Watch & compare
Harness engineering
Different ways to see the same idea. Play one cut at a time, then return to the guide to try it yourself.
Why we recommend Prove the patch
Astra makes the acceptance rule concrete: the same 200 response passes for the invoice owner and fails for another tenant, then both checks run again after repair. Its larger labels and explicit ready-for-human-review ending make it the clearest main chapter entry for a team adopting agents. Keep baseline for session continuity and fable for the distinction between a completion claim, a test result and a persistent record.
Revised original · 26 sec
Resume work
A saved workspace and verified progress record let a fresh session resume pending work after startup checks.
Read the video sequence
- 0–9s: Resume work. Session 1 changes task A, runs its check, and records A as verified; B remains pending.
- 9–17s: Session 1 ends. Its workspace and progress record survive. Session 2 reads the record, identifies B as pending, initializes the workspace, and runs a startup smoke check. This check does not establish complete regression coverage.
- 17–26s: Session 2 changes B, runs its check, and records B as verified. A remains recorded from the earlier run; B is not evidence that all of A was retested. Both recorded results hold, then the whole frame fades to black.
About this cut
Production: Original prototype; model not recorded.
Revision: gpt-6-astra comparative review.
Original model was not recorded; comparative editing is not original authorship.
Illustrative session handoff. A startup smoke check is not comprehensive feature revalidation; saved progress can become stale after subsequent edits.
Audio analysed, not heard. Phone legibility checked on 350px decoded frames, not a physical device.
Recommended · Astra · 28 sec
Prove the patch
Use executable acceptance checks to return failures to an agent, rerun evidence after a repair, and hand the result to a human reviewer.
Read the video sequence
- In this illustrative invoice service, an agent proposes patch 1. The harness runs a request from the customer who owns the invoice. It returns 200, meaning success, and satisfies the first check. The second check has not run.
- A different customer also receives 200. That violates this example’s agreed access rule, which expects denial with 403. The second check turns red and the change is blocked from advancing to a ready-for-review state.
- The harness sends the failure back to the agent. At 11.40s the agent produces patch 2 and both old check results clear in the same frame, because they describe the previous patch.
- The harness runs both checks again. The owning customer still receives 200; the other customer now receives 403. Both satisfy the stated contract. This demonstrates two passing checks, not complete security.
- The harness sends the evidence to human review and marks it ready. No deployment or human approval is assumed. The resolved state holds, then fades to black. The diagram assumes working check controls; stored instructions alone cannot enforce permissions.
About this cut
Production: gpt-6-astra.
Revision: gpt-6-astra comparative review.
Scripted illustrative invoice scenario, not a recorded agent repair or a guarantee of agent reliability.
The example contract uses 403 for another tenant; that response is not a universal authorization policy, and two checks do not establish complete security or correctness.
The diagram shows the execution/check slice of a harness. Persistent prompts and progress records do not enforce permissions; actual controls and their configuration do.
Audio cues, levels, and spectrogram were analysed; audio was not physically listened to.
Originally self-reviewed; now also compared independently from author reviews against all three encoded cuts at full resolution and 350px width. No learner study or physical-phone test.
Alternative · Fable · 28 sec
Done means verified
An agent's "done" is a claim; the harness runs the end-to-end check and flips a feature to passing only on its own evidence, so a failed claim goes back to the agent while the record stays false.
Read the video sequence
- The agent works on feature A, then sends the harness a DONE claim. The feature list row for A turns orange: claimed but not yet verified.
- The harness runs the end-to-end tests for A. They pass, and only then does the harness write "A passes:true" to the feature list, which turns green.
- The agent works on feature B and sends the same DONE claim. The harness runs the tests for B and they fail.
- The feature list row for B stays "passes:false"; the harness returns the failed claim to the agent, which jolts red. The claim alone changed nothing.
- The agent fixes B and claims DONE again. The harness re-runs the tests, they pass, and "B passes:true" is written with a chime: both features now have recorded passing checks. A remains recorded from its earlier run; this sequence does not show A being retested after B changes.
- The list holds both features green, then the frame fades to black.
About this cut
Production: anthropic/claude-fable-5-1.
Revision: gpt-6-astra comparative review.
Audio verified analytically (peak -6.6 dBFS, spectrogram, onset alignment of 55 of 61 cues; the six quiet ack and first clock ticks were merged by the detector); no physical listening.
Frame legibility checked from decoded frames at full size and 350 px, not on a real phone.
Illustrative scenario: two features, one failing run, no measured timings or pass rates.
Shows the harness owning the test run and the record write; the source article has the agent self-verify under prompted rules, which prompts alone do not enforce.
The persistent green A row is prior recorded evidence, not proof of current regression coverage after edits to B.
These animations use sound effects rather than narration. The written guide explains the mechanism and its limits. Model names describe how a cut was made, not a quality ranking.
What the review found
- Astra 00:02.55–00:06.60 shows why an apparently successful response can be a failure against the agreed contract; baseline 00:03–00:06.40 and fable 00:03.10–00:07.65 leave the tested behavior abstract. Astra therefore gives the strongest first explanation of what a harness checks.
- Baseline 00:09–00:16.50 uniquely shows the session disappearing while workspace and progress survive, followed by record reading, initialization and a smoke check. This is useful complementary teaching, although the short INIT/SMOKE transfers and anonymous tasks require more interpretation than Astra’s two visible expectations.
- Fable 00:10.85–00:15.85 separates DONE B from RUN B, FAIL and a still-false feature row; at 00:22.60–00:24.60 a new pass permits the record update. This gives a clearer completion-claim lesson than baseline, while Astra supplies the more concrete reason for a failed check.
- Astra 00:11.40 now clears both prior results in the same frame as PATCH 2, before fresh checks at 00:15.75 and 00:18.15. Baseline 00:22.40 and fable 00:24.60 retain A’s historical pass while recording B; their transcripts now explicitly avoid claiming that A was retested after B changed.
- At 350px, Astra’s 00:06.30 failure and 00:24.50 resolved state have the strongest label hierarchy. Baseline’s 00:12.80 recovery state and fable’s 00:14.30 failed test remain readable but use smaller record labels and moving chips; baseline’s missing opening title has been corrected.
- Astra 00:21.75–00:25.50 holds READY for human review, without implying deployment or approval. Baseline 00:22.40–00:25 and fable about 00:24.60–00:27 hold saved results instead; all endings resolve, fade and reach matching near-black bookends. Astra’s longer hold helps inspection but makes it slightly less brisk.