What is the Orchestrator?
The orchestrator is the routing layer that decides which agent should handle incoming messages. It sits between channels and agents, analyzing messages and dispatching them to the appropriate destination. In Kubernetes terms, the orchestrator is like an Ingress controller—it routes traffic to the right service based on rules.Architecture
Routing Modes
Disabled (Default)
All messages go to the default agent:Rules-Based
Route messages based on regex patterns:AI-Based
Let the LLM decide which agent to use:Hybrid
Combine rules and AI for best results:Manual Routing
Users can override routing with explicit mentions:Configuration
Namespace-Level Orchestration
In distributed mode, orchestration is configured per-namespace:Agent Bindings
Agents are bound to namespaces with triggers:Routing Flow
Proxy Channels
The orchestrator creates isolated channels for each message:Multi-Agent Responses
When routing to@all, responses are aggregated:
Conversation Context
The orchestrator maintains routing context per conversation:Sticky Routing
Enable sticky routing to maintain agent affinity:Monitoring Routing
View Routing Decisions
Routing Metrics
Best Practices
Use rules for performance
Use rules for performance
Rules-based routing is instant. Use it for common patterns to avoid AI latency.
Use AI for edge cases
Use AI for edge cases
Hybrid mode gives you the best of both worlds—fast rules and smart fallback.
Name agents clearly
Name agents clearly
Agent names should clearly indicate their purpose for accurate AI routing.
Test routing thoroughly
Test routing thoroughly
Test your rules with various message patterns to ensure correct routing.
Orchestrator vs Direct Chat
| Feature | With Orchestrator | Direct Chat |
|---|---|---|
| Multiple agents | Yes | No |
| Auto-routing | Yes | No |
| Manual selection | Yes | N/A |
| Latency | Higher (routing step) | Lower |
| Complexity | Higher | Lower |
klaw chat) for single-agent scenarios.
Use orchestrator for multi-agent deployments (Slack, distributed mode).

