Worked exampleAI Delivery Lifecycle

One idea. Eight phases.
Every consequential step approved by a human.

The AI Delivery Lifecycle page sets out the model and the return. This page shows it working: one concrete product idea travelling end-to-end through AI Product Studio — the screens a Product Owner touches, the agents on duty at each phase, the decisions only a human makes, and the artefact that carries forward at every hand-off.

“Our customers keep asking to pull their invoice history into a spreadsheet. Can we let them export invoices as CSV?”
Priya, Product Owner at Lumen Billing — a nine-person team behind a subscription-billing product. Her finance customers copy invoice data into spreadsheets by hand.
Start with AI Product StudioRead the AIDLC model

Lumen Billing and Priya are fictional. The screens, agents, gates and rules on this page are the real product — and the usage numbers in the story are illustrative, not measurements.

How to read the journey

Every phase below repeats the same four elements, so the pattern is visible: a screen, an agent, a human decision, an artefact. That repetition is the governance model.

  • On screenThe Studio pages Priya touches, named exactly as they appear in the product navigation.
  • Agents on dutyThe roster agents that act at this phase — and what each one actually does.
  • Human decisionThe gate a person holds. Nothing consequential proceeds without it.
  • Carried forwardThe artefact that moves to the next phase — every hand-off is a named, auditable thing.

From a sentence to a shipped, measured outcome

Intent → Context → Plan → Code → Review → Verify → Release → Telemetry — the same eight phases the Studio's Delivery Loop navigation walks in order.

  1. Intent

    On screen:Intent Pad

    Priya types the idea into the Intent Pad exactly as her customer said it — no template, no form-filling. Because the Intent Classifier is enabled on her roster, the capture is triaged straight away: kind set to opportunity, urgency medium, the title sharpened to "Invoice history export (CSV)", and a suggested link to the studio's accepted outcome "Cut finance-admin effort for customers".

    • Intent Classifier Sets the kind, urgency and title, and suggests which strategic outcomes the intent serves. It is barred from inventing acceptance criteria or a technical solution — those belong to later phases.
    Human decision

    Priya accepts the classification and links the outcome. An intent no human stands behind goes no further.

    Carried forward A classified intent, tied to a strategic outcome.

  2. Context

    On screen:Context LibraryCode Repositories

    The studio is connected to Lumen's billing repository — read-only, over a scoped access token. Priya runs a scan from the Code Repositories page: the Codebase Analyser explores the file tree, derives the tech stack and hosting set-up, and proposes context entries — plus a couple of candidate tech-debt intents it spotted along the way. Every proposal lands in the Recommendations queue; nothing is applied automatically.

    • Codebase Analyser Reads the connected repository and surfaces tech stack, hosting and architecture notes as recommendations for human approval. It never modifies a file and never creates anything without a person accepting it first.
    Human decision

    Priya and her lead engineer approve the useful entries into the Context Library and discard the rest.

    Carried forward A Context Library grounded in the real codebase — the background every later agent run draws on.

  3. Plan

    On screen:IntentWork Packages

    Priya opens the intent, drafts its brief and lets the Composer break it down in three AI-drafted passes — workstreams, then a work package under each, then the work items on each package — with Priya editing as she goes. The stories carry Given/When/Then acceptance criteria ("Given a filtered invoice list, when I choose Export, a CSV of the visible columns downloads"). The Architecture Advisor reviews the approach against the Context Library and recommends reusing the existing reporting endpoint rather than adding a parallel data path — risk assessed low.

    • Architecture Advisor Assesses impact and risk against the recorded architecture and recommends patterns. It recommends; humans decide.
    • Test Architect Writes the test plan into the package's Plan as a Definition of Ready item — happy path, edge cases and failure modes across unit, integration and end-to-end layers — so the coding agent builds to it.
    Human decision

    Priya approves each Work Package — its scope, acceptance criteria, the agents selected for the build, and the studio's Definition of Ready and Definition of Done snapshotted onto it. Below full autonomy, this gate is always human.

    Carried forward An approved Work Package, ready to dispatch.

  4. Code

    On screen:Work PackagesRun Board

    Priya dispatches the approved package to one coding agent — here the studio's own runner — and the run appears on the Run Board with its cost and status. The test plan the Test Architect wrote at readiness travels in its brief. The coding phase runs to a strict contract: the agent works from the approved plan and the scanned codebase, and its output is a file-by-file change proposal — path, operation, content, and the reasoning behind each change.

    No agent commits to Lumen's repository. Ever. The proposal is the deliverable. A human reads the diff, and a human merges it. That is not a caveat on the design — it is the design: AI delivery you can put in front of an auditor.
    • Code Generator Implements the approved work package as a commit-ready change proposal, scoped to that package, with any new dependency flagged rather than smuggled in.
    Human decision

    Priya's engineer acknowledges each run's plan before it proceeds and answers agent question-backs on the Run Board.

    Carried forward A reviewable code proposal per work package — diff plus reasoning — with the cost of producing it on the record.

  5. Review

    On screen:Review feed

    The Definition of Done reads the pull request, and the Review feed shows what each agent wants from it. The Code Reviewer checks the change against Lumen's policies and style guide; the Security Scanner runs OWASP-guided checks — and on an export feature it looks exactly where you would want it to: is the CSV endpoint tenant-scoped? Could a crafted invoice field smuggle a formula into the spreadsheet? One package bounces — the invoice query missed the tenant filter — and goes back with changes requested.

    • Code Reviewer Delivers a verdict with file-and-line comments — approved, approved with comments, or changes requested.
    • Security Scanner Reports severity-tagged findings, and cannot suppress one without a documented human risk acceptance.
    Human decision

    When an agent cannot decide an item it asks a question, and Priya answers it on the Review feed — the answer goes to the coding agent's pull request, and the item is reassessed. Every decision on the gate is recorded: who, when and why.

    Carried forward An approved change with a recorded review verdict and a clean scan.

  6. Verify

    On screen:Verify

    The Work Package's Definition of Done — snapshotted when the package was created, so nobody can quietly move the goalposts — is checked item by item. Each item has a named assignee, agent or human: all automated tests pass, no critical or high security findings, accessibility to WCAG 2.2 AA, documentation updated. A green suite can pass automatically; a failure always waits for a human.

    • Test Architect Accountable for the testing items on the checklist — unit, integration and end-to-end suites green.
    • Compliance Auditor Accountable for the control items — and barred from marking a check passed without the underlying evidence.
    Human decision

    Priya closes the human-assigned items and confirms the checklist is honestly complete.

    Carried forward A Definition of Done with every required item evidenced.

  7. Release

    On screen:Release planRelease comms

    The completed work packages — Definition of Done passed, pull requests merged — go onto a release on the Release plan, and the release names what it should move: fewer tickets asking for invoice copies within 30 days. It records the release honestly; it does not deploy behind anyone's back — deployment stays with Lumen's own pipeline. Sign-off is two-key: the server's readiness check plus a named human, at every trust level. On Release comms, the same release becomes write-ups for customers, for support, security and operations, and a formal change record for an auditor — each approved before it goes out.

    • Release Publisher Drafts each audience's release comms from the release record alone — the packages, their Definition of Done evidence and the approvals — and says so when the record does not state something.
    Human decision

    Priya gives the second key. Her name is on the release.

    Carried forward A shipped increment traceable back to the sentence typed on the Intent Pad.

  8. Telemetry

    On screen:Outcome TelemetryOutcome Feedback Loop

    After release, the team records real readings against the key result the release named. The Telemetry Analyst analyses those readings — and only those: when there is no data it declines to run rather than inventing a trend. In the story's readings, finance users adopt the export quickly, tickets asking for invoice copies fall away, and one pattern stands out: customers export a CSV and immediately re-import it into their accounts package. That is not a bug — it is the next opportunity.

    • Telemetry Analyst Judges each release against what it said it would move — on track, behind, regressed or inconclusive — from the readings in its window, with a hard rule against reporting telemetry that was not observed.
    Human decision

    Priya decides which insights become new intents — a release that falls behind raises a course correction she can accept or reject; nothing becomes an intent on its own. The candidate accounts-package integration goes onto the Intent Pad — and the loop starts again, this time with a Context Library that already knows the codebase.

    Carried forward Evidence the outcome moved — and the next classified intent.

What’s on the record when it’s over

The idea went from words to a shipped, measured outcome — and the evidence assembled itself along the way. The Audit Explorer holds all of it, with nothing to reconstruct after the fact.

  • The original intent, and who accepted its classification
  • Every context entry, and who approved it into the library
  • The approved work packages — scope, acceptance criteria, selected agents
  • Every agent run, with its plan, cost, duration and output
  • Every review verdict — who, when and why
  • The Definition of Done, item by item, with evidence
  • The named human whose sign-off shipped the release
  • The telemetry that says whether it actually worked
That repetition is the point. A screen, an agent, a human decision, an artefact — eight times over. Nothing consequential happened without a person deciding it, and nothing decided went unrecorded. This is what governed, auditable AI delivery looks like when you follow a single idea all the way through. For the mechanism behind it — the compounding, the ROI model and the adoption ladder — read the AIDLC page, or explore the Studio itself.

Run your own idea through it

Start with one intent, one squad and the supervised trust level — every gate on, every step recorded. The journey on this page is a four-week commitment, not a transformation programme.

Create your studioThe AIDLC model & ROI caseExplore AI Product Studio