Here's a scenario that every team building AI communication agents has hit:
Your agent calls a lead on Tuesday. Long conversation — the lead asks detailed questions about pricing, the agent walks through options, they agree to a follow-up. The lead says "send me the details over email."
The agent sends the email. The lead responds on Wednesday — not to the email, but via SMS. "One more question about the enterprise tier."
Your agent receives the SMS. It has no idea who this person is, no context from Tuesday's call, no knowledge that an email was sent, no awareness that this is message 4 in an ongoing conversation about a contract.
It starts from scratch. "Hi! How can I help you today?"
The lead, who has been in deep conversation with this agent for three days, gets a reset greeting and quietly loses confidence in your product.
Why this happens
Communication context is stored per-channel in today's infrastructure. Twilio tracks voice call records. Your email provider tracks email threads. Your SMS handler tracks message history. None of these systems talk to each other.
When a contact switches channels — which they always do, because humans communicate on whatever channel is most convenient at the moment — the session context lives in the channel they left, not the one they're on.
This is not a developer mistake. It's the architecture. Channels are separate products with separate APIs, separate authentication, separate data models. Stitching them together is custom engineering work that almost nobody does, because it requires building a session layer that none of the underlying platforms provide.
What agents need
An agent handling a multi-channel relationship needs to know, at every turn:
None of this should require the agent to look anything up. It should arrive with every inbound message, as part of the communication protocol itself.
The session model that works
The right architecture maintains a thread — a persistent record of the full relationship between an agent and a contact — that spans every channel and every session.
THREAD: agent ↔ [email protected]
SESSION 1 (May 20, via Phone)
Turn 1: Agent → "Hi, following up on your trial..."
Turn 2: Lead ← "Yes, interested. Send pricing."
Turn 3: Agent → Email sent: [pricing PDF]
SESSION 2 (May 22, via SMS)
Turn 1: Lead ← "Quick question on enterprise tier"
Turn 2: Agent → [picks up with full context from Session 1]When the SMS arrives in Session 2, it carries a prior_turns_summary in its message envelope: "Lead confirmed interest in enterprise plan after initial call on May 20. Pricing email sent. Has follow-up question on enterprise tier." The agent knows everything it needs to know.
This isn't a database lookup. It's a protocol feature. The session context is maintained at the infrastructure layer and delivered with every message — just like how a telephone call carries caller ID as a protocol feature, not an application feature.
The technical implementation
In an ACES-native system, every inbound message carries session context as a first-class field:
{
"context": {
"thread_id": "thread_lead_982",
"turn_index": 4,
"prior_turns_summary": "Lead confirmed interest in enterprise plan. Asked about pricing. Pricing PDF sent via email on May 22."
}
}The agent handler receives this with every message. There's no database query, no session reconstruction, no cross-channel API calls. The infrastructure did the work.
Why this matters for business outcomes
The cold start problem doesn't just make agents feel dumb. It directly affects conversion rates.
A sales agent that remembers the full history of a prospect relationship is not just more efficient — it's more human. It can reference what was discussed, acknowledge what was promised, pick up the thread naturally.
A sales agent that greets a warm lead like a stranger on every channel switch is not just annoying — it signals that the whole operation is disconnected, automated in a bad way, not actually paying attention.
Cross-channel session persistence is the difference between an AI agent that communicates like a colleague and one that communicates like a call center IVR.