Agent Memory: What to Save, Where, and Who Reads It

Most writing on agent memory starts with a taxonomy: short-term, long-term, episodic, semantic. That is useful vocabulary, and our guide to AI memory layers covers it. This post starts somewhere else, with the question you actually face once an agent can write things down: what should it write, under what name, and who gets to read it back?

Get those three answers wrong and the agent's memory becomes a junk drawer. Get them right and you have a short list of files that every agent you run, in every tool, treats as the current truth.

Quick Answer

Agent memory works best as a small set of named, overwritable notes, not an ever-growing log. Save settled decisions and stable facts, give each one a predictable name, keep earlier versions in history, and put the notes somewhere every agent can read, not inside one tool's private memory.

Decision 1: What Should an Agent Write Down?

Agents are eager. Left alone with a save tool, they will record everything, and a store full of everything is nearly as unhelpful as a store of nothing, because retrieval has to wade through noise.

A useful test: would a different agent, next week, behave better for having read this?

Worth saving:

• Decisions that are settled. "We quote in GBP and invoice in the client's currency." "We don't offer custom contracts under a year."
• Stable facts the agent had to be told. Product naming, who owns which area, the tone of voice for customer replies.
• Outputs you will reuse. An approved brief, a finished competitor summary, a template that worked.
• Corrections. The moment you tell an agent "no, we never say it that way," that correction deserves a home.

Not worth saving:

• Transcripts of the conversation itself. The decision inside it is worth keeping; the back and forth is not.
• Anything still being debated. A half-formed opinion saved as fact gets retrieved as fact.
• Things that already live in a source of truth. If the answer is in your docs or your inbox, connect that source instead of copying it into a note that will drift from it.

That last point is the split most teams miss. There are two kinds of knowledge an agent needs: what your business already wrote down somewhere, and what your agents work out along the way. The first should be connected and kept in sync. The second is what memory is for.

Decision 2: How Should Memory Be Named?

A memory store with no naming discipline is unsearchable by anything except similarity, and similarity alone does not tell you which of three near-identical notes is the live one.

The pattern that holds up is one note per topic, named like a route: /pricing, /brand-voice, /support-escalation, /q4-priorities. In Context Link, a Memory is exactly this: ask an agent to save something to /pricing, and later ask it to update /pricing, and it is the same note rather than a second competing one.

Two consequences follow:

1. Agents can fetch by name, not just by search. When a task obviously needs the pricing rules, asking for /pricing is more reliable than hoping a semantic query surfaces the right paragraph.
2. Overwrite beats append. A note that is updated in place always reflects the latest decision. A log of appended entries forces every future reader to reconcile contradictions.

Keep names short, lowercase and boring. If two agents would reasonably guess different names for the same thing, you have two notes where you wanted one.

Decision 3: What Happens to the Old Version?

"Overwrite beats append" raises the obvious worry: what if the agent overwrites something good with something worse?

This is why memory should be version-controlled. In Context Link, when a Memory's content changes, the previous version is archived rather than deleted. It stays out of search, so retrieval only ever returns the current note, but it is there if you need to see what changed or restore it.

That gives you both properties you want: the live note is always the single current answer, and a bad update is a recoverable mistake instead of a silent loss.

Decision 4: Who Gets to Read It?

This is where most "memory for agents" setups quietly fail. If the memory lives inside one product, only agents inside that product benefit. The decision you made in a Claude session is invisible to the ChatGPT session your colleague runs an hour later.

Three scopes are worth separating:

Scope	What goes here	Who reads it
Private	Your working preferences, drafts, personal notes	Only you, across your own AI tools
Shared	Org-wide decisions, brand rules, pricing, process	Everyone in the organisation, in any tool
Source	What your docs, inboxes and sites already say	Everyone, kept in sync automatically

Context Link keeps a private Memory per user and an organisation-level one, so the first two rows are two stores rather than one pile. The third row is connected sources, which are searched together with the memory.

Because Context Link is reached through one MCP connector from Claude, ChatGPT and other MCP-aware agents, the same note is readable from all of them. An agent in one tool writes /pricing; an agent in another reads it.

What This Looks Like in Practice

Say you run a small agency and use a research agent, a drafting agent and a reporting agent, in different tools.

1. In a research session you decide the agency won't take on clients in a particular sector. You tell the agent: "Save this to /client-criteria."
2. A week later, a drafting agent in another tool is asked to write a proposal. Before it starts, it is told: "Get context on /client-criteria." It reads the current rule instead of guessing.
3. You change your mind and say: "Update /client-criteria to allow that sector with a minimum retainer." The earlier version moves into history. Every agent now reads the new rule.

Nothing in that flow depends on any single agent remembering anything. The memory is outside all of them.

Common Mistakes

• Saving too eagerly. Tell agents to save only when you explicitly ask, or you will inherit the junk drawer.
• Treating memory as a replacement for sources. Notes drift; documents are maintained. Connect the document.
• No naming convention. Pick routes before the first save, not after the fiftieth.
• Per-tool memory only. If it cannot be read from the other tools you use, it is a preference, not shared memory.

Frequently Asked Questions

What is agent memory?

Agent memory is information an AI agent can store and retrieve beyond a single conversation: decisions, facts and outputs that later sessions, and other agents, can read. It differs from the context window, which only holds what is in the current session.

Should an agent save everything automatically?

Usually not. Automatic saving fills the store with unreviewed notes that are later retrieved as if they were settled. A safer pattern is to have the agent save when you ask it to, to a named note.

Can different agents share the same memory?

Yes, if the memory lives outside any one tool. With Context Link, Claude, ChatGPT and other MCP-aware agents read and write the same Memories through one connector.

Is agent memory the same as RAG?

They solve different problems. RAG retrieves from content that already exists, such as documents, sites and inboxes. Agent memory holds what agents decide or produce along the way. In Context Link both are searched together. See RAG vs MCP for how the pieces fit.

What if an agent overwrites a memory with something wrong?

Context Link archives the previous version when a Memory changes, so an update can be reviewed and the earlier version restored.

The Short Version

Agent memory is a design problem more than a feature. Save settled decisions, not conversation. Name notes like routes and overwrite them in place. Keep history so mistakes are recoverable. And put the notes where every agent you use can read them.

To try it, connect Context Link to your AI tool and say "Save this to /your-first-note."