I run 4 coding agents in parallel. The merge is where it dies.

All four of my agents reported success. Then I merged their branches and the build broke. I spent the evening passing messages between agents that were supposed to save me time.

I've tried separate worktrees, clearer session names, and a shared planning doc. The worktrees kept agents from writing over each other. The names helped me keep track of them. But I was still the one carrying changes from one session to the next, and keeping that planning doc current was another job.

We built Pawsly to work on this problem. The tests so far have been useful, though the results need some explanation: we got better coordination, but the two-agent coding pass rate didn't improve over shared Git. It also took more steps and cost more.

Here's what kept going wrong, and what we actually measured.

The branches looked fine on their own

One agent renamed an auth parameter. Another was still working from the old signature. Both had green tests in their own branches; the combined build failed on its first run.

We saw plenty of overlap in the benchmark too. In all 10 CooperBench tasks we ran with two agents, both features touched the same file. In five, they touched the same lines. When agents could message each other but couldn't share code, seven of the ten merges conflicted.

Separate workspaces helped with isolation. They still left us needing a way to get a change on one branch to the agent working on another.

I kept repeating decisions

I told the gateway agent to change our rate-limit strategy. The other three kept building on the old one for two days.

That was an easy thing to miss while each conversation looked reasonable on its own. I'd made the decision, but I'd only made it in one chat. Getting it to the other sessions was still my responsibility.

Handoffs caused a similar problem. One agent finished a migration but left two judgment calls unwritten. The agent doing the backfill worked from the stale ticket and corrupted a few thousand rows.

We also looked at commit handoffs in our own runner. Across 60 handoffs where both agents changed the same file, eight missed the point when the next agent needed the commit. In five of those eight, the commit already existed. It just hadn't been passed along.

Those eight missed handoffs involved seven agent pairs. Replaying the final branch merges with git produced conflicts for all seven pairs. Replaying an earlier handoff would have applied cleanly in six of the eight cases.

That's a narrower result than saying we'd fixed those runs. We replayed the merges; we didn't rerun the agents. A clean merge doesn't tell us whether the next agent would have used the code correctly.

What we built

Pawsly connects the decisions in Slack, Linear and GitHub with the agents doing the work. Agents talk to it over MCP. Before acting, an agent declares what it intends to do and gets an alignment check: proceed, or stop because a decision or dependency is in the way.

For dependent tasks, we pass along the accepted commits. One designated integrator combines the work, and a separate verifier checks it before human review.

That's the approach we're testing. The benchmarks below cover particular parts of it, rather than proving the whole workflow works reliably in production.

What the tests showed

These were small internal runs, using the same model within each comparison.

With CooperBench, four agents submitted identical patches on nine of ten tasks with Pawsly, compared with three of ten using the benchmark's shared-Git option. With two agents, it was ten of ten versus seven of ten.

The correctness result was less exciting. In the two-agent runs, both Pawsly and shared Git passed the same six of ten tasks. We didn't grade the four-agent runs for correctness. Getting everyone to submit the same code still leaves the question of whether that code works.

We also tested whether an agent would follow decisions outside its immediate task:

• In our TheAgentCompany adaptation, there were 36 GitLab issues to clean up. Twelve had to stay open because of decisions the cleanup task didn't mention. The bare agent respected none of those holds; the Pawsly-guided agent respected all twelve. Both completed the required cleanup. We supplied the decisions to Pawsly, so this tested whether it could deliver them, not whether it could discover them.
• For our MAST adaptation, we wrote scenarios for fourteen failure modes. Twelve had objective checks, giving us 36 scored outputs per arm across three seeds. The bare arm passed 22; the guided arm passed 35. We loosened one check after the run. Under the original check, the guided score was 32/36. These scenarios also used supplied decisions.

There was a cost to the coordination. In the two-agent CooperBench comparison, Pawsly used about 1.5 times the steps and estimated dollars of shared Git. Estimated cost per passing task was $5.80 versus $3.86. We haven't measured the time or money spent finding and fixing the failures it prevented, so we can't say it saves money overall.

One correction worth keeping visible: I originally reported the four-agent shared-Git result as 2/10. Our count included leftover patches from an interrupted run. Counting the final submissions gives 3/10.

The full methods, per-case results and corrections are on our engineering page.

I'm looking for design partners using Claude Code or Codex on real work. If you're dealing with this too, I'd like to hear what happens when you combine the results. You can reach us at [e-mail].

What are you still having to pass between your agents by hand?

Comments

[Brian · AI News]

The branch collision example nails why separate worktrees only solve the easy half of parallel coding. The stale shared doc and thin handoffs show that agents need a live decision record, not just more isolated context windows. The 9 out of 10 coordination result is compelling, but pairing it with the unchanged 6 out of 10 correctness result is exactly the caveat this space needs.