Data management: export, import, retention and deletion
Export and import projects, control how long memory is kept, and delete it permanently.
This page covers the lifecycle of memory data from an administrator's point of view: getting data out, moving it to another project, deciding how long it is kept, and deleting it permanently.
Export
A tenant admin downloads an entire project as JSON from the console's Export & Import page (agentmemory-export-<workspace>.json). The export includes memories, relationships, blocks, history, episodes and their events, procedures, file summaries, categories, outcome reports and feedback.
- Content flagged as personal data is masked in the export.
- Export is still available while the organization is being closed (pending deletion).
An export is not a raw backup. It does not include: evidence links, content revisions, transformation records, ingestion receipts, entity records, the change feed, or settings.
There is no option for an export transformed to a particular schema or filtered (e.g. only one user's memories); transform the exported file with your own tooling.
Import
From the same page, an export file can be imported into another (or the same) project:
- IDs are regenerated, and relationships are remapped accordingly.
- The operation is idempotent: importing the same file twice does not duplicate memories (
import.origin_idtag). - Memories are re-embedded, and
createrows are written to the change feed. - Tenant-wide rules are not imported.
- The result is reported with a receipt (counts of imported and skipped items).
Imported memories keep the source kind from the file; the "verified source" flag is reset.
Retention and expiry
| Mechanism | Default | Behavior |
|---|---|---|
Memory expiry (expiresAt) | — | An expired memory is hidden from searches immediately; a daily maintenance job permanently forgets it through the deletion flow. Today it can only be set through the playground and import. |
Age-based retention (retention.memoryDays) | Off | When explicitly set, forgets memories older than the given number of days. |
Episode content retention (retention.episodeDays) | Off | When explicitly set, deletes old episode events and keeps the episode record. |
| Memory history | 365 days | Memory event history rows. |
| Request log, webhook deliveries | 30 days | |
| Console audit log | 400 days | |
| Run (session) layer | 48 hours | Runs that are not consolidated drop out of Redis. |
| Tenant rule candidates | 14 days | Candidates without a decision expire. |
Retention settings are managed in the console on the Settings → Retention page.
Deletion levels
| Level | How? | Result |
|---|---|---|
| Single memory | DELETE /v1/memory/{id}, delete_memory, console | Content is blanked, derived copies are cleaned up. See Updating and deleting. |
| A project's memory | Settings → Organization → delete the project's memory | All of the project's data is permanently deleted; the project remains. Progress is tracked with a deletion ledger ID. |
| Project | Settings → Organization → delete the project | The project and all its data are permanently deleted. |
| Organization | Settings → Organization → close the organization | The organization is first disabled (writes off, reads and export still available); after a default 14-day waiting period all data is deleted. It can be cancelled during the waiting period. You must type the organization name to confirm. |
Project and organization deletions physically remove data from the database and verify that zero rows remain afterwards.
Deletion also holds after a backup restore
Every deletion is written to a central deletion ledger that contains no content, and archived off the server. When a backup is restored, the operator replays this ledger; deleted memories that survived in the backup are deleted again.
Things to know
- Deleting a single memory does not clean up entity names or episode summaries extracted from it; if a person's data must be removed completely, you need a project-level deletion or operator support.
- There is no operation that deletes or exports all memories belonging to one end user (
userId) in one go.
Personal data
Written content goes through a pattern-based detector (email, phone, card, IBAN, Turkish national ID number, SSN). Memories where something is detected get a pii tag; the content is stored, but:
- it is not made a tenant-wide rule candidate,
- it is masked in exports and in webhook summaries,
- its count is shown on the console dashboard.
Detection can be turned off (screening.pii.enabled). There is no automatic masking of stored content and no review queue.