Market Context 8 min read

# McKinsey Rewired Software Delivery for the Agentic Era. The Enforcement Layer Isn’t in the Org Chart.

McKinsey’s 2026 report is the clearest enterprise account yet of how agents change the way software gets built: roles, processes, and the whole delivery operating model get rewired around supervision and orchestration. It is right about all of it. It is also an org-design document — and nothing in an org-design document executes at the moment an agent writes code.

By Theo Valmis·June 2026

In May 2026, McKinsey Technology published “Rewiring software delivery for the agentic era.” It is a strategy-consulting read on a shift this site has tracked from the engineering side, and it is worth taking seriously precisely because it comes from the operating-model direction rather than the tooling one.

## What McKinsey’s rewiring covers

The report’s argument is that agentic AI rewires the entire software delivery lifecycle, so human roles move from execution to supervision and orchestration. Engineers stop writing every line and instead spend their time “supervising generation, validating architecture, and managing quality,” and “structuring agent tasks into precisely defined workflows” with “templates for agentic output.” New roles appear — prompt engineers, agent orchestrators, human-in-the-loop designers — and demand rises for senior engineers and architects who set standards across teams, vendors, and agents.

And McKinsey says something that lands very close to home:

> Architecture becomes more important, not less, because someone still has to define what the system is allowed to do.McKinsey, “Rewiring software delivery for the agentic era” (2026)

That is correct, and the report is strong on the org side of it: architects defining guardrails, review points, and non-functional requirements; the operating model redesigned so humans supervise rather than type. None of this is a straw man to knock down. The rewiring is real and most enterprises need it. (For the engineering-side version of the same role shift, see the future of software engineering after vibe coding.) The question is what the rewiring, by its nature, cannot reach.

## An operating model is an org-design artifact. Nothing in it executes.

Here is the seam. Everything McKinsey describes is an org-design artifact: roles, pods, review processes, talent, standards, the shape of the delivery org. Redrawing those decides who is accountable for architecture. It does not produce the thing that actually holds at the moment an agent generates code — a machine-checkable constraint the change is evaluated against before it lands.

The reason is a mismatch of speed. An org chart is a human-latency control loop: a reviewer reads, an architect weighs in, a standard gets discussed. The agent does not run at that latency. It runs underneath the org chart, at machine latency, in the gap between the redrawn roles — producing dozens of changes in the time it takes one review thread to start. McKinsey’s notion that “someone still has to define what the system is allowed to do” is right; what the report leaves implicit is that, for an autonomous agent, “define” has to mean compile into something that executes, not write down for a human to uphold. A definition only a person can enforce is not reachable at the speed the agent is moving.

McKinsey rewires the operating model around agents; nothing in an operating model executes at generation time. The rewired org names the architect who owns a decision. It does not give that decision a way to reach the agent at the moment of the change.

This is why a perfectly rewired delivery org can still accumulate architectural drift. Every role is staffed, every review point exists, every standard is written — and the system still slides off its design, because no role’s authority operates at the latency the agent does. That an authorized, well-supervised process still produces drift is the recurring finding behind harness engineering still needs governance and the broader case that governance becomes an infrastructure layer, not a process one.

## A spec the agent reads, versus a spec the agent cannot cross

The sharpest place to see the gap is in McKinsey’s own remedy. Its answer to agent unpredictability is better structure on the way in: “precisely defined workflows” and “templates for agentic output.” That is a real improvement — and it upgrades only one side of the loop. A precisely defined workflow is a spec as input: a richer instruction the agent reads, and may follow or quietly override. It is not a spec as enforced constraint: a binary verdict the change is checked against and cannot cross.

Spec as input (the rewiring) | Spec as enforced constraint
--- | ---
a richer prompt / template / workflow | a compiled, machine-evaluable rule
the agent reads it; may override it | the change passes or fails against it
improves the input to generation | renders a verdict on the output
upheld by humans, at human latency | enforced by the system, at machine latency

McKinsey’s rewiring makes the input side excellent: better-organized humans feeding better-structured tasks to agents. It leaves the enforcement side — the part that makes autonomy safe rather than merely faster — structurally unaddressed, because that side is not an org artifact and an operating-model redesign cannot mint it. This is the same reason a retrieved document is not a rule: retrieval explains architecture; it does not enforce it.

## The substrate the rewiring needs but cannot produce

What closes the gap is not another role or another review gate. It is a layer that turns “what the system is allowed to do” into something evaluated at the moment of the change: the team’s architectural decisions compiled before generation into enforceable infrastructure, applied deterministically at the commit, the pull request, and in CI, with the provenance to say which decision a change violated and where it came from. It sits below the operating model and runs at the agent’s latency, which is exactly where the org chart cannot reach. It is the runtime counterpart to McKinsey’s human architecture — the place where a defined boundary becomes an enforced one.

That is the one layer a rewiring presupposes and never supplies. McKinsey hands architecture back its authority on the org chart. Enforcement is what lets that authority survive contact with an agent moving faster than any review it sits above.

## What the report actually confirms

McKinsey’s report matters because of where it comes from. When a top-tier strategy voice describes software delivery as an operating-model problem rather than a developer-tooling one, it confirms the shift is structural: enterprises are redesigning how software is built around autonomous execution, not just buying faster autocomplete. That is the right diagnosis.

It also draws the boundary of its own frame. An operating-model redesign can decide who owns architecture, how work is structured, and which humans supervise which agents. It cannot, by construction, produce the layer that enforces a decision at the instant an agent acts on it — because that layer is infrastructure, not org design. The rewiring is necessary. It is not, on its own, enough to make autonomous execution hold its shape.

The rewiring decides who is accountable for the architecture. The enforcement substrate is what lets their decisions hold when an agent executes between the redrawn roles. McKinsey describes the first with unusual clarity. The second is the layer the org chart cannot contain.

## Frequently asked questions

What does McKinsey’s “Rewiring software delivery for the agentic era” report argue?+
It argues that agentic AI rewires the whole software delivery lifecycle, so human roles shift from execution to supervision and orchestration. Engineers move from writing every line of code to supervising generation, validating architecture, and managing quality; they spend more time structuring agent tasks into precisely defined workflows and templates for agentic output. New roles emerge — prompt engineers, agent orchestrators, human-in-the-loop designers — and demand rises for senior engineers and architects who define standards. McKinsey’s notable line is that “architecture becomes more important, not less, because someone still has to define what the system is allowed to do.” It is a software-delivery operating-model and workforce transformation argument, not a thesis about governance tooling or enforcement.
Does McKinsey call for architectural governance or deterministic enforcement?+
No. The report uses none of those terms. Its “architecture matters more” point is about human architects defining guardrails, review points, and non-functional requirements inside a workflow transformation — not about machine-enforced governance. Reading McKinsey’s rewiring as creating demand for an enforcement substrate is Mneme’s extension of the report, not McKinsey’s conclusion. The report describes the operating-model change; it does not identify execution-time enforcement as the missing piece.
Why isn’t an operating-model rewiring enough to govern AI agents?+
Because an operating model is an org-design artifact, and nothing in an org-design artifact executes. Redrawing roles, pods, and review processes decides who is accountable for architecture; it does not produce the machine-checkable constraint that holds at the moment an agent generates code. The org chart is a human-latency control loop, and the agent operates below it, at machine latency, between the redrawn roles. The redrawn org can still ship architectural drift because no role’s authority reaches generation time. Closing that gap requires an enforcement substrate that is infrastructure, not an org artifact.
What is the difference between a spec as input and a spec as enforced constraint?+
A spec as input is a richer instruction the agent reads and may follow or override — a better prompt or template, which is what McKinsey’s “precisely defined workflows” and “templates for agentic output” upgrade. A spec as enforced constraint is a binary verdict the agent cannot cross: the change is checked against compiled architectural rules and passes or fails regardless of what the agent intended. McKinsey’s rewiring improves the input side of the loop; the enforcement side, the part that makes autonomous execution safe, is a different object the operating-model redesign does not produce.
Related operational essays

- The Next AI Infrastructure Category Is Governance

  Every infrastructure wave grows a governance layer. Agentic delivery is the next one.

- The Future of Software Engineering After Vibe Coding

  The engineering-side version of the role shift McKinsey describes.

- What Is the AI SDLC?

  The lifecycle redefined by AI, and where enforcement has to sit inside it.

- The Next Layer Is Coordination Governance

  Orchestrating agents is not the same as constraining what they build.

Related governance concepts

- Governance Infrastructure

  Why governance for autonomous systems has to be infrastructure, not a process.

- Governance Before Generation

  Compiling the team’s decisions into constraints the agent meets at generation time.

- Runtime Governance

  Where a defined architectural boundary becomes an enforced one.