Introducing Agent Memory: persistent, multi-tenant memory for AI agents

Most AI agents start every session from zero. They re-read the same files, ask the same questions and repeat mistakes they were already corrected on. Adding a vector store helps a little: you can retrieve text that looks similar to the question. But similarity is not memory. A vector store won't notice that a correction from last week overrides a decision from last month. It doesn't know which memories helped a run succeed. And it can't prove that a user's data was really deleted.

Today we're launching Agent Memory, a persistent memory layer for AI agents. It was built multi-tenant from the first schema, and its job is to let agents remember what matters, learn from what happened, and forget when they're asked to.

What it does

Agent Memory sits between your agents and your storage. Agents write what they learn while they work: decisions, corrections, violations, approved patterns, references to artifacts, and user preferences. When an agent needs context, it asks a question in natural language and gets back a single compiled context, sized to the token budget it sets.

Behind that one call are four kinds of memory:

Session memory: short-lived context for the current run, kept in Redis.
Workspace memory: durable facts, stored in PostgreSQL with pgvector.
Episodic memory: one record per run, with what happened and how it ended.
Procedural memory: learned how-tos distilled from successful runs.

A consolidation pipeline connects them. When a run ends, or goes idle, its session is distilled into an episode, promotable facts are extracted and stored, relationships between facts are inferred, contradictions are flagged, and the procedures behind successful runs are reinforced. A separate post covers the memory model in depth.

One contract, every surface

Agents reach for memory in different ways, so the same contract is available on five surfaces:

MCP, as a remote Streamable HTTP endpoint with OAuth discovery or a local stdio server, plus a Claude Code plugin.
The Node and Python SDKs, both packaged as agentmemory.
The .NET client, which implements the same IAgentMemory interface you can also host in-process.
The versioned /v1 HTTP API.

Here is the basic lifecycle in Node:

1import { AgentMemoryClient } from 'agentmemory'
2
3const memory = new AgentMemoryClient({ apiKey: KEY, baseUrl: API, workspaceId: WS })
4
5const { id } = await memory.add('Alex is vegetarian', {
6  userId: 'alex', runId: 'run-1', sourceKind: 'user', idempotencyKey: 'note-42',
7})
8const context = await memory.search('what can Alex eat?', { userId: 'alex', runId: 'run-1' })
9await memory.outcome({ runId: 'run-1', buildSuccess: true, receiptId: context.receiptId })
10const { status } = await memory.delete(id)   // 'deleted' | 'pending' | 'blocked' | ...

The surfaces aren't kept in sync by hand. A parity scenario runs the same remember, recall and forget lifecycle over REST, MCP and the .NET client in the integration suite, and through the Node and Python SDKs against a live API in CI. It also uses two keys bound to different agents and checks that one agent never sees or deletes the other's private memory.

Design choices we care about

Identity comes from the credential. You don't send an agent id. Each API key is bound to one or more agents, and the bound agent is the one acting. userId names the person a memory is about, not the caller. As a result, a request body cannot impersonate another agent.

Recall comes with a receipt. Every search returns a receiptId that names exactly what was delivered. When you report a run's outcome or feedback against that receipt, the memories that were actually used are credited or penalized. This feedback loop is how memory improves over time, rather than just piling up.

Truth changes over time. Memories are bi-temporal: they record when a fact was true and when it was recorded. A correction can supersede an earlier decision, and superseded facts are hidden from recall unless you ask for them. You can also query what was known as of a given date.

Every memory can explain itself. Each memory records its source, extraction method and model, its lineage, and what replaced it. Passing explain=true on a recall returns the ranking breakdown.

Forgetting is a first-class operation. A delete redacts the memory immediately, then removes the copies derived from it. You can poll an erasure status until it reads complete. If other live memories depend on the one being deleted, the delete is blocked and returns their ids, unless you explicitly ask for a cascade.

Isolation in the database

Agent Memory is organized as tenant → workspace → application → run. Isolation is enforced by Postgres itself. Every tenant table uses forced row-level security keyed to a transaction-local tenant setting, and the application connects as a role that cannot bypass RLS. If a query runs without a tenant context, it returns zero rows. A third launch post walks through how this works.

Benchmarks, honestly reported

We measured recall quality with LongMemEval. On the full LongMemEval_S set of 500 questions, with GPT-4o as the answerer and the official evaluate_qa.py script and GPT-4o judge, Agent Memory scored 83.8% QA accuracy (95% confidence interval 80.6–87.0%). The oracle ceiling on the same setup was 90.4%, and session-level Recall@40 was 0.995. An earlier 50-question subset scored about four points higher. We publish the full-set number because the subset was the one we iterated against. The methodology and the deviations from defaults are documented next to the results.

Deployment

The managed service runs on Microsoft Azure in the EU. A tenant can live in the shared schema protected by RLS, or on a dedicated database. For environments where data can't leave the building, a reference air-gapped profile runs Postgres, Redis, a local OpenAI-compatible model server and the Agent Memory hosts with no outbound network.

Get started

The Hobby plan is free and includes 50,000 operations a month. New workspaces start with a 14-day Pro trial. Create an account, follow the quickstart, and connect your agent over MCP or an SDK. If you're evaluating Agent Memory for a larger deployment, talk to us.