A Green Build Is Not a Working AI Product
I have seen the word “done” used for seven different states of the same AI feature.
The code existed locally. Tests passed. A pull request merged. A deployment completed. An endpoint returned 200. A page rendered. A real user completed the intended job.
Only the last state tells us that the product worked. The other six are useful evidence on the way there.
I call this the Release Proof Ladder. Each rung proves something different, and no rung inherits the meaning of the one above it.
AI products make this distinction more important because their most serious failures often look like successful execution.
Software can fail loudly. AI often fails fluently.
A conventional form either saves the record or throws an error. An AI system can return a grammatically complete answer while omitting the one clause that changes its meaning.
That answer may pass transport checks, schema validation and snapshot tests. The deployment is healthy. The product is wrong.
This is one reason agent evaluation now focuses on multi-turn behaviour, tool use and changed environments rather than one final string. Anthropic’s current evaluation guidance separates the task, trial, grader, transcript and outcome because useful agents act over time. That structure is closer to a product journey than a prompt test.
The same distinction applies outside model evaluation. A production release needs evidence at several levels.
| Rung | What it proves | What it does not prove |
|---|---|---|
| Local change | The intended implementation exists | It integrates or survives a clean environment |
| Focused test | A named contract passes | Adjacent journeys still work |
| Merge | The candidate entered the canonical codebase | It reached any running system |
| Staging | The candidate runs with production-like dependencies | Production identity, data and permissions are correct |
| Deployment | Infrastructure accepted the release | A person can complete the job |
| User journey | One person completed one intended job | The system will remain reliable |
| Observation | The journey holds across time and variation | Every future case is safe |
Status reporting becomes much more honest once the team names the rung.
“Merged” is useful. “Deployed” is useful. Neither needs to borrow the word “working.”
The ladder also makes parallel work easier to coordinate. One person can own implementation, another can certify the staged journey and an operator can own the production observation window. Everyone can see which question remains open. Without named rungs, six people can report progress while nobody owns the final customer result.
The exact candidate has to climb the ladder
Teams sometimes combine proof from different versions without noticing.
A local branch passes tests. A slightly older commit is on staging. Production responds to a smoke test. A screenshot from yesterday shows the desired interface. Individually, each artifact is real. Together, they prove very little about one release.
The ladder only works when the same candidate moves upward.
That means attaching evidence to an immutable release identity: a commit, build or artifact that can be followed through focused tests, staging, deployment and the final journey. If a fix lands after staging verification, the candidate changed. The relevant checks need to follow it.
This feels slower when a team is rushing. It is faster than debugging a production state assembled from assumptions.
AI requires two journeys: the happy path and the refusal path
Normal product testing concentrates on successful completion. An AI product also needs proof that it refuses unsafe completion.
If a research agent cannot fetch the primary source, does it expose the gap or fill it with a nearby article? If a conversation system has incomplete audio, does it label the finding or silently construct one? If an action agent lacks permission, does it stop before mutation? If a learning system cannot ground feedback, does it admit that or improvise authority?
The refusal path is where product policy becomes visible.
| Successful journey | Refusal journey |
|---|---|
| Sufficient evidence is present | Evidence is missing or contradictory |
| The user can inspect the basis | The user can see why progress stopped |
| The permitted action completes | No unauthorized state changes |
| A receipt records the result | A receipt records the failed precondition |
An agent that succeeds on the demo and invents its way through the missing-data case has passed half a test.
Device reality is part of the release
One recording interface we built had a waveform that looked alive in a simulator and passed its component checks. The remaining question was more ordinary: did it respond truthfully to a person’s voice on a physical phone, at the size and conditions in which it would be used?
That is not visual polish. The waveform is evidence that the microphone is listening. A convincing animation driven by the wrong signal makes the product feel functional while concealing a capture failure.
The release therefore needed a physical-device rung. Install success did not satisfy it. A screenshot did not satisfy it. Real speech, interruption, pause, resume, save and recovery did.
Different products add different rungs. The principle is stable: if the customer experiences a boundary, release proof must cross it.
Operational evidence belongs inside “done”
Cloudflare’s durable-agent guidance treats each model or tool call as an independently retryable step and resumes a workflow from its last successful checkpoint after interruption. That capability improves runtime durability. A product team still has to prove that retries do not duplicate actions, that resumed work uses the right identity and that the final result reaches the user.
Monitoring is also not a substitute for progress. Watching a long job proves that someone watched a long job. It does not move the candidate up the ladder unless the observation closes a defined release question.
For systems that run continuously, the final rung should have an explicit window and failure budget. “No alert in the last hour” is weak. “The scheduled job produced the expected artifact for three consecutive runs, with no duplicate action and a verified cleanup receipt” is a claim someone else can challenge.
This is the operating discipline behind How to Monitor AI Agents in Production. Monitoring becomes meaningful when it is attached to an exact product promise.
What I got wrong
I used to treat deployment as the finish line and production checking as follow-up. That works when the final uncertainty is mostly infrastructure. It breaks when the product’s value depends on an unpredictable input, a model judgment, a permission boundary or a physical device.
Now I treat the whole release as the unit of completion. Breadth comes before depth: one complete journey through one exact candidate before the next layer of capability becomes active.
The hard question is organizational. Most tools reward code movement, test completion and deployment speed because those events are easy to count. Real user proof is slower, messier and owned by several people at once. How should a team measure delivery when the most valuable rung is the least convenient one to automate?