What is an agent harness? Execution loops and state management around a model
How harnesses connect models, tool execution and task state, with cross-session progress, recovery and approvals distinct from models and multi-agent orchestration.
Understand the concept
An agent harness is runtime software around a model that organizes task loops and tool execution. After the model proposes a step, the runtime invokes the environment, maintains state from results and handles needed approvals and recovery. It is software rather than another foundation model. Different tools and state management can change the behavior of the same model.
A tool call needs actual execution and returned feedback
A file-read proposal still needs software to identify the call, execute it and return the result to the right task. Failures must not silently become successes. The harness manages continuation, stopping and human intervention across these steps rather than merely concatenating chat text.
Execution can occur locally, in containers or elsewhere. The harness needs actual working material and available tools; a path string is not an existing file. Strong models do not make tool requests execute without an executor.
Long tasks need records of completed work
Anthropic’s long-task design initializes an environment and maintains feature and progress records for later sessions. New sessions can recover context rather than restart or prematurely declare completion. This is one design, not a required filename or two-stage architecture for every harness.
Progress labels must correspond to checks, and recovery must inspect changed environments. A summary can omit failures, and Git does not restore external business state automatically. Define recoverable state and handling of unconfirmed operations across sessions.
Products can reuse one harness through different interfaces
OpenAI exposes the Codex harness as reusable execution software, with integrations for conversations, events and approvals. Desktop clients are one form; the runtime can serve other task applications. Reuse does not automatically grant every tool or credential to the integrating app.
This separation allows model and execution policies to be configured independently with inspectable processes. Retain links between calls and results and useful failure states rather than only a generic error. Check integration support against the selected version.
Separate orchestration and model responsibilities
Models reason and generate, while harnesses execute and manage state. Multi-agent orchestration distributes work among roles and may be part of a harness, but does not constitute the complete runtime. Several role prompts do not establish recovery, approval or bounded execution.
Trace requests, environment returns and stopping conditions. Missing tool feedback or endlessly repeated failures may be harness defects rather than model defects. Find the actual state or message-handling gap before assuming a model switch will repair it.
Checked sources
These sources support the concepts and methods described here. Examples and test scope are labeled separately; check the version of the tools you use.