TECHNICAL GUIDE
What Runs an AI Agent?Understanding Harnesses, Runtimes, and the Codex Loop
An agentic AI system can pursue a goal, take actions, examine the results, and adjust what it does next. In our article, What Is Agentic AI?, we described that behavior as a loop:
Plan → Act → Observe → Check evidence → Update state → Repeat
But what actually keeps that loop running?
When an AI system decides to run a test, something must execute the command. When the test fails, something must return the failure to the model. When the work continues, something must preserve enough context for the next step.
That surrounding software is commonly called an agent harness.
Understanding the harness connects the concept of agentic AI to the tools people already use. It also clarifies what must be built—or adopted—when creating an agent.
The model and the harness have different responsibilities. The model interprets the task, reasons about the available information, and proposes actions. The harness coordinates model calls, routes tool requests, returns results, and maintains the running session. OpenAI’s architecture documentation separates this harness from the environment where commands and code execute. OpenAI’s agent architecture
From a Model Response to an Executed Action
Consider a familiar request:
Review this pull request and fix any bugs you find.
The model might decide to inspect the changed files. It produces a request to use a file-reading or shell tool. The harness routes that request to the appropriate executor and returns the output.
The model then decides whether to inspect more code, run tests, or propose a change. Each result becomes information for the next decision.
A simplified execution cycle looks like this:
- Assemble the task, instructions, context, and available tools.
- Ask the model for its next response.
- If it requests a tool, check the applicable permissions and execute or route the request.
- Return the result to the model.
- Continue until the work completes, pauses for input, encounters a stopping condition, or reaches a limit.
Now follow what moves between these components during a task.
Requests, results, and context
The harness runs the execution cycle. The model chooses actions within the choices and boundaries the system provides.
Those boundaries also depend on the tools and environment. A database tool can enforce read-only access. A sandbox can restrict files or network connections. An approval requirement can prevent a requested action from executing until it is authorized.
Writing a restriction in a prompt and enforcing it through software are different responsibilities. The harness, tools, and infrastructure need to support the intended limits. OpenAI’s harness and sandbox boundaries
How the Harness Relates to the Agentic Loop
Our agentic-loop diagram describes this same activity at a different level.
| Agentic-loop concept | What happens in the running system |
|---|---|
| Plan | The model interprets the objective and selects a next action. |
| Act | A tool request is executed through the harness and connected infrastructure. |
| Observe | Tool output becomes available to the model. |
| Check evidence | The system evaluates whether the result supports the requested outcome. |
| Update state | Findings, actions, and remaining work are retained for subsequent steps. |
| Repeat, finish, or escalate | The system continues, returns a result, or pauses for another decision. |
These stages explain behavior. They do not require six separate software components or a rigid sequence of model calls. Planning and evidence assessment might happen within one response. A task might need several tool calls before a meaningful result can be assessed.
The bottom bar in our earlier diagram—instructions, context, tools, permissions, and memory/state—shows the resources supplied to the agent. The harness connects those resources to the running loop.
The execution environment is another piece. For a coding task, that might be a local checkout or a remote sandbox containing files, dependencies, and a test runner. An agent that only calls external services might not need a dedicated filesystem or shell environment. OpenAI’s environment options
The Codex Loop in Practice
Codex provides a concrete example of these pieces working together. OpenAI describes its working loop as planning, editing code, running tools, observing results, repairing failures, updating progress, and repeating. Repository files, diffs, command output, and other artifacts help it maintain context over the task. The Codex loop
Return to the PR-review example. A test failure can change what Codex does next. It may inspect the failing implementation, make a change, rerun the test, and investigate a new failure. The sequence emerges from the evidence and the task’s constraints.
In Codex, those exchanges support the same agentic loop we introduced earlier.
The Codex loop
The agent might also find no bugs. In that case, a useful result would explain what it inspected, which checks it performed, and what remains uncertain. The goal is to satisfy the request with supporting evidence.
State is essential to this process. A model cannot use a result that has not been made available to it. Long-running work therefore needs ways to preserve useful information: conversation history, summaries, progress records, files, or other durable storage.
Updating that state does not mean retraining the model. It means making relevant history available when work continues. Anthropic’s work on long-running harnesses illustrates how progress artifacts and clear handoffs help agents continue across sessions. Effective harnesses for long-running agents
Choosing an Agent Runtime
Does building an agent mean building all of this yourself?
You need an execution mechanism, but you can adopt one.
If you use an existing agent product such as Codex, the runtime is already provided. Your work focuses on defining the task, supplying context and access, configuring boundaries, and reviewing results.
If you are building an agent into your own application, you can choose how much of the runtime to own. Here, runtime means the software that operates the agent while it works; the harness is the part coordinating its model-and-tool loop.
Building an agent means choosing how much of this execution machinery you want to operate.
Who operates the loop?
| Approach | Who operates the loop? | What you take responsibility for |
|---|---|---|
| Existing agent product | The product supplies the runtime. | Define tasks, provide context and access, configure boundaries, and review results. |
| Managed agent runtime | The provider operates the harness. | Configure the agent and connect it to your product, tools, and data. |
| Agent SDK | A reusable runner operates inside your application. | Integrate the runner and manage deployment, storage, and application-specific controls. |
| Custom loop | Your code coordinates model calls and tool execution. | Implement the orchestration, state handling, permissions, recovery, and stopping behavior you need. |
Within OpenAI’s current offerings, the Agents API provides a managed Codex harness, the Agents SDK provides a runner inside your application, and the Responses API offers a lower-level foundation for your own integration. These choices differ in where execution is managed and how much infrastructure your team owns. OpenAI’s runtime comparison
Defining What Done Means
Whichever route you choose, the application still needs a well-defined job. It needs relevant context, useful tools, appropriate permissions, and a way to assess success.
For the PR-review agent, “done” might require examining the requested changes, resolving confirmed bugs, running relevant checks, and reporting anything that remains unverified. Passing tests provide evidence, but their value depends on what those tests actually cover.
A harness can coordinate the work and enforce selected checks. The quality of the result still depends on the model, the tools, the context, and the evidence available.
That is the practical connection between the diagram and a working application: the agentic loop describes how the system makes progress; the harness provides the machinery through which that progress happens.