Agents
How an agent combines static instructions, memory configuration, runtime context, and an assigned capability surface.
Agents are the primary behavioral units in Nenjo, and the composite that assembles every other primitive. An agent defines a role: how work is interpreted, what prompt context matters, which capabilities it can access, and how it behaves across runtime modes.
How an agent is built
An agent's behavior comes from a layered prompt configuration plus a memory profile:
system_prompt— the agent's soul: stable identity, voice, and core principles. This is what abilities inherit and domains build on; it should not change between runs or modes.developer_prompt— tactical behavior: routing, response discipline, and tool-use guidance. This is the layer abilities replace and domains append to.- Memory profile — which memory scopes the agent draws from (
core_focus,project_focus,shared_focus). It configures retrieval; it is not prompt content.
Put stable identity in the system prompt, tactical behavior in the developer prompt, and reusable static guidance in context blocks. The runtime supplies changing execution data separately.
Runtime modes and context
The identity and memory profile stay stable across modes. The worker builds a typed turn-context message for the active mode and follows it with the raw input.
| Mode | Runtime input |
|---|---|
chat | Turn clock/context, then the raw user message |
task | Task/routine/Git context, then the task instructions |
gate | Task/routine/gate context, then the evaluation instructions |
heartbeat | Scheduled execution context, then the configured instructions |
council | Council task context, then the member or leader instructions |
Chat, task, and gate templates are not agent configuration. This keeps authored instructions byte-stable while the changing tail remains explicit and replayable.
Heartbeat schedules
An agent can carry an optional heartbeat schedule — a recurring autonomous run for checks and maintenance loops. The schedule provides execution input; the worker places changing schedule state in runtime context instead of rendering it into the static prompts.
Assigned capability surface
An agent gains capabilities through explicit assignments:
- Abilities — agent-invoked specialist behaviors
- Domains — user-activated execution modes
- MCP servers — external tool integrations
- Script tools — package or native script-backed tools
- Model — the LLM that runs the role
- Platform scopes — permission refs (assigned by users or platform policy, never self-granted)
Start with a clear role and the smallest useful capability set. Add tools, scopes, domains, knowledge, and memory focus deliberately as the agent's responsibility grows. Prefer assigning a focused ability over broadening the base prompt.
Once you have agents, workflows orchestrate several of them into repeatable processes.