Update — July 18, 2026: The next layer is here — graph engineering makes multi-agent organizations programmable. Loops = one agent's behavior. Graphs = the org structure connecting many agents.
In June 2026, a single quote from Boris Cherny—the creator of Claude Code at Anthropic—quietly reframed how developers think about AI:
"I don't prompt Claude anymore. I have loops that are running. They're the ones that are prompting Claude and figuring out what to do."
That shift—from you prompting the agent to a system prompting the agent—is what loop engineering is about.
June 30, 2026: Andrew Ng adds a product-building lens — inner agentic coding loops (minutes) nested inside developer feedback (hours) and external user feedback (days) when shipping 0→1 software.
Video course: Introduction to Loop Engineering (~1 hour on Udemy) — ReAct, reflection, tool-use, and multi-agent loops; Claude Code
/loopin Cursor; termination, memory, and guardrails. Course hub →
The One-Line Definition
Loop engineering is the practice of designing the system that prompts your AI agent, rather than typing each prompt yourself.
Where prompt engineering asks: "What should I say to get the best output?"
Loop engineering asks: "What system should I build so the agent finds the work, does it, verifies it, and remembers what it did—without me in the loop at all?"
Where It Came From
The term was popularized in June 2026 by Addy Osmani (engineering lead at Google Chrome), synthesizing ideas from Boris Cherny at Anthropic and Peter Steinberger (founder of PSPDFKit/Nutrient). The framing appeared across Osmani's blog, a Substack post, and a GitHub reference repository that quickly became a community standard.
The timing wasn't accidental. By mid-2026, AI coding agents had become capable enough to run multi-step tasks autonomously for hours. The bottleneck shifted from model capability to orchestration design. Developers who were still typing prompts one at a time were leaving 90% of the value on the table.
Prompt Engineering vs. Loop Engineering
| Dimension | Prompt Engineering | Loop Engineering |
|---|---|---|
| Unit of work | One turn | Entire autonomous run |
| Who drives the agent | You, manually | A system you designed |
| Duration | Seconds | Minutes to hours |
| Output | A response | A verified outcome |
| Leverage | 1× | 10–100× |
| Skill required | Phrasing | System design |
Prompt engineering isn't dead—it's table stakes. Loop engineering is the next layer.
The Five Components of a Loop
Every well-designed agent loop has the same five parts:
1. Trigger
What starts the loop. This can be:
- A schedule (every morning at 9am, check for open issues)
- An event (a PR opens, a test fails, a deploy completes)
- A human instruction ("go fix all ESLint warnings")
- Another agent completing its task
Without a trigger, you're still prompting manually. The trigger is what makes the loop autonomous.
2. Goal
A verifiable end state the agent works toward. Not "make things better"—but "all tests pass" or "zero open P1 issues" or "bundle size under 200KB."
Vague goals produce vague loops. The agent needs something it can check against. The /goal command in Claude Code is the clearest implementation of this idea: you define the completion condition upfront, and Claude iterates until it's met or the budget runs out.
3. Actions
The tools the agent can use inside the loop:
- Read and write files
- Run bash commands
- Call APIs and MCP servers
- Spawn sub-agents
The actions define the surface area of the loop. Wider action sets mean more autonomy but more risk. Claude Code hooks let you intercept and gate these actions—running linting after every file edit, blocking dangerous commands before they execute.
4. Verification
How the loop knows when to stop. This can be:
- Running tests and checking exit codes
- A supervisor agent reading the final state and confirming the goal was met
- A diff review by a second model
- A CI pipeline passing
Without verification, loops either run forever or stop too early. The supervisor architecture in Claude Code's /goal spawns an independent session to audit whether the primary agent actually achieved what it claimed.
5. Memory
What persists across iterations so the agent doesn't repeat work or lose context:
- Session persistence (
--continue,--resume) — reload a previous conversation - CLAUDE.md — stable project context loaded every session
- External memory (databases, files, vector stores) — cross-session state
Memory is what separates a loop that learns from one that spins.
What a Loop Looks Like in Practice
Here's a concrete example—a morning triage loop:
Trigger: Every weekday at 8am
Goal: All GitHub issues labeled P1 have an assigned owner and a comment with a plan
Actions: Read GitHub issues (via MCP), write comments, assign labels
Verify: Check that zero P1 issues have no assignee
Memory: Log of issues already triaged this week
You set this up once. Every morning, an agent wakes up, pulls the issue list, triages anything unassigned, writes initial plans, and stops when the goal is confirmed. You review the results over coffee.
That's the leverage Boris Cherny was describing.
For a deeper implementation guide with Claude Code specifically, see: Loop Engineering: How to Design Coding Agent Loops That Run While You Sleep.
The Infrastructure Behind Loops
Building loops at scale requires more than just a good prompt. The key infrastructure layers:
Worktrees — Parallel agent runs that edit different parts of the codebase simultaneously need isolated working trees. Without them, two agents stepping on the same files creates corrupted state.
Scheduling — Whether it's cron, GitHub Actions, or Claude Code's built-in /bg command and Agent View, you need something that fires the trigger reliably.
Skills and CLAUDE.md — Loops that lack project context make bad decisions. CLAUDE.md files and skill definitions are how you encode what the agent should always know without burning context on it every turn.
MCP servers — Agents that can only read files are limited. MCP servers plug your agent into the external systems it needs: GitHub, Slack, your database, your CI system. See our guide on Claude Code MCP servers.
Observability — Long-running loops need logging. What did the agent do? Where did it stop? Why did it fail? Without observability, debugging a broken loop is guesswork.
Common Failure Modes When You First Build a Loop
Most first attempts at loop engineering fail in one of four predictable ways. Recognizing the pattern early saves hours of debugging a loop that was architecturally doomed from the start.
1. The goal is unverifiable, so the loop never stops. A goal like "improve code quality" has no check condition — the agent can iterate forever and never know it's done. Every goal needs a binary or measurable test: a passing test suite, a linter with zero errors, a specific metric crossing a threshold. If you can't write the verification step in one sentence, the goal isn't ready for a loop yet.
2. The action surface is too wide for the trust level. Giving an unsupervised overnight loop full write access to production infrastructure, secrets, or billing systems is how a small bug becomes an incident. The fix isn't "don't automate it" — it's scoping actions to match how much you trust the loop's current track record. Start loops in a sandboxed branch or worktree with narrow permissions, and widen the action surface only after the loop has a track record of hitting its verification step correctly.
3. There's no memory, so the loop repeats itself. A loop that starts fresh every run re-discovers the same context, re-reads the same files, and sometimes re-does work it already finished. This is the single most common reason loops feel expensive relative to their output — most of the token spend goes to re-deriving state instead of making progress. CLAUDE.md and session persistence exist specifically to eliminate this.
4. Verification is delegated back to the same agent that did the work. If the agent that wrote the code is also the one that decides whether the code is good, you've built a loop that confirms its own success by construction. The fix is a second, independent check — a separate supervisor session, a CI pipeline that doesn't share context with the worker, or a human spot-check on a sample of runs. This is why the /goal command's supervisor architecture spawns a fresh session to audit the primary agent's claimed outcome rather than trusting its self-report.
Measuring Whether a Loop Is Actually Worth Running
Not every repetitive task deserves a loop. Before investing in trigger, verification, and memory infrastructure for a task, it's worth running a quick cost check:
| Question | If the answer favors loops | If the answer favors manual work |
|---|---|---|
| How often does this task recur? | Daily or more | One-off or rare |
| How verifiable is "done"? | Tests pass / metric hits threshold | Subjective judgment call |
| What's the blast radius of a bad run? | Low — sandboxed, reversible | High — customer-facing, irreversible |
| How much human review does output still need? | Spot-checks only | Full review every time |
A loop that still requires full human review of every output isn't saving leverage — it's just moved the work from "doing the task" to "reviewing the agent's attempt at the task," which is sometimes more expensive than doing it directly. The highest-value loops are the ones where verification is cheap and automatic (tests, linters, metrics) and the failure cost is low, because that's where the agent can run unsupervised and you only look at the exceptions.
Why This Is a Paradigm Shift
The deeper implication of loop engineering is a change in where the developer's leverage lives.
In the manual prompting era, a developer who was good at phrasing got better results. In the loop engineering era, the leverage is in system architecture—the quality of the trigger, the precision of the goal, the design of the verification step.
This isn't about replacing developers. It's about elevating what developers do. As the Anthropic engineer's framing put it: the developer who builds the loop once gets compounding returns every time it runs.
The developers who thrive in the agentic era won't be the ones who write the best prompts. They'll be the ones who design the best loops.
Where to Go Next
If you want to go deeper on the practice side:
- Run loops in your harness (Aug 20, 2026): Claude Code · Cursor · GitHub Copilot · Codex CLI · Copilot Studio · Microsoft 365 Copilot
- Loop Engineering for Students: Career Guide — degrees, certifications, career prospects, and a hands-on /loop tutorial
- Introduction to Loop Engineering (Udemy) — ~1-hour video: ReAct loops,
/loopin Cursor, guardrails, and failure-mode fixes - Top 5 Loop Engineering Courses in 2026 — ranked: explainx.ai's course and live workshop vs DeepLearning.AI, Anthropic Academy, and LangChain Academy
- Andrew Ng's Three Loops for 0-to-1 Products — product vision, spec, and user feedback clocks (June 2026)
- Loop Engineering Goes Mainstream: June 2026 Discourse Decoded — why the whole developer internet is talking about this right now
- Claude Code Loops Official Guide (July 2026) — Anthropic's taxonomy for /goal, /loop, /schedule
- Loop Engineering: Coding Agent Loops That Run While You Sleep — hands-on implementation guide
- Claude Code Dynamic Workflows — how dynamic scheduling works in practice
- Fable 5 Loop Design: Self-Correction and Memory — advanced loop patterns with self-correction
- The Agentic Era: What Changes from 2026 to 2030 — the bigger picture of where this is heading
- Agent Harness Engineering — the scaffolding layer that sits around the loop
- LoopX: A Control Plane for Long-Running Agent Work — an open-source state kernel for multi-day loops (objectives, gates, quota, evidence)
- Elon Musk cited "The Machine Stops" over Blizzard's outage — why teams running loops in production need runbooks and rotation, not just a working loop, so understanding doesn't disappear along with the manual work