Loop Engineering: How Claude's Scheduled Tasks Actually Run Themselves
How Claude's scheduled tasks use loop engineering, done criteria, and turn, time, and event triggers to run business workflows without supervision.
What is loop engineering in Claude?
Loop engineering is the practice of giving an AI agent a repeatable cycle of work with a clear finish line, instead of a single prompt and reply. Claude keeps working through a task, checking in on itself, and only stops (or comes back to you) once a specific “done” condition is met. Anthropic has documented this concept directly, describing it as the mechanism behind Claude’s scheduled tasks: rather than answering one question in a chat window, Claude plans and executes a sequence of steps autonomously, pausing for human input only when it actually needs it.
TL;DR
- Loop engineering replaces one-off chat prompts with a repeating cycle: Claude works until a defined finish condition is met, not until it runs out of things to say.
- Done criteria is the core skill to learn. A clear finish condition like “every transaction is matched or flagged for review” tells Claude exactly when a loop can stop.
- Three trigger types drive loops: turn-based (you send a message), time-based (a schedule, like every Friday at 4pm), and event-based (something happens, like an email arriving).
- Time-based triggers dominate most practical business use cases because they remove the need for you to sit in the loop as a middleman.
- Event-based triggers can be simulated with frequent time-based checks, such as scanning an inbox every hour to catch new emails as they arrive.
- Claude Cowork can’t touch local files, so workflows that need shared context (voice profiles, templates, contacts) typically get routed through connectors to tools like Notion or Composio.
- Vague prompts produce vague loops. The clearer the done criteria, the faster a scheduled task gets built and the more reliably it runs unattended.
Remy doesn't write the code. It manages the agents who do.
Remy runs the project. The specialists do the work. You work with the PM, not the implementers.
How does a Claude loop actually work?
A loop starts with a task and a condition for stopping. Claude uses its planning and reasoning capabilities to figure out the steps needed to reach that condition, executes them, checks whether the condition is satisfied, and either finishes or keeps iterating. This is different from a normal chat exchange, where the model produces one response and waits for the next human message.
The practical shift is that you’re no longer prompting Claude turn by turn. You’re defining an outcome and letting Claude figure out the path. A basic example: “keep going until every receipt is matched to a transaction or flagged for my review.” That single sentence gives Claude a criteria of done. It can now plan a multi-step task, hunting through inboxes, matching data, and flagging exceptions, without you specifying each individual action.
Human input still has a role. Loop engineering deliberately builds in checkpoints so a person can review, correct, or approve before the loop continues. This keeps output quality high while still removing the busywork of manual, step-by-step supervision.
What are done criteria and why do they matter?
Done criteria are the explicit conditions that tell Claude when a loop is finished. They’re the single most important thing to get right when setting up a scheduled task, because a vague or open-ended goal produces an agent that either stops too early, keeps going in unhelpful directions, or can’t tell you clearly what it accomplished.
Good done criteria tend to share a few traits: they’re measurable, they cover the full scope of the task, and they define what happens when the task can’t be completed cleanly. An invoice reconciliation loop, for instance, isn’t “done” when Claude has matched some receipts. It’s done when every transaction from a given period is either matched or placed on a list for manual follow-up. That second branch matters. Real-world data is messy, and done criteria need to account for the cases where Claude can’t finish something on its own.
Writing done criteria well is largely about specificity. Instead of “clean up my inbox,” a workable done criteria might be “review every unread email from the last 24 hours, draft a reply for anything matching a known template, and flag anything unusual for manual review.” The more precise the finish line, the less back-and-forth is needed to get the loop running correctly.
What are the three trigger types for scheduled loops?
Loops get started in one of three ways.
Turn-based triggers happen when a person sends a message and Claude works until it hits the done condition, then returns control. This is the most familiar mode, but it requires a human to be present to kick things off, which limits how much time it actually saves. It’s best suited to tasks that genuinely need a person to initiate them each time.
One coffee. One working app.
You bring the idea. Remy manages the project.
Time-based triggers run on a schedule: every Friday at a set time, on the first of the month, twice a day on weekdays. This is where most practical business automation lives, because it removes the need for a person to remember or initiate anything. A reconciliation task that runs every Friday afternoon, or a subscription audit that runs monthly, both fall into this category.
Event-based triggers fire when something happens in the world: a meeting ends, an email lands in an inbox, a file gets updated. These are powerful because they make the loop reactive rather than merely scheduled, but they depend on being able to detect the event reliably.
A useful workaround is to convert an event-based need into a time-based trigger by checking frequently. Instead of waiting for a true “new email received” event, a loop can check the inbox every hour and treat “new email found” as the condition that kicks off the rest of the process. This sacrifices a small amount of latency for much simpler setup.
What gets in the way of building these loops?
Two practical constraints show up repeatedly. First, scheduled tasks running in the cloud can only reach external apps through built-in connectors. There’s no general credential vault, so raw API keys typically can’t be pasted into a task’s configuration. Second, many built-in connectors are scoped to a single account, for example one Gmail inbox, which breaks down as soon as a workflow spans multiple email addresses or data sources.
The common fix is to route through an integration layer such as Composio, which sits between Claude and the target apps, holds the necessary credentials on its own side, and exposes multiple accounts or services through a single connector. Claude never sees the underlying credentials directly, it just calls the connector.
A related constraint is that cloud-run scheduled tasks can’t access local files or folders on your desktop. Any shared context a loop needs, like a brand voice profile, a set of email templates, or a contacts list, has to live somewhere a connector can reach, which in practice often means a tool like Notion rather than a local drive.
Is loop engineering worth setting up for a small business?
For repetitive, well-defined processes, yes. The setup cost is mostly in defining done criteria clearly and wiring up the right connectors, which is typically a one-time effort of minutes to an hour depending on complexity. Once running, a scheduled loop removes the need for a person to remember, initiate, or manually execute the same task on a recurring basis.
The tradeoff is that loop engineering isn’t well suited to ambiguous, judgment-heavy work where “done” can’t be defined in advance. It works best for processes with a clear, checkable end state: matching transactions, auditing recurring charges, drafting emails in a known style, or converting meeting notes into task list entries. For those categories, the combination of a clear done criteria and a time-based or event-based trigger turns a recurring manual chore into something that runs in the background.
Frequently Asked Questions
What is the difference between a loop and a regular chat with Claude?
A regular chat is one prompt and one response, with a human deciding what happens next. A loop is a repeating cycle where Claude keeps working, checking its own progress against a done condition, and only returns to the human when the condition is met or when it genuinely needs input.
What makes done criteria “good” versus “bad”?
Good done criteria are specific and measurable, and they account for edge cases where Claude can’t complete something automatically. A bad done criteria is open-ended, like “handle my emails,” with no clear stopping point or fallback for cases the agent can’t resolve.
Can event-based triggers really be replaced with time-based ones?
Yes, in many practical setups. Checking an inbox or a data source on a frequent schedule, such as every hour, can substitute for a true real-time event trigger, at the cost of some delay between the event happening and the loop reacting to it.
Why can’t scheduled tasks just use my local files?
Cloud-run scheduled tasks operate outside your local desktop environment, so they can’t read files or folders stored on your machine. Any information a loop needs has to be accessible through a connector, which usually means storing shared context in a connected app rather than a local file.
Do these loops still need human oversight?
Yes. Loop engineering is built around checkpoints where Claude pauses for review or approval rather than acting fully unsupervised. This keeps quality high while still removing the need for constant, manual, turn-by-turn interaction.
