> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Agent memory administration

> Operate your agents' conversation memory from the dashboard: inspect per-contact facts, mask or reveal PII, teach facts manually, forget single entries, and run DSAR-grade erasure — with the right role for each action.

# Agent memory administration

Three complementary surfaces cover agent memory: the [memory plane](/agents/memory-plane) explains how retrieval works inside a live turn, [Customer Memory](/guides/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:

| Action                                                         | Surface                                                                  |
| -------------------------------------------------------------- | ------------------------------------------------------------------------ |
| Recall one contact for **this agent**                          | This page (`/agents/:id/memory`)                                         |
| Curate across every agent / teach a manual fact on any contact | [Customer Memory browser](/guides/customer-memory) (`/agents/memory`)    |
| Remove one contact entirely (DSAR)                             | **Forget all** here — scope deliberately spans all agents                |
| Empty an organisation's plane on offboarding                   | Tenant-level erasure endpoint (see [memory plane](/agents/memory-plane)) |

## 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](/agents/memory-plane) — resolution, retrieval, and rendering inside a turn, and the Profile-API read path.
* [Customer Memory](/guides/customer-memory) — the tenant-wide curation browser.
* [Audit log](/guides/audit-log) — find every reveal and erasure entry.