Shared memory for a team of AI agents
Four people are on one client. Each runs Claude Code, most also run Cursor, one lives in ChatGPT. That is a dozen agents working on the same engagement, and not one of them knows anything the other eleven learned.
So somebody decided in a call on Monday that the export has to be CSV because the client's finance team lives in Excel. On Thursday a colleague's agent confidently proposes JSON, because to that agent the conversation on Monday never happened. Somebody notices, or nobody does and it ships.
This is usually filed under "we should document things better." It is not a documentation problem.
Why the handover doc keeps getting written
It gets written because the alternative — someone reading six weeks of Slack — is worse. And it goes stale immediately, because the moment it is written the work continues and nobody updates a document whose only reader has already read it.
The reason this cycle never breaks is that the knowledge is produced in conversations and stored in people's heads, and every attempt to fix it asks a human to do transcription work they have no incentive to do. The doc is a tax somebody pays once per new joiner.
Agents made this worse before they made it better. Every developer now has a tool that could hold this context perfectly — and each one holds a private copy, built from their own conversations, invisible to everyone else.
The structural problem: user_id
Look at how memory products model scope and the problem becomes obvious.
Mem0 — the most widely used — scopes memory as user_id / agent_id / run_id / app_id. Memory attaches to a user and follows them. ChatGPT's built-in
memory is the same idea: it learns about you. Both are excellent at what they
are for, which is personalisation.
But a memory keyed on user_id cannot be shared by adding a setting, any more
than a single-player game becomes multiplayer with a checkbox. If the primary
key is the person, then every fact in the store is a fact about or belonging
to that person, and there is no coherent answer to "what does this project
know" — only "what does Dana's assistant know", four times over, with no way to
reconcile them.
That is why nothing you can configure in a personal memory tool solves the Thursday problem.
What has to be true instead
Four things, and they are all consequences of making the project the unit rather than the person.
1. One memory per engagement, not per person. Everyone connects their own agent to the same store. Your colleague's Cursor and your Claude Code read the same facts because they are the project's facts, not yours.
2. It has to bind to something everyone shares. A folder path is on one laptop. The git remote is the same string on every machine and for every person, which is what lets a teammate's capture land in the same project instead of minting a second one. (Renames break this if you let them — a repository moved into an organisation has a new URL and the same project, and a system that does not handle that will quietly fork its own memory. We did this to ourselves in September, which is how we know.)
3. Nobody can be asked to maintain it. Any design where a human decides what
to record has already failed, for the same reason the handover doc fails. So has
any design where the agent is asked to decide — telling a model it may call
add_memory when something matters is advice, and a model under load ignores
advice. It has to be automatic: an event when a turn ends, and a server that
decides for itself whether anything durable happened.
4. It has to be reviewable, because it is shared. A private memory that is 70% right is an annoyance. A shared one that is 70% right is a liability — it is now wrong in four people's tools at once, authoritatively. So every fact needs to show where it came from and who it came from, and anything written automatically needs to be removable in one click by whoever spots it.
What this changes, concretely
- A new person on the engagement connects their agent and it already knows what was decided and why. No handover doc, because there is nothing to hand over.
- Someone rotates off and the project does not lose what they knew.
- A decision made in one tool is known in every other tool the next morning.
- Nobody has to be caught up, because being caught up is the default state.
Who this is actually for
If you work on one long-lived product with one team, the pain is real but mild — you are all in the same Slack and mostly know the same things.
It gets acute when you run several engagements at once: consultancies, agencies, forward-deployed teams. Then the context is not just missing, it is confusable. Working on one client from inside another client's checkout is routine, and a memory system that decides which project a fact belongs to by looking at your working directory will file it under the wrong one. We watched twelve facts about one client land in another's graph for exactly that reason; the fix was to route on what the sentence is about, not on where you happened to be sitting.
Trying it
Kika is the project-scoped kind. Two commands, free:
claude plugin marketplace add usekika/kika-plugin
claude plugin install kika@kika
Then /mcp, choose kika, approve in the browser. The first decision you make in
a repository creates the project automatically from its git remote — there is no
form to fill in — and anyone else on that repository connects to the same one.
How it decides what is worth keeping, and how it compares to Mem0 and Zep.