Loop Engineering: From Prompts to Durable Agent Loops

GitOps Secrets Management for Production Kubernetes

Production patterns for managing secrets in GitOps workflows: Sealed Secrets, External Secrets Operator, SOPS, and HashiCorp Vault integration with ArgoCD.

The End of Prompting

Peter Steinberger (PSPDFKit) put it bluntly: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." Boris Cherny, who leads Claude Code at Anthropic, operates the same way: "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."

This is loop engineering — replacing yourself as the person who prompts the agent with a small system that finds the work, hands it out, checks it, writes down what is done, and decides the next thing. You define a purpose; the AI iterates until it is complete. The leverage point has moved: from crafting individual prompts to designing the control systems that orchestrate agents over time.

The surprising part is that this is no longer a tooling exercise. A year ago a loop meant a pile of custom bash you maintained forever. Today the building blocks ship inside the products — Codex and Claude Code both have them, in nearly the same shape. Once you notice the shape is the same, you stop arguing about which tool and just design a loop that works no matter which one you happen to be in.

The Anatomy of a Loop

A loop needs five building blocks and one place to remember things. Each one has a job:

Automations: The Heartbeat

Automations are what make a loop an actual loop and not a one-off run. A scheduled task, a CI job that keeps running after you close the laptop, a hook that fires at a point in the agent lifecycle — any of them qualifies.

In the Codex app, you create an automation in the Automations tab: pick the project, the prompt it runs, how often, and whether it runs on your local checkout or a background worktree. Runs that find something land in a Triage inbox; runs that find nothing archive themselves. OpenAI uses these internally for daily issue triage, summarizing CI failures, writing commit briefings, and hunting bugs introduced last week.

Claude Code gets to the same place through scheduling and hooks:

• /loop 5m /babysit — re-run a prompt on an interval
• /loop 30m /slack-feedback — poll a channel and react
• /loop 1h /pr-pruner — clean up stale PRs
• cron tasks and lifecycle hooks for shell commands at agent events
• GitHub Actions, if the loop must survive your laptop being closed

Cherny's own running loops read like a chore list: /loop 5m /babysit, /loop 30m /slack-feedback, /loop /post-merge-sweeper, /loop 1h /pr-pruner. His canonical babysit loop, in longhand: "babysit all my PRs. Auto-fix build issues, and when comments come in, use a worktree agent to fix them."

Worktrees: Parallel Safety

The second you run more than one agent, files start colliding. Two agents writing the same file is the exact same headache as two engineers committing to the same lines without talking first.

A Git worktree fixes it: a separate working directory on its own branch, sharing the same repository history. One agent's edits literally cannot touch another's checkout.

• Codex builds worktree support in — several threads hit the same repo without bumping into each other
• Claude Code gives the same isolation via git worktree, a --worktree flag to open a session in its own checkout, and isolation: worktree on a subagent so each helper gets a fresh checkout that cleans itself up

The mechanical collision goes away, but you are still the ceiling: your review bandwidth decides how many parallel agents you can actually run, not the tool.

Skills: Codified 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 inside holding instructions and metadata, plus optional scripts, references, and assets.

Two properties make skills work in loops:

• Lazy loading: a skill loads only when used, so it costs almost nothing in context until it is needed
• Trigger matching: Codex runs a skill via $name or /skills, or by itself when a task matches the skill description — which is why a tight, boring description beats a clever one

Cherny checks slash commands into .claude/commands/ for every inner-loop workflow he runs many times a day, so both his team and Claude can reuse them.

Connectors: Reaching Real Tools

A loop that can only see the filesystem is a tiny loop. Connectors, built on MCP (Model Context Protocol), let the agent read your issue tracker, query a database, hit a staging API, or drop a message in Slack.

Both Codex and Claude Code speak MCP, so a connector you write for one usually works in the other. Plugins bundle connectors and skills together, so a teammate installs your whole setup in one go instead of rebuilding it from memory.

Sub-Agents: The Maker/Checker Split

The usual split in both tools: one agent explores, one implements, one verifies against the spec. Codex defines agents as TOML files in .codex/agents/; Claude Code uses .claude/agents/ and agent teams that pass work between them.

Verification is the single highest-leverage addition to any loop. Cherny: "Give Claude a way to verify its work. If Claude has that feedback loop, it will 2-3x the quality of the final result." The loop runs while you are not watching, so a verifier you actually trust is the only reason you can walk away.

The same principle applies to the stop condition: /goal keeps going until a condition you wrote is actually true — after each turn a fresh, small model checks whether the condition holds. That is the maker/checker split applied to "done" itself: the agent that did the work no longer decides when the work is complete.

Cost note: sub-agents burn more tokens — each one does its own model and tool work. Spend them where a second opinion is worth paying for.

The Sixth Element: State

A markdown file, a Linear board, anything that lives outside the single conversation and holds what is done and what is next. It sounds too dumb to matter — and it is the same trick every long-running agent depends on. The model forgets everything between runs, so the memory has to be on disk, not in context. The agent forgets; the repo doesn't.

In a loop, the state file is the spine: it remembers what got tried, what passed, and what is still open, so tomorrow morning's run picks up where today stopped.

Cherny's rule for long-running work: "Every single time Claude makes a mistake, I don't tell it to do it differently. I tell it to write it to the CLAUDE.md, or make a skill, or something. If you can do this, then Claude can just run forever." Note the distinction: CLAUDE.md is context, not enforcement — to hard-block an action you need a PreToolUse hook.

The Platform as the Loop's Runtime

This is where loop engineering meets classic DevOps. The platform — GitOps in particular — becomes the loop's runtime:

• GitOps is the memory layer. ArgoCD and Flux watch repositories and reconcile clusters automatically. The loop does not need to invent state management; it inherits it from the platform.
• Infrastructure is a better oracle than application code. A plan diff is deterministic and machine-readable. A policy check returns a hard verdict. Drift and cost are numbers you can threshold.
• Outer and inner loops. The outer loop watches for new releases, compliance changes, and security patches. It delegates to inner loops that roll updates across clusters in stages. Each inner loop reports back: drift detected, policy passed, tests green. The outer loop decides whether to proceed to the next stage or halt and alert a human.

Teams at scale already run variations of this today. This is the difference between an agent that says "here is the fix" and a loop that ships the fix, verifies it, and communicates the result.

Budgets, Guardrails, and Escape Hatches

Osmani is explicit about the risk: token usage patterns can vary wildly depending on whether you are token-rich or token-poor, and loops run while you sleep. Set the guardrails before the loop's first run:

• Iteration cap — a maximum number of loop turns per run
• Token/dollar ceiling — the loop aborts when it hits it
• Condition-based halt — e.g., stop on two consecutive identical failures
• Human gates — review the output, not every step; keep the same quality bar for AI-written code as for human-written code
• Triage inbox — anything the loop cannot handle lands there, so you are the escalation path, not the scheduler

A Production Loop: Daily Triage

This is the same loop in Codex, Claude Code, or opencode, because the pieces are the same pieces. A morning automation calls a triage skill that reads yesterday's CI failures, the open issues, and recent commits, and writes findings into a markdown file. For each finding worth doing, a thread opens an isolated worktree and sends a subagent to draft the fix; a second subagent reviews the draft against the project skills and existing tests. Connectors open the PR and update the ticket. Anything unhandled lands in the triage inbox. The state file remembers everything, so the next run resumes.

You designed this once. You do not prompt any of those steps.

War Story: 259 PRs in 30 Days

Cherny reports landing 259 PRs in 30 days — every line written by Claude Code — after uninstalling his IDE in late November 2025. The number is directional: his dramatic scale claims (hundreds of agents, his share of GitHub commits) are worth treating with skepticism, and the often-cited "~4% of public GitHub commits" figure is a third-party SemiAnalysis estimate with no published methodology. But the implementable core is real and available today: /goal, /loop, /schedule, worktrees, agent view, hooks, skills, and CLAUDE.md, wrapped in loops you write and verify.

The practical pattern that survives contact with reality: a small morning loop that summarizes CI failures and drafts fixes saves the day's first hour. The PR review still happens by a human — just over coffee instead of before it.

Caveats

• It is early. Osmani, who popularized the term, is still explicitly skeptical. Loops compound both good and bad behaviors; a bad prompt in a loop fails forever, not once.
• Costs are real. Loops multiply token spend. Budget ceilings are not optional.
• Trust before autonomy. A verifier you trust is the prerequisite for walking away. Without one, a loop is just unsupervised code generation.
• Design the loop, not the vendor. The building blocks converge across tools; loops designed against one vendor's UI become obsolete when the product changes.
• Write things down. The state file and CLAUDE.md are what make the loop durable — the model forgets; the repo doesn't.

Further Reading

• DevOps in the Age of AI — how AI reshapes the delivery pipeline
• From Manual to Automated Operations — the automation progression loops build on
• Agent Observability with OpenTelemetry — observing the loops once they run unattended
• Kubernetes GitOps with ArgoCD — the memory layer loops inherit
• CI/CD Pipeline Optimization — the pipeline loops plug into