Loop engineering

For the first few years of coding agents, the human was the loop. You prompted, read what came back, noticed the test that still failed, prompted again, and kept doing that until it was done. The agent did the typing. You did the steering, every few minutes, all day.

Loop engineering is the name that spread through 2026 for moving yourself out of that position: designing the system that prompts the agent, checks its work, and steers it, so that it can run many cycles without you. IBM's definition is a good one: the practice of designing agentic workflows, or loops, that iteratively guide AI agents toward user defined goals with minimal human intervention. Prompt engineering is writing one good instruction. Context engineering is deciding what the model sees on each call. Loop engineering is the layer above both: the cycle itself.

Anatomy of a loop#

Every loop has the same four beats, whether it is a coding agent fixing a test or a research agent writing a report.

Goal. Not "improve the checkout page" but "make test_checkout.py pass without changing the tests". A loop needs a stop condition a program can check, or it never knows it is finished.

Act. One attempt by the agent: an inner loop of tool calls, as in What an agent is.

Observe. Something other than the agent's own opinion judges the attempt: tests, a type checker, a linter, a schema validator, or a second model with its own instructions and rubric.

Adjust. What failed is written somewhere the next attempt will read, so it does not make the same mistake twice.

The five decisions#

1. The stop condition. Prefer checks that cannot be argued with: tests pass, the build is green, the JSON validates, the numbers reconcile. A rubric graded by a model is weaker but still far better than the agent deciding for itself.

2. The checker. A maker and checker split, where a separate verifier with its own instructions judges the work, catches more than asking the same agent "are you sure?". The agent that wrote the bug tends to believe its own explanation of why it is fine.

3. The spine. A persistent record of the task: the plan, what was tried, what failed and why. A markdown file in the repository is enough. It survives context compaction and restarts, and it keeps attempt five from repeating attempt two. This is the write it down outside move, made central.

4. Budgets. A maximum number of attempts, tokens, money and wall clock time, enforced by the loop code, not requested of the model.

5. Escalation. When the budget runs out or the checker keeps rejecting, the loop stops and hands a clean summary to a person: what was tried, the current state, the failing check. A loop that fails loudly is fine. One that fails silently is the real risk.

Tune it#

Here is the arithmetic of a loop. One attempt succeeds some of the time. The checker catches some of the failures, and each caught failure gets another attempt, up to a limit.

Two lessons fall out of it. First, retries are only as good as the checker: with a weak check, failures ship as successes and extra attempts change almost nothing. Second, retries are cheap when they are rare: each extra attempt only runs on the failures that were caught, so allowing three attempts usually costs much less than three times as much.

That is the answer to the question at the top. If you can build a strong automatic check, invest in the loop first, because it multiplies whatever reliability the agent already has. If you cannot check the work automatically, retries cannot help you, and a more reliable single attempt plus a human review is the better investment.

The loop in code#

Strip away the framework and a task loop is short. The agent call can be any of the approaches in the frameworks chapter.

import subprocess
from pathlib import Path
 
SPINE = Path("PROGRESS.md")
MAX_ATTEMPTS = 4
 
def check() -> tuple[bool, str]:
    # The stop condition: the test suite, not the agent's opinion.
    run = subprocess.run(["pytest", "-x", "-q"], capture_output=True, text=True)
    return run.returncode == 0, run.stdout[-3000:]
 
def task_loop(goal: str) -> bool:
    SPINE.write_text(f"# Goal\n{goal}\n\n# Attempts\n")
    for attempt in range(1, MAX_ATTEMPTS + 1):
        run_agent(  # your agent: a tool loop that can read and edit the repo
            f"{goal}\n\nRead PROGRESS.md first. Do not repeat failed approaches."
        )
        ok, report = check()
        if ok:
            return True
        with SPINE.open("a") as f:
            f.write(f"\n## Attempt {attempt} failed\n```\n{report}\n```\n")
    escalate(SPINE.read_text())  # budget spent: hand the record to a person
    return False

Outer loops#

The same idea scales up a level. Instead of you starting each task, something else does:

• A schedule. A cron job or CI workflow runs the loop nightly over open issues, failing flaky tests, or dependency updates. Coding tools now ship this directly; Claude Code, for example, has a /loop command that reruns a prompt on an interval.
• An event. A new issue label, a failed deploy or a customer ticket triggers a loop.
• Many at once. Several loops run in parallel, each in its own git worktree or sandbox so they cannot trample each other's files, each producing a pull request for a person to review.

At the extreme, people run the same prompt against a coding agent over and over in a plain shell while loop, letting the spine file and the test suite carry progress between runs. It works surprisingly often, and it shows how much of the reliability is in the check and the spine rather than in any single clever prompt.

Checkpoint#