Continuing one conversation on another channel

The chain, stage by stage#

Nothing about continuity is special-cased per channel. Every inbound arrival runs the same chain, and continuity is what happens at stage five when the canonical record already exists.

1. Trigger — a person who is already known writes or rings on a channel they have not used before.
2. User or external event — a provider webhook, a mail fetch or a carrier answer URL delivers the arrival.
3. Authentication and workspace resolution — the workspace is entered before any record is read; a lookup made outside it finds nothing rather than finding somebody else's.
4. Ingest — the provider's shape is normalised into the canonical threads / messages / contacts rows the engine reads.
5. Canonical record — value_key(kind, value) turns the arriving address into an Identity key, and that key already points at a Person. No second Person is created.
6. Reasoning — the model is given the relationship, not the channel: who this is, what stage they are at, what was promised.
7. Knowledge, memory and rules — memory resolves narrowest-first through workspace → channel → endpoint → contact, so a note left against the contact applies whichever channel they used.
8. Autonomy and approval — the autonomy mode of the *new* channel governs the reply, not the mode of the channel the relationship started on.
9. Action through a provider — the reply goes out on the channel the person used, through the same send boundary a human's own send uses.
10. Result — the outbound is recorded against the new channel's thread with the provider's own acknowledgement.
11. Relationship, timeline and memory — both channels' events land on one timeline under one Person, in time order.
12. Audit, usage and Needs You — the decision log records which rule applied on the new channel; anything held appears in Needs You.

What you see and what moves underneath#

The context handed to the model is budgeted, and the budget is small on purpose — roughly 700 characters of memory, about 600 for the contact block, and around 2,000 characters and four facts from Knowledge. On a live call every character of instruction is paid for in first-token time, so continuity means the *salient* history rather than all of it. A person who wants everything reads the timeline, which is not budgeted.

What carries across, and what stays behind#

Carries: identity

Every Identity on the Person, including the one that has just arrived.

Carries: memory and standing instructions

Contact-tier memory beats channel-tier memory, so a direction given about this person holds on the new channel.

Carries: commitments

Open follow-ups, deals and cases belong to the Person, so the new conversation knows what was promised.

Carries: a block

A block is a connect_memory row tagged block:<channel> rather than a column, which is precisely why it survives a channel change.

Stays behind: the thread

Threads are per channel. A call is not appended to an email thread, and quoting an email into a WhatsApp reply is a decision, not a default.

Stays behind: autonomy

Autonomy resolves per channel. Approving replies on email says nothing about what voice may do.

Stays behind: provider state

Read receipts, labels and delivery evidence belong to the channel that produced them.

Where continuity breaks#

Two failures account for most of it, and they look identical from the outside — the reply reads as though nobody had ever spoken to this person before.

1. The arriving address is not an Identity yet. A person who has only ever emailed rings from a mobile Connect has never seen. There is nothing dishonest about the resulting record: it is a genuinely new contact point. Attach it, or merge, and the history returns.
2. Two Person records already exist. The duplicate was never proposed or never merged, so each channel has half a history. See an obvious duplicate was not suggested.
3. The new channel is off or draft-only. Continuity worked; the reply is being withheld by an autonomy rule, which is a different problem with a different fix.

Confirming it actually worked#

1. Open the person from #/relationships and count the Identities.

   Result The address they have just used is listed there. If it is not, resolution did not happen — a merge or an added identity is the fix.

2. Open the timeline and look for both channels in one column.

   Result An interleaved timeline proves one Person owns both conversations.

3. Read the decision log entry for the new reply.

   Result It names the rule that applied on the new channel. A refusal is recorded here too, because a refusal is a decision.

Questions#

Related#

• One person across phone, email and WhatsApp
• Identities
• The customer timeline
• Customer 360
• Why the machine proposes a merge and a person disposes
• Two people were treated as one