An approved specification defines what must be true. An approved verification plan defines what evidence will show whether it is true. A loop uses both controls repeatedly to improve successive versions of one work product.
The principle is simple: the controls stay fixed; the work product changes.
That boundary prevents an agent from making success easier after a weak attempt. If the specification, verifier, sources, tools, permissions, or decision rules need to change, the current run should stop. The agent may propose a change for a future run, but it should not approve its own new rules.
Define the Run Before It Starts
A real autonomous loop needs more than “keep improving.” It needs a retained baseline, a comparison rule, a budget, and explicit stopping conditions.
Andrej Karpathy’s autoresearch project demonstrates the pattern in a tightly controlled setting: an agent modifies one file, trains for a fixed five-minute budget, checks one objective metric, keeps or discards the result, records the experiment, and repeats [1]. The transferable lesson is not the specific code. It is the design of the environment around the agent.
For professional work, define:
Work product: the only artifact the agent may change.
Fixed controls: named versions of the specification and verification plan.
Environment: approved sources, tools, runtime, and permissions.
Selection rule: how a passing candidate must improve on the retained version.
Limits: iteration, time, or cost budget.
Stops: success, plateau, unresolved evidence, or a decision reserved for a person.
The baseline is the first retained version. The loop never has to accept a worse candidate merely to keep moving.
Separate Findings From Decisions
The verifier returns evidence-based findings: MET, NOT MET, or UNRESOLVED. The loop then makes an operational decision:
DISCARD means restore the best retained version, not erase the experiment. The loop should preserve a compact lesson about what changed, what evidence appeared, and what should be tried next. Failed attempts can improve the next decision even when they do not improve the work product.
NASA describes a baseline as an agreed set of requirements, designs, or documents whose changes are controlled [2]. NIST similarly emphasizes documented, repeatable evaluation and a traceable basis for management decisions [3]. Together, these ideas explain why a loop needs fixed controls and a visible record, not merely repeated generation.
The Prompt
Run a bounded improvement loop on [WORK PRODUCT].
Fixed controls:
- Specification: [VERSION]
- Verification plan: [VERSION]
- Approved sources, tools, runtime, and permissions: [ENVIRONMENT]
- Selection rule: [HOW A PASSING CANDIDATE IMPROVES ON THE RETAINED VERSION]
- Success, plateau, and stopping conditions: [CONDITIONS]
- Iteration, time, or cost limit: [BUDGET]
Preserve the baseline as the first retained version. Modify only the work product.
Use a separate verifier role or fresh context to apply the approved verification
plan to every candidate.
For each iteration:
1. Choose one change using the retained version and prior lessons.
2. Produce a candidate version.
3. Verify it as MET, NOT MET, or UNRESOLVED with supporting evidence.
4. KEEP it only when all required conditions are MET and it satisfies the
selection rule. DISCARD it when a condition is NOT MET or it does not improve.
HALT when a material condition is UNRESOLVED.
5. Record the change, evidence, decision, lesson, and next action. Carry the
lesson into the next iteration.
Continue without requesting approval until the budget ends or an approved
success or plateau condition is met. Halt if continued work would require
changing a fixed control or making a decision reserved for a person.
Return the best retained version, final verification report, iteration record,
unresolved issues, and proposed control changes for a future run. Do not apply
those proposed changes during this run.What Makes the Loop Autonomous
The agent does not need a person to approve every attempt. It can choose a bounded change, generate a candidate, invoke the verifier, decide KEEP or DISCARD under the approved rules, record the lesson, and continue for the allowed number of iterations.
Human authority moves to the boundaries. Before the run, a person approves the objective, controls, environment, budget, and escalation conditions. After the run, a person reviews the best retained version, unresolved issues, and any proposed changes. During the run, human intervention is required only when a material issue is UNRESOLVED or the next action would exceed those boundaries.
This is what turns a sequence of prompts into an actual loop: state persists across iterations, lessons influence the next attempt, and the best verified result is protected.
Questions
Can the loop improve the specification or verification plan?
It can propose changes, but it should not apply them during the active run. Approve new control versions first, then begin a new run so every candidate is judged on the same basis.
Does DISCARD mean the iteration was wasted?
No. The candidate is not retained, but its evidence and lesson remain in the iteration record. That learning should narrow the next change.
How many iterations should run without a person?
Use the smallest budget that can reveal useful improvement without creating unacceptable cost or risk. High-consequence work needs tighter limits and earlier escalation than reversible drafting work.
References
1. Karpathy, A. (2026). autoresearch. GitHub.
2. National Aeronautics and Space Administration. (2016). NASA systems engineering handbook: Appendix B—Glossary.
3. National Institute of Standards and Technology. (2023). Artificial Intelligence Risk Management Framework Core: Measure.
Notes
Join the EPM Network to access insights, influence our research, and connect with a community shaping the industry’s future.
Support us by sharing this article with your friends and colleagues, or over social media.