Shared Memory for Multiple AI Coding Agents (What They Already Share, and What They Don't)

This morning I watched two AI agents share a memory, and neither of them used the one I built.

I was testing ContextForge's setup with a brand-new account. I asked Claude to remember a test decision: use GraphQL instead of REST for the API layer. Claude tried to search ContextForge first, got an error back, shrugged, and wrote the decision to its own built-in memory file instead. A few minutes later I opened a second session in the same folder. It found the decision right away. "This was already in my local memory," it said.

So the two sessions did share a memory. It was a markdown file on my laptop.

The error was ours. On an empty account, our search returned an error instead of an empty answer, and the fix for it had been sitting in the repo since July without ever being deployed. New users whose agent searched before saving had been hitting that same wall ever since. I deployed the fix today, ran the same test again, and this time the second session saved the decision to ContextForge too. But the detour taught me more about shared memory for multiple AI coding agents than anything I'd written about it before, so this post is about that.

"Multiple agents" means four different things

When people say they want shared memory across agents, they usually mean one of these. They don't share the same things.

Setup	What they already share	What they don't
Subagents inside one session	Whatever the parent writes into each subagent's brief, and the results they hand back	Anything the parent didn't think to pass down
Two sessions of the same tool, same folder, same machine	The tool's built-in memory for that project (in Claude Code, a MEMORY.md folder per project)	What the other session is doing right now
Different tools on the same repo (Claude Code and Cursor, say)	Nothing, except the files in the repo	Every decision made in the other tool
Your agent and a teammate's agent	Nothing, except what's committed	Everything that lives in either person's tool or account

The first two rows are better than they were a year ago. Claude now keeps memory per project, Claude Code writes its own notes between sessions, and that's exactly what my second session picked up this morning. If you work alone, in one tool, on one machine, you may already have all the shared memory you need. I'd rather tell you that than sell you something.

The last two rows are where it falls apart. Built-in memory lives inside one tool and one account. It doesn't cross into Cursor, it doesn't reach your other laptop, and it never reaches the person you work with.

Where shared memory actually breaks

Running into this every day, I keep seeing the same three failures.

It crosses a boundary. The decision was made in Claude Code; the next change happens in Cursor. Or on the other machine. Or in your teammate's session. The new agent has never heard of it and confidently does the opposite. I wrote about that pattern in why AI coding agents contradict earlier decisions.

The reason gets dropped. Most notes record what was decided, not why. "Use GraphQL" survives; the reason behind it (say, "the mobile screens needed a dozen REST calls each") doesn't. Without the why, the next agent re-opens the question the first time it looks inconvenient.

The memory goes stale. Someone renames the file the note talks about. The note doesn't know. Now every agent that reads it is working from a map of a building that has been remodeled. Static files like CLAUDE.md have the same problem, just slower.

What a shared memory needs to do

After this morning, my list has four items instead of three.

1. One place every agent can reach. Not a file inside one tool's config. Something Claude Code, Cursor, Copilot and Claude Desktop can all read and write. That's what MCP is for: one memory server, any client that speaks the protocol.
2. Decisions with their reason attached. Save "API layer uses GraphQL because the mobile screens needed a dozen REST calls each," not "GraphQL."
3. A way to notice when the code moved. If a memory points at files, it should get flagged when those files change, so an agent confirms or corrects it instead of trusting it.
4. It has to work on day one, when it's empty. This is the one I learned today. When an agent has two memories available, it uses whichever one answers. If the shared one returns an error, or makes the agent work for an empty answer, the agent falls back to its private memory, and your "shared" memory never gets the first entry. A shared memory that fails on empty never stops being empty.

There's also a fifth thing that isn't memory at all: knowing what the other agents are doing right now. Memory is history. If two sessions are about to edit the same module this minute, you need presence, not recall. I wrote about that separately in One Developer, Five Terminals, Zero Awareness.

How I set it up

I build ContextForge, so this is the setup I use, with my bias stated up front. In Claude Code:

claude mcp add contextforge -s user -e CONTEXTFORGE_API_KEY=<your-key> -- npx -y contextforge-mcp
cd your-project && npx contextforge-mcp init

init links the folder to a project, so every agent working in that repo reads and writes the same memory, and it adds the rules that make sessions check who else is live before big changes. For Cursor, Copilot, Claude Desktop and Windsurf it's the same server added to that tool's MCP config; the setup page now walks you through each one, because "add this to your MCP config" turned out to be where people got stuck.

Then, when something worth keeping happens, say it plainly: "Save to ContextForge: we use GraphQL for the API layer because the mobile screens needed a dozen REST calls each." Naming the memory matters more than it should. Ask an assistant to "remember" something and it may reach for its built-in memory first, which is exactly what I watched happen this morning.

What it won't do

• It won't save things on its own judgment alone. Agents save what they're asked to, plus what they decide is worth keeping. A memory nobody writes to stays empty.
• It isn't a lock. Presence tells one session another is on the auth module; it doesn't stop it from going there.
• It doesn't replace reading the code. It tells the next agent what was decided and why. The code is still the truth for what is.

If you only ever run one tool on one machine, your built-in memory is probably enough, and you can skip all of this. If your agents cross tools, machines or people, they need one place to meet. Just make sure that place answers on day one.