Unlocking Swarm Intelligence with Big Agentic Brain and Claude Code

Originally published at nevolin.be. Disclosure: I'm involved in building Big Agentic Brain, the open-source system tested here.

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

Model	No shared memory	With BAB	BAB + search-first nudge
Sonnet 5.5	12%	79%	100%
Haiku 5.5	0%	75%	88%
Opus 5.5	12%	88%	92%

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

Model	Teams	No memory	Local notes only	Local + shared BAB
Sonnet 5.5	4	67%	67%	100%
Haiku 5.5	8	8%	13%	96%
Opus 5.5	2 (exploratory)	33%	67%	100%

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)

Model	No memory	Local notes only	Local + shared BAB
Sonnet 5.5	$0.0427	$0.0408	$0.0363
Haiku 5.5	$0.00672	$0.00414	$0.00333
Opus 5.5	$0.1285	$0.0908	$0.0950

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.

Toolset	Tokens added per request	Cost per run vs no memory (Sonnet, team-knowledge tasks)
Full tool surface	8,598	1.51×
Lean (3 tools)	648	1.18×

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.