🔁 /loop — The Execution Interval
O /loop is the most basic building block of loop engineering. It works like a cron job for AI agents: you set an interval (every 5 minutes, every hour), and Claude Code wakes up, checks the state of the world, does what needs to be done, and goes back to sleep. No human interaction in between.
"With slash loop, we set an interval for running a prompt. So like, for example, every five minutes, I'm going to check for new GitHub issues in this repo and handle any that come in."
In Portuguese: "With /loop, we set an interval for running a prompt. For example, every five minutes I’ll check this repo for new GitHub issues and take care of any that show up."
📋 Anatomy of a /loop
Interval
Time between each agent "wake-up." Typically 5 minutes, 15 minutes, 1 hour.
External input source
GitHub issues, a directory of files, an API, a database. The agent needs "something to look at."
Action prompt
What to do when you wake up. "Check for new issues. If there are any, handle the oldest one."
Active terminal
The /loop depends on the Claude Code terminal running. If you close it, the loop stops.
🎯 Reflection Point
The /loop is powerful for repetitive, predictable tasks, but it has a fundamental limitation: everything runs in the same Claude Code session. As Cole points out later, "if you loop for a while, you're going to completely bloat your context for your LLM and overwhelm it." The /loop works well for short cycles. For extended work, you need something more.
🎯 /goal — The Completion Criteria
While /loop defines "when to wake up," the /goal defines "when to stop." You set objective completion criteria, and the agent works until it meets them. There’s no fixed interval. The agent stays active until the condition is true.
"So we set some criteria like here is how you know you are done. And then we're forcing the coding agent to work until it is done, kind of like Ralph loops that went viral a few months ago."
In Portuguese: "We set criteria like, ‘This is how you know you’re done.’ Then we have the agent work until it’s finished, kind of like the Ralph loops that went viral."
Good /goal criteria
- ✓"All tests pass"
- ✓"Zero open issues in the repo"
- ✓"All tasks in plan.md marked as done"
- ✓"The build compiles without errors"
Risky criteria
- ✗"Make the code good" (too subjective)
- ✗"Everything works" (no verifiable metric)
- ✗"Make the app look good" (impossible to evaluate)
- ✗No iteration limit (infinite loop)
⚠️ The Risk of Unbounded /goal
If the completion criteria are poorly defined or impossible to meet, /goal becomes an infinite loop that burns tokens nonstop. Cole mentions that for a relatively simple app, he spent over 1 million tokens. Always set a maximum number of iterations along with /goal, or use timeouts as a safety net.
📅 /routines — Scheduled Jobs
O /routines is the third building block. Unlike /loop (short interval, repetitive task) and /goal (work until completion), /routines are scheduled jobs with broad scope. Think of it as "every hour, wake up, look at the complete spec document, and handle the next task in the queue".
"And finally, we have /routines. These are scheduled jobs. For example: every hour, I want you to wake up, check a broader spec document, and take care of the next task."
In Portuguese: "And finally, we have /routines. These are scheduled jobs. For example: every hour, I want you to wake up, check a broader spec document, and take care of the next task."
🔄 /routines vs. /loop: What’s the Difference?
| Aspect | /loop | /routines |
|---|---|---|
| Interval | Short (minutes) | Long (hours) |
| Scope per cycle | Single, quick task | Task from a larger spec |
| Input | External event (issue, webhook) | Complete spec document |
| Analogy | Simple cron job | Scheduled batch processing |
🧩 How the Building Blocks Fit Together
The strength of loop engineering isn’t in any one isolated block. It’s in the combination of them to form a coherent system. Boris Cherny, for example, uses /routines to schedule work cycles, /goal within each cycle to define when the agent has finished a stage, and /loop to monitor external events between cycles.
"Engenharia de loops é combinar ou criar um sistema em torno de todas essas coisas — rotinas, /loop — para que possamos fornecer um escopo de trabalho maior a um assistente de programação com IA e fazer com que ele avance aos poucos."
In Portuguese: "Engenharia de loops é combinar ou criar um sistema em torno de todas essas coisas — rotinas, /loop — para que possamos fornecer um escopo de trabalho maior a um assistente de programação com IA e fazer com que ele avance aos poucos."
📋 Combined System Example
Every 1 hour, wake the orchestrator and say: "look at the spec, identify the next pending task."
The orchestrator sets up a /goal for the worker: "Implement feature X. You're done when all tests pass."
In parallel, a /loop checks every 5 minutes for new issues on GitHub. If it finds any, it adds them to the spec.
🎯 Reflection Point
The key word in Cole’s quote is "incrementally." The central idea of Loop Engineering isn’t to give the agent an entire project and say "do it." It’s to break the work into small cycles, each with a limited scope and its own validation. Without that, the agent tries to solve everything at once and, as Cole warns, "it will get completely overwhelmed".
🔧 The Loop Skill: Self-Assembly
One of the most interesting things Cole demonstrated and that Claude Code has is a internal capability called "loop skill". You don't need to configure /loop manually. Just tell Claude Code to load the skill, and it builds the loop system on its own, deciding the interval and strategy.
"You just tell it to use the loop skill. So there's a capability built right into the tool where it knows how to set up these loop systems based on what we ask it to do."
In Portuguese: "You simply tell it to use the loop skill. There's a capability built into the tool that knows how to set up these loop systems based on what we ask it to do."
🖥️ What Cole Demonstrated
Input: simple spec document
A numbered task list in plan.md. Nothing elaborate.
Claude Code identified the structure
"It says this is a sequential list of tasks: it’ll run the first one and then schedule a short wake-up."
The loop configured itself
"It wrote the prompt: /loop work through plan.md one task at a time." Cole didn’t write that prompt. Claude Code did.
Incremental execution
In 2 minutes, it had already completed the first 2 tasks. Each wake-up completes one task and schedules the next.
💡 Important Insight
The fact that Claude Code sets up the loop on its own is technically impressive, but there's a dangerous side: you lose visibility into how the loop was configured. Cole deliberately used a simple example, but in Boris Cherny's systems with “tens of thousands of agents,” automatic setup without observability is a real risk.
❓ Questions
The three building blocks seem simple. And they are. But that simplicity hides real pitfalls that need to be surfaced before you start implementing.
Does everything run in the same session?
Cole raises a structural problem: "you're not really working between different coding agent sessions. Like when you're just using /loop in Claude Code, it's really just continuing in the same coding agent session." This means inevitable context bloat. Each loop iteration adds more context, and the LLM becomes progressively more overwhelmed. It’s an architectural limitation, not a bug.
What is the real cost of maintaining these loops?
Each /loop wake-up consumes tokens. Every /goal iteration does too. And /routines, which read an entire spec each cycle, are especially expensive. Cole measured more than 1 million tokens for a simple app. If you pay per token, the bill adds up fast.
What if the loop makes the wrong decision?
When Claude Code auto-builds the loop via a skill, it also decides the next cycle's prompt. If that decision is wrong, the error spreads to all subsequent cycles. Without a human in the loop, you only discover the problem after you've already spent tokens and time. Cole calls this "the biggest problem with loop engineering right now."
⚠️ The Limit of Blocks Alone
/loop, /goal, and /routines are primitives. They're the building blocks, not the house. Without an orchestration system that distributes work across different sessions, manages state externally, and allows human intervention, these blocks produce mediocre results for anything beyond simple demos. The next module (1.3) shows how the Orchestrator-Workers architecture solves exactly that.
📋 Module Summary
Next Module:
1.3 — Orchestrator-Workers Architecture