Loop Engineering for DevOps: From Prompting to Supervised Agent Loops

The shift: you stop writing prompts, you start writing loops

Boris Cherny, who leads Claude Code at Anthropic, described his own workflow in a line that reframes the whole conversation: "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."

That is not a productivity tip. It is a different unit of work. Prompt engineering optimizes a single request-response. Loop engineering designs a system that gathers context, acts, verifies the result, and course-corrects — repeatedly, often on a schedule, sometimes without a human in the seat for each turn. And of every discipline in software, DevOps and SRE are where loops fit most naturally, because ops work is already recurring, already verifiable, and never truly "done."

This guide is about applying that pattern to infrastructure work — and, just as importantly, the guardrails that stop a loop from turning a 2am cost-cleanup into a 2am outage.

What an agent loop actually is

Strip away the hype and every agent loop is three phases that repeat:

1. Plan / gather context — the agent assesses the current state and decides the next move.
2. Act — it runs a command, edits a file, opens a PR, queries an API.
3. Observe / verify — it reads the result and updates its plan.

Then it loops. The loop ends when a stopping criterion is met (the check passes, a budget is exhausted, or a human approves), not when a prompt "finishes." Boris's own running loops make the shape concrete — recurring jobs scheduled like cron:

/loop 5m  /babysit-prs        # address review comments, rebase, shepherd PRs
/loop 30m /slack-feedback     # turn Slack requests into draft PRs
/loop 1h  /pr-pruner          # close stale, superseded PRs
/loop     /post-merge-sweeper # sweep up review comments missed pre-merge

Notice these never reach an end-of-task. The codebase keeps changing, so the loop is the workflow. That is the mental model to port into ops.

Why ops is the ideal home for loops

App feature work has a finish line; infrastructure rarely does. Config drifts, dependencies age, costs creep, alerts fire. Those are exactly the tasks that reward a persistent supervised loop:

• PR babysitting for infra repos — an agent that watches your Terraform/Helm PRs, runs terraform plan, posts the diff, addresses review nits, and rebases. Pairs naturally with the metrics in DORA Metrics with GitHub Actions — a loop that shortens lead time is a loop you can measure.
• Drift remediation — a loop that runs terraform plan on a schedule and, when it finds drift, opens a PR with the correction (never applies silently).
• FinOps cost sweeps — a loop that queries cost per namespace, finds workloads under 20% efficiency, and drafts right-sizing PRs. Read-only analysis by default; changes go through review.
• Incident first-responder — a loop that, on a page, gathers the evidence (metrics, recent deploys, logs) and posts a triage summary before a human is even online. This is the autonomous incident response idea, expressed as a supervised loop rather than a one-shot agent.
• Dependency & CVE bumps — a loop that watches for advisories and opens tested upgrade PRs.

The common thread: the agent needs tools, not just text. Give it scoped, safe access — e.g. a read-mostly Kubernetes MCP server — so each "Act" step is a real, bounded operation, not a hallucinated command.

The one rule that makes loops trustworthy: maker ≠ checker

The single most important principle in loop engineering is the maker/checker split: the model that performs the work must not be the same context that decides whether the work is correct. An agent asked "did you finish?" will cheerfully say yes. An agent whose output is judged by a separate, deterministic check cannot lie its way past a failing test.

So the "Verify" phase must lean on deterministic signals, not self-assessment:

• terraform plan shows an empty diff → drift resolved.
• The test suite / npm run build / kubectl apply --dry-run=server passes.
• A policy engine (OPA/Kyverno) returns no violations.
• An SLO/error-budget query stays green after the change.

The related idea from multi-agent panels applies here too: independent verification beats a single agent grading its own homework. If your loop's only stopping criterion is the agent's own opinion, you don't have a loop — you have an unbounded generator.

Guardrails: how a loop stays on the right side of "helpful"

This is where most write-ups stop and where ops engineers should start. An autonomous loop with write access to production is a liability unless you bound it deliberately.

1. Bound the iterations. Every loop needs a hard turn/time cap. Runaway loops are the canonical failure mode — an agent that keeps "fixing" and never converges burns tokens and, worse, keeps mutating state.

# a loop with an explicit ceiling and a real success gate
MAX_TURNS=8
for i in $(seq 1 $MAX_TURNS); do
  agent_act || break
  terraform plan -detailed-exitcode && exit 0   # exit 0 = no diff = done
done
echo "loop hit MAX_TURNS without converging — escalate to human" >&2
exit 1

2. Separate read loops from write loops. Analysis, triage, and drafting can run fully autonomous — the blast radius is a PR or a Slack message. Anything that mutates prod (apply, scale, delete, restart) goes behind an approval gate: the loop proposes, a human merges. Default every ops loop to read/propose; promote to auto-apply only for genuinely reversible, low-stakes actions.

3. Make the loop observable. Log every Act step — the command, the diff, the cost. You want to answer "what did the agent do at 03:14?" the same way you'd answer it for a human on-call. Treat the agent's actions as a first-class telemetry stream; instrument it like anything else you'd trace with OpenTelemetry.

4. Budget cost and blast radius explicitly. Token spend scales with turns; a stuck loop is also a billing incident. Cap spend per run, and constrain what the tools can touch (namespaces, accounts, resource types) so a confused loop can't wander outside its lane.

5. Fail loud, escalate to a human. When the stopping criterion isn't met inside the budget, the loop should page a person with its context — not silently give up or, worse, force a "done."

Where loops don't belong (yet)

Loops shine on recurring, verifiable, reversible work. They are the wrong tool for novel architecture decisions, irreversible one-way-door operations (dropping a database, a global config flip) without human sign-off, and anything where you can't write a deterministic check for "correct." If you can't describe the success condition as a command that returns a clean exit code, you're not ready to loop it — you're ready to assist with it, human in the seat.

The takeaway

The industry spent two years perfecting prompts. The next step, as Boris Cherny's workflow signals, is not a better prompt — it's a well-built loop: gather, act, verify against a deterministic check, and iterate under hard guardrails. For DevOps that's a gift, because our work was always loop-shaped: recurring, measurable, and never finished.

Start with one read-only loop — a drift detector that opens PRs, or an incident triager that posts a summary. Give it a real verification signal and a hard iteration cap. Prove it's useful and safe before you ever hand a loop the keys to apply. In production, the difference between an army of helpful agents and an army of expensive incidents is entirely in the guardrails you write around the loop.