Claude Agents at Work
by Isaac Otu
Chapter 1
On 6 August 2026 I asked one of my agents a plain question: what do you actually do anymore.
It was a coordinator, the kind of agent whose only job is deciding which other agent runs next, and for months it had been describing its work to me in the same confident terms. It ran on a schedule. Certain tasks fired on Mondays, Wednesdays, and Fridays; a report went out on Saturdays. I finally checked that schedule against the list of tasks the system actually had registered, and none of them were there. They had been cleared out weeks earlier in an unrelated tidy-up. Nobody had told the coordinator, because a schedule that has quietly stopped firing does not announce it. It just goes on believing.
On its own that is just a stale config. What made me sit up was the next thing I found: a second agent, in the same operation, carrying its own copy of the same dead schedule in its own instructions. Two agents, confidently wrong about the same fact, and nothing anywhere in the system had noticed or ever would have.
Most writing about AI agents sells a tidier picture. You build a set of them, each with a job, and they run your operation while you sleep: a marketing agent, a support agent, a research agent, a little company that looks after itself. It is an appealing picture and it is not entirely wrong. It just leaves out the part that decides whether the thing actually works.
The tidy picture leans on a metaphor: agents as teammates. And the metaphor quietly imports an assumption from real teams, that a colleague working from a wrong idea gets corrected by the others, because people talk and notice and push back. Agents do not do that. A fleet is a team where nobody looks up from their own desk unless you make them.
Underneath the metaphor is a real line. One agent is a tool. A fleet of agents is an organisation. Crossing that line changes what can go wrong, not just how much you can get done.
A tool holds no belief about your operation that outlives the conversation you are having with it. You supply the context fresh each time, or you keep it in one project, and nothing sits in a file somewhere getting a little more wrong every day nobody looks. A fleet has exactly that: parts that hold beliefs about your operation on their own, between conversations. Those beliefs drift, in different directions, about the same fact, and nothing is built to pull them back together. The dead coordinator was one such belief. The second agent was another, drifting the same way, found by accident.
You cannot scold your way out of this one. It falls out of how the systems are built.
When a fleet dispatches an agent, that agent's working context is assembled from its own definition plus whatever it is handed for the task. There is no shared store every agent reads through on its way to acting, the way application code reads through one database. Updates are local: you edit the file for the role you happen to be thinking about that day. What you end up with has the consistency guarantees of a stack of separately maintained documents, which is to say none.
You can build it the other way. Some frameworks route every agent through a shared state object or a common memory, so there is one copy of the truth and every role sees the same one. That trades the drift for a different set of problems. The shared store becomes a bottleneck, and a single point of staleness where one wrong value makes every role wrong at once, and it couples roles that should never have needed to know about each other. Distributed per-agent context buys you isolation, simplicity, and the ability to keep working when one part breaks. The drift is the bill for those. What is not defensible is running the distributed design and then acting surprised, months later, that the copies disagree.