Orchestrator: coordinator and specialists

Orchestrator chooses suitable specialists and can continue after their results. Delegation depends on the current request.

These steps refer to features identified in the application code. This material has not been validated on a live instance; check the documentation and the options in your version.

How it works, step by step

The delegation contract

Tell the coordinator what each worker handles and what input it needs. A worker returns facts, sources and limitations rather than instructions to redefine roles. For one classification and a single handoff, Router may suffice. For independent simultaneous perspectives, compare Parallel.

Detailed lab

A complete delegation example

Coordinator instruction: “Choose a worker for the missing information. Do not request data outside its role. Combine facts and flag contradictions.” The product worker consults the catalog; the delivery worker consults shipping information.

“What part does LX-240 use and when does it arrive?” yields two pieces of evidence: P-12 in the catalog and estimated 2–3 business days after dispatch. The coordinator preserves the distinction between compatibility and an estimate. If delivery evidence is missing, answer the first part and explain the second limitation without inventing a promise.

The visual map

Follow the solid arrows for the main flow. Dashed blue arrows supply data or context; dashed pink arrows show feedback or returning results. Colors and shapes distinguish models, stores, decisions and outputs. Workers return to the orchestrator, which decides whether to delegate again or finish. On smaller screens, scroll horizontally to follow the entire diagram.

A complete example

“Is it compatible and when does it arrive?” needs product expertise and then delivery information. Results return to the coordinator for the final response.

orchestrator: LunaCoordinator
worker_1: ProductSpecialist
worker_2: DeliverySpecialist

Try it yourself

1. Create an orchestrator and two workers with different responsibilities.
2. Record the input, source and expected outcome before running the experiment. Use only the fictional data in the example.
3. Follow the diagram stages. At every step record what information is received and produced; do not confuse intermediate output with the final outcome.
4. Repeat after removing necessary information or making the input ambiguous. Check whether the system clarifies, stops or invents an answer.
5. Compare with the explained solution. Keep the configuration, date, result and an explanation for differences. Change one thing and retest.

An explained solution

The coordinator combines confirmed information and labels delivery estimates as estimates. A successful exercise lets you show the connection between input, stages and outcome. When information is missing, a cautious answer is more useful than invented details. Compare more than style: check conditions, sources and operations too.

When it helps and what can go wrong

Dynamic delegation does not automatically mean parallel execution. Choose this approach when it improves a measured need. Keep a simple baseline and compare outcomes using identical inputs. One successful example does not establish reliability in every situation.

Check your understanding

Is multi-agent an eighth template?

No. It is an architectural category that can use several existing templates.

Who executes a call proposed by the model?

The application or host service after validation. The model does not automatically gain unrestricted access.

What outcome should this exercise produce?

The coordinator combines confirmed information and labels delivery estimates as estimates.

Words to remember

• Nod: A stage in an execution graph.
• Tool calling: A structured request to use an external capability.
• Idempotency: Controlled repetition without duplicating an effect.

Sources and your next step

• LangGraph — Workflows and agents

To prepare: W04 — Sequential: a team working in order