Automation Is Not a Policy
Explore how to transform manual decision-making into automated loop contracts for coding agents working across sessions. Understand six critical steps that govern progress, verification, and stopping conditions. Learn to build reliable automation loops that maintain authority boundaries, verify outcomes, and properly manage state for stable, repeatable agent behavior.
We'll cover the following...
- What decisions was the engineer making by hand?
- What is the smallest loop worth automating?
- What belongs in a Loop Contract?
- Who is allowed to say the loop is done?
- When has a retry earned the right to run?
- How should budgets and authority shape the loop?
- Can you build the loop before writing a runner?
- What can you add to your own harness today?
- How do you test the loop itself?
- What’s next?
Wrenfold’s engineer spent Tuesday afternoon driving CLIN-547 through four agent sessions. After each session, she read the checkpoint, copied the latest failure into a new prompt, asked for one repair, ran npm run test:e2e, and decided whether to continue.
By 5:40 PM, the waitlist test had moved from a missing promotion to a duplicate notification. She turned the routine into a shell loop: keep asking the agent to fix CLIN-547 until the end-to-end command exits with zero.
The command stayed red. The agent made the first valid repair, saw the same duplicate-notification failure twice, then changed queue ranking, email formatting, and the appointment route. Attempt seven exceeded the original Scope Contract. Attempt nine rediscovered a decision already recorded in the checkpoint. The loop stopped only when its tool budget expired.
Automation removed the tired person who had been supplying judgment between turns. It did not replace that judgment with a policy.
What decisions was the engineer making by hand?
Each manual session looked like “ask, inspect, ask again,” but the engineer was performing six separate jobs:
Select one eligible goal from the Feature Ledger.
Read durable state before deciding what happens next.
Authorize one bounded action under the Scope Contract.
Run the Verification Route and interpret claim-level evidence.
Persist the result for the next attempt or session.
Choose a named transition: retry, succeed, or stop for review.
A useful loop writes those decisions down before unattended execution begins. Repeating a prompt is only the dispatch mechanism.
This sits on the reliability side of the course’s line: capability is what the model can do; reliability is what your system lets it finish. A stronger model may find the duplicate-notification bug sooner. The harness still decides whether the feature was eligible, which files it may change, what proof counts, and when another attempt would be unsafe or pointless.