Multi-Agent Systems Are Mostly the AI Version of Conway's Law

Carlos E. Perez put it bluntly in that tweet: most multi-agent systems are just the AI version of Conway's Law. Give every team an expert subagent and put an orchestrator on top, and the result is Frankenprompts, lossy handoffs, subagent sprawl, and doubled latency.

Anthropic recently published a long article with a very direct title: “Building agents: When to fold subagents into your main agent loop.” Its core recommendation is one sentence: fold most subagents back into a single main agent loop, using progressive skills and tool search for progressive disclosure. Shared context plus today's models can often beat multi-agent setups on quality, cost, and speed.

The original link is here: https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop

The background is worth spelling out. Enterprises want an agent with a single entry point, with different capabilities owned by different teams. The easiest approach is to have each team build its own agent, then have a platform team build an orchestrator. The structure looks simple, but it immediately creates several costs:

• Context management: what gets passed between agents often loses detail as it goes back and forth.
• Subagent sprawl: every team ships its own, ending up with hundreds that overlap, lack common standards, and have no clear owner.
• Frankenprompt: every team adds a line to the system prompt, the rules conflict, and the voice is inconsistent.
• Siloed evals: everyone adds a set of evals optimized only for their own subtask, no one maintains the full set, and the scores leaders receive are diluted.
• Latency: every extra layer of architecture adds another layer of latency. One customer compared them and found a single-agent loop was about 2x faster.

Anthropic's article includes three diagrams that make the problem quite intuitive. The first is a typical subagent design: routing, planning, and domain experts stacked layer upon layer.

The second explains the downside of splitting by problem type: each agent carries only its own piece of context, the agents play a game of telephone, and information gets distorted with every handoff.

Why does a single loop work again now? The article gives three reasons. Shared context produces better answers; in long tasks, earlier results stay in the main window and can be connected together. Progressive disclosure prevents context bloat—skills and tools load only when needed, which cut Claude Code's system prompt by more than 80%. And the models themselves have gotten stronger: starting with Opus 4.5, a single loop can handle more than most teams expect, and each new model can move more decisions from the harness into the model.

The migration path is not all at once either. First merge the most-used subagents, especially those that are frequently called in sequence, touch the same data, and appear in pairs in production traffic. Before merging, build a small end-to-end eval. If you don't want to rewrite, you can first call the subagent as a tool while the main agent keeps talking to the user. Only at the end do you turn each subagent's prompt into a skill and its API calls into MCP tools, comparing evals one by one: leave the worse ones in place and fold in the better ones.

The comments include several voices worth reading.

AI Quanting asked a technical question: where exactly does the 2x latency come from? If subagents run in parallel, the cost should fall on handoffs and the orchestrator's own turns, so what needs cutting is the number of hops. This challenge is quite accurate: folding saves round trips; parallelism is not the key.

Luiya said he runs 5 agents each handling a separate area, and every bug lives in the handoffs, so folding subagents into a single loop makes him 'uncomfortably convinced it makes sense.' But he would keep the parallel part.

hankthetank reminded people that cost should be calculated per validated result, not per run. Missed bugs, false positives, and review time all have to be included; otherwise, a faster single loop may be a more expensive system.

There is also a data reversal worth noting in the material: Vals AI's benchmark found that an agent team cost 1.8 to 5.1 times as much as a single agent, while only one score difference was statistically significant. In another test, a multi-agent Claude workflow found 66 of 70 planted bugs, while a single agent found at most 27. The same material contains evidence both for and against folding, depending on whether you are optimizing for cost or recall.

Anthropic itself says there are still three cases for subagents: when a single loop shows measurable performance degradation due to context bloat; when you need parallel, disposable new context windows; and when a single agent selects tools poorly or the system prompt contains conflicting instructions.

The closing line of the article is worth copying down: the stronger the models and the longer agents run, the more subagents can become skills and tools. But you don't have to do it all at once. Build small end-to-end evals, fold one in, check the scores, put the worse ones back, and keep folding in the good ones.

The direction of architecture evolution is starting to shift from 'what can we add' to 'what can we remove.' This is the most noteworthy line in this guide.