Walk through the LangGraph supervisor pattern for multi-agent orchestration

Short answer·Hard·4.0 · 0·~3 min·Asked atAda OpenAI Tata Digital

Attempt it

Describe the LangGraph supervisor pattern end to end: the graph topology, how routing decisions are made, how state flows between supervisor and workers, and why teams choose this pattern over AutoGen GroupChat or a CrewAI hierarchical crew.

Free · 2 AI evals / day

The LangGraph supervisor pattern wires multi-agent orchestration as an explicit star-shaped graph. One central node, the supervisor, decides who works next. Several worker nodes, researcher, writer, critic, code executor, whatever your task needs, do the actual work. Edges connect the supervisor to each worker, and every worker has a return edge back to the supervisor. Mechanically: the supervisor is an LLM call whose prompt lists the available workers and instructs the model to output the name of the next worker to invoke (or `FINISH` to stop). A conditional edge after the supervisor reads that output and dispatches to the named worker. Each worker reads the shared state, does its job, writes updates back to state through a reducer (for example, appending its output to a `messages` list), and an unconditional edge sends control back to the supervisor for the next routing decision. The loop continues until the supervisor outputs `FINISH`, at which point a terminal edge routes to `END`. State is shared. Every node sees and updates the same state object, and the checkpointer persists state per thread id. So multi-turn conversations, human in the loop pauses, and crash recovery all work out of the box. The pattern is popular because the control flow is visible in the graph. You can see the supervisor, the workers, and the edges in code and in LangGraph's visualizer. AutoGen's GroupChat hides the same logic inside a chat manager; CrewAI hides it inside the manager LLM.

**Topology.** One supervisor node and N worker nodes. Edges: supervisor → conditional_edge → each worker; each worker → supervisor (unconditional); supervisor → END (conditional, fires when supervisor returns FINISH). **Supervisor.** An LLM call. Its system prompt enumerates the available workers (e.g. 'researcher: finds facts; writer: drafts prose; critic: checks accuracy; FINISH: end the run') and asks the model to output the next step as a structured value. Typically a `route(next='researcher')` tool call so the output is typed and parseable. The conditional edge has a routing function that reads the supervisor's last message, extracts the `next` field, and returns the corresponding worker name (or `END` for FINISH). **Workers.** Each worker reads the shared state, performs its specialty (search, drafting, evaluation), and writes back via state-update returns. The standard reducer is `add_messages` for a chat history: each worker appends an `AIMessage` tagged with its name, and the supervisor sees the cumulative log when it next routes. Other reducers handle accumulators, set-merges, or last write wins fields. **Loop and termination.** Workers always return to the supervisor. The supervisor decides whether to continue routing or `FINISH`. A `recursion_limit` config prevents runaway loops if the supervisor gets stuck. **Persistence.** Compile with a checkpointer (`PostgresSaver`, `SqliteSaver`, etc.) and a `thread_id` per session. Now the whole conversation persists, can be resumed, supports time-travel debugging, and can pause at `interrupt_before=['supervisor']` for human in the loop approval before any routing decision. **Why this beats alternatives.** Routing is a typed value, not an implicit chat side effect. Workers are unit-testable in isolation given a state. The whole graph is visible at design time. AutoGen GroupChat embeds the routing inside a chat manager that reads message text. It works but is harder to debug.

TL;DR

A supervisor LLM node routes to one of N worker nodes via a conditional edge based on its structured output; workers update shared state and return to the supervisor; the loop terminates when the supervisor outputs

Memory aid

Easy to grasp

Picture a newsroom. The editor (supervisor) reads what is on the table and says 'researcher, dig into this' or 'writer, draft a paragraph' or 'critic, check the facts'. Each person does their bit, hands the work back to the editor, and the editor decides who is next. Eventually the editor says 'good, we publish'. The whole thing is happening on one shared whiteboard everyone can see, and somebody is taking photos of the whiteboard after each handoff so the work survives even if the building burns down. That photo log is the checkpointer.

Key concepts

LLM frameworks Agents

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

The supervisor pattern is LangGraph's canonical answer to multi-agent orchestration. It pins routing to a typed graph construct, separates the routing-decision LLM call from the worker LLM calls, and inherits LangGraph's surrounding machinery (checkpointer, reducers, human in the loop, time-travel) for free. The pattern has become the production default for agent systems that need to run unattended and survive process restarts.

This section walks the topology, the supervisor's structured-output discipline, the state and reducer story, the operational properties from the checkpointer, and the comparison with the obvious alternatives in the framework landscape.

Topology. A star, not a chain

Imagine a star graph. At the center sits the supervisor node. Around it sit N worker nodes. Researcher, writer, critic, executor, whatever the task demands. The edges are asymmetric: from the supervisor, a conditional edge dispatches to one worker per round; from each worker, an unconditional edge returns to the supervisor; a separate conditional case routes to END when the supervisor signals FINISH.

The entry point is the supervisor. The first round, the supervisor sees only the user's initial input in state and picks a starting worker. That worker runs, writes its output to state, returns to the supervisor. The supervisor now sees the original input plus the worker's output and picks the next worker (possibly the same one again, possibly a different one, possibly FINISH).

The topology matters because it is what makes the routing decision a separate, inspectable, replaceable concern. You can swap the supervisor's implementation (different LLM, different prompt, deterministic function) without touching the workers. You can add or remove workers without changing the supervisor's structure. Just update the routing schema. The shape of the graph is the shape of the system.

Supervisor. A router, not an agent

Workers and state. Reducers as the load-bearing detail

Persistence and operational properties

Comparison with AutoGen GroupChat and CrewAI Hierarchical

Production hygiene. Guardrails and instrumentation

Situations where this technique stops working.

2–4 min · Everything important, quickly.

python

from typing import Annotated, Literal
from typing_extensions import TypedDict
from langgraph.graph import StateGraph, END
from langgraph.graph.message import add_messages
from langgraph.checkpoint.postgres import PostgresSaver
from langchain_openai import ChatOpenAI
from pydantic import BaseModel

class State(TypedDict):
    messages: Annotated[list, add_messages]
    next: str

class Route(BaseModel):
    next: Literal['researcher', 'writer', 'critic', 'FINISH']

llm = ChatOpenAI(model='gpt-4o').with_structured_output(Route)

def supervisor(state: State) -> dict:
    decision = llm.invoke([
        {'role': 'system', 'content': 'Route to researcher, writer, critic, or FINISH.'},
        *state['messages'],
    ])
    return {'next': decision.next}

def researcher(state): ...   # returns {'messages': [AIMessage(...)]}
def writer(state): ...
def critic(state): ...

builder = StateGraph(State)
for name, fn in [('supervisor', supervisor), ('researcher', researcher), ('writer', writer), ('critic', critic)]:
    builder.add_node(name, fn)

builder.set_entry_point('supervisor')
for w in ['researcher', 'writer', 'critic']:
    builder.add_edge(w, 'supervisor')

builder.add_conditional_edges(
    'supervisor',
    lambda s: 'END' if s['next'] == 'FINISH' else s['next'],
    {'researcher': 'researcher', 'writer': 'writer', 'critic': 'critic', 'END': END},
)

with PostgresSaver.from_conn_string(DB_URL) as cp:
    graph = builder.compile(checkpointer=cp, interrupt_before=['supervisor'])

Real products, models, and research that use this idea.

LangChain's multi-agent supervisor tutorial uses researcher and chart-generator workers behind a supervisor LLM
Production teams deploying long-running research agents on Claude Opus 4.7 use supervisor patterns with Postgres checkpointers for crash recovery

What an interviewer would ask next. Try answering before peeking at the approach.

QHow does the supervisor pattern handle parallel worker execution?

Out of the box the conditional edge picks one next worker. For parallelism, the supervisor can emit multiple routes and the graph fans out using Send directives; reducers on shared state must then be carefully chosen (add_messages is safe; non-deterministic last write wins is not). Parallel workers re-converge at the supervisor on completion.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Letting the supervisor return free-form text instead of a structured route. The conditional edge needs a typed signal, not a string parse.

60 second bullets to scan on the way to the call.

Star-shaped topology with one supervisor and N workers
Supervisor as an LLM call producing a structured route signal

Primary sources. Browse if you want the original framing.