Anatomy of a deep agent: plan, sub-agents, files, memory

An exploded view of an agent unit: cover, planner board, three small cards, storage drive and memory module floating apart

You leave an agent overnight with a job that should take a few hours: read the guidance for three grant programmes, check your project against each, and draft a one-page note on which to apply for. In the morning there is a cheerful message saying it is done. The note recommends a programme whose deadline passed last month, which the agent noticed at step twelve and forgot by step forty. Its working is spread across a conversation you would need an hour to read. There is no plan to look at, no notes, and nothing to restart from if you want to fix one part.

The real cause: a loop is not an agent

Most agents are a loop. The model thinks, calls a tool, reads the result, thinks again. For five steps that is enough. For five hundred it is not, because everything the agent knows about the job lives in one place, the conversation, and the conversation is its memory, its workspace and its plan all at once.

What makes an agent deep is not a bigger model. It is a handful of parts outside the model that give the work a structure: something to plan with, someone to delegate to, somewhere to write, and something to remember with. Remove any of them and a specific thing breaks.

Four parts, and what breaks without each

The plan. A to-do list in a file. Without it, the agent’s plan is whatever it last said, and a long run drifts: early constraints, like a deadline, quietly fall out of view. With it, the plan is an object you and the agent can both read, each item has a status, and a constraint written at the top stays at the top.

Sub-agents. Workers started with a fresh context for one item each, returning one report. Without them, everything happens in the same context, and the agent’s attention is spent on its own history; see why a swarm beats a single bot. With them, the planner holds only the plan and the reports.

The file system. A virtual file system the agents read and write: notes, drafts, downloaded documents, intermediate results. Without it, every result lives in the conversation and dies with it, and a long-running task cannot survive a restart. With it, work accumulates where you can open it, and one sub-agent can pass the next a file instead of a paragraph.

Memory. Two kinds, deliberately kept apart. The working memory of the job is the files above, and it belongs to the task. Long memory about you is different: in Kyber it belongs to KyberBot, lives on your own devices, and is mostly kept on a home node. A swarm is given the slice of it a task needs. What agents may keep is what they learned about the work — this source was unreliable, this method failed — written down as notes, not what they learned about you.

There is a fifth part worth naming. Skills are folders of instructions and scripts — how to read a grant guideline, how to format a note — loaded only when a task calls for them. Without skills, either the prompt grows until most of it is irrelevant, or every run reinvents the method. With them, the agent’s know-how is a readable thing you can version and edit.

What holds the parts together

Parts are not yet a system. Four things connect them.

A homeostat on cost and confidence. The planner watches what the swarm is spending and how often its reports get corrected, and when either leaves its range it slows down: fewer sub-agents, smaller steps, more questions. The argument for regulating an agent’s own behaviour is in an agent that regulates itself.

Policies outside the model. What a sub-agent may read, run and reach is decided by its KyberCell, not by a paragraph in its prompt. A model can be talked out of an instruction. It cannot be talked out of a closed port.

A human in the loop, through one door. Agents do not interrupt you directly. Anything sensitive goes back to KyberBot, which knows when to ask you and how.

A shared picture of the world. Twenty sub-agents need one answer to what a client or a deadline is. A small ontology and a graph give them that, so their reports fit together.

None of this depends on which model does the thinking. A small model on a deck and a large one elsewhere fit the same anatomy, which is the point: the structure carries over when the model is replaced. All of it runs on KyberLinux, the same system on a card and on a server.

A test you can run today

Give your current agent a job with about ten steps. At step six, stop it. Then answer:

  1. Can you open a file that shows which steps are done?
  2. Are the intermediate results files you can read, or only messages in the conversation?
  3. If you restart it, does it pick up at step seven or at step one?
  4. Is a constraint you gave at the start still visible to it at step six?
  5. Did it load instructions for tasks it was not doing?

Each “no” to the first four and each “yes” to the last is a missing part. You do not need our system to fix them, but you will find yourself building the same five things. The KyberAgent homepage shows how we put them together.