Rupam Golui

Posted on Aug 4

Are you still using a router-orchestrator for your agents in 2026?

#ai #typescript #architecture #llm

Here's a type that lived in our OpenDiagram codebase until a few weeks ago:

export type WorkspaceAgentId = "router" | "memory" | "diagram" | "canvas" | "answer";

Five agents. A router out front to classify your message, a memory agent to pull project context, a diagram agent to plan the design, a canvas agent to render it, an answer agent to write the reply. Progress events streaming to the UI so you could watch the baton get passed between them, little spinners lighting up in sequence.

It demoed beautifully.

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 architecture comparison, which is worth reading in full because it also caught me being sloppy.

the bill, and the part that isn't on the bill

Small confession that changes the argument.

I called mine a router. In LangChain's taxonomy a router is stateless: classify, fan out in parallel, synthesise, done. Three model calls for a one-shot request, same as the alternatives. Not actually the expensive one.

What I'd built was the subagents pattern wearing a router's name. Classify, dispatch to a specialist, flow the result back through a main agent that writes the reply. Sydney Runkle 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.

Walden Yan named this exactly in Don't Build Multi-Agents: "actions carry implicit decisions, and conflicting decisions carry bad results". Two agents each make dozens of unstated choices about naming, spacing, edge cases, style. Nobody reconciles them. You find out at integration time, which for a diagramming tool means a canvas that looks like two people drew half of it each and neither of them talked.

Third cost, and this is the one that actually wore me down: debuggability. One agent gives you one trace to read top to bottom. Five agents give you a conversation between processes, each of which made a locally sensible decision that summed to a globally wrong one. Every debugging habit I have assumes determinism lives somewhere in the stack. Here it doesn't live anywhere.

All of that machinery, and I had two tools.

two blog posts, one day apart

This is where I'd have written a much dumber post if I'd stopped at the vibes.

Cognition published Don't Build Multi-Agents on 12 June 2025. Anthropic published How we built our multi-agent research system 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.

Harrison Chase went looking for the overlap 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: Multi-Agents: What's Actually Working. Same author, ten months later, updated position. The class of multi-agent systems that works today is narrower and specific: multiple agents contribute intelligence while "writes stay single-threaded". Read-only helpers are fine, and he points out that most working multi-agent setups in the wild are exactly that, closer to a tool call than to a colleague.

So "multi-agent is dead" is wrong, and anyone quoting only the 2025 post is a year behind. I was that person right up until I opened the follow-up.

There's a genuinely strange finding in there too. Devin's review agent works better when it shares no context at all with the agent that wrote the code, catching around 2 bugs per PR on Devin-authored PRs, roughly 58% of them severe. That looks like a direct contradiction of the share-everything principle from ten months earlier, and it mostly isn't: a reviewer reasoning backwards from the diff, without the author's assumptions and without hours of accumulated context clogging its attention, is smarter about that diff than the author is. I like that he shipped that finding as-is instead of sanding it to fit the old post.

What stayed dead through both posts is the specific thing I'd built. A classifier in front of every turn, paying a serial model call to answer a question the model was about to answer anyway as part of doing the work, then handing the specialist a summary instead of the conversation.

so I deleted it

The entire orchestration layer collapsed into this. I'm on the Vercel AI SDK:

const tools = {
  ask_user: askUserTool,
  draw_diagram: createDrawDiagramTool(log, themes[themeName]),
};

const result = streamText({
  model: resolved.model,
  instructions: buildSystemPrompt(),
  messages: [{ role: "user", content: buildCanvasContext(diagrams) }, ...modelMessages],
  tools,
  stopWhen: isStepCount(6),
});

That's it. That's the whole thing that five agents and a progress-event system used to do.

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.