Fieldnotes / engineering
← Loop engineering

Watch & compare

Loop 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 Evidence first

Astra makes the consequential decision explicit: valid failure permits an edit, fresh passing evidence routes to review, and zero selected tests blocks further edits. Baseline is a useful companion for budget exhaustion versus early success. Fable adds retained history and a repeat-evidence handoff, but its denser log and illustrative report identifier require more interpretation at phone size.

Revised original · 24 sec

Bounded runs

A harness-owned call budget ends an unsuccessful run; a passing result can exit to review before that budget is spent.

Read the video sequence
  1. 0–9.7s Run A has a three-call budget. Three agent-to-tool cycles consume it. Amber RETRY results return feedback; they do not mean the task has succeeded.
  2. 9.7–13.2s With no calls remaining, the run routes to Stop. The stage fades to separate this exhausted task from the next example.
  3. 13.2–19.6s An independent run B starts with its own three-call budget. After one continuing result, a second tool result becomes PASS and travels to Review with one call left.
  4. 19.6–24s The edit loop dims and Review remains active. The run has ended successfully for review; the animation does not show merge approval. A full-frame fade closes the loop.
About this cut

Production: Original prototype; model not recorded.

Revision: gpt-6-astra comparative review.

The three-call budget and outcomes are illustrative, not a recommended production limit.

The diagram abstracts the harness implementation and does not show timeout cancellation, evidence classification or a blocker handoff.

The separate run B must be authorized independently; an exhausted agent cannot refill its own budget.

Audio was analysed, not heard.

Recommended · Astra · 28 sec

Evidence first

Classify observed test results before allowing another agent edit: repair a valid failure, review a passing patch, and hand off missing validation.

Read the video sequence
  1. 0–4.5s In this illustrative repair task, the agent runs 12 selected tests. One assertion fails. The result gate accepts this as usable feedback for another edit.
  2. 4.5–9.8s The failure returns to the agent. Patch 0 becomes patch 1, consuming the edit permit: the gate returns to WAIT and the new patch is untested. The same selected tests run again; all 12 pass in this illustrative task.
  3. 9.8–14.2s The passing result exits the edit loop and reaches an engineer for patch review. Passing these tests does not authorize an automatic merge.
  4. 14.2–20.2s A separate task begins, but the keyword selector leaves no tests selected and returns exit 5. The gate blocks the edit path, and the task remains at patch 0. This gate represents enforced application logic, not a prompt-based permission guarantee.
  5. 20.2–28s An evidence envelope represents the command and logs sent to the engineer to inspect test discovery. Product edits stay stopped. The scene fades out without claiming the blocker was repaired.
About this cut

Production: gpt-6-astra.

Revision: gpt-6-astra comparative review.

Illustrative scenario, counts, and timing; this is not a demonstrated model repair or a guarantee of successful fixes.

The result gate represents executable harness policy; persistent prompts alone do not enforce permissions, edit scope, or stopping.

Immediate handoff for no tests is this repair-only workflow’s policy; a separately scoped diagnostic agent could investigate discovery.

Passing the selected tests permits human review, not automatic merge or proof of overall correctness.

Audio was checked by decoded signal analysis and spectrogram, not physically heard.

Authored independently without inspecting baseline media or other variant scenes; original authorship is retained; the comparative review and corrections are separately attributed.

Alternative · Fable · 31 sec

Repeated evidence reaches a limit

Record comparable observations from a fixed test selection; a configured limit on repeated failure evidence stops edits and hands the trace to an engineer. Passing tests also exit to human review.

Read the video sequence
  1. 0–4.2s The agent sends EDIT 1 around the ring to a fixed 12-test suite. Five tests fail; 5 FAIL enters the run log with a full illustrative bar.
  2. 4.2–7.6s EDIT 2 returns 2 FAIL under the same selection. A shorter bar and a check mark register the reduced count. Counts summarize this example; they are not a sufficient general progress test.
  3. 7.6–13.55s EDIT 3 returns PASS. The log retains the earlier observations, a REVIEW badge appears, the loop dims, and a REVIEW chip reaches the human for patch review.
  4. 13.55–18.75s The scene fades into a separate task with a repeat limit of three. Its first edit returns FAIL a7; the log records 3 FAIL · a7. Here a7 represents one normalized assertion report, not merely a failure count.
  5. 18.75–22.15s The second edit returns the same report a7. Two matching log entries turn amber and a warning mark appears.
  6. 22.15–26.55s The third edit returns a7 again. Three matching entries reach this example’s configured repeat limit: the log turns red, a REPEAT LIMIT badge appears, and the agent and loop dim.
  7. 26.55–30.7667s HAND OFF travels from the retained run log to the human. The human lights to acknowledge receipt; the blocker has not been repaired. The resolved handoff holds before a full-frame fade.
About this cut

Production: anthropic/claude-fable-5-1.

Revision: gpt-6-astra comparative review.

The repeat threshold of three is an illustrative policy, not an optimal count or proof that a repair is impossible.

The same failure count can hide different failing tests. The revised repeated-report identifier a7 stands for matching failure identities and relevant assertion details under a fixed selection; it is not a suggested production hash length.

The initial falling-count example assumes stable tests and controlled state; counts or a single green run alone do not prove overall correctness.

The run log represents executable harness checks; the animation does not demonstrate permission enforcement or timeout cancellation.

Iteration budgets are complementary and shown in the baseline cut.

Audio was analysed by signal levels, cue windows and spectrogram, not heard.

Original author provenance is retained; teaching and render corrections are attributed separately.

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