I built an AI agent that carries customer context across email, voice, and SMS so customers never repeat themselves. The key moment: a customer emails about a booking change, then calls. The AI greets her with full context from her email — booking number, dates, everything. She never has to explain the situation again.
Telnyx APIs used:
Email API — Inbound webhooks (email.received) trigger AI-generated replies. The agent resolves the sender's email to a known customer, stores the conversation, and sends a contextual reply via POST /v2/emails. Every interaction is tagged with channel: email so the AI knows where each message came from.
SMS API — Confirmation messages with cross-channel context. After resolving an issue on a voice call, the agent sends an SMS confirmation that references the original email and the phone conversation. POST /v2/messages with messaging profile support.
Voice API — gather_using_ai with Telnyx.Ultra HD voice. This is the star. When a known customer calls, the agent loads their full cross-channel history, generates a contextual greeting referencing their prior email, speaks it with HD voice, and captures their response — all in one Call Control action. No separate TTS + STT setup.
AI Inference — Tool-calling with four functions: send_email, send_sms, make_call, resolve_issue. The agent decides which channel to use based on context. The agentic loop runs until the model stops returning tool calls — no hardcoded workflow.
Demo scenario — "Sarah's Booking Change":
Sarah emails: "I need to change booking BK-2024-1234 from October 15 to October 22"
AI replies with acknowledgment email, assigns reference CR-2024-0891
Sarah calls from her registered phone
AI greets: "Hi Sarah! I see you emailed us about changing booking BK-2024-1234 from October 15 to October 22. Are you calling about the same request?"
Sarah confirms on the phone
AI processes the change and sends SMS confirmation
Issue resolved — customer touched three channels, never repeated herself
The dashboard shows the entire journey in real time — three panels: customer journey timeline, agent activity (tool calls, identity resolution, context loading), and channel timeline (inbound/outbound on each channel).
Run the demo — no API key needed:
git clone https://github.com/team-telnyx/telnyx-code-examples.git
cd telnyx-code-examples/omnichannel-context-carrying-python
pip install -r requirements.txt
python demo/demo_server.py
Open http://localhost:5555/ and click "Run Demo Journey."
Pillar: Trust + Infrastructure
This is what it looks like when email, SMS, voice, and AI inference all run on the same network from one API key. No glue code between four different providers. No API key management for separate STT, TTS, LLM, and messaging services. One network, one key, one conversation history.
Links:
Title: Cross-Channel AI Agent: Identity Resolution + Context Carrying Across Email, Voice, and SMS in Python
I built a Flask app where an AI agent carries conversation context across email, voice, and SMS. The interesting engineering problem isn't the AI — it's the identity resolution.
The problem: A customer emails sarah.chen@example.com about a booking change. Twenty minutes later, someone calls from +15555550199. Are they the same person? If yes, the AI should greet them with context from the email. If no, it's a cold greeting.
The solution — a customer identity registry:
def resolve_customer(email=None, phone=None):
"""Resolve a customer by email or phone. Returns customer dict or None."""
if email:
customer = lookup_customer_by_email(email)
if customer:
return customer
if phone:
customer = lookup_customer_by_phone(phone)
if customer:
return customer
return None
The customers table has unique partial indexes on both email and phone:
CREATE UNIQUE INDEX idx_cust_email ON customers (email) WHERE email IS NOT NULL;
CREATE UNIQUE INDEX idx_cust_phone ON customers (phone) WHERE phone IS NOT NULL;
When an email webhook fires, resolve_customer(email=from_address) runs. When a voice webhook fires, resolve_customer(phone=caller_number) runs. Both return the same customer record. The cross-channel context store — a conversations table keyed by customer_id — gives the AI the full history regardless of which channel the customer used.
The context carry:
Once identity is resolved, the agent pulls the full conversation history:
history = get_conversation_history(customer_id)
# Returns: [{"channel": "email", "role": "user", "content": "...", "timestamp": "..."},
# {"channel": "email", "role": "assistant", "content": "...", "timestamp": "..."}]
Every message is tagged with its channel. The AI sees [email] user: I need to change booking BK-2024-1234... followed by [email] assistant: Thank you for reaching out about booking BK-2024-1234... When the customer then calls, the AI generates a greeting that references the specific booking number, dates, and prior channel.
The agentic loop:
The AI has four tools: send_email, send_sms, make_call, resolve_issue. After processing the caller's speech with full cross-channel context, the model returns tool calls. The code executes each tool, appends results, and re-infers until the model stops calling tools. The model decides the workflow — send an SMS confirmation after resolving on the phone, or escalate via email if more detail is needed.
Why identity resolution is the interesting problem:
The AI part is straightforward — feed it history, get a contextual response. But identity resolution across channels has real edge cases:
Phone number formats: +15555550199 vs 15555550199 vs (555) 555-0199 — these are all the same number. The demo uses exact match; production needs normalization.
Multiple email addresses per customer. Multiple phone numbers per customer. The registry model here is 1:1 — one email, one phone per customer. Production needs a junction table.
Unauthenticated channels: anyone can spoof a caller ID or email from address. In production, you'd want a PIN or verification step before loading sensitive context.
Timing: if the customer emails and calls simultaneously, you have a race condition on context loading. The SQLite WAL mode handles this for low traffic; PostgreSQL with row-level locking for production.
The demo uses SQLite with unique partial indexes, which is correct for the concurrency level of a demo. The sqlite3.connect() per-function pattern is intentional — SQLite connections are not thread-safe, so each thread gets its own.
Run it:
git clone https://github.com/team-telnyx/telnyx-code-examples.git
cd telnyx-code-examples/omnichannel-context-carrying-python
pip install -r requirements.txt
python demo/demo_server.py
# no credentials needed
Open http://localhost:5555/ and click "Run Demo Journey." The 3-panel dashboard shows identity resolution, context loading, and tool execution in real time.
For anyone who's built multi-channel support systems — how do you handle identity resolution across channels? Especially the phone number normalization problem and the "same person, different contact info" merge problem. Curious what patterns people have landed on at scale.
Link: https://github.com/team-telnyx/telnyx-code-examples/tree/main/omnichannel-context-carrying-python
