12 Agent Loops Worth Copying (One of Them Silently Does Nothing)

Start with the trap, because it's the loop most people build first. You want a reviewer on repeat, so you type /loop 20m /code-review. Nothing reviews anything. Since v2.1.196, a scheduled fire only executes skills Claude is allowed to invoke on its own — and the bundled /verify and /code-review ship with disable-model-invocation: true. Your reviewer arrives in the session as plain text. Same for /permissions, /model, /clear, and any MCP prompt. The loop runs happily and reviews nothing, and nothing warns you.

That failure is the whole lesson about loop catalogues. There aren't fifteen kinds of loop; there are three questions, and every loop you'll ever see is an answer to them:

1. What starts the next turn? A condition, a clock, or an external event.
2. What proves it's done? And can that thing actually run commands, or is it just reading the transcript?
3. Where does it run? Your session, your machine, or Anthropic's cloud.

Get those three right and the loop is trivial. Get them wrong and you've built a very expensive while true. Here's the catalogue, grouped by question one.

Loops the clock starts

1 · The self-paced watcher. /loop check whether CI passed and address any review comments — omit the interval and Claude picks its own delay after each iteration, anywhere from one minute to one hour, based on what it just saw: short waits while a build is finishing, long waits once the PR goes quiet. It prints the delay and the reason each pass. Best for: babysitting a PR without paying for empty polls.

2 · The Monitor swap. When you ask for a self-paced loop, Claude may reach for the Monitor tool instead — it runs a background script and streams each output line back, so nothing polls at all. If your "loop" is really "tell me when this line shows up in the log", say that and let it skip cron entirely. Best for: waiting on a long build, a deploy, or a test run whose output you can grep.

3 · The fixed-tick maintainer. A bare /loop runs a built-in maintenance prompt: finish unfinished work, tend the current branch's PR (review comments, red CI, merge conflicts), then bug hunts and cleanup passes when nothing else is pending. It won't start new initiatives, and irreversible things like pushing only proceed when the transcript already authorized them. Add an interval — /loop 15m — for a fixed cadence instead. Best for: keeping a branch green while you're in meetings.

4 · The team's loop as a committed file. Drop a .claude/loop.md and it replaces that built-in prompt for bare /loop. Project-level wins over ~/.claude/loop.md, edits take effect on the next iteration (so you can tune a loop while it runs), and anything past 25,000 bytes is truncated. Best for: one shared "keep the release branch healthy" routine your whole team inherits from the repo.

<!-- .claude/loop.md -->
Check the `release/next` PR. If CI is red, pull the failing job log,
diagnose, and push a minimal fix. If new review comments arrived, address
each and resolve the thread. If everything is green and quiet, say so in
one line.

5 · Your own skill on repeat. /loop 20m /review-pr 1234 re-runs your skill each iteration — which works precisely because your project skills don't set disable-model-invocation. This is the fix for the trap at the top: wrap the review you want in a project skill and loop that. Best for: any recurring check you've already codified.

6 · The one-shot wake-up. Not a loop, and the cheapest thing on this list: in 45 minutes, check whether the integration tests passed. Claude pins it to a cron minute and the task deletes itself after firing. Best for: hand-off waits, where a real loop would just burn turns.

Loops a condition stops

7 · The stated-check goal. /goal (v2.1.139 or later) sets a completion condition and keeps starting turns until a small fast model — Haiku by default — confirms it holds, returning a short reason each pass that becomes the next turn's guidance. The condition can run to 4,000 characters, and you bound it inside the condition itself: append or stop after 20 turns. Best for: migrations and refactors with a compile-or-test end state.

/goal every call site of the old auth client is migrated, `npm test` exits 0,
and lint is clean. Do not modify any test file. Or stop after 20 turns.

8 · The headless goal. claude -p "/goal CHANGELOG.md has an entry for every PR merged this week" runs the whole loop to completion in a single invocation — the version you put in cron or CI. One catch worth knowing before you decide it hung: with default text output, nothing prints until the condition is met. Add --output-format stream-json --verbose. Best for: unattended overnight work you'd otherwise supervise.

9 · The verifier that can actually check. Here's the distinction almost everyone misses. /goal is a wrapper around a session-scoped prompt-based Stop hook, and that evaluator does not call tools — it only judges what Claude already surfaced in the conversation. So "all tests pass" gets graded on Claude's own claim about the tests. An agent hook is the upgrade: it spawns a subagent that runs the suite itself, with a 60-second default timeout and up to 50 tool-use turns. Best for: the moment you catch an agent declaring victory it didn't earn.

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "agent",
            "prompt": "Verify that all unit tests pass. Run the test suite and check the results. $ARGUMENTS",
            "timeout": 120
          }
        ]
      }
    ]
  }
}

Loops that run with your laptop shut

10 · The nightly cloud routine. A routine is a saved prompt plus repositories plus connectors, running on Anthropic-managed infrastructure. Create one with /schedule daily PR review at 9am from the CLI, or from the web form. Two numbers matter: the minimum interval is one hour (anything faster is rejected), and each run clones fresh from the default branch and can only push to claude/-prefixed branches unless you explicitly widen that. Best for: backlog grooming, docs-drift sweeps, weekly reports.

11 · The alert-triggered routine. Add an API trigger and the routine gets its own /fire endpoint. Your monitoring tool POSTs the alert body as text, and whoever is on call reviews a draft PR instead of opening a blank terminal. The gotcha that will eat your first afternoon: text arrives wrapped in a <routine-fire-payload> block labelled as untrusted data, so the routine's saved prompt has to opt in explicitly — something like "investigate the alert described in the routine-fire-payload block" — or the payload just sits there as inert context. Best for: Sentry-to-PR triage.

curl -X POST https://api.anthropic.com/v1/claude_code/routines/trig_.../fire \
  -H "Authorization: Bearer sk-ant-oat01-xxxxx" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "Sentry alert SEN-4521 fired in prod. Stack trace attached."}'

12 · The GitHub-event routine. A trigger on pull_request.opened runs your team's own review checklist on every PR, with filters on author, labels, base/head branch, draft state, or a regex. One sharp edge: matches regex tests the entire field value, so a title filter for hotfixes has to be .*hotfix.* — bare hotfix matches only a title that is exactly that one word. Best for: encoding the review standards your humans keep forgetting.

The two loops nobody sets up (and should)

Events pushed into the session you already have open. Channels are MCP servers that inject events straight into a live session — CI results, webhooks, or a Telegram message from your phone — instead of spawning a fresh cloud sandbox. Run claude --channels plugin:telegram@claude-plugins-official, pair your account, then lock it down with /telegram:access policy allowlist so only you can push. That's the human-in-the-loop approval queue built out of something real: the loop pauses, messages you, and continues on your reply, while the work happens on your machine against your actual files. It's a research preview, and on Team or Enterprise plans an Owner has to enable it first.

Review that fires on git commit, not on your memory. roborev is an MIT-licensed Go binary (1,583 stars, with commits landing the same day I write this) that installs a post-commit hook, reviews every commit in the background, and — the part that makes it a loop — roborev refine iterates auto-fixes until the reviews pass. It auto-detects Claude Code, Codex, Gemini, Copilot, Cursor and others. Best for: making review happen while the context is still warm, without you remembering to ask for it.

curl -fsSL https://roborev.io/install.sh | bash
roborev init      # post-commit hook: every commit queues a background review
roborev refine    # iterate fixes until the review queue is clean

The caps that quietly kill loops

Every one of these is documented, and almost nobody reads them until a loop misbehaves:

• Session loops expire after 7 days. A recurring task fires one final time, then deletes itself. That's a feature — it bounds how long a forgotten loop can run — but plan around it.
• Jitter reaches 30 minutes. An hourly job set for :00 can fire anywhere up to :30. If timing matters, schedule 3 9 * * * instead of 0 9 * * *.
• No catch-up. If Claude is mid-turn when a task comes due, it fires once when Claude goes idle — not once per missed interval.
• 50 scheduled tasks per session, and starting a fresh conversation wipes all of them. --resume brings back the unexpired ones.
• Green is not success. A green routine run means the session started and exited without an infrastructure error. It says nothing about whether your task worked. Open the transcript.

The EM angle

Loops are delegation, so the management questions don't change: what's the deliverable, how do we know it's done, what's the blast radius. What's new is that the answers are files now — .claude/loop.md, a Stop hook in settings.json, a routine's saved prompt. That's your team's autonomy policy in version control, and the cheap way to lift the whole team's floor is to commit one good loop, not to teach nine people to type /loop.

Today: take the one check you re-run by hand every day and turn it into loop #5 — put it in a project skill, then run /loop 20m /your-skill. Before you start it, write the stop condition in one sentence. If you can't, that's your real finding.

Sources

• Claude Code docs — Run prompts on a schedule
• Claude Code docs — Keep Claude working toward a goal
• Claude Code docs — Automate work with routines
• Claude Code docs — Automate actions with hooks
• Claude Code docs — Push events into a running session with channels
• roborev — continuous background code review for coding agents