> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vorel.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Memory and state
> The agent is stateful. It remembers a customer across every conversation, every channel and every data source you have connected, and it carries that state into every turn.
Most AI agents are stateless. Each conversation starts from nothing, the customer re-explains
themselves, and anything they said last week is gone.
**Vorel's agent is stateful.** One persistent state per customer, built from every conversation they
have ever had with you on any channel, plus everything your connected systems know about them. That
state is assembled and injected into every single turn.
This page is the mechanism.
## What "stateful" means here
A customer's history does not reset. What they asked in March is available in August, distilled
rather than replayed.
A phone call, a WhatsApp thread and a web chat are one customer with one memory. State belongs
to the person, not the channel.
Conversations, your CRM, bookings, cases, leads, consent records and outbound history all feed
the same state.
State is assembled at the start of a conversation and reaches every turn, including the first
one. The agent is never briefed late.
## The identity spine
State is useless if the agent cannot tell that two conversations are the same person. Identity is
the load-bearing part.
A customer record holds many identities, and any of them resolves to the same person:
| Identity | Comes from |
| -------------- | --------------------------------------------------------- |
| Phone number | Voice caller ID, WhatsApp |
| Email address | Email channel, CRM, anything the customer confirms |
| WhatsApp id | The WhatsApp channel |
| Instagram id | Instagram DM |
| Messenger id | Facebook Messenger |
| Web visitor | The chat widget |
| CRM contact id | Your CRM, which acts as the anchor where one is connected |
When a conversation starts on any channel, the incoming signal is resolved against these. A match
continues that customer's state. No match creates a record, which later merges when the person
gives you something that links them.
### Verified versus claimed
Only **verified** identities unlock cross-channel memory. A caller ID, a confirmed email, an exact
CRM match are verified. Something a customer merely typed is not.
This is a privacy gate, not a technicality. Without it, anyone who types a known customer's email
address into your web widget would be handed that customer's history. An unverified signal still
creates and enriches a record; it just does not open someone else's past.
Everything is workspace-scoped. Nothing learned about a person in one workspace is ever visible in
another.
## What the agent knows at the start of a conversation
State is assembled once when the conversation opens, cached, and injected into the prompt. It has
four layers.
Name, contact details, language preference, and the facts you already hold. Slots carry
provenance so the agent knows the difference between something confirmed and something inferred.
Distilled summaries of recent conversations, each carrying the intent, how it ended, open
threads left hanging, commitments made, and the outcome. Summaries rather than raw transcripts,
because replaying every past message into every prompt is slow, expensive, and worse.
Upcoming appointments and past no-shows, open cases and their history, current leads and how far
qualification got, consent status, and previous outbound contact.
Where a CRM is connected, the agent reads the contact back: full properties, notes, open deals,
open tickets. Not a five-field stub. This runs on every channel, not just voice, and is fetched
once per conversation rather than every turn.
## Memory facts
Underneath the summaries, the agent maintains **atomic facts** about a customer: one fact per thing
known, rather than a blob of prose.
Each fact carries:
* **A kind and a key**, so "allergy" and "preferred branch" are distinct, queryable things
* **Provenance**, on a ladder of `verified` > `claimed` > `inferred`
* **Its source**, the exact conversation and message it came from
### Facts supersede, they do not overwrite
When a customer's situation changes, the new fact supersedes the old one and the old row is kept,
marked superseded. It is never deleted.
A lower-provenance claim cannot overwrite a higher-provenance fact. If someone claims something that
contradicts a verified fact, the claim is stored already-superseded, as an audit row.
The result is a complete trail: what the agent believes, what it used to believe, what it rejected,
and why. You can see this as a graph on the customer's page, with fact nodes, conversation anchors,
supersession arrows and provenance badges.
## Recall on demand
Always-injected state is deliberately compact, because everything in the prompt costs latency on a
phone call.
For anything deeper, the agent has two recall tools it calls only when the conversation needs them:
| Tool | Searches |
| ------------------------- | --------------------------------------------------- |
| Recall past conversations | Distilled summaries, semantically |
| Recall customer memory | Atomic facts, semantically, with a lexical fallback |
Both are semantic, so "does he have any dietary requirements" finds a fact recorded as "allergic to
peanuts" without sharing a keyword. Because they are on-demand, a conversation that never needs deep
history pays nothing for it.
## Budgets and ranking
Context is finite, and a voice turn cannot afford to spend it all.
History is **relevance-ranked** rather than simply most-recent, and each channel gets its own budget.
A phone call runs on a tighter budget than an email thread, because the caller is waiting. Long
conversations are distilled mid-session so a two-hour thread does not slowly starve the agent of
room to think.
## Configuring it
Under **Settings, then Memory**, you control what state gets assembled:
* Which **dossier sections** are included: cases, appointments, qualification, summaries
* **How much history** and how many characters of it
* **Per-channel budgets**
Defaults are sensible. The main reason to change them is a workspace whose conversations are unusually
long, or one that wants the agent to lean harder on the CRM than on conversation history.
## Seeing what the agent sees
On any customer's page, the **Memory and context** section shows the actual assembled state: every
distilled summary, the provenance-ranked facts, the qualification rollup, the recall corpus, and the
dossier as it reaches the prompt.
When an agent says something surprising about a customer, this is where you find out why, and
[Explainability](/agent/explainability) shows what a specific turn retrieved.
## What it deliberately does not do
* **No cross-workspace memory.** Ever.
* **No memory unlocked by an unverified identity.** See the verification gate above.
* **No inference about protected characteristics.** The platform does not detect or store attributes
like gender from a voice.
* **No indefinite retention.** State is retained on the schedule in
[Data retention](/security/data-retention) and then purged. Your CRM is the long-term record,
which is why the agent writes what it learns back to it.
## Merging, correcting and erasing
Two records that turn out to be the same person can be merged from the customer view, and the merge
is recorded. Correcting a fact writes a new one and supersedes the old.
A customer can be erased on request: conversations tombstoned, message content redacted, details
cleared from leads and appointments. The audit trail keeps a salted hash rather than the raw
identifier, so the deletion stays provable without reintroducing the data. See
[Data handling](/security/data-handling).