I have watched the same failure pattern play out in two unrelated projects this quarter, built for two different clients, with two different agent architectures, solving two different problems.

Both times, the symptom looked identical: a review cycle that would not converge.

In one large-scale application modernisation engagement, the client’s own technical team built a Peer Review agent – separate from our Dev and QA agents – to assess code quality before anything reached a human reviewer. The instructions behind that PR agent were written independently, by a different team, and were not shared with us in detail. Our developers had no way to know, in advance, what the agent was checking for. They found out only by submitting code and reading the feedback.

The PR agent kept generating comments. Sometimes seven rounds of comments, on the same piece of code, before it stopped. Many of the flagged items were not defects. They were stylistic preferences, hypothetical edge cases, and in several cases, feature requests dressed up as code quality feedback – asking for functionality that was outside the agreed project scope entirely.

Our developers and our Dev agent were, in effect, running on a hamster wheel – fixing, resubmitting, receiving a new round of commentary, fixing again – with no shared definition of what “done” looked like.

In a separate engagement, we generate business requirement documentation using our BA agent – parsing legacy application logic and producing BRDs that can run 500 to 1,500 pages for a large system. The client’s business analysts began using their own AI agent to review our output. The feedback loop that followed had the same shape: legitimate functional gaps mixed in with comments like “this section is too technical, use business English,” or a request to standardise terminology – “Registration No.” instead of “Vehicle Registration” – in places where both terms were used interchangeably in the legacy system itself, and where a competent developer would have resolved the ambiguity in seconds.

Neither case involved a broken agent. Both agents were doing exactly what they were instructed to do. The problem was that nobody had defined what “done” meant, and nobody had aligned the two agents’ instructions with each other.

It is worth pausing on the irony here.

Picture how this work happened before agents. A human business analyst drafting a 500-page BRD is spending nearly all of their cognitive energy on capturing functionality correctly. There will still be errors and omissions – human output varies by author, and a review cycle exists precisely to catch that variance. That review cycle is expensive, but it is bounded. A human reviewer eventually reaches a point of diminishing returns and signs off.

An agent-generated BRD, once the underlying instructions are well-designed, is actually more consistent than the equivalent human-drafted document. Less variation between authors. Fewer careless omissions. A more deterministic starting point for the next stage of the pipeline.

What we are watching instead, in these uncoordinated cases, is the opposite of what the technology should deliver: reviewers – human or agentic – reaching for something, anything, to flag, because the review step itself has become the deliverable rather than a means to an end. We are not catching more real defects. We are manufacturing friction.

It is structurally similar to a generative adversarial network with no training objective — a generator and a discriminator locked in a loop, except nobody designed this pairing to converge, and nobody is watching the loss function.

The direct cost is obvious: developer hours and project timeline consumed by rework that produces no functional improvement. In the PR agent case, aligning instructions and shifting quality checks earlier in the pipeline brought review cycles down from seven rounds to one or two. That gap – five or six wasted cycles – is not a rounding error on a project timeline.

The less obvious cost is what it does to how leadership reads the whole AI initiative. When a VP, a delivery director, or a business sponsor looks at a project where two agents have been going back and forth for a week over semantic phrasing, the conclusion they draw is not “our review process needs recalibrating.” It is “the agents aren’t delivering the efficiency we were promised.” That conclusion is wrong, but it is also completely understandable from where they sit – and it is exactly the kind of conclusion that stalls an AI initiative at the executive level, regardless of how good the underlying agents actually are.

Because building an individual agent has become genuinely easy, most organisations now have several — a Dev agent here, a QA agent there, a client-side review agent nobody on the delivery team has visibility into. Each one may be well-designed in isolation. The failure happens in the space between them, where nobody owns the coordination.

This is the same process reengineering principle I have written about earlier in this series, applied one level up. It is not enough to reengineer a single workflow around a single agent. When multiple agents — potentially built by different teams, on different platforms, with different owners — participate in the same pipeline, the orchestration between them needs to be deliberately designed, not left to emerge from however each agent happened to be instructed.

In my view, a genuinely governed agentic SDLC process needs at minimum:

• Explicit, shared acceptance criteria, defined upfront.
  If there is a UAT checklist or a code quality standard an output will eventually be measured against, that standard needs to be visible to every team and every agent contributing to that output — not discovered after the fact through a slow, iterative review cycle. Fine-tuning an agent against a standard nobody has shown you is not quality control. It is guesswork with extra steps.
• Deliberately designed agent-to-agent workflows, not agents that happen to interact because they touch the same artefact.
  A BA agent, a Dev agent, a QA agent, and a review agent can each be excellent individually. Whether they function as a coordinated pipeline or an adversarial loop depends entirely on whether someone designed the handoffs, the shared vocabulary, and the convergence criteria between them.
• A defined human-in-the-loop threshold.
  When two agents disagree, or fail to converge after a set number of retries — three is a reasonable starting point — the process should escalate to a named human reviewer automatically, rather than continuing to iterate indefinitely. Bounded retries with automatic escalation replace unbounded, silent iteration.
• Governance on tool use and token consumption.
  An uncoordinated multi-agent loop is not just a time cost. It is a direct, measurable token cost, running on infrastructure someone is paying for, often invisibly, until a bill or a burn-rate review surfaces it.

I want to be honest about something: none of the individual teams in either project were doing anything unreasonable. The client’s PR agent team had a legitimate quality bar in mind. Our BA agent team was building good documentation. The client-side review agent – reviewing BRDs against a legitimate business-readability standard – had a reasonable instinct too. Nobody set out to build friction. It emerged from the absence of a shared governance layer above the individual agents.

That is, I think, the more important lesson here. As agent-building becomes commoditised – and it genuinely has, to the point where nearly any technical team can stand one up in days – the organisations that get real value out of this technology will not be the ones with the most agents. They will be the ones who treat the coordination layer between agents as seriously as the agents themselves: shared instructions, versioned and reviewed like any other operational policy; clear ownership of acceptance criteria; and a human escalation path that activates automatically rather than by hope.

We have started applying exactly this thinking to how we structure multi-agent SDLC pipelines internally, and it is the same principle behind the control-plane layer we have been building in elsai Foundry – a governance layer that sits above whichever agents an organisation is running, whether they were built on Claude, an in-house framework like our own iBeam agents, or a client’s own tooling, and gives every agent in the estate a shared, versioned instruction set, a defined escalation path, and visibility into what each agent actually did and what it cost. The specific platform matters less than the principle: coordination between agents needs to be designed and owned, not left to whichever team built the loudest one.