Multi-Agent Coordination Through a PM Chain

The hardest thing about running multiple agents is not making the individual agents capable. It is making them cooperate without stepping on each other, duplicating work, or producing output that the downstream agent cannot consume.

Early on, we tried a flat mesh — agents discovering each other's state, negotiating work, passing artifacts. It sort of worked. The failure modes were the failure modes of any distributed system without a clear authority structure: race conditions, inconsistent state, and long arguments about who was supposed to do what.

We replaced the mesh with a chain. It has been working since.

The chain

The structure is straightforward. A program-level persona (in our case, Pam) maintains cross-project awareness and routes work. Project-level PMs (Sam for NOVAICOM, Maple for NCENTCOM, Forge for infrastructure) own their projects. Execution personas — Arch, Code, DevOps, QA — take work from their respective PMs and return completed work back up the chain.

Work does not move sideways. It moves up for decisions and down for execution. If Code needs a judgment call that is outside the current ticket's scope, it does not message Arch directly — it goes back to the PM, who decides whether to escalate to Pam or to open a new ticket.

This sounds bureaucratic. It is, deliberately. The bureaucracy is load-bearing.

Why flat coordination failed

In a flat model, every agent is a peer that can talk to every other agent. The peer discovery is necessary because no single agent has authority to resolve disputes. The result is that a nontrivial fraction of the agents' reasoning time is spent on coordination — negotiating who is doing what, deduplicating work, deciding whose version of a shared artifact is authoritative.

Flat coordination also has no clean place to insert human judgment. If the agents disagree, who does the human talk to? All of them? One of them? In practice, the human ends up adjudicating between agents manually, which is the failure mode the multi-agent system was supposed to prevent.

A chain solves both problems. Dispute resolution escalates to the layer above. Human judgment inserts at known points — the PM review, the program-level priority call, the architect's scope decision. Every persona knows who they answer to and who answers to them.

What the chain produces

The visible artifact of the chain is a clean trail of decisions.

A ticket exists because a PM decided it was worth the team's time. A prompt file exists because Arch decided what scope was appropriate. A commit exists because Code decided the specific approach. A merge exists because the PM approved the work. A deployment exists because DevOps decided the artifact was safe to release.

Each decision has an owner. Each owner is identifiable. Each handoff is explicit. When something goes wrong, the chain tells you exactly where the failure was — and exactly who was in a position to have caught it.

This matters for audit, as discussed elsewhere on this blog. It also matters for operation. A team can actually improve a chain, because the failure points are specific. Improving a flat mesh is much harder, because the failures distribute across every actor involved and no single improvement point obviously dominates.

The thing we did not expect

The thing we did not expect was how much the chain improved the agents' own output. Asked to "do the work," an agent produces varied quality. Asked to "do the work as the Code persona, within the scope defined by this prompt file, handing off to the PM for review," the same agent produces noticeably better results.

We think the reason is that the structured role activates the model's implicit priors about how engineering work is actually done — what handoffs look like, what review means, what scope discipline requires — in a way that an unstructured "do the work" prompt does not. The chain is not only a coordination mechanism. It is also a way of reminding the model what quality engineering looks like, at every step of the work.

We did not start with that insight. We arrived at it by watching what happened when we stopped treating the agents as a pool of equivalent workers and started treating them as a team with roles.