Autonomous coding agent loops, explained: turn-based, goal, time, and proactive

An autonomous coding agent loop is an agent that repeats cycles of work (gather context, act, verify) until a stop condition is met, instead of answering a single prompt and stopping. The idea behind "designing loops instead of prompting" is that agents do better when they can iterate against a clear goal. There are four common loop types, distinguished by how they're triggered and how they're stopped. Not every task needs a complex loop: start with the simplest one that fits.

1. Turn-based loop

Triggered by a prompt; stops when the agent judges the task complete. Every prompt you send starts a manual loop where you direct each turn: the agent gathers context, takes action, checks its work, and responds, then you review and write the next prompt. This is the plain "agentic loop." Best for shorter, one-off tasks. You improve it by writing specific prompts and encoding your review steps as a reusable verification skill so the agent can check more of its own work.

2. Goal-based loop

Triggered manually; stops when the goal is achieved or a turn cap is reached. When one turn isn't enough, you define what "done" looks like: for example, "get the homepage Lighthouse score to 90 or above, stop after 5 tries." Each time the agent tries to stop, an evaluator checks your condition and sends it back to work until the goal is met or the cap is hit. Deterministic criteria (tests passing, a score threshold) work best, because the agent doesn't have to guess what "good enough" means. This is the rung where a real proof of the goal matters most.

3. Time-based loop

Triggered on an interval; stops when you cancel or the work completes. Some work is recurring: the task is the same and only the inputs change (summarize the standup channel each morning), or it depends on an external system you poll and react to (a PR that may get review comments or fail CI). A time-based loop re-runs a prompt on a schedule. Run it locally and it stops when you close your machine; move it to the cloud and it keeps going. Prefer longer intervals, or event triggers, over tight polling.

4. Proactive loop

Triggered by an event or schedule with no human in real time; each task exits when its goal is met, and the routine runs until you turn it off. This composes the others: a schedule that watches for new work, a goal that defines done, a verification skill, a second agent that reviews with fresh context, and an autonomy setting so it doesn't stop to ask permission. Best for recurring streams of well-defined work: bug reports, issue triage, migrations, dependency upgrades. This is the most powerful and the most dangerous rung, because it can spawn many agents at once; pilot on a small slice before a large run.

Choosing a loop

Keeping quality high in a loop

The output of a loop is only as good as the system around it. Keep the codebase clean so the agent follows existing patterns; give it a way to verify its own work; make docs easy to reach; and use a second agent with fresh context for code review, because it's less biased than the agent that wrote the change. When one result misses the bar, don't just fix that instance: encode the lesson so every future iteration inherits it. To manage tokens, choose the smallest primitive and model that fit, define clear stop criteria, and pilot before a large run.

Where an autonomous work-loop platform fits

These loop types are single-agent primitives. When you want them composed across many agents on one history (in dependency order, collision-safe, with a verdict on every change) that's an autonomous work-loop platform like Aura Crew. It reads the same ready-work view whether you drive it from the CLI (aura loop run) or from chat (/loop), and gates every merge on a proof of the goal. See also how the work-loop harnesses compare.