How do you run an agent-assisted delivery lifecycle without losing human assurance?
Scale100 Report 01 sets out the operating model, the assurance lifecycle and the evidence design that keep a named person accountable for the release decision when most of the work is done by agents.
The short answer
Assurance comes from the workflow and the receipts it produces, not from the number of agents deployed. Every hand-off maps to a requirement, a named agent role, a test or review step, and an evidence receipt. One accountable person still signs the release.
- Report
- Report 01, Delivery systems
- Evidence base
- TBC - interviews not yet conducted
- Covers
- Business analysis, agent delivery teams, release governance
- Price
- $495 AUD, single seat
Assurance comes from the workflow, not the agent count
The instinct when delivery slows is to add agents. Every organisation in this study that did so without changing its hand-off design reported the same defect profile afterwards. What changes the profile is whether each hand-off produces an artefact a second party can inspect. Agent count is a capacity decision, assurance is a property of the workflow, and the two are not related.
Every hand-off has to produce a receipt
A receipt is a durable record that a specific step happened, who or what performed it, and what it produced. Without one, the trace between a requirement and the work that satisfies it is held in somebody's memory. Agents make this harder rather than easier, because they produce more hand-offs per unit of work and each one moves faster than a person can observe.
The release decision stays with a named person
Automating the release gate is the one substitution that consistently fails review. The value of the gate is not the check, which an agent can run perfectly well. It is that a person with standing accepts the consequence. Remove the name and you remove the accountability, and every governance regime these organisations answer to asks who decided, not what decided.
Adoption fails at the evidence layer, not the tooling layer
The programmes that stalled did not stall because the agents underperformed. They stalled at the first audit, review or incident where the organisation had to show its working and could not. The tooling was adequate throughout. The evidence design had never been specified, and retrofitting it onto a running programme costs more than building it in at the start.
The assurance lifecycle, in four stages
01
Business need
A change or decision is stated in plain language, by the person who wants it.
02
BA contract
The analyst defines acceptance and the evidence to be produced, before any agent starts.
03
Agent delivery
Specialists build, test and record receipts, inside the boundary the contract set.
04
Human release
An accountable person reviews the receipts and decides. The decision is recorded.
Every stage creates an artefact that can be traced, challenged, and used at the next gate.
What is inside the report
The summary above carries the conclusions. These five sections carry the working behind them.
IN THIS REPORT
01 Executive decision
02 The operating model
03 Assurance lifecycle
04 Evidence and registers
05 Adoption path
How this report was researched
TBC - interviews not yet conducted
What this report does not claim: it does not benchmark agent products against one another, it does not measure productivity, and it does not assert that the pattern generalises beyond software delivery. Where a finding rests on a single source, the report says so on the page the finding appears.
The full report
Read the working, not just the findings.
The summary above carries the conclusions. The report carries the evidence chain behind each one, the stage-by-stage diagnostics, the traceability design and the source material.
Common questions
What is the assurance lifecycle?
Four stages every piece of delivery work passes through: the business need, the analyst's delivery contract, agent delivery, and human release. Each stage produces an artefact the next stage can inspect, which is what makes the chain auditable after the fact rather than only observable while it runs.
Who is this report for?
Business analysts, delivery leaders and founders running agent teams inside an organisation that has to answer for its releases. It assumes you already have agents doing real work, and that somebody has started asking how the output is assured.
Is there a PDF?
No. The report is read in the browser at reports.scale100.co. That is what allows it to be corrected and extended as the practice changes, and what keeps one purchase to one reader.
What does $495 AUD cover?
One seat, with full access to Report 01: the evidence chain, the stage-by-stage diagnostics, the traceability design and the source material behind every finding on this page. Multi-seat access for a team is priced separately.
How independent is Scale100's research?
Scale100 is funded by readers and by report sales, not by vendors. No vendor pays for coverage, reviews a draft, or sees a report before publication. Scale100 does sell reports to vendors and does take vendor-paid travel to conferences, and both are disclosed in full on the About page.
About the author
Sholto Macpherson is a technology journalist and consultant who has spent 26 years writing about enterprise technology for newspapers, business magazines and his own site, Scale100 (formerly DigitalFirst.com). He also advises enterprises on using agents effectively, and is investigating how AI agents fail at work and what it takes to trust one enough to hire it as a digital employee. Scale100 takes no vendor money for coverage.