All articles
January 31, 2026 6 min read

The supervisor pattern: an LLM whose tools are other agents

The cleanest way to coordinate several specialised agents is a supervisor — an LLM that routes each turn to a worker agent and decides when the job is done. Here's the pattern, the routing, and the guards against infinite loops.

Written forEngineering
Multi-AgentAgentsArchitecture

When you genuinely need multiple specialised agents (and the multi-agent post argues you usually don't), the supervisor pattern is the most legible way to coordinate them. The trick is a mental reframe: the supervisor is just an agent whose 'tools' happen to be other agents.

InOrchestrator LLMassigns subtasksWorker LLMWorker LLMWorker LLMSynthesiser LLMOut
A supervisor decides which worker agent should act next, delegates to it, and reads the result — looping until it decides the task is finished.

The supervisor is a router

At each turn, the supervisor — an LLM — looks at the state of the task and decides who should act next: the researcher, the writer, the reviewer, or nobody, because the task is done. It's a routing decision, and the reliable way to get it is structured output: the supervisor returns a small object like { next: 'researcher' } or { next: 'FINISH' }, not free text you have to interpret. That structured route is what the graph uses to hand control to the chosen worker.

Structured routing, not prose
class Route(BaseModel):
    next: Literal['researcher', 'writer', 'reviewer', 'FINISH']

supervisor = model.with_structured_output(Route)
# each turn: supervisor picks the next worker (or FINISH);
# the graph routes to that worker, runs it, and returns to the supervisor.

Workers do the work; the supervisor decides

Each worker is a focused agent with its own prompt and tools (and its own context — the sub-agents post covers why that isolation matters). A worker acts, its result goes back into shared state, and control returns to the supervisor, which decides the next move. The supervisor never does the domain work itself; it only routes. That separation is what keeps the system debuggable — you can read the sequence of routing decisions and see exactly why it did what it did.

Guard against infinite loops

The failure mode of any supervisor is looping forever — researcher, writer, researcher, writer — never choosing FINISH. So you never trust the LLM alone to stop. Add hard guards: a max-iteration counter that forces termination after N steps, a clear FINISH condition the supervisor is prompted toward, and ideally a check that the loop is making progress (the same discipline as the agent-loops post). The LLM proposes when to stop; your code guarantees that it does.

A supervisor system is one agent routing to others and deciding when it's done. Make the routing structured, keep the supervisor out of the actual work, and never let the model be the only thing that can end the loop.
Building something with LLMs?
I help teams ship GenAI that’s reliable and cost-efficient.
Let’s talk