Orchestration

Multi-agent orchestration

Coordinating several specialised agents within one run — deciding which agent handles what, how work is handed between them, and how the result is assembled into a single answer.

Multi-agent orchestration is the coordination of several specialised agents inside a single run. Rather than one agent with a large prompt covering every topic, work is split across sub-agents with narrow responsibilities, and an orchestration layer decides who handles what.

Why split at all

A single agent handling billing, technical support, and account changes needs one prompt covering all three. That prompt grows, the instructions start to conflict, and behaviour becomes hard to predict. Splitting into sub-agents gives each one a narrow, testable responsibility — and lets each use a different model, different tools, and a different permission posture.

The orchestration contract

Anter's runtime enforces a specific shape:

  • The root agent never answers. It holds shared instructions and routes. Every real answer comes from a sub-agent.
  • Root instructions are merged into whichever sub-agent is active — so they always apply, even though the root never speaks on its own.
  • Where root and sub-agent instructions conflict, the sub-agent wins. Write sub-agent instructions assuming they take priority.
  • A run proceeds in steps, each step being one sub-agent's turn: one or more tool calls, a handoff, or a final answer.
  • Every run ends in exactly one final answer.

A consequence worth internalising: a root-only agent with no sub-agents cannot answer anything at all. You must define at least one sub-agent as the default.

Handoff, not broadcast

Orchestration here is not a group chat. Work moves through explicit edges — either a transfer, which moves ownership of the conversation, or a delegation, which asks for a result and keeps ownership. Which one you pick changes who the user is talking to for the rest of the conversation.

Where it goes wrong

The dominant failure mode is not a bad model — it is a badly shaped routing graph. Full meshes of transfers cause ownership thrash; unreachable specialists never get routed to even though the design validates. Both are design errors that show up at run time as correction nudges or an exhausted transfer budget.

In the Anter docs

Related terms

Last updated July 27, 2026