Let me tell you the same story twice.
The customer is Maya, who runs a small bakery and is shopping for a better inventory system. The seller is a software company whose agent, call it Olive, does first-line sales conversations. Both stories are hypothetical. Only one of them ends with Maya buying.
Version one: the cold start
Tuesday, 10:15 a.m. Olive calls Maya, who signed up for a trial the day before. The call is good. Maya explains that she bakes for three cafes, her biggest headache is tracking flour and butter, and she needs something her part-time staff can use on a phone. Olive says it will send a short pricing summary. The call ends warmly.
Olive's call system logs a transcript and marks the call "completed."
Tuesday, 10:40 a.m. The pricing summary goes out by email. The email system logs it as "sent."
Saturday, 8:05 a.m. Maya is at the bakery, hands covered in flour. She texts the number that called her on Tuesday: "Hey, quick question - does it work with more than one location? One of the cafes is opening a second spot."
The text arrives in the messaging system. That system has never heard of Tuesday's call. It has no idea who Maya is, beyond a phone number. So Olive replies:
> "Hi there! Thanks for reaching out. Could you tell me a bit about your business and what you are looking for?"
Maya stares at her phone. She told this to a person-sounding voice four days ago. She types, with flour on her screen: "I already explained this on the phone."
Olive, still blind to Tuesday, replies: "I'm sorry for the confusion! Could you share some details so I can help?"
Maya closes the app. She does not buy.
Nothing in this story is a model failure. Olive is polite, fluent, and quick. The failure is that every channel kept its own memory. Voice had a call record. Email had a sent log. Text had an empty inbox. Three systems, each correct about its own corner and wrong about Maya.
The whitepaper names this cross-channel fragmentation and describes it as the defining failure of current agent communication: the agent that called on Tuesday remembers nothing when the lead texts back on Saturday.
Version two: the session follows the customer
Rewind to Saturday, 8:05 a.m. Same text from Maya. Same bakery, same flour.
This time, the text arrives with context attached. Before Olive reads a word, it already has:
// illustrative pseudocode, modeled on the whitepaper's context block
context:
thread_id: "thread_maya_bakery"
turn_index: 4
prior_turns_summary:
"Trial signup Monday. Tuesday call: bakes for three cafes,
main pain is tracking flour and butter, needs mobile use
for part-time staff. Pricing summary emailed Tuesday."So Olive replies:
> "Good morning, Maya! Yes, multi-location is supported. Since your staff will be on phones, it works well for a second cafe. Want me to send a one-page comparison for the two-location setup?"
Maya, hands still floury, types: "Yes please."
Olive sends the comparison by email, and mentions it in the thread so Maya knows to look. Three days later, when Maya calls with a pricing question, the voice agent opens with, "Hi Maya, I see you were looking at a two-location setup. What would you like to know?"
She did not repeat herself once.
What changed between the two versions
Not the model. Not the tone. Not the pricing.
The difference is a single design decision: context belongs to the relationship, not the channel.
The whitepaper formalizes this as a thread and its sessions:
In the whitepaper's own example, a lead moves from a phone call to an SMS reply to an email to a WhatsApp message to a final call, and every turn arrives with full prior context. The channel switches are invisible to the customer, and nearly invisible to the agent.
Why this is hard to retrofit
You might think: just store everything in a database and look it up. Teams try. It tends to go wrong in predictable places.
Identity matching. A text comes from a phone number. An email comes from an address. A call comes from a different number than the one in the CRM. Deciding that all three are Maya is the hard part, and it needs a stable identity underneath.
Summaries, not dumps. Handing the model four days of raw transcripts is slow, expensive, and noisy. The useful thing is a compact, accurate summary of what matters, kept current as the conversation moves.
Multiple instances. The agent that answers Saturday's text may be a different process, or a different instance, from the one that made Tuesday's call. The memory cannot live inside any one of them.
Stale or wrong memory. A summary that says Maya wants three locations when she said two causes confident mistakes. Memory needs to be inspectable and correctable, and old facts need to age.
Boundaries. Some things should not follow a customer everywhere. Sensitive details shared on a call may not belong in a text thread that a family member glances at. Continuity is a feature only as long as it respects context.
The paper's argument is that none of this should be an application-layer project each team rebuilds. It should be a protocol primitive, delivered with every inbound message and maintained by the infrastructure, visible to the agent without extra calls.
The customer's view
Here is the easiest way to test your own system. Pretend to be a customer and do this:
1. Call. Explain a need in detail.
2. Wait a day.
3. Text the same number with a follow-up question that assumes the call happened.
4. Then send an email.
If any step makes you re-explain, you have a cold start. And from the customer's side, a cold start does not feel like a technical gap. It feels like being forgotten.
People forgive a lot from software. They rarely forgive being asked the same question twice by something that claims to be helping them.
The takeaway
Version one and version two have the same agent, the same words, and the same customer. One ends with a closed window and one ends with a sale.
Memory that follows the customer across channels is not a luxury feature. It is the difference between a conversation and a series of introductions.
Build it at the layer where every channel meets, so the agent that answers on Saturday already knows what happened on Tuesday. That is the thinking behind session continuity in ACES, and it is the kind of thing Dial handles at the infrastructure layer.