AI orchestration patterns

Consider an activity recommendation application with multiple agents, some called concurrently and others sequentially. It has a weather agent and an activity agent. The weather agent retrieves the weather forecast for when the user wants to plan an activity, and then supplies that forecast to the activity agent.

If one agent is coded to directly call another agent, then that agent must always call that other agent. The weather agent would always call the activity agent, making it difficult (if not impossible) to reuse the weather agent in other flows within the same application.

Akka approaches this through workflows and composable design. Agents built with Akka typically do exactly one thing, and ideally this one thing is small. These small building-block agents lend themselves well to being composed in different ways to support multiple patterns.

The key difference between direct agent communication and Akka’s approach is that in Akka the workflow decides which agents are called, when they’re called, and whether they run concurrently. Agents become small, easily managed pieces of code that handle discrete interactions with a model. The results of those interactions can be reused in many different ways by the guiding workflows.

This orchestration approach is often called the supervisor pattern: a central workflow acts as the supervisor, coordinating multiple worker agents. Agents don’t communicate directly with each other, instead, the supervisor decides which agents to call, in what order, and how to handle their outputs. This separation keeps agents simple and reusable while centralizing reliability concerns like durable execution steps, retries, and failure handling in the workflow.

Akka offers two implementations of the supervisor pattern. A Workflow supervises agents from outside, with explicit steps written by the developer; this is the focus of the examples below. An Autonomous Agent supervises through its declared coordination capabilities (delegation, handoff, teams, moderation), with the framework driving the loop and the model deciding which agent runs next. Both give the same durable-execution, retry, and audit guarantees; the difference is whether the orchestration sequence is fixed in code or decided by the model. The remainder of this document describes each orchestration pattern and maps it to one or both of those options.

The corollary of the supervisor pattern is a rule about how agents communicate: agents should not make ad-hoc, protocol-level calls to other agents. When an agent reaches another agent directly, over HTTP, gRPC, JSON-RPC, A2A, ACP, or by wrapping the call as an MCP tool, it bypasses platform mediation and gives up durability, retries, and audit. It also permanently fixes the supervision structure, so the calling agent can no longer be composed into other flows.

Instead, route all coordination through a supervisor that runs on the Akka runtime: a Workflow when the orchestration steps are fixed in code, or an Autonomous Agent coordination capability (delegation, handoff, teams, moderation) when the model should decide which agent runs next. Both inherit the same composability, durability, and recovery guarantees from the runtime. The coordination tools that the Autonomous Agent runtime exposes to the model are platform-mediated and durable, and are distinct from the ad-hoc protocol calls to avoid.

For the mechanics of how a supervisor reaches its agents and external services, see Component and service calls and Integrations.

In the sequential orchestration pattern, AI agents are assembled in linear chains (also frequently referred to as “pipelines”) in a well-known, fixed order at development time. Each agent in the chain passes the output of its work to the input of the next agent in the chain.

Akka moves the responsibility of direct agent calls up to an orchestrating workflow, as shown here:

This pattern is used in step-by-step processing, where each step builds on the results of the previous step.

Sequential orchestration is ideal for:

You should avoid sequential orchestration when:

Concurrent orchestration refers to running multiple AI agents simultaneously working on the same task. The outputs of all concurrent agents are then collected and processed. This is ideal when you have a number of agentic tasks that do not rely on the outputs of others.

A workflow initiates the concurrent agents and collects their results.

Note that in this diagram, the workflow is responsible for controlling agent 1.1 and agent 1.2. Akka agents don’t spawn sub-agents; the workflow decides which agents are needed and the Akka runtime takes care of provisioning.

As you’ll see later in this document, Akka workflows can easily spawn concurrent agents or even sub-workflows as needed. This reinforces the notion that the only real difference between these patterns in Akka and elsewhere is that Akka separates the roles of orchestration and model communication while most other frameworks choose to combine them.

More advanced concurrent orchestration could be implemented by a parent workflow spawning child workflows. In this pattern, each child workflow performs a multi-step task and then delivers the result back to the parent workflow as a message (i.e. method call). The parent workflow pauses when waiting for the results from children. The results would be stored in the state, and when the parent workflow is satisfied with all of the collected results it transitions to another step.

In this kind of advanced scenario, Akka takes care of all the hard parts like managing distributed state, distributed long-running timers, workflow resiliency, and much more.

When the coordinator is itself an Autonomous Agent, the equivalent is the delegation capability configured for parallel workers: the model picks which workers to launch, and the runtime runs them concurrently and gathers the results back into the coordinator’s context.

Group chat orchestration is when multiple agents collaborate to solve problems, make decisions, or judge work products. This collaboration between agents is facilitated by a shared discussion and a chat manager to coordinate all of the activities.

Calling this pattern a group “chat” can be misleading. We prefer to use a more generalized pattern name, such as shared sessions where multiple agents have different levels of access to a common conversation history during the task. Group chat is just one of many possible implementations of this pattern.

In this example, the parent workflow calls a planner agent. The planner agent’s job is to interact with a model to determine an execution plan and then return this plan as some well-typed, structured data.

This plan is then interpreted and followed by the parent workflow, which then delegates to agents and even child workflows. Throughout all of these agent and workflow interactions, a common shared session is used by all of the agents when building context for LLMs.

This concept of a shared session in Akka is flexible enough that it can be applied to any of the patterns outlined in this document.

Group chat (session) orchestration is ideal for:

Group chat (session) orchestration should be avoided when:

When the coordinator is itself an Autonomous Agent, the equivalents are the teams capability (peer team with a shared task list and direct messaging between members) and the moderation capability (turn-taking conversations driven by a moderator). See Coordination capabilities for the details.

Handoff orchestration refers to empowering agents to defer or to hand off work to some other part of the process. In this pattern the plan and tasks are not completely known until receiving the initial input. Part of the dynamic planning process involves choosing which agents will be involved and which will not.

Akka has two natural fits for handoff. The Autonomous Agent component implements handoff directly as a capability: an agent declares which peers it can hand off to and the runtime exposes a handoff tool to the model. When the model decides to hand off, ownership of the task transfers to the next agent and the first agent steps back. Because the capability is declared on the agent and driven by the runtime, the durability, retry, and audit guarantees come from the runtime, not from agent code.

For request-based agents, the same outcome can be achieved with a workflow that uses a planning agent to choose the next worker. If the individual request-based agents are themselves responsible for deciding whether to handle a given input, those agents can no longer be recomposed for any other purpose; with Akka you instead use a combination of workflows, optional sub-workflows, and specialized planning agents.

With agents getting structured responses from LLMs, it is possible to instruct the LLM to judge what agent might be best suited for handling a request. The planning response is then handled by the workflow, which calls the selected agent.

Tool calls (e.g. MCP) can be used to add more deterministic logic to planning and routing when pure LLM-based judgment might not be predictable enough.

This plan-and-execute loop can be extended by combining it with any of the other patterns outlined in this document.

Magentic orchestration is a pattern for open-ended, complex problems that don’t have a predetermined plan. This dynamic planning aspect often overlaps with other patterns in this group. In this pattern, agents frequently have access to tools.

In this dynamic variant of the supervisor pattern, an AI model creates the plan, decides the next step, evaluates results, and determines when the goal has been achieved. Either supervisor implementation works for this pattern. With a workflow supervisor, the workflow still provides durable execution with built-in retry mechanisms; the AI influences what happens, but the workflow ensures it happens reliably. With an Autonomous Agent coordinator using delegation, the same guarantees come from the runtime: the model picks the next worker and the runtime persists the task, retries failures, and bounds iteration.

When we use one of these supervisors as a ubiquitous coordinator and allow agents to be small, purpose-built model interaction components, then the need for individual, concrete patterns becomes less explicit. We don’t need to rewrite agents if we want to use them in different ways, we can either change how planning agents work, modify small bits of logic in the workflow, or change the coordinator’s declaration.