Memory Several Agents Can Share
On Monday you start a second agent on the same project, in a different CLI, from a different vendor. You ask it why the middleware call was moved behind the queue, and it has no idea. The first agent knows. It has known for three weeks, it will still know tomorrow, and there is no way for it to hand that over. What it learned went wherever its own runtime keeps such things and nowhere else. Nothing broke and nothing was lost. The knowledge was filed under the tool that produced it rather than the project it was about, and a project outlives its tools.
Seed outlives the grower who selected it
For most of farming history a grower kept his own seed. The best heads off the best plants went into a jar in his own barn, and thirty seasons of patient selection ended when the farm did. A village seed store changes who the seed belongs to. Everyone puts in, everyone takes out, and a packet works in any soil, behind any tractor, in hands that never met the person who filled it.
A shared memory service is that store. Several coding agents, on different runtimes, save and query through one endpoint, reached over MCP, a hook, or a plain API. The service keeps the records, indexes them, and serves them to whichever compatible agent asks next. An agent running in Codex writes down why the middleware was chosen; a Claude Code agent, in the session after, asks the same endpoint and gets the reasoning back.
Then there is the packet you can carry. Once a codebase has been indexed, that structural index can be compacted into a file and committed beside the code. Whoever clones the repository loads the snapshot and indexes only what differs locally, so an agent can ask about symbols almost at once instead of paying for the whole reconstruction. Wikis and reviewed skills travel the same way: a team publishes a release procedure, and the agent assigned to the deploy loads it when the session opens.
A packet carries whatever was in it
A store serving everyone has to know who is asking. Run one namespace for everything and two problems arrive together, one irritating and one serious. The irritating one is that queries come back full of material from projects nobody asked about. The serious one is that a decision recorded inside one client’s repository is now reachable by an agent working for another, and nothing in the retrieval path was ever asked to care. This is why the useful unit is an asset with an owner, a visibility and a version, rather than a row in a common pile.
Review is the other half. A packet that goes into the store untested goes out to everybody, and a memory that is private, half-finished or simply wrong now propagates at the speed of the service instead of dying with the session that produced it. Sharing raises the value of what is true and the cost of what is not, in the same motion. So the question stops being how much your agent may remember and becomes what it may write where others will read it unsupervised — which is a narrower thing to grant, and much easier to grant safely.
Nobody regrows it and it stops coming up
Two things keep a shared store worth querying. One is that it can be searched both ways. Asked about a deploy that went wrong, the semantic side finds the report that reads closest to the question, and the explicit relations carry you from there to the rollback decision and the service it touched. Neither route reaches that on its own. The other is that those relations are claims, not settled truth: they came from somewhere, they can be stale, and what agents learn afterwards should be allowed to reweight them. A snapshot committed once and never regenerated is the same failure in slower motion, an agent reasoning carefully about a repository that no longer exists.
Get that right and the project’s experience stops depending on which runtime you happened to pick, which is what makes that choice revisable rather than permanent. As soon as there are two agents, memory stops being something an agent has. It is something the project keeps.