Troels Frimodt Rønnow

Every "I built X with multi-agent Claude" post I read this year follows the same arc. The author spawns five sub-agents. They run in parallel. The author calls it 5x faster. The implication is that you should also spawn five sub-agents next time you build something.

This is the wrong lesson. If you take it at face value, you will burn a weekend wiring up an "agent crew" that turns out to be slower, less reliable, and harder to debug than just writing the code yourself.

The actual reason sub-agents work, when they work, has nothing to do with parallelism. It is context isolation. Once I internalised that, I started building very different systems — and I stopped reaching for orchestration when a single Claude Code session would have shipped the feature in half the time.

The example everyone is copying wrong

The financial dashboard build from Gencay on AIMaker is the canonical sub-agent demo. Five agents: Frontend Architect, Data Layer, Visualisation, Prediction Engine, AI Counselor. Each owns a slice of the app. They coordinate through a /specs folder. It ships fast.

The post reads like a manifesto for parallelism. It is not. Look at what each sub-agent actually does. The Frontend Architect never touches Prophet forecasting code. The Prediction Engine never reads React component trees. The AI Counselor never debugs FastAPI route handlers. Each one runs in a clean context window — no irrelevant test logs, no half-finished sibling implementations, no 40,000 tokens of "here is the rest of the codebase for your reference".

That isolation is the whole point. The parallelism is a side effect.

Spawn five sub-agents that share the same context and bicker over the same files, and you will not get 5x speed. You will get five conflicting plans for the same problem, a merge nightmare, and a project that takes longer than building it sequentially.

What context isolation actually buys you

Three things, in order of how often I need them:

Smaller working sets. A sub-agent that only sees the React frontend cannot get confused by your Python data layer. Its tool calls are cheaper, its decisions are sharper, and the model is less likely to invent compromises that span boundaries it should not be crossing. Same reason I put modules behind interfaces in my own code.

Cleaner returns. A sub-agent returns a summary, not a transcript. That summary is what the main agent gets to keep. If the sub-agent spent 30 tool calls fighting a Prophet install, the main agent sees "predictions endpoint built, smoke-tested at /predict". You filter noise at the boundary.

Tool scoping. A research sub-agent gets read-only access. A builder gets write. A tester gets bash. This is not a productivity hack; it is a safety boundary. The blast radius of a confused agent shrinks to whatever its tool whitelist allows.

None of these benefits require parallelism. You can run sub-agents one at a time and still capture all three. The bottleneck is almost never wall-clock time on the AI side — it is the back-and-forth between you and the model.

The three patterns worth knowing

Once I stopped thinking about sub-agents as teammates, the patterns in the wild started to cluster into three shapes:

The Router. A small dispatcher reads the user's question, picks the right specialist agent, and routes the call. Each specialist has its own grounded knowledge base. The router holds no domain context — only a map of "who knows what". The NotebookLM founder router walkthrough is the cleanest version of this pattern I have seen written up. It works when you have N independent expert domains and a clear classifier for which one to invoke.

The Crew. A single planner spawns N sub-agents, each owning a disjoint slice of work. They coordinate through a shared spec file, not by chatting. The financial dashboard above is the textbook example. It works when the slices truly are disjoint and the boundaries are stable enough to write down before the work starts.

The Unified Agent. One agent at the top, with reusable skills, MCP integrations, and a CLAUDE.md that orchestrates the whole pipeline. No sub-agents at all — just skills composed in sequence. The "stop juggling Claude Projects, build one Claude Cowork" piece on GenAI Unplugged is the best argument I have read for this pattern. It works when the workflow is linear and you would otherwise be the one carrying state between disconnected Claude Projects.

These are not interchangeable. Pick wrong and the architecture fights you.

When sub-agents are the wrong answer

Here is the prediction you can disagree with: most "multi-agent" projects on developer Twitter are unified agents in a trench coat. The author would have shipped faster, with less infrastructure and less debugging time, by writing one good CLAUDE.md and a few skills.

The signal that you do not need sub-agents:

The work is linear. Step B genuinely cannot start until step A finishes.
The slices are not really independent. They share state, they share schema, they share definitions.
The "team" never disagrees. If the planner already knows what each sub-agent will do, the planner can just do it.
You will read every output anyway. Filtering at the sub-agent boundary saves you nothing if you babysit each handoff.

Content workflows almost always fall into this trap. Writing a newsletter is not five parallel jobs. It is one job with five phases, and the phases need to see each other. Use a unified agent with skills. The Cowork pattern wins here because Substack-publishing and internal-link-suggesting genuinely do not need their own context windows — they need to share yours.

How to decide in 30 seconds

Before you reach for sub-agents, answer two questions.

First: are the contexts genuinely different? If your Frontend Architect would benefit from seeing the data layer's code, you do not have a sub-agent boundary, you have an artificial wall. Tear it down.

Second: would you want this output as a summary, or as a transcript? If the answer is "I need to read every line the agent produced", you do not want a sub-agent. You want a chat. Sub-agents are valuable precisely because their full reasoning is discardable.

If both answers point to isolation — different contexts, summarisable outputs — spawn the sub-agent. Scope its tools tightly. Give it a written contract via a spec file. Then let it run.

If either answer is shaky, write a CLAUDE.md, build a couple of skills, and move on. You will ship sooner and have less to maintain.

The takeaway

Multi-agent architecture is not a tier above single-agent work. It is a different shape of solution, with its own cost. The cost is real: more failure modes, more orchestration code, more state to keep consistent, more places where the model can lose the plot.

You pay that cost when context isolation buys you something concrete. You skip it when one well-instructed agent would have done the job.

The teams I see compounding the fastest are not the ones with the most exotic agent topologies. They are the ones who know which pattern to reach for, and — more often — which one to leave on the shelf.

If your team is currently building "an agent crew" and you cannot articulate what each agent's context window contains that the others' do not, you have the wrong pattern. Send me a message and I will help you draw the boundaries on the back of an envelope before you write more orchestration code.

Sources I drew from: