Skip to main content
Customer memory connects exact, verified identities to one Audience contact and maintains a compact conversation summary. A customer can therefore continue in another channel without repeating known preferences, agreements, or open items. Memory is available for supported voice, SMS, messaging, email, and helpdesk channels. Anonymous browser visitors and unverified contact details cannot read or update customer memory.

​
Identity safety

  • Verified phone numbers, email addresses, and channel identities are matched only within the current workspace.
  • Display names and transcript content are never used to merge contacts.
  • Conflicting identities are never merged automatically.
  • Business sender identities are not treated as the customer’s identity.
  • Email memory requires authenticated sender verification; the visible sender text or message body alone is not enough.
  • Anonymous browser calls and chats do not participate in cross-channel memory.

​
Configure the workspace

Open Workspace Settings → Data → Memory to enable memory, select allowed channels, require consent, and choose a rolling retention period. An assistant can narrow the workspace policy under Assistant → Settings → Privacy → Caller memory by selecting read channels, write channels, categories, and a scope. Retention and staleness are separate, independently configured settings. Retention decides how long a memory record exists at all — every successful update renews the rolling window, or you can choose to keep records until manually deleted; once retention lapses, the record is deleted. Staleness is optional and off by default: enable it and choose a number of days, and a profile with no call in that many days simply stops being injected into conversations, while the underlying record is kept — a later call refreshes it, so it doesn’t have to start over unless retention has also lapsed. Every read, write, consent change, skip, and deletion is audited. Audience → Memory lets workspace admins grant or withdraw consent and erase all shared and assistant-scoped memories for a contact.

​
API and MCP

  • GET/PATCH /api/v1/settings/memory manages the workspace’s allowed channels, consent policy, and retention period.
  • GET /api/v1/contacts/memory lists customer memories.
  • GET/PATCH/DELETE /api/v1/contacts/{id}/memory reads, updates, or erases a contact’s memory. An update must provide the current revision; a stale revision returns 409.
  • Assistant updates can define the memory scope, read and write channels, and allowed categories.
Equivalent MCP operations follow the same permissions and return the same customer-facing data as the REST API.
Only retain customer context with a lawful basis. Explicitly denied consent always prevents memory reads and writes. Unknown consent also blocks when the workspace requires consent.