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

Posted on Oct 29 • Originally published at contextforge.dev

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.

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

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.

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.

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

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.

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 Enter fullscreen mode Exit fullscreen mode 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.

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.