How do you move from individual prompting to automated workflows?
A loop is not a bigger prompt. It's a control structure with a termination condition. Understanding that distinction determines whether your automation scales or compounds your coordination problems.
In June 2025, a post from Pieter Levels on X describing his workflow accumulated 6.5 million views. Boris Cherny's Acquired keynote on loop engineering followed. Addy Osmani defined five building blocks. Matt Pocock described the Ralph approach. For a few weeks, everyone was talking about loops.
Most of that discourse was about individual developer practice. How does one engineer set up a loop that runs while they sleep? That's a useful thing to understand. But as a leader, the more important question is: what happens when 30 engineers each run 2–3 loops simultaneously? What's your fleet management story?
That's the organizational dimension of loop engineering that most of the June 2025 discourse didn't address, and where most teams that try to scale loops run into problems.
The abstraction ladder
From autocomplete to orchestration loops
Autocomplete
AI completes the line you're typing. No agent, no loop. You're still writing code; AI is your fast-forward button.
Prompted sessions
You describe a task in natural language; the agent writes the implementation. You review and commit. Still synchronous, still single-session.
Parallel sessions
You run multiple agent sessions simultaneously on separate tasks. Your role shifts to context-setting and review orchestration across sessions.
Loops
An automated cycle: trigger → agent work → verification → iterate or complete. Runs without your active involvement. You define the termination condition; the loop runs to it.
Orchestration loops
Multiple coordinated loops with shared context, governance policy, and observable state. Loops are aware of each other and don't conflict. Fleet management applies.
Definition
What a loop actually is
A loop is a control structure with four components: a trigger that starts execution, agent work that produces output, a verification gate that determines success or failure, and a termination condition that defines when done means done.
The termination condition is the most important part. Without one, you don't have a loop. You have an agent session that runs until something breaks, or until someone manually stops it. The Deep Feed 47-run experiment on autonomous agent completion found that agents without explicit stop conditions reliably overshoot, adding unrelated features or making unnecessary changes while "finishing" a task.
Matt Pocock's Ralph pattern is the simplest useful loop: a bash while-loop that runs an agent, runs tests, commits if tests pass, and exits when the acceptance condition is met. No framework required. But the termination condition must be externally defined, not by the agent.
#!/bin/bash
# Simplest useful loop: run → verify → commit or retry
# Termination: test suite green + acceptance check passes
MAX_ITERATIONS=5
ITERATION=0
while [ $ITERATION -lt $MAX_ITERATIONS ]; do
echo "Iteration $((ITERATION + 1))/$MAX_ITERATIONS"
# 1. Agent run (replace with your actual agent invocation)
agent run --task "$TASK" --context ./specs/current.md --output ./src
# 2. Verification gate (termination condition)
if npm test && npm run typecheck && npm run check:acceptance; then
git add -A
git commit -m "feat: $TASK [agent-loop, iter-$((ITERATION + 1))]"
echo "Done. Tests green."
exit 0
fi
echo "Tests failed, iterating..."
ITERATION=$((ITERATION + 1))
done
echo "Max iterations reached. Human review required."
exit 1 # Escalate: loop didn't convergeThe building blocks
Five components of a production loop
Addy Osmani's five building blocks are the right frame for what a production loop requires, beyond the simplest bash script.
01
Automations
The trigger mechanism. What starts the loop? Scheduled cron, git webhook, CI event, Jira ticket status change, monitoring alert. The trigger determines who has visibility into the loop and when.
02
Worktrees / isolation
Loops must run in isolated environments. Git worktrees or separate branches per loop prevent loops from interfering with each other or with human-authored work. At team scale, this is the first thing that breaks if you don't design for it.
03
Skills / context
The organizational knowledge the agent has access to: specs, coding conventions, architectural decisions, adjacent service contracts. This is your context layer from Module 01. Without it, loops produce the same context-fragmentation problems as manual sessions.
04
Connectors
Integration with your toolchain: GitHub for PRs, Jira/Linear for tickets, Slack for notifications, your CI system for gates. Loops that can't report status or route escalations properly become black boxes, which breaks governance.
05
Sub-agents + state
Complex loops coordinate multiple agents with shared state. The state management is the hard part: how do sub-agents share progress? How does one sub-agent's output become another's input? This is where orchestration infrastructure matters.
The org-scale problem
Where loops break when teams adopt them
Individual loop practice is well-documented. The org-scale problems are less discussed. Here's what breaks when you move from one engineer's loop to a team's loops.
Environment conflicts
Developer A's triage loop and Developer B's refactor loop both modify the same service. Without isolated environments and conflict detection, they step on each other. At 20 engineers running 2 loops each, this happens constantly. The fix: every loop gets a dedicated worktree/branch, and conflict detection runs before loops start, not at merge time.
Review queue multiplication
Every loop produces PRs. Ten engineers running 3 loops each means 30 concurrent agent workflows, each potentially producing multiple PRs per cycle. Without risk-based routing and Tier 1 auto-merge, the review queue explodes. This is where Module 03's decision tier framework connects directly to loop engineering.
Context staleness
Loops that run for hours or days start with current context and drift. The codebase changes while the loop is running. Without a mechanism to refresh context mid-loop, agents make decisions based on stale architectural state. Long-running loops need context refresh checkpoints.
Cost without observability
Loop cost scales with iteration count, not task count. A loop that iterates 20 times to converge costs 20x a single-pass task. Without per-loop cost tracking and iteration budgets, token spend becomes unpredictable. This is what happened at Uber: not loop count, but unbounded iteration.
CO-BUILD PROGRAM
From playbook to production
We work directly with engineering leaders who are making this transition now. You bring the real constraints; we help you build the coordination layer around them.