--- slug: steering-loop type: pattern summary: "The closed cycle where an agent acts, receives feedback, and adjusts, turning raw model output into reliable results through iteration." created: 2026-04-04 updated: 2026-04-27 related: agent-sprawl: relation: related note: "A well-structured steering loop concentrates work in a focused agent rather than spawning new ones." agentops: relation: fed-by note: "The signals AgentOps captures are what the outer steering loop acts on between runs." approval-fatigue: relation: related note: "Batching reviews into steering loops reduces prompt count." architecture-fitness-function: relation: fed-by note: "Fitness function failures feed into the steering loop, driving agents to self-correct architectural violations." best-current-practice: relation: informs note: "Steering loops are the feedback mechanism that detects when a practice has drifted from current standards." bounded-autonomy: relation: constrained-by note: "The steering loop executes within whatever autonomy tier is active for the task at hand." compaction: relation: uses note: "Compaction reclaims context space when the loop runs many iterations." context-engineering: relation: uses note: "Each iteration must fit feedback into the remaining context budget." dark-factory: relation: related note: "The steering loop still operates in a Dark Factory, but the steering inputs come from specifications and aggregate metrics rather than per-action human review." feedback-loop: relation: refines note: "A feedback loop at the governance level: observe agent behavior, decide whether to continue or intervene." feedback-sensor: relation: depends-on note: "Sensors provide the signals that drive each correction cycle." feedforward: relation: depends-on note: "Feedforward controls shape the agent's first attempt and reduce the number of loop iterations needed." garbage-collection: relation: specialized-by note: "" harness-agentic: relation: depends-on note: "The harness orchestrates the loop and enforces stopping conditions." harnessability: relation: supported-by note: "A harnessable codebase supports tighter, faster steering loops." human-in-the-loop: relation: enables note: "The loop's escalation path is what brings a human in at the right moment." metric: relation: related note: "Metrics provide the data that steering loops act on." permission-classifier: relation: related note: "The classifier is one of the loop's gates between turns, deciding which actions need a human in the loop right now." plan-mode: relation: related note: "Planning before acting is feedforward that reduces the iterations a steering loop needs." runtime-governance: relation: complements note: "The steering loop adjusts the agent's behavior over time; runtime governance bounds what the loop can do at any single moment." service-level-objective: relation: related note: "SLO burn rate is one of the clearest signals a steering loop can act on, whether the loop's actuator is a human or an agent." shift-left-feedback: relation: enabled-by note: "Shifting feedback earlier tightens each steering iteration." verification-loop: relation: refines note: "The verification loop describes the change-test-inspect cycle; the steering loop is the complete closed-loop system that includes feedforward, feedback, and escalation." --- # Steering Loop > **Pattern** > > A named solution to a recurring problem. *A steering loop is the closed cycle where an agent acts, receives feedback, and adjusts, turning raw model output into reliable results through iteration.* > "All models are wrong, but some are useful." > — George Box *Also known as: Agent Loop, Control Loop, Iterate-Until-Done* ## Understand This First - [Feedforward](feedforward.md) -- feedforward controls shape the agent's first attempt and reduce the number of loop iterations needed. - [Feedback Sensor](feedback-sensor.md) -- sensors provide the signals that drive each correction cycle. - [Harness (Agentic)](harness-agentic.md) -- the harness orchestrates the loop and enforces stopping conditions. ## Context At the **agentic** level, the steering loop is the structural core of every [harness](harness-agentic.md). It connects [feedforward](feedforward.md) controls with [feedback sensors](feedback-sensor.md) into a single closed system. Without the loop, feedforward and feedback are isolated mechanisms. With it, they form a control system that converges on correct output. The idea comes from control theory. A closed-loop controller measures output, compares it to a desired state, and adjusts input until the error shrinks below a threshold. In agentic coding, the "desired state" is working code that satisfies a task. The loop runs until the agent gets there or hits a stopping condition. ## Problem How do you turn an agent's probabilistic output into reliably correct results when no single generation is guaranteed to be right? A [model](model.md) generates plausible code, not provably correct code. Feedforward controls improve the odds of a good first attempt. Feedback sensors detect mistakes afterward. But neither mechanism alone closes the gap. You need a process that takes sensor output, feeds it back into the agent's context, and triggers another attempt. Without that connection, every detected error requires human intervention. ## Forces - **Models improve with iteration.** An agent that sees a test failure and tries again will often fix the problem. The loop exploits this natural capability. - **Unbounded loops are dangerous.** An agent stuck in a retry cycle wastes tokens, time, and context window space. It can also make things worse with each attempt. - **Different errors need different responses.** A type error requires a targeted code fix. A fundamental misunderstanding of the task requires re-reading the spec. The loop must route signals to the right kind of correction. - **Humans need visibility.** If the loop runs silently for 30 iterations, the human has no way to intervene when the agent goes off course. ## Solution **Connect feedforward and feedback into a closed cycle with explicit stopping conditions.** The steering loop has four phases that repeat until the task is done or a limit is reached. **Act.** The agent generates or modifies code based on the current task and any correction signals from the previous iteration. On the first pass, feedforward controls (instruction files, specs, linter configs) shape the output. On later passes, the agent also has feedback from its previous attempt. **Sense.** The harness runs feedback sensors against the output. Computational sensors (type checkers, linters, test suites) run first because they're fast and deterministic. Inferential sensors (LLM-as-judge, semantic diff) run at checkpoints where slower evaluation is worth the cost. **Decide.** The harness or the agent evaluates the sensor results. If all checks pass, the task may be complete. If checks fail, the loop classifies the failure: is it a localized code error the agent can fix, or a deeper misunderstanding that needs human input? That classification determines whether the loop continues, escalates, or stops. **Adjust.** The agent incorporates the feedback and returns to Act. Good harnesses format sensor output so the agent can act on it directly: a test failure with the assertion, expected value, and actual value. Noise gets stripped. The agent doesn't need a full stack trace for a missing return statement. The loop needs boundaries. Set a maximum iteration count (five to ten attempts for most tasks). Track whether each iteration makes progress. If the same test fails three times with different attempted fixes, the agent is thrashing and should stop. Surface the iteration count and sensor results to the human so they can intervene at the right moment, not after the context window is exhausted. Some harnesses add a completion gate: a validation check that runs when the agent signals it's done, confirming that the output actually satisfies the task before the loop exits. If the gate fails, the validation output enters the conversation history and the agent gets another pass. This prevents premature exit when the agent declares victory on code that doesn't work. Fowler describes three nested loops in agentic practice. The **inner loop** is the steering loop itself: the agent acts and self-corrects. The **middle loop** is human review: the developer inspects the agent's result and provides direction. The **outer loop** is harness improvement: the developer changes feedforward controls, sensor configuration, or tool access to make future inner loops more effective. Good practice moves human attention outward over time, from fixing individual outputs to improving the system that produces them. Annie Vella's 158-engineer longitudinal study (March 2026) gave the middle loop its empirical grounding and named the work that happens there *supervisory engineering*: directing, evaluating, and correcting agent output. > **💡 Tip** > > When the steering loop consistently takes more than three iterations on a particular type of task, treat it as a signal. Either the feedforward controls are missing something the agent needs, or the feedback sensors aren't catching the real issue early enough. Fix the harness, not just the output. ## How It Plays Out A developer asks an agent to add pagination to a REST endpoint. The agent reads the specification (feedforward), writes the implementation, and the harness runs the test suite (feedback). Two tests fail: the response doesn't include a `next_page` token when more results exist. The agent reads the failure messages, adds the token logic, and the harness reruns tests. All pass. Two iterations, and the developer only reviewed the final result. A team's harness runs a three-sensor stack: TypeScript compiler, ESLint, and a focused test subset. The steering loop has a five-iteration cap and a progress check: if the same sensor fails with the same error class on consecutive attempts, the loop stops and surfaces the problem to the developer. On a complex refactoring task, the agent fixes type errors across four files in three iterations. On the fourth attempt, it introduces a circular dependency that the linter catches but can't resolve without architectural guidance. The loop stops. The developer points the agent at the right module boundary, and it completes the task on the next pass. One human intervention, at the point where human judgment was actually needed. > **💡 Example Prompt** > > "Add pagination to the /users endpoint. After each change, run the type checker and the tests in tests/test_users.py. If anything fails, read the error and fix it before moving on. Stop and ask me if the same error recurs three times." ## Consequences The steering loop makes agents self-correcting within the bounds of what sensors can detect. It reduces the volume of broken output that reaches human review, letting developers focus on design and intent rather than debugging syntax errors. It also makes the value of good harness infrastructure concrete: better controls mean fewer iterations, faster task completion, and lower token costs. The cost is design effort. A naive retry loop wastes resources or makes problems worse. You need thoughtful stopping conditions, progress detection, and escalation paths. The loop is also bounded by sensor quality: if your tests don't cover the behavior the agent is changing, the loop will declare success on broken code. The context window sets another ceiling. Each iteration adds to the conversation history, so a loop that runs too many times can exhaust the window before the task is resolved. [Compaction](compaction.md) helps, but prevention through better feedforward and better sensors helps more. ## Sources - The steering loop draws on closed-loop feedback control, a concept formalized in control theory through the work of Harold S. Black, Norbert Wiener, and others in the mid-20th century. The act-sense-decide-adjust cycle is a direct adaptation of the standard feedback controller architecture. - Kief Morris developed the inner/middle/outer loop model for agentic software engineering in ["Humans and Agents in Software Engineering Loops"](https://martinfowler.com/articles/exploring-gen-ai/humans-and-agents.html) (ThoughtWorks, March 2026), providing the framework for how human attention migrates outward as harness quality improves. The same article introduced the *in the loop / on the loop / out of the loop* vocabulary used in the [Human in the Loop](human-in-the-loop.md) entry. - Birgitta Boeckeler's guides-and-sensors framework from ["Harness engineering for coding agent users"](https://martinfowler.com/articles/harness-engineering.html) supplies the feedforward/feedback vocabulary that the steering loop unifies into a single closed system. - Annie Vella's ["The Middle Loop"](https://annievella.com/posts/the-middle-loop/) (March 2026) is a longitudinal mixed-methods study (158 engineers in round one, 101 in round two, 95 matched, 28 countries) that names *supervisory engineering* as the work happening in the middle loop and decomposes it into directing, evaluating, and correcting. ## Further Reading - [Matt Greenwood, "Open vs Closed-loop agentic coding"](https://mattgreenwood1.substack.com/p/open-vs-closed-loop-agentic-coding) — a practical comparison of open-loop (generate and hope) vs. closed-loop (steering loop) agent workflows. - [Simon Willison, "Designing agentic loops"](https://simonwillison.net/2025/Sep/30/designing-agentic-loops/) — practical advice on loop structure, stopping conditions, and avoiding runaway agents. --- - [Next: Harnessability](harnessability.md) - [Previous: Feedback Sensor](feedback-sensor.md)