Supervisor agents: coordinating specialist agents

A user asks for a comparison of three suppliers, including current prices and the total cost of an order. Research can find the supplier information. A calculation tool can produce the totals. Someone still needs to notice missing prices, keep quantities consistent, and turn the results into one answer.

The supervisor-worker pattern gives a coordinating agent that responsibility. It gives specialists specific tasks, checks their results, and decides whether to do more work or answer the user. Workers have their own instructions and tools; the supervisor owns the overall request.

TL;DR Use a supervisor when specialist results need ongoing coordination. Give workers clear tasks and return useful evidence, not entire transcripts by default. Independent work can run in parallel. Measure coordinator and worker costs separately, and stop repeated delegation when it is no longer making progress.

What the supervisor coordinates

A supervisor is useful when splitting responsibilities makes the task easier to handle. A research worker might search supplier documentation, while a calculation worker uses validated arithmetic tools. The coordinator decides what information is missing and how the results fit together.

This separation can keep irrelevant tool details out of the coordinator's context. It does not happen automatically: the worker's return contract determines what the supervisor sees. A concise answer without its source or uncertainty can be just as unhelpful as an oversized transcript.

LangChain's subagent pattern exposes specialist agents as tools to a main agent. The specialists return results to the caller rather than taking over the conversation.

A worker does not need to be an agent if a normal function will do. Fixed arithmetic belongs in a calculator. Introduce a specialist agent when the subtask needs its own decisions, context, or tool sequence.

Follow a supplier comparison

The supervisor first checks the user's quantity, currency, and delivery requirements. Without those inputs, comparing headline prices may produce a misleading recommendation.

It can then ask a research worker for each supplier's price, terms, source link, and observation date. If a price is unavailable, the worker should say so. The supervisor should not turn an estimate into a quoted price just to complete the table.

Once the relevant inputs are available, calculation can proceed. The output should retain the assumptions: unit price, quantity, shipping, and any taxes included. The supervisor combines those results and identifies what remains uncertain.

These contracts matter more than the number of workers. Two specialists with clear responsibilities can be useful. Ten vague roles can leave the coordinator repeatedly guessing who should do the work.

Calling specialists as tools

A current LangChain implementation can wrap a specialist in a tool. The example below assumes a configured model and a web_search tool whose access controls and error behavior are already implemented.

from langchain.agents import create_agent
from langchain.tools import tool
 
researcher = create_agent(
    model=model,
    tools=[web_search],
    system_prompt=(
        "Research supplier information. Return source links, "
        "observed prices, and any missing or uncertain details."
    ),
)
 
@tool
def research_supplier(task: str) -> str | list:
    """Research a supplier and return sourced findings."""
    result = researcher.invoke({
        "messages": [{"role": "user", "content": task}],
    })
    return result["messages"][-1].content
 
supervisor = create_agent(
    model=model,
    tools=[research_supplier],
    system_prompt=(
        "Coordinate supplier research. Ask for missing requirements. "
        "Use sourced findings and identify gaps before recommending a supplier."
    ),
)

Adapted from LangChain, Subagents. This shows one worker integration, not a complete purchasing application. Calculation, approval, persistence, and execution limits need their own implementation.

The call passes an explicit task to a fresh researcher invocation. It does not automatically forward the supervisor's entire conversation. If a worker needs a previously confirmed constraint, the caller must pass it or provide an authorized way to retrieve it.

Limit the coordinator's tools to the responsibilities it should have. That reduces what it can execute, but it does not prevent the model from writing an unsupported answer. Validate required outputs and enforce sensitive actions in application code. A prompt saying "only coordinate" is not a runtime restriction.

Sequential and parallel work

Supplier lookups may run in parallel when they do not depend on one another. Calculating a total must wait for the relevant prices. Checking a finished comparison must wait for the comparison itself.

A supervisor can support either execution order. The names supervisor and orchestrator are not a universal distinction between sequential and parallel systems. Frameworks use them differently. Anthropic's orchestrator-worker pattern emphasizes breaking a task into subtasks and synthesizing results; the supervisor framing emphasizes continuing coordination and conversation ownership.

Parallel execution can reduce waiting time. It does not remove the workers' token costs, and it does not inherently sacrifice traceability. Give every worker run a parent request identifier and retain the inputs, outputs, and timing needed to reconstruct the request.

The orchestrator-worker article examines decomposition and parallel execution in more detail. For either design, dependent steps must wait for the information they need.

When coordination gets stuck

Suppose the research worker cannot find a supplier's price. The supervisor asks again with the same task, receives the same missing result, and asks again. The failure may be a missing fallback policy rather than a bad worker.

Give the coordinator a way to handle incomplete work: ask the user, report an unavailable comparison, or stop at a budget boundary. Make tool errors distinguishable from valid negative findings. "Supplier does not publish a price" and "search service timed out" call for different next steps.

LangGraph provides an execution step limit through recursion_limit. Set limits for the version and runtime you use, including child-agent runs. Reaching a limit should produce a clear incomplete status. Inspect why the run needed more steps before deciding whether to adjust the limit.

Do not assume every loop is a prompt bug. Missing data, an unavailable service, conflicting worker outputs, or a lost completion signal can produce repeated delegation. Compare the requested task and returned result at each cycle to identify which one occurred.

Measure the added work

A delegation can include several coordinator turns and several worker turns. The amount of context in each call also differs. Two model calls do not necessarily cost twice as much as one, and a worker call is not necessarily one model turn.

Track coordinator usage, worker usage, tool costs, retries, and total elapsed time. Also track task completion and the accuracy of the final comparison. Shortening coordinator prompts is not a success if workers repeatedly miss constraints and have to start again.

Start with one representative request. Inspect whether each delegation provided information the supervisor needed, whether results preserved their sources, and whether the coordinator recognized when to stop. Expand the worker set only when an additional responsibility has a clear input and output.

If a single agent with tools already performs the supplier comparison reliably, keep it. If the specialist should ask the user follow-up questions directly, a handoff may fit better. The agent-pattern overview compares these choices without tying them to a fixed team size.

Sources

• LangChain: Subagents
• LangChain: Graph API and recursion limits
• Anthropic: Building effective agents