Principle:Microsoft Autogen Swarm Orchestration
| Knowledge Sources | |
|---|---|
| Domains | Multi-Agent Systems, Swarm Intelligence, Team Orchestration, Workflow Architecture |
| Last Updated | 2026-02-11 00:00 GMT |
Overview
Swarm orchestration is the coordination pattern where a team of specialized agents is assembled and managed such that speaker transitions are driven entirely by agent-emitted handoff messages rather than by a centralized selector.
Description
Traditional multi-agent orchestration patterns rely on external mechanisms to determine which agent speaks next. Round-robin systems cycle through agents in a fixed order. Selector-based systems use an LLM to choose the next speaker based on conversation context. Swarm orchestration takes a fundamentally different approach: the agents themselves determine the routing.
In a swarm, the orchestrator's role is reduced to:
- Initialization: Designating the first speaker (the first participant in the list).
- Transition detection: Monitoring the message stream for HandoffMessage events and updating the active speaker accordingly.
- Continuation: If no handoff occurs, the current speaker continues.
- Termination: Stopping when a termination condition is met or max turns are reached.
This agent-driven routing model produces several architectural properties:
- Decentralized control: No single point of failure in routing decisions. Each agent independently decides whether to continue or hand off.
- Dynamic topology: The actual execution path through agents emerges at runtime based on conversation content, even though the possible paths are defined at configuration time.
- Participant ordering matters: The first participant is always the initial speaker. This is not merely a convention but an enforced requirement; the first participant must be capable of producing HandoffMessage instances.
- No inner team support: Unlike SelectorGroupChat or RoundRobinGroupChat, swarm teams do not support nested team participants. Each participant must be a direct ChatAgent.
Usage
Use swarm orchestration when:
- Agent-driven routing is preferred over centralized LLM-based speaker selection.
- The workflow topology is known at design time but the execution path should be determined dynamically by the agents.
- You need lightweight orchestration without the overhead of an additional LLM call for speaker selection.
- Each agent has clear handoff criteria that can be expressed in its system prompt and handoff descriptions.
- The team should support human-in-the-loop patterns through HandoffTermination.
Theoretical Basis
Swarm orchestration implements a finite state machine (FSM) where each agent is a state and handoff messages are transitions:
Swarm FSM:
States: S = {agent_1, agent_2, ..., agent_n}
Initial state: s_0 = agent_1 (first participant)
Transitions: T: S x HandoffMessage -> S
Execution loop:
current_speaker = s_0
REPEAT:
messages = current_speaker.process(conversation_context)
IF termination_condition(messages):
STOP with TaskResult
IF max_turns exceeded:
STOP with TaskResult
handoff = find_last_handoff(messages)
IF handoff is not None:
current_speaker = handoff.target
ELSE:
current_speaker = current_speaker (no change)
The speaker selection algorithm in the swarm manager:
- If the message thread is empty, select the current speaker (initialized to the first participant).
- Otherwise, scan the thread in reverse order for the most recent HandoffMessage.
- If found, update the current speaker to the handoff target.
- If no handoff is found, retain the current speaker.
This is distinct from other orchestration patterns:
| Pattern | Speaker Selection | Routing Logic | LLM Overhead |
|---|---|---|---|
| Round Robin | Fixed rotation | Predetermined order | None |
| Selector | LLM-based | Centralized LLM decides | Extra LLM call per turn |
| Swarm | Handoff-based | Agent-driven (decentralized) | None (beyond agent's own LLM call) |