From 12% to 38%: How a Graph Turned Claude Subagents Into a Team

Please go through it entirely 🫠

Every time I ask Claude to handle several tasks at once, it does something impressive. It spawns subagents, gives each one a piece of the work, and hands me back a neat summary.

But when those subagents work on different features of the same project, the summary hides a problem. Their changes overlap. One edits a file another depends on. Two touch the same imports. So I end up reading both outputs and merging them myself, or spinning up a third agent whose only job is cleaning up after the first two.

I wasn't delegating anymore. I was reviewing and merging.

Why this matters now

We're moving into a world of autonomous agents: agents that plan, split work, and run without a human watching every step. Multi-agent systems are how serious work is starting to get done.

But the way we coordinate them today, with a lead agent handing out tasks and reading back summaries, wasn't designed for helpers that work at the same time, on the same thing. If every parallel run needs a human or a third agent to merge it, it isn't really autonomous.

And I’m lazy enough to hate that extra verification work, so I started researching.

What the research says

Researchers studying multi-agent systems keep reaching the same conclusion:

• Anthropic studied agents working together and concluded: "Coordination doesn't naturally emerge from stronger intelligence nor alignment at the individual level." [1]
• Berkeley researchers (MAST) analyzed over 1,600 traces from 7 popular multi-agent frameworks. They found that "performance gains on popular benchmarks are often minimal," and catalogued 14 failure modes in three groups, one of them inter-agent misalignment. [2]
• In real projects, a study of over 142,000 pull requests made by AI coding agents found a 27.67% merge-conflict rate. [3]

The idea that changed my direction came from Anthropic's own write-up. Their agents worked through "a shared forum and self-hosted repository,"(basically a space where they can discuss and buildup on) and they suggest that "a central forum in which agents can agree on best practices and protocols" could help. [1] Claude Code's agent teams follow the same thinking. Team lead spawns teammates. They share a task list of work items that teammates claim and complete, and they message each other directly using tools. And task claiming "uses file locking to prevent race conditions." Its docs still warn: "Two teammates editing the same file leads to overwrites." [4]

So agents need a shared space. But what should that space be?

The idea

What if that shared space was a graph, one that doesn't just store what agents say, but enforces the rules between them?

A graph database stores things and the relationships between them. A function calls another function. A file imports a module. An agent owns a piece of code. A fact comes from a source. Relationships are stored directly, every answer comes with a path that explains it, and questions like "who is working on what this depends on?" are a single query.

So the shared space would hold:

• Ownership: one agent at a time per piece of code, handed over cleanly when it's done.
• Facts with sources: a teammate's claim counts only if it links back to where it came from.
• A live map of the project: who is working on what, and what depends on what.

If the graph handles that, subagents can finish and combine their own work, with no third agent and no human merging afterwards.

The irony, and why I didn't stop there

The irony is that this idea came out of my research sessions with Claude. But you can't build on an AI's suggestion blindly. So I went looking for proof.

Most multi-agent work is coding or reaching a decision together, so I picked the public benchmarks built for exactly those:

• HiddenBench (ICML 2026): facts are split across a team of agents. The authors report that "multi-agent LLMs achieve only 30.1% accuracy under distributed information," while a single agent with all the facts reaches about 80.7%. [5]
• CooperBench (2026): two coding agents build features in the same codebase. The authors found a "curse of coordination": agents average about 30% lower success when paired than when working alone, with channels "jammed with vague, ill-timed, and inaccurate messages." [6]

I tested properly:

• the same model in every setup,
• every rule written down before running anything,
• a held-out test set,
• and fair controls, including a placebo.

The results

HiddenBench, 40 held-out tasks (Claude Haiku 5.5):

The graph setup beat the placebo with p = 0.006.

CooperBench, 45 coding task pairs (Claude Sonnet 5.5): the two agents' work merged cleanly 35 times out of 45 with the graph, versus 22 when they coordinated by chat (p = 0.002). No third agent did the merging.

The discovery that shaped everything after: a shared board without source checks scored exactly the same as the placebo. A shared space on its own wasn't enough. A shared space with enforced rules was.

From research to Nodes

The results told me what the architecture had to be:

• One graph per project.
• Ownership decided atomically, so two agents can never both win.
• Facts that carry their sources.
• A gate every agent passes before it acts.

That became Nodes, an MCP server you plug in at the root of any repo, used by the whole team. Run nodes init, and it reads your code and git history into a FalkorDB graph. In Claude Code, it also enforces the rules automatically through hooks.

While your helpers run in parallel, Nodes:

• gives each piece of code one owner at a time, and hands it over when the work is done;
• makes helpers wait instead of overwriting, and wakes them the moment the code frees up;
• catches deadlocks (helpers waiting on each other) as a cycle in the graph;
• marks unchecked claims as unverified, so teammates don't act on them as fact;
• shows everything live on a dashboard, in plain sentences, with the exact Cypher query behind every decision.

It has already run live with 4 parallel Claude subagents on a real project, managing their ownership, waits and hand-offs as they worked.

What this unlocks for autonomous agents

• Parallel work that combines itself: no human merging, no extra cleanup agent.
• Better team decisions: 38% vs 12% when facts are spread across a team.
• Cheaper results: on HiddenBench, each correct decision cost $0.32 with the graph, versus $0.56 with plain chat and $0.80 with the placebo.
• Trust you can check: helpers act on facts with sources, not on each other's guesses.

The benefits that came along naturally

Things I didn't set out to build, but got from using a graph:

• Every decision explains itself: the path and the query are right there.
• Full replay: watch any run again, step by step.
• Project memory: a new helper starts out knowing the code, its history, and who worked on what.
• Scale: 100 agents competing for the same code produced zero double-claims, and conflict checks take 2 to 4 ms at the median on a 15,700-node codebase.
• Proof that the product is what I tested: all 4,916 recorded calls from the experiments, replayed through the finished product, returned exactly the same results.

What I learned

I started with a belief that I am going to do something more than just finish what's asked for. The most valuable thing I did was refuse to trust Claude blindly. Well I always wanted to do much more than research every time, and this time I had the opportunities to check and verify my claims by performing public bench marks on an architecture that I have designed. I had real joy when my architecture scored better than the baseline. Well I really want to write an extended research paper in fields of those public benches and submit it (I am open to learn so I would love if you can flag anomalies and educate me), but sadly arXiv needs an endorsement for first-time authors and hopefully one day I reach that level.

Nodes is open source: https://github.com/scorp2006/Nodes. Built for Graph Hacks by WeMakeDevs × FalkorDB.

References

1. Anthropic, Patterns and problems in emerging multiagent systems, Aug 13, 2026. https://www.anthropic.com/research/multiagent-systems
2. Cemri, Pan, Yang et al., Why Do Multi-Agent LLM Systems Fail?, arXiv:2503.13657. https://arxiv.org/abs/2503.13657
3. Ogenrwot & Businge, AgenticFlict: A Large-Scale Dataset of Merge Conflicts in AI Coding Agent Pull Requests on GitHub, AIware 2026, arXiv:2604.03551. https://arxiv.org/abs/2604.03551
4. Claude Code documentation, Orchestrate teams of Claude Code sessions. https://code.claude.com/docs/en/agent-teams
5. Li, Naito & Shirado, Systematic Failures in Collective Reasoning under Distributed Information in Multi-Agent LLMs (HiddenBench), ICML 2026, arXiv:2505.11556. https://arxiv.org/abs/2505.11556
6. Khatua, Zhu, Tran et al., CooperBench: Why Coding Agents Cannot be Your Teammates Yet, arXiv:2601.13295. https://arxiv.org/abs/2601.13295