The Confidence Problem
Every engineer who has worked with AI agents has collected a version of this story: the agent announces success — clearly, articulately, with a summary of everything it accomplished — and the work is not done. A test was skipped. A file was edited but never saved. The deploy went out but the feature flag stayed off. The summary was written by the same process that did the work, and that process wanted to be finished.
This is not a model quality problem that better models quietly fix. It is an incentives problem baked into the architecture. When the worker grades its own work, the grade measures the worker's belief, not the world's state. Humans have the same failure mode; that is why code review, CI, and change management exist. We spent decades building institutions on the premise that the author's confidence is not evidence — and then wired up agents that report their own completion and called it automation.
The fix is not prompting the agent to "be careful." The fix is structural.
Verification Is a Role, Not a Step
In a Skyflo mission, verification is performed by a separate agent that wrote none of the code.
This sounds like a small design choice. It changes everything about what the phase means. The verification agent has no investment in the implementation being correct. Its context is not polluted by the plan's assumptions or the implementer's rationalizations. Its only inputs are artifacts: diffs, test results, CI runs, canary metrics, runtime behavior. Its only job is to answer one question — does the evidence support the claim that the objective is met?
Because it is a distinct role, it can also run on a different model. Verification is largely a reading task: cheaper, smaller, or fully local models handle it well. Teams that route implementation to a frontier model and verification to a local one get an auditor that is always on and costs almost nothing — the model routing is per role, not per product.
The implement-verify split mirrors something engineering already believes. We do not let authors approve their own PRs. The surprise is not that agents need the same structure; the surprise is how long we shipped agent products without it.
The Evidence Chain
"Verified" has to decompose into something checkable, or it is just "done" with extra letters. Skyflo structures it as a chain, and every link must hold:
- Change — the diffs exist, are linked to the mission, and match the plan's scope. Nothing merged outside it.
- Tests — new behavior is covered; the suite passes; coverage did not silently rot.
- CI — the full matrix is green across every affected repository, not just the one that was easy.
- Delivery — artifacts built, signed, and rolled out where the plan said they would be.
- Runtime — the system behaves: error rates flat, latency inside budget, the new behavior observably active in production.
The chain is the claim's anatomy. When someone asks "is the rate-limiting work actually done?", the answer is not a sentence — it is a report: 4 PRs merged, 63 tests passing, CI green across the matrix, canary at 50% with a 0.02% throttle rate hitting only synthetic abusers, p99 latency +0.4ms against a 1ms budget, 24/24 pods rolled out.
Any link that cannot be established is surfaced as exactly that: an unverified claim. The mission does not complete on charisma.
Runtime Is Part of the Definition of Done
The most common gap in engineering verification — human or agent — is stopping at CI. Green checks mean the code does what the tests say in a clean room. Production is not a clean room.
That is why the chain extends through delivery into runtime, and why a mission holds itself open through the canary. A change that passes every test and degrades p99 by 40ms did not land; it detonated slowly. An agent that closes the loop only at "checks passed" would have reported success. The verification agent watching runtime metrics reports what actually happened — and if the outcome regresses, the mission is not done, no matter how good the diff looked.
This is also where the approval gates earn their keep. The steps with irreversible consequences — production mutations, infrastructure changes — paused for a human before execution. Verification then confirms the consequences were the intended ones. Gate before, evidence after: judgment and proof, in that order, neither replacing the other.
What Evidence Buys You
Three things, compounding:
Trust that scales past supervision. The reason teams keep agents on a short leash is that unverified success reports make delegation feel like gambling. An independent evidence chain is what makes it rational to hand over bigger objectives. You are no longer trusting the worker; you are trusting the audit.
An honest failure mode. When a mission cannot verify, you learn which link broke — the tests never covered the new path, the canary showed a regression, the rollout stalled at 8 of 24 pods. That is a debuggable state, not a mystery.
A record worth remembering. When the outcome is written to engineering memory, it carries its evidence with it. Six weeks later, "why do we cap tenant burst rates at 2x?" resolves to a verified record linked to the mission that established it — not to an archaeology expedition through chat logs.
"Done" stops being a feeling reported by the process that most wants to be finished, and becomes a state of the world you can check. That single substitution is most of what it takes to trust engineering work you did not do yourself — which is, in the end, what an agent is for.