Loop Engineering Checklists
Three complete, check-as-you-go reviews for building a loop, containing its risk, and deciding whether one run produced trustworthy evidence.
A checklist should support a decision, not create another directory.
The earlier collection split goals, worktrees, pull-request review, feedback, quality checking, and metric gaming into many short pages. Those topics still matter, but they belong inside three decisions: whether the loop is designed well enough to start, whether its permissions and workspace are safe, and whether the evidence from a finished run is good enough to act on.
Build
Goal, discovery, handoff, checker, memory, stop rule, budget, fallback, and approval.
Contain
Worktree isolation, permissions, forbidden actions, rollback, and human control.
Validate
Expected evidence, actual evidence, shortcut detection, decision, and next action.
The practical building blocks every safe, token-aware agent loop needs before it runs.
Safety questions to answer before running an autonomous AI agent loop.
A practical checklist for validating one agent loop run before deciding whether to stop, adjust, or run again.
How to use the reviews
- 01
Write the expected evidence and hard stops before the first run.
- 02
Mark each item from the actual diff, command output, or saved artifact.
- 03
Treat any forbidden shortcut or missing approval as a stop, even when other checks pass.
- 04
Record one decision: approve for human review, revise one assumption, or stop and escalate.
Start with the decision that could go wrong.
Build
The loop has not started, or its goal and exits are still vague.
A named validator, a bounded scope, a retry limit, a fallback, and a human approval point.
Contain
The task can affect files, services, credentials, deployments, or other people.
An isolated workspace, minimum permissions, forbidden actions, rollback evidence, and a clear last permitted action.
Validate
A run has finished and someone must decide whether its result is trustworthy.
The baseline, actual diff or artifact, command output, rejected shortcuts, limitations, and one explicit next action.
A green command is evidence, not the decision.
Imagine a CI repair loop that began with one reproducible parser test failure. The run finishes with the focused test and the full suite green. The validation review still checks that the original test remains present, no unrelated checks were skipped, the diff stays inside the parser package, and the agent did not obtain merge authority. If those facts are visible, the decision is “ready for human review.” If the test was deleted, the decision is “stop,” even though CI is green. If the focused test passes but the broader suite was not run, the decision is “revise” with one next action: run the missing suite and attach its output. This is why the checklist records evidence and a decision separately.