Multi Agent
Multi-Agent Servers
Run multiple agents on a single server using AgentServer. Each agent gets its own route, and you can configure SIP-based routing for username-to-agent mapping.
Multi-agent servers let you run several specialized agents from a single process. This simplifies deployment, reduces resource overhead, and provides unified management. Instead of running separate processes for sales, support, and billing agents, you run one server that routes requests to the appropriate agent.
This architecture is especially useful when you have related agents that share infrastructure but have different personas and capabilities.
Single Agent vs Multi-Agent: Decision Guide
Choosing between agent.run() and AgentServer depends on your deployment needs.
Use single agent (agent.run()) when:
- You have one agent with a single purpose
- You want the simplest possible deployment
- Each agent needs isolated resources (memory, CPU)
- Agents have very different scaling requirements
- You’re using container orchestration that handles multi-instance deployment
Use AgentServer when:
- You have multiple related agents (sales, support, billing)
- Agents share the same deployment environment
- You want unified health monitoring
- SIP routing determines which agent handles a call
- You want to reduce operational overhead of managing multiple processes
- Agents share common code or resources
Basic AgentServer
Agents are available at:
AgentServer Configuration
Registering Agents
With Explicit Route
Using Agent’s Default Route
Server Architecture

Managing Agents
Get All Agents
Get Specific Agent
Unregister Agent
SIP Routing
Route SIP calls to specific agents based on username:
When auto_map=True, the server automatically creates mappings:
- Agent name → route (e.g., “salesagent” → “/sales”)
- Route path → route (e.g., “sales” → “/sales”)
SIP Routing Flow

Health Check Endpoint
AgentServer provides a built-in health check:
Response:
Serverless Deployment
AgentServer supports serverless environments automatically:
Complete Example
AgentServer Methods Summary
Performance Considerations
Running multiple agents in a single process has implications:
Memory: Each agent maintains its own state, but they share the Python interpreter. For most deployments, this reduces overall memory compared to separate processes.
CPU: Agents share CPU resources. A heavy-load agent can affect others. Monitor and adjust if needed.
Startup time: All agents initialize when the server starts. More agents = longer startup.
Isolation: A crash in one agent’s handler can affect the entire server. Implement proper error handling in your handlers.
Scaling: You scale the entire server, not individual agents. If one agent needs more capacity, you scale everything. For very different scaling needs, consider separate deployments.
Shared State Between Agents
Agents in an AgentServer are independent instances—they don’t share state by default. Each agent has its own prompts, functions, and configuration.
If you need shared state:
Use external storage (Redis, database) rather than Python globals:
Sharing configuration:
For shared configuration like API keys or business rules, use a shared module:
Routing Logic
AgentServer routes requests based on URL path and SIP username. Understanding this routing helps you design your agent structure.
Path-based routing is straightforward:
- Request to
/sales→ Sales agent - Request to
/support→ Support agent
SIP routing extracts the username from the SIP address:
sip:sales@example.com→ looks up “sales” → routes to/salessip:help-desk@example.com→ looks up “help-desk” → routes based on mapping
Auto-mapping creates automatic mappings from agent names and route paths:
Manual mapping gives explicit control:
Common Patterns
Department-Based Routing
Route calls to different departments based on phone number or SIP username:
Time-Based Routing
Route to different agents based on business hours (implement in a custom router):
Feature-Based Agents
Different agents for different capabilities:
Best Practices
DO:
- Use meaningful route names (/sales, /support, /billing)
- Enable SIP routing for SIP-based deployments
- Monitor /health endpoint for availability
- Use consistent naming between routes and SIP usernames
- Implement proper error handling in all agent handlers
- Use external storage for shared state
- Log which agent handles each request for debugging
DON’T:
- Register duplicate routes
- Forget to handle routing conflicts
- Mix agent.run() and AgentServer for the same agent
- Store shared state in Python globals (use external storage)
- Put agents with very different scaling needs in the same server