Use subagents to keep MCP usage predictable as tool count grows.
Reference architecture
Recommended subagents
| Subagent | Tools to include | Guardrails |
|---|
| Contacts | search, create, update, tag, merge | block destructive updates without explicit user confirmation |
| Conversations | list threads, read messages, send messages | enforce channel and recipient validation |
| Calendar | check availability, create appointments, reschedule | require timezone normalization before booking |
| Opportunities | read pipelines, move stages, update values | require reason text for stage/value changes |
| Payments | invoices, transaction lookup, payment status | read-only by default; gate write actions behind approval |
Router policy
The router should decide by intent, then hand off to one specialist:
- Contact lookup, enrichment, segmentation -> Contacts
- Messaging, inbox summaries, follow-ups -> Conversations
- Booking or rescheduling -> Calendar
- Deal progression and forecasting -> Opportunities
- Billing, invoices, transaction checks -> Payments
System prompt pattern
You are the router. Never call MCP tools directly.
Pick exactly one specialist subagent unless task requires a sequence.
If task is write/destructive, request explicit user confirmation first.
If location is missing, ask for locationId before delegating.
Execution strategy
- Router classifies user intent.
- Specialist agent calls MCP tools for that domain only.
- Specialist returns structured output to router.
- Router produces final response and audit trail.
Minimal implementation checklist
- Build one MCP client wrapper shared by all subagents.
- Add per-subagent allowlists for tool names.
- Add approval middleware for write operations.
- Log all MCP tool calls with
locationId, tool name, and status.
- Add replay tests for common workflows.
Starter template in this repo
Use the included template files as your baseline:
mcp/subagents/subagents.config.example.jsonmcp/subagents/README.md
Last modified on March 6, 2026
