How to Build a Claude Code Agent That Works in a Loop (Exact Setup Inside)

Most agents run once, hand you broken work, and leave you to check and re-run it yourself. You’re the loop, and it’s exhausting.

Every self-fixing, self-optimizing agent runs on one pattern: do, check, repeat until done. Build that skeleton once and point it at anything: bugs, speed, cost.

Here’s the full setup 👇

Before we dive in, I share daily notes on AI & vibe coding in my Telegram channel: https://t.me/zodchixquant🧠

The pattern under every autonomous agent

People build a “self-fixing agent,” then a separate “self-optimizing agent,” then another for cost, and write each from scratch. They’re all the same three moves: an agent does work, something measures whether it hit the goal, and a controller decides keep going or stop.

Get that skeleton right once and the specific job becomes a plug-in. Swap “run the tests” for “run the benchmark” and your bug-fixer becomes a speed-optimizer. The loop doesn’t change, only the check does.

So instead of five loop setups, you build one and point it wherever you need.

File 1: the reusable loop command

This is the skeleton. Drop into .claude/commands/loop.md:

The whole design is in step 1: the loop asks what “done” means, then runs that as the truth every cycle.

That one line is what makes it reusable. The agent isn’t hardcoded to tests or speed, it loops toward whatever goal you name.

File 2: the pluggable check

The loop is generic because the check is swappable. Keep your checks in one place, .claude/checks/, and point the loop at the one you need.

A test check, checks/tests.sh:

A speed check, checks/speed.sh:

A lint check, checks/lint.sh:

Same loop, three different goals. You run **/loop fix the failing auth test **and it uses the test check. You run /loop make the search 2x faster and it points at the speed check. The skeleton never changes, you just tell it what “done” looks like.

This is why one well-built loop beats five one-off ones. Each new goal is a 3-line shell script, not a new agent.

File 3: the stop rules

A loop needs brakes or it runs forever and fakes a pass. Put these in CLAUDE.md:

The “hasn’t improved in two cycles” rule is what separates real progress from spinning.

If two rounds of work didn’t move the number, more rounds won’t either, and that’s a human’s cue, not the agent’s to keep grinding.

What you actually see

You point the same loop at two different goals.

Bug fix:

Then speed, same command, different check:

Same skeleton, same stop rules, two completely different jobs. You built the loop once and pointed it where you needed.

Common mistakes

No goal check. A loop without a concrete “done” runs on the agent’s opinion, and the agent always thinks it’s done. The check is the loop. No check, no loop.

A check the agent can edit. If it can pass by weakening the test or the benchmark, it eventually will. The check has to be something the agent runs, not something it can rewrite.

No cap. Without a cycle limit, a stuck loop burns tokens until you notice. The cap turns “infinite spin” into a clean “here’s where I got stuck” report.

Building a new agent per goal. The whole point is one loop, many checks. If you’re writing a fresh agent for every task, you missed the pattern. Swap the check, keep the loop.

The 10-minute setup

3 minutes: create .claude/commands/loop.md, the reusable skeleton.

3 minutes: write 2-3 checks in .claude/checks/ for the goals you hit most.

2 minutes: add the stop rules to CLAUDE.md.

2 minutes: run /loop on a real task, then run it again on a totally different one with a different check.

You stop building a new agent for every job. One loop, swappable goals, and it runs toward each one until the check says done.

It didn’t get smarter, you just stopped writing the same loop five times.

Thanks for reading!

I share daily notes on AI, finance, and vibe coding in my Telegram channel: https://t.me/zodchixquant