Great review. If you use this program every day, there is one thing you should know. CLAUDE.md is doing a lot of the most important work here, and it's the most fragile piece of the stack. A rule like "always re-read X before editing" is written as a piece of prose, and prose is subject to context. It's either one compaction or one subagent that appears from quietly disappearing, and there's no warning when this happens. The subagent case is the clear one: a subagent gets a new window, doesn't have the parent's CLAUDE.md discipline, and acts on the assumption that the rule was meant to stop something. The only thing that can reliably enforce the rules is settings.json permissions.deny, which the runtime checks before the model picks a tool. This means that you can't use cat or grep to bypass it. Everything left in prose is a strong default, not a guarantee. It's good to know which of your rules are which.
The title is very fashionable at the moment. Subagents are good at the part that can be broken down into separate tasks. The problem is that each subagent has its own understanding of the plan. When the plan changes, or if one subagent changes its assumptions, the windows don't stay in sync. You get work that's similar but doesn't fit together, and this shows up when you're integrating. The easy part is parallelism. The difficult part is making sure the different agents work well together, and that's not something you can easily achieve by increasing the number of subagents. I'm curious to know if your seven were reading from one source that stayed fixed, or if any of them were supposed to react to what the others produced.
A shared handoff file is better than implicit coordination. The problem to watch out for is the file becoming out of date: agent A reads Agents-Collab.md, agent B updates it mid-task, and agent A continues to act on what it has read. The protocol is only as good as how fresh each agent is on the file that contains it. "Live" is the hard part when two agents run at once instead of handing off one after the other. If each agent had a version or timestamp that they checked before they acted, it would stop a handoff written after A's last read from being ignored.
Saying "agents lying" isn't usually deception. It's the model telling a story about a gap that the runtime couldn't fill. This gap could be a rule or a state that the runtime was supposed to respect, but wasn't actually enforced. This means that the contract is completed as text. It is best to use a harness that enforces the SOP out of the model's reach. This is because if you leave anything as prose in context, it will lead to one compaction or one subagent spawn from evaporating. The most difficult case to test would be an SOP that depends on a state that changes under the agent. If step 3 says "use the latest config" and another process updated it after the agent read it at step 1, will the harness re-check, or enforce against the snapshot the agent loaded?
It's really useful to have a clear list of who's on the team and what they do, because there isn't one at the moment. A static team definition doesn't show the runtime hazard. This is when two agents read the same artifact. One updates it, while the other keeps acting on the version it loaded. The roles can be clearly defined, but the output is still unclear because agent B wasn't told that agent A had moved the shared state. I would like to know if you think that coordination layer is part of the problem, or if it is only a problem with the runtime.
It wasn't a crash that cost us the most time; it was a stale read. Two agents shared a plan file. One updated the file during the run and the other continued to work off the version that had been loaded at the start. Both produced plausible output. Nothing errored. We only discovered this issue during the review process, after wasting hours of generation time. I now treat any artefact that two agents can both access as a coordination problem, not a storage one. The cheapest and most effective solution was to stamp a version on the artefact and re-check it before acting, instead of trusting the copy read at the start of the run.