Here's a type that lived in our
It's gone now. One loop, two tools, and the app does more than it did before.
If you're starting an agent project this year and your first instinct is to sketch that fan-out diagram, this post is for you, because it was my first instinct too, and it was already about eighteen months out of date when I drew it.
why we all built it this way
The router-orchestrator shape wasn't stupid. It was the correct answer to a problem that existed.
In 2024, models were noticeably worse at two things: holding a long mixed context without losing the thread, and picking the right action out of a large action space. Both of those are fixable by narrowing the space. Give each agent three tools and one job, and it can't pick wrong. Give it a fresh short context, and it can't get confused. OpenAI shipped Swarm, Microsoft shipped AutoGen, and every tutorial on the internet drew the same picture, so I drew it too.
That constraint has mostly lifted. Models today follow long instructions, keep track of what happened forty messages ago, and select from a couple dozen tools without much drama. If you're still splitting work into specialists in 2026, there's a decent chance you're engineering around a limitation your model doesn't have.
LangChain's own guidance now opens with a version of this: start with one agent, add tools before you add agents, and only graduate to multi-agent when you hit an actual wall. That's from the January 2026 is blunt about the cost of that: it "adds one extra model call per interaction", because everything has to come home before it can be spoken. So I was paying a full serial round trip on every single turn, including "draw me a diagram of a URL shortener", where there is nothing whatsoever to classify.
Fine, that's latency and tokens. Measurable, annoying, survivable.
The part that isn't on the invoice is worse. Every handoff is lossy compression. When a specialist finishes, the next agent doesn't see what it saw, it sees a summary: the reasoning, the intermediate tool results, the constraint the user mentioned three messages ago and never repeated, all flattened into a paragraph. Then the next decision gets made on that paragraph.
named this exactly in on 13 June 2025, describing an orchestrator-worker architecture that beat a single agent by 90.2% on their internal research eval. Opposite titles, consecutive days, both from teams who obviously know what they're doing.
That's a signal to read harder, not to pick a side.
a few days later and found the thing they actually agree on: "read actions are inherently more parallelizable than write actions". Reads fan out cleanly. Writes collide, because now you have to merge two sets of implicit decisions. And look at what Anthropic's system does with that, which is easy to miss under the headline number: the research runs in parallel across subagents, then the lead agent writes the report itself, in one pass. They didn't parallelise the writing either.
The number that recontextualises the 90.2% is in the same post. Anthropic found that "token usage by itself explains 80% of the variance" in performance on BrowseComp. Multi-agent won mostly because it spent more. Agents burn roughly 4x the tokens of a chat; multi-agent systems around 15x. That's a compute purchase, and sometimes a good one, but you should know which thing you're buying before you attribute the win to your architecture.
the update most people citing this stuff have missed
Cognition shipped a follow-up in April 2026:
The model reads the request and works out whether to ask a clarifying question, draw something new, or modify a diagram already sitting on the canvas, in the same reasoning pass it uses to do the work. The decision and the execution share a context because they are the same context. Nothing gets summarised on the way.
Where did the routing logic go? Into the tool descriptions.
description:
"Render the final diagram to the user's canvas. Call exactly once per design, " +
"after you have written a short plan in chat. Set targetId to update a diagram " +
"already on the canvas; omit it to add a new one.",
This is the part I'd have underestimated reading someone else's version of this post. In a router setup, a router prompt decides who handles what. In a single loop, your tool descriptions are your routing logic, and they have to be prescriptive about when to call, not just polite about what the tool does. Writing them like docstrings gets you a model that calls the right tool at the wrong moment. Rewriting one sentence is also a much cheaper experiment than moving an agent boundary, which I'd trade for the saved model call any day.
The step cap earns its line too. A router bounds work structurally, the graph just ends. A loop will keep going if you let it, so it needs a ceiling you actually write down. (isStepCount is the AI SDK 7 spelling btw. It was stepCountIs before, so half the examples you'll find online won't compile.)
when you should still split
I'm not anti-multi-agent, and I don't think the takeaway is "always one loop forever".
The rule I'd give my past self is: writes stay single-threaded. One agent owns mutation, full stop. Anything that only reads can safely go parallel, and honestly a read-only helper is a tool call with extra ceremony, so treat it as one. If you're about to let two agents write, you've just signed up to own conflict resolution between two things that can't talk to each other, and you'll discover the conflicts at the worst possible moment.
Beyond that: count your tools before you count your agents. If it's a handful, you don't have a routing problem, you have a tool-description problem. And if you can't read one trace end to end, every future bug is going to cost you a multiple to diagnose.
When project-wide chat over markdown files lands in what I'm building, I'll probably add a read-only search subagent, because reading parallelises and that's the pattern the evidence supports. I might be wrong about the shape of it. I'll find out and write it up.
What's not coming back is a classifier in front of everything.
sources
, Walden Yan, Cognition, April 2026
, Harrison Chase, LangChain, June 2025
Choosing the Right Multi-Agent Architecture, Sydney Runkle, LangChain, January 2026
SOCIAL SHARE CARD GENERATOR