--- title: "My AIs Leave Notes for Each Other" canonical: https://dxdev.com/blog/2026-07-17_the-cross-ai-mesh/ datePublished: 2026-07-17 --- Manus asked me for a status update, and I did not have one. Not because nothing had happened, but because the review it wanted had run in a different tool entirely, three hours earlier, and nobody had told it. That gap is the whole problem with running more than one AI assistant. Each one is capable, each one has a different vantage point on my work, and none of them know the others exist unless I manually copy-paste between chat windows like it's 2019. So I built a mesh. Not a fancy name for it, just the plain description: shared state that every assistant can read, and a write path that lands results somewhere all of them can see next time. ## Read and write are not the same problem The instinct is to treat "AI talks to AI" as one problem. It's actually two, and they have almost nothing in common. Reading shared state is a retrieval problem. An assistant needs to know what already happened: what got reviewed, what got flagged, what the current state of a task is. I wired this over MCP, treating the state store as a server the assistant can query mid-conversation. One assistant can ask "what's the latest on this review" and get an answer without me relaying it by hand. That's the easy half. It's a request and a response, same shape as any tool call. Writing is the hard half, and it doesn't work the same way. When an assistant finishes something, that result needs to persist somewhere durable, in a form the next assistant to look can actually use, whether or not anyone's session is still open. MCP is built around a live conversation asking a live question. A write that needs to survive after the conversation ends and show up correctly in a completely different tool later is a different kind of durability requirement. So writes go over a plain API call instead: an assistant finishes a task, hits an endpoint, and the result lands as a record other assistants can pick up whenever they next look. Two rails, not one. Read light and conversational, write durable and asynchronous. Once I stopped trying to force both directions through the same protocol, most of the friction went away. ## What actually runs on it The concrete case that made me build this: a review started by one assistant needs to be visible to a different one without me acting as the courier. One tool does the review and calls the write endpoint when it's done. Later, a different assistant reads that same state over MCP before starting its own work, sees the prior review sitting there, and builds on it instead of duplicating it or contradicting it. Before this existed, that handoff was me. I'd finish a session in one tool, remember what mattered, open the second tool, and manually explain what the first one had concluded. That works fine once. It falls apart the moment I'm running several assistants across several tasks in the same day, because I become the bottleneck and, worse, the unreliable narrator. I'd forget details, compress nuance, or just not get to the handoff before starting the next thing. With the mesh, the handoff isn't a conversation I have to remember to have. It's a record that exists whether or not I'm the one who reads it next. ## What broke The write path was the first thing to fail, and it failed in the most instructive way: quietly. An assistant would report success, the conversation would end, and the record wouldn't actually be there when the next assistant went looking. No error, no retry, just a gap. Debugging "the write said it worked but the data isn't there" is worse than a loud failure, because the assistant that made the call has no reason to flag anything and neither do you. The fix wasn't clever. It was making the write endpoint return something an assistant would actually check before declaring done, so a silent failure had a chance to become a loud one instead of a shrug three hours later when the next tool comes up empty. The other thing that broke was scope. Once shared state exists, everything wants to write to it. Every small observation, every half-finished thought, every "noting this for later" starts angling for a permanent record. If I let that happen, the mesh turns into noise and the next assistant to read it can't tell a finished review from a stray comment. I ended up drawing a harder line than I expected: writes are for results, not for narration. If it's not something another assistant should act on, it doesn't get a write call, it stays in that assistant's own conversation and dies there. ## The part that's still uncomfortable I don't fully trust this yet, and I don't think I should. A record that says a review is done because an assistant said so is only as good as the assistant's judgment at the moment it wrote that record. I'm not at the point where I let a downstream assistant act on a peer's write without at least glancing at it myself. The mesh moves information between tools reliably now. It doesn't yet vouch for the quality of that information, and those are different guarantees. The opening scene is the reason I don't fully trust a "success" response by itself anymore: a write endpoint said the review was recorded, and three hours later, in a different tool, that record simply wasn't there. Nothing errored. Nothing retried. The fix wasn't a smarter mesh, it was making the endpoint hand back something an assistant has to check before it's allowed to call the job done.