Waterfall
Right when the work is well understood and the cost of change is high. A data centre, a regulated migration.
Blackstone& field note · for delivery and technical leads
How do we know it’s done?
Most software can answer it: the tests pass, the spec is met, it ships. An agentic system cannot. Its inputs are unbounded and its output varies across them, so there is no finished state to point at. Knowing it is done becomes a measurement you keep making, with evals.*
Waterfall, agile and probabilistic delivery are three answers to that one question, for three different kinds of work. And the third is less new than it looks: it keeps waterfall's gates and agile's short cycles, and the core change is at the engineering level, where a binary "done" becomes an eval bar, with funding, sponsor reporting and the kill mechanism following from it.
* An eval is an automated quality check for an AI system: a set of real examples with agreed good answers, scored on every change. Where deterministic software has tests that pass or fail, an agentic system has a score against an agreed bar.
The same probabilistic build, run three ways · confidence over time
01 / Waterfall
Confident, then integration
02 / Agile
The demo overstates
03 / Probabilistic
A measured band
Match the method to the determinism of the work.
Agile
Right when the software is deterministic but the requirements move. Short loops turn change into feedback.
Probabilistic
Right when the output itself is probabilistic. "Done" is a measured band, not a fixed state you inspect once.
A healthy portfolio runs all three. Agentic systems are the third kind of work, and fit cuts both ways: the wrong method is expensive in either direction.
01
Waterfall
Built for known work · answers it with a plan
Requirements›
Design›
Build›
Test›
Deploy
Why it exists
When the work is well understood and change is expensive, fixing scope, cost and date up front is the rational choice. The plan is the contract.
Where confidence comes from
The plan. Progress is reported as the percentage of planned artifacts complete against it.
Where it breaks for agentic work
The requirements were frozen against a deterministic picture a probabilistic system never matches. Confidence reads high and stays high, right up until integration proves it false, at the end, where a fix is most expensive.
The practice underneath · phase gates
Confidence over timeon probabilistic work · perceived
When you learn you were wrong: at the end.
02
Agile / Scrum
Built for moving requirements · answers it with a working increment
Backlog›
Sprint›
Increment
↶ repeat every sprint
Why it exists
When the software is deterministic but requirements evolve, short loops turn uncertainty into feedback. This was a real advance, and for most software it is still the right answer. We are not arguing against it.
Where confidence comes from
A working increment each sprint, meeting a Definition of Done, backed by automated tests and CI/CD.
Where it breaks for agentic work
The instruments are binary. A test passes or fails; the Definition of Done is met or not; the demo stands in for production. Those instruments are right for deterministic software and mis-measure a probabilistic deliverable: the demo works, which is not the same as "it works 92 percent of the time on live traffic." You can write an eval threshold into a Definition of Done. What you cannot write in is the unknown number of experiments it takes to reach it, or a demo that behaves like the live traffic distribution. And velocity presumes the work is estimable, when agentic work is research.
The practice underneath · the sprint loop
Confidence over timeon probabilistic work · perceived vs actual
When you learn you were wrong: at the sprint review, and the demo overstates live traffic.
03
Probabilistic
Built for agentic systems · answers it with a re-verified eval band
Domain›
Intent›
Spec + evals›
Build agent›
Harden›
Monitor
↶ iterate to the eval bar under flow, not fixed sprints
Why it exists
The output is probabilistic, so "done" is not a state you inspect once. It is a measured band you hold and keep re-earning. The number of iterations to clear the bar is unknown before you start, so the work runs as flow, in short plan-build-review cycles, and money releases the same way, an eval-gated tranche at a time.
What it keeps from the first two
Waterfall's gates, for control and funding. Agile's cyclical working and Kanban flow, for learning. Teams keep the rituals they already run, even as work to the eval bar flows rather than fitting a fixed sprint; the change starts at the engineering level, where a binary definition of done becomes an eval bar, and funding, sponsor reporting and the kill mechanism follow from that shift.
Where confidence comes from
A measured range, re-verified on every change. Done is a floor you hold, for example at least 92 percent on our own eval set. A golden dataset sets the bar; an eval gate in CI blocks any regression past it; the uncertain tail routes to a human; live traffic is monitored for drift.
When you learn you were wrong
Continuously, in production, on purpose, with guardrails and monitoring capping the cost of each lesson. Visible uncertainty beats false precision.
Where it breaks in turn
On deterministic work. If a rules engine or a plain service clears the job, an eval harness is overhead for certainty you already had. Fit cuts both ways.
The agentic work card · the unit of work, not a story
- intentthe outcome and why it matters, human owned
- eval barthreshold scored across an owned test set
- confidencethe calibrated score below which it must not act, and what it does instead
- guardrailsrefusals and the never-do list
- data classthe sensitivity tier it may touch
- cost budgettokens and cost per outcome, with a degrade path
The practice underneath · the eval loop
Confidence over timea measured band
When you learn you were wrong: continuously, in production, on purpose.
≥ 92%
The bar in this note is 92 percent on an owned eval set. The number is an example; the mechanism is the method: a floor you hold, and re-earn on every change.
How do we know it’s done? Three answers.
Read down the last column. It is not a better version of the first two; much of it is borrowed from them. It is the accurate answer when the deliverable is probabilistic, and it is the standard an agentic system needs.
| Waterfall | Agile / Scrum | Probabilistic | |
|---|---|---|---|
| What is fixed up front | Scope, cost, date | The goal and the process; scope stays open | The intent and the eval bar, not the solution |
| What is delivered | One integrated release, late | A shippable increment each sprint | A monitored system that holds an eval threshold |
| How assurance is expressed | Percent of plan complete | Tests pass, Definition of Done met | Eval score on an owned dataset, plus live monitoring |
| When you learn you were wrong | at the end | at the sprint review, on demo evidence | continuously, in production |
| What the sponsor sees | A plan burning down | A working demo | A confidence range with guardrails and cost per outcome |
| How funding releases | One budget, up front | Stable team, rolling budget, burn per sprint | Eval-gated tranche funding: a plan and a kill switch at once |
| Kill or change mechanism | Change request, expensive | Re-prioritise the backlog | Fail the gate, stop or reroute, cheap by design |
Lineage, stated plainly: continuous delivery for machine learning is Thoughtworks ground, CD4ML through to their current AI-native engineering work. DORA's 2025 evidence on AI-assisted delivery, humans building with AI, points to the same discipline: trust comes from instrumentation, not impressions. Practitioners have framed done for probabilistic software as acceptable variance. Stage-gate funding, where a review releases the next tranche, has been enterprise practice for decades. The parts are known ground. The synthesis, and the determinism axis it hangs on, is what we bring.
Running an agentic build, gate by gate.
In our experience, many organisations have never taken an AI build all the way to production. The gap is rarely ambition, budget or tooling. It is the delivery method. A probabilistic system needs the third path: domain-bounded and funded by eval-gated tranches, with the agentic work card, the golden datasets, the guardrails and the monitoring in place from the first week.
Why gates replace a fixed plan
You cannot promise a date for research. What you can promise is a sequence of small, bounded bets, each one funded only when the last has cleared its eval bar on real data. We call the mechanism eval-gated tranche funding: money follows evidence, every gate is a value checkpoint and a place to stop, and uncertainty is bounded rather than pretended away.
The method, the assets and the gates outlive the first delivery: run them once, keep them, and the next build starts further up the curve.
What a sponsor holds, gate to gate
Evidence
An eval score per gate, on real data, not a status report.
Control
A kill switch per tranche, priced in and cheap to pull.
Economics
Cost per outcome, with a degrade path agreed before an overrun.
The five gates
Frame
Domain boundaries, intent, and the eval bar: what "good" means, made measurable.
Prove
Golden datasets, a first end-to-end slice, the first eval gate passing on real data.
Build
Iterate to threshold under flow, card by card, guardrails and cost budgets on.
Harden
Integration, human-review checkpoints, rollback, cost per outcome inside budget.
Operate
Monitor for drift, re-verify evals, and transfer the capability to your teams.