How agent loops work
An agent loop is a task with a check. The agent does some work, checks the result, and then continues or stops.
In practice, the agent observes the current state, takes one action, checks what happened, and decides what to do next. Use a loop when the result of one step should change the next step. If it will not, use a one-time task instead.
What makes a loop useful
Start with a clear goal. Describe the result in a way you can measure or review. “Improve the code” is vague. “Make every page load in under 50 milliseconds under the same test conditions” gives the agent a real finish line.
Keep each action small. Ask the agent to make one bounded, reversible change at a time. Smaller changes are easier to verify and easier to undo when the result gets worse.
Use a fixed check. Run the same test, benchmark, rubric, or approval step after every change. The check—not the agent’s opinion—determines whether the work improved.
Define how it stops. Say what success looks like, when no change is needed, when the agent should ask for approval, and when it should stop because it is blocked or out of budget.
A goal loop starts manually and continues until its check passes or its budget runs out. A scheduled loop starts at a set time or after an event. Every scheduled run should still finish, report its result, and wait for the next trigger.
Write the prompt
Write the loop in ordinary language. Name the trigger, the current information the agent should inspect, the change it may make, the check it must run, and the conditions that make it stop.
Copy and adapt this:
When [trigger], inspect [fresh inputs]. Choose one in-scope action using [criteria], then make the change.
Run [acceptance check] under the same conditions. Record what changed, the evidence, and the next step in [state file].
Repeat only while progress is measurable and [budget] remains. Stop when [success gate] passes. Stop without changes when [no-op condition] is true.
Ask for approval or report a blocker when [escalation condition] occurs. Never [forbidden action]. Finish with [pull request, report, artifact, or handoff].
Run the prompt once by hand before you schedule it. The first run usually reveals a missing check, an unclear boundary, or a stopping condition that needs to be more specific.
Run it in your coding agent
The same loop prompt works across tools. The main difference is where you save recurring instructions and how you schedule future runs.
Cursor
Open the repository, select Agent, and paste the loop prompt. Include the files in scope, the exact check to run, and the stopping rule. Review the terminal output and diff, then use the check—not the agent’s summary—to decide whether the work is done.
For recurring work, save stable guidance in .cursor/rules
or AGENTS.md. Use Cursor Automations for scheduled or
event-triggered runs. See the official documentation for
Agent,
Rules, and
Automations.
Codex
Open the repository and start a Worktree thread when the loop should change code in isolation. Paste the prompt with the goal, constraints, check, and “done when” condition. Review the diff and final test or benchmark result before accepting the work.
For recurring work, keep project rules in AGENTS.md.
Test the prompt manually, then create a Codex Automation and review
its first runs. See the official documentation for
best practices,
AGENTS.md, and
Automations.
Claude Code
Run cd my-project, then claude. Paste the
loop prompt with its check, budget, and stopping rule. Run
/init if you want a starting CLAUDE.md for
stable project instructions.
For polling inside an open session, use a prompt such as
/loop 5m check whether the deploy finished. Use a Routine,
Desktop task, or GitHub Action for work that must survive a closed
terminal. See the official documentation for
CLAUDE.md,
scheduled tasks, and
Routines.
Factory
Open the repository, run droid, and paste the loop prompt.
Include the working directory, check, final output, and stopping rule.
Review the spec, permissions, edits, and verification output.
For recurring work, call
droid exec --auto medium -f .factory/prompts/loop.md from
CI or cron. Use the lowest autonomy level that can finish the task.
See the official documentation for the
Droid CLI and
Droid Exec.
Devin
Start a session with the correct repository and branch. Paste the loop prompt and say whether the final output should be a pull request, report, or clean no-op. Review the plan, changes, and evidence before merging.
For recurring work, save the prompt as a Playbook. Use Schedule Devin or Settings > Schedules for recurring runs, then review Past Sessions. See the official documentation for Playbooks and Scheduled Sessions.
Product controls change. The links above go to each product’s official documentation.
Keep loops safe
Set limits. Give every loop a maximum time, cost, retry count, iteration count, or affected scope. A loop should never interpret “keep going” as unlimited authority.
Keep the check stable. Changing the benchmark after every result makes progress impossible to compare. Use a fresh acceptance set when the loop is optimizing a prompt or model.
Leave a useful handoff. Record the goal, completed
steps, evidence, blockers, and next action in
tmp/<file>.md. Never store secrets there.
Keep consequential actions behind approval. Require a person to approve production, destructive, financial, privacy-sensitive, or external-message actions. Blocked, exhausted, and stagnant runs are not successful runs.