# Continuing a WhatsApp conversation

A WhatsApp exchange is one canonical thread against one Person, so the next message is read with everything before it in view. Beyond the thread, Connect carries the relationship record, memory at four tiers and the workspace's Knowledge. A long gap does not erase any of that — but it closes Meta's 24-hour window, which changes what may be sent, not what is known.

- **Status:** Available
- **Audience:** both
- **Channels:** whatsapp
- **In the app:** #/whatsapp, #/inbox, #/timeline
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/whatsapp/conversation-continuity/

## Three different kinds of continuity

| Layer | What it holds | Survives a long gap? |
|---|---|---|
| The thread | The messages themselves, in order, on one conversation | Yes |
| The relationship | The Person, their identities, stage, cases and deals | Yes |
| Memory | Durable directions and facts at workspace, channel, endpoint and contact tiers | Yes |
| Knowledge | Sources the workspace supplies that answers are grounded in | Yes — it is not per conversation at all |
| Meta's 24-hour window | Permission to send a free-form message | No — this is what a gap actually closes |

Conflating the last row with the first four is the most common misunderstanding about this channel. Connect does not forget a customer because they went quiet for a month. What it loses is the right to write to them without a template, and that is Meta's rule — `window_open` measures 24 hours from the last inbound message and is consulted before every send, so the refusal happens locally rather than as a rejected network call.

Imported history is the exception that proves the rule. When a QR-linked number shares up to 180 days of the handset's own chats, those messages are stored as already handled and deliberately do not open a window: Meta opens one only for messages that arrive after onboarding, and treating old history as an invitation would produce a refused send at best.

## What the engine reads before answering

Every reply is composed against a budget rather than against everything that exists, because a model given an unbounded history answers slowly and no better. Knowledge contributes a bounded extract, memory a bounded set of directions, and the contact block a short summary of who this is. The thread supplies the recent turns.

The consequence is worth stating plainly: something said forty messages ago is not guaranteed to be in the reply's view, while something recorded as a memory is. If a fact matters permanently — a delivery address, a language preference, a person who must always be copied — put it in [Memory](/docs/memory/) rather than trusting the transcript to carry it.

> **Note** Memory resolves narrowest-first across workspace, channel, endpoint and contact, and an empty tier is returned rather than dropped. "Nothing is set for this contact" is a visible answer, not a blank.

## When a conversation should not continue

Continuity is not always the right behaviour. Several states deliberately break it. A block directive on the contact stops Connect writing to that person on this channel — it lives in the memory row's tags, which is what makes it hold across future conversations rather than just this one. A STOP reply sets `opted_out` on the conversation as well. A suppression or do-not-contact entry stops outbound traffic regardless of thread. And an autonomy mode of `off` means the channel receives and answers nothing.

Each conversation also carries its own controls, independent of the workspace policy: automation set to follow the policy, to answer automatically, to write drafts only, or to be off; pause and resume; take over, which hands the thread to a person; and a language and standing instructions that apply to this thread alone. `whatsapp_engine` checks all of them before any model is asked, so a paused conversation costs nothing to leave paused.

On a QR-linked number one of those controls is pulled by somebody else. When a reply is typed in the WhatsApp Business app it arrives as an echo, and Connect reads that as a takeover: the conversation is marked paused with the business app named as the person holding it, and stays that way until it is resumed. Two authors answering the same customer at once is the failure this prevents.

In each case the inbound message is still recorded. Connect keeps hearing a person it may not write to, because losing the message would be worse than not answering it.

## Continuing somewhere else

Because the Person is shared across channels, a conversation that starts on WhatsApp can be answered by email or a call and still be one history. The thread does not move — a WhatsApp thread stays a WhatsApp thread — but the relationship timeline shows both, and the reply on the second channel is written knowing about the first.

[Continuing on a different channel](/docs/workflows/cross-channel-handover/) walks through what that looks like as a flow, including the case people find surprising: the customer sees two separate conversations even though Connect sees one relationship.

## Questions

### How far back does Connect read on a long WhatsApp thread?

Recent turns plus bounded extracts of knowledge, memory and the contact summary. The exact size is tuned for reply speed, so the reliable way to make something persist is a memory entry, not a longer chat.

### If a customer returns after six months, does Connect remember them?

Yes — the Person, the history and every memory are still there, and the reply reflects them. Whether Connect may write first after that gap is a separate question, answered by Meta's 24-hour window and, outside it, by whether an approved template fits.

### Does starting a new thread reset anything?

Nothing durable. Memory, knowledge and the relationship are not stored on the thread. A new thread is a new conversation, not a new customer.

## Related

- [WhatsApp in Connect](https://connectbyjbrh.com/docs/whatsapp/)
- [Recognising who sent a WhatsApp message](https://connectbyjbrh.com/docs/whatsapp/person-resolution/)
- [Replying on WhatsApp](https://connectbyjbrh.com/docs/whatsapp/replying/)
- [What WhatsApp cannot do here](https://connectbyjbrh.com/docs/whatsapp/whatsapp-limits/)
- [Memory in Connect](https://connectbyjbrh.com/docs/memory/)
- [Continuing on a different channel](https://connectbyjbrh.com/docs/workflows/cross-channel-handover/)
- [Relationship memory versus chat history](https://connectbyjbrh.com/research/relationship-memory/)

## What this page is based on

- `backend/app/whatsapp.py` — `window_open`, `_import_history`, `_store_echoes`, `update_conversation`
- `backend/app/whatsapp_engine.py` — what stops a reply, checked before any model is asked
- `docs-source/sources/GENERAL.md` §6 — memory tiers and `directives()`
- Connect capability registry (docs-source/facts.py) — `memory_tiers`, `block_directive`