Every AI Gets the Same Memory

The tab problem

I had four AI tools open most days. Claude Code on the desktop, ChatGPT in a browser tab, Manus running its own tasks, and whatever I was testing that week. Each one asked the same first question in a different way: what’s going on, what have you already decided, what’s the current state of things. I answered it four times. Every session started with me re-explaining myself.

That’s not a hypothetical inefficiency. I could point to the exact cost. A ticket would get resolved in one tool, and the next tool I opened had no idea it happened. An architectural decision made on Tuesday would get re-litigated on Thursday because the agent I was talking to never saw the note where I’d already settled it. I was the sync layer. Manually. Every time.

The vault already existed, it just wasn’t shared

I’d already built the fix for half the problem. I keep a single vault, git-tracked, edited interchangeably by hand in Obsidian and by Claude Code from the terminal. Dashboards render live state so I don’t have to recompute it every morning. Session manifests, ticket state, work logs, decision threads, all of it lives in one place with one folder structure everyone who touches it already understands.

The line in the vault’s own README says it plainly: vault is read by every station, and vault is the only place that is. Ticket state, station topology, cross-context decisions, all canonical there because nowhere else stays true across every machine I work from.

The problem was that “every station” meant my machines. Claude Code running locally could read the vault 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 was smart enough to reason well over context, but blind to the one place that context actually lived unless I fed it in by hand, copy-pasted, always a little stale by the time I pasted it.

Turning the vault into an endpoint

So I stopped treating “give the AI context” as a copy-paste problem and started treating it as an access problem. I built a small MCP server that sits in front of the vault, read-only, and exposes it the way any of these tools already knows how to consume: a set of MCP tools for reading and searching, not a raw filesystem mount.

Read-only was not a hedge, it was the design. I did not want an outside model able to reach in and rewrite my own operating notes. Sync goes one direction: vault out, 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 are not sitting on my local network, I put it behind a Tailscale funnel and gated it with per-client API keys rather than one shared secret. Each tool gets its own key, so if one client misbehaves or a key leaks, I revoke that one without taking the whole gateway down. I’m not publishing the funnel URL or the key names here. The pattern matters more than the specific endpoint, and the specific endpoint is exactly the kind of thing that shouldn’t be public.

What changed once all three could read it

Once the gateway was live, I pointed Claude Code, ChatGPT, and Manus at the same vault through the same MCP interface. Not a shared prompt. Not a shared document I pasted into each one. The same live, queryable source, read at request time, by three different products with three different interfaces and no relationship to each other except that they now agree on what’s true.

The difference showed up immediately in a way I hadn’t fully predicted. It wasn’t just that I stopped re-explaining myself. It was that disagreements between the tools stopped being about facts and started being about judgment. Before, if Claude and Manus gave me different answers, half the time it was because one of them had stale or missing context and was guessing. Now, if they disagree, it’s a real disagreement, both looking at the same dashboards, the same session manifests, the same work log, and reaching different conclusions. That’s a much more useful kind of disagreement to have. I can actually adjudicate it.

The dashboards do a lot of the heavy lifting here. They’re designed as cheap surveys on purpose, precomputed state instead of raw folders each tool would otherwise have to walk on its own. When any of the three clients hits the gateway, it’s not scanning years of session history to figure out where things stand. It’s reading the same rendered summary I read every morning, then drilling into a specific folder only if the task actually calls for it. That restraint was already baked into the vault’s structure for my own sake, so it came for free on the multi-agent side too.

The part I didn’t expect

I thought the win here would be convenience. Less pasting, faster starts. That part is true, but it’s the smaller part. The real shift is that I now think of my AI tools as clients of one system instead of three separate relationships I maintain in parallel. When I make a decision, I make it once, in the vault, and every tool that talks to me afterward inherits it without me doing anything else.

I still keep the gateway read-only and still keep keys scoped per client. Giving three different products write access to the one place I trust as ground truth is a different kind of risk than giving them read access, and I’m not ready to take that one on yet. Read-only got me most of the value with almost none of the downside. That’s usually the right trade to make first, and the write side can wait until I’ve actually earned the confidence to open it.

dxdev LESSON · paste into your AI coding agent
LESSON: Multiple AI tools stop disagreeing over stale context once they all read the same live source
SOURCE: dxdev.com/blog/2026-07-15_one-memory-many-ais
WHAT HAPPENED: Running four separate AI tools meant answering the same "what's going on" question four times by hand; a decision settled in one tool's session would get re-litigated by another that never saw the note, because a single git-tracked vault existed but was only reachable by whichever tool had the repo checked out locally. The fix was a small read-only MCP server in front of the vault, reachable from outside the local network through a tunnel and gated by per-client API keys rather than one shared secret, so a leaked or misbehaving key could be revoked without taking down the whole gateway. Once all three tools read through the same live gateway, disagreements between them stopped being about stale or missing facts and started being genuine disagreements in judgment over the same dashboards and session records, which is a disagreement worth having. Write access was deliberately withheld: anything an outside tool wanted to write back landed in a capture inbox for manual review rather than applying directly, because read-only access captured most of the value with almost none of the downside.
THE RULE: When multiple independent AI tools need the same operational context, give them a shared read-only endpoint over your one canonical source, gated by per-client credentials, rather than manually re-explaining state to each one. Disagreements between tools then reveal real differences in judgment instead of one tool simply having stale or missing context.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any operational context, a project's state, decisions, or history, manually re-explained or re-pasted into more than one AI tool rather than served from one shared, canonical source.
  2. Any external-facing read access to an internal data source protected by a single shared credential rather than per-client keys that can be individually revoked.
  3. Any AI tool given write access to a canonical source of truth without a review or quarantine step between the tool's proposed write and it actually landing.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.