A swarm, not a bot

You hand an agent a job that looks reasonable: compare twelve supplier contracts against your standard terms and write up where each one differs. It starts well. By contract five it has read three hundred pages, tried two ways of building the comparison table and abandoned one. By contract nine it quotes a termination clause that belongs to contract four. The summary arrives two hours later, fluent and confident, and wrong in at least two places. You do not know which two, and the only way to find out is to do the job again yourself.

Nothing in that story requires a bad model. The same model, asked about contract nine on its own, gets it right.

The real cause is the shape of the job

A single agent doing a long job carries the whole job in one context. Every page it has read, every tool output, every dead end it tried and every plan it revised stays in the window and competes for attention with the thing that matters now. Context is the scarce resource, and one bot spends it on its own history.

Bigger windows postpone the problem; they do not remove it. A longer window lets the agent hold more of the past, which is exactly what is hurting it. The fix is not more room. It is less clutter in any one place.

Where one bot breaks

Context rot. Material from early in the job bleeds into decisions late in the job. The agent does not forget contract four; it remembers it at the wrong moment.

A plan that lives in its head. The plan exists only as sentences in the conversation. When it is revised, the old version is still there a few pages up, and nothing marks which one is current. You cannot read the plan without reading the whole transcript.

One set of permissions for everything. The step that reads a stranger’s web page runs with the same keys and the same network as the step that sends an email. Whatever the least trustworthy input can persuade the agent to do, it can do with everything you gave it.

No unit of review. Two hours of work come back as one block of prose. You cannot check what was concluded about contract seven without checking everything, so in practice nobody checks anything.

All-or-nothing failure. If the run dies at the ninety-minute mark, the work dies with it. There is no list of what was finished and nothing on disk to resume from.

What a swarm does instead

A swarm splits the same job along the lines a careful person would.

A planner takes the goal and writes it down as a to-do list, in a file rather than in its head: twelve contracts, one item each, plus a final item to assemble the comparison. The file is the plan. It can be read, edited and resumed, and when the planner changes its mind the change is visible.

Each item goes to a sub-agent with a fresh context. It sees one contract, your standard terms and the instructions for the comparison, and nothing else. It does its reading and its dead ends in its own workspace, then hands back one report: the differences it found, with page references. The scratch work stays behind in its files, where you can open it if you want to, and out of the planner’s way.

The planner’s context now holds the plan and twelve short reports. That is small enough to think clearly about, which is the whole point.

Two more properties come for free. Every sub-agent runs in its own KyberCell, so the one reading an untrusted document holds no keys and no open network. And because each step is written down, the contract-seven conclusion has its own trajectory you can check without touching the other eleven.

Where a step is sensitive — sending something, paying something, deleting something — the swarm does not decide. It stops and asks the assistant that sent the work, and that assistant asks you. That hand-off is the subject of a piece on KyberBot’s site about how an assistant hands work to a swarm. Underneath, each cell is held in place by the operating system, which is the subject of how KyberLinux keeps a swarm in its cells.

What a swarm costs

It is not free. A swarm spends more total compute than one bot doing the same job, because twelve sub-agents each read the standard terms and each start from zero. Coordination adds latency. And for a short question a swarm is ceremony: working out which of two dates is later does not need a planner.

The trade is worth making when the job is longer than the attention of one context, when parts of it touch untrusted material, or when someone will need to check the result piece by piece. Most work that matters is at least one of those.

A test you can run today

Take the last job you gave an assistant that ran for more than half an hour, and answer four questions without asking the assistant.

1. Can you read the plan as it stands now, separately from the conversation?
2. Can you point to the part of the result that came from one sub-task and check it on its own?
3. If you had cancelled the run halfway, what would have survived?
4. Did the step that read untrusted input hold the same permissions as the step that could act?

If your answers are no, no, nothing and yes, you had a bot, not a swarm. That is not a criticism of the model. It is a description of the shape it was forced into, and the shape is the part you can change. The KyberAgent homepage shows how the rest of the system fits around it.