An agent loop is the operating rhythm of an agentic system. It is the cycle that takes a goal in, gathers context, decides what to do next, acts, records the result, and decides whether to continue or stop. Most pieces on Triadive are about some part of this rhythm — what the intake looks like, how context is bounded, where memory lives, how tool calls fail, when the loop should stop.

This field note is the pillar that pulls those pieces together. It is meant to be read once and returned to. It names the loop variants Triadive has documented, the failure modes each variant tends to produce, and the design choices that decide whether a given loop keeps an agent coherent or slowly destroys it.

The point is not to memorize the variants. The point is to recognize which one you are running, why it is failing when it is, and what changing the loop — not the model — would do.

What a loop is, in one paragraph

A loop is the smallest repeating structure that lets an agent make progress on a goal it cannot finish in one pass. The loop reads the goal, asks what to do next, acts, observes the result, and repeats until something tells it to stop. The "something" is usually a stop condition: a success check, a failure budget, a wall-clock limit, or an explicit user signal.

A model call without a loop is a chatbot. A model call inside a loop is an agent. The difference is the loop, not the model. That is why agent design is mostly loop design with some model selection around the edges.

The basic anatomy of any agent loop is the same six stages, regardless of the loop variant:

1. Intake — receive the goal, the task, or the trigger. 2. Context — gather the information needed to act well. 3. Inference — decide what to do next. 4. Tool execution — act on that decision. 5. Persistence — record what happened in a place that survives the loop iteration. 6. Termination — decide whether to stop or run another cycle.

Each of these stages is its own design problem. The loop variants differ mostly in how those stages are wired together and where the state lives between iterations.

The piece on What Is an Agent Loop? walks through these stages in the simplest possible form. The rest of this pillar assumes that vocabulary and focuses on what changes when the loop scales up.

The five loop variants Triadive has documented

Once you have seen the basic cycle a few times, the interesting design question becomes: which loop variant fits this work? Triadive has worked through five. None of them is "the right one." Each is the right one for a specific shape of work.

1. Single-shot loops

A single-shot loop runs once and exits. The intake is the prompt. The context is whatever the model already has. The inference produces an output. The termination is implicit — there is no next iteration.

Single-shot is what most chatbot work actually is, and it is the correct shape for a surprising amount of real work: classification, extraction, summarization, rewriting, format conversion. The mistake is to reach for a more elaborate loop when single-shot would do.

The signal that you have outgrown single-shot: the prompt starts sprouting conditional logic, the context starts exceeding the window, or you find yourself copy-pasting the previous output into the next call.

2. Multi-turn loops

A multi-turn loop is the basic agent loop in conversational form. Each turn is one iteration of the cycle. Context is the conversation history. Persistence is whatever the platform stores between turns. Termination is the user stopping, an explicit "done" signal, or a configured cap.

Multi-turn is the most common loop in interactive agent products. Its failure modes are well known and well studied: context drift, tool contamination, hidden failures, and weak termination are all amplified by long conversations. The piece on Why Agents Stall Without Clear Termination is mostly about multi-turn loops.

3. Cron-driven loops

A cron-driven loop runs on a schedule, not in response to a user. Intake is the trigger event. Context is built fresh from the current state of the world. Inference produces a decision or an artifact. Persistence is the durable record of the run. Termination is built into the schedule — the next iteration starts on the next tick, whether or not the previous one finished well.

Cron-driven loops are how long-lived automation actually gets built. The Daily Check-in Loop and the Daily Triage Routine are both cron-driven. The piece on Cron Jobs, Heartbeats, and Scheduled Work walks through the design choices.

The characteristic failure of cron-driven loops is not the loop itself; it is the silent loop. A cron loop that produces nothing useful for three days in a row is harder to detect than a chat agent that hallucinates once.

4. Sub-agent loops

A sub-agent loop delegates part of the work to a child session. The parent loop stays in charge of intake, persistence, and termination; the child loop runs its own intake-context-inference-action cycle, returns a result, and the parent loop continues.

Sub-agent loops are how an agent system gets parallelism, focus, and quota isolation. The piece on Sessions, Sub-Agents, and Child Sessions covers the design choices in detail.

The characteristic failure of sub-agent loops is the return-shape problem. A child loop returns a result the parent loop does not know how to interpret, and the parent loop either retries forever or treats the malformed result as success. The fix is almost always at the contract layer, not the model layer.

5. Graph-driven loops

A graph-driven loop replaces the linear sequence with a state graph. Each node is a step. Each edge is a typed transition. The loop moves through the graph, branching on state, joining on completion, and exiting when it reaches a terminal node. Inference still happens inside each node; what changes is the structure around it.

Graph-driven loops are how non-trivial workflows get built without becoming spaghetti. The Loops vs Graphs piece covers when the routing decision is worth making.

The characteristic failure of graph-driven loops is premature graphing. Reaching for a state graph to solve a problem that is still a single-loop problem adds cost without buying clarity. The threshold for graduating from a loop to a graph is roughly: more than one branch, more than one terminal state, or more than one place where the work can fail.

What changes between loop variants

Once the variants are visible, the design choices start to organize themselves. Each variant makes different things easy and different things hard.

  • Single-shot vs multi-turn. Single-shot trusts the prompt to do all the work. Multi-turn trusts the conversation to do the work. The trade-off is between prompt craft and context management.
  • Multi-turn vs cron-driven. Multi-turn trusts the user to keep the conversation alive. Cron-driven trusts the schedule to keep the work alive. The trade-off is between responsiveness and predictability.
  • Cron-driven vs sub-agent. Cron-driven trusts the schedule to serialize the work. Sub-agent trusts the parent loop to coordinate the children. The trade-off is between simplicity and parallelism.
  • Sub-agent vs graph-driven. Sub-agent trusts the model to decide what to delegate. Graph-driven trusts the graph to encode the routing. The trade-off is between flexibility and auditability.

None of these trade-offs is a one-way door. Loops can be re-shaped without re-platforming. A multi-turn loop with a cron wrapper is a cron-driven loop that still feels interactive. A cron-driven loop with a delegation step is a sub-agent loop wearing a uniform.

The mistake is to treat the variant as a commitment. The variant is a choice you can revisit every time the loop stops behaving the way you intended.

Failure modes the loop has to defend against

Every loop variant eventually has to defend against the same handful of failure modes. They are listed here so they can be recognized when they show up, regardless of variant.

  • Context drift. The context the loop is reasoning over is no longer the context the operator intended. The piece on Why Context Explodes Without Bounding treats this in depth.
  • Tool contamination. A bad tool result gets treated as truth and propagated through the rest of the loop. The fix is to give the loop a way to fail loudly on bad tool results, not silently incorporate them.
  • Weak termination. The loop does not know when to stop, so it keeps cycling. The piece on Why Agents Stall is about this failure mode specifically.
  • Hidden failures. The loop reports success but did not actually do the work. This is the most expensive failure mode because it takes the longest to detect. The fix is durable artifacts, not chatty confirmations.
  • Over-looping on ambiguous goals. The goal is too vague to make progress on, and the loop keeps trying anyway. The fix is at intake: refuse the goal until it is specific enough to act on.

A useful exercise: take any running agent system and rank these five failure modes by current blast radius. The ranking changes as the loop changes, but at any moment one of them is the dominant cost.

Loop hygiene

Loop hygiene is the practice of keeping a loop legible to the next operator. It is the cheapest investment an agent system can make and the one that pays back the most under stress.

The minimum viable loop hygiene is six things:

1. The loop is named. Not "the agent" — the actual loop, with a file or a graph node you can point to. 2. The intake is auditable. You can replay what the loop saw at step 1 on any past run. 3. The context sources are explicit. You can list what the loop pulled from and what it ignored. 4. The tool calls are durable. You can find every tool call the loop made, with input and output. 5. The termination condition is written down. Not "it feels done" — an actual predicate the next operator can read. 6. The state is recoverable. If the loop dies mid-iteration, the next iteration can pick up where the previous one stopped.

These are not aspirational. They are the floor below which an agent system becomes impossible to debug.

Reading order for the loop coverage on Triadive

The loop pieces on Triadive are designed to be read in this order:

1. What Is an Agent Loop? — the basic cycle. Start here. 2. Inside the Agent Loop — each stage in more detail, with examples. 3. Loops vs Graphs — the first major design choice. 4. Cron Jobs, Heartbeats, and Scheduled Work — how loops run unattended. 5. Sessions, Sub-Agents, and Child Sessions — how loops delegate. 6. Why Context Explodes Without Bounding — the most common failure mode, in depth. 7. Why Agents Stall — the second most common failure mode. 8. Memory Design Mistakes — where loops go wrong because of memory.

Read in this order, the pieces build on each other. Read out of order, each one still makes sense on its own.

The takeaway

Loop design is the part of agent design that outlives any specific model, any specific platform, and any specific year. The loop decides how the agent handles ambiguity, how it recovers from failure, how it uses memory, how it terminates, and how it stays auditable. The model decides none of those things.

If you take one thing from this pillar, take this: when an agent system misbehaves, change the loop before you change the model. The loop is almost always the cheaper, faster, more durable fix.