An agentic execution loop lets a model observe state, choose a tool, inspect the result, and continue until it produces a final answer. This is useful for coding work because a patch can be compiled and tested before it is returned.
The same loop can waste money, repeat a side effect, or drift away from the task. A production loop therefore needs explicit bounds enforced by the runtime, not merely requested in a prompt.
“Bounded agentic execution loop” is a descriptive design pattern, not an industry protocol. Its value comes from combining several familiar controls.
The loop
A minimal coding loop has five stages:
- Observe: Read the approved task, current repository state, and relevant evidence.
- Plan: Select one bounded next action.
- Act: Invoke an allowed tool with validated arguments.
- Verify: Inspect the tool result and update task state.
- Stop or continue: Return a result, request approval, or take another turn.
The runtime should own the counters and permissions. A model cannot be trusted to enforce its own budget after it has lost context or entered a repetitive failure pattern.
Bounds that matter
Use several independent limits:
- maximum model turns;
- wall-clock deadline;
- model-token or cost budget;
- tool-call count and per-tool timeout;
- maximum bytes read, written, or returned;
- allowed workspace, network destinations, and credentials; and
- retry count by error class.
Reaching a limit should produce a structured terminal state such as complete, needs_approval, budget_exhausted, or failed. Do not silently convert an unfinished run into success.
OpenAI's Agents SDK, for example, exposes a max_turns limit and raises a specific error when a run exceeds it. That is one control, not a complete policy.
Stop conditions
A good stop condition is observable and testable. Examples include:
- the requested artifact exists and its acceptance checks pass;
- no allowed action can resolve the remaining failure;
- the next action requires authority the run does not have;
- repeated attempts produce the same error fingerprint; or
- a budget or deadline is reached.
“Continue until confident” is not a stop condition. Confidence is model-reported state, not external evidence.
Retry safely
Retries should be selective. Transient network failures may merit exponential backoff. Syntax errors may merit one corrected attempt. Authentication failure, policy denial, or a deterministic failing test usually requires a different action rather than repetition.
Durable workflow systems can persist step results and retry a failed step instead of replaying the entire run. Cloudflare Workflows, for example, defines each step as an individually retryable unit whose state can be persisted across infrastructure failures.
Idempotency is essential for side effects. A request is idempotent when repeating it has the same intended effect as performing it once. Reads are often naturally idempotent; payments, deployments, comments, and file writes may require an idempotency key, compare-and-set condition, or explicit precondition. Logging a duplicate is not the same as preventing it.
Approval gates
Pause before actions with material external impact:
- publishing or deploying;
- deleting or moving data;
- changing access controls or secrets;
- spending money;
- messaging people; or
- modifying systems outside the approved workspace.
The approval request should show the exact action, target, relevant diff or parameters, and expected consequence. Approval for one action must not become authority for later unrelated actions.
Verification and recovery
Each mutation should have a matching verification step. After a code edit, inspect the diff and run the narrowest relevant checks. After deployment, check the deployed version and a health signal. Keep test output and tool errors as evidence attached to the run.
Recovery should be planned before execution. Prefer reversible changes, versioned artifacts, and transactional boundaries. A rollback is still a side effect and needs the same targeting and authorization discipline as the original action.
Measure the loop
Track completion rate, verified success, human override rate, repeated-error rate, turns, latency, and cost. Segment results by task type and risk level. A loop that completes quickly by skipping verification is not better.
The goal is not maximal autonomy. It is the smallest amount of autonomous iteration that can produce a verified result within explicit authority.