Governing agentic delivery

Your AI controls probably watch. They do not stop.

Most enterprise answers to "how do you control AI?" describe instruments that record what already happened. This is a doctrine for the controls that act before and during the work — and a vocabulary for telling the difference.

Observability makes behavior visible. A control plane makes policy operational.

Governance sets the rules · The control plane puts them into operation

The problem

A log that records a violation has already permitted it.

Ask an enterprise how it governs AI and you will usually hear about traces, dashboards, audit logs, and evaluation suites. Every one of those instruments acts after the model has acted. They are excellent at telling you that something went wrong. None of them stopped it.

That gap is tolerable when AI drafts a summary someone reads before sending. It stops being tolerable the moment an agent writes to a repository, moves money, touches a member record, or opens a pull request against a regulated system. At that point the question is not what happened. It is what was allowed to happen, and what could have prevented it.

The models are extraordinary at producing output that sounds correct, and plausibility is not correctness. Professional-services firms have retracted AI-assisted reports over fabrications. Law firms have been sanctioned over invented citations. The failure mode is not that the model refuses to work — it is that it works confidently and wrongly, and nothing in the path objected.

The same defect, two architectures. Instrumentation observes the outcome. A verifier in the control plane withholds it. Both produce a record; only one changes the outcome.

There is a second, slower failure that matters more to a CFO than to an engineer. A Carnegie Mellon study of AI coding agents found the initial three-to-five-times velocity gain dissipates within roughly three months, as security, maintainability, reliability and complexity defects accumulate faster than the features do. Unverified speed does not compound. It converts into debt, and the debt eats the gain.

That finding is third-party and industry-reported. It is cited here as the argument for verification discipline, not as a measured result of any one programme.

The definition

A verifier is a check with the authority to stop.

A verifier is a named, independently-owned check with a defined trigger, a defined scope, the authority to block, and a recorded disposition.

Four properties, all required, and each one rules out something that commonly masquerades as control. A check without a named owner is a suggestion. A check without authority to block is a dashboard. A check that leaves no recorded disposition leaves no evidence — which means it cannot be audited and, for a regulated estate, did not happen. And a check that fires at the wrong moment is theatre: the most rigorous review in the world is worth little if it runs after the change is already live.

The spine

Sort every control by when it acts.

Control timing is the organizing idea, and it converts an abstract governance debate into a question an executive can put to their own estate: which of our AI controls can actually stop something, and at what moment?

Three classes control. One only observes. The fourth column is drawn without signal colour deliberately — an estate whose entire AI control story lives in that column has visibility without authority.

Before
generation

Preventive verifiers

"The agent cannot."

These bound what the agent is capable of attempting at all. Every constraint applied here is a class of defect that never has to be caught later — and a well-bounded agent is also a cheaper and more accurate one, because it navigates less and guesses less.

policy-as-code
tool allowlists
scoped credentials
protected paths
data-boundary rules
approved context

On failure: the action is impossible rather than merely disallowed. There is nothing to remediate.

During
generation

Inline verifiers

"Checked while working, not after."

These run while the agent produces work, block on failure, and hand back a correction signal the agent must resolve before it can proceed. This is the class that turns an agent from an unsupervised generator into a supervised one — and it is the class most organizations are missing entirely.

schema conformance
deterministic tests
secret scanning
data-flow checks
diff-scope limits
protected-lane enforcement

On failure: the loop halts and the agent must fix it. Work does not advance past a failed inline verifier.

Before
release

Gate verifiers

"Nothing ships unverified."

Zero-trust and multi-layered: deterministic analysis fused with agentic review, plus evaluations and quality gates, closing at named human authority. This is the classical control point, and it works far better when the first two classes have already removed the noise.

static + dynamic analysis
dependency policy
intent vs requirement
evaluations
evidence completeness
release authority

On failure: release is withheld. A failed gate creates remediation work; it never transfers accountability to an agent.

After
release

Continuous verifiers

"The last line, not the control."

Runtime monitoring, drift and regression detection, and incident feedback form the observability layer. It is necessary, but it acts after the fact and can report only what has already happened. Primary assurance must come from controls that act before impact.

runtime monitoring
drift detection
regression watch
incident feedback

On failure: an incident is raised and remediation enters the maintenance loop. The event has already occurred.

Non-negotiables

Two rules that decide whether any of this is real.

The zero-trust independence rule

No agent verifies its own output. A verifier must be independent of the generator — a different model lineage, or a deterministic tool — and named human authority remains accountable for the disposition.

Every model carries characteristic biases and failure modes. Asking one to grade its own homework reproduces those biases in the verdict and returns a confident pass. This is the point that lands hardest with a risk officer, because it is not a new idea to them at all: it is segregation of duties, applied to a new kind of actor.

The fusion rule

Algorithmic and agentic verification are complementary, never either/or. Algorithmic verification is deterministic and repeatable — analysis, dependency policy, secrets, data and control flow, tests, coverage, schema conformance. It catches the known and the mechanical, identically every time, and it cannot tell you whether the code does the right thing.

Agentic verification reasons about intent, business-logic correctness, requirement conformance, and the unknown-unknowns no rule was written for. On its own it is non-deterministic. Fused, the two cover each other's blind spots.

The register

Doctrine becomes control when it has a register.

A verifier register is the artifact that turns this from a point of view into an auditable control set. One row per verifier, and one column most organizations would rather leave off.

Starter verifier register — adapt per estate
Verifier	Class	Trigger	Owner	Layer	Authority
Sensitive-data boundary	Preventive	Context assembly	Security architecture	Algorithmic	Blocks
Tool and dependency allowlist	Preventive	Tool invocation	Security engineering	Algorithmic	Blocks
Scoped credential broker	Preventive	Credential request	Security architecture	Algorithmic	Blocks
Protected-lane / diff-scope limit	Inline	Every file write	Security architecture	Algorithmic	Blocks
Secret exposure scan	Inline	Every diff	Platform engineering	Algorithmic	Blocks
Contract and schema conformance	Inline	Interface change	Platform engineering	Algorithmic	Blocks
Deterministic test suite	Inline	Pre-commit	Platform engineering	Algorithmic	Blocks
Intent-versus-requirement review	Gate	Pull request	Named code reviewer	Agentic	Flags
Security and dependency gate	Gate	Pull request	Security engineering	Algorithmic	Blocks
Evidence-completeness check	Gate	Release packaging	Evidence owner	Algorithmic	Blocks
Named release authority	Gate	Release decision	Release authority	Human	Approves
Drift and regression watch	Continuous	Post-release runtime	Operations owner	Algorithmic	Flags

The column to add, and never to omit, is Standing: implemented today, or documented standard. A register that does not separate what runs from what is designed is a marketing document, and an auditor will treat it as one. Being able to say "these six are live, these six are the standard we are building to" is worth more than a full page of green checkmarks nobody believes.

The system

Three loops, or the discipline decays.

Verifiers operate in three loops. Designing them deliberately is what makes the system compound rather than decay — and the mechanism runs in both directions.

Inner agentic loop

guide → generate → inline verify → correct

Catches defects at the moment of creation, when the fix is cheapest and the context is still live.

Without it: the agent produces volume nobody has checked, and defects surface downstream at multiples of the cost.

CI verification loop

multi-layer verify → evaluate → quality gate → human gate

Proves the change is correct, secure and conformant before it can ship.

Without it: review becomes the bottleneck, then rubber-stamps what it cannot keep up with.

Maintenance loop

detect debt → verified remediation → re-verify

Holds complexity flat so the codebase stays navigable — to humans and to agents.

Without it: debt compounds, agents slow down on their own output, and the velocity gain reverses.

The compounding is not a metaphor. Cleaner codebases measurably reduce the effort agents need to operate on them, because an agent must understand a system before it can safely change it. Maintenance is not hygiene here. It is throughput.

The objection

"Won't all this verification slow the agents down?"

It is the right question, and the honest answer is that it slows a single generation step and speeds up everything after it. The comparison that matters is not verified-versus-unverified on one task. It is the three-month curve.

Unverified agentic delivery is fastest in week one and slowest by month four, because every unreviewed shortcut becomes a constraint on the next change. The measured pattern is a three-to-five times gain that returns to baseline within a quarter while defect rates stay elevated. Verification is what stops the curve bending back.

There is a second-order effect worth naming: the preventive class actively makes agents cheaper. Constraints and well-packaged context reduce the searching, guessing and rework an agent does, which reduces the tokens it burns getting to the same answer. The discipline is not purely a tax.

Industry-reported · third party · not our own measurement

External findings cited in this doctrine
Finding	What it implies
Agentic task-length benchmarks are reported at ~50% success; held to 80% accuracy, achievable task length collapses METR task-length benchmarking, as presented at AI Engineer, 2026	Headline capability numbers are not enterprise-grade reliability numbers.
A 3–5× velocity gain dissipates within ~3 months as security, maintainability, reliability and complexity defects accumulate Carnegie Mellon University study, as presented at AI Engineer, 2026	Unverified speed converts into debt at least as fast as it converts into features.
Teams applying multi-layered verification report AI-derived production outages ~44% less frequently Vendor-reported partner data, AI Engineer, 2026	Verification discipline shows up in production reliability.
A disciplined guide/verify/solve approach inside agentic loops produced a ~92% reduction in issues in one large-bank test Vendor-reported customer test, AI Engineer, 2026	The effect compounds across the loop rather than per step.

How to use this

Lead with the distinction, not the taxonomy.

Start with the operating distinction: observability makes behavior visible; a control plane makes policy operational. The four classes show how policy acts at each control point.

Then name the missing class. Nearly every organization already has preventive controls, because they have had identity management and allowlists for years, and nearly every one has post-hoc observability. What is almost always absent is anything that acts during generation. Naming that gap is what makes the conversation useful rather than merely affirming.

Doctrine committed to the repository, with one owner
Verifier register created, including a populated Standing column
The inline class specifically audited — what actually blocks mid-generation today?
Zero-trust independence verified — is any agent reviewing its own output?
The three loops named and owned
Public copy leads with visibility versus operational control
Third-party figures attributed and labelled industry-reported
Every claim separated into implemented versus documented standard

Claims discipline

Credibility is the entire value of this conversation.

These rules travel with the doctrine. An organization that overclaims on control loses the argument permanently the first time someone checks.

Keep it model-agnostic. Never name a specific coding assistant or vendor product as your process; tools change and the method is the asset. Attribute borrowed figures and label them industry-reported. Separate implemented from designed everywhere. Coverage is not completion — mapped controls and mapped requirements are not the same as verified evidence, and one must never quietly become the other in a summary. And a failed gate creates remediation work; it never transfers accountability to an agent.