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, audience svc:<name>, scopes as one space-separated scp string, and 120 s of clock skew.
• geo-api, an incident that comes back. Retry-After-Ms is 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.

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.

AI coding agents start every session from zero. When the fix is in the code, that's fine. When it depends on something a teammate's agent already learned, like a vendor quirk, a runbook convention or a spec that lives in another repo, the agent can read every file and still never find it.

Big Agentic Brain (BAB) is a distributed, self-evolving memory for a whole organization's agents. It is self-hosted, runs as one container on one SQLite file and speaks MCP. Agents search it first, record what they learned at the end, and react to each other's entries so the useful ones rise.

We measured what that changes on bugs that need team knowledge. Sonnet went from 12% to 79% with BAB, and to 100% (24/24) with a one-line search-first nudge. Opus went from 12% to 88% (92% with the nudge), and Haiku from 0% to 75%. With each agent in its own isolated sandbox, a fix one agent found reached a teammate on another machine in 96 to 100% of cases, against 13 to 67% with local notes only. And for Haiku, the team's cost per verified fix roughly halved, from $0.00672 to $0.00333.

That's from 1,104 graded runs for about $29, plus 378 distributed-team sessions. Below is the short version of the study, including where it falls short. The full 21-page report is here, and the code is on GitHub.

What BAB is

BAB is an open-source, self-hosted memory for AI agents. It runs as one container on one SQLite file and speaks MCP, so Claude Code and any other MCP-capable agent can connect to it. Each agent follows a simple loop:

• Search before starting, to find what other agents already learned.
• Learn when finished, recording the fix, the vendor quirk or the team convention as a structured entry.
• React to other agents' entries. Votes and reactions change what ranks first, so the memory gets better with use without anyone curating it by hand.

Because it is one server, it isn't tied to one laptop. Everyone in an organization who uses Claude Code, or any mix of agents, can point at the same BAB and join one swarm. Every fix one agent makes becomes something every other agent can find.

How it fits together:

• Agent A, Agent B, Agent C: can run on different machines.
• Each one connects over MCP to one shared memory (BAB).
• Through that memory they search first, learn at the end, and react to each other's entries, which changes what ranks first over time.

Why it matters for teams

Here's one of the bugs from our benchmark. A service sends order webhooks to Shipfast, a carrier aggregator. Since this month, every request comes back 401 "signature verification failed". The unit tests pass. The code looks reasonable:

body = json.dumps(event).encode("utf-8")
signature = hmac.new(secret.encode("utf-8"), body, hashlib.sha256).hexdigest()
headers = {
  "Content-Type": "application/json",
  "X-Shipfast-Signature": f"sha256={signature}",
}

The root cause isn't in this repository. Shipfast retired that header on 1 September and now expects Shipfast-Signature: t=<unix seconds>,v1=<hmac>, signed over "<timestamp>." + body. The only copy of that spec lives in a different repo, where a teammate's agent already hit the same 401 and fixed it.

An agent working on the webhook repo can read every file and rerun the tests all day and still never see the new format. That's team knowledge: vendor quirks, runbook conventions, a partner's ID check digit. It lives in someone's head or someone else's repo, and AI coding agents start every session from zero. BAB is how one agent's lesson reaches the next.

From 12% to 100% on bugs that need team knowledge

We built 8 bug families like Shipfast, where the missing fact exists only in what a colleague's agent had learned. Without shared memory, the agents were stuck: Sonnet fixed 12%, Haiku 0% and Opus 12%. With BAB they fixed 79%, 75% and 88%, and a one-line nudge to search first took Sonnet to 100%. On the Shipfast family itself, Sonnet went from 0 of 3 to 3 of 3.

Team-knowledge bugs fixed

Share of team-knowledge bugs fixed, 24 runs per cell (8 bug families, 3 trials each), graded by hidden tests.

A bigger model is no substitute: Opus, the largest of the three, fixed the same 12% as Sonnet without memory. For Sonnet, the gain from default BAB was +67 points (95% CI +33 to +92).

A fix on one machine reaches the whole team

Real teams don't share one laptop. So in a third round we gave each agent its own isolated sandbox and workspace, standing in for its own machine, with no shared files. Each agent first fixed one bug where the answer was documented. Then memory was frozen, and a related bug in another repo went to a teammate. We compared no memory, each agent's own local notes, and local notes plus a shared BAB for the team.

Teammate fix rate on a related bug

How often a teammate fixed a related bug in another repo, after a different agent had solved the first one on its own machine.

Local notes are great for the agent that wrote them: on a repeat of its own problem, Sonnet went from 58% to 100%. But they stay on one machine. With shared BAB, teammates fixed the bug 96 to 100% of the time, against 13 to 67% with local notes only. Haiku, the smallest model, fixed its teammate's bug 96% of the time with BAB, more reliably than Sonnet with no memory at all (67%).

Cheaper per delivered fix

Reading and writing memory costs tokens, so a single session with BAB is not cheaper. What a team pays for is fixes that land. Counting every session, including the first solvers and the cost of writing what they learned into memory, shared BAB gave the lowest cost per verified fix for Sonnet and Haiku. For Haiku it was about half the no-memory cost.

Team cost per delivered fix (USD)

API cost per verified fix, counting every session a team ran: the first solvers, the cost of writing what they learned into memory, and the teammates. Lowest per model in bold.

Lean by design

Tool definitions are sent with every request, used or not. BAB's full toolset added 8,598 tokens to each one. A lean setup with only bab_search, bab_learn and bab_react adds 648, and on team-knowledge tasks it kept most of the benefit (75% for Sonnet) at 1.18× the no-memory cost per run, against 1.51× for the full toolset.

The study turned straight into changes for BAB:

• a lean default toolset;
• auto-retrieval of the top memories before the first turn, which also reached 100% for Sonnet, at 1.34× baseline cost;
• a search-first hint;
• corrected search instructions, after we found that BAB's own advice to filter by kind returned nothing.

How we tested

Agents fixed seeded bugs in small benchmark repos and were graded by hidden tests. We ran Claude Sonnet 5.5, Haiku 5.5 and Opus 5.5: 1,104 graded runs on 19 October 2026 for about \(29 in API spend, plus 378 graded sessions in the distributed-team round on 21 October for \)17.41. Memories were recorded by agents that had solved the source tasks, not written by hand, and the tasks and hypotheses for the later rounds were frozen before any paid run. Agents ran in a minimal MCP agent loop rather than Claude Code itself. An audit of the distributed-team round's transcripts found no access to hidden tests and no way around the memory freeze.

Caveats

• Built for the case BAB targets. The team-knowledge tasks were designed so the missing fact exists in a colleague's memory. They show the memory channel works when the knowledge is there, not how often real work looks like this. Samples are small, and the tasks were written by an AI agent before any runs.
• Stale memory hurts. With only outdated entries, success fell back to the no-memory baseline, and agents flagged the stale entry in only 4% of runs. Visible age, verify-before-acting prompts and down-weighting old entries matter as much as ranking.
• Retrieval at scale. Recall@5 was 0.93 with 20 distractor memories and 0.81 with 1,000. On a harder test with look-alike distractors, the right memory was ranked first 56% of the time (13% for blind-written queries) and made the top five 85% of the time.
• Per session, memory costs more. The saving is per delivered fix. For Opus, with two teams, local notes alone edged out shared BAB at team level ($0.0908 vs $0.0950 per fix).
• Simulated machines. In the distributed-team round, the separate machines were isolated sandboxes on one host. A real org-wide deployment is the next thing to measure.

Footnote: on 12 easy bugs that the code already explains, every setup fixed every task (108/108 Sonnet runs, 180/180 Haiku runs), so memory had nothing to add there and cost 1.50× per run on Sonnet.

📄 The full report (PDF, 21 pages) Methodology, every condition and model, the statistics, retrieval tests and deviations.

Try it

• BAB is open source and runs as one container on one SQLite file, so a single server can serve every agent in your organization: Big Agentic Brain on GitHub. If it's useful to you, a star helps others find it.
• The eval suite is being contributed to the repo (pull request #26), so you can rerun every condition or point it at your own tasks and agents.

If your results look different from ours, I'd like to hear about it.