Long-term memory for AI coding agents

Coding agents are good at the task in front of them, but durable context is still fragmented. This page explains what agent memory is, where native host memory helps, and what to look for when context needs to follow you across tools.

A model reasons over a context window — a finite buffer of tokens. When a session ends, that buffer is discarded. Some coding agents now persist selected context in their own native memory files or stores. That is a real improvement, but the memory is generally scoped to that host and project. A decision learned in Claude Code does not automatically follow you into Codex, Cursor, or OpenCode, and each host applies its own lifecycle and controls.

The remaining problem is therefore not simply persistence. It is portability, provenance, and selective recall across tools without loading an entire history into every new context window.

Agent memory is an external layer that runs a loop: capture → recall → consolidation. Capture reads what happened and writes down what is worth keeping. Recall surfaces the relevant subset at the start of, or during, a later session. Consolidation dedups and reconciles facts so the store stays coherent over time.

This is distinct from a bigger context window. A larger window lets the model see more at once; memory lets durable facts outlive the window and return only when they are relevant — without paying to re-load the whole history every time.

Memory systems mostly fall into two camps, and both are reasonable choices depending on what you value.

A cloud memory database keeps your memories in a hosted store. The service handles persistence, indexing, and retrieval; you read and write through its API. This centralizes operations and can scale across machines and teams without local setup.

A local-first vault keeps memory as files on your own machine — typically Markdown you can open, edit, and move. Retrieval runs against a local index. This keeps the data under your control and portable, at the cost of running the index locally.

Whichever architecture you pick, a few properties separate a memory layer you can trust from one you cannot:

• Data ownership and portability. Can you read, edit, and move your memory, or is it locked inside a proprietary store?
• Recall quality. Hybrid retrieval — keyword (BM25) plus semantic (vector) search — generally beats either alone for surfacing the right fact.
• Non-lossiness. Originals should be retained. Summarization that throws away the source text is hard to audit and impossible to recover.
• Secret handling. Automated writes should redact recognized tokens, keys, and credentials before storage, while making the limits of pattern-based redaction clear.

agentcairn is local-first. Memory is distilled into a local Markdown vault that is the source of truth — not a one-way export from a database. A rebuildable DuckDB index gives fast hybrid retrieval (BM25 + vector, fused with RRF, with an optional reranker). The index is a cache; the Markdown is the truth, so it survives model upgrades, index rebuilds, and uninstalling the tool.

It works across coding agents: Claude Code and Codex as plugins, OpenCode and Hermes through native integrations, and Cursor plus other MCP hosts via the bundled server. They resolve the same configured vault, which defaults to ~/agentcairn.

Import Claude Code auto-memory · AI memory in Obsidian · How agentcairn compares