As an agent workflow grows, teams often introduce a router, a supervisor, or specialist agents. These names describe different coordination patterns. The right choice depends on where decisions belong, how much context each component needs, and which actions must be kept behind a permission boundary.

Router: choose the path

A router classifies an incoming request and sends it to one of several destinations. It works well when the routes are understandable and mostly independent: billing questions to billing support, technical questions to technical support, and appointment requests to a booking flow.

Keep the router narrow. Give it the minimum context needed to classify the request, define an explicit fallback, and measure misroutes. A router should not also own every tool call or maintain a hidden business policy that the destinations cannot inspect.

Supervisor: coordinate the work

A supervisor manages a sequence or plan across specialists. It may ask one component to retrieve information, another to draft an answer, and a third to validate the result. This can be useful when the steps are dependent and a shared task state matters.

The risk is that the supervisor becomes an unrestricted administrator. Define which specialists it may call, what evidence each result must include, how conflicts are resolved, and which transitions require approval. A plan is not authority; each consequential action still needs server-side validation.

Specialists: own bounded capabilities

A specialist should have a clear responsibility and a small toolset. A CRM specialist may look up an account or prepare a draft update. A knowledge specialist may retrieve approved policy. A scheduling specialist may propose available times. Separate ownership makes testing and access review easier.

• Give each specialist a concise input and output contract.
• Return citations, confidence signals, or validation results where useful.
• Prevent a specialist from calling tools outside its purpose.
• Make failure and escalation states part of the contract.

Choose the simplest pattern that fits

Use a router when the request needs one clear destination. Use a supervisor when several dependent steps must be coordinated. Use specialists when different responsibilities require different data, tools, or owners. Use a single agent when one bounded loop can do the work more reliably.

Many systems can start with ordinary application code around one model call. Add routing or orchestration only when it fixes a demonstrated problem such as context overload, permission separation, or independent evaluation. More agents do not automatically produce better answers.

Design handoffs as interfaces

A handoff should include the task objective, relevant user context, source evidence, completed work, unresolved questions, and allowed next actions. Avoid passing an entire conversation when a concise structured state is safer and easier to test. If agents are separately owned, define identity, authentication, capabilities, and task status explicitly; the A2A and MCP comparison provides useful context.

Test the boundaries

Test misclassification, missing context, contradictory results, duplicate calls, timeouts, prompt injection in retrieved data, and an agent attempting an action outside its authority. Review traces by step so a final answer does not hide a failed or unauthorised intermediate action.

A good orchestration design feels less like a collection of personalities and more like a set of accountable services. Each component has a reason to exist, a measurable contract, and a safe path when it cannot complete the task.