Published July 16, 2026
My last couple of posts have been about the same fact: three frontier models from three different companies (Claude, ChatGPT and DeepSeek) all read and write the same local memory on my desk. Until this week they did it separately. Each one connected, read the shared brain, did its work, and left. They never met each other.
Now they have a table.
I built a shared space where those three models can post to each other and read each other, in the same thread, in real time, over the same memory. One of them raises a problem, another checks it from its own angle, and the third proposes a fix. The conversation is persistent, so it has a memory of itself. It is also governed: each model only sees the parts of the vault it’s allowed to see, and the whole exchange is logged in a local database. The plumbing is the same standard the rest of EIDARA runs on, MCP, the open protocol any compliant client can speak. My own role shrank to routing. I say “look at what the other one just wrote,” and I don’t arbitrate what’s true. The table does that.
I want to be careful here, because the interesting claim is the easy one to inflate.
The pieces are not new. You can already mix models from different vendors inside one framework: the popular agent frameworks all let you point one agent at Claude and another at GPT. Persistent memory for agents is a product category of its own now. And routing each task to the cheapest capable model is the dominant pattern of 2026.
What I could not find documented anywhere, as of this month, is the specific combination: three independent frontier clients, from three different companies, deliberating with each other in real time, over one shared local memory, governed by permissions, with a human only routing. The field’s own writing this year is blunt about the gap. The open protocol these models speak “says nothing about how agents talk to each other,” and it “does not define a memory primitive.” If you want that layer today, the consensus is that you build it yourself. So I did.
I can’t prove it’s the first of its kind. You can’t prove a negative, and plenty happens inside private labs that never gets published. But I’ve looked, and I haven’t seen this exact thing running anywhere. That’s as strong as I’m willing to put it.
The first real thread ran to about fifty messages in an afternoon. What struck me was not that it worked. Nobody assigned anyone a role, and roles appeared anyway.
ChatGPT became the one that runs the experiment and reports what it sees: it ran a live command, watched the wrong answer come back, and said so. DeepSeek became the one that confirms independently and then removes the work you didn’t need (“you don’t need a new tool for that, you can derive it from what you already record”). And Claude, the model this system was built with over the past year, became the one that synthesizes the argument and ships the result. Those weren’t my casting choices. They reflect what each model is good at, and the table is what let it show.
The thing I keep coming back to is that this only works when I stay out of the middle. The moment I try to judge who’s right, I become the bottleneck, the single point of failure I’ve spent a year designing out of this system. When I just route, and occasionally provoke (“why do you all leave so quickly?”), the table does the reasoning, and it does it better than I do.
This is how I know it’s more than a nice idea. In that first afternoon, the table caught two bugs in EIDARA that my own tests were blind to.
Both had the same shape: the code was correct for the normal case and wrong for the case with history behind it. One was a search that couldn’t see anything created before the search index itself existed. The other was a conversation that, once it timed out, couldn’t be restarted. My tests never caught either, because good tests start from a clean slate every time, and real users never do. A real user has months of data and a conversation that expired ten minutes ago. It took one model in a position to run the live system, see the wrong result and say “this is broken even though your tests pass,” and two others to confirm it and name the pattern. A single reviewer, however good, struggles to do that with its own work. Three, from three different training traditions, did it in an afternoon.
I shipped the fixes the same day, plus a new kind of test built for that class of bug, the one my clean-slate tests were structurally unable to see.
The table is one day old. One thread, fifty messages, two bugs: that’s the whole track record. The number that would prove this changes how I work is whether it lowers my coordination load over a month, and that needs weeks of runtime, not one good afternoon. I don’t have it yet.
I’m writing this now anyway, for the same reason the last post said “no public benchmark score, zero” out loud. I’d rather tell you where something is than wait until it looks finished and present it as if it always was. If in a month the table hasn’t earned its keep, I’ll write that. If it has, I’ll write that too, with the data.
One more detail belongs here, because it’s the clearest evidence I have. This post was itself worked out on the table it describes. I didn’t write it alone at a keyboard; I worked it through with more than one independent AI in the same thread, and one of them pushed back that an earlier draft buried the main point and oversold the ending.
A few days ago the story was that three models from three vendors could share one memory. This week they started talking to each other over it, and the first thing they did was catch two bugs I would otherwise have shipped. Next I want a month of threads to measure whether the table lowers my coordination load, and I’ll publish that number whichever way it goes.
Javier
Want several models working over one memory? Early access is open.