← All posts
April 25, 2026 · 7 min read · By Mnemonic Team

The Developer's Guide to Governed AI Memory

What governed AI memory actually looks like in code

This is a technical post. If you want the business case for AI memory governance, read Why AI Memory Without Governance Is a Ticking Time Bomb first.

Here we're going to look at how Mnemonic works as an AI memory API — what the code looks like, what the architecture looks like, and specifically what is different about a governed memory layer versus bare vector stores or tools like Mem0 and Zep.

The core primitives

Mnemonic's API has three primary operations: remember, recall, and forget.

remember — write a memory

const { Mnemonic } = require('@mnemonic/sdk');

const client = new Mnemonic({ apiKey: process.env.MNEMONIC_API_KEY });


await client.remember({   agent: 'support-bot',   tenant: 'acme-corp',   fact: 'User prefers email contact, not phone. Contact: user@example.com',   retention: '90d',          // TTL: auto-delete after 90 days   access: ['support', 'success'],  // which agent roles can read this   metadata: {     source: 'conversation',     session_id: 'sess_abc123'   } });

What happens before anything is written:

  1. PII scan runs. The email address is detected and redacted. What gets stored: "User prefers email contact, not phone. Contact: [EMAIL_REDACTED]."
  2. Redaction event is logged. Type: EMAIL. Agent: support-bot. Tenant: acme-corp. Timestamp: now.
  3. TTL is set. 90 days from write time. Enforced at the infrastructure layer — no cron job required.
  4. Access policy is stored with the memory. Only agents with role "support" or "success" can retrieve this.
  5. Write audit record is created. Who wrote, when, from what session.
  6. Memory is stored. Embedded and indexed.

The developer wrote one API call. The governance layer handled everything else.

recall — retrieve memories

const memories = await client.recall({
  agent: 'support-bot',
  tenant: 'acme-corp',
  query: 'How does this user prefer to be contacted?',
  limit: 5
});

// memories[0] = { //   fact: "User prefers email contact, not phone. Contact: [EMAIL_REDACTED].", //   score: 0.94, //   created_at: "2026-04-01T10:23:00Z", //   expires_at: "2026-07-01T10:23:00Z", //   id: "mem_xyz789" // }

What happens before any memory is returned:

  1. Agent identity is verified. API key → agent role → access policy check.
  2. Tenant isolation is enforced. Only memories scoped to "acme-corp" are searched.
  3. Access boundary is checked. Only memories the requesting agent is permitted to read are candidates.
  4. Read audit record is created. Which memories were returned, to which agent, at what time.
  5. Expired memories are excluded. TTL enforcement at query time, not just at cleanup time.

The 5 memories returned are exactly the memories this agent is permitted to see, from this tenant, that have not expired.

forget — delete a memory

await client.forget({
  tenant: 'acme-corp',
  memory_id: 'mem_xyz789',
  reason: 'user_erasure_request'  // GDPR Article 17 compliance
});

What happens:

  1. Deletion is authenticated. Must be an admin-scoped key or match the original writing agent.
  2. Memory is deleted from all storage layers (vector store, metadata store).
  3. Deletion is logged immutably. Reason, timestamp, requesting agent, memory ID. Cannot be overwritten.
  4. Proof of deletion is available. The audit record is your evidence for right-to-erasure compliance.

How this differs from Mem0, Zep, and bare vector stores

Bare vector stores (Pinecone, Weaviate, pgvector)

Bare vector stores are great databases. They are not memory infrastructure for AI agents in regulated environments.

| Capability | pgvector / Pinecone | Mnemonic | |-----------|---------------------|---------| | TTL enforcement | Manual (cron jobs) | Automatic (infrastructure layer) | | PII redaction | None | Pre-storage, typed detection | | Access control | API key only (all-or-nothing) | Per-memory, per-agent-role policies | | Audit logging | None | Every read/write/delete | | Tenant isolation | Namespace by convention | Hard isolation by architecture | | GDPR deletion | Manual query + delete | forget() with immutable proof |

Mem0

Mem0 is a developer-friendly memory layer with intelligent extraction. Its value proposition is making memory easy to add. Governance is not part of its value proposition.

  • No retention policies — memories persist indefinitely by default.
  • No PII redaction pipeline — what you store is what stays.
  • No audit log — there is no record of who accessed what.
  • No access scoping — any Mem0 API key retrieves any memory.

For consumer applications where none of that matters, Mem0 is a reasonable choice. For regulated environments, it is not.

Zep

Zep focuses on long-term memory for conversational AI. It has more structure than bare vector stores — session management, dialog history, knowledge graph extraction.

  • Zep CE (open-source): No retention policy enforcement, no audit logging, no PII handling. You own all of that.
  • Zep Cloud: More mature, but governance primitives (audit logs, retention enforcement, access policies) are not the core product. They are add-ons or assumptions left to the developer.

The pattern with both Mem0 and Zep: memory is the core, governance is your problem.

In Mnemonic: governance is the core. Memory is how it works.

The retention policy model

Retention in Mnemonic works at three levels, in order of precedence:

1. Memory-level TTL — set at write time.

await client.remember({ ..., retention: '30d' });  // expires in 30 days
await client.remember({ ..., retention: '1y' });   // expires in 1 year
await client.remember({ ..., retention: 'session' });  // expires when session ends

2. Agent-level default TTL — configured on the agent definition.

// Agent configured with default 90-day retention
// Any memory written by this agent inherits 90d unless overridden

3. Tenant-level maximum TTL — hard ceiling set by the platform admin.

// Tenant configured with maximum 365-day retention
// No memory in this tenant can persist longer than 365 days, regardless of agent or memory-level settings

This tiered model means a developer can set per-memory TTLs for fine-grained control, but the compliance team can set guardrails at the tenant level that cannot be overridden by individual agent implementations.

The audit log structure

Every memory operation generates an audit event. The structure:

{
  "event_id": "evt_abc123",
  "event_type": "memory.write",
  "tenant_id": "acme-corp",
  "agent_id": "support-bot",
  "memory_id": "mem_xyz789",
  "timestamp": "2026-04-15T14:23:11Z",
  "redactions": [
    { "type": "EMAIL", "field_position": 52 }
  ],
  "metadata": {
    "source": "conversation",
    "session_id": "sess_abc123"
  }
}

For recalls:

{
  "event_type": "memory.read",
  "agent_id": "support-bot",
  "query_hash": "sha256:...",
  "memories_returned": ["mem_xyz789", "mem_def456"],
  "access_policy_checked": true,
  "expired_excluded": 0
}

The audit log is:

  • Immutable — events cannot be deleted or modified via the API
  • Queryable — filter by tenant, agent, event type, time range
  • Exportable — for compliance reporting and auditor review

Multi-tenant architecture

Mnemonic enforces tenant isolation at the storage layer, not the application layer.

Each tenant's memories are stored in isolation. There is no query path that can return memories from a different tenant. The isolation is an architectural invariant — it does not depend on developers correctly passing the right tenant ID every time.

For SaaS companies building on top of Mnemonic:

// Correct: tenant is passed explicitly on every operation
await client.remember({ tenant: req.user.organization_id, ... });
await client.recall({ tenant: req.user.organization_id, ... });

// The platform ensures organization B cannot retrieve organization A's memories // even if a developer made an error in their tenant ID logic

The isolation check happens at the API gateway level. Mismatched tenant IDs fail fast with a 403.

Getting started

Mnemonic is available now. The free tier covers up to 10,000 memory operations per month.

npm install @mnemonic/sdk

const { Mnemonic } = require('@mnemonic/sdk');

const client = new Mnemonic({   apiKey: process.env.MNEMONIC_API_KEY });


// Governance is on by default. await client.remember({   agent: 'my-first-agent',   tenant: 'my-org',   fact: 'User is an early adopter. Signed up in April 2026.',   retention: '1y' });

Every operation from this point is governed: PII-scanned, TTL-enforced, access-controlled, and audit-logged.

Further reading

Ready to govern your AI memory?

Mnemonic gives your AI agents persistent memory with PII redaction, audit logging, and retention policies built in — not bolted on.

Start for free → Read the docs