Introducing Loop Engineering

Exploring the emerging Human-Agents partnership

6 min readJul 5, 2026

In early June 2026, three voices from different corners of the AI-coding world converged on the same idea within days of each other, and the phrase that stuck was “loop engineering.” Peter Steinberger, creator of OpenClaw, posted that people shouldn’t be prompting coding agents anymore — they should be designing loops that prompt their agents. Boris Cherny, who heads Claude Code at Anthropic, made the same point from the inside, saying he no longer prompts Claude directly: he has loops running that prompt Claude and figure out what to do, and writing loops is now his job. Addy Osmani then gave the practice a name and an anatomy — automations, worktrees, skills, connectors, sub-agents, and external state.

Loop engineering is an emerging discipline for designing AI-agent workflows that can start from a trigger, pursue a verifiable goal, use tools and memory, evaluate progress, and iterate until a stopping condition is met.

Note that, in principle, loop engineering isn’t inherently a coding concept. At its core it’s a way of thinking about any recurring goal-directed process — a system that finds work, acts on it, checks the result, remembers what happened, and decides what to do next, without a human re-initiating every cycle by hand. That pattern shows up wherever there’s repeated judgment to apply: operations, research triage, customer support, content pipelines, even personal workflows.

But the domain where it has actually been built out, named, and given working primitives right now is software engineering with AI coding agents — so that’s where this article focuses.

From Prompt design to System design

If we travel back to the early days of AI adoption, one of the first new disciplines that emerged was that of Prompt Engineering — the art and science of writing a well-defined prompt to let the AI achieve the goal. We then soon realized that LLMs needed more than a prompt — they needed to know more about us, our habits, our preferences, our job and the knowledge we wanted them to be grounded on. In other words, they needed context — and that’s when we started talking of Context Engineering.

With Loop Engineering, the idea is different. Instead of asking yourself “what should I ask?” (prompt engineering) or “what should the model know?” (context engineering), the main question is “How sohuld work progress autonomously?”.

So ultimately, what you will be building is an execution cycle or, in other words, a small system that:

Finds the work (discovery/triage)
Acts on it (an agent does the task)
Checks the result (a separate verifier judges it)
Remembers what happened (state persists outside the conversation)
Decides the next step, and repeats

Prompt engineering optimizes a single instruction. Loop engineering optimizes the system that decides what to prompt, when, and whether the result was actually good enough to stop.

What’s inside a Loop?

According to Osmani’s article, aloop needs five building blocks plus a sixth thing that ties them together: memory.

1. Automations . These are triggers that go off on a schedule and handle discovery and triage on their own, rather than waiting for a human to start the cycle. This is what turns a single agent run into an actual loop instead of a one-off task.

2. Worktrees — parallel isolation. Worktrees let multiple agents work in parallel without stepping on each other’s files, the same way two engineers working on separate branches avoid colliding on the same lines.

3. Skills — codified project knowledge. A skill is how you stop re-explaining the same project context every session; both major tools use the same format, a folder with a SKILL.md file holding instructions and metadata. Without this, a loop re-derives your entire project from scratch on every cycle; with it, understanding compounds instead of resetting.

Get Valentina Alto’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

4. Plugins and connectors — reach into real tools. Connectors, built on MCP, let the agent read an issue tracker, query a database, hit a staging API, or post to Slack — this is the difference between an agent that says “here is the fix” and a loop that actually opens the PR, links the ticket, and pings the channel once CI is green.

5. Sub-agents — separate the maker from the checker. The most useful structural choice in a loop is splitting the agent that writes the work from the agent that checks it, because the model that wrote the code is in no position to objectively grade its own homework. A second agent, sometimes running a different model, catches what the first one talked itself into believing was fine.

6. State — the memory that survives the agent forgetting. This is a markdown file, a project board, or any store that lives outside a single conversation and holds what’s done and what’s next — because the model forgets everything between runs, but the repo doesn’t.

Example: Building a Loop to address new Issues

Imagine an Airline company with the ambition of modernizing their website through a conversational trip planner agent. A new issue pops-up:

Issue #2194 - Conversational Trip Planner Agent:

add a conversational trip planner to the website so a passenger can describe a trip in plain language (“Rome, mid-May, two adults, economy, under €600”) and get back a few ranked itinerary options with reasons. That planner is the product the customer will eventually talk to.

Let’s see how a proper Loop can address this issue.

Trigger →a scheduled dispatch workflow that auto-detects new issues assigned to you and kicks off the loop, then wire it into the instructions. This will live under the .github/workflows/loop-dispatch.yml.
Normalize the intent → Custom instructions + a Skill + Issue template.
.github/copilot-instructions.md is the standing protocol Copilot loads on every task; the deliver-feature skill (.github/skills/deliver-feature/SKILL.md) is the reusable "restate goals/constraints/assumptions" playbook, auto-invoked on feature issues. The feature-loop.yml issue template guarantees the input is already structured.
Plan behind a human gate → Plan mode (/plan) + its approval step.
Copilot's plan mode produces the plan and blocks until a human approves before writing code. This is a first-class CLI/agent capability, not something you hand-roll.
Build in bounded slices → Autopilot (--autopilot, bounded by --max-autopilot-continues N); optionally Fleet (/fleet).
Autopilot is what lets Copilot execute multiple steps autonomously after approval; the continuation cap keeps it from runaway looping. /fleet decomposes genuinely independent slices into parallel subagents.
Verify continuously → GitHub Actions workflow + the Skill’s test mandate.
loop-verify.yml is the CI gate (lint/unit/integration/contract). The skill instructs Copilot to run checks after each slice locally, so failures surface before CI.
Auto-recover → The GitHub Copilot coding agent + MCP (GitHub server).
On github.com, the coding agent reacts to CI failures and PR review comments as new inputs and pushes follow-up commits. The built-in GitHub MCP server is how it reads CI logs, PR threads, and issue comments to drive that recovery.
Persist loop memory → The issue/PR thread as state, reached via MCP.
There’s no separate database — the issue and PR are the memory. Custom instructions tell Copilot to write status/assumptions back there, and the GitHub MCP server gives it read/write access so context survives across steps.
Enforce the done-condition → CI check + Hooks + branch protection.
The done-condition job in loop-verify.yml fails while any acceptance checkbox is unticked. .github/hooks/pre-pr.json blocks unsafe shortcuts (no push to main, no --no-verify, warn on PRs lacking tests). Branch protection makes green CI a merge prerequisite.

You can find all the primitives of this loop here: Valentina-Alto/loop-engineering

Conclusion

Loop engineering is still an emerging discipline, but it is already reshaping how modern software is built and maintained. Its impact goes beyond productivity gains, introducing a new way of structuring work between humans and AI systems. Over time, this will likely evolve into a broader mental model — not just for code, but for designing effective collaboration between humans and autonomous agents.