Reflection

One brain, three models.

Published July 10, 2026

The moment the thesis stopped being a thesis

In May, in a post about sharing agents, I wrote that agents are just markdown files: the logic of an assistant shouldn’t be trapped inside whichever vendor you happened to build it with. Any AI that reads the file becomes that agent, whether it’s Claude, GPT or DeepSeek. At the time that was a claim about the architecture of the project, not something I had proven across vendors in practice.

This week it stopped being a claim, and the proof came from shared memory rather than from more agents. Memory is the harder half. Three MCP clients, from three different places, are now reading and writing the same local brain, and the newest one comes from a different AI vendor entirely.

Three clients, three vendors

Until this week, EIDARA’s local brain was read and written by two MCP clients: a multi-model aggregator, and Anthropic’s Claude desktop app. This week I added a third, OpenAI’s Codex desktop app, with a GPT model behind it.

All three point at the same local MCP server. All three read the same compiled brain: 588 notes today, compiled into a single file of about 18,500 tokens that every assistant reads at the start of a session. All three write to the same inbox of facts. None of them had to be modified for another to join, and that was the goal. The aggregator already spoke to several models, so multi-model in itself wasn’t new. What’s new is that a client from one LLM vendor now connects to the same brain as a client from another, with no architectural friction between them.

How it connected

The mechanics were mundane, which is the best kind of milestone. Codex’s desktop app configures its MCP servers in a TOML file rather than the JSON that other clients use. The block is small:

[mcp_servers.DARA]
command = "uv"
args = ["run", "--script", "path/to/your/dara-server"]
startup_timeout_ms = 30000

One snag is worth writing down: the client has to be granted full local access before it’s allowed to launch a local process. Without that, Windows refuses to create the process and you get a flat “access denied.” Grant it, restart the app, open a new conversation, and the memory tools appear. Total time, including debugging the permission block, was about twenty minutes.

Why a standard protocol makes this possible

MCP is a standard, not one company’s product. When a server exposes tools, any client that respects the spec can use them. Anthropic published it, OpenAI adopted it, and the ecosystem is converging on it. EIDARA depends on none of them in particular. It depends on the standard.

The standard alone wasn’t what made this land cleanly, though. The structural work of the past few weeks had been building toward exactly this, even if I didn’t plan it that way:

• The confidentiality zones. The moment there’s more than one client, each one needs to see only its own scope. The vault is split into four zones (personal, business, shared, and system) and every client is scoped to a subset. Without zones, adding a client would mean total exposure. With them, a new client sees only what it should.
• The protocol for how a large model writes. The batch-and-calibrate rules I wrote a couple of weeks ago were written for any frontier model, not for one in particular. Any large model that reads them should honor them. This week was the first real test of that “any.”
• Per-client profiles. Each client gets its own scope and its own permissions. The OpenAI client starts read-only until I’ve watched how it behaves. The Anthropic client writes freely. Same server, different policies.

The consequence is the part I care about. The project’s memory is no longer tied to the model it was built with. If a model from one vendor is better for a given project tomorrow, I use it, and the memory stays. If another vendor’s model is better for a different project, same again. Working by project instead of by provider becomes viable in practice.

The first days with a GPT client

So far the connection has behaved well. The new client read the vault, ran queries, and returned answers consistent with what’s in the brain. I didn’t get the broken first-integration moment you brace for.

It has also been sending back useful feedback about EIDARA itself, such as proposals and comments on the shape of the context the server hands it, which I’m collecting as material for the next round.

I’m watching three things. First, that the write protocol is honored the same way from the new client as from the old ones; early signs say yes, but that’s a two-to-three-week confirmation, not a one-day one. Second, that when the new client starts writing, cross-model contradictions from differences in phrasing don’t spike; I have a proactive check ready to absorb them. Third, an internal maintenance backlog that has nothing to do with any client, which I want to drain before the active write volume doubles.

From shared agents to shared memory

In May, in that post about sharing agents, I wrote: any AI that reads it becomes that agent (Claude, GPT, DeepSeek, doesn’t matter). That was about agents. The same sentence now holds for memory: any model that connects to the same MCP server can share the same brain, whatever vendor built it.

Today that means one server, three clients from three vendors, and the same memory in the middle. The next step is letting the OpenAI client write, once the next two or three weeks confirm it follows the same protocol as the others.

What happened next is in two later posts: a few days after this, the three models audited EIDARA side by side, and then started talking to each other over the same memory.

Javier

---

See the full roadmap →