Agent memory for coding agents

What agent memory is

Agent memory is durable context that survives a session: the fact that auth lives in src/auth/guard.ts, that this team prefers pnpm, that a migration replaced webpack with vite last month. Without it, every session re-discovers the same facts — slowly, and sometimes wrongly. With it, an agent starts already knowing the shape of your project and your preferences.

The harnesses converged on this fast. Claude Code layers static instructions (CLAUDE.md / AGENTS.md) with auto-memory — a per-project MEMORY.md the agent itself writes and reads every session. Cursor's index carries workspace context across chats. Devin checkpoints task state; Antigravity treats artifacts as memory.

The three places memory lives

• Harness-native. Best integration, zero portability: Claude Code's memory doesn't help Cursor, and vice versa. Summaries go stale when code moves, and you can't measure what the agent "remembers."
• Dedicated memory layers over MCP. Mem0, Zep, Letta expose memory as tools any MCP client can call — one store across Claude Code, Cursor, and CLI agents. Portability is the win; trust is the question: what got remembered, by whom, and can you see it?
• Local-first memory beside the index. Memory as just another retrieval problem — harvested as the agent works, recalled with the same hybrid engine as code, stored where you can read it.

The trust problem, and three properties that fix it

A memory that's wrong is worse than no memory — it poisons every session that trusts it. Three properties make memory trustworthy:

• Measured recall. If memory claims to be retrieval, it should be scored like retrieval — hybrid lexical + semantic fusion, not a keyword grep over a JSON file.
• Visible injections. When remembered context enters the prompt, it should appear in the evidence rail — which memories, at what recency — so a session that acted on a stale fact is debuggable like one that acted on a bad search.
• Explicit supersession. Facts change. A new memory should mark the old one superseded — out of recall, but kept on disk for audit. Prompt framing matters too: remembered context should always read as possibly stale, verify against current code.

How OCE does it

OCE ships a memory store beside the code index, wired the same way as everything else:

# the built-in agent harvests insights + preferences as it works
oce trace

# any MCP client gets the memory tools
claude mcp add oce -- oce mcp
#   → memory_remember / memory_recall / memory_forget

# read and manage it directly
oce memory list
oce memory add "the team prefers pnpm" --kind preference
oce memory search "how is auth done"

Recall is hybrid — lexical + embeddings fused, the same conviction as code search. Memories render as a Markdown twin (memories.md beside memories.json) that you can read, diff, and hand-edit. Secret-shaped content is refused at write time. Every injection shows in the evidence rail's context engineering view. Nothing leaves the machine, and MCP clients share the same store — Claude Code, Cursor, CI bots — without a hosted service in the middle.

Where the line is

Memory is not a knowledge graph, not a hosted service, and not a substitute for code search — it's the small, high-trust layer above it: facts, preferences, and decisions that make each session start smarter than the last one ended. If a "memory" is big enough to need its own ranking pipeline, it belongs in the index; if it's a fact small enough to state in one sentence, it belongs here.

Frequently asked questions