The Stack Observer
Agentic AI

Loop Engineering: How AI Agents Started Designing Their Own Prompts

•Stackxx•Agentic AI, AI, DevOps

In June 2026, Boris Cherny—creator of Claude Code at Anthropic—said something quietly revolutionary: “I don’t prompt Claude anymore. I have loops that are running.”

That single sentence captures the biggest shift in how developers work with AI since ChatGPT. The term loop engineering, popularized days later by Google engineering lead Addy Osmani, describes a practice already reshaping workflows: designing autonomous systems that prompt agents, evaluate their own output, and decide whether to continue, retry, or stop.

From Prompts to Systems

For the last three years, prompt engineering was the bottleneck: what should I say to get the best output? Developers spent hours crafting one-shot prompts, tweaking temperature settings, and debating zero-shot versus few-shot approaches. It was a craft, and the best practitioners could coax remarkable outputs from carefully worded instructions.

By mid-2026, that craft became table stakes. Models got smart enough to run multi-step tasks for hours. The problem was no longer output quality—it was orchestration. A developer typing prompts one at a time into a chat interface was essentially operating a manual lathe in a CNC factory. The leverage had moved upstream, from the prompt to the system that generates, evaluates, and manages prompts automatically.

Loop engineering replaces the single prompt with a system: a trigger that starts work without human intervention, a goal that defines completion, a set of actions the agent can take, a verification step that checks results, and memory that persists across iterations. You don’t type the prompt. You design the loop that types it for you.

The Anatomy of a Loop

Every production-grade agent loop has the same five components, whether running inside Claude Code, Cursor, or a custom orchestration framework:

1. The Trigger

The trigger starts the loop without human input. It can be a schedule—every weekday at 8am, check for unassigned issues. It can be a CI/CD event: a test failure, a deploy completion, a new pull request. Or a signal from another agent. The trigger makes the loop autonomous rather than interactive.

In practice, triggers are becoming first-class infrastructure. GitHub Actions fire webhooks on PRs. Cron jobs poll APIs. Claude Code’s /bg command lets agents run detached from the terminal. The trigger layer is where loop engineering intersects with traditional DevOps.

2. The Goal

A goal is not a vague aspiration like “make the code better.” It is a verifiable end state the agent can check: “all tests pass,” “zero open P1 issues,” “bundle size under 200KB.” The Anthropic /goal command in Claude Code is the clearest implementation: define completion conditions upfront, and the agent iterates until they’re met or the budget runs out.

Precision matters. A goal like “fix the bug” gives the agent no way to verify success. A goal like “the reproduction script exits with code 0 and produces no error output” gives a concrete target. Vague goals produce vague loops. Specific goals produce specific outcomes.

3. The Actions

Actions are the tools the agent can use: reading and writing files, running shell commands, calling APIs or MCP servers, spawning sub-agents for parallel tasks. The action set defines the surface area of the loop. A narrow set—read files, run tests—produces a safe but limited loop. A wide set—full shell access, production database writes—produces a powerful but risky one.

This is where permission systems come in. Hooks let you gate actions: run linting after every file edit, block dangerous commands, require human approval for production changes. The action layer is where security and autonomy trade off, and getting this boundary right is a core loop engineering skill.

4. The Verification

Verification tells the loop when to stop. Without it, loops run forever or quit too early. Verification can be: running tests and checking exit codes; a second model auditing whether the primary agent achieved its goal; a CI pipeline passing; or a supervisor agent confirming the final state matches the goal.

The most robust loops use multiple verification layers. A coding agent might verify by running tests and asking a second model to review the diff and checking for new security vulnerabilities. This is expensive in compute but cheap compared to shipping a bug. Claude Code’s /goal explicitly spawns an independent session to audit claimed success.

5. The Memory

Memory persists across iterations so the agent doesn’t repeat work. Session persistence (--continue, --resume) lets agents pick up where they left off. Project context files like CLAUDE.md encode stable knowledge. External memory—databases, files, vector stores—enables cross-session state that survives restarts.

Memory separates a loop that learns from one that spins. An agent with no memory retries the same failed approach. An agent with good memory remembers that apt-get failed last time because the container lacks sudo, and adjusts. That small difference compounds over long-running loops.

What This Looks Like in Practice

Consider a morning triage loop:

  • Trigger: Every weekday at 8am, fired by cron
  • Goal: Zero P1 issues are unassigned and lack a triage plan
  • Actions: Read GitHub issues via MCP, write comments, assign labels, @mention team members
  • Verification: Query GitHub API until unassigned P1 count reaches zero
  • Memory: A log of issues already triaged this week

You design this once. Every morning, the agent wakes up, pulls the issue list, triages anything unassigned, writes plans, assigns owners, and stops when verification passes. The team lead reviews results over coffee rather than doing triage manually. That is the leverage Boris Cherny described.

Another example: a dependency vulnerability scan loop. Triggered by Dependabot alerts, the agent reads the advisory, checks if the vulnerable dependency is used in production code paths, generates a patch or upgrade plan, runs tests, and opens a PR. The human reviews the PR. The loop did the investigation, patch generation, and validation.

The Infrastructure Stack

Running loops at production scale requires more than a good prompt:

  • Worktrees and isolation: Parallel agents need isolated working trees. Without them, two agents editing the same files create corrupted state. Git worktrees and containerized environments are standard.
  • Scheduling: Cron, GitHub Actions, or built-in commands like Claude Code’s /bg. The scheduling layer is where loop engineering meets traditional automation.
  • Context encoding: CLAUDE.md and skill definitions encode project knowledge without burning context tokens every turn.
  • MCP servers: The Model Context Protocol connects agents to GitHub, Slack, Jira, databases, CI pipelines. Without MCP, agents are isolated.
  • Observability: Long-running loops need structured logging and tracing. Without it, debugging a broken loop is guesswork.

Where Loop Engineering Fits in the Stack

Loop engineering is not replacing developers. It is changing where leverage lives. In the manual prompting era, leverage came from phrasing skill. In the loop engineering era, leverage comes from system architecture: trigger quality, goal precision, action safety, verification reliability, and memory depth.

For platform engineers, this means building infrastructure for safe agent execution: worktree isolation, action hooks, permission systems, and cost controls. For DevOps teams, it means integrating agent loops into CI/CD pipelines and treating agent runs as first-class jobs with logging, retries, and rollback procedures. For individual developers, it means a shift from typing prompts to designing systems—writing rules that govern agent behavior rather than micromanaging each step.

The developers thriving in the agentic era won’t be the ones who write the best single prompts. They’ll be the ones who design the loops that run while they sleep.

Failure Modes and Edge Cases

Loops fail in predictable ways. Understanding these failure modes is part of the discipline:

  • Infinite loops: A goal that is unachievable given the action set, or verification that is too permissive. The agent keeps trying and failing. Budget controls and iteration limits are the standard defense.
  • Overfitting to verification: The agent makes verification pass without solving the real problem. Classic example: deleting test assertions rather than fixing code.
  • Action overreach: The agent has access to too many tools and uses them in unanticipated ways—modifying wrong files, calling wrong APIs, deploying to wrong environments. Action hooks and allowlists are the defense.
  • Memory corruption: The agent remembers the wrong thing, or memory becomes inconsistent across parallel loops. Versioned memory stores help, but this remains an active research area.

These are not reasons to avoid loops. They are reasons to engineer them carefully. Every production system has failure modes. The question is whether you designed for them.

In a nutshell

Loop engineering represents a genuine paradigm shift. The unit of work has moved from the single prompt to the autonomous run. The skill that matters has moved from phrasing to architecture. The leverage has moved from the individual developer typing into a chat window to the system designer who builds something that works without supervision.

The term is new, but the idea is not. Developers have always automated themselves out of repetitive work. Loop engineering is simply the latest form: automating the automation itself. The developers who master it will spend less time typing prompts and more time designing the systems that make those prompts obsolete.

Sources