Skip to main content

Loops vs Graphs: How the Two Patterns Nest

One agent iterating and many agents passing work are different things at different levels. Holding the distinction makes architecture conversations much shorter.

Verdeshell Team · 5 min read · Last reviewed

They nest. Loop engineering governs how one agent iterates on its own work. Graph engineering governs how many agents pass work between roles.

A graph of loops: the two patterns nestGraph engineering governs how work passes between specialized agents. Loop engineering governs how each of those agents iterates internally. Every node in the graph runs its own loop, so the two patterns operate at different levels of the same system rather than competing.GRAPH — how work passes between rolesProductloopEngineeringloopQAloopLOOP — how one agent iterates inside its own nodeSo the question is never “loops or graphs”. It is a graph of loops.Most muddled architecture arguments are two people using “agent” at different levels.
A graph of loops. The graph governs handoffs between roles; each node governs its own iteration.

The distinction in one table

Loop engineering — scope: one agent, one cycle. Governs how a single agent iterates on its own work. The unit is act, observe, reason, retry. The analogy is one engineer refining until the tests pass.

Graph engineering — scope: many agents, many roles. Governs how work passes between specialized agents. The unit is node, edge, feedback edge. The analogy is a team handing work down a pipeline and back up it when something fails.

How they nest

The graph is the overall workflow of specialized agents. Each node is one agent, and that agent is usually running its own internal loop.

So the answer to "loops or graphs" is almost always "a graph of loops". Asking which one to use is a category error — they operate at different levels of the same system.

The progression

From prompts: you prompt the agent at every step, and the quality of the output tracks the quality of your prompting.

To loops: you design the loop that prompts the agent, and the quality tracks the design of your stop conditions and tool access.

To graphs: you orchestrate many looping agents, and the quality tracks how well you decomposed the roles.

The direction of travel is agents taking on larger and more autonomous chunks of work — and the human role moving further up, from writing the instructions to designing the system that generates them.

Why the distinction is worth holding

Most unproductive architecture arguments come from two people using "agent" at different levels — one meaning a node in a workflow, the other meaning the iteration inside it.

Naming the level first makes the disagreement resolvable. It usually turns out both people are right about different things.

Want this built properly?

We design and run these systems for clients. Tell us the problem and we will tell you whether an agent is the right shape for it.