Here is the complete, production-ready Blogger-compatible HTML article: ```html
Two years ago, building with AI agents meant writing a careful prompt, reading the response, and typing the next instruction. The human held the tool. The workflow was turn-by-turn, prompt-by-prompt, and every session started from scratch.
That model is dissolving. A new discipline is emerging, one that asks a fundamentally different question: instead of crafting individual prompts, what if you designed the system that prompts the agents for you?
This discipline has a name. It is called Loop Engineering.
Coined and formalized by Cobus Greyling and expanded by Addy Osmani, Loop Engineering is the practice of building autonomous AI agent workflows that plan, execute, verify, hand off tasks, preserve state, manage costs, and continuously improve over time. It moves beyond isolated prompt crafting into the territory of systems engineering, where the developer designs once and the AI operates continuously.
The open-source Loop Engineering project provides the practical foundation for this shift. It offers starter templates, production patterns, audit tools, cost estimators, and implementation examples that help developers understand and build real autonomous AI workflows.
This article teaches the concept first, then uses the repository as a practical reference throughout.
Key Takeaways
- Loop Engineering replaces you as the prompter. You design a system that discovers work, assigns tasks to agents, verifies results, and persists state on a schedule.
- It builds on five primitives plus memory: Automations, Worktrees, Skills, Plugins and Connectors, Sub-agents, and a durable state file.
- The leverage point has shifted from crafting individual prompts to designing the control systems that orchestrate agents over time.
- Loop Engineering is tool-agnostic in shape. Claude Code, Codex, and Grok all share the same fundamental loop architecture.
- The open-source Loop Engineering project provides starter templates, CLI tools, audit scoring, cost estimation, and production patterns you can clone and adapt.
- Start in L1 (report-only) before enabling autonomous fixes. Unattended loops make unattended mistakes.
Open-source on GitHub under MIT License
Quick Information
Quick Verdict
What Is Loop Engineering?
At its core, Loop Engineering is the practice of designing a system that discovers work, assigns it to AI agents, verifies results, records outcomes, and decides what to do next — all on a schedule or until a goal is met.
Think of it this way. Traditional prompt engineering is like having a conversation with a colleague where you explain each task individually, one at a time. Loop Engineering is like writing a standard operating procedure once, then letting the team execute it repeatedly while reporting back to you only when something needs your judgment.
As Cobus Greyling explains in his foundational essay: "Loop engineering is the shift from you being the one who prompts the coding agent turn-by-turn to you designing a system that discovers work, hands tasks to agents, verifies results, persists state, and decides the next action — on a schedule or until a goal is met."
Addy Osmani, the former Director at Google Cloud AI, frames it even more directly: "Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead."
The concept has gained significant momentum in mid-2026. Peter Steinberger, creator of OpenClaw, stated publicly: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." Boris Cherny, head of Claude Code at Anthropic, echoed this from the inside: "I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops."
The implication is profound. The developer's highest-leverage activity is no longer crafting the perfect prompt. It is designing the system — the loop — that determines which prompts get sent, when they get sent, and what happens with the results.
Why Traditional Prompt Engineering Has Limitations
Prompt engineering remains valuable. A well-crafted prompt is still the fastest way to get a specific task done in a single agent session. But when you zoom out to the full workflow, several limitations become apparent.
Session Amnesia
Every agent session starts cold. The model has no memory of what it did five minutes ago, let alone last week. Without external state, the loop re-derives everything from scratch on every run. This is what Osmani calls "intent debt" — the gap between what the agent knows and what you actually intended.
Human Bottleneck
Turn-by-turn prompting requires the human to be present and engaged. If you walk away, the work stops. A prompt-driven workflow cannot run overnight, on weekends, or while you attend a meeting.
No Verification Built In
In a prompt-driven session, you are the verifier. You read the output, decide if it is correct, and type the next instruction. There is no structural separation between the agent that writes code and the agent that checks it.
No Cost Awareness
A single prompt does not require cost management. But when you chain dozens of prompts across parallel agents, token costs multiply rapidly. Without budget controls, a loop that spawns implementer and verifier sub-agents on every run can exhaust a token allocation before breakfast.
No Persistent Learning
In a prompt-driven workflow, lessons learned live in the human's head. The next session starts with the same assumptions and the same mistakes. There is no durable memory that accumulates knowledge across runs.
No Human Handoff Protocol
When an agent encounters something ambiguous or risky, it either guesses or asks in real time. There is no structured mechanism for escalating decisions to a human with full context.
Prompt Engineering vs Loop Engineering
The two approaches are not mutually exclusive. Prompt engineering is still the fastest way to get a single task done. Loop Engineering takes over when you need that task to happen repeatedly, reliably, and without you sitting at the keyboard.
Understanding Autonomous AI Workflows
An autonomous AI workflow is any system where the AI agent operates independently for a period of time, making decisions, taking actions, and reporting results without requiring human input at every step.
This is not a new concept in computer science. Software has had cron jobs, CI/CD pipelines, and monitoring systems that run autonomously for decades. What is new is that the agent running the loop can now reason about what it finds and decide what to do about it.
A CI pipeline runs tests and fails if something breaks. An autonomous loop runs tests, identifies the specific failure, drafts a fix, gets that fix reviewed by a second agent, and opens a pull request — all before a human wakes up.
The difference between a simple automation and an autonomous AI workflow is judgment. The automation executes a fixed script. The AI workflow evaluates what it finds and chooses an appropriate response from a range of possibilities.
This is also where the concept intersects with what Osmani calls the "factory model." The factory model is the system that builds the software: pipelines, agents, checks, and handoffs. Loop engineering is how you operate the factory floor — not manually assembling each unit.
The Lifecycle of an AI Agent Loop
Every well-designed loop follows a lifecycle. Understanding this lifecycle is the foundation of Loop Engineering. Each component exists for a specific reason, and removing any one of them weakens the entire system.
Planning
Before any work begins, the loop must determine what needs to happen. This is typically handled by a triage skill — a set of instructions that tells the agent what to look for (CI failures, open issues, dependency vulnerabilities) and how to prioritize what it finds.
The triage skill should produce a structured output format. Without this structure, the loop has no reliable way to determine what qualifies as actionable versus what is informational noise.
Task Execution
Once triage identifies actionable work, the loop spawns an implementer sub-agent. This agent receives a specific task, isolated context, and the project's skills (conventions, build commands, review standards). It works in an isolated worktree so its changes do not collide with parallel work.
Verification
This is the single most important structural pattern for reliable loops. The agent that wrote the code is a poor judge of its own work. A separate verifier sub-agent — sometimes on a stronger model, always with different instructions — reviews the output against the project's specifications, runs tests, and checks lint rules.
The implementer must never grade its own homework. This is not a model limitation. It is a structural one. As Osmani writes: "In unattended loops, the verifier is what lets you walk away with some confidence."
Handoff Between Agents and Humans
Some decisions belong to the loop. Some belong to a human. A well-designed loop has explicit triggers for escalation: maximum retry attempts, risky file paths, ambiguous requirements, or anything on a denylist.
When the loop escalates, it includes full context: what it tried, what happened, and what it needs from the human. This is the difference between a useful handoff and a noisy interruption.
State Management
The loop must track what it is working on, what it tried last time, and what is waiting for a human. Without a state file, the loop has amnesia on every run. It re-derives context, repeats mistakes, and cannot build on previous work.
Good state answers three questions: What are we currently working on? What did we try last time and what happened? What is waiting for a human?
Memory Persistence
This is the durable spine of the loop. A markdown file, a JSON document, a database row, a Linear board column — something that lives outside any single conversation and accumulates knowledge across runs.
The model forgets everything between sessions. The state file does not. Every long-running agent depends on this principle.
Cadence
How often does the loop run? The cadence must match the urgency of the work. A daily triage can run once per day on weekdays. A PR babysitter might run every ten minutes during active hours. A dependency sweeper can run every six hours.
The right cadence balances responsiveness against cost. Running heavy sub-agents every five minutes burns tokens rapidly. Running triage only once a day means problems sit for 24 hours before anyone notices.
Budget and Cost Control
Token costs can explode with sub-agents and frequent cadences. Every well-designed loop needs a budget file that tracks spending, sets daily caps, and provides a kill switch.
The Loop Engineering project includes a cost estimation tool (npx @cobusgreyling/loop-cost) that helps you predict token spend before enabling a loop in production.
Failure Recovery
Loops fail. The question is not whether they will fail, but how gracefully they recover. Common failure modes include infinite fix loops (the agent keeps trying the same approach), state rot (the state file references closed items), and verifier theater (the verifier approves but tests fail in CI).
Each of these has documented mitigations. The Loop Engineering project maintains a failure mode catalog that covers these patterns.
Continuous Improvement
A loop that runs the same way forever eventually drifts out of relevance. The best loops evolve: they update their skills based on new conventions, adjust their triage rules based on what worked, and accumulate lessons in their state file.
The Loop Engineering project itself runs its own loop engineering practices. The repository uses daily triage workflows, PR babysitters, and audit tools that score its own loop readiness.
Understanding LOOP.md
LOOP.md is the operational blueprint of a loop. It documents how a loop is operated, what its active loops are, how they coordinate, and what safety gates are in place.
In the Loop Engineering reference repository, the LOOP.md file serves a dual purpose. It is both documentation and the seed for the loops that maintain the repository. It describes active loops like daily triage, PR babysitter, dependency sweeper, and changelog drafter.
Each loop entry in the file specifies the cadence, the phase (report-only, assisted, or unattended), the skills used, and the handoff rules. This file is what tells the agents how to operate without human guidance.
Think of LOOP.md as the standard operating procedure for your autonomous AI workflow. Without it, the loop has no defined behavior. With it, the loop knows what to do, when to do it, and when to escalate.
Starter Templates
The Loop Engineering project provides ready-to-clone starter templates for different coding agents. Each starter contains the minimum viable configuration to begin running a loop.
Pattern Registry
The pattern registry is a machine-readable index of all documented loop patterns. Each pattern specifies its cadence, risk level, required skills, and verification approach.
The Loop Engineering project currently documents seven production patterns:
The project recommends starting with Daily Triage because it has the lowest risk and lowest token cost. You learn the mechanics of loops without risking production code.
Loop Audit
The Loop Audit tool is a CLI utility that scores your project's loop readiness. It inspects your repository for the presence of state files, skills, budget configurations, verification steps, and other loop engineering best practices.
Running the audit produces a numerical score from 0 to 100 and categorizes your loop readiness into levels:
The Loop Engineering reference repository itself scores 100 at L3, because it practices what it preaches.
Cost Estimation
Token costs are the most practical concern for anyone running loops in production. A 5-minute loop that spawns both an implementer and a verifier sub-agent on every run will consume tokens rapidly.
The loop-cost CLI tool helps you estimate token spend before enabling a loop:
npx @cobusgreyling/loop-cost --pattern daily-triage --level L1The cost estimation considers your chosen pattern, the number of sub-agents, the cadence, and the model you are using. It gives you a concrete number before you run up a bill.
The project recommends using a loop-budget.md file that defines daily token caps and a kill switch. If spending exceeds the cap, the loop pauses until the human reviews and decides whether to continue.
CLI Workflows
The Loop Engineering project provides four CLI tools, all available through npm:
All four tools are published to npm from tagged releases. No cloning required for end users.
How Developers Can Build Their First Loop
Building your first loop is a four-step process. The goal is to start simple, verify that the mechanics work, and expand only after the basics are proven.
Step 1: Scaffold Your Loop
Choose a starter pattern. The Daily Triage starter is the lowest-risk option because it only reports findings without taking autonomous action.
npx @cobusgreyling/loop-init . --pattern daily-triage --tool grokThis command scaffolds the minimum viable loop structure in your project directory and prints your Loop Ready score automatically.
Step 2: Estimate Costs
Before enabling the loop, check how much it will cost to run:
npx @cobusgreyling/loop-cost --pattern daily-triage --level L1Start with L1 (report-only) during your first week. This gives you visibility into what the loop finds without risking autonomous changes to your codebase.
Step 3: Run and Review
Let the loop run for one week in report-only mode. Review what it finds each day. This is the calibration phase. You are learning what the loop prioritizes, how noisy its output is, and whether the triage rules match your expectations.
Step 4: Audit and Improve
After a week, run the audit tool to see how your loop scores:
npx @cobusgreyling/loop-audit . --suggestThe --suggest flag shows you exactly which checklist items are missing and how to address them. Each suggestion is a copy-ready command you can run immediately.
Only after your L1 loop runs reliably for a week should you consider promoting to L2 (assisted fixes with verifier) or L3 (fully unattended).
Real-World Examples
Coding Agents
The most common application of Loop Engineering is automating coding workflows. A loop monitors CI failures, drafts fixes, opens pull requests, and runs tests. The human reviews and merges.
The Loop Engineering project includes examples for Grok, Claude Code, Codex, and OpenClaw. Each example demonstrates the same loop shape applied to different tool ecosystems.
Research Agents
A research loop can periodically scan academic databases, arXiv, or specific repositories for new papers matching predefined topics. It can summarize findings, categorize them by relevance, and surface them in a daily digest.
Business Automation
Loops can monitor CRM systems, support queues, or financial dashboards. When predefined thresholds are crossed, the loop generates reports, drafts responses, or escalates to the appropriate team.
Content Creation Pipelines
A content loop can aggregate news from specific sources, draft summaries, generate social media posts, and queue them for editorial review. Each piece goes through a maker/checker split where one agent drafts and another reviews for accuracy and tone.
Customer Support Automation
Support loops can monitor incoming tickets, categorize them by urgency, draft initial responses using the knowledge base, and route complex issues to human agents with full context preserved.
Advantages
- Continuous operation. The loop runs on a schedule, not when you happen to be at your keyboard. Work happens overnight, on weekends, and during meetings.
- Consistent verification. The maker/checker split means every output gets reviewed by a separate agent with different instructions. This structural separation catches errors that the implementer would otherwise miss.
- Persistent state. The state file accumulates knowledge across runs. The loop learns from what it tried and what worked, rather than starting from scratch every session.
- Cost visibility. Budget files and cost estimation tools make token spending visible and controllable. You can set daily caps and kill switches before running anything.
- Human handoff. Escalation triggers ensure that ambiguous or risky decisions land in front of a human with full context, rather than being guessed at by the agent.
- Tool-agnostic architecture. The loop shape is the same whether you use Claude Code, Codex, or Grok. You design the loop once and it works across tools.
- Scalable parallelism. Worktree isolation lets multiple agents work on different parts of the codebase simultaneously without collisions.
Limitations
- Token costs escalate. Sub-agents, frequent cadences, and long-running loops multiply token consumption. A loop that spawns implementer and verifier on every run can exhaust token allocations quickly.
- Verification is structural, not absolute. A verifier sub-agent reduces errors, but it does not eliminate them. Unattended loops make unattended mistakes. Human review remains essential.
- Comprehension debt. The faster the loop ships code, the bigger the gap between what exists and what you actually understand. You must actively read what the loop produces.
- Setup complexity. Building a well-structured loop requires understanding of state management, verification patterns, cost controls, and safety gates. This is not a trivial undertaking.
- Emerging discipline. Loop Engineering is still early. Best practices are evolving, tooling is maturing, and failure modes are still being cataloged.
- Cognitive surrender risk. The comfortable posture is the dangerous one. When the loop runs itself, it is tempting to stop having opinions. The same loop accelerates someone who stays the engineer and lets someone abdicate judgment entirely.
Common Beginner Mistakes
- Starting at L3. Enabling fully unattended loops before establishing L1 and L2 reliability. Always start in report-only mode.
- Skipping the verifier. Using the same agent session for both implementation and verification. The maker must never grade its own homework.
- No state file. Running the loop without durable state. The loop has amnesia every run and cannot build on previous work.
- Ignoring token budgets. Enabling heavy sub-agents on tight cadences without estimating cost first. This leads to surprise bills.
- Over-notify. Pinging the team on every run, not every actionable finding. Notification fatigue causes real escalations to be missed.
- No escalation triggers. Letting the loop retry indefinitely without a maximum attempt limit or human handoff.
- Auto-merge without path allowlists. Enabling auto-merge for all code changes rather than restricting it to verified trivial paths.
- Skipping the audit. Running loops without periodic readiness scoring. The audit tool catches drift before it becomes a problem.
Best Practices
- Start with Daily Triage in L1. Low risk, low cost, immediate visibility into what the loop finds.
- Use skills consistently. Encode project conventions, build commands, and review standards in SKILL.md files. This reduces intent debt.
- Always separate maker and checker. Different agents, different instructions, and ideally different models.
- Maintain your state file. Read it at the start of every run. Write outcomes and timestamps at the end. Prune stale entries.
- Set token budgets before enabling loops. Use loop-cost to estimate, loop-budget.md to cap, and loop-run-log.md to track.
- Escalate with context. When the loop hands off to a human, include what it tried, what happened, and what it needs.
- Read what the loop ships. Comprehension debt grows silently. Weekly human review of loop output is essential.
- Use worktree isolation. Every code-editing sub-agent should operate in its own worktree to prevent parallel collisions.
- Audit regularly. Run loop-audit after significant changes to verify your readiness score stays accurate.
- Document your loops. Keep LOOP.md updated with active loops, their cadences, and their safety gates.
Future of Loop Engineering
Loop Engineering is still in its early stages. As Cobus Greyling writes in his Substack essay, "The AI landscape is unfolding fast, tools and concepts are created on the fly." Loop Engineering follows in the lineage of Context Engineering and Harness Engineering, each addressing a different layer of the AI development stack.
Several trends are shaping the direction of this discipline:
Tool Convergence
Claude Code, Codex, and Grok have all landed on remarkably similar primitives. Automations, worktrees, skills, connectors, and sub-agents exist in all three tools. This convergence suggests that the loop shape is becoming tool-agnostic, which means the discipline of designing loops will persist even as specific tools evolve.
Community Patterns
The Loop Engineering project already maintains a pattern registry with seven production patterns. As more developers adopt loops, the pattern library will expand. The project actively invites contributions of patterns, starters, and failure stories.
MCP as the Connector Standard
Model Context Protocol (MCP) has become the common substrate for connectors. Connectors written for one tool often port to another. This interoperability makes loops more portable and reduces the lock-in risk.
Goal Engineering as a Companion
The Loop Engineering project lists Goal Engineering as a companion discipline. Loops discover work and iterate toward completion. Goals define what "done" means and ensure the loop stops at the right point. Together, they form a complete autonomous workflow framework.
Multi-Loop Coordination
As teams adopt multiple loops, coordination between them becomes important. The Loop Engineering project documents multi-loop coordination patterns, including priority ordering and collision prevention.
From L1 to L3 Over Time
The phased rollout model (report-only, then assisted, then unattended) will become the standard adoption path. Organizations will establish their own criteria for when a loop earns the right to act autonomously.
Expert Analysis
Loop Engineering represents a genuine shift in how developers interact with AI agents. The conversation has moved from "how do I write a good prompt" to "how do I design a system that uses agents effectively."
Peter Steinberger's observation that "you should be designing loops that prompt your agents" captures the essential insight. The developer's highest-leverage activity is no longer crafting the perfect instruction for a single turn. It is designing the architecture that determines when agents run, what they do, how their work is verified, and when humans need to be involved.
Boris Cherny's perspective from inside Anthropic confirms that this is not just a theoretical framework. It is how the people building these tools actually work. "My job is to write loops" is a statement about where the leverage point has moved in software development.
Addy Osmani's analysis adds important nuance. Two people can build the exact same loop and get completely opposite results. One uses it to move faster on work they understand deeply. The other uses it to avoid understanding the work at all. The loop does not know the difference. You do.
The open-source Loop Engineering project makes these ideas concrete. It provides not just the conceptual framework but the actual templates, tools, and patterns that developers need to build production loops. The MIT license and active community mean it will likely become the standard reference for this discipline.
The risk is cognitive surrender — the comfortable trap of letting the loop run while you stop having opinions about correctness or design. The remedy is deliberate engagement: reading what the loop ships, questioning its decisions, and maintaining the judgment that the loop amplifies rather than replaces.
Read Next
If you found this guide useful, you may also be interested in these related Provixx articles:
- UI-TARS Desktop: ByteDance's Open-Source Desktop Automation Agent — ByteDance's open-source desktop automation agent demonstrates how AI agents can interact with graphical interfaces, a capability that complements the code-focused loops described in this article.
- GitHub Spec Kit: AI Coding Framework — How GitHub's spec-based approach to AI coding intersects with the structured workflow design principles of Loop Engineering.
- Agency Agents: Open-Source Multi-Agent AI Framework — A framework for building multi-agent systems, relevant to the maker/checker split and sub-agent coordination patterns in Loop Engineering.
- New Open-Source AI Agents Frameworks — A roundup of emerging open-source frameworks for building AI agents, including tools that support the loop patterns described here.
Final Thoughts
Loop Engineering is not a bigger prompt. It is a different kind of system. Instead of writing instructions for a single interaction, you design the architecture that determines which interactions happen, when they happen, and what happens with the results.
The five primitives — automations, worktrees, skills, connectors, and sub-agents — plus durable state management form the building blocks. The patterns documented in the open-source project give you concrete starting points. The CLI tools let you scaffold, audit, estimate costs, and detect drift.
But the most important thing Loop Engineering teaches is not the tooling. It is the mindset shift. The developer is no longer the person who prompts the agent turn-by-turn. The developer is the person who designs the system that prompts the agents, verifies their work, records outcomes, and knows when to step in.
As Osmani writes: "Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go."
This is why Loop Engineering matters even if you are only beginning your journey with AI agents. Understanding how autonomous workflows are structured, how state persists across runs, and how verification separates reliable systems from fragile ones — these principles will serve you regardless of which specific tools you use or how the AI landscape evolves.
The leverage point has moved. Loop Engineering is how you follow it.
