--- title: "Why We Stopped Pasting Stale Context Into Three Different Chat Windows" canonical: https://dxdev.com/blog/one-memory-many-ais/ datePublished: 2026-07-15 --- We had four AI tools open most days: Claude Code on the desktop, ChatGPT in a browser tab, Manus running its own tasks, and whatever we were testing that week. Each one opened with the same question in different words. What's going on, what have you already decided, what's the current state of things. We answered it four times, and every session started with us re-explaining ourselves. ## Where the cost showed up We could point to the exact cost. A ticket would get resolved in one tool, and the next tool we opened had no idea it happened. An architectural decision made on Tuesday got re-litigated on Thursday because the agent we were talking to never saw the note where we'd already settled it. We were the sync layer, by hand, every time. ## The archive already existed, it just wasn't shared We'd already built the fix for half the problem. We keep a single archive, git-tracked, edited interchangeably by hand and by Claude Code from the terminal. Dashboards render live state so we don't recompute it every morning. Session manifests, ticket state, work logs and decision threads all live in one place, with one folder structure everyone who touches it already understands. The archive's own README says it plainly: it is read by every station, and it is the only place that is. Ticket state, station topology and cross-context decisions are canonical there, because nowhere else stays true across every machine we work from. But "every station" meant our machines. Claude Code running locally could read the archive because it had the repo checked out. ChatGPT in a browser tab could not. Manus, running somewhere else entirely, could not. Each of those tools reasoned well over context, but none of them could see the one place the context lived unless we fed it in by hand. We copy-pasted, and what we pasted was always a little stale by the time it landed. ## Turning the archive into an endpoint So we stopped treating "give the AI context" as a copy-paste problem and started treating it as an access problem. We built a small MCP server that sits in front of the archive, read-only, and exposes it the way these tools already know how to consume: a set of MCP tools for reading and searching, not a raw filesystem mount. Read-only was deliberate. We did not want an outside model able to reach in and rewrite our own operating notes. Sync goes one direction, archive out and questions in. If something needs writing back, it lands in a capture inbox and gets swept into the real structure later, reviewed, never applied directly. To make it reachable from tools that aren't on our local network, we put it behind a Tailscale funnel and gated it with per-client API keys instead of one shared secret. Each tool gets its own key, so if one client misbehaves or a key leaks, we revoke that one without taking the whole gateway down. We aren't publishing the funnel URL or the key names here. ## What changed once all three could read it Once the gateway was live, we pointed Claude Code, ChatGPT and Manus at the same archive through the same MCP interface. No shared prompt, and no shared document pasted into each one. It was one live, queryable source, read at request time, by three products with three different interfaces and no relationship to each other except that they now agreed on what was true. The difference showed up immediately. We stopped re-explaining ourselves, and disagreements between the tools stopped being about facts. Before, if Claude and Manus gave us different answers, half the time one of them had stale or missing context and was guessing. Now, when they disagree, both are looking at the same dashboards, the same session manifests and the same work log, and reaching different conclusions. That is a much more useful disagreement to have, because we can actually adjudicate it. The dashboards do a lot of the heavy lifting. They're cheap surveys on purpose: precomputed state instead of raw folders each tool would have to walk on its own. When any of the three clients hits the gateway, it isn't scanning years of session history to figure out where things stand. It reads the same rendered summary we read every morning, then drills into a specific folder only if the task calls for it. That restraint was already baked into the archive's structure for our own sake, so it came for free on the multi-agent side. ## The part we didn't expect We thought the win would be convenience, less pasting and faster starts. That's true, but it's the smaller part. The bigger shift is that we now treat our AI tools as clients of one system instead of three separate relationships maintained in parallel. When we make a decision, we make it once, in the archive, and every tool that talks to us afterward inherits it. We still keep the gateway read-only and keys scoped per client. Giving three different products write access to the one place we trust as ground truth is a different kind of risk than read access, and we aren't ready to take that one on yet. Read-only got us most of the value with almost none of the downside. ## If you run several tools Give them all read access to one current source of notes instead of pasting context into each by hand. Start read-only, with a separate key per tool, so one misbehaving client or leaked key can be revoked without taking the rest down. Open write access only once you've earned the confidence to do so.