Acceptance tests an agent writes and a human arms.
The hard part of trusting agent output is not running checks — it is knowing the checks mean something. A verified flow is a browser-level acceptance test, authored by the agent that built the feature, approved by a person, and replayed identically on every run that follows.
- goto/checkout
- fillcard number
- clickPay now
- assertorder confirmation visiblenot reached
- 01
An agent proposes the flow
While working on a change, an agent drives the run’s live preview in a real browser and records what it did as an ordered list of steps — navigate, click, fill, assert, screenshot. It submits that list as a draft flow against the repository.
The steps are validated against a schema before they are stored. A flow is data, not a script we execute blindly.
- 02
A human approves it
Drafts sit in the repository’s Flows tab until someone approves them. Nothing an agent writes enters the gate on its own say-so, which is the entire point of a gate.
Approved flows are versioned against the commit they were generated from, so you can see when one was written and by which run.
- 03
It replays deterministically
On every later run, each approved flow replays against that run’s own preview deployment. The replay is a browser executing stored steps — no model is involved, so the same flow produces the same verdict for the same build.
A run that never served the repository’s app is skipped rather than failed. Filing a false failure is worse than filing nothing.
- 04
The replay is the evidence
Each replay records its own video, saves screenshots at the points the flow asked for them, keeps anything the flow downloaded, and writes a per-step pass or fail. The result is attached to the run, not to a dashboard somewhere else.
Each replay is filmed separately. An earlier version reused one recording for every flow, which made the videos worthless as evidence.
A flow that asserts nothing after its last click is an error, not a pass.
We learned this from our own gate. A sign-up flow filled the registration form, took a screenshot, and reported green — for weeks — while proving nothing about whether an account had actually been created. A check that cannot fail is not a check; it is decoration that makes everyone downstream more confident and less safe.
So the rule is enforced at replay time rather than only when the flow is written: every approved flow is re-examined on each run, and one that ends without asserting an outcome is recorded as an error with that reason attached. Flows armed before the rule existed are held to it too.
Evidence, per replay
Everything below is stored against the run, addressable per replay, and scoped to your organization.
Per-step results
Which steps ran, which passed, and where it stopped — not a single red or green light for the whole flow.
A video of that replay
Filmed for that flow, on that run, paced so it is watchable rather than a one-second blur.
Screenshots at the asserted points
Taken where the flow asked for them, so the claim and the picture are the same moment.
Anything the flow downloaded
A generated export or report is evidence too, and it is kept with the replay that produced it.
What this does not do yet
- The replay happens after the pull request is opened, not before it. A red gate is recorded on the run with its evidence; it does not yet block the pull request or the merge. Making it blocking is the next step, and we would rather say that than let you assume it.
- The gate is best-effort by design today: if the replay infrastructure itself breaks, the run is not failed for it. That is the right default while the gate is young and the wrong one once it is trusted.
- Flows cover what a browser can drive. They do not replace unit tests, they do not reason about architecture, and they cannot tell you the ticket was wrong.
- The gate result is not yet written onto the pull request body. It lives on the run.