Loop Engineering: Run Claude in a Loop Until the Work Is Actually Done, Quentin IA Marketing

Most people use Claude like a vending machine: you ask a question, it answers, you close the window. One decision, one result. Loop engineering flips that logic completely. You stop writing instructions one at a time and start designing the system that writes them for you, again and again, until there is nothing left to do.

A loop is a system that prompts an AI agent repeatedly to handle multi-item work, with no human stepping in between each step. Instead of prompting by hand "do task 1", then "do task 2", you write the rules of the game once and the agent runs through them on its own.

The mindset shift matters more than any tool: prompting is tactical (one instruction, one result). Loop engineering is strategic (you design the machine that produces the results). It is the difference between doing the work and managing the worker. This guide hands you the reusable skeleton and one concrete example.

Claude AI Lab

The Claude AI Lab is my Skool community where I share my Claude systems and the more advanced modules. Entry is free.

Join the Lab →

✅What you need for a loop to hold up

Repeating or multi-item work. A loop pays off on volume or recurring work, not on a one-off question.

A measurable goal. A number, a percentage, or a checklist Claude can score itself against. "Make it good" does not work.

A way to verify. If you cannot describe how the loop checks its own work, it is not a loop yet, it is a prompt.

Claude Code. The version of Claude that acts instead of just answering. It is what runs the loops, locally or in the cloud.

The thing that changes everything

A loop does not stop after one result. It finds the work, does it, checks itself, records what is done, then goes again. You describe the finished state once, it handles the rest.

The five-beat cycle

🔁 the structure common to every loop

Whatever the task, every well-built loop follows the same rhythm. Remember these five beats, the rest is just packaging.

🔁The rhythm of a loop

Find the work. The loop discovers what is left to do: open tasks, failing tests, unanswered emails, items in a queue.

Do it. The agent handles one item at a time, exactly the way you would prompt it by hand.

Check itself. A verification step decides whether the work is actually done and correct, with evidence.

Remember. The loop records what it finished (a state file or a task board) so it does not redo it and can resume later.

Go again. It repeats until nothing is left, then stops or notifies you.

Why beat 4 is the most underrated

The state file turns several runs into one continuous operation. Without it, every run starts from zero. With it, the same scheduled loop always resumes exactly where it left off.

The loop charter

📋 the skeleton to copy and paste

Here is the core of the guide: a charter you fill in once and hand to Claude as its instructions. It covers the five beats and adds the goal and the stopping condition. Copy it, replace the brackets, and you have a loop.

GOAL: [the finished state in one sentence, with a checkable number.
Ex: "every product page in /pages has the right price and passes the link checker"]

WHERE TO FIND THE WORK: [say exactly where to look for items.
Ex: "scan the /pages folder" or "read the unchecked lines in TODO.md"
or "take the tasks tagged 'ai' on my connected board"]

HOW TO DO THE WORK:
- Finish one item completely before starting the next.
- Match the style and conventions of the existing files.
- On a decision that needs a human (spending, deleting, contacting),
  do not decide: add it to a "needs decision" list and move on.

HOW TO CHECK YOURSELF: [pick the evidence that fits the task.
Ex: "run the tests" or "re-read and confirm alignment with the GOAL"
or "take a screenshot that shows the correct rendering"].
Evidence, not confidence. If it fails, fix and re-verify.
Max 3 attempts per item, otherwise mark it "blocked".

HOW TO REMEMBER: keep a LOOP-STATE.md file.
After each item, log: name, status (done / blocked / needs decision),
what changed, the context for the next run.
Read this file first on every run.

WHEN TO STOP: when everything is done or marked blocked, or after
[N] items for this run. End with a short report:
what is done, what is blocked, what needs a decision.

The most important part is the GOAL. A vague goal ("make it good") gives nothing to score against, so the loop stops like a regular prompt. A measurable goal gives it a wall to push against until it is truly finished.

What to remember about verification

The golden rule: the loop verifies on evidence, never on a feeling. "The test passes", "the link opens", "the screenshot shows the right price". Not "looks good".

The 5 pieces in Claude Code

🧩 the bricks that make a loop reliable

The charter describes the behavior. Here are the five Claude Code bricks that make it possible and reliable, unattended.

🗓️

Automations

Schedule the run instead of triggering it by hand: a scheduled routine ("every day at 8am, triage my issues"), or headless mode claude -p "your loop prompt" fired by an external scheduler.

🌳

Worktrees

Git worktrees give each agent an isolated copy of the project. Several agents work in parallel without overwriting each other. You just ask: "do this in a separate worktree".

📂

Skills

Markdown files in .claude/skills/ that store the project knowledge (structure, rules, formats). Write it once, and every loop run starts already informed.

🔌

Connectors

MCP integrations connect the agent to your real tools (email, task tracker, Drive, databases). "Find the work" then becomes "read my inbox" or "check my Linear board".

👥

Sub-agents

One agent builds, one agent reviews. The reviewer grades the builder's work independently. That is what makes a loop trustworthy when nobody is watching.

You do not need all five on day one. A simple loop holds up with a charter and an automation. You add worktrees, skills, connectors, and sub-agents as your loops grow.

The 3 caveats to know

⚠️ before you automate everything

A loop is not always the right answer. Keep these three limits in mind before you start.

🚫

A one-off task does not justify a loop

Single-answer work (write this email, summarize this document) runs faster as a regular prompt. A loop only pays off on repeating or multi-item work.

💸

It costs more

A loop that checks itself and retries burns several agent turns per item. You hit your usage limits faster. That is exactly why you set an "N items per run" limit.

✅

Verification is not optional

An unverified loop just makes mistakes faster. If you cannot describe how it should check its work, keep it as a prompt until you can.

Example 1: the research brief that checks itself

Take a classic task: write a one-page brief on a topic. The known trap is that Claude produces a clean brief with invented sources, without even knowing it made them up. The loop fixes this with a measurable goal.

🎯The goal that changes the result

Set the measurable goal. Every claim has at least 3 sources, and every link actually opens and supports the claim.

Let it write. Claude drafts a first version of the brief.

Make it check itself. It opens each source one by one, confirms it exists and that it really says what is claimed.

Loop until green. It replaces fake or weak sources, then runs the check again, until every source passes.

minimum sources per claim

max attempts per item before blocking

human intervention between runs

Without a loop, you do this verification by hand, link by link, after the fact. With the loop, that checking work is built into the system, and the brief only comes out when it stands up.

Example 2: your sales pipeline that follows up on its own

Working solo, what kills your revenue is almost never a lack of leads, it is the follow-ups that slip through the cracks. You had a conversation, then life takes over, and three weeks later the prospect is cold. This is repeating, multi-item work, perfect for a loop.

📈The sales follow-up loop

Set the measurable goal. Every prospect with no reply in 7 days has a personalized follow-up ready for you to approve.

Say where to find the work. Your CRM or database (Notion, Airtable, HubSpot): the records tagged "follow up" or with no contact in more than 7 days.

Let it do the work. For each record, Claude drafts a short follow-up that recalls the context of the last exchange. Not a generic copy-paste.

Verify, log, stop. It checks that the follow-up actually references the prospect's context and does not repeat the last message sent, then logs the date in the record. It sends nothing: it stacks the drafts so you approve them in five minutes.

The detail that matters: contacting someone is a human decision, so the loop stops right before sending, exactly as the charter prescribes. You keep your finger on the trigger, it does everything else.

Example 3: every video repurposed into multi-platform posts

You publish a video or a podcast episode, and 80% of the distribution potential dies because you do not have time to repurpose it. A loop turns a single piece of content into several posts, every time you release one.

✂️The content repurposing loop

Set the measurable goal. Every new video has 3 derivative posts ready (1 LinkedIn, 1 Instagram caption, 1 X thread), each with a hook on the first line and a CTA.

Say where to find the work. The list of your videos or episodes not yet repurposed: a folder, or a "to repurpose" row in your content database.

Let it do the work. From the transcript, Claude writes one post per platform, respecting each format (length, tone, hook structure).

Verify and cap it. It checks that each post has a hook on the first line, respects the platform's character limit, and ends with a CTA. You cap it at 2 or 3 videos per run so you do not blow through your usage.

The result: the day you publish, your derivatives are already ready to review and schedule, instead of staying a "to-do" that never gets done.

That is loop engineering: you no longer ask for a result, you describe what a successful job looks like, and you let the machine conform to it on its own.

Where to start

Pick a single repeating task you already do by hand. Write it a measurable goal, fill in the charter above, set a limit of a few items for the first run. You will tune the verification after you have watched it run once.