Four Loop Types Every Agent Needs

Leer en español → · 阅读中文版 →

An agent loop needs a stop condition before it needs more tools. Without one, it burns tokens, repeats work, or acts when nobody is watching.

In June, I wrote about agent loops that stop themselves: systems where multiple models verify each other’s work and cap the cost. That article covered one pattern: run more than one model, let them disagree, and put something in the path that reads the disagreement. This one zooms out to the loop types underneath the systems I’ve already built.

Last week, the Claude Code team published “Getting started with loops”, and it gave me language I didn’t have before. They define loops as “agents repeating cycles of work until a stop condition is met,” and they break them into four types based on what triggers them, what stops them, and what kind of task fits. When I mapped my existing systems against that taxonomy, something clicked. I wasn’t looking at a pile of weird personal automations. I was looking at a stack of loop patterns.

Here’s the taxonomy, what each type does, and which systems I’ve already shipped that fit each one.

The four types

• Turn-based loops. You prompt, the agent works, you check, you prompt again.
• Goal-based loops. The agent runs until an explicit condition is met, or a turn cap is hit.
• Time-based loops. Work runs on a schedule or in response to an event.
• Proactive loops. Scheduled and autonomous. The agent acts without you in the room.

Each one answers the same question differently: who decides when to stop?

Turn-based loops: you already use these

Every prompt you send starts one. The agent gathers context, acts, checks its own work, and hands the result back. Then you verify and write the next prompt. You are the stop condition.

This is the loop everyone runs without thinking about it, and it’s fine for short tasks that aren’t part of a regular process.

What I’ve built: multi-agent verification loops

My last article covered two systems that fit here.

opencode-fusion is panel plus judge. Three agents, three models, one question. The panel answers, the judge scores them, and you see one synthesized answer instead of three transcripts.

opencode-fusion ask \
  --panel "gpt-4o-mini,claude-3-5-haiku-20241022,gemini-2.0-flash-exp" \
  --judge "gpt-4o" \
  "Write a Python function to validate email addresses"

The models are pinned from when I built it. Swap in whatever’s current; the pattern doesn’t care.

agmsg bridge is persistent cross-agent messaging. A small bridge watches a shared SQLite inbox and delivers messages between three agents, each pinned to a different provider. They message each other until they converge or hit a disagreement.

The bridge doesn’t decide when to stop. It just moves messages. The stop condition lives in the agents’ instructions: reply with your answer or request clarification, and after three rounds, escalate to a human.

The upgrade path for turn-based loops is to move your manual verification into a SKILL.md so the agent can check its own work end to end. Quantitative checks work best. “Tests pass” is verifiable. “Looks right” is not.

## Verification Loop

**Stop condition:** Tests pass OR max 3 attempts

1. Run `npm test`
2. If pass: complete
3. If fail AND attempts < 3: fix and retry
4. If fail AND attempts >= 3: escalate

Goal-based loops: deterministic exit criteria

Goal-based loops run until a specific condition is satisfied, with a turn cap as the backstop. You define done up front, and the agent checks progress against it instead of asking you every round.

In Claude Code that’s the /goal command. Something like:

/goal Refactor the auth module to use JWT instead of sessions.
Done when: all tests pass, no linter errors, PR opened.

What I’ve built: OpenClaw goal tracking

OpenClaw has create_goal and update_goal built in:

create_goal({
  objective: "Migrate auth to JWT",
  token_budget: 50000
});

// Later...
update_goal({
  status: "complete",
  note: "Tests pass, PR #47 opened"
});

I use this for multi-step work that spans sessions: implement the feature, write the tests, update the docs. Success criteria go in first, the agent checks after each step, and the goal closes when the criteria are met. The token budget is the cost cap.

Time-based loops: scheduled work

Time-based loops run on a schedule or fire off an event: a webhook, a file change, a push. Claude Code gives you named primitives here. /loop re-runs a prompt locally on an interval, like checking a PR every five minutes until CI is green. /schedule moves the routine to the cloud so it runs without your machine. Note that /schedule is a research preview as I write this, so expect it to change.

Copilot CLI has experimental slash commands for the same local scheduling pattern. /every or /loop schedules a recurring prompt, skill, or schedulable slash command inside the current session. Give it an interval in seconds, minutes, or hours. In the build I tested, omitting the interval creates a self-paced schedule: the CLI runs now and chooses the next run after each pass.

/every 5m check PR #47 and tell me when CI is green
/every watch the deploy

For one-shot delayed work, /after schedules a prompt once:

/after 30m check whether the preview deploy is live

That is session-level scheduling. For work that needs to run without your machine or terminal session, wire copilot -p into GitHub Actions, cron, a webhook handler, or whatever scheduler already owns the routine.

What I’ve built: Dream Cycle and auto-consolidation

Dream Cycle is a nightly AI research scanner. Every night at 2:00 AM it scans arxiv for the last seven days, checks GitHub trending for AI/ML repos, filters by relevance with embeddings, generates improvement proposals through GitHub Copilot CLI, commits the output to git, and sends a summary to Telegram.

Stop condition: research scanned, proposals generated, git commit succeeds.

Cost: it runs on my existing Copilot plan. The CLI calls draw from the monthly included AI Credits, and this workload stays inside them. If you run heavier nightly jobs, watch your credit usage; scheduled loops are exactly the kind of thing that quietly eats a budget.

Auto-consolidation is memory management. It runs when at least 24 hours have passed since the last run and at least 5 sessions have accumulated. It reads the MEMORY.md index, scans recent daily logs for new signal, merges into topic files, de-duplicates, and prunes the index back under its size limit. Current compression ratio is about 9:1, turning 107 KB of daily logs into 11.6 KB of topic files.

The mechanics are the same for both: OpenClaw cron spawns an isolated session, the session executes and writes output, then terminates on completion or timeout. No human in the loop.

If you’re starting out, begin with read-only monitoring. Let a scheduled loop watch and report for a week before you let it write anything.

Proactive loops: fully autonomous work

Proactive loops are scheduled work with no human in real time. Each task inside the routine exits when its goal is met, and the routine itself keeps running until you turn it off. The agent doesn’t just report. It triages, fixes, opens the PR, and notifies you afterward.

What I haven’t built yet: issue triage plus auto-fix

The plan: every 6 hours, scan GitHub issues across my repos. Triage into P0/P1/P2. For P0s, spawn a fix agent that reads the issue, proposes a fix, hands it to a review agent that runs tests and checks style, and opens a PR only on approval. For P1s, comment with reproduction steps and ask for logs. For P2s, label them help wanted. Notify me if a P0 blocker shows up.

Why it’s not built: autonomous code changes need strong verification loops underneath them. I want the second-agent PR review pattern shipped and trusted first. Then it becomes the gate inside the triage loop, not an afterthought bolted on.

That ordering is the whole point. Verification layers first, autonomy second.

When not to loop

Before you build one, four questions.

Is the stop condition clear? If you can’t define done in one sentence, you need a simpler problem, not a loop.

Is the cost bounded? Reading disagreement should never cost more than the bug it catches. Set token budgets, run cheap models for initial passes, and escalate to expensive models only when the cheap ones disagree.

Can a human verify the output? If your answer is “I don’t know how to check this,” the agent won’t know either. Quantitative checks beat vibe checks.

Is this actually recurring work? One-off tasks don’t need loops. Just do the work.

What the taxonomy buys you

All four types share the same skeleton: a trigger, a work cycle, a stop condition, and verification. The difference is who decides when to stop. In turn-based loops it’s you. In goal-based loops it’s the agent, checked against explicit criteria. In time-based loops it’s the schedule. In proactive loops it’s the agent again, after acting on its own.

Having names for that changes how you build. “I built a thing that checks itself” becomes “I built a turn-based verification loop with panel consensus and a three-round escalation cap,” and the second sentence is reusable. You can lift the pattern into a skill template, explain the tradeoff to a teammate, and see the gap in your own stack. I have turn-based and time-based loops running today. Proactive is next, and now I know exactly which verification layer is missing before it’s safe to ship.

A note before you build this

One caveat before you schedule anything. A turn-based loop fails in front of you. A time-based loop fails at 2 AM with nobody watching, and a proactive one acts on the failure. Start read-only, keep the budgets tight, and don’t give a loop write access until you’ve watched it be wrong a few times.

Originally published on X.