How to Create Loops with Claude: A Practical Guide to Agentic Automation
Claude Loop Engineering: How to Design Agents That Iterate, Verify, and Remember
Most Claude workflows still start as manual prompting: you write the prompt, wait for the answer, inspect the result, and decide what to ask next. That works for one-off tasks, but it becomes inefficient when the work is repetitive, stateful, or needs several rounds of checking. At that point, the better abstraction is not a better prompt. It is a loop.
A Claude loop is a repeatable workflow around the model. It defines what triggers the run, what context Claude should read, what it is allowed to do, how the output is verified, where the state is stored, and when the loop should stop, repeat, or escalate to a human. The model still performs the reasoning and tool use, but the loop provides the operating structure.
In this guide, we will build the idea gradually. We will start with a minimum viable Claude loop using TASK.md, LOOP_INSTRUCTIONS.md, PROGRESS.md, and an outputs/ folder.
Then we will add verification, persistent state, scheduled execution with /loop, safer permission boundaries, and optional connectors. The goal is not to make Claude fully autonomous from the beginning. The goal is to design a controlled workflow that can iterate, verify, remember, and become more useful over time.
Table of Contents:
What a Claude Loop Actually Is
When You Should — and Should Not — Build a Loop
The Minimum Viable Claude Loop
Adding Persistent State with PROGRESS.md
Verification: Separating the Worker from the Checker
Scheduling the Loop with /loop
Adding Tools, Connectors, and Safer Permissions
Complete Walkthrough: Building Your First Claude Loop
I’m hosting a live workshop on Hands-On Hermes Agent: Persistent Agents, Memory, Skills, and Real Workflows.
In 120 minutes, you will learn how Hermes Agent works, set up your first persistent agent, and build practical workflows with memory, skills, messaging, and automation.
1. What a Claude Loop Actually Is
Most people start with Claude by writing prompts manually. They describe a task, provide some context, wait for the response, review the result, and then decide what to ask next. This works well for one-off tasks, but it does not scale when the work is repetitive, stateful, or needs several rounds of checking and refinement.
A Claude loop changes the control structure around the model. Instead of you manually prompting Claude at every step, you design a small system that gives Claude a goal, provides the right context, lets it act, checks the result, records progress, and decides whether another iteration is needed. The important shift is not that Claude becomes fully autonomous. The shift is that the prompting process itself becomes part of the system.
At the simplest level, a loop has six parts:
Trigger — something starts the loop, such as a manual command, schedule, file change, Git event, or failed CI run.
Context — Claude reads the task description, relevant files, project instructions, and previous progress.
Action — Claude performs the next step, such as writing a report, editing a file, drafting a fix, or classifying failures.
Verification — the result is checked against a concrete condition, such as a checklist, test suite, linter, schema, or expected output format.
State update — the loop records what happened, what changed, what failed, and what should happen next.
Decision — the loop either stops, asks for human review, or runs another iteration.
A useful way to think about a Claude loop is that Claude remains the reasoning and execution engine, while the loop provides the operating structure around it. The loop decides when Claude runs, what Claude reads before acting, what Claude is allowed to change, how the output is checked, and what information survives after the session ends.
This last part is important. Claude sessions are temporary. A loop needs a persistent state outside the model if it is going to continue across multiple runs. That state can be a markdown file, a task board, a database entry, a GitHub issue, or any other durable record. In the simplest version, it is just a file called PROGRESS.md.
A Claude loop is not just “ask Claude again.” It is a repeatable workflow around Claude: trigger, context, action, verification, state update, and decision. The model performs the work, but the loop controls how the work continues.
For example, imagine a daily project review loop. Every morning, Claude opens a project folder, reads TASK.md and PROGRESS.md, checks what changed since the previous run, writes a short report, updates the progress file, and stops. You are not asking Claude from scratch each day. The loop gives Claude the same operating procedure every time and lets the state file carry information across runs.
A minimal folder for this kind of loop might look like this:
project-review-loop/
├── TASK.md
├── PROGRESS.md
├── LOOP_INSTRUCTIONS.md
└── outputs/
└── daily-review.mdTASK.md defines the purpose of the loop. PROGRESS.md stores what happened in previous runs. LOOP_INSTRUCTIONS.md tells Claude how to behave during each iteration. The outputs/ folder gives the loop a predictable place to write results.
The first version does not need connectors, sub-agents, worktrees, or complex automation. It only needs one constrained task and one reliable place to store progress. Once that works manually, you can add scheduling, verification, permissions, and tool access later.
The reason this pattern matters is that it changes the unit of work. With manual prompting, the unit of work is a single prompt-response interaction. With loops, the unit of work becomes a recurring process. You are no longer only designing what Claude should answer. You are designing how Claude should keep working toward a goal over time.
The simplest reliable loop should be deliberately small. It should read context, do one constrained job, write the result somewhere predictable, update state, and stop. More autonomy can be added later, but the first objective is repeatability.
This is also why loops are different from ordinary scripts. A script usually follows fixed instructions. A Claude loop can inspect the current state of a project, reason about what changed, decide which step is appropriate, and produce a new output based on the current situation. The loop provides structure, while Claude provides adaptive reasoning inside that structure.
However, that flexibility is also what makes loops risky if they are designed poorly. A loop with no state forgets what happened before. A loop with no verification trusts its own output too easily. A loop with no stop condition can waste time, tokens, and sometimes modify things it should not touch. The technical value of loop engineering is not simply making Claude run repeatedly. It is designing the boundaries that make repeated execution useful and safe.
Loop engineering is the practice of designing those boundaries: what starts the loop, what Claude can access, what Claude can change, how progress is recorded, how results are verified, and when a human must review the output.
In the next sections, we will build this idea gradually. Before creating a loop, we need to decide whether the task deserves one at all. Not every task should become an automation. Some work is too vague, too rare, too expensive, or too dependent on human judgment. A good Claude loop starts with the right task selection.
2. When You Should — and Should Not — Build a Loop
Before building a Claude loop, it is worth asking whether the task actually needs one. A loop adds structure, persistence, verification, and automation, but it also adds cost and operational complexity. For many tasks, a single well-written prompt is still the better option.
A loop is useful when the task is repetitive, stateful, and checkable. Repetitive means the task happens often enough that automation is worth the setup. Stateful means each run benefits from remembering what happened in previous runs. Checkable means there is some concrete way to decide whether the output is acceptable.
For example, a daily project review loop is a good candidate. The task happens repeatedly, the loop needs to remember previous progress, and the output can be checked against a simple structure: files reviewed, changes summarized, blockers listed, and PROGRESS.md updated. A one-time brainstorming session, on the other hand, is usually not a good candidate. It may be valuable, but it does not need persistent automation.
A Claude loop is most useful when the task repeats, the output can be checked, and the next run benefits from what happened in the previous run. Without those three conditions, a loop often becomes a more expensive version of a normal prompt.
A practical way to evaluate a task is to run a simple loop-readiness check.
The Loop Readiness Check
Before turning a task into a Claude loop, ask five questions:
Does this task repeat? If the task does not happen regularly, the setup cost may not be worth it. A loop works best when it runs daily, weekly, on every pull request, after every meeting, or after a specific recurring event.
Can the result be verified? The loop needs a way to reject bad output. In code workflows, this might be a test suite, type checker, linter, or build command. In document workflows, it might be a checklist, required output format, naming convention, or review rule.
Does Claude have enough context to act? The loop should have access to the files, instructions, logs, tickets, documents, or connectors needed to complete the task. If Claude cannot inspect the relevant environment, the loop will operate from an incomplete context.
Is there a clear stop condition? The loop must know when to stop, repeat, or escalate. “Continue until it looks good” is too vague. Better stop conditions include “the output file exists,” “all required sections are filled,” “tests pass,” or “the issue is marked for human review.”
Is there a safe review point? Any loop that can modify files, open pull requests, send messages, update tickets, or touch external systems should have a human checkpoint at the beginning. Automation should start with drafts and reports before moving toward direct action.
This checklist is useful because many loop ideas fail before implementation. The problem is not Claude’s capability. The problem is that the task has no stable trigger, no reliable verification step, or no clear definition of done.
Consider the difference between these two examples:
Bad loop candidate: Every day, improve the product strategy document until it feels stronger.
This is vague. The loop has no objective stop condition and no clear verification signal. The output depends heavily on judgment. Claude may generate useful suggestions, but the process should remain human-led.
A better version would be:
Better loop candidate: Every Friday, review the product strategy document, identify sections that changed during the week, list unresolved assumptions, and write a structured review note to outputs/strategy-review.md. Do not edit the strategy document directly.
This version is more suitable for a loop because it has a schedule, a limited scope, a predictable output file, and a safer permission boundary. Claude is not asked to make strategic decisions automatically. It is asked to inspect, summarize, and prepare material for human review.
Good First Loops
The best first loops are small and low-risk. They should produce outputs that are easy to inspect and safe to ignore if they are wrong. A useful first loop should usually write a report, update a state file, or draft a recommendation. It should not make irreversible changes.
Good first loop examples include:
Example #1: Daily project review:
Read the project folder every morning, summarize what changed, identify blockers, update PROGRESS.md, and write a report to outputs/daily-review.md.
Example #2: Meeting follow-up loop:
After a meeting notes file is added, extract action items, owners, deadlines, and unresolved questions into outputs/follow-up.md.
Example #3: Folder cleanup planning loop:
Inspect a messy folder, classify files by type, propose a cleanup plan, and write the plan to outputs/cleanup-plan.md. Do not move or rename files yet.
Example #4:CI failure triage loop:
When CI fails, read the logs, classify the failure, identify likely causes, and draft a report. Do not change code until a human approves the suggested fix.These tasks are good starting points because the loop can be constrained. It reads known inputs, produces known outputs, and updates the state in a predictable place. The loop can be useful even before it is allowed to make direct changes.
The first loop should usually be read-heavy and write-light. Let Claude inspect, summarize, classify, and draft before allowing it to modify important files or external systems.
Bad First Loops
Bad first loops tend to be broad, vague, high-risk, or difficult to verify. They usually sound attractive because they promise large automation gains, but they fail because the loop cannot reliably decide whether it has done the right thing.
Bad first loop examples include:
Example #1: Rewrite the entire backend architecture.
Example #2: Improve our product direction every week.
Example #3: Automatically modify authentication and payment code until all issues are fixed.
Example #4: Deploy changes to production when Claude thinks they are ready.
Example #5: Clean my whole computer and reorganize all files automatically.The common problem is not that Claude cannot help with these tasks. Claude can assist with planning, reviewing, drafting, and analysis. The issue is that these tasks involve high judgment, high impact, or unclear verification. They should be handled through supervised workflows, not unattended loops.
For example, “clean my whole computer automatically” is too broad for a first loop. A safer version is: “inspect the Downloads folder, group files by type, and write a proposed cleanup plan without moving anything.” Once the plan is reliable over several runs, the loop can be extended to rename or move files inside a controlled sandbox folder.
The Permission Ladder
A useful way to think about loop design is through a permission ladder. You do not need to start with full autonomy. In fact, most loops should begin with very limited permissions.
A safe progression looks like this:
Level 1 — Read-only analysis
Claude reads files and writes a summary.
Level 2 — Draft output
Claude writes reports, plans, or suggested changes in an outputs/ folder.
Level 3 — Sandbox edits
Claude modifies files only inside a controlled sandbox or draft branch.
Level 4 — Draft external action
Claude opens a draft pull request, draft message, or draft ticket update.
Level 5 — Human-approved action
Claude applies changes only after explicit approval.
Level 6 — Fully automated low-risk action
Claude completes the task automatically, with logs, limits, and rollback options.Most first loops should stay at Level 1 or Level 2. That is enough to prove whether the loop is useful. You can inspect the output, correct the instructions, improve the state file, and check whether Claude is making the same mistakes repeatedly.
Only after the loop becomes reliable should you move it up the ladder. This is especially important when the loop has access to code, customer data, production systems, private documents, or communication tools.
Cost and Noise Also Matter
A loop can fail even if it technically works. It may run too often, produce too much output, consume too many tokens, or create review work that is larger than the task it was supposed to automate.
This is why the first loop should have a limited scope and a predictable output. Before scheduling it, run it manually several times. Check how much context it reads, how long the output is, and whether the result is useful enough to review repeatedly.
A good loop should reduce cognitive load. It should not create a new inbox full of low-value reports. Runs that find nothing important should either update the state quietly or write a short “no meaningful change” note. Runs that find something important should make the reason clear.
A loop is not successful because it runs automatically. It is successful when it produces useful work with less supervision than manual prompting, while staying within clear cost, permission, and review boundaries.
A Simple Rule for Choosing the First Loop
For the first implementation, choose a task that is useful even if Claude only produces a report. This keeps the risk low and still demonstrates the core loop pattern: trigger, context, action, verification, state update, and decision.
A good first loop might be:
Every morning, review this project folder, compare it with the previous state, summarize changes, identify blockers, update PROGRESS.md, and write a daily report to outputs/daily-review.md.This task is practical, repeatable, and easy to extend. Later, you can add more capabilities: checking Git history, reading issue trackers, connecting to Slack, opening draft tickets, or suggesting code changes. But the first version should prove the operating model before adding more autonomy.
In the next section, we will build the minimum viable Claude loop around this idea: one task, one state file, one output folder, one verification step, and one controlled run.
3. The Minimum Viable Claude Loop
Once you have selected a task that is repetitive, low-risk, and easy to verify, the next step is to build the smallest version of the loop. This first version should not include advanced automation, multiple agents, external connectors, or broad permissions. The goal is to prove the operating pattern before increasing autonomy.
A minimum viable Claude loop has five parts:
One task — a clear, narrow job that Claude performs every run.
One context file — instructions that define how the loop should behave.
One state file — persistent memory that survives between runs.
One output location — a predictable place where Claude writes results.
One verification step — a simple check that decides whether the run is acceptable.
This version can run manually at first. Manual execution is not a weakness; it is the safest way to test the loop before scheduling it. You run the loop, inspect the output, adjust the instructions, and repeat until the behavior is stable.
The first Claude loop should be intentionally simple. It should read context, perform one constrained task, write output to a predictable location, update state, and stop. The objective is not full autonomy. The objective is repeatability.
For this section, we will use a practical example: a daily project review loop. The loop reads a project folder, summarizes what changed, identifies blockers, writes a short report, and updates its progress file. This example works well because it is useful, low-risk, and easy to adapt to code projects, writing projects, research folders, or course material.
The folder structure looks like this:
minimal-claude-loop/
├── TASK.md
├── PROGRESS.md
├── LOOP_INSTRUCTIONS.md
└── outputs/
└── daily-review.mdEach file has a specific role:
TASK.md defines the loop’s goal.
PROGRESS.md stores state between runs.
LOOP_INSTRUCTIONS.md defines the operating procedure Claude should follow.
outputs/daily-review.md stores the generated report.
