Every non-trivial agent workflow is either a loop or a graph, and often a hybrid of both. A loop iterates until something terminates. A graph routes through typed transitions until it reaches a terminal node. The choice between them is the most consequential design decision in any agent system that does more than one thing.

This pillar names the threshold where iteration becomes routing, the patterns that work at that threshold, and the mistakes that come from picking the wrong shape for the work. It is meant to be read once and returned to whenever a workflow starts to feel like it has outgrown its current shape.

The point is not to memorize the patterns. The point is to recognize which shape a system is currently using, why it is failing when it is, and what changing the shape — not the model — would do.

What "loop" and "graph" mean here

In this manual, the two words have specific meanings that do not always match their use elsewhere.

A loop is a repeating structure in which the agent reads the current state, decides what to do next, acts, and repeats. The decision logic lives inside the loop. The structure around it is mostly implicit. Termination is a condition the loop checks each iteration.

A graph is a collection of nodes (steps) and edges (typed transitions) that an agent moves through. Each node is a small loop in its own right, but the structure around them — what comes next, what does not, what counts as success — is explicit. Termination is a property of the graph; some nodes are terminal, others are not.

The basic piece on Loops vs Graphs introduces the distinction. The piece on Basic State Graphs and Workflows treats graphs in more detail. This pillar assumes both and focuses on the threshold between them.

Why the threshold matters

The loop-or-graph decision matters because the two shapes make different things easy and different things hard.

Loops make the following things easy:

  • Goal-directed work. "Keep going until the goal is satisfied."
  • Adaptive decisions. The next step depends on the most recent observation, not on a pre-planned path.
  • Simple state. The state is whatever the loop has accumulated.
  • Low ceremony. No graph definition, no node registry, no edge types.

Loops make the following things hard:

  • Auditability. Why did the loop take the path it took? Often the only answer is "because the model decided to."
  • Branching. Each branch is a new conditional inside the loop; after three or four, the loop becomes spaghetti.
  • Reuse. The same routing logic, written into two different loops, becomes two different bugs to maintain.
  • Parallelism. Loops run serially; concurrent branches have to be coordinated outside the loop.

Graphs make the following things easy:

  • Explicit routing. "From state X, only edges A and B are valid."
  • Branching at scale. Each branch is a node; adding a branch is adding a node.
  • Auditability. The path through the graph is a sequence of edges, not a model decision.
  • Reuse. The same node can appear in multiple graphs; the same edge types can be shared across workflows.

Graphs make the following things hard:

  • Adaptive decisions. Every branch the agent might want to take has to be encoded as an edge.
  • Goal-directed work. A graph does not "iterate until done." It traverses until it hits a terminal node.
  • Up-front design. A graph has to be drawn before it runs.
  • Over-engineering. Reaching for a graph to solve a problem that is still a single-loop problem adds cost without buying clarity.

The threshold between the two is the point where the cost of implicit routing inside a loop starts to exceed the cost of explicit routing in a graph. Below the threshold, loops are cheaper. Above it, graphs are cheaper.

The five signals that you have crossed the threshold

Triadive uses five signals to identify workflows that have outgrown their loop and need a graph. They are listed here in roughly the order they show up.

1. More than one terminal state. The workflow has at least two distinct success outcomes — "completed," "needs human review," "escalated" — and they need to be distinguishable in audit logs. A loop can express this, but only by encoding each terminal state in the loop's termination logic. 2. Branching that exceeds three levels. The decision tree inside the loop is deeper than three nested conditionals. Past three levels, the loop becomes harder to read than a small graph. 3. State that survives across iterations. The workflow has durable state that does not fit in the loop's local context — typically a state machine, a session record, or a ticket. 4. Reuse across workflows. The same routing decision is needed in more than one workflow. Encoding it twice is a future bug. 5. Human-in-the-loop pauses. The workflow has explicit pause points where a human has to act before the workflow continues. Encoding pauses inside a loop adds tail latency and observability cost that graphs make cheap.

The first signal is the cheapest to detect and the one most often missed. The fifth is the most expensive to retrofit and the one that shows up loudest in operator experience.

The patterns that work at the threshold

Once a workflow has crossed the threshold, the design question becomes which graph pattern fits the work. Triadive uses four.

Pattern 1 — Sequential graph with typed edges

The most common pattern. Each node has one outgoing edge to the next, with a typed condition that decides which edge to take. The graph looks like a flowchart with conditional branches. The state graph glossary entry captures the basic vocabulary.

Use this when the workflow is essentially linear with a few branches. The cost is the graph definition; the benefit is that the path through the workflow is auditable.

Pattern 2 — Hub-and-spoke with a coordinator

One node acts as a coordinator. The other nodes are leaves that the coordinator dispatches to. The coordinator decides what to run next based on the current state. The leaves do not know about each other.

Use this when the workflow has a clear central decision and a set of independent operations. Sub-agent loops live inside this pattern; the coordinator is the parent loop, the leaves are the child loops.

Pattern 3 — Pipeline with retries

A linear pipeline where each node has its own retry budget and its own dead-letter destination. The pipeline itself is the graph; each node is the loop.

Use this when the workflow is mostly straight-through processing with isolated failure modes. The piece on Error budgets and failure handling treats this in detail.

Pattern 4 — State machine with typed events

The graph is a state machine. Each node is a state. Each edge is triggered by a typed event. The workflow transitions through states based on the events it receives, not on the model's decisions.

Use this when the workflow is event-driven and the events are external — a webhook, a queue message, a cron tick, a user action. This is the pattern that long-lived automation usually ends up in, whether or not it started there.

The mistakes that come from picking the wrong shape

The threshold is the place where mistakes are most often made. The mistakes are listed here in roughly the order they cost the most.

Mistake 1 — Premature graphing

Reaching for a graph to solve a problem that is still a single-loop problem. The graph adds cost without buying clarity. The signal that you have made this mistake is that the graph has only one node, or that the graph's edges are all unconditional.

Fix: collapse the graph into a loop. Most "graphs" with fewer than three nodes are loops wearing a uniform.

Mistake 2 — Loop-encoded graph

The opposite mistake. Encoding a graph's worth of routing logic inside a single loop. The loop becomes spaghetti. The signal that you have made this mistake is that the loop's intake includes a "which mode are we in?" branch, or that the loop's termination condition has more than three clauses.

Fix: extract the routing into a graph. The loop becomes a node; the graph becomes the structure around it.

Mistake 3 — Graph-encoded loop

A graph that the agent loops over because the terminal node never actually fires. The signal is that the same node runs more than once in a typical execution, or that the workflow has a "loop back to the start" edge that fires more often than the other edges.

Fix: convert the looping node into a loop inside the node. The graph's job is routing, not iteration.

Mistake 4 — Untyped edges

A graph where the edges do not declare their conditions. The agent has to figure out which edge to take. The signal is that the graph has runtime branches that do not appear in the graph definition.

Fix: type the edges. Each edge should declare its condition. The graph's job is to make the routing legible, not to delegate it.

Mistake 5 — Stateless graphs

A graph that does not actually carry state between nodes. Each node has to recompute the state from scratch. The signal is that the same expensive query happens at every node, or that the workflow's behavior depends on the order of node execution.

Fix: introduce explicit state. Either a state object passed between nodes, or a state store the nodes read from and write to. The graph's job is to organize the state, not to ignore it.

Hybrid patterns: where loops live inside graphs

The loop-or-graph question is rarely a binary. Most real workflows are hybrids: a graph for routing, loops inside the nodes for the work each node has to do.

A useful default: the graph handles routing; each node is a loop. The graph decides what to do next; the node decides how to do it. The two pieces have different failure modes and different debugging strategies. Mixing them produces workflows that are hard to reason about end-to-end.

A second useful default: the loop handles iteration; the graph handles delegation. A parent loop runs as long as the work needs iteration; when the work needs parallelism, the loop delegates to a sub-graph. The piece on Sessions, Sub-Agents, and Child Sessions treats this pattern in detail.

A third useful default: the cron drives the loop; the graph organizes the work. A cron tick starts a loop; the loop reads the current state from a graph-style state machine; the loop acts; the loop terminates; the next tick starts again. This is the pattern most long-lived automation ends up in.

How the threshold moves over time

The threshold is not fixed. A workflow that started as a single loop may grow into a hybrid as the work scales. A workflow that started as a small graph may collapse back into a loop when the work simplifies.

The signs that the threshold has moved:

  • The loop has been edited more than ten times in a quarter.
  • The graph has fewer than three nodes but more than five conditional edges.
  • New operators take more than a week to understand the workflow.
  • The workflow's audit log is no longer enough to debug the most common failures.

Each sign is a signal to reconsider the shape. None of them is a signal to redesign from scratch. The threshold moves by small steps, and the workflow should move with it.

Reading order for the loops-vs-graphs coverage on Triadive

The pieces on Triadive that touch this pillar build on each other. Read in this order:

1. What Is an Agent Loop? — the loop half of the comparison. 2. Loops vs Graphs — the comparison itself, in concept form. 3. Basic State Graphs and Workflows — the graph half, in implementation form. 4. From Loops to Graphs: Agent Engineering — the engineering discipline around the threshold. 5. Graph-Based Agent Memory — the memory layer that graphs make possible.

Read in this order, the threshold becomes visible. Read out of order, the patterns still make sense but the design choices become opaque.

The takeaway

The loop-or-graph question is the design question that outlives any specific model or platform. Loops and graphs are not competitors; they are two shapes for two different kinds of work, and most real systems use both. The work is to recognize which shape the current work needs, which shape the work is going to need as it grows, and how to move between the two without rewriting the whole workflow.

If you take one thing from this pillar, take this: when a workflow starts to feel like spaghetti, the answer is rarely "use a smarter model." The answer is almost always to look at the shape of the workflow — loop, graph, or hybrid — and ask whether the shape still matches the work.