Shared Memory for Multiple AI Coding Agents (What They Already Share, and What They Don't) A developer at ContextForge tested shared memory across AI coding agents and found that two Claude Code sessions on the same machine already share project memory through a local MEMORY.md file, while different tools, machines, and teammates share nothing beyond committed repo files. The test also surfaced a bug where ContextForge's search returned an error instead of an empty result on new accounts, a fix that had sat undeployed since July and was shipped after the test. The developer argues shared memory breaks down across tool, machine, and teammate boundaries, and that notes typically lose the reasoning behind decisions and go stale as files change. 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. | 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. 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 https://contextforge.dev/blog/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 https://contextforge.dev/blog/why-claude-md-goes-stale , 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 https://contextforge.dev/blog/one-developer-five-terminals-zero-awareness . I build ContextForge https://contextforge.dev , 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=