The diagram I keep almost drawing has five boxes in it. A researcher agent, a writer, an editor, a QA pass, and an orchestrator sitting above them holding the whole thing together. You have seen this diagram. Somebody draws it at every AI meetup, the boxes always have job titles, and the finished picture looks like a company with the people removed. It is a seductive thing to draw and I have started drawing it more than once.
What actually does my work looks nothing like that. One instruction file, twenty-five skills and twenty-five slash commands, all of them written by me, accumulated over months in ten-minute increments after something went wrong. There is no diagram. Nothing in it would survive a demo.
The case for the five boxes isn't silly. Anthropic published figures from their own research system: a lead agent running parallel subagents beat a single agent by 90.2% on their internal research evaluations. That is not a rounding error. The reasoning behind it is clean, too. Each subagent gets its own context window, so a fleet holds more of a problem in mind than any single agent can, and it looks in several directions at once. More agents, more capacity, and the gain shows up in a number.
Then read the second figure in the same post. Multi-agent systems burn roughly fifteen times the tokens of a chat, and Anthropic is direct that the task has to be worth it.
Tokens are the cheap part of that bill.
The expensive part is that every agent you add is a thing you now own. Instructions drift. Edge cases surface one at a time, each arriving as a small surprise, and then there is the boundary with the other agents, which has to be negotiated. That negotiation is where the interesting failures live. Walden Yan at Cognition wrote this up in June 2025 under the blunt title "Don't Build Multi-Agents". His example is two subagents asked to build a Flappy Bird clone: one produced a Super Mario style background, the other built a bird that didn't match it, and the coordinating agent had no way to reconcile them. Neither subagent did anything wrong. They just each made an assumption the other never saw. Yan's second principle states it plainly: "Actions carry implicit decisions, and conflicting decisions carry bad results."
You can read all of that as a temporary engineering problem, and you would have Anthropic's own words behind you. Their post says LLM agents are not yet great at coordinating and delegating to each other in real time. "Not yet" is carrying weight in that sentence and it may well be right. Coordination is the kind of thing that gets solved. I wouldn't bet against it.
So grant it. Assume the coordination problem clears next year and the fleet stops tripping over itself. Something in the comparison still doesn't move.
Count what a new agent gets you: one agent, doing one job. Now count what a change to the layer underneath gets you. The two rubric files that govern how I write run to just under four thousand words between them. They were slow to write and I resented most of it. They now apply to everything I write, through every tool I point at them, including the ones I haven't built yet. A new agent is an addition. A change to the shared layer is inherited, and inherited by things that don't exist yet.
Economists have had a name for that shape since 1995. Bresnahan and Trajtenberg's paper on general purpose technologies argues that steam, the electric motor and semiconductors earned their status through a specific property, which the authors call innovational complementarities. Plenty of inventions were useful. These ones had the trait that every downstream sector using them got more productive each time the thing itself improved. That is a grand comparison for a text file and I'm not making it. The shape is the same at a much smaller scale, which is all I need. Improvements to a shared layer are inherited. Improvements to a unit stay in the unit.
So any setup like this has two layers in it. There's a countable layer, made of things you can point at and name, and there's a compounding layer, made of whatever those things all sit on. They are never the same layer, and the reason is structural rather than accidental. A thing becomes countable by being discrete and separable. A thing compounds by being shared and inherited. Those are opposite properties. Anything you can tally is, by construction, something whose improvements stay local.
Which raises the better question. If the leverage sits in the layer underneath, why does everyone spend their weekend building the fleet?
Because the fleet is legible. It has names, an architecture diagram, a headcount, and a demo. A harness improvement is a diff in a text file that makes several unrelated things slightly less annoying, and it is invisible to everyone, including to you in three weeks when you can't remember what changed. James C. Scott's Seeing Like a State is four hundred pages on the heavy version of this problem, where states rebuild what they govern so it can be read from the centre. What can't be counted from the centre gets managed as though it isn't there, and it is regularly the part holding everything up.
We do the small version to ourselves, and nobody is forcing us. The agent count is the legible metric, so the agent count is what grows. Nobody demos a text file.
The model has to survive its own counterexamples, and there are two real ones. The first is that the fleet genuinely wins under conditions Anthropic states precisely: breadth-first work, several independent investigation paths, information that exceeds a single context window. Their research system is a good fit for its own architecture. Cognition's exception points the same way, at subagents that stay narrow, don't write, and never have to agree with each other about anything.
The second counterexample is harder on my argument. You can't improve a harness you haven't used. The knowledge of what the shared layer is missing only arrives through building the specific thing and watching where it fails. Agents come first in the order of operations, and they have to. The failure arrives later, when you build the tenth one without ever writing down what the first three taught you, because the tenth agent is visible progress and the writing-down is not.
The practical form of this is a question available at the moment something breaks. An agent does something bad. You now have two places to put the fix: into that agent's instructions, or into the layer beneath it. The first is faster and it is almost always what happens. The second is the one still working after you've thrown that agent away.
And you will throw that agent away. My expectation, not a finding: most of what sits inside a given agent right now is compensation for a model limitation that won't survive two more releases. The scaffolding gets rebuilt every time the ground moves. The rubric doesn't. Each upgrade quietly deletes some of the fleet and none of the substrate.
So the diagram is wrong even when the boxes are drawn correctly. Draw it honestly and the agents shrink to something between a wrapper and a job title, and the thing carrying the weight turns out to be a file nobody would sit through a demo of.