Caller memory
Caller memory
Caller memory lets your agents remember the people they talk to across calls. When a known caller dials in again, the agent already knows who they are and what happened last time — so it can greet them by name, skip questions it has already asked, and pick up where the last conversation left off.
It is enabled per agent, but the stored memory is shared across your organization's agents — a caller recognized by your support agent is also recognized by your sales agent (so long as that agent also has memory enabled). Whether memory is recalled or written for a given call is decided by the answering agent's own enable flag at call time.
Memory is keyed by the person's identity, normalized to a stable key:
- Phone calls — the person's phone number, whichever side of the call they were on: on an inbound call that's the number that dialed you (
from); on an outbound call it's the number your agent dialed (to). The number is normalized to digits only (the+is dropped), so the same human keys the same memory in both directions — your agent can call a lead today and recognize them when they call back tomorrow. - Browser / API web calls — the trusted
identifieryou supply when starting the call (lowercased to a stable key). Anonymous web calls with no identifier never build or recall memory.
Each call's Summary shows whether caller memory was recalled into the conversation (the Caller memory row).
Enable it
In the agent builder, open the Analysis step and turn on caller memory. You can set a retention window (TTL) in days — how long a caller's memory is kept and used before it expires. The default is 90 days (configurable from 1 to 3650).
This is saved on the agent as metadata.callerMemory = { enabled, ttlDays }.
Enablement is checked on the answering agent at call time: if you turn memory off, agents stop using it immediately, even while old rows wait out their TTL.
What's remembered
After each call, Telenow distills the conversation into a compact memory for that caller:
- A rolling summary — prose covering who the caller is and what's happened across their calls.
- A facts ledger — structured key/value details worth keeping (e.g. name, account number, preferences).
- Call count and the last session id.
How it's captured and used
- Capture — a background worker processes finished calls roughly every 45 seconds (looking back a couple of hours) and merges each call into the caller's memory: it distills the transcript with the platform LLM, merges with any prior memory (newer facts win, transient chatter is dropped), and writes it. It never blocks the call. The capture is metered as a paid feature like analysis.
- Recall — at the start of a call, if the answering agent currently has memory enabled and the caller's identity is known, the stored summary and facts are injected into the agent's context. The agent uses them naturally and won't re-ask details it already has. Disabling memory on an agent stops recall immediately, even while old rows wait out their TTL.
Caller memory needs a stable identity. Phone calls use the person's number automatically. Browser web calls use the trusted
identifieryou pass when starting the call (see caller identity); anonymous web calls with no identifier don't build or use memory.
Privacy & control
Memory is personal data — treat it accordingly.
- View — the Agent → Analysis tab lists recent caller memories for the organization (caller, summary, facts, call count, last seen, expiry).
- Erase — remove a single caller's memory on demand (for GDPR / DPDP "right to be forgotten" requests).
- Expiry — memories past their TTL are no longer injected.
| Method | Path | Purpose |
|---|---|---|
GET | /api/agents/{id}/analysis/memory | List recent caller memories (org-shared) |
DELETE | /api/agents/{id}/analysis/memory?caller={number} | Erase one caller's memory |
Both are dashboard routes (org-scoped session auth, { success, data } envelope). The list is org-wide — the {id} only scopes the request to the agent's organization, since storage is shared across the org. For the erase call, pass the caller's number (or identifier) as it was used on the call; Telenow normalizes it to the stored key (digits only for numbers), so formatting and the leading + don't matter.
Troubleshooting
- Agent doesn't recognize a returning caller — confirm the answering agent has memory enabled, that the earlier call actually had a transcript, and (for web/API calls) that you passed the same
identifier. Anonymous web callers are never remembered. - A web caller isn't remembered across calls — you must pass a stable
identifieron each init request; without one there's no key to store against. - Memory looks stale — capture runs after the call ends (~45 s) and merges; if a fact changed mid-call it lands once the call completes.
Related
- Post-call analysis — structured analytics per call (configured on the same Analysis step).
- Compliance — handling caller PII, retention, and right-to-be-forgotten requests.
- Data protection, GDPR & DPA — retention, export and erasure of caller data.
- Context variables — pass known values into a call from your own systems (complementary to memory, which is learned from past calls).
- Building agents — the Analysis step where both are turned on.
API
/api/orgs/{orgId}/memory
User JWT + X-Org-Id.
| Method | Path | Purpose |
|---|---|---|
GET | / | Recent caller memories — the transparency view |
DELETE | /?caller={number} | Erase one caller's memory |
Any org member may read; erase is membership-gated (the dashboard surfaces it to admins). DELETE is the endpoint to wire a GDPR / DPDP erasure request to.
Storage is org-keyed, but the switch is per agent. Enabling memory and its retention live on the agent (metadata.callerMemory — see Agent field reference), while the stored memories belong to the organization. That is why a caller recognised by one memory-enabled agent is recognised by the others, and why erasing here erases them everywhere rather than per agent.