The agentic loop
A basic chat completion is strictly reactive: it accepts an input prompt, generates a continuation, and immediately terminates. In that single interaction, the model cannot run a build, inspect a filesystem, or verify whether its code compiles.
Transforming an LLM into an autonomous coding assistant requires an orchestration layer: a program that interprets model output, executes requested commands (such as running a test suite or writing a file), feeds the execution output back to the model, and repeats the cycle until the objective is satisfied. That orchestration program is the Harnessthe program between you and the model API. It assembles the context, executes the tools the model asks for, enforces permissions, and keeps calling the model until the job is done.Full glossary entryIntroduced in The agentic loop. The majority of what practitioners describe as an "AI agent" actually resides within the logic of this harness.
Consider a practical development workflow. You prompt the system: "The parser test is failing, fix it." The harness packages your request alongside its internal system prompt, project-level instructions, and the current workspace configuration. The model evaluates the prompt and requests a shell command to execute the test suite. The harness executes the command and feeds forty lines of pytest failure traces back to the model. Analyzing the stack trace, the model issues two tool calls requesting parser.py and parser_test.py. The harness reads both files and returns nine hundred lines of code. The model then proposes modifying three lines in parser.py. Recognizing a state-modifying action, the harness pauses execution and prompts you for confirmation. Upon your approval, the edit is applied. The model requests one final test run, observes that the suite passes, and returns a concise completion summary with no further tool calls. What felt like a single command involved five model round-trips, four tool executions, and an interactive confirmation checkpoint—all triggered by seven words of user input.
The execution loop
Each iteration through this cycle constitutes a Turnone pass through the agentic loop. One model call, plus whatever the harness does with the answer before the next call.Full glossary entryIntroduced in The agentic loop: a single model invocation paired with the harness operations that handle its response. The overarching recursive process is the Agentic loopthe cycle of calling the model, running the tools it asks for, appending the results to the conversation, and calling again until the model asks for nothing.Full glossary entryIntroduced in The agentic loop.
- Context assembly: The harness gathers the system prompt, user intent, recent conversation history, and accumulated tool outputs.
- Model inference: The assembled context is dispatched to the model API.
- Action parsing: The model responds with natural language prose, structured Tool calla structured block the model emits naming a tool and its arguments. It executes nothing; the caller decides whether to run it.Full glossary entryIntroduced in Tool calls, or a combination of both.
- Policy evaluation and execution: The harness evaluates requested tool calls against its security policies. Some run automatically, others require interactive confirmation, and disallowed operations are rejected.
- Observation ingestion: Execution results—including standard output, standard error, exit codes, or refusal notices—are appended to the conversation context.
- Loop continuation: The cycle recurses back to step 1.
The loop concludes when the model produces a terminal textual response without requesting further actions, or when a configured stop condition halts execution.
Because LLMs are fundamentally stateless between API calls, models cannot remember what files they inspected in earlier turns unless the harness actively preserves those tool results within the context window.
Harness responsibilities beyond the model API
At the raw API level, an LLM simply transforms prompt tokens into completion tokens. Everything required to turn those token predictions into reliable software automation is handled by the harness:
- Context assembly and pruning: Raw user input represents only a fraction of the outgoing payload. The harness injects runtime system prompts, repository rules, conversation history, tool definitions, and dynamic workspace content. For detailed token budgeting, see what fills a context window.
- Tool execution and protocol adapters: When a model requests
read_file, the harness handles the physical disk read. For external integrations, such as MCP, the harness acts as the client maintaining subprocess lifecycles or network sockets and projecting tool schemas into the model's format. - Security and authorization: A robust Permission modelthe rules a harness applies to decide which tool calls run without asking, which stop and wait for your confirmation, and which are refused outright.Full glossary entryIntroduced in The agentic loop establishes clear boundaries around tool execution. It dictates which operations run automatically, which require interactive human approval, and which are blocked outright. Reading local files is generally permitted silently, while modifying code, running arbitrary shell commands, or accessing external networks typically requires elevated privileges.
- Token management and compaction: As conversation logs expand with lengthy tool outputs, the harness monitors available context limits. When thresholds are breached, it triggers automated compaction, pruning intermediate tool outputs or summarizing early turns to preserve room for new work.
- Resilience and error handling: Upstream API timeouts, rate limits, malformed JSON arguments, and non-zero process exits all require distinct recovery strategies. The harness manages retries, formats error diagnostics, and presents actionable feedback to the model.
- Subagent orchestration: When tackling broad investigations, a harness can instantiate a Subagenta nested agentic loop with its own context window, given one task and returning only its result, so a large search does not fill the main conversation.Full glossary entryIntroduced in The agentic loop—an isolated agentic loop with its own dedicated context window. Rather than polluting the primary conversation with tens of thousands of tokens of search results, the subagent performs the exploration independently and returns only a concise synthesis to the parent loop.
- Execution sandboxing: A Sandboxan enforced boundary around tool execution, covering which files a tool may read or write and which hosts it may reach. It holds whatever the model has been persuaded to try.Full glossary entryIntroduced in The agentic loop enforces strict operating system-level constraints around running processes. By restricting filesystem writes to designated project directories and isolating network interfaces, sandboxes prevent accidental damage or prompt injection attacks regardless of what commands the model attempts to run.
- Audit transcripts: Maintaining comprehensive on-disk audit logs of every prompt, tool invocation, and shell output ensures that complex automated changes remain inspectable and reproducible.
Stop conditions and safeguards
An agentic loop operating without guardrails can enter runaway cycles—repeatedly executing failing commands with minor variations while burning tokens and incurring API costs. A Stop conditiona limit that ends an agentic run whether or not the job is finished, such as a turn cap, a token budget, a wall clock timeout, or a user interrupt.Full glossary entryIntroduced in The agentic loop provides a deterministic boundary that halts execution regardless of model state.
Production harnesses commonly enforce multiple complementary limits:
- Turn caps: Enforcing a maximum count of model round-trips prevents infinite loops when an agent gets stuck in circular troubleshooting.
- Token budgets: Capping total token consumption ensures that complex runs cannot exceed predefined cost thresholds.
- Wall-clock timeouts: Setting hard elapsed time limits terminates operations that hang on long-running compilation or test commands.
- Repeated failure thresholds: Halting after consecutive failed invocations of the same tool prevents repetitive trial-and-error spirals.
- Interactive interrupts: Giving developers keyboard interrupts (such as pressing escape) provides immediate manual control over runaway execution.
Set every limit before you start the run.
- Set a maximum number of turns.
- Set a maximum token budget for the run.
- Set a wall clock timeout.
- Stop the run after three consecutive failures of the same tool.
- Write the transcript to a file.
- Run the harness in a sandbox. Give write access to one directory only.
Failure modes in extended agent runs
Prolonged autonomous runs introduce specific failure modes that do not appear in single-turn interactions:
Compounding errors: If a model introduces a subtle flaw—such as hallucinating a method name or misinterpreting a test fixture—subsequent turns will read that code back from the filesystem as ground truth. Lacking out-of-band awareness, the model treats its own earlier mistakes as established architectural patterns, spreading the error across other files. Grounding the agent in external, deterministic verification—such as running linters, compilers, and test suites whose outputs cannot be hallucinated—is the primary safeguard against compounding mistakes.
Context drift and goal loss: As an agent explores a large codebase, thousands of tokens of intermediate command output can push the original user prompt out of the model's immediate attention window. An agent tasked with fixing a minor bug may drift into refactoring unrelated utilities. Mitigation strategies include periodic task re-anchoring, preserving the user goal in protected system prompt regions that bypass compaction, or decomposing expansive tasks into discrete, modular subagent runs.
Selecting the right harness involves evaluating how well each system balances autonomous execution with safety controls. Comparing harnesses analyzes the trade-offs across current tools.
Terms introduced
- Harness: the program between you and the model API that assembles context, runs tools, enforces permissions, and keeps the loop going.
- Agentic loop: the cycle of calling the model, running the tools it asks for, appending the results, and calling again until it stops asking.
- Turn: one pass through that cycle. One model call plus whatever the harness does with the answer.
- Permission model: the rules deciding which tool calls run silently, which need your confirmation, and which are refused.
- Subagent: a nested loop with its own context window, given one task and returning only its result.
- Stop condition: a limit that ends a run whether or not the job is finished, such as a turn cap, a token budget, or a timeout.
- Sandbox: an enforced boundary around tool execution, covering the files a tool may read or write and the hosts it may reach.
How providers do it
Both APIs stop when the model asks for a tool and hand the work back to the caller. The names differ and the stop conditions differ a lot.
| The loop | Anthropic | OpenAI |
|---|---|---|
| Model asks for a tool | stop_reason: "tool_use" plus tool_use blocks | output item "type": "function_call" |
| Result goes back as | tool_result with tool_use_id | "type": "function_call_output" with "call_id" |
| Next call carries history by | resending the messages | previous_response_id |
| Prebuilt harness | Claude Agent SDK, Claude Code | Codex |
| Headless invocation | claude -p, or the Agent SDK | codex exec |
| Turn limit | max_turns / maxTurns | not found in the docs read |
| Spend limit | max_budget_usd / maxBudgetUsd | not found in the docs read |
| Permission model | permission mode, plus allow and deny rules | approval_policy |
| Sandbox | OS isolation for Bash commands | sandbox_mode, defaulting to workspace-write |
| Automatic compaction | yes, marked by a compact_boundary message | yes, at model_auto_compact_token_limit |
Every cell above is confirmed against the vendor's own documentation, except the two "not found" rows, which are open questions rather than a claim that the feature is absent.
The row that changes how a run is designed is the turn limit. Anthropic's harness will stop itself at a number you set; on OpenAI's, the cap read on the pages above is the sandbox rather than a count, so a run that keeps retrying a failing tool has to be stopped by whatever launched it.
- Anthropic
- OpenAI
What this maps to: the Messages API does not run the loop. It returns a tool_use block and stops, and the caller runs the tool and calls again. Anthropic also ships the loop twice over: as the Claude Agent SDK, a library for Python and TypeScript, and as Claude Code, the harness built on it.
| Question | Answer | Status |
|---|---|---|
| How does the model ask for a tool? | The response carries stop_reason: "tool_use" and one or more tool_use content blocks | confirmed |
| How does the result go back? | A tool_result block quoting the matching tool_use_id, in the next request | confirmed |
| Does the API ever run the tool? | Client tools, no. Server tools such as web_search, web_fetch and code_execution run on Anthropic's infrastructure and return results in the same response | confirmed |
| Is there a loop written for you? | Tool Runner in the SDKs executes the tools and sends the results back automatically | confirmed |
| What is a turn called? | A turn: model output with tool calls, SDK executes them, results feed back. The loop ends when Claude produces output with no tool calls | confirmed |
| Turn limit | max_turns / maxTurns. Counts tool-use turns only. No limit by default | confirmed |
| Spend limit | max_budget_usd / maxBudgetUsd. Subagent spend counts toward it | confirmed |
| Wall clock limit | No wall clock option appears in the agent loop reference read. Open question | unconfirmed |
| How does a run report why it stopped? | ResultMessage.subtype: success, error_max_turns, error_max_budget_usd, error_during_execution | confirmed |
| Permission model | permission_mode / permissionMode, one of default, acceptEdits, plan, dontAsk, auto, bypassPermissions, evaluated together with allowed_tools and disallowed_tools | confirmed |
| What happens on a denial? | Claude receives a rejection message as the tool result and usually tries another approach | confirmed |
| Subagents | Supported. A subagent starts with a fresh conversation, does not see the parent's turns, and returns only its final response as a tool result | confirmed |
| Compaction | Automatic as the window approaches its limit. A system message with subtype: "compact_boundary" marks it | confirmed |
| Sandbox | Operating system level filesystem and network isolation for Bash commands, configured separately from the permission rules | confirmed |
| Transcript | Sessions are written to disk and can be resumed or forked by session ID | confirmed |
Their vocabulary
| Standard term | Their term |
|---|---|
| Agentic loop | Agent loop |
| Turn | Turn, counted as tool-use round trips |
| Stop condition | Max turns, max budget, reported as a result subtype |
| Permission model | Permission mode, plus allow and deny rules |
| Subagent | Subagent |
Where to look
The ResultMessage at the end of an SDK run carries subtype, num_turns, total_cost_usd and session_id, which answers what stopped the run and what it cost. In Claude Code, /context shows what is in the window and /usage shows the session's token and cost totals.
Last verified: 2026-09-09 against https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview and https://code.claude.com/docs/en/agent-sdk/agent-loop and https://code.claude.com/docs/en/permissions.
What this maps to: the Responses API returns a function call as an output item and stops. The caller runs the function and sends the output back on the next request. Codex is OpenAI's own harness around that loop, and it is the place where the approval and sandbox decisions are made.
| Question | Answer | Status |
|---|---|---|
| How does the model ask for a tool? | An output item with "type": "function_call" | confirmed |
| How does the result go back? | An input item with "type": "function_call_output", carrying the matching "call_id" | confirmed |
| How is the next turn chained? | previous_response_id on the following request, so the history does not have to be resent | confirmed |
| Prebuilt harness | Codex, on a CLI, an IDE extension, a desktop app, ChatGPT on the web, and a cloud environment | confirmed |
| Running the loop with nobody watching | codex exec "<prompt>", for pipelines and repeatable workflows | confirmed |
| Permission model | approval_policy, set to on-request, never, or a granular policy that keeps some prompt categories interactive. untrusted is no longer supported | confirmed |
| Approval flag | --ask-for-approval <mode>, short form -a | confirmed |
| Sandbox | sandbox_mode, one of read-only, workspace-write (the default) and danger-full-access | confirmed |
| Sandbox network and paths | [sandbox_workspace_write] with network_access and writable_roots | confirmed |
| Turning everything off | --dangerously-bypass-approvals-and-sandbox, aliased --yolo. --full-auto is deprecated and warns | confirmed |
| Recommended CI invocation | codex exec --sandbox workspace-write | confirmed |
| Compaction | model_auto_compact_token_limit in the config file sets the point at which the conversation is compacted | confirmed |
| Turn limit or wall clock | No turn cap or wall clock key appears in the configuration reference read. Open question | unconfirmed |
| Subagents | Not covered on the pages read. Open question | unconfirmed |
| Transcript | history.persistence controls whether the transcript is saved | confirmed |
Their vocabulary
| Standard term | Their term |
|---|---|
| Tool call | Function call, as an output item |
| Permission model | Approval policy |
| Sandbox | Sandbox mode |
| Headless run | codex exec |
Where to look
~/.codex/config.toml holds the approval and sandbox keys for every project, and a .codex/config.toml inside a trusted project overrides them. Read both before deciding what a CI run is allowed to do.
Last verified: 2026-09-09 against https://developers.openai.com/api/docs/guides/function-calling and https://learn.chatgpt.com/docs/config-file/config-reference.md and https://learn.chatgpt.com/docs/agent-approvals-security.