Every agent project starts with a single agent. It performs well, the team adds a capability, then another, and at some point the quality drops without anyone having changed anything. The instructions have grown to a page and a half, the agent has twenty tools available and it has started choosing the wrong one often.
That is the point where multi-agent architecture stops being sophistication and becomes necessity. The supervisor pattern is the most predictable way to organize it, and this text explains how it works, what it costs and when not to use it.
Why a single agent degrades
The degradation has two causes, and both are mechanical, not mysterious.
The first is competition for attention inside the instructions. Every new rule fights the earlier ones for space. A prompt that describes sales, finance and support at the same time forces the model to decide, on every message, which of the three roles to take on, before deciding what to answer.
The second is noise in the tool catalog. Choosing between three tools is easy. Between twenty, with similar names and overlapping descriptions, the error rate climbs fast. And choosing the wrong tool is expensive: it produces the wrong call, a useless answer and another attempt.
What the supervisor pattern is
In the supervisor pattern there is an agent that does not do the work. It reads the request, decides who should handle it and routes it. The specialists do the actual work, each with its own short instructions and its own small set of tools, and hand back to the supervisor, which decides whether the answer is complete or a step is missing.
Three properties follow from that design, and they are what justifies the cost:
- Each specialist stays simple. Short instructions, few tools, a clear scope. It is the condition for quality to stop falling as the system grows.
- The routing decision lives in one place. When the routing gets it wrong, there is a single point to fix, instead of a rule spread across five prompts.
- Adding capability does not disturb what already works. A new specialist comes in without altering the others' instructions, which is exactly what does not happen with a single agent.
The four topologies, and when to use each
| Topology | How it works | When it is the right choice |
|---|---|---|
| Single agent | One agent, one set of instructions, one set of tools. | A narrow, stable scope. As long as quality does not fall, it is the right architecture and the cheapest to operate. |
| Chain | Fixed steps in order: extract, validate, record. | The process is deterministic and the order never changes. You do not need a model deciding the path. |
| Supervisor | A router decides which specialist handles each request. | Distinct domains with a clear boundary (sales, finance, support). It is the most common case in an operation. |
| Network | Agents call one another, with no center. | Exploratory problems with no predictable path. Flexible and hard to audit: rarely the right design for a business process. |
If your process has a fixed order, you do not need a supervisor: you need a chain. Putting a model in charge of deciding what has already been decided is paying for latency and variability and getting nothing back.
How routing works in practice
The supervisor decides based on three inputs: the current message, the conversation history and the description of each specialist. The third is the one teams most neglect and the one that most affects the outcome.
A specialist description is not a label, it is a decision criterion. "Finance agent" does not tell the supervisor whether a duplicate invoice request belongs to it or to support. "Handles collections, duplicate invoices, renegotiation and payment status; does not handle contract cancellation" does. The part that starts with "does not handle" usually fixes more misrouting than the affirmative part.
Two precautions that prevent most routing problems:
- Boundaries that do not overlap. If two specialists can legitimately serve the same request, routing becomes unstable and the same customer gets different treatment on different days.
- A path for what does not fit. With no explicit fallback destination, the supervisor picks the least wrong specialist and the answer comes out confident and out of scope. A path to a human beats a guess.
What breaks in production
Multiplied cost
Every hop between supervisor and specialist is at least one more model call, carrying context. A request that the single agent resolved in one call can consume three or four. The gain in quality usually makes up for it, but it has to be measured, not assumed. One practical adjustment: the supervisor rarely needs the most expensive model, because its job is to classify, not to write.
Context lost in the handoff
The specialist receives the request, but does not always receive what was said before. The classic symptom is the customer who has to repeat information they just gave when the subject changes. Explicitly defining what crosses the boundary (full history, a summary, or only the current request) is an architecture decision, not an implementation detail.
Loops between agents
The supervisor sends it to finance, which decides the case belongs to support and hands it back, and the supervisor sends it again. With no hop limit and no record of where the request has already been, the loop only shows up on the end-of-month invoice.
An error with no owner
When the answer comes out wrong, the question is where. Bad routing, a specialist with poor instructions, a tool that returned stale data. Without a per-execution trail recording each hop's decision, debugging becomes trial and error against a system that changes behavior every run.
What to measure from day one
- Routing accuracy. The percentage of requests that went to the right specialist on the first try. It is the metric that tells you whether the problem is the supervisor or the specialists.
- Hops per request. The average reveals loops and unstable routing before the cost draws attention.
- Cost per resolved request, not cost per call. A cheap call that resolves nothing is the most expensive of all.
- Handoffs to a human, broken down by reason: out of scope, low confidence or technical failure. The three call for different fixes.
When not to use multi-agent
Worth stating plainly, because the architecture became fashionable and its cost is real. Stay with a single agent when:
- The scope is narrow and the quality is stable. There is no prize for complexity.
- The tasks share almost all of their context. Splitting into specialists only recreates the handoff as a new problem.
- The process has a fixed order. That is a chain, and a chain is cheaper and more predictable.
- You are not measuring anything yet. Without observability, multi-agent is not more capable: it is harder to debug.
How this shows up at Runflow
Runflow's TypeScript SDK brings the supervisor pattern as a primitive, alongside typed tools, memory with automatic summarization and Agentic RAG, all defined in code versioned in your own Git. In the Conversation Hub, it is the supervisor that orchestrates sales, finance and support specialists by context, in the same thread where the human agent works.
What sustains this architecture in production is not the routing, it is the record: every execution, decision and tool call is stored and reproducible. That is what lets you answer where the request went wrong, instead of guessing.
