A product owner asks for faster account recovery. A coding agent reads the ticket and an older design note attached to it, adds a recovery endpoint that issues a session as soon as an emailed link is opened, writes unit tests for it, and opens a small pull request with a clear description. The tests pass. The reviewer approves, because nothing in the diff is wrong.

Before the ticket existed, the security lead had settled a rule: an account holding a payment method requires step-up verification before account recovery can issue a new session. The rule lived in a meeting note and a chat thread. It never reached the ticket, the design note, the repository, or any check. The new path omitted it, and every check passed.

None of this happened. The scenario is fictional from the ticket to the dashboard and describes no real system, team, incident, deployment, or measurement. It runs through this article and the next three in the series because it shows the one failure that decides where an agent belongs in delivery: correct work for a constraint that never arrived.

Why Adding a Coding Agent Did Not Fix the Delivery Problem

Your first guess is probably a better prompt, a stronger model, or more tests. None of those touch the failure. The agent did not misread the ticket. It read a ticket that was already incomplete, and the tests it wrote checked the code against its own reading. A test cannot check a constraint that nobody wrote down.

The fixture is a delivery failure that happened to involve an agent. Before agents, the same ticket would have reached an engineer who might have remembered the chat thread, or might not. The agent changed one thing: it took away the pause in which a person could have noticed. It produced coherent, reviewable, passing work faster than the process could supply the intent that work depended on.

The same mechanism sits behind a claim you will find in vendor material. Anthropic's AI-native SDLC playbook, published in August 2026, and the Claude Academy course behind it argue that once code generation is cheap, pressure moves into planning, review, testing, and deployment. A vendor is describing its own product there, so treat the claim as an inference rather than a measured result. It holds anyway. If the expensive part of a change was never the typing, making typing cheaper cannot make delivery better on its own. It makes the rest of the system the bottleneck, and the rest of the system was not designed to run at the agent's pace.

If your team counts agent adoption in merged pull requests, the fixture looks like a success.

What This Model Is and Is Not

What follows is a reference model for this series: a way to reason about one software change as it moves from intent to production and back, when an agent can do more than type. It is a recommendation. It does not replace your organization's security policy, repository rules, release process, or incident runbooks, and where they disagree with it, they win.

The model asks four questions at every handoff. What may the agent do here? What artifact persists when this step is done? Who decides whether the work moves on? What evidence has to exist before it may? An engineer who can answer those four for the change in front of them knows what to write next, what the agent is allowed to touch, which check must run, what to keep, and who signs. A manager who can answer them knows who is accountable, what evidence survives, and where the escalation goes.

Three parts of the model get only a mention here, because each is a subject of its own in this series. Which checks can produce which evidence, and why one passing eval is a sample rather than a proof, is one. Who reviews, who signs, and what a rollback record needs is another. The manager's view, with accountable roles, retained evidence, reversibility, escalation, and one honest rate, is the third.

Every vendor reference in this article was last reviewed on 2026-09-02. Product features move faster than lifecycle arguments, so read the dated details as snapshots and the model as the durable part.

The Words the Rest Depends On

The sources on this subject use several labels, and they do not describe one method. The table fixes what each word means in this series and where the meaning comes from.

So the first question to settle is which lifecycle you mean: using agents to build product software, or building and operating an agent. Everything below is about the first.

Agents Can Act at the Gate, but They Do Not Own the Gate

The diagram is a conceptual representation of the whole journey, drawn for this series and reproducing none of the sources' diagrams. Read it top to bottom: the agent's work sits between things people own.

A rejected release returns to the earliest failed step, and the production signal becomes the next intent. The table below is the same journey with the four questions answered for each handoff. It is this series' analysis, assembled from the sources named later and from the boundary argument in the first article of this series. It has no name, and it is not an industry standard. Change any row that does not fit your system.

Read the table for what it refuses to let the agent do. It drafts, proposes, checks, and prepares, and at every one of those points a named person confirms, corrects, judges, or authorizes. Human in the loop is a slogan until each gate has an artifact, an owner, and a way to enforce it.

Four vendor-neutral recommendations hold the table together. Every handoff fixes what the agent may do, what artifact persists, who decides, and what evidence permits progression; a handoff missing one of those is where the fixture's rule went to die. Tests and evaluations defend only the constraints that reached the specification, the repository context, a policy, or an evaluation set, and nothing downstream recovers a constraint that never arrived. A control that can be inspected is not a control that is enforced: a review that repository policy does not require is a convention, and a nominal approval with no artifact behind it is not a gate. And ceremony scales with two things, how open-ended the reasoning is and how expensive a plausible wrong result would be, which is why the same table is too much for most changes and not enough for a few.

Where the Constraint Has to Enter

The first four handoffs are where the fixture's rule could have entered cheaply. Each one below answers the four questions in the same order, then names the lighter version for a team that cannot change CI, does not hold release authority, and has no formal environment gate.

Intent comes first. The agent may draft an intent record from the ticket, ask the questions the ticket does not answer, and list what it could not resolve. It may not confirm any of it. The artifact that persists is the corrected intent record. The product owner decides whether the intent is understood well enough to design against. The evidence permitting progression is that owner-corrected record, with a named owner beside every constraint. The lighter equivalent is a ticket template with two required fields, constraints and who owns them, which costs nothing and would have been enough here.

The record below is a worked template for the fixture, not a form to copy unchanged. The line to read is the constraint, and the owner beside it.

# Intent: faster account recovery
 
Owner: product owner, account access
Why: locked-out customers abandon recovery, and support absorbs the cost
Wanted: a customer who shows control of their email gets back in faster
 
Constraints:
- C1 (security lead): an account holding a payment method requires step-up
  verification before account recovery can issue a new session.
- C2 (support lead): recovery must not weaken the existing lockout rules.
 
Open questions:
- Q1 (security lead): which account classes count as holding a payment method?
- Q2 (support lead): is a shorter link lifetime acceptable?
 
Out of scope: password reset, device trust

The whole difference between the fixture and a safe version of it is on that page: the rule is written down, it has an owner, and everything downstream can be checked against it.

Requirements and design come next. The agent may draft criteria, options, and flagged concerns from the intent record; it cannot resolve a concern, only surface it. The artifact that persists is a set of acceptance criteria with the open concerns named. Product, domain, security, and architecture owners decide, each for the concern they own. The evidence permitting progression is the criteria showing every concern either resolved by its owner or carried forward with an owner and a deadline. The lighter equivalent is the security lead answering one question in the ticket and that answer being pasted into the criteria.

The criteria below are the same worked template one step later. Watch what happened to Q1 and Q2.

Acceptance criteria: faster account recovery
 
AC1. A customer without a payment method who opens a valid recovery link
     receives a new session.
AC2. A customer with a payment method who opens a valid recovery link is sent
     to step-up verification and does not receive a session. (C1)
AC3. An expired or reused link receives neither a session nor a step-up prompt.
AC4. Every recovery decision is logged with the account class and the outcome.
 
Resolved: Q1, by the security lead. Any account with a stored card, bank
mandate, or wallet token holds a payment method.
Carried forward: Q2, owner support lead, must be resolved before release.

AC2 is the constraint restated as something a test can encode. Q2 is deliberately still open, with a name on it, which is what "carried forward" has to mean.

Implementation planning is the last handoff before anything changes. The agent may read the repository and propose the files, the order, the risks, the tests, and the rollback. The artifact that persists is the implementation plan. The engineer decides whether the plan is ready before any mutation. The evidence permitting progression is the engineer-corrected plan naming affected surfaces, tests, and the rollback path. The lighter equivalent is a plan written as the first comment on the pull request, before the code exists.

The excerpt below is the worked template's plan for the same change. The risk line is the one that matters.

# Plan: faster account recovery (excerpt)
 
Affected surfaces:
- RecoveryService.decide(account, link) returns IssueSession or RequireStepUp
- StepUpPolicy.appliesTo(account) reads the payment-method flag; no changes
- RecoveryController routes RequireStepUp to the existing step-up flow
 
Order: policy check first, then the fast path, then the controller route.
 
Tests to add:
- RecoveryDecisionTest: payment-method account -> RequireStepUp  (AC2, C1)
- RecoveryDecisionTest: no payment method -> IssueSession       (AC1)
- RecoveryLinkTest: expired or reused link -> no session        (AC3)
 
Risk: the fast path bypasses StepUpPolicy if the decision is made in the
controller. Keep the decision in RecoveryService.
 
Rollback: turn the recovery.fast-path flag off. No data migration.

The plan names the policy module as a surface the change must consult, names the test that encodes AC2, and names a rollback that needs no migration. In the fixture, none of those lines existed, so the agent built exactly what it was asked to build.

Build is the stage most teams think of as the agent's job, and it is the least interesting one. The agent may edit the surfaces the plan names, call the tools it is allowed, and run the local feedback loop until it reports a real result. It may not widen the surface, and it may not touch the policy module unless the plan names it. The artifact that persists is the change itself on a branch, with a summary that links back to the plan. The engineer decides whether the implementation is acceptable and owns any departure from the plan; a departure is a reason to go back to the plan, not to press on. The evidence permitting progression is the executed test result, the commits, and the summary, not a description of tests that never ran. The lighter equivalent is the same rule enforced by habit, which is fragile, and by a pull request description that has to name the plan, which is less so.

Durable context is what carries a constraint between tasks, and it deserves one paragraph rather than a stage. An agent that starts every task from an empty window loses the same rule every time. The earlier article on an LLM wiki for software teams covers accumulated product context in depth, and the one on keeping Spring Boot delivery aligned shows repository instructions doing the same job at codebase level. Treat both as one artifact in this model: the place where C1 survives after the ticket is closed.

Where Less Is Right

A ten-row table can become ceremony, and ceremony would contradict the argument. Anthropic's December 2024 guidance on building effective agents separates workflows, which follow predefined code paths, from agents, which direct their own process and tool use, and recommends the simplest pattern that works. Anthropic notes that the tooling described there has changed since; the distinction has not. AWS makes the same point from the other side in its AI-DLC proposal: breadth and depth should adapt to the task rather than every task adapting to the workflow.

The ladder below is a conceptual representation of the rule stated earlier. Ceremony rises with the cost of a plausible wrong result and with how open-ended the reasoning is, and most changes belong on the first rung.

Plenty of changes need none of the artifacts above. A routine patch update inside an already approved dependency policy needs no intent record. A typo in a log message needs no acceptance criteria. A configuration change whose owner is already named in the repository needs a reviewer, not a plan. One model call that drafts a commit message from a diff is not an agent and should not be governed like one. For all of these, the existing pull request process is the lifecycle, and adding artifacts would slow the change without adding a decision.

The recovery fixture sits on the top rung for one reason only: a wrong result issues sessions to accounts that hold a payment method. A tidy pull request was therefore the wrong place to discover the policy, and the stage where the rule should have entered was the cheapest one, not the last one. Agent count is a separate question from lifecycle design; the multi-agent topology of an investigation pipeline is its own subject in this series and does not change any row of the table.

The model also bends on a small team. When the product owner, the engineer, and the release authority are one person, the chain collapses into one conversation, and that is fine. Two things should survive the collapse: the constraint still gets written where the next task can find it, and the release decision still has a name on it. Without those, a small team has the same failure with fewer people to notice.

What the Sources Show, Dated

The model above is analysis, not a summary of any vendor's process, but its shape is not invented either. The Claude Academy course, reviewed on 2026-09-02, organizes fourteen lessons over six stages from planning to maintenance and describes a chain in which the product owner corrects an intent record, an engineer corrects the plan before code is written, feedback loops and evaluations produce evidence before a person reviews, and production authority stays behind gates. Its stated audience is engineering, platform, and security leads in organizations already using Claude Code, especially large or regulated enterprises, and it assumes a repository and a CI pipeline the reader may change. Every stage here names a lighter equivalent for that reason. The course's artifact names, such as intent.md and plan.md, are its own choice; this model uses roles and records instead.

Anthropic's playbook, published on 2026-08-21, is the vendor's argument that cheap code generation moves the bottleneck. DORA's 2025 report, 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 matter. Read that as a warning about the delivery system rather than a productivity result. This article adds no number to it. IBM and Salesforce, cited in the glossary, describe a different lifecycle, the one for building and operating an agent, and treat evaluation and observability as lifecycle concerns for the agent itself; the same discipline applies when the agent is a participant in delivering something else.

None of the sources establishes that agent participation improves delivery outcomes in general. The vendor pages describe capability, the framework sites describe proposals, and the research page describes a system property. More agent activity is not evidence of better delivery. It is load on whichever parts of the delivery system were already weak, and the fixture shows where that load lands.

The Unresolved Part Is Measurement

The question this article cannot close is what to watch. The fixture would have looked like success on any dashboard that counts merged pull requests, and a count of corrections after merge rises with volume whether or not the workflow got better. I do not have a clean answer for which signal a team should watch first, and I am suspicious of anyone who does. What I am sure of is the smallest useful next move: write down one constraint where the next task will find it, and put one name on the release decision. Then look at what changes.