Picture three engineers on three laptops. Each runs a coding agent, and each agent keeps tidy notes about what it learned. One of them spends an afternoon discovering that a geocoding service sends Retry-After-Ms in milliseconds and that a 503 means "quota exhausted, stop retrying". Two weeks later, a teammate's agent hits the same suspended API key in a different repo, and those tidy notes are sitting on the wrong laptop.
That gap is what I wanted to measure. In my first write-up on shared team memory for coding agents, every agent talked to one memory on one machine. Real teams are distributed, so the obvious objection was fair: maybe an agent's own local memory already gets most of the benefit, and a shared layer is overhead.
The setup simulated a small distributed team
I'm involved with Big Agentic Brain (BAB), an open-source, self-hosted shared memory for agents that speaks MCP, so any MCP-compatible coding agent can search it and write to it. Because I have a stake in it, the hypotheses and analysis code for this round were frozen before any paid run.
Each simulated team had three agents, each in its own sandbox with no shared filesystem. I built three "walls" a team can hit, each spread across two repos:
- Paylane, a vendor API quirk. Amounts must be minor-unit strings using ISO 4217 exponents, rounded half-up, with a lowercase currency code, so JPY has no minor unit and KWD has three decimals.
-
Gatekeeper, an internal auth convention. Tokens need issuer
https://gatekeeper.internal, audiencesvc:<name>, scopes as one space-separatedscpstring, and 120 s of clock skew. -
geo-api, an incident that comes back.
Retry-After-Msis in milliseconds with a default of 1000, retries stop after three attempts, and a 503 means quota, so it is never retried.
First, every agent fixed a bug in a repo where the rule was documented. Then memory was frozen, and a related bug in a second repo went either back to the same agent or to a teammate who had worked on something else. The second repo never states the rule, although it contains a log of 64 to 70 recorded requests from which a patient agent could work it out.
I compared three setups: no memory, local-only memory where each agent keeps its own notes, and local memory plus a shared BAB for the team. The metrics I cared about were cost per verified fix and time to a verified fix, with hidden tests deciding what counts as fixed and every failure counted at the 900 s cap. The round covered 378 graded sessions on Claude Sonnet 5.5, Haiku 5.5 and Opus 5.5 and cost $17.41 in total.
Local memory is excellent when the same agent hits the same wall
The first result is good news for anyone already giving their agent a notes file. When the repeat bug went back to the agent that had solved the first one, Sonnet's fix rate went from 58% with no memory to 100% with its own notes, and its cost per fix fell from $0.0692 to $0.0427.
Haiku, the smallest model, showed the effect more sharply. Its fix rate on the repeat problem went from 21% to 96%, and its median time to a verified fix dropped from the 900 s cap, meaning most attempts never got there, to 17.5 s.
Local notes stop helping the moment the bug lands on a teammate's machine
The picture changed when the related bug went to a different agent. With local-only memory, Sonnet fixed 67% of these teammate cases, which is exactly what it managed with no memory at all. Haiku fixed 13% and Opus 67%.
In this distributed round, with the shared BAB in place, the teammate fix rate was 100% for Sonnet and Opus and 96% for Haiku. The result that surprised me most is that the cheapest model with a shared memory delivered fixes more reliably than the mid-size model with no memory.
The pre-registered check that "an agent's own memory does not help a teammate" held for all three models. Local memory cost the teammate about the same as no memory, with Sonnet at a ratio of 1.109 and Opus at 1.008. That sounds obvious when written down, but it is the core argument for a shared layer: knowledge that lives on one laptop behaves like no knowledge for everyone else.
Team cost per fix is where the shared layer pays for itself
Per-agent numbers hide the cost of writing memories in the first place, so I also counted all nine sessions per team, including the first solvers and their extra effort to record what they learned.
| Model (teams) | Team cost per fix: none | local only | local + shared |
|---|---|---|---|
| Sonnet 5.5 (4) | $0.0427 | $0.0408 | $0.0363 |
| Haiku 5.5 (8) | $0.00672 | $0.00414 | $0.00333 |
| Opus 5.5 (2, exploratory) | $0.1285 | $0.0908 | $0.0950 |
For Haiku, shared memory roughly halved the team's cost per delivered fix compared with no memory, and the full ordering of shared, then local, then none was significant across eight teams. For Sonnet the shared layer came out about 15% cheaper per fix than no memory, and the shared-versus-local difference was significant even with only four teams.
The honest part is that shared memory is not free
Opus broke the pattern. Local-only memory edged out the shared setup at team level, $0.0908 against $0.0950 per fix, although with two teams nothing in that comparison is significant. The reason shows up in the same-agent sessions: when an agent already has the answer in its own notes, also querying the shared memory costs Haiku about 26% and Opus about 23% more per session than local memory alone.
One use case also carries much of the gap. No model ever solved geo-api without the relevant memory, while Sonnet and Opus mostly solved Paylane and Gatekeeper cold, where memory moved cost by 10 to 20% rather than deciding whether the fix landed. Rules that can be guessed from general knowledge benefit less; incident knowledge that contradicts reasonable defaults benefits most.
There are further limits worth stating plainly. The three use cases are synthetic, each agent had only one earlier session, and Sonnet ran with four teams after a machine restart cost me the original eight-team run. The agent loop was my own minimal MCP loop rather than a commercial coding agent, and a real agent might load its local notes more cheaply.
What I take from this
Local memory and shared memory solve different problems. A notes file is the right tool when the same agent will hit the same wall again, and it is cheap and effective at that. A shared memory is the right tool when the next person to hit the wall is a teammate, which in a team of more than one is most of the time.
If I were setting this up for a team today, I would keep each agent's local notes, add a shared layer for the knowledge that crosses repos and people, and keep the shared tool surface small so that the overhead on routine work stays low.
Try it or check the work
BAB is open source and runs as one container on one SQLite file: github.com/enhesa/big-agentic-brain. It works with any MCP-compatible agent. The eval suite for the earlier rounds is being contributed in pull request #26, and the full report (PDF) covers the earlier rounds in detail.
If your team has run something similar and seen different numbers, I would like to hear about it.
Originally published on nevolin.be.
Top comments (0)