Loops and Graphs

Two design decisions sit above the agent loop's mechanics: whether to build a loop at all - a standing process that keeps doing a class of work until a condition holds - and when a loop should become a graph of specialised, checkpointed steps. This chapter gives decision rules for both, grounded in what makes loops trustworthy: the quality of the signal they iterate against.

Design Loops, Not Prompts

A prompt says "do this." A loop says "keep doing this class of work until this condition holds, remember what happened, and stop when judgment is needed." Examples: a nightly job that triages new issues and drafts fixes for the easy ones; an agent that keeps a dependency set updated and opens PRs that pass CI; a migration that processes files until a manifest is empty. The design questions are when it's worth building, what it iterates against, and how it stops.

When a loop pays for itself

A loop has a setup cost F (building tools, checks, state, permissions). It earns it back over N future occurrences if

P × N × (S + R) > F

where P is the probability a run succeeds, S the attention saved per occurrence, and R the risk avoided per occurrence (fewer manual slips). Small N - a one-off task - rarely justifies a loop; just do the task. A frequent task with a low P doesn't either, until the verifier improves P.

The verifier is the bottleneck

A loop is only as good as the signal it iterates against. Each iteration is a chance to fix an error - or to repeat it more confidently. The evidence in this course points one way:

• In the Module 15 lab, self-review without new information fixed one solution and broke two, while feedback from the visible tests fixed one and broke none, at a fraction of the tokens - small differences on problems the model mostly already solved, but in the direction the literature predicts.
• Huang et al. (2023) found that models asked to self-correct reasoning without external feedback often don't improve and sometimes get worse.
• In Lab 13, a harness check that compared the reply with the actual database fixed one class of error and exposed another - a check tells you that something is wrong, which is what a loop needs to continue.

So invest in the check before the loop: tests, type checkers, schema validation, execution results, a comparison with source documents, a state check. When no reliable check exists, keep a human in the loop.

A good loop also improves its environment: it leaves behind a new test, a clearer instruction in AGENTS.md, or an automated check, so the next run is cheaper and safer.

When a Loop Becomes a Graph

Default to one loop: one context, one prompt, fewer moving parts, easier debugging. Split into a graph (explicit nodes with their own prompts, tools, models and checkpoints) only when you can name the reason:

The sharper test: what if it dies halfway?

Ask what happens if the process is interrupted:

• A loop is enough when the task is bounded, restarting costs seconds, and nothing irreversible happens mid-run.
• Use a graph (with checkpoints or durable execution) when state must survive a restart, a human must approve intermediate output, or side effects mean a restart must resume rather than repeat (Durable Execution).

This moves the argument from how complicated the process feels to what its failures cost, which settles it faster.

Failure Modes on Both Sides

flowchart TD
    subgraph LF["🔁 Loop failure modes"]
        LF1["♾️ No termination<br/>no progress detection"]
        LF2["💸 Repeated side effects<br/>duplicate emails, charges"]
        LF3["🪞 Weak verifier<br/>confident repetition of errors"]
    end
    subgraph GF["🕸️ Graph failure modes"]
        GF1["🧩 Over-engineering<br/>nodes for a loop-shaped task"]
        GF2["🔄 Non-idempotent nodes<br/>unsafe to re-run after restart"]
        GF3["🗂️ State schema drift<br/>old checkpoints, new code"]
    end

    style LF1 fill:#e8e0d4,stroke:#c8b89a
    style LF2 fill:#e8e0d4,stroke:#c8b89a
    style LF3 fill:#e8e0d4,stroke:#c8b89a
    style GF1 fill:#ddd8e4,stroke:#b8b0c8
    style GF2 fill:#ddd8e4,stroke:#b8b0c8
    style GF3 fill:#ddd8e4,stroke:#b8b0c8

• Loops need every stop condition from The Agent Loop - iteration and budget caps, timeouts, repeated-call detection - and idempotent side effects.
• Graphs need idempotent nodes (they may run twice after a restart) and versioned state schemas; and each node inside usually runs its own small bounded loop, so the loop rules still apply.
• Isolation beats instructions for both: sandboxes and scoped credentials decide the blast radius of a failure, whatever the topology.

The Hybrid Reality

Most production systems are graphs of loops: a deterministic outer graph holds durable state, approvals and the audit trail; inside each node a bounded agent loop handles the uncertain work. The outer graph answers "what is the shape of this process?"; the inner loops answer "what's the next step?".

Check Yourself

Exercises

Study Notes

• Loop = keep doing a class of work until a condition holds; build one when P × N × (S + R) > F
• The verifier bounds the loop: external checks over self-critique; good loops improve their environment
• Graph signals: specialities, parallelism, per-step models/tools, auditable branching, a large verifier
• "What if it dies halfway?" - failure semantics decide loop vs checkpointed graph
• Loops: stop conditions, idempotent side effects; graphs: idempotent nodes, versioned state; production = graphs of loops

References

• Anthropic, Building Effective Agents (Dec 2024)
• Huang et al., Large Language Models Cannot Self-Correct Reasoning Yet (2023)
• LangChain, Workflows and agents (2026)

Last reviewed: 2026-09