


Keep an AI Working on a Long Task by Itself Within Set Limits and Stop Safely
Use when an AI should work on a long task without check-ins. It sets the goal, limits, and what counts as done, saves progress each round, tries a new approach when stuck, and stops with a report when done, over budget, or blocked.
To use this AI rule
## Write Down the Goal and What Counts as Done Before Starting
Before starting a long-running autonomous loop, write a compact mission contract that another agent could execute without relying on conversation memory.
- State the objective, approved scope, expected deliverables, and explicit exclusions.
- Define completion with observable acceptance criteria, such as required artifacts, passing checks, or verified outcomes.
- Record permission boundaries: which reversible actions may proceed automatically and which destructive, production, financial, credential, or external actions require approval.
- List dependencies, assumptions, and the authoritative sources that govern decisions.
- Set iteration, time, call, token, or cost limits before work begins.
Treat the contract as stable during the run. Continue autonomously inside it, but stop and report when new work would expand the objective, exceed authority, or require a materially different decision.
## Save Progress After Each Round So Work Can Resume After a Restart
Maintain a durable state record after every meaningful iteration so the loop can resume from evidence rather than reconstructed memory. Keep one current source of truth and update it atomically when possible.
The record must include:
- mission and acceptance criteria;
- completed work with verification evidence;
- current task, next action, and remaining work;
- decisions, assumptions, and rejected approaches;
- blockers, unresolved risks, and required approvals;
- iteration count, elapsed time, calls, tokens, and estimated cost;
- the last known-good checkpoint and rollback instructions.
On restart, read the state record, confirm that referenced artifacts still match it, and resume from the first unfinished verified step. Never claim inherited work is complete without checking the underlying result. If the record and actual state disagree, preserve both, stop dependent work, and report the discrepancy.
## Take One Small Step per Round and Check the Result
Use the same evidence-producing cycle for every iteration of an autonomous task:
1. Read the mission, current state, remaining budget, and latest evidence.
2. Select the smallest high-value action that advances an acceptance criterion.
3. Check that the action is inside the approved scope and permission boundary.
4. Execute it without repeated confirmation when it is reversible and already authorized.
5. Verify the result with the narrowest reliable test, inspection, or comparison.
6. Update the durable state, metrics, checkpoint, and next action.
7. Continue immediately unless a stop condition has been reached.
Do not mark progress merely because an action ran. Count progress only when the state changed toward completion and evidence supports that change. Keep failed experiments in the record so later iterations do not repeat them blindly.
## Notice When Work Is Stuck and Try a Different Approach
Evaluate progress after every iteration. Treat the loop as stagnant when two consecutive iterations produce no verified advancement, the same unresolved error recurs twice, output quality declines materially, or the agent repeats questions or actions without gaining evidence.
At the first confirmed stagnation signal:
- pause the current approach;
- compare the latest state with the last known-good checkpoint;
- identify whether the cause is missing information, permission, environment failure, an invalid assumption, or an ineffective strategy;
- choose a materially different diagnostic or smaller test;
- record why the previous approach failed before retrying.
Do not duplicate a task while an earlier attempt may still be running. After three confirmed failures for the same blocking condition, stop the loop instead of consuming more resources. Preserve artifacts and report the evidence, attempted strategies, current state, and the smallest decision or external change needed to resume.
## Watch the Time and Cost Limits and Stop When They Run Out
Treat resource limits as hard operating constraints, not informal targets. Track actual or best-estimate usage after each iteration, including loop count, wall time, model or service calls, tokens, and monetary cost when available.
- Warn in the state record when usage reaches 70% of any limit and narrow work to the highest-value remaining criteria.
- At 90%, avoid exploratory work and perform only actions required to verify, preserve, or safely stop the run.
- At 100%, do not begin another resource-consuming iteration. Save state and issue a stop report.
- Never bypass, reset, or silently reinterpret a limit to keep the loop alive.
- If usage cannot be measured reliably, use a conservative estimate and state the uncertainty.
Budget exhaustion is not completion. Report completed and incomplete criteria separately, with the resources required for a justified continuation. Resume only with a new or explicitly extended budget.
## Save a Restore Point Before Risky Changes and Report Every Stop
Create a recoverable checkpoint before risky writes, broad changes, migrations, destructive operations, or actions with significant external effects. Confirm what the checkpoint contains, how to restore it, and whether restoration has been tested. Never describe a copy as a backup unless it can reasonably recover the affected state.
Roll back to the last verified checkpoint when a change causes a regression, corrupts state, violates acceptance criteria, or leaves the system less safe. Do not erase diagnostic evidence needed to explain the failure. Destructive rollback, production changes, credential changes, purchases, and irreversible external actions require explicit permission unless the mission contract already grants that exact authority.
Stop immediately when the mission is complete, the user requests a stop, a hard budget is reached, authority is missing, safety cannot be established, state is inconsistent, or the same blocker has failed three times. Every stop report must state:
- why the loop stopped and whether the objective is complete;
- what changed, what remains, and what is currently running;
- verification evidence and unresolved risks;
- checkpoint and rollback status;
- resource usage against limits;
- the exact next action or approval needed to resume.
