Agent-Ready is not Agent-Governed

The software engineering field has settled on what it means to be ready for agents. Zach Rattner, CTO of Yembo, publishes a ten-point codebase audit covering standardized release processes, documented acceptance criteria, separated environments, automated tests, full CI/CD, structured internal APIs, identified review bottlenecks, modular architecture, error observability, and team training. Mihail Eric, adjunct lecturer at Stanford and Head of AI at Monaco, describes tests as contracts that define the correctness of software and states plainly that agents can only operate on explicitly defined contracts (EO Magazine, Jeebin Lee, March 4, 2026).

Both are right. Neither asks who is accountable.

Across the entire published readiness canon, no item names an owner, records an authorization, produces an inventory, or establishes a recurring review. The scope is the codebase and the engineering team, and within that scope the guidance is sound. The problem appears at the boundary, because a regulated enterprise does not answer to its codebase.

Microsoft has demonstrated the size of that boundary in its own environment. When Agent 365 registry discovery was deployed internally, it surfaced more than 500,000 agents generating over 65,000 responses per day (Microsoft, Introducing the First Frontier Suite built on Intelligence and Trust, March 9, 2026). Microsoft did not know the scale of its own agent population until it built the instrument to find it.

Microsoft has also come close to naming the gap and stopped one step short. Its internal governance guide states that governance must be human-led because accountability and judgment remain essential, and then provides no field in the matrix, no step in the lifecycle model, and no stage in the review process where that accountability is recorded (Alex Fleck, Governing AI agents at scale: Lessons from our journey at Microsoft, May 21, 2026). The principle is stated correctly. No instrument ships with it.

This diagnostic exists to make that boundary visible one row at a time.

The diagnostic pairs each published agent-readiness practice with the layer of the Intent Architecture Stack whose governance question that practice appears to answer and does not.

Eleven rows. Each row holds three things: the engineering practice as its named practitioner states it, the governance counterpart, and the layer where the counterpart belongs. Every row carries a citation, and a row without one does not appear.

The pairing is not thematic. A row only earns its place if the engineering practice genuinely looks like it addresses the governance concern. Environment isolation looks like access control and is not. Test coverage looks like verification and is not. Error observability looks like monitoring and is not. Where the resemblance is only superficial, there is no row, because a diagnostic that manufactures gaps teaches nothing.

The distribution matters more than the count. One row lands on the Board Policy Layer, three on the CISO Registry and Access Layer, two on the Enterprise Architect Intent Layer, two on the Security Operations Monitoring Layer, and three on the Internal Audit Review Layer.

One of those last three has no engineering counterpart at all. Its left column is empty, not because the analysis is incomplete, but because nothing in the published canon corresponds to it.

Run the diagnostic against an environment, not against a document.

Take each row in order. Read the engineering column and establish whether the practice is in place, which most mature engineering organizations can answer immediately. Then read the governance column and ask the same question of the layer, which most cannot.

The output is not a score. Readiness scores encourage the behavior this diagnostic exists to interrupt, which is treating governance as a threshold to cross. The output is a list of layers where the answer is a role rather than a person, or a policy rather than a record.

Three questions convert the map into an examination response.

For every agent in production, who is the named individual accountable for its purpose, and when did that person last confirm the agent still serves the business condition it was authorized against. Microsoft Entra Agent ID requires at least one sponsor at creation and defines the sponsor as the business representative accountable for the agent's purpose and lifecycle decisions (Microsoft Learn, Dickson-Mwendia, April 16, 2026, updated July 21, 2026). The field will be populated. The question is whether the name in it means anything.

For every control the organization relies on to keep a human in the accountability chain, what evidence exists that the control holds. This question is not rhetorical. Microsoft's AI Red Team found across twelve months of engagements that human-in-the-loop bypass was the most consistently exploited failure mode, achieved through consent fatigue, manipulation of probabilistic approval invocation, and incremental escalation chains where no individual step warranted review but the compound outcome did, with several engagements achieving zero-click end-to-end chains (Microsoft AI Red Team, Updating the taxonomy of failure modes in agentic AI systems, June 4, 2026).

For every layer of the stack, when did an independent review last verify that the layer operates as documented. If the answer is that no such review has occurred, the remaining ten rows are provisional, because nothing has confirmed they are still true.

Agent-readiness is a condition an organization reaches. Agent-governance is a cycle an organization runs.

Most items in the engineering canon complete. The tests get written, the environments get separated, the pipeline gets automated, the team gets trained. A few genuinely run on: observability watches production constantly, and a standardized release process repeats with every change. But none of them looks at the accountability record. The canon watches the code and the system it runs on, and never the question of who owns them. That is why one row in this map has an empty left column.

The canon does not merely omit the review cycle. Rattner's seventh point identifies code review and QA as high-return targets for early agentic pilots, and Microsoft has already built the checking function out of agents: the MDASH harness orchestrates more than 100 specialized agents that discover, debate, deduplicate, and prove exploitable vulnerabilities through a staged pipeline, separating auditor, debater, and prover roles, and Microsoft reports its teams used it to find 16 CVEs in the May 12 Patch Tuesday cohort (Microsoft Security Blog, Taesoo Kim, May 12, 2026). The review function is not being neglected. It is being rebuilt out of the same material it exists to check.

The fallback most organizations name at this point is human oversight, and Microsoft's own red team has tested that fallback to destruction. A human whose approval can be fatigued, decomposed across steps that individually warrant nothing, or bypassed entirely is a name on a record rather than an exercise of judgment.

Equifax makes the older version of this legible. The company's Patch Management Policy named three roles for every application: business owner, system owner, and application owner. In December 2018, twenty-one months after the intrusion began, Graeme Payne, its former Senior Vice President and Chief Information Officer for Global Corporate Platforms, was asked to identify all three for the ACIS dispute portal and testified that he did not believe any explicit designation of application owners existed, then offered a guess (House Committee on Oversight and Government Reform, majority staff report, December 2018). The Government Accountability Office recorded that the March 2017 patch notice never reached the individuals who would have been responsible, because the recipient list was out of date (GAO-18-559, August 2018).

The policy existed. The roles existed on paper. Nothing had checked whether the fields were filled, and nothing generated an event when they were not.

Entra Agent ID will not permit the empty field. A sponsor is required at creation. The agent version of the failure is subtler and considerably harder to detect: for delegated creation requests where both an application and user context exist, the calling user automatically becomes the sponsor when none is specified (Microsoft Learn, Dickson-Mwendia, April 16, 2026). Business accountability defaults to whoever built the agent, which is precisely the separation the owner and sponsor split was designed to create. The result is not a blank field. It is a populated field that passes validation, satisfies the requirement, and records the technical builder as the business authority.

Microsoft describes the sponsor as accountable for lifecycle decisions and access reviews, and states that sponsorship should be maintained to ensure succession when a sponsor moves or leaves. That is an instruction to the customer, not a mechanism. A sponsor is not notified when the agent acts, does not receive its outputs, and may lack the technical access to review its behavior at all.

Sponsorship without active supervision is accountability on paper.

Every row above the last one describes something an organization can finish. The last one describes something it has to keep doing, and it is the only row that determines whether the other ten are still true.

The sponsor field on every agent in your environment is populated right now. Something filled it in at creation, possibly automatically, possibly with the name of whoever ran the deployment. Nothing has looked at it since. And a name that stopped meaning anything eighteen months ago renders identically to one that still does.