Agent Architecture and Orchestration
Execution Loop — Stack
Execution loop › Stack
Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.
Selection criteria
What you are choosing is how much of the turn-by-turn machinery you own, and what you give up in control when you do not own it.
- Context assembly control. Whether you decide what enters the next call, or the runtime decides and you configure around it.
- Argument validation. Whether tool arguments are checked against a schema before execution, and whether a failure is returned to the model as a correctable observation.
- Per-iteration durability. Whether each turn is written somewhere that survives the process, which is the prerequisite for resuming and for auditing.
- Step-level observability. Whether every model call, tool call, token count, and latency is individually visible without instrumenting by hand.
- Interruptibility. Whether the loop can be stopped between iterations and later continued, as opposed to only being killed.
- Replay. Whether a recorded run can be re-executed to reproduce a decision, and what has to be stubbed for that to work.
- Accounting. Whether tokens, spend, wall clock, and tool-call counts are tallied per iteration or only for the run as a whole.
- Streaming semantics. Whether output can be streamed while keeping the commit point under your control.
Options
| Option | Best for | Watch out for |
|---|---|---|
| Hand-written loop over a provider chat API with native tool calling | Teams that want full control of context assembly and have the appetite to own it | Everything — retries, validation, accounting, truncation — is yours to write and keep correct |
| Framework agent executors (library-provided agent runners) | Getting a working loop quickly with conventional behaviour | Context assembly and truncation policy are usually opaque and hard to override cleanly |
| Graph runtimes with explicit nodes and edges (LangGraph, Google ADK, Burr) | Loops that need checkpointing, branching, and human interruption as first-class concepts | The loop becomes a graph you must reason about; debugging moves from a stack trace to a state diagram |
| Durable workflow engines as the loop (Temporal, Restate, AWS Step Functions) | Runs measured in hours or days that must survive deploys and infrastructure failure | Determinism constraints on loop code; the engine's retry semantics and the agent's must be reconciled |
| Provider-hosted agent runs (managed run APIs, cloud agent services) | Offloading the loop entirely, including context management and tool dispatch | Truncation and retry behaviour are not yours; a change on the provider's side changes your product |
| Reasoning models with an internal multi-step process | Tasks where the deliberation is internal and external tool orchestration is light | Little visibility into intermediate steps; stopping and accounting are coarse-grained |
| Code-execution loop where the model emits a program that calls tools | Work that benefits from composing several calls per turn with real control flow | Sandboxing becomes the dominant design problem; failures arrive as runtime exceptions, not tool errors |