The Story
For about two years now, the pitch for multi-agent AI has been the same: instead of one model grinding through a task alone, spin up a team of them. A planner, a coder, a reviewer. Divide the work, move faster, ship more. It sounds obviously right — it’s how human teams work, after all.
관련해서 Cursor’s Origin and Git hosting at agent scale도 함께 참고하시면 좋습니다.
The trust-and-provenance angle shows up again in trust and traceability in AI systems.
The problem is that when researchers actually measure it, teams of agents often do worse than a single agent working alone. Put two frontier models on a shared task and they talk past each other, overwrite each other’s changes, and lose track of what the other one is even doing. A benchmark called CooperBench, published earlier in 2026, found agents collaborating scored about 30% lower than they managed solo — roughly 70% of their own solo success rate. So the interesting question isn’t “should agents work in teams.” It’s “why do teams of agents keep tripping over each other, and what actually fixes it?”
A new paper out of Carnegie Mellon — “Effective Strategies for Asynchronous Software Engineering Agents,” by Jiayi Geng and Graham Neubig — takes a hard swing at that question, specifically for software engineering. Their answer is refreshingly unromantic. The fix isn’t smarter conversation between agents. It’s borrowing the boring coordination machinery human developers already rely on: git.
Their system has a name, CAID, short for Centralized Asynchronous Isolated Delegation. Don’t let the acronym scare you — it’s built on three plain ideas. A manager agent breaks the job into pieces and hands them out (“centralized delegation”). Each engineer agent then works in its own isolated copy of the codebase — a git worktree, basically a private branch with its own files — so nobody is editing the same file at the same time (“isolated workspaces”). And the whole thing runs on an event loop where the manager delegates and checks progress without everyone marching in lockstep (“asynchronous execution”).
Here’s the piece that makes the whole thing click. The agents don’t merge their work by chatting about it. They merge it the way engineers do — through an explicit `git merge`, gated by tests. An engineer finishes a chunk, the changes get integrated into the main line only if the tests pass. Branch, work in isolation, merge with verification. That single design choice — treating git primitives as the coordination protocol — is what the paper points to as the real unlock.
And the numbers hold up — though it’s worth reading them carefully, because the size of the win depends heavily on which model you run. The paper tested three: Claude Sonnet 4.5, GLM 4.7, and MiniMax 2.5. On PaperBench (reproducing research papers from scratch), CAID’s absolute improvement over a single agent was +6.1 points for Claude Sonnet 4.5, +7.4 for GLM 4.7, and a striking +25.6 for MiniMax 2.5. On Commit0-Lite (building Python libraries from scratch), it was +6.0 for Claude Sonnet 4.5, +3.6 for GLM 4.7, and +14.7 for MiniMax 2.5. So the headline 25.6- and 14.7-point figures aren’t averages — they’re MiniMax 2.5’s best-case gains. For Claude and GLM the lift is real but single-digit. To put one concrete case in view: on PaperBench, Claude Sonnet 4.5 went from 57.2% solo to 63.3% with a two-engineer setup. These are the authors’ reported results, on those specific benchmarks — not a universal law — but even the modest numbers are a clear, measured win where naive multi-agent setups had been losing.
The Takeaway
The word doing the heavy lifting in that title is “asynchronous,” and it’s worth being precise about what it buys you — because it’s not what most people assume.
The instinct is that asynchronous, parallel agents mean speed. Four engineers working at once should finish in a quarter of the time, right? The paper is admirably honest that this isn’t what happens. It flatly notes that multi-agent execution costs more in API tokens than a single agent, and that wall-clock time isn’t substantially reduced despite the parallel work. Why? Because the merging stays sequential. You can write in parallel, but you still integrate one piece at a time, testing as you go. The bottleneck just moves from writing to reconciling.
So if async isn’t buying speed, what is it buying? Quality through isolation. The reason naive agent teams fail is that they step on each other — concurrent edits collide, dependencies drift out of sync, and stitching everyone’s partial work into a coherent whole falls apart. Each agent produces something locally sensible that’s globally broken. By giving every agent its own worktree and forcing integration through a tested merge, CAID removes the collisions. Asynchrony here isn’t a performance trick. It’s a conflict-avoidance strategy. That’s a genuinely different mental model, and it reframes what these systems are for.
There’s a bigger pattern I keep noticing across the agent stories we’ve followed. When people ask “why don’t AI agents just work together,” the missing ingredient is almost never intelligence. It’s infrastructure. Earlier this month we looked at why “AI agent identity” suddenly became a hard problem — agents can’t cooperate safely if the system can’t even tell who’s who. This CAID work is the same lesson from a different angle: agents can’t cooperate productively if there’s no shared state, no clean way to hand off work, no verification gate. The intelligence was arguably already there. What was missing was the plumbing.
And that’s the direction this whole field seems to be quietly moving. Not toward agents that negotiate cleverly in natural language — which turns out to be the fragile part — but toward wrapping agents in the same battle-tested tools humans built to coordinate messy parallel work. Git worktrees. Tests as a merge gate. A manager that delegates. These aren’t AI breakthroughs; they’re software engineering hygiene, and it’s telling that they’re what moved the needle. The most reliable way to make a team of agents behave, it seems, is to stop asking them to be a chatty team and start treating them like disciplined engineers who commit their work and let the CI decide.
One honest caveat before anyone gets too excited: the gains here are on specific research benchmarks — paper reproduction and library-building — not on a sprawling legacy enterprise codebase with a decade of tangled dependencies. Whether “branch, isolate, merge-with-tests” scales to that mess is the open question. But as a proof that the fix for flaky agent collaboration is structural rather than conversational, it’s a clean result. The path to agents that build software together doesn’t run through better small talk. It runs through better version control.
This article is for informational purposes only and is not a recommendation to adopt any particular technology or product.
TL;DR: A CMU paper (CAID) shows teams of AI coding agents can beat a single agent — not by talking to each other, but by working in isolated git worktrees and merging through tested `git merge`. The size of the win varies by model: on PaperBench, +6.1 points for Claude Sonnet 4.5, +7.4 for GLM 4.7, and up to +25.6 for MiniMax 2.5 (Commit0-Lite: +6.0 / +3.6 / +14.7). Those top figures are MiniMax’s best case, not an average. The key insight: asynchrony here buys conflict-free quality, not speed (cost went up, wall-clock time barely moved). The bottleneck in multi-agent AI is infrastructure, not intelligence.
Photo: Annie Spratt / Unsplash
댓글 남기기