McKinsey's How to close the agentic adoption gap frames transformation as a five-stage progression from Awareness to Enforce, supported by a 1:3:5 investment pattern across technology, process redesign, and adoption.
The agentic adoption gap is not primarily technological
McKinsey describes a 1:3:5 pattern in successful AI transformations: for every dollar invested in agentic technology, organizations spend three on process redesign and five on capability building and adoption.
Many organizations reverse those priorities. They concentrate on the tool while treating work design, skills, and behavior as implementation details.
Deploying an agent does not create an agentic operating model.
The report also identifies four fears that inhibit adoption:
- being exposed as insufficiently knowledgeable about AI;
- remaining accountable for decisions made with systems employees do not fully control;
- operating without a stable picture of the future organization; and
- losing professional expertise and identity.
The second fear is especially relevant to software engineering. McKinsey calls it accountability without control.
An employee may use an agent to analyze or act, but responsibility does not transfer to the agent when the result is wrong.
The engineering parallel is immediate. A coding agent can choose a dependency, bypass a service boundary, modify a public API, or recreate functionality that an earlier architectural decision rejected. The agent produces the implementation. The organization owns the consequences.
Delegating execution is not delegating accountability
Human software development already depends on layered controls. Teams establish standards. Architects ratify decisions. Security groups prohibit patterns. Platform teams constrain infrastructure. Reviewers inspect changes.
AI coding agents alter the execution side of that system.
An agent can make many implementation decisions in the time a human previously made a smaller number. Agents can also operate across more of the repository and in parallel.
Engineering leaders need to preserve one boundary:
Delegating execution does not delegate accountability.
If an agent introduces a prohibited database or contradicts an accepted ADR, the organization cannot meaningfully answer that the model made the choice. Someone still owns the architecture.
McKinsey's answer at the organizational level is to redesign the operating system around agentic work. Software engineering needs the same principle to reach the agent's execution path.
Translating Awareness to Enforce into engineering
McKinsey's sequence is useful because it shows why enforcement belongs late in adoption, after teams understand the work being changed.
Awareness
Developers and engineering leaders need direct experience with coding agents. They learn what the systems can do, where they fail, and which tasks are appropriate to delegate.
At this stage, experiments matter more than elaborate governance infrastructure.
Belief
Teams begin seeing repeatable value. Agents generate useful tests, investigate unfamiliar code, or complete bounded changes. Experienced engineers show colleagues where the tools help and where judgment remains necessary.
Trust becomes operational rather than theoretical.
Commit
Agent use enters normal delivery. The question changes from whether engineers should experiment to where agents belong in the workflow.
Exposure grows at the same time. An experimental assistant makes an isolated mistake. An agent embedded in daily work can express the same misunderstanding repeatedly across the codebase.
Develop
Organizations build competence around task design, context engineering, evaluation, review, tool use, and workflow architecture. One-time training is poorly suited to systems that change quickly, so capability develops inside the work.
That still does not solve every governance problem. A skilled developer can give an agent excellent context and receive a technically valid implementation that conflicts with an architectural decision.
Enforce
This is the point where the organization stops depending exclusively on people remembering the desired behavior.
For engineering, the question becomes which decisions should be part of the execution environment, which should remain advisory, and which are consequential enough to justify deterministic enforcement.
The engineering interpretation is:
Move important architectural intent from something agents are told about to something their changes can be evaluated against.
Documentation, context, and enforcement are different controls
These layers are often treated as interchangeable. They are not.
Documentation records the decision
An ADR can state that a service uses SQLite rather than PostgreSQL. It preserves institutional rationale so the decision does not disappear with staff turnover or tool changes.
Context exposes the decision
An agent cannot follow a decision it never sees. A useful decision corpus makes relevant architectural decisions available to the task and code area where they apply.
This improves the probability of conformance. It does not guarantee it. A model can misunderstand the decision, retrieve a superseded record, or treat the rule as optional guidance.
Enforcement evaluates the change
Enforcement turns an explicit part of architectural intent into a machine-evaluable constraint.
For example:
Decision: This service must use SQLite. PostgreSQL dependencies are prohibited.
Documentation records the rule. Context gives it to the agent. Enforcement evaluates the resulting change and produces a deterministic verdict when the prohibited dependency appears.
That is the transition from remembered intent to executable constraint.
Enforce does not mean policy for every preference
McKinsey is not proposing deterministic software guardrails. Its Enforce stage is organizational. This engineering interpretation is ours.
Nor should teams convert every architectural preference into a hard block.
Some decisions are contextual. Some vary legitimately by service. Some are temporary. Some are better expressed as advice than enforcement.
A mature verification contract defines:
- which decision is authoritative;
- where it applies;
- what constitutes a violation;
- whether the result is PASS, WARN, REVIEW, or FAIL; and
- how an exception becomes visible and durable.
If an agent receives a verdict, engineers should be able to trace it to the governing decision. Otherwise enforcement becomes another opaque system people learn to bypass.
The decision corpus becomes part of the operating system
McKinsey argues that durable adoption requires the formal operating system of the organization to reinforce the desired behavior.
ADRs and engineering standards already belong to that operating system. The problem is that most were designed for human execution.
Humans read the record. Humans remember the rule. Humans notice the mismatch. Humans raise it in review.
As more execution moves to agents, the decision corpus needs a path from human authority to machine execution:
- capture what was decided and why;
- retrieve the current decision relevant to the change;
- propagate the same authority across tools and agents;
- evaluate machine-checkable constraints against the proposed result; and
- surface evidence when implementation diverges.
This is governance propagation. It is not orchestration. Orchestration determines what work runs. Governance determines what must remain true while it runs.
Human review should not be the first architecture check
McKinsey argues that adoption should be measured by whether work becomes better, faster, safer, or more valuable, not by login counts or agent invocations.
Engineering leaders should apply the same standard.
The relevant metric is not how much code an agent generated. It is whether agentic development improved delivery while keeping architectural and operational risk within acceptable bounds.
Post-generation review remains essential for judgment and exceptions. Deterministic decisions do not always need to wait for that review.
Where a constraint is known before generation, verification can begin during planning and continue against the resulting change. That reduces the need for reviewers to reconstruct architectural history from every diff.
Organizational and engineering enforcement are complementary
An organization cannot close the adoption gap by installing technical guardrails. Teams still need trust, work redesign, skills, leadership, and credible outcome measures.
The reverse is also true. Organizational change does not make architectural decisions executable.
A company can train thousands of employees and redesign workflows while its coding agents continue making locally plausible changes that conflict with the architecture.
The two layers complement each other:
- Organizational enforcement establishes how people, accountability, incentives, metrics, and workflows sustain agentic work.
- Engineering enforcement establishes which machine-executed changes may cross important technical boundaries.
At sufficient autonomy, mature organizations need both.
From adoption to governed execution
The progression McKinsey describes is important. Organizations make agentic AI understandable, credible, normal, and effective. Then they redesign the operating system so the new behavior persists.
Software engineering has an additional requirement because agents are not merely supporting the workflow. They are executing part of it.
The more implementation authority organizations delegate, the more important it becomes to preserve the engineering decisions constraining that authority.
Mneme is building that engineering layer: a project decision corpus, governance propagation into coding-agent workflows, and deterministic evaluation where architectural decisions can become reliable contracts.
The goal is not to replace engineering judgment. It is to make sure that when an organization reaches McKinsey's Enforce stage, the decisions its engineers remain accountable for can reach the systems now doing more of the work.