# Continuing one conversation on another channel

A channel change is not a new conversation. The address the person arrives on — a number, a mailbox, a WhatsApp handle — resolves to an Identity, the Identity resolves to a Person, and that Person's memory, stage, open follow-ups and deals are what Connect reasons with. The message thread stays per channel. The relationship does not.

- **Status:** Available
- **Audience:** both
- **In the app:** #/relationships, #/timeline, #/inbox
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/workflows/cross-channel-continuity/

## 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

| Stage | What you see | What changes | What can fail |
|---|---|---|---|
| Identity resolution | The caller or sender is named, not 'unknown' | An Identity row is attached to an existing Person | The address is new and unlinked, so a second Person is created |
| Context assembly | The reply references the earlier thread | Nothing is written yet | Budgets truncate the older material first |
| Autonomy | A reply sends, or waits in Needs You | An approval row, if the new channel asks | The new channel is `off`, so nothing is drafted at all |
| Timeline | Email and call interleaved under one person | Timeline rows, not a copy of the message | Two Person records, so two half-timelines |

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](/docs/relationships/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](/docs/troubleshooting/duplicate-not-detected/).
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.

> **Note** Merging is a human decision, never automatic. `duplicates` proposes; `merge_people` is run by a person and preserves identities, stages, follow-ups, deals, demos, cases and onboarding from both sides.

## 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

### Does replying on a new channel start a new thread?

Yes, and deliberately. Threads are provider objects: a WhatsApp conversation and a mail thread cannot be one row without lying about one of them. The join happens above them, on the Person and the timeline.

### If someone rings from a number nobody has recorded, is the history lost?

No — it is unattached. The call is captured against a new contact point, and the moment that number is added as an Identity or the two records are merged, the earlier history is in front of Connect again.

### Can memory left on one channel affect another?

Contact-tier memory can, because it is resolved for that Person on any channel. Channel-tier and endpoint-tier memory cannot: they describe one mailbox or one number and stop there.

## Related

- [One person across phone, email and WhatsApp](https://connectbyjbrh.com/docs/relationships/cross-channel-identity/)
- [Identities](https://connectbyjbrh.com/docs/relationships/identities/)
- [The customer timeline](https://connectbyjbrh.com/docs/relationships/timeline/)
- [Customer 360](https://connectbyjbrh.com/docs/relationships/customer-360/)
- [Why the machine proposes a merge and a person disposes](https://connectbyjbrh.com/research/one-person-many-channels/)
- [Two people were treated as one](https://connectbyjbrh.com/docs/troubleshooting/wrong-person-matched/)

## What this page is based on

- docs-source/sources/CHANNELS.md §5 — relationships and CRM
- docs-source/sources/GENERAL.md §3 and §6 — the data model and memory tiers
- Connect capability registry (docs-source/facts.py)