A field guide

AI coding agent memory, explained.

Every AI coding agent — Claude Code, Codex, Gemini CLI, Cursor — is brilliant inside a single session and amnesiac between them. “Agent memory” is the layer that fixes that: it captures what a session learned and makes it available to the next one, and to your other agents. This page explains what that actually means, the kinds of memory on offer, and how to pick an approach that keeps your code private.

See pricing Read the docs

The concept

Why agents forget in the first place.

An agent's working memory is its context window — the tokens it can see right now. When the session ends, that window is discarded. Most tools do write a transcript to disk (~/.claude/projects, ~/.codex/sessions, and so on), but they never read those files back on the next run. So the model that spent an hour learning your codebase yesterday starts today knowing nothing about it. That gap — between what was recorded and what gets reloaded — is the problem “agent memory” solves.

Persistent memory is not a bigger context window. It is a separate store that outlives any single conversation, that you can search, and that an agent can pull from on demand instead of holding everything in tokens at once.

What to compare

Four things that separate real memory from a bigger prompt.

Scope awareness

Good memory knows which repo, branch and worktree a decision belongs to, so a fix from one feature doesn't leak into another. Dumping a flat transcript into the prompt does the opposite.

Cross-agent reach

You rarely use one tool. Memory that only serves the agent that wrote it strands your context; memory that spans every agent lets a Claude Code decision reach Codex.

Where it lives

Cloud memory services store embeddings of your code on their servers and bill per token. A local-first store keeps everything on your machine and works offline.

How it connects

The cleanest integration is MCP: the agent calls a memory tool natively, with no wrapper or copy-paste, so recall happens in one round trip.

One approach

How Tramya implements it.

Tramya is a local companion that indexes the history your agents already write to disk, extracts decisions, touched files and errors, and serves them through an MCP server that every supported agent calls the same way. A session starts by querying get_project_context and ends by saving a durable decision with save_memory. The index is a SQLite database in ~/.tramya/; search runs offline, provenance is preserved, and an optional Cloud vault — encrypted on your device before upload — adds multi-machine and team sharing without ever sending plaintext.

Frequently asked questions

What is memory for an AI coding agent?

It is a persistent store, separate from the context window, that captures what a session learned — decisions, files, errors, conventions — and lets a later session or a different agent retrieve it on demand. Without it, each session starts from zero even though the transcript is sitting on disk.

Isn't a larger context window enough?

No. A bigger window helps within one conversation but is still discarded when the session ends, and you can't search it or share it with another agent. Persistent memory outlives the conversation and is retrieved selectively, which is cheaper and more precise than stuffing everything into tokens.

Does agent memory work across different tools?

It can, if the memory layer indexes every agent rather than one. Tramya reads the local history of Claude Code, Codex, Gemini CLI, Cursor and others into a single store, so a decision made in one is available to the rest over MCP.

Is my code exposed to a third party?

With a local-first approach, no. Tramya keeps its index on your machine and works offline; Cloud sync is opt-in and the vault is encrypted device-side before anything leaves.