Writing ·
When Agent Loops Grow Up, They Become Graphs
Agent loops remain useful for bounded work. When a system needs parallel branches, approval gates, checkpoints, and scoped recovery, make the control flow explicit with an agent workflow graph.
By Youssef Hemimy · agent workflows · AgentOps · orchestration
Agent loops do not disappear as systems grow; they become a bounded edge inside an explicit workflow graph. A loop is excellent for one repeatable job: act, verify, retry, stop. A graph earns its complexity when the system must make parallel work, conditional routing, approval, checkpoints, and recovery visible to both the software and the operator.
A loop is a control-flow primitive, not a whole architecture
The recent Ralph-loop conversation is useful because it gets one thing right: a capable agent can improve a bounded piece of work over several attempts. The loop needs a verifier, a stop condition, and a budget. That is a good pattern for fixing a test failure, refining a draft, or retrying a contained tool operation.
It becomes the wrong shape when one outer loop is quietly expected to coordinate everything else: independent specialists, writes with different risk, a reviewer who may be offline, and a partial failure after other work already completed. More prompting does not make those boundaries legible. Explicit control flow does.
The graph gives each agent a job—and each edge a policy
An agent graph is not an org chart full of little AI boxes. It is a model of execution. Nodes own bounded work; edges state what may run next, in parallel, after review, or after a recovery decision. The diagram below has two specialists, but the important part is not the agent count. It is the join point, the risk boundary, and the recovery scope.
01 · ENTRY
Intake
request + constraints
02 · ROUTER
Planner
choose the work
03A · SPECIALIST
Research agent
evidence + sources
03B · SPECIALIST
Systems agent
constraints + tools
04 · MERGE
Synthesizer
one reviewable plan
05 · POLICY
Risk gate
side effect allowed?
LOW RISK
Execute
bounded write
Verify
pass or retry
The loop stays here: one owner, one retry budget, one exit condition.
HIGH RISK
Human approval
Freeze the proposed action; resume only with the recorded decision.
Four questions that expose a loop-shaped system
| Question | A loop can answer | A workflow graph makes explicit |
|---|---|---|
| What repeats? | One bounded task until verification passes or its budget ends. | Which node owns the loop, its budget, and its exit path. |
| What can run independently? | Usually nothing without custom coordination around the loop. | Fan-out branches and the join that waits for their results. |
| Who decides on a risky write? | The loop's agent prompt or a convention outside the run. | A policy edge to a frozen, reviewable approval request. |
| What resumes after failure? | Often the entire attempt unless the loop builds its own state model. | The failed branch, from a named checkpoint and known handoff. |
Graph the control plane, not every thought
The model should still reason inside a bounded task. The graph should govern the decisions that need a reliable answer outside the model: which task starts, what state it receives, whether a side effect is allowed, what gets retried, and where a human must decide. This keeps orchestration deterministic where it needs to be without pretending the work itself is deterministic.
That split is now visible across orchestration frameworks. Google ADK documents graphs alongside dynamic workflows and higher-level sequential, parallel, and loop patterns. Microsoft distinguishes native control flow from graph workflows, reserving graphs for fixed topology, routing, and fan-out/fan-in. Those are implementation choices; the design lesson is broader: do not hide a system’s control plane inside one agent’s running context.
The production payoff is recoverability
A graph becomes valuable when the operator can answer: what completed, what is waiting, and what may safely run again? A checkpoint after the research branch should not imply replaying an approved write. A stalled review should pause the action, not consume a retry budget. A verifier failure should return to the executor that owns that work—not launch the whole system from the top.
This is the same AgentOps Hardening question behind workflow recovery, human approval gates, and idempotent tool calls: the model may choose an action, but the harness must preserve the state and authority needed to explain or resume it safely.
When to add the graph
Keep the loop when the work has one owner, one verifier, and one meaningful exit. Add an explicit graph when the run must coordinate independent branches, carry state across a waiting period, route by risk, or restart only the failed part. Start with the smallest graph that makes those responsibilities observable. A linear chain is still a graph; you do not earn points for turning a three-step task into an AI ant colony.
Sources
FAQ
Are agent loops obsolete?
No. A bounded loop remains a good fit for one repeatable unit of work with a clear verifier, retry budget, and exit condition. The change is architectural: put that loop inside an explicit workflow when the wider system has parallel paths, risk branches, or durable recovery needs.
Does every multi-agent system need a graph?
No. A small linear workflow or ordinary application code is often clearer. Use a graph when the control flow itself needs to be explicit and inspectable: for example, a fan-out that must join, a conditional approval branch, or recovery that must restart only one completed stage.
What belongs in an agent workflow graph?
Nodes should own a bounded responsibility: an agent task, a deterministic tool step, a policy check, a human-review request, or a verifier. Edges should make routing, handoffs, and recovery decisions explicit rather than leaving them as prompt instructions.
Where should retries live in an agent graph?
At the smallest safe boundary. A verifier can return one executor to a bounded retry loop, while a durable checkpoint lets the wider workflow preserve completed branches. Write-side retries still need idempotent tool contracts so a resumed run does not repeat an external effect.
Building something that has to hold up?
We do this work for teams — agent reliability hardening, custom MCP servers, and full-stack AI systems built to survive production.