Principle:Microsoft Autogen Selector Orchestration
| Knowledge Sources | |
|---|---|
| Domains | Multi-Agent Systems, Orchestration, LLM Routing, Dynamic Speaker Selection, AI Agents |
| Last Updated | 2026-02-11 00:00 GMT |
Overview
Selector orchestration is a dynamic turn-taking strategy in which an LLM (or custom function) analyzes the conversation context to decide which agent should speak next, enabling adaptive multi-agent workflows where the most relevant agent is chosen at each step.
Description
While round-robin orchestration assigns turns in a fixed order, many real-world multi-agent scenarios require context-sensitive speaker selection. For example, in a software development team with a planner, coder, and tester, the coder should speak after a plan is produced, and the tester should speak after code is written -- but the planner might need to speak again if the tester finds issues. The speaking order depends on what was just said.
Selector orchestration addresses this by using an LLM as a meta-agent that reads the conversation history and selects the most appropriate next speaker from the available participants. The selection LLM is given a prompt containing:
- Role descriptions: Each participant's name and description, so the selector understands what each agent does.
- Conversation history: The recent messages exchanged, so the selector understands the current state.
- Selection instruction: A directive to choose the next speaker and return only the agent's name.
The selector approach offers several advantages over fixed ordering:
- Adaptiveness: The conversation flow naturally follows the task requirements rather than an arbitrary sequence.
- Efficiency: Agents only speak when their expertise is relevant, avoiding unnecessary turns.
- Flexibility: New agents can be added to the team without redesigning the conversation flow.
- Emergent behavior: The conversation patterns emerge from the selector's understanding of the task rather than being hard-coded.
Key configuration dimensions include:
- Selector prompt: The template that instructs the selection LLM. It uses placeholders for roles, participant names, and conversation history.
- Repeated speaker policy: Whether the same agent can be selected consecutively. Disabling this encourages diverse participation.
- Custom selector function: An optional programmatic override that bypasses the LLM entirely for cases where selection logic can be expressed as code.
- Candidate filtering: An optional function that narrows the set of eligible speakers before the selector makes its choice.
- Retry logic: If the LLM returns an invalid agent name, the system retries up to a configurable number of attempts.
Usage
Use selector orchestration when:
- The conversation flow should adapt to what agents have said, not follow a predetermined order.
- You have agents with distinct specializations and want the most relevant one to speak at each step.
- You need complex multi-agent workflows without explicit state machine programming.
- You want the LLM to act as a router directing work to the right specialist agent.
- You need to combine LLM-based selection with programmatic overrides for specific situations.
Theoretical Basis
Selector orchestration implements a form of centralized dynamic scheduling where a scheduler (the selector LLM) makes routing decisions based on the current state of the system (conversation history).
This can be modeled as a Markov Decision Process (MDP) where:
- State: The conversation history up to the current turn.
- Action space: The set of available participants.
- Policy: The selector LLM's decision function, mapping conversation state to the next speaker.
- Transition: After the selected agent speaks, a new state (updated conversation history) is produced.
The selection process follows this logic:
FUNCTION selector_select_next(participants, history, model_client, selector_prompt):
1. If candidate_func is defined:
a. candidates = candidate_func(history)
b. If candidates has exactly one agent, return that agent (skip LLM)
2. If selector_func is defined:
a. Return selector_func(history) (fully custom logic)
3. Build role descriptions from participant names and descriptions
4. Format selector_prompt with {roles}, {participants}, {history}
5. If not allow_repeated_speaker:
a. Remove last speaker from candidate list
b. If only one candidate remains, return that candidate
6. FOR attempt = 1 to max_selector_attempts:
a. Call model_client with formatted prompt
b. Parse response to extract agent name
c. If name matches a valid participant, return that participant
d. If name is invalid, retry with error feedback
7. If all attempts fail, fall back to first valid candidate
The two-level override system (candidate_func then selector_func) enables a hybrid approach: programmatic logic can narrow the candidates or fully determine the speaker for known situations, while the LLM handles the general case. This is analogous to a policy with constraints in reinforcement learning, where the action space is restricted before the policy selects.
The retry mechanism addresses the inherent unreliability of LLM outputs. Since the selector LLM produces free-form text, it might occasionally return an invalid agent name. The retry loop with error feedback gives the LLM a chance to correct itself, and the configurable max_selector_attempts controls the trade-off between reliability and latency.