Agent autonomy is not just about following instructions. It is the ability to coordinate without a human in the loop. It sounds like magic — until you see it with your own eyes.
One of the ecosystem's services lost its backups. Production data was never at risk, but a service without backups is not something you sleep well next to. The anomaly was spotted by the data-check agent. A second agent, the implementer, deployed a fresh backup routine and set up the cron job. The two never exchanged a single line — no chat, no «pass this along to him». What worked was shared context.
What follows is how that mechanism is built and why it changes the way development is managed. No inside plumbing required: exact IPs, hosts, passwords, and repository names add nothing to the story.
Coordination Without a Coordinator
Each agent works in an isolated session. It cannot see the others: it has no idea how many there are, what they are doing, or how the work is split. What it can see is the shared knowledge base — a space where statuses, logs, decisions, and the context of finished tasks are written down.
That base is not an archive but a living document. An agent reads it before starting work and writes back to it when finished. The decision about what to do comes not from negotiation but from reading: what has already been done, what remains open.
In the backup case, the first agent noticed a mismatch between the expected schedule and the actual logs. It did not raise an alarm to anyone — it recorded the gap in the context: «production database — last successful backup N days ago».
The second agent started later and for a different task — setting up monitoring. Reading the context, it saw the gap and decided on its own: before adding monitoring, the backups had to be restored. It deployed the backup, verified it worked, and only then returned to its primary task. No one issued a «fix the backup first» instruction. The decision came out of the context.
Why This Is Not a Fluke
A single success is luck. But the pattern repeats. Cross-agent coordination through context becomes a system precisely as the work grows harder: over the second month the share of complex tasks rose, even though their total count barely moved. The substance got heavier; the human involvement in coordination did not.
The reason is not a clever algorithm but a simple rule baked into how an agent behaves: «if the context shows an open problem and no one is assigned to it — take it on». Responsibility is not passed around. A problem an agent stumbles upon and that no one is fixing becomes that agent's problem.
From Dispatcher to Architect
Time used to go into manual coordination. «This agent checks the backups, that one sets up monitoring, reconcile their results in the evening» — the work of a dispatcher holding in their head who is doing what and what depends on what. Now the time goes elsewhere: into keeping the context full and current. Who takes which task, the agents decide themselves.
The shift is measurable in money too. The base cost is the Claude subscription; on top of it, the month's delegation to cheap external models through Coworker came to $15.18 — the grunt work that would otherwise eat into expensive Claude limits. Add the fixed server rent. This is a change not in the amount but in the line item: instead of paying for a dispatcher's attention, paying for the completeness of context.
The coordination is powered by the Datarim framework — already open-sourced under MIT. Coworker, which spreads load across LLM providers, is open too. The code that coordination rests on should be auditable — that is the point of publishing it openly, not the GitHub stars.
What Actually Lives in the Shared Context
For an agent to decide instead of a human, the context has to hold exactly what the human would keep in their own head. A month in, it turned out this is not «all the documentation» but a few specific layers.
The first layer is task state. What is closed, in progress, blocked, and why. This is where an agent looks first: is it duplicating someone else's task, does its step depend on someone else's unfinished one.
The second layer is the history of decisions. Not «what was done» but «why it was done this way». During the migration of the database to a dedicated server, an agent recorded not only the command but the reason: why commit date rather than file modification time; why deduplication by filename. The next agent hitting the same fork reads a ready decision instead of reinventing it.
The third layer is open problems with no owner. The most important one for coordination. This is exactly where the second agent learned about the broken backup. The rule is short: a problem no one has claimed, and you ran into it — you take it. Not «pass it on», not «leave it for later».
This structure did not arrive at once. For the first weeks the base was a dumping ground: agents wrote everything into it, and reading it became more expensive than working the task out from scratch. It took a dedicated task to clean up the knowledge base itself: sort the logs into layers, drop the duplicates. Context that no one tends loses its value as fast as a team without a coordinator.
Context as a Safe Space
This approach has a flip side, and it is more honest than any conclusion. Context does not make agents omniscient: what is not in the base, an agent will not guess. A couple of times this month that is exactly what happened — an agent walked past a problem that had no line in the context, because it stayed in a human's head and was never written down. The uncomfortable lesson: the discipline of writing things down now matters. The cost of coordination did not disappear — it moved from manual control to the completeness of context. That is cheaper, but not free.
The principle holds regardless of team size — one developer or a hundred, these tools or others. Context decides not because it is smart, but because it lets the agents be smart themselves. When the context is complete, instructions become redundant: the agents find work for one another in it and figure things out on their own.