Status: In Development · Playground demo coming soon.
The recipe below is complete and runnable today; only the hosted playground showcase is pending.
What you’ll build
A multi-agent support cluster where:- Tier-1 triages: answers common questions, takes safe actions, escalates clean
- Tier-2 specializes: picks up with full T1 context already in memory, runs deeper diagnostics
- Memory is shared across both agents: same
user_id, samecustomer_id - Handoffs are explicit: the customer is told they’re being moved, T1 writes a summary, T2 reads it
When to use this recipe
Build this if:- Your support has a meaningful skill split (general vs specialist, billing vs technical, etc.)
- A high % of tickets resolve at T1 and you want to keep T2 capacity for the hard ones
- Customer continuity across the handoff matters: no “please explain again” moments
- You can describe the escalation rule clearly (this is the bit that breaks if vague)
Architecture at a glance

Stack
Multi-agent orchestration is a great fit for LangGraph (Python) and Mastra (TypeScript) if you want graph-shaped routing with retries and persistence baked in. The recipe below uses OpenAI Agents / Vercel AI SDK to stay consistent with the rest of the Cookbook; port to LangGraph/Mastra once your routing graph grows.
Prerequisites
- A Synap API key. See Authentication
- Python: Python 3.11+
- TypeScript: Node 18+ and Python 3.11+ on the host
Install
Build it
1. Shared scoping
Both agents use the same scopes. That’s the whole trick.customer_id = "<your-product>": single tenant or per-customer orguser_id = <ticket requester ID>conversation_id: one per ticket, shared across both agents
conversation_id, user_id, and customer_id must be valid UUIDs. Generate the per-ticket id with str(uuid.uuid4()) (Python) or crypto.randomUUID() (JS), as shown below.2. The escalation policy
This belongs in your code, not the LLM’s head. T1 calls a tool to escalate; the tool decides what counts.3. The Tier-1 agent
Fast model, common-issue tools, escalate when out of depth.4. The Tier-2 agent
Bigger model, deeper tools, picks up with full T1 context already in memory.5. The router
One small function picks which agent gets the next message based on routing state.Run & verify
Turn 1 (routes to T1)
Turn 2 (still T1, but escalates)
Turn 3 (now T2)
Customize / extend
- Three or more tiers → add tools and routing entries. Memory model is unchanged.
- Human at the end → the final tier can be a human queue. See WhatsApp + Human Handoff for the pattern.
- LangGraph / Mastra port → if routing grows into a real graph, port to LangGraph (Python) or Mastra (TypeScript).
- Slack as the channel for T2 → some teams have T2 specialists working out of Slack. Same agent, different I/O. See Patterns → Slack Bot.
Troubleshooting
T2 re-asks the customer to explain- Sharpen the T2 system prompt’s “don’t make them re-explain” rule.
- Confirm the T1 escalation memory is being written before the customer’s next turn (no race).
- Check
synap_searchactually fires on the first T2 turn: log tool calls during development.
- The escalation rule is too vague in the prompt. Tighten the criteria, and consider gating with a tool-side check: require
synap_searchto have been called first.
ROUTINGis in-process memory. Use Redis with TTL. After a resolution, clear the routing entry so the next ticket starts at T1.
- The bridge message helps. Customize it per escalation reason (“connecting you with billing” vs “connecting you with engineering”).
Related
- Integrations: OpenAI Agents SDK · Vercel AI SDK · LangGraph · Mastra
- Concepts: Memory Scopes · Conversational Context Lifecycle · Agent Interactions
- Patterns: Slack Bot · Graceful Degradation
- Other recipes: WhatsApp + Human Handoff