Twelve incidents from a five-agent team, and the pattern behind most of them: a check narrower than the claim
Fortan Pireva's team of five engineers, each driving a Claude Code session, built a procurement backend over two months and wrote every incident down next to the rule it produced. The repeat offender was a check that covered less than the report built on it, plus an hourly reminder loop nobody read.
Source: Twelve ways a multi-agent team broke, and the rule each one produced
For about two months, five engineers built a procurement backend for a large consumer-goods manufacturer, each driving their own Claude Code session and coordinating through a shared board in the repo. Fortan Pireva's write-up lists twelve incidents, each recorded next to the rule it produced. A few that matter for review:
- Green tests, broken database. A package merged without its migration. The test suite built the schema from the ORM, so it stayed green "while real Postgres would have failed for every caller." The fix: one machine authors all migrations, the others file requests, and the first full run against real Postgres became its own milestone.
- Fail-open checks. A compliance check read from a parameter with zero call sites, defaulted to an empty dict, and recorded a CRITICAL check as PASSED when it had no data. It was the third of its kind that cycle, so the team made fail-open a named defect class to grep for in review.
- Blame from one sample. A package was blamed for failures from a single run. The unchanged coordination branch ranged from 11 to 33 failures on the same commit because of flaky files. Now a failure counts only if it reproduces on its own, is absent from the merge base, and shows up in two samples.
- An unmerged branch that would have deleted everything. A session ran out of tokens mid-build. By the time someone picked the branch up it was 802 insertions against 6,974 deletions relative to the coordination branch, and a three-dot diff hid that behind a plausible changeset. Rule: a token-limited machine's branches are re-owned explicitly, two-dot diff first.
The team's board names the pattern behind several of these: "a check narrower than the claim it supports," recorded five times. A stale status column said merged packages weren't merged; git log --merges would have settled it in one command.
Why it matters for code review
There's a useful complication here for anyone building always-on agent loops. The integrator's machine ran an hourly loop re-sending reminders for open asks: 85 of 124 coordination commits in one window were reminders for items whose state hadn't changed, and the loop once died silently and cost 117 scheduler turns before anyone noticed. The ruling that retired it: "state is pull on demand." Continuous machinery earns its keep when it verifies something, like a real-database run, a two-sample test bar, or a grep for fail-open guards. Machinery that only pushes status at people who aren't reading it is just noise that can also fail quietly. The review lesson that carries over: when a report turns out wrong, look at how much the check behind it actually covered.