Execution Loop

What it is

The control structure that advances one agent repeatedly: assemble the context, call the model, interpret what came back, perform any requested tool calls, append their results, and decide whether to go round again. Every iteration re-evaluates the whole situation from the context it was given, which is why the loop — not the model — is where an agent's cost and latency actually accumulate.

Why it matters

The loop coordinates mechanically enforced boundaries before another model or tool call. Iteration ceilings and spend accounting belong to the controller; argument validation, permissions, and observation shaping may be delegated to other harness components, but the loop must use those components without a bypass. It is also where the economics are set: each turn pays again for everything accumulated so far, so a design that appends generously is paying a quadratic bill nobody wrote down.

Inner execution versus outer work

This capability describes the inner loop inside one agent run. An outer controller can select a work item, launch this run, check the resulting artifact, update a backlog, and decide when another attempt or another item is eligible. Those cross-run decisions belong to Loop Engineering. Carrying durable run counters alone does not establish item-level acceptance or prevent a fresh run from repeating previously committed work.

The loop, its concurrency, and its exits

Four things are easily conflated. The loop is the control structure that decides there will be another iteration. Running several calls at once is a concurrency choice made inside or across iterations, and changes throughput rather than control flow. The rules that deliberately end the loop — success criteria, budgets, deadlines — are stopping conditions, and a loop with no stopping condition other than an iteration ceiling has no definition of done. Noticing that iterations are producing no progress is a diagnosis, separate again, and it feeds a stopping condition rather than being one.

Key decisions

• What is carried into the next iteration: the full history, a sliding window, a running summary, or a structured scratchpad rebuilt each turn from durable records.
• Whether tool results enter the context verbatim or are normalised, truncated, and bounded first — and who decides what to drop.
• Whether arguments are validated against the tool's schema before execution, and whether an invalid call returns a correctable error to the model or raises.
• Where the per-iteration deadline sits, independent of the overall run deadline, so a single slow tool cannot hold a turn indefinitely.
• Whether each iteration is durably recorded, which is what makes a crashed run resumable and an audit trail possible.
• How streaming interacts with iteration: whether partial output reaches the user before the turn's tool calls are known to have succeeded.

Failure modes

• Context grows by a tool result every turn until the window is exceeded mid-task, and the truncation strategy discards the original instructions first because they are oldest.
• A single tool returns forty thousand tokens of raw payload and every subsequent iteration pays for it again.
• Errors are appended as plain prose, the model reads them as content rather than as feedback, apologises, and reissues the identical call.
• The iteration ceiling is reached and the loop returns the last model message, which is typically an intention to continue rather than an answer.
• Arguments are passed through unvalidated, so a malformed call raises inside the runtime and kills the run instead of being returned to the model as something it could fix.
• There is no per-turn deadline, and one unresponsive tool holds the user's turn open until an outer timeout fires with no partial result.
• The record of what was called and what came back exists only in the prompt, so trimming the prompt also destroys the audit trail.
• Streaming commits visible output before the turn's tool calls complete, and the user reads a confident statement that the subsequent tool result contradicts.

Related capabilities

• Loop Engineering — the outer work-selection and verification cycle
• Agent Harness Engineering — the runtime services each turn uses
• Agent Graph Engineering — explicit paths that can contain this loop
• Termination Conditions — the rules evaluated to decide against another iteration
• Loop Detection — identifies iterations that are not advancing anything
• Parallel Execution — concurrency within or across iterations
• Interrupt and Resume — requires iterations to be durable boundaries
• Shared State Management — holds what the context cannot keep carrying

Applies: Production readiness · Design questions