What Is a Harness? The Agent, The Model, the Harness, and the Sandbox

An agent harness is the program that turns a model's decisions into action. The model decides what should happen next and emits a response or a tool call. It does not run the command, touch the filesystem or call the API. The harness executes the action, returns the result, and decides whether to continue or stop. OpenAI's harness is called Codex.

The easiest way to hold this is to think about a worker.

The agent is the worker. The model is the thinking: it decides what should happen next, and deciding is all it does. The harness is the doing: it carries out each decision, keeps the notes so that hour three still knows what happened in hour one, and calls time when the job is finished or going wrong. The sandbox is the workspace.

Five words get used for this stack and they slide around, so here is the map.

Term	In the worker picture	What it is
Agent	The worker	The whole thing doing the job, rather than a layer inside it
Model	The thinking	Decides what should happen next and emits a response or tool call. Does not act
Harness	The doing	Runs the loop, executes each tool call, keeps the memory, enforces the limits
Sandbox	The workspace	The isolated machine where generated code actually runs
Framework	The template the job was set up from	Abstractions for building one, such as LangChain or the OpenAI Agents SDK

Vendors carve this up differently, so the words are worth pinning down rather than assuming. OpenAI's Agents API treats the agent as the model plus its instructions, tools and MCP servers; Anthropic describes session, harness and sandbox as separate pieces. The map above is the one this post uses.

Two shortcuts to keep. If swapping the thinking underneath would leave it still working, you are talking about the doing. And workers get sent home mid-shift, which is why what is left on the workspace matters more than who was standing at it.

What does the harness actually do?

Four jobs.

1. It runs the model in a loop. A model answers once and stops. A harness keeps it working step after step: send the current state, read the tool call that comes back, execute it, feed the result in, decide whether to go again.

2. It gives the model hands. Reading files, calling tools, querying APIs, running code. The model names the action; the harness performs it.

3. It manages memory. This is the one people underestimate. A job that runs for three hours has to still know at hour three what happened at hour one. Long jobs eventually exceed the useful context window, and resending the full history on every turn gets expensive well before that. So the harness compacts, summarises, writes things down and reads them back. LangChain's stated promise for its runtime is blunt about the requirement: the agent should survive a server restart.

4. It enforces the rules. What the agent is allowed to touch, what needs a human approval before it happens, and when to stop: because the job is done, because it is stuck, or because the budget is spent. Deciding when an agent is finished and when it is about to do something expensive is genuinely hard, and none of it is a model problem.

Harnesses you have heard of: OpenAI's Codex, Anthropic's Claude Code, Cursor, and a long tail teams build in-house.

OpenAI published its own breakdown of what sits inside the Codex harness in February 2026, and it is worth reading as a parts list. Beyond the agent loop itself they name three things: thread lifecycle and persistence, config and auth, and tool execution in a sandbox. A thread, in their description, is "the durable container" for a session, and thread history is persisted so that a client can reconnect and pick up a consistent timeline. Persistence runs through the whole architecture: in the durable thread history, and in the environment where the agent does its work.

Is harness something new?

You might be wondering, if the harness is a new thing, where did agents come from before it? The harness is not new; the word is. Every agent that has ever worked had one, because something always had to run the loop and execute the tool calls. Until recently every team hand-rolled it, buried it inside whatever they called "the agent code," and threw it away with the project. What changed in 2026 is that the layer got named, standardised, and sold.

• OpenAI's Agents API, public beta Sep 10 2026. The managed Codex harness: sessions, context compaction, multi-step recovery, subagent delegation, all server-side. Run it on an OpenAI-hosted sandbox or connect an execution environment of your own.
• Vercel's eve, open source since Jun 17 2026. File-system-first, so an agent is a directory of files. Durable execution, checkpointed sessions and sandboxed compute, built in.
• LangChain's LangGraph, the durable runtime with checkpointing and stores, in production at Lyft, Replit, Uber and LinkedIn. DeepAgents is the harness on top and connects to sandbox backends you choose. One caution: the OpenAI Agents SDK and Agents API are different products one letter apart, and only the API is a managed harness.
• Anthropic, managed agents running harness and sandbox as a hosted service.

They package it differently, and not every configuration includes every piece. But they converge on the same production requirements: durable session state, recoverable execution, and a controlled environment for tools. All of them need somewhere reliable to hold state.

Duration is what makes that choice expensive

Inside a sandbox: an isolated execution environment, usually made for one task and disposable when it ends, from Modal, E2B, Daytona, Vercel, Cloudflare or your own Kubernetes. Even the managed harnesses leave that a choice, OpenAI's included.

Duration is what makes that choice expensive. A sandbox that dies thirty seconds into a job costs nothing; you start again. A sandbox that dies seven hours in costs seven hours, and you pay for them twice: once in the tokens already spent, once in the compute to do the work again. As agents move from minutes to hours to overnight, the question quietly changes from how fast a sandbox starts to what is left when it stops without warning.

So the question to ask a vendor is not whether they persist. It is what survives a kill nobody scheduled.

Nirvana keeps the workspace on a networked volume that was never part of the compute. Quirq killed the process mid-checkpoint and rebuilt the pod under a new UID: all 5,501 committed checkpoints came back. E2B gives you no way to simulate the host dying, so it was tested with the one destructive operation it does offer, terminating the sandbox, which takes the local disk with it: 0 of 5,000, with no pause called. E2B's pause and snapshots were not part of the test, and calling pause does save your state.

Machines die. Agents die. The work shouldn't.

Spin up persistent, isolated, fast sandboxes on Nirvana: docs.nirvanalabs.io/cloud/compute/agent-sandboxes