In May 2026, Patrick van Esch, Yuanyuan Gina Cui, and J. Stewart Black published Beware the Agentic Convergence Trap in Harvard Business Review. The argument is sharp and, for a strategy piece, unusually mechanical. When many organizations deploy similar AI systems, point them at similar objectives, and feed them similar data, those systems independently arrive at near-identical decisions. The result is not a smarter market. It is a market where everyone moves the same way at the same time.

The authors’ central example is RealPage. The company did not force landlords to coordinate prices. It shipped a feature: an auto-accept option for its pricing recommendations. Hundreds of competing landlords independently chose to switch it on. Each made a locally rational decision. Collectively, they produced something that looked like coordinated rent-setting across entire cities, and eventually drew regulatory scrutiny. No one in the system intended the outcome. The defaults produced it.

HBR’s framing is the part worth holding onto. The convergence trap is not a technology problem. It is a leadership and governance failure that the technology makes possible. The systems did exactly what they were configured to do. The failure was in not deciding, deliberately, where the organization’s judgment should override the default.

That sentence is why this article belongs on a site about architectural governance. The trap HBR describes at the level of business strategy is the same trap that is quietly running at the level of code.

The same mechanism, one layer down

Consider how AI-assisted engineering actually works in mid-2026. The frontier coding models are converging in capability and are available to everyone on roughly equal terms. Teams reach for the same two or three models. They wire them up with similar prompts. They ask them to solve problems that, across an industry, look very alike: an auth flow, a payments integration, a retrieval pipeline, a CRUD service over a familiar schema.

A model is a compression of its training data. Asked an underspecified question, it returns the centroid — the most probable, most generic, most widely-represented answer. That is a feature when you want a sensible default. It is a liability when the same centroid is being returned to every team that asks. Point the same model at the same problem with the same loose prompt, and it will reach for the same repository pattern, the same error-handling shape, the same dependency, the same folder layout.

Each generation is locally rational and collectively homogenizing. No engineer intends for their architecture to look like everyone else’s. But absent an instruction to diverge, a probabilistic model converges by construction. The auto-accept feature in HBR’s example has an exact analog: accepting the agent’s first plausible suggestion, every time, without a layer that says “not that way — this way.”

This is the convergence trap as an engineering phenomenon. The asset that used to differentiate a software company — how it had decided to build things, accumulated over years of hard-won judgment — erodes when the building is delegated to a shared model running on shared defaults. The codebase drifts toward the industry mean. And like RealPage’s landlords, no single commit looks wrong. The homogenization is emergent.

HBR’s escape route is a governance instruction

The most useful thing about the HBR piece is that it does not stop at the diagnosis. Its prescription, paraphrased, is a short list of governance moves: decide where humans stay accountable; define objectives that go beyond the platform’s defaults; build unique data inputs the model cannot get elsewhere; and measure divergence as a strategic indicator rather than assuming it. The winners, the authors argue, will be the organizations that design their AI to reach conclusions their competitors’ AI will not.

Read that list again with an engineering eye. Every item maps cleanly onto something an architectural governance layer does.

HBR’s anti-convergence moves, translated to the codebase
01
Decide where humans stay accountable → Recorded decisions
The architectural choices your team has actually made — the storage backend, the dependency policy, the layering rule — are where human judgment overrides the default. Governance turns those choices into structured records instead of tribal knowledge that the agent never sees.
02
Define objectives beyond the defaults → Constraints at generation time
A default prompt produces a default answer. A constraint surfaced before generation tells the model the objective your team actually holds — this pattern, not the popular one — and does it on every call, not just when someone remembers to mention it.
03
Build unique data inputs → Decision memory
Your accumulated decisions are the one input no competitor’s model has. They are not in the training set. A governance layer makes that private corpus retrievable and enforceable, turning it into the engineering equivalent of HBR’s proprietary-data moat.
04
Measure divergence → Enforcement provenance
You cannot manage what you cannot see. When every enforced verdict traces back to a specific recorded decision, divergence from the industry default stops being a hope and becomes an auditable, deliberate property of the system.

HBR is telling executives to stop accepting the platform default as their strategy. The engineering corollary is to stop accepting the model default as your architecture. Both are the same instruction: insert a layer of deliberate, enforced judgment between the system and its output.

Why prompts and conventions are not enough

The obvious objection is that teams already do this. They have a style guide. They have a CLAUDE.md. They have conventions. Surely that is enough to keep an agent from converging.

It is not, for the same reason HBR’s convergence trap is not solved by good intentions. An instruction that lives in a document is advisory. It competes for the model’s attention with everything else in the context window, it is applied probabilistically, and it degrades as the session grows and as the context gets crowded. The agent reads “prefer composition over inheritance” and then, three turns later, generates the inheritance hierarchy anyway, because the default pull was stronger than the reminder. Convergence wins on the margin, commit after commit.

Advisory convention
Hope the agent diverges
Conventions in a prose file. Read sometimes, applied probabilistically, weakened by context pressure. The default reasserts itself whenever attention lapses. Differentiation is left to chance.
Enforced governance
Guarantee the agent diverges
Typed decisions, retrieved by relevance, enforced before generation and checked at the boundary. The divergence your team chose holds regardless of which model runs or how long the session has been open.

This is the difference between wanting to escape the convergence trap and building the mechanism that escapes it. RealPage’s landlords did not lack good intentions. They lacked a deliberate override. A governance layer is that override, made deterministic, applied every time, independent of which model happens to be executing the prompt this week.

The strategic stakes are not abstract

It is tempting to treat code-level convergence as a cosmetic concern. It is not. The architecture of a system is where its hardest-won advantages live: the performance characteristics competitors cannot match, the domain modeling that took years to get right, the integration choices that make the product feel coherent. When that layer drifts toward the mean, the product drifts toward the mean with it. You end up with software that a competitor could have generated from the same prompt — because, increasingly, they could have.

HBR also names the downside risk, and it transfers. Convergence does not only erase upside; it can create shared, correlated failure. When everyone’s system makes the same call, everyone is exposed to the same blind spot at the same moment. In a codebase, that is the shared vulnerable dependency, the identical mishandled edge case, the same architectural shortcut replicated across an industry because the model recommended it to all of them. Differentiation is also diversification. Enforced divergence is partly a resilience strategy.

The winners design their AI to reach conclusions their competitors’ AI will not. In engineering, that conclusion is the architecture — and the only way to guarantee it is to govern it.
The HBR thesis, applied to the generation layer

What this means for engineering leaders

The Agentic Convergence Trap is usually read as a boardroom memo. It is also a memo to anyone responsible for an AI-assisted codebase. The mechanism the authors describe — shared systems, shared defaults, emergent sameness, governance as the only real defense — is not specific to pricing or strategy. It is a general property of delegating decisions to convergent models without a layer of enforced judgment on top.

The practical takeaways are short:

  • Treat the model as a shared input, not a moat. Everyone has it. What you do above it is the differentiator.
  • Make your decisions explicit and enforced. Tribal knowledge the agent never sees cannot keep your architecture distinct. Recorded, retrievable, enforced decisions can.
  • Put the override before generation, not after. Catching convergence in code review is detection. Preventing it at generation time is governance.
  • Measure divergence on purpose. If you cannot point to where your system is deliberately different, assume it is converging.

HBR’s authors gave the strategy world a clear name for a real failure mode and the right remedy: governance, not better defaults. The same name and the same remedy apply to the layer where code is actually written. The teams that internalize it will own architectures their competitors cannot regenerate from a prompt. The teams that do not will ship the centroid, along with everyone else.