Problem
A customer calls on Monday, gets a quote, and opens the website chat on Wednesday to ask about it. In almost every deployment we have seen, the second conversation starts from nothing.
The naive framing is "connect the channels". The real question is narrower and harder: what may an agent remember about someone, across which interfaces, and on what evidence that it is the same someone?
Hypothesis
One agent definition can serve several channels with a shared knowledge base and shared business logic. Shared *memory* is a separate problem gated on identity confidence, and should be modelled as such rather than as a channel feature.
Architecture
One agent definition - instructions, tools, guardrails
An adapter is responsible for exactly three things: transport, the timing model of its channel, and the affordances it can express. Nothing else may live there. The moment an adapter starts holding business rules, the promise of a single agent definition is gone and you have four agents with a shared logo.
| Property | Phone | Web chat | Messaging |
|---|---|---|---|
| Timing | Synchronous, sub-second | Synchronous, seconds | Asynchronous, hours |
| Turn length | Short, spoken | Medium | Variable, often batched |
| Rich output | None - audio only | Links, cards, files | Links, files |
| Identity evidence | Caller number | Session, cookie | Account handle |
| Knowledge | Shared | Shared | Shared |
| Business logic | Shared | Shared | Shared |
| Guardrails | Shared | Shared | Shared |
Implementation
Memory tiers
We split memory into three tiers with different sharing rules, because they carry very different risk if they leak to the wrong person.
- Turn state - what is happening right now. Never shared across channels; it dies with the session.
- Episode summary - a compact record of one completed conversation. Shared, but only above an identity-confidence threshold.
- Durable facts - preferences, entitlements, open tickets. Shared, and always attached to a record in a system of record, never to an agent-internal blob.
That third rule is the one that saved us. Durable facts live in the CRM and are read through a tool; the agent has no private long-term store. When a customer asks to be forgotten, there is exactly one place to delete from - a property that is very hard to retrofit.
Identity confidence
Each channel produces a different quality of evidence. We score it rather than treating it as boolean, and the score gates what the agent may recall unprompted.
// Evidence strength differs per channel. A caller ID is a hint, not a
// login: number spoofing and shared household phones both break the
// assumption, so recall is gated rather than automatic.
const EVIDENCE = {
authenticatedSession: 0.95,
verifiedCallback: 0.80, // we called them back on a stored number
callerIdMatch: 0.55,
sameDeviceSession: 0.50,
nameAndPostcode: 0.45,
} as const
// Below the threshold the agent may still *use* durable facts once the
// caller volunteers the reference themselves - it just may not open with
// them. "I see you called about X" to the wrong person is a data breach
// with a friendly tone of voice.
const RECALL_THRESHOLD = 0.75Below the threshold, the agent may verify but not volunteer. It can ask "is this about the quote from Monday?" only once the caller has given it a reason to; it may never open a call by reciting what it remembers.
Result
The single agent definition held up. Sharing instructions, tools and guardrails across adapters worked with fewer per-channel exceptions than expected - the exceptions that remain are about output format (a phone agent cannot send a link) rather than about behaviour.
Shared memory did not hold up as a channel feature, and we stopped treating it as one. It is an identity feature. Once we modelled confidence explicitly, most of the uncomfortable product questions - "should it greet them by name?" - became a threshold decision with an auditable answer instead of an argument.
One finding we did not expect: callers are more forgiving of an agent that asks a verifying question than of one that knows too much. Confident recall from an unauthenticated channel reads as surveillance, even when it is correct.
Limitations
What this experiment does not establish. Listed because an experiment without limitations is an advertisement.
- This is a prototype, not a shipped capability. It runs against a test tenant with synthetic customer records; it has not been through a data-protection review for production use.
- The evidence weights are hand-set. They encode our judgement about risk, not a calibration against real linkage accuracy.
- Asynchronous channels stress the model in ways we have not resolved: an email thread that resumes after three weeks has valid identity evidence and stale context, which is a different failure than we designed for.
- Cross-channel recall has jurisdiction-specific legal constraints that a threshold does not capture. Engineering can make it auditable; it cannot make it lawful on its own.
Next steps
- Add an explicit consent step so a customer can opt in to cross-channel recall, and record that consent as evidence in its own right.
- Test the episode-summary tier against long asynchronous gaps, where the summary is right but the world has moved on.
- Evaluate consistency: ask the same question through all four adapters and diff the answers automatically.