Coordination patterns

Pick the smallest abstraction that still captures what you need. The escalation order, from cheapest to heaviest, is roughly: tool, then task on the same agent, then a separate agent.

The same operation can sit at different levels in different systems. "Check the weather" can be:

Start with the cheapest option and escalate when the lighter abstraction stops fitting. Reasons to escalate include the result needing to be tracked outside the iteration, the work needing more iterations than its sibling work, or the parent’s context getting noisy.

Control passes from agent to agent, and one agent is active at a time. Context accumulates or is transformed as it moves along the chain.

This is the simplest and most coherent pattern: one thread of reasoning runs throughout. The trade-off is path dependency. Early decisions constrain later ones, and errors compound rather than correct. Order matters: research then plan gives a different result from plan then research. Real processes are often graphs rather than chains, which is where sequential composes with delegative.

Fixed pipeline. When the order is known at development time, a workflow calls the agents one after another and passes each output to the next agent’s input.

A fixed pipeline suits multi-step processes with clear linear dependencies that do not change between runs, steps that cannot run concurrently, and data transformation pipelines, though if the work is only data transformation, agents and models may not be needed. Avoid it when steps can run in parallel without downstream dependencies, when you might branch or short-circuit based on the results of single steps, or when the interaction between agents is collaboration rather than handing work along. The agent team tutorial shows a workflow with fixed steps that calls agents in sequence.

Handoff. When the plan is not known until the input arrives, an agent defers the work to whichever agent fits it. Choosing which agents take part is part of the planning.

An Autonomous Agent implements handoff as a capability. The agent declares the peers it can hand off to, and the runtime offers the model a handoff tool. When the model hands off, ownership of the task moves to the next agent and the first agent steps back. The durability, retries and record come from the runtime, not from agent code. The support sample in the autonomous agent playground shows a triage agent that classifies a customer request and hands off to a billing or technical specialist.

With request-based agents, a workflow reaches the same outcome by calling a planning agent that chooses the next worker. The planning agent asks the model, through a structured response, which agent best suits the request, and the workflow calls that agent. Tool calls, for example over MCP, add deterministic logic to the choice when the model’s judgment alone is not predictable enough. If the worker agents themselves decided whether to handle an input, they could not be recomposed for any other purpose. This plan-and-execute loop can be combined with any of the other patterns.

Example: A triage agent receives a customer request, decides its category and hands control to the right specialist, which then owns the interaction.

A coordinator assigns subtasks to workers. Workers run in isolated contexts, and their results come back to the coordinator for synthesis.

Context isolation is the defining feature. Each worker can go deep on its subproblem without distraction or influence from the others. Isolation also means no cross-pollination, so coherence depends on the coordinator, which must do well at both decomposition and synthesis. In competitive delegation, the coordinator gives the same task to several workers and selects the best result; at large scale, with many agents and statistical selection, this blurs into the emergent pattern.

Use delegation when a task decomposes into distinct subtasks that benefit from focused contexts, when you need independent perspectives, when parallel execution reduces latency, or when you want broad exploration with many independent attempts.

Concurrent workers. A workflow step starts several agents at once and collects their results before the next step. The workflow decides which agents are needed, and the runtime provisions them; agents do not start sub-agents of their own.

For larger work, a parent workflow starts child workflows. Each child performs a multi-step task and delivers its result to the parent as a message. The parent pauses while it waits, stores the results in its state, and moves to its next step when it has what it needs. The runtime handles the distributed state, the long-running timers and the recovery of each workflow. When the coordinator is an Autonomous Agent, the delegation capability configured for parallel workers does the same: the model picks which workers to start, and the runtime runs them concurrently and gathers their results into the coordinator’s context. See Workflows for concurrent steps.

Dynamic planning (magentic). For open-ended problems without a predetermined plan, a model creates the plan, decides the next step, evaluates the results and decides when the goal is met. Agents in this pattern often have access to tools.

Either supervisor works. With a workflow supervisor, the model influences what happens, and the workflow makes sure it happens reliably, with durable steps and retries. With an Autonomous Agent coordinator that delegates, the model picks the next worker and the runtime persists the task, retries failures and bounds the number of iterations. When the supervisor coordinates everything and agents stay small, the individual patterns matter less: to change how agents are used, you change the planning agent, a little workflow logic or the coordinator’s declaration, not the agents. The planner agent tutorial shows an Autonomous Agent coordinator that delegates to worker agents.

Example: A research coordinator delegates fact-gathering to a researcher and trend analysis to an analyst. Both work in parallel with isolated contexts, and the coordinator combines their findings into a brief.

Peer agents share context and communicate as they work on a common problem.

The strength of this pattern is mutual awareness. Agents build on, question and correct each other, and debate can surface better answers than any one agent finds. Shared context also enables groupthink: agents converge too early, reinforce each other’s biases, or defer to whichever agent speaks first or most confidently. The more interdependent the collaboration, the more it behaves like a single agent.

Use collaboration when subtasks are interdependent and agents need to see each other’s work, when quality benefits from debate or review between peers, or when different expertise must be integrated as the work happens rather than combined afterward.

Shared sessions. This pattern is often called group chat, where a chat manager coordinates agents in a shared discussion. The name can mislead: the general form is a shared session, in which several agents have different levels of access to a common conversation history. Some agents can only read the history, some can only write to it, and some do both. A shared session can be applied to any of the patterns on this page.

In a typical example, a parent workflow calls a planner agent, which asks a model for an execution plan and returns it as structured data. The workflow follows the plan and delegates to agents and child workflows, and all of them use one shared session when they build context for the model. A caller joins an agent to a session through the inSession option of the component client. The Ask Akka agent tutorial and its sample use explicit sessions in this way, as does the trip planning sample.

Shared sessions suit collaboration between agents, workflows and child workflows, and quality control that checks the session history. Avoid them when a sequential pipeline is enough, when conversations can grow without an upper limit or very many sessions start in a short time, and when there is no objective way to decide that a conversation is complete.

Teams and moderation. An Autonomous Agent that leads a team shares a task list with its members, and members message each other directly. Moderation is a more structured form: members still share context, but a moderator decides who speaks when, sees the full transcript and decides when the conversation ends. It trades some autonomy for a predictable cadence. Use it when the value comes from a shaped exchange, such as a peer review, a negotiation or a panel discussion, rather than from members claiming and completing work in parallel. See Coordination capabilities.

Example: A team lead splits a project into tasks. Developer agents claim tasks from the shared list, work on them independently and message peers when they need to coordinate. The lead monitors progress and disbands the team when the work is done.

Many agents work in parallel with little individual context, following simple rules. Each agent changes a shared environment, and the environment influences what the other agents do. Complex behavior emerges from these indirect interactions.

This pattern is for scale and exploration, and it is the hardest to make work. Behavior is statistical, the sum of many simple actions. That makes the system resilient, with no single point of failure, and also unpredictable. Selection turns many independent contributions into a useful result: emergent selection reinforces good contributions as other agents build on them, and external selection brings in something outside the swarm to evaluate and curate. In practice you may want both.

Use it for large problems with many similar agents and tolerance for probabilistic outcomes, for broad exploration, and to avoid converging early on one solution. There is no dedicated capability for it. It is usually built on team leadership as a blackboard system, in which the shared data space replaces direct messaging. The blackboard can be the team’s task list, or an entity or view offered to the agents as a tool.

Example: A brainstorm team adds ideas to a shared board, each agent independently. A lead curates the board, and the result emerges from accumulation and refinement rather than explicit coordination.