Clarion Street

Topology as the New Dial: Supervisors, Swarms, and Who Holds the State

·8 min read

Yesterday I argued that the agent-framework market had consolidated into a spectrum, and that the decision was which primitive you need, not which framework. That piece stopped one step short. Once you have decided to run more than one agent at all, there is a second decision underneath the first, and it has nothing to do with frameworks. It is about who holds control and who makes the next call.

That decision has a clean shape. On one end, a supervisor owns the plan and makes every routing decision itself, choosing which specialist to invoke next. On the other end, there is no center. Agents hand control directly to each other, and the system remembers which agent was last active. The field spent two years arguing over frameworks and then consolidated them. The next argument is over topology, and it is starting to get a research vocabulary instead of a brand debate.

The two poles

The supervisor pattern puts one agent in charge. LangChain’s langgraph-supervisor states the arrangement plainly: the supervisor controls all communication flow and task delegation, deciding which agent to invoke based on the current context. Anthropic calls its own version orchestrator-worker. A lead agent spawns subagents and decides the next move from what they return.

The swarm pattern removes the center. LangChain’s langgraph-swarm defines a swarm as agents that dynamically hand off control to one another based on their specializations, and the system remembers which agent was last active so the conversation resumes with that agent. OpenAI’s Agents SDK implements the handoff literally as a tool. transfer_to_refund_agent is a tool call the model can make, and when it fires, the receiving agent takes over the conversation and sees the entire previous history. Control moves sideways, and it does not come back.

The honest version of the trade is narrower than the blog posts make it sound. Both LangChain libraries default to passing the full message history along, and both make that configurable. langgraph-supervisor lets you choose between full_history and last_message for what comes back from a worker. langgraph-swarm passes the full history by default and lets you write your own handoff tools. Token cost is not something the topology decides for you. It is a dial you set. What the topology does decide is where the routing decisions live. A supervisor puts every “what happens next” in one agent you can watch. A swarm scatters those decisions across the agents themselves.

What it costs

Anthropic published the cleanest numbers on the multi-agent tax, and they come from its own orchestrator-worker research system. Its agents use about 4x the tokens of a chat interaction, and its multi-agent setup uses about 15x. Token usage alone explained 80% of the variance in BrowseComp performance, which is the number I keep coming back to. Multi-agent systems mostly work because they are a structured reason to spend more tokens. That is fine when the task’s value covers the bill.

The same post found that a multi-agent system with Opus 4 as the lead and Sonnet 4 subagents beat single-agent Opus 4 by 90.2% on an internal research eval. The payoff is real, and it is real specifically for work that parallelizes. Anthropic’s own guidance is that multi-agent earns its keep for heavy parallelization, information that exceeds a single context window, and interfacing with numerous complex tools. A single agent with good tools is the honest default.

I would sit with that guidance longer than most write-ups do. Multi-agent demos well. A supervisor or a swarm is a structured excuse to spend more tokens, and the structure only pays when the task’s value covers the bill. Most workloads do not clear that bar.

One thing that post does not do is compare a supervisor to a swarm. Anthropic did not run that experiment in public. The 15x is multi-agent against chat, and the 4x is a single agent against chat. If someone quotes a token premium to argue that swarms are cheaper than supervisors, check where the number came from. The figure that exists measures something adjacent.

Topology as an optimization target

While the frameworks argued, a cluster of February 2026 papers started treating the topology itself as the thing you optimize, rather than a brand you pick once. The shared premise is that model capability has converged enough that arrangement now matters more than model choice.

AdaptOrch is the most direct version. It formalizes something it calls a Performance Convergence Scaling Law and reports a 12 to 23 percent improvement from choosing the right topology over a static one, even with identical underlying models. That is a measured delta tied to arrangement, not to model quality.

Symphony-Coord drops static roles and centralized controllers entirely. It casts agent selection as an online multi-armed bandit, a LinUCB selector, with decentralized execution and sublinear regret bounds. The routing specializations, in the paper’s phrase, emerge from interaction and feedback rather than being assigned up front.

AOrchestra takes a third route. It models any agent as a tuple of instruction, context, tools, and model, then creates specialized sub-agents on demand. Against the strongest baselines on GAIA, SWE-Bench, and Terminal-Bench, it reports a 16.28 percent relative improvement paired with Gemini-3-Flash.

None of these are independently replicated, and the numbers are self-reported. I am treating them as direction, not precision. The direction is what matters. Topology is becoming a first-class optimization target, and the choice is starting to look like a search problem with measured deltas rather than a taste question between two logos.

The supervisor library steps back

There is one concrete datapoint that gives this argument a news hook, and it is subtler than the version going around. LangChain now opens the langgraph-supervisor README with a note steering most users away from the library. Build the supervisor pattern directly via tools, it says. The tool-calling approach gives you more control over context engineering and is the recommended pattern in the LangChain multi-agent guide. LangChain is making the library compatible with LangChain 1.0 so existing code keeps working. langgraph-swarm carries no such note.

I read this as the same consolidation, seen from the framework side. The supervisor pattern is not dying. Anthropic is running it in production and winning evals with it. What is thinning is the need for a dedicated library to express the centralized pattern. When the recommended way to build a supervisor is a tool-calling agent plus your own delegation logic, the framework and the primitive have merged. Yesterday’s spectrum post reached for that from the framework side, and the research cluster reaches for it from the topology side.

The self-hosted trade

For a self-hosted operator, the choice still matters, just not for the reasons the marketing gives you. The two LangChain libraries share the same LangGraph runtime, so both get checkpoints, tracing, and human-in-the-loop if you wire them in. A swarm is not inherently harder to observe, and a supervisor is not inherently more expensive. Those are configuration choices, not properties of the topology.

What the topology does change is where the routing decisions happen, and that is the part worth caring about when an auditor shows up. A supervisor concentrates every “why did we go there” decision in one agent, which makes a run easier to step through and reason about. A swarm spreads those decisions across the agents themselves, so reconstructing the chain of control takes more work. The traces are not missing. There are just more of them to stitch together.

I wrote earlier that a trace is not the same thing as an audit trail. This is where that distinction bites. The next part is my judgment, not a measured result, and it rests on one assumption: a single place where decisions get made is easier for a human to audit than many places. If that assumption holds for you, and you have an auditor somewhere downstream, the supervisor’s legibility is usually worth whatever tokens a different history-handling setting might save. If it does not hold, decide on cost and reliability, which the topology barely changes anyway.

The word decentralized deserves a caveat. A swarm is still developer topology inside one runtime. It is not a peer-to-peer network of independent agents, and it does not solve discovery, identity, or cross-runtime coordination. Those problems remain MCP and A2A territory, which this site has covered at length. What a swarm gives you is a control flow with no center inside a single system, not a federation.

My read is that the honest default stays single-agent, and the topology question only matters once you have crossed into multi-agent for a real reason. When you have, the decision is simple to state and harder to live with. A supervisor gives you one place where every routing decision is made. A swarm gives you none. You are choosing which is easier to live with, and for a self-hoster with an auditor somewhere downstream, the place where the decisions are written down is usually the one worth keeping.

Sources

  1. How we built our multi-agent research system — Anthropic Engineering
  2. langgraph-supervisor — LangChain
  3. langgraph-swarm — LangChain
  4. Handoffs — OpenAI Agents SDK
  5. AdaptOrch: Task-Adaptive Multi-Agent Orchestration in the Era of LLM Performance Convergence — arXiv
  6. Symphony-Coord: Adaptive Routing for Multi-Agent LLM Systems — arXiv
  7. AOrchestra: Automating Sub-Agent Creation for Agentic Orchestration — arXiv
  8. Supervisor vs Swarm vs Handoffs: Multi-Agent Orchestration Patterns in 2026 — dreaming.press (AI-authored, human-editor-reviewed)