Agent loop

How it works

An agent loop is a control loop, and the harness owns it. The model does not run free; it proposes one step at a time, and the harness decides whether that step happens. Each turn:

• Assemble context — system prompt, the task, tool schemas, and the results of prior turns.
• Ask for the next action — the model returns a tool call, a sub-goal, or a final answer.
• Execute it in the world — run the tool, call the API, write the file, query the store.
• Capture the observation — append the result as new context the model will see next turn.
• Check stop conditions — goal reached, iteration or token budget spent, or a guard tripped.

The loop repeats until one of those conditions fires. The model supplies judgment; the harness supplies memory, execution, and limits. That split is the whole point: the model is stateless and stochastic, so every durable fact — what has been tried, what succeeded, how many turns remain — lives in the harness, not the weights. A loop built this way is legible at every turn. You can read the exact context that went in, the action the model chose, and the observation that came out. That per-turn trace is the unit you debug, evaluate, and roll back against.

Why it matters in an agent harness

The loop is where control actually lives. Autonomy is not a property of the model; it is how many times you let the loop run, and with what permissions, before a check or a human intervenes. Everything an operator cares about attaches to the loop, not the prompt.

• Reversibility comes from capturing state between turns, so you can checkpoint before a risky action and unwind to a known-good turn.
• Observability comes from logging each turn's context, action, and result — a trajectory you can replay instead of guessing.
• Permissions attach to the execute step: the model may ask for any tool, but the harness decides which calls are allowed, sandboxed, or gated behind approval.
• Failure containment comes from the stop conditions. A loop with no iteration budget and no guard is not autonomous; it is unbounded.
• Evaluation runs on the trajectory the loop emits, so you grade the decisions, not just the final string.

Move any of these into the model and you lose them the moment the model changes. Keep them in the loop and they hold across model swaps and version bumps.

Agent loop vs agentic workflow

Both run a model repeatedly, but they differ in who decides the control flow, and that difference changes how you design and how much you can predict.

The practical rule: predetermine the flow when you already know the steps, and hand control to the loop only where the path genuinely can't be known in advance. Many strong systems are workflows with one or two loop-shaped stages inside them, not a single loop doing everything.

The Rifty take

We optimize for a loop that is legible and interruptible over one that is maximally autonomous. Give the model judgment; keep state, execution, permissions, and stop conditions in the harness where you can inspect and reverse them. We accept a few more turns and a little more scaffolding as the price of being able to read exactly what happened and unwind it. A loop you cannot bound or replay is not an agent — it is an outage waiting for a trigger.

Common failure modes

• No stop condition. Without an iteration or token budget, a stuck model loops until something else kills it. Set an explicit budget and a fail-closed default.
• Context that only grows. Appending every observation forever blows the window and buries the signal. Summarize or compact between turns instead of accumulating raw output.
• State smuggled into the prompt. Facts that belong in harness memory get re-derived from history each turn, drifting as the transcript grows. Keep durable state structured and outside the model.
• Silent tool failures. An error returned as plain text the model can rationalize away corrupts the next decision. Surface failures as distinct, unambiguous observations.
• Untrusted observations treated as instructions. Tool and web results can carry injected directives. Fence external content as evidence, never as commands the loop must follow.
• No per-turn trace. If you can't replay the loop, you can't debug or evaluate it. Log context in, action chosen, and result out for every turn.

Frequently asked questions

What is the difference between an agent loop and a single model call?

An agent loop runs many model calls in sequence, feeding each action's result back as new context, while a single call returns one answer with no execution or follow-up. The loop lets the model act, observe, and correct across turns; a single call cannot use tools or react to results.

How do you stop an agent loop from running forever?

Give the loop explicit stop conditions the harness enforces: an iteration budget, a token or cost budget, a goal-met check, and guards that fail closed. Never rely on the model to decide when to stop. The harness owns termination, so an unresponsive or stuck model still halts predictably.

Where should state live in an agent loop?

State should live in the harness, not the model. The model is stateless and stochastic, so durable facts — what was tried, what succeeded, turns remaining, permissions — belong in structured harness memory. Re-deriving state from the growing transcript each turn causes drift and burns context you cannot afford.

Is ReAct the same as an agent loop?

ReAct is one policy for an agent loop, not a different thing. It structures each turn as reason-then-act-then-observe. An agent loop is the general cycle; ReAct is a specific, widely used way to prompt and sequence the reasoning and action steps within that cycle.

How do you debug an agent loop that behaves inconsistently?

Debug the trajectory, not the final output. Log each turn's exact context in, action chosen, and observation out, then replay it. Inconsistency usually traces to context that grows or drifts, silent tool failures, or missing state — all visible in the per-turn trace and invisible in the answer alone.