Orchestrator Agent Pattern
The orchestrator agent is the entry point for a multi-agent team. It reads the user's intent and routes to the appropriate specialist — using keyword rules, embedding similarity, or its own LLM reasoning to make the routing decision.
What Makes an Agent an Orchestrator?
Any Octopus agent can act as an orchestrator. What distinguishes it is:
- Its system prompt focuses on intent classification, not domain answering
- Its tool registry includes the
route_to_agentandhandoff_to_agenttools (registered by the multi-agent plugin) - It has a
TeamConfigthat lists the specialist agents it can route to - Its LLM may be a smaller/cheaper model since it only routes — not a heavy reasoning model
AgentRouter
The AgentRouter is the component that makes the routing decision. It is configured with a routing strategy:
public class AgentRouter
{
public async Task<AgentRoutingResult> RouteAsync(
string userMessage,
AgentTeam team,
CancellationToken ct = default)
{
return _config.Strategy switch
{
RoutingStrategy.Keyword => await KeywordRouteAsync(userMessage, team),
RoutingStrategy.Embedding => await EmbeddingRouteAsync(userMessage, team),
RoutingStrategy.LLM => await LLMRouteAsync(userMessage, team),
_ => AgentRoutingResult.Default(team.DefaultAgentId)
};
}
private async Task<AgentRoutingResult> EmbeddingRouteAsync(
string message, AgentTeam team)
{
var queryEmbedding = await _embeddingProvider.EmbedAsync(message);
var scores = team.Members.Select(member => new
{
AgentId = member.AgentId,
Score = CosineSimilarity(queryEmbedding, member.IntentEmbedding)
});
var best = scores.MaxBy(s => s.Score);
return new AgentRoutingResult(best!.AgentId, best.Score, RoutingStrategy.Embedding);
}
}
Orchestrator System Prompt Template
The orchestrator's system prompt is focused entirely on routing:
You are a routing assistant for the BizFirstGO enterprise support team.
Your job is to determine which specialist agent should handle the user's request.
Available specialists:
- HR Agent: leave requests, payroll questions, benefits, onboarding
- Finance Agent: expense reports, budget queries, invoice approval
- IT Support Agent: software issues, access requests, hardware problems
- Legal Agent: contract review, compliance questions, policy interpretation
Rules:
1. Route to exactly one agent per user message.
2. If the request spans multiple domains, route to the primary one.
3. If you cannot determine the domain, route to the default agent.
4. Do NOT answer the user's question yourself — only route.
Use the route_to_agent tool to route.
Routing Decision with LLM Strategy
// The orchestrator LLM is given the route_to_agent tool:
{
"name": "route_to_agent",
"description": "Route the user's request to the appropriate specialist agent.",
"inputSchema": {
"type": "object",
"properties": {
"agentId": { "type": "string", "description": "The ID of the target specialist agent" },
"reason": { "type": "string", "description": "Why this agent was selected" },
"confidence": { "type": "number", "description": "0.0 to 1.0 routing confidence" }
},
"required": ["agentId", "reason"]
}
}
Routing Configuration in agents-app
In the agents-app, the team's routing policy is configured in the Team Config panel:
| Field | Value | Description |
|---|---|---|
| Routing Strategy | Embedding / Keyword / LLM | How routing decisions are made |
| Default Agent | Agent ID | Fallback when no agent matches |
| Confidence Threshold | 0.0 – 1.0 | Min score to route; below this goes to default |
| Intent Examples | List of phrases per agent | Used for embedding-based routing index |
If routing latency is a concern, use keyword or embedding routing rather than LLM routing. LLM routing adds a full LLM call to every user message before the specialist even starts. Embedding routing typically adds less than 20ms.