The dashboard for the team that adopted a coding agent looks the way an adoption dashboard is supposed to look. More pull requests created, more merged, a shorter median time to merge, and a growing share of merged changes with the agent as author. The change that made account recovery faster is one of them. It merged quickly, with passing tests and a clean review, and it counted toward every line on the board.

Underneath the dashboard, the recovery log says something else. Accounts that hold a payment method are receiving new sessions from an emailed link without the verification the policy requires, because an account holding a payment method requires step-up verification before account recovery can issue a new session, and the new path omitted that rule. Every check passed. The dashboard counted the result as throughput.

This scenario is fictional end to end, carried through this series from ticket to dashboard, and it describes no real system, team, incident, deployment, or measurement. It is here because it shows what the numbers a manager is usually offered can and cannot say about a delivery system that now includes an agent.

Why Output Counts Mislead

The numbers on the fictional dashboard are real kinds of numbers. GitHub's documentation for its cloud coding agent, reviewed on 2026-09-02, describes pull-request lifecycle metrics: counts of pull requests created and merged, agent-created pull requests merged, and median time to merge. This article uses that name deliberately. They measure adoption and throughput of pull requests, and nothing about them claims to measure delivery outcomes. The fixture is invisible to every one of them, because a change that omits a constraint merges exactly as fast as one that honors it, and often faster.

Any output count has the same trap. It rises with volume whether or not the work got better, so a team that ships more changes and more mistakes looks identical to a team that ships more changes and fewer. DORA's 2025 research, reviewed the same day, describes AI as an amplifier of an organization's existing strengths and weaknesses and points to its AI Capabilities Model for the practices that decide which way the amplification goes. DORA's own guide to its delivery metrics warns against having one metric to rule them all and recommends several with a healthy tension between them. Read that as a warning about the system, not a productivity result; this article adds no number to it.

So the manager's question is not "how much more did we ship". Start with four handoff questions: what the agent may do, what artifact persists, who decides, and what evidence permits progression. Then add measurement. In management terms, those become accountability, surviving evidence, reversibility, escalation, and measurement. This recommendation defers to your organization's security policy, repository rules, release process, and incident runbooks.

Who Is Accountable at Each Gate

The table is this series' management view of the same handoff model the engineering articles use. Roles are roles, not titles from any particular organization. The consequence column is deliberately one word because it is the first thing a manager needs to know when something goes wrong.

The consequence column describes what remains after the decision is executed, not whether someone can revise the record before execution. Yes means the decision itself creates no external effect. Variable means the action it authorizes may cross that boundary. Partial means rollback can restore future behavior while leaving data changes or external events to repair.

Two rows carry the fixture. Implementation acceptance is where the product owner should have been asked whether the eval criteria still matched intent, and nobody was asked. Release authorization is where the reversibility class should have said that the code could be rolled back but the session-issuance events could not be erased. Whether the credentials could later be invalidated is a separate mitigation that this fixture does not establish. Neither row requires a new tool. Both require a name.

For readers who want the engineering view behind this one, the row below is the last handoff quoted from the ownership table this series uses, with its wording unchanged. The columns are what the agent does, what persists, who decides, and what evidence permits progression.

What Evidence Should Survive

A gate with no retained evidence is a gate that cannot be audited, and a manager who cannot audit a gate is trusting a habit. The evidence that should survive each handoff is short, and none of it is new.

The intent record, with a named owner beside every constraint. The acceptance criteria, with each concern marked resolved or carried forward and the carried ones owned. The implementation plan. Test results tied to the specific change rather than a dashboard aggregate. Eval results with the case identifiers, the run count, the threshold, and the date the cases were last confirmed against current intent. Both reviews recorded, intent and implementation, with the reviewer's role. The release record with its reversibility class and the two rollback names. The deployment or rollback record. And the incident record, if there is one, ending in a new intent stub rather than in a closed ticket.

Where it lives matters as much as whether it exists. Evidence in a chat thread is evidence the next change cannot find; the fixture's constraint died in that place. Evidence in the repository or the tracker, linked from the change request, is evidence an agent reads and a reviewer can follow. On a team without a formal system, the lighter equivalent is one linked document per change with the records above as headings. It needs no dedicated platform, but someone still has to keep the template, links, and owners current.

What Can Be Undone and What Must Escalate

Reversibility is the fact that decides who signs. The model uses four classes, offered as a recommendation rather than a taxonomy any source defines. Reversible by flag or configuration: future behavior returns to the old path and no data changed. Reversible by redeploying the previous build, with no data changed. Reversible with repair: data changed, and returning needs a migration or a backfill. Irreversible as an event: an external effect occurred, such as a session being issued, a message being sent, or money moving. Later mitigation may reduce the consequence; it does not make the event unhappen.

The fixture belongs to the last class even though its code belongs to the first. Turning the flag off restores the old recovery path; it does not un-issue a single session already granted to a payment-method account. A release record that only said "flag-reversible" would have been true and misleading. The class on the record has to describe the consequence, not the code.

Escalation works only when the trigger facts are encoded. In the original fixture, neither the design nor eval condition would have fired: C1 was omitted, so no concern was carried, and the missing case never changed. The revised design condition catches the failure only if account recovery is durably classified as identity-sensitive and routed to a named policy or domain review. Without that routing fact, the omission remains invisible.

A Rate to Start With, and What It Cannot Tell You

Having rejected output counts, this article cannot end by recommending another count. A count of post-merge corrections rises with merge volume just as pull-request counts do, and it would penalize the team that adopted the agent most. The starting diagnostic has to be a rate, and its parts have to be declared before anyone reads it.

Define the follow-up interval before defining the cohort. The denominator is all agent-assisted merged changes whose full team-declared follow-up interval has elapsed by the reporting cutoff. The numerator is the subset that needed an intent correction during its own interval. Report only mature cohorts. "Agent-assisted" needs an inclusion rule your team writes down, such as the agent authored the plan or the diff, and it has to stay the same from period to period. "Intent correction" means a change to the intent record, the acceptance criteria, or a constraint after the change merged, tagged as such in the tracker at the time; a fix that only changes code without changing what was asked for does not count. The reporting period selects which mature cohort is shown; it does not replace the per-change follow-up interval. The baseline is the same rate for a comparable mature cohort without agent involvement under the same interval, or, if that is unavailable, the first mature agent-assisted cohort, stated as a baseline rather than a target.

Then the caveats, which are the honest half of any diagnostic. The rate is a local signal about whether intent is reaching the agent's inputs. It is not proof that the workflow caused anything, and it cannot distinguish a team that writes better intent records from a team that stopped tagging corrections. That second case is the recording bias, and it is severe on teams that never recorded intent corrections in the first place; the lighter equivalent is to start tagging post-merge corrections in the tracker before measuring anything, and to treat the first period as calibration. The rate also sits inside a balanced set, not above it. DORA defines change fail rate and deployment rework rate as proportions of deployments, alongside lead time, deployment frequency, and recovery time, and a team should read the intent-correction rate next to those rather than instead of them. This article does not prescribe one metric for every team. It proposes one place to start and says what that place cannot see.

None of the sources cited here shows that an agent workflow improves delivery outcomes in general, and none of them measures the fixture's kind of failure. The vendor page documents pull-request metrics. The research describes a system property and defines delivery measures. The rest is this series' analysis, and the evidence for it is the fixture, which is fictional and offered as reasoning rather than proof.

What I Cannot Measure Yet

The failure in the fixture leaves no trace until it fails. A constraint that never reached the intent record produces no missing test, no failing eval, no rejected review, and no rollback, right up until the recovery log shows sessions where there should have been a verification step. I do not know how to measure that absence in advance, and I am wary of anyone who says a dashboard can. What a manager can do this week is smaller and more useful: ask for the reversibility line on the last release record, and ask when the eval cases were last confirmed against what the product now requires. If nobody can answer either question, that is the measurement.