Multi-agent supervisor

When the task splits into distinct skills with different tools and prompts, when one agent's tool list or context gets too large to choose well, or when parts can run in parallel. The costs are more tokens, more latency and harder debugging, so start with one agent and split when you measure a problem.

A supervisor agent reads the request and decides which specialist to call next: a search agent with web tools, a data agent with SQL, and a writer agent. Each specialist is its own graph or create_agent with focused tools and prompt. The supervisor receives their results, decides whether more work is needed, and ends when the writer produces the final report.

Specialists return concise summaries or structured results rather than full transcripts, shared state holds only what others need, large artifacts are stored outside and referenced, and each agent keeps its own private message history.

Evaluate end-to-end task success and cost, plus each agent separately on its own subtasks, check routing decisions (did the supervisor pick the right agent), count handoffs and loops, and compare against a single-agent baseline.

In a supervisor pattern a central agent decides who acts next, and specialists report back to it: predictable and easy to trace. In a network or swarm, agents hand off directly to each other: more flexible and fewer hops, but harder to control and debug.

Through the graph state: usually a shared list of messages, or a typed state with fields per agent. Handoffs are tool calls or Command objects that update the state and name the next node. Subgraphs can keep private state and return only a result.

It is an LLM with a routing prompt and either structured output naming the next agent or handoff tools (one per agent); its decision is routed with conditional edges or Command(goto=...).

A tool or node returns Command(goto='agent_name', update={...}), moving control to another agent and passing state updates, which is how swarm and supervisor patterns transfer work.

Cap handoffs and the recursion limit, track visited agents in state, require the supervisor to state why another round is needed, and route to a finishing node after a maximum number of steps.

When agents are peers and the right next expert depends on the conversation, such as customer service routing between billing and tech support. The active agent hands off directly, avoiding an extra supervisor call each turn.

Each agent is its own node or subgraph with its own model: a strong reasoning model for the supervisor or planner, cheaper fast models for simple specialists, balancing cost and quality.

Each agent can be a compiled subgraph with its own state schema, added as a node in the parent graph; state keys shared with the parent pass through, and private keys stay inside, keeping agents modular and testable.

The supervisor can fan out with Send to several agents at once when subtasks are independent, then gather results with a reducer before deciding the next step.

Return a list of Send objects from a conditional edge, one per item, each naming the worker node and the state to pass it. The workers run in parallel and write into a state key with a reducer, such as list concatenation, and a later node combines the results.

Sourced from Docs by LangChain (MCP)

It returns a Command with goto set to the target node, an update, and graph set to Command.PARENT, which navigates to the closest parent graph. Any state key updated this way that both graphs share must have a reducer defined in the parent state.

Sourced from Docs by LangChain (MCP)

LangSmith shows nested runs per agent, with model and tool calls, so you can see which agent made which decision, its tokens and latency, and where errors started.

Supervisors managing teams of agents, which themselves report to a top-level supervisor, useful for very large systems such as a research team and a writing team coordinated by a project lead.

Use shared state keys for the current task, a store for long-term facts any agent can read, and avoid letting every agent write everywhere; define which agent owns which data.

Return an error result to the supervisor, which can retry, choose another agent, or report partial results; protect with timeouts and limits per agent.

More model calls and tokens, more latency from coordination, harder debugging and evaluation, and possible inconsistency between agents. They pay off only when specialisation or parallelism improves outcomes.

Give each agent a narrow role, clear inputs and outputs, only the tools it needs, and instructions on what to return to the supervisor, so its behaviour is predictable and testable.

It provides a prebuilt create_supervisor that wires agents with handoff tools and the supervisor loop, which you can customise or replace with your own graph as needs grow.

Deploy it as one LangGraph application with persistence, or deploy agents as separate services communicating via APIs or protocols such as A2A when teams own them independently.

Pass only what the next agent needs, typically the last AI message and a ToolMessage confirming the transfer, rather than the full history. Subgraph handoffs need deliberate context engineering, otherwise agents receive malformed or bloated histories.

Sourced from Docs by LangChain (MCP)

For most handoff cases, because it is simpler: one agent changes its prompt and tools based on state. Use multiple agent subgraphs only when an agent needs a bespoke implementation, such as its own graph with reflection or retrieval steps.

Sourced from Docs by LangChain (MCP)

Pass a timeout on the Send for that worker, which overrides the target node's static timeout for that dispatch only. Without one, the node's timeout set at add_node time applies, so you can keep a default and tighten it per call.

Sourced from Docs by LangChain (MCP)

Wrap the deployment in a RemoteGraph and add it as a subgraph node. RemoteGraph exposes the same interface as a compiled graph, so the parent can invoke and stream it; use UUIDs as thread IDs if the parent has a checkpointer.

Sourced from Docs by LangChain (MCP)

Agent-to-agent communication standard for agents built by different teams or vendors to discover each other's capabilities and exchange tasks and results over HTTP.

Start with one agent, split only where prompts or tools become too large or responsibilities clearly differ, and confirm each split improves evaluation metrics.

Stream which agent is working and short status updates, then the final combined answer, so users understand delays and trust the result.

Make one agent (often the supervisor or writer) responsible for the final answer, give it all specialist results, and instruct it to reconcile or flag disagreements.

A classify node decides which sources apply, a routing function returns one Send per chosen source node so they run in parallel, and each source node writes its findings for a synthesize node that combines them into one answer.

Sourced from Docs by LangChain (MCP)

1. ARoute work to the right specialist and decide when it is doneCorrect answer
2. BStore vectors
3. CFine-tune the specialists
4. DRun every tool itself

Why: It plans and delegates; the specialists do the work with their own tools.

1. ANothing
2. BConcise summaries or structured resultsCorrect answer
3. CFull transcripts
4. DRaw HTML pages

Why: Keeps shared context small.

1. ARestart the graph
2. BEdit the system prompt
3. CReturn Command(goto=...)Correct answer
4. DCall the other agent's API directly only

Why: It moves control with state updates.

1. ANothing
2. BA random baseline only
3. CHuman typing speed
4. DA single-agent baselineCorrect answer

Why: Multi-agent must earn its cost.

1. AHigher token cost and latencyCorrect answer
2. BThey cannot be traced
3. CThey require fine-tuning
4. DThey cannot use tools

Why: Extra coordination messages and model calls add cost and time.

1. AHandoff caps and recursion limitsCorrect answer
2. BMore agents
3. CHigher temperature
4. DLonger prompts

Why: Route to finish after a limit.

1. AWhen there is one agent
2. BWhen peers hand off directly by conversationCorrect answer
3. CAlways
4. DNever

Why: Avoids an extra supervisor call.

1. AThe supervisor fans out with SendCorrect answer
2. BThey cannot
3. CBy using one model
4. DThrough email

Why: Gather results with a reducer.

1. AThey remove tools
2. BPrivate state stays inside each subgraphCorrect answer
3. CThey share every key
4. DThey disable persistence

Why: Shared keys pass through.

1. AThe logger
2. BThe supervisor or plannerCorrect answer
3. CEvery specialist equally
4. DNone

Why: Routing decisions matter most.

1. AA random answer
2. BAn error result the supervisor can handleCorrect answer
3. CNothing
4. DA crash for the whole graph

Why: Supervisor retries or reroutes.

1. ASendCorrect answer
2. Binterrupt
3. Cadd_edge
4. DMemorySaver

Why: Each Send dispatches one node invocation with its own state.

Sourced from Docs by LangChain (MCP)

1. ANavigate to the closest parent graphCorrect answer
2. BRestart the current graph
3. CEnd the run
4. DCall a remote graph

Why: Subgraph agents use it to hand off.

Sourced from Docs by LangChain (MCP)

1. AThrough the vector store
2. BBy editing the source code
3. CWith a handoff tool or a Command naming the next nodeCorrect answer
4. DBy restarting the graph

Why: A handoff updates the state and routes execution to the target agent's node.

1. AOne agent only
2. BNo routing
3. CA database
4. DSupervisors of supervisorsCorrect answer

Why: It organises teams within teams.

1. Abuild_swarm only
2. Bcreate_supervisorCorrect answer
3. Ccreate_router
4. Dmake_team

Why: From langgraph-supervisor.

1. AEmpty
2. BNarrow with clear inputs and outputsCorrect answer
3. CAs broad as possible
4. DIdentical for all

Why: Predictable behaviour.

1. ALess debugging
2. BNo evaluation needed
3. CMore calls, tokens and latencyCorrect answer
4. DFewer model calls

Why: Coordination overhead.

1. ALogs
2. BA storeCorrect answer
3. CEach agent's prompt
4. DThe UI

Why: Readable across threads.

1. ALangSmithCorrect answer
2. Bnpm
3. CJest
4. DBabel

Why: Find where errors start.

1. ASMTP
2. BFTP
3. CSSH
4. DA2ACorrect answer

Why: Agent-to-agent tasks over HTTP.

1. AThe user
2. BNobody
3. COne agent that reconciles resultsCorrect answer
4. DEvery agent separately

Why: Avoids conflicting outputs.

1. AA larger model
2. BNo special handling
3. CA reducer in the parent stateCorrect answer
4. DA new thread

Why: Concurrent updates must be merged.

Sourced from Docs by LangChain (MCP)

1. AThe thread ID
2. BThe SendCorrect answer
3. CThe checkpointer
4. DThe system prompt

Why: It overrides the node's default timeout for that call.

Sourced from Docs by LangChain (MCP)

1. AStateSchema
2. BRemoteGraphCorrect answer
3. CSend
4. DToolMessage

Why: It exposes the same interface as a compiled graph.

Sourced from Docs by LangChain (MCP)

1. ANo state at all
2. BA single agent with middlewareCorrect answer
3. COne subgraph per tool
4. DA new graph per user

Why: It is simpler than multiple agent subgraphs.

Sourced from Docs by LangChain (MCP)

1. ANever
2. BWhen it is fast
3. CWhen prompts or tools grow too largeCorrect answer
4. DOn day one always

Why: Confirm with evaluations.

1. AOnly show errors
2. BStream which agent is workingCorrect answer
3. CHide everything
4. DShow raw logs

Why: Builds trust during delays.

1. APrompt length
2. BWhether the supervisor picked the right agentCorrect answer
3. CNetwork speed
4. DToken price

Why: A key multi-agent metric.

1. AAs separate services via APIs or A2ACorrect answer
2. BOnly in one file
3. COnly locally
4. DNever

Why: Independent ownership.

1. AEmailed
2. BStored outside and referencedCorrect answer
3. CCopied into every prompt
4. DDeleted

Why: References save a lot of tokens.

1. AThe API keys
2. BThe last AI message and a transfer ToolMessageCorrect answer
3. CThe entire raw history
4. DNothing

Why: Lean context avoids malformed or bloated histories.

Sourced from Docs by LangChain (MCP)