​

Agent memory administration

Three complementary surfaces cover agent memory: the memory plane explains how retrieval works inside a live turn, Customer Memory covers the tenant-wide curation browser (/agents/memory), and this page covers the per-agent Conversation Memory administration console — the one place you manage one agent’s record of one contact. Open it under AI Agents → Agents → pick an agent → Memory, at /agents/:id/memory. (Older bookmarks for /ai/memory redirect into the canonical AI-hub routes, so deep links keep working.)

​

What the page is for

One agent accumulates per-contact facts across every channel its conversations touch. This console answers two operator questions fast:

• “What does this agent know about this customer?” — pick a contact, and every fact that agent holds on them lists as a row.
• “Fix it.” — forget an inaccurate fact, teach a correct one, or erase the contact’s whole memory footprint on a data-subject (DSAR) request.

Facts group by contact, one section per contact, instead of a paginated grid — the mental model is the customer, not a table.

​

Picking a contact

Paste a contact ID (cnt_…) into the Contact ID field and press Load (or hit Enter). Deep links from elsewhere in the dashboard carry ?contact=<id>, and the field honours the plain cnt_… prefix form — no URL-encoded string required. Two hints keep ambiguous states honest:

• Pending-load notice — if you change the typed ID after loading, a notice tells you the rows on screen still describe the previously loaded contact until you press Load again.
• Load without an ID — the button refuses and asks for an ID first, instead of silently no-oping.

Once a contact is loaded, a Search facts box narrows the rows inline (client-side, no re-fetch), and a Refresh button re-pulls from the server.

​

Viewing facts

Each row shows the fact text, its type badge, the capture date, and an importance score. A row in the raw list never shows contact identifiers beyond the ID you loaded. Only fact-type entries list here — summaries, preferences, and goals also live in the plane, but the administration console narrows to factual recall; the tenant-wide browser (next section) pages over all four types if you need a wider sweep.

​

Masking and revealing PII

Fact content arrives masked by default. The Reveal PII / Mask PII toggle unmasks it for the loaded view — available only to owner, admin, or developer roles, and every reveal writes an audit entry naming who unmasked what. Use it in the minimum window you need, then mask again. The same role-and-reveal contract holds on the public API.

​

Operator vs supervisor roles

The page is gated to owner, admin, and developer — because it can expose raw, conversation-derived facts and supports bulk erasure. Viewer-tier roles still get read-only access through the memory tab on the agent detail page. That split matches the server’s role checks on the underlying endpoints, so an operator can’t widen their reach by opening the console.

​

Curating facts

• Forget a fact — the per-row delete action removes that one entry after a confirmation. The agent no longer recalls it on future turns. Audit-logged.
• Teach a fact — the Teach a fact button opens a dialog for one short fact (up to 10,000 characters) about the loaded contact. The agent incorporates it immediately, the same as a fact it extracted from a conversation. Audit-logged.
• Forget all (DSAR) — the contact header’s Forget all action erases every memory point this tenant holds on the contact — across every agent, not only this one — and flips the contact’s memory consent off (memory_enabled = false), closing the race where a live conversation would write a new fact right after the wipe. It confirms before running and it audit-logs. This is the GDPR right-to-erasure path.

An erased contact shows the Memory disabled for this contact state instead of rows, and further teaches are blocked until consent is re-enabled from the contact’s profile. If you erase and then type a different contact ID, the console suppresses the stale “opted out” warning until the new contact loads — so it doesn’t imply the freshly typed contact is opted out too.

​

Scope of an action

Memory is scoped per contact, and retrieval is layered on top of that: the tenant always scopes first, then the contact and unified identity, and optionally one agent or one conversation narrows further. Pick the console that matches what you want to change:

​

How memory affects grounding

On every new turn the runtime resolves the contact, retrieves their top-scoring entries, and attaches them as one system-level block. The previous turn’s block is stripped before the fresh one attaches, so memory never accumulates across a conversation; whatever you forget or teach changes what the agent grounds on for the very next turn, not a lagging pipeline. Deleting a fact removes it from context immediately; teaching a new fact makes it available immediately; a contact-wide Forget all plus consent-off leaves future turns with no memory block at all.

​

Retention and redaction

Retention is controlled, not unbounded:

• Importance scores (0–1) let the system evict low-value entries when a contact’s plane nears its budget — operator-authored facts land high by default so they outlive auto-extracted noise.
• Per-contact caps bound fact growth, and past the cap the API rejects new facts with a 422 rather than growing silently.
• Masking is the default view, and the runtime only ever attaches the current, curated plane — so redaction is a curation action (forget/erase), not a post-hoc scrub.

​

Next steps

• Memory plane — resolution, retrieval, and rendering inside a turn, and the Profile-API read path.
• Customer Memory — the tenant-wide curation browser.
• Audit log — find every reveal and erasure entry.