OpenAI's Agents API is a harness. ARC is a new kind of computer for agents

On 10 September 2026, OpenAI published Introducing the Agents API. The subtitle is one line:

Build and run cloud agents with the Codex harness, fully managed by OpenAI.

Harness is the word to keep. A model only continues text. To keep it working, something around it has to feed the task and the files, call tools, read the result, feed that back, compact the context when the window fills, and split oversized work onto subagents. That surrounding loop is what Codex has been running. The Agents API does a concrete thing: it takes that loop, hosts it, and exposes it as an HTTP API.

I think this release is worth a careful reading. Not because the industry got another "agent platform," but because the docs now say out loud how the loop, the environment, and the application are supposed to split. Once a split is public, you can talk about what each layer is for, where it stops, and where something else should plug in.

Last month we wrote Agents don't need a better sandbox. They need a computer of their own.. After reading the Agents API docs, I am more sure that split was the right one. They productized the harness. The computer is a different layer. ARC is that layer, and it can attach at the interface they already opened.

Four pieces, and that is the whole API

The developer docs reduce the Agents API to four concepts: Agent, Environment, Session, and Events. In ordinary language:

Agent is which model, which instructions, which tools. Environment is where its hands go: the machine that reads files, runs commands, and loads skills. It can be absent, an OpenAI-hosted sandbox, or codex exec-server on a machine you run. Session is the durable instance of that agent; work can continue across turns without restitching the conversation. Events are the process: streams, webhooks, a way to steer mid-flight.

The architecture page draws the duty line more cleanly. OpenAI runs the harness: the model loop, tool dispatch, session state, context compaction. Your application submits work and receives events. If the agent needs files and a shell, you attach an environment. Their sentence:

OpenAI manages sessions, orchestration, context compaction, and recovery while your application provides tools and chooses its execution environment.

That is an interface, not a slogan. One POST /v1/agents/sessions asks you to fill in roughly this: the model, the instructions, the tools (MCP, built-in search, programmatic tool calling), whether to fan out subagents, which environment, and the first task. They run the rest of the loop.

The sandbox choice is real. Hosted environments reuse the isolation that already sits under Codex and ChatGPT. Self-hosted runs an executor in your environment; it connects outbound, receives commands, returns results. Plugins are the third insert: a package of skill directories plus MCP config, uploaded as a ZIP to a hosted sandbox, or pointed at from capability_directories. A skill is instructions the model can load. MCP is a socket. A plugin binds the two so a session starts with those capabilities already in the environment.

So the Agents API is not "an agent." It is a hosted Codex loop, plus a replaceable workspace, plus a packaging format that drops instructions and sockets into that workspace. The top-level object is a session. Files live under /workspace. Identity is an organization, a project, and an API key.

What that layer is worth

Say first what it fixes. For a couple of years, a lot of teams wrote their own prompt chains, their own tool-call managers, their own compaction, their own subagent graphs. That work is glued to the model: change the model, and the harness often has to change with it. OpenAI said this plainly. New model abilities often need harness changes, so they keep the harness next to the model and version it as an API. You do not have to keep a private copy of the loop.

Looked at one by one, the capabilities hold up. Automatic compaction carries work across a single context window without you inventing a summary policy. Tool search loads tool definitions on demand, instead of stuffing every schema into the prompt. Programmatic tool calling lets the agent fan out calls in code, filter the results, and bring only what matters back into the narrative. Multi-agent hands independent subtasks to subagents that keep their own context. This is engineering for long jobs that otherwise fall over. It is not a slogan.

Sandboxes and plugins earn their keep too. Incident work, a repo, a report: the agent needs somewhere to run commands, touch files, and leave intermediate artifacts. Packaging skills and MCP as a plugin means the same capability can show up in Codex, in ChatGPT, and in this API. If you ship tools, that is a clear distribution surface.

You might think: then this is the agent platform. From "I just want it to run," yes. One API call and you have a loop, files, tools, subagents. For a lot of one-shot work, that is enough. Generated Python, a log hunt, a release-note comparison: you do not first need a long-lived computer.

Where it stops should be read from the docs, not from a wish. The harness remembers a session. The sandbox offers a POSIX workspace. The plugin teaches the model which tools to use in that workspace. Root identity comes from a platform account. Even if you pick a self-hosted environment, the docs are explicit: session state still lives on the API side; that choice does not make the Agents API Zero Data Retention. Put differently: the hands can live on your machine. Memory and orchestration remain their service.

That is not a verdict. It is the layer they chose to host. Short jobs, disposable workspaces, a platform account as root: the abstraction matches. In the August piece we called this layer a box: execution material. The Agents API makes the box easier to use and easier to plug. It also makes "the box is not the computer" easier to point at.

A computer answers a different set of questions. Who does this action stand for? Which tree does it see, rather than the whole disk? Is permission a decaying, revocable grant, or a long-lived key in an environment variable? When the job finishes, do the files, the identity, and the history sit with the owner, and are they still the same machine if the harness is swapped? A session and /workspace do not have to answer those. They do not.

Plug ARC into the seam they already cut

If the interface is already split, the join belongs on the seam. It does not belong in "stuff the whole computer into the sandbox."

We call that machine ARC: an Agentic Realm Computer. Underneath is AFS: databases, tools, and memory mounted as paths. People and agents see the tree projected for them; what is outside that tree is not there. Identity is a DID, so the actor stays the same across devices and runtimes. Apps install on that machine as blocklets, which are just bounded, deployable units. The CLI is arc. It was a client from day one: in arc deploy --server, the server is the computer. A process inside a sandbox is not.

So the join is almost the diagram they already published. Their figure has three boxes: the application sends tasks, the Agents API runs the harness, the sandbox handles commands and files. We attach after the third box. The last hop is not "write into /workspace." It is "write into production ARC."

The first three boxes follow OpenAI's published architecture diagram. The fourth is where we sit: the sandbox runs the plugin and arc CLI; identity, AFS, and deploy land on production ARC. The dashed line is still their self-hosted compute.

An app, Codex, or ChatGPT submits a task. The Agents API runs the harness: compact, find tools, split subagents. When the harness needs hands, it reaches into the sandbox you chose. That sandbox loads an ARC plugin: skill instructions, plus arc mcp as the socket. MCP here is only a transport into the same AFS world. Inside the sandbox the agent looks like it is calling tools. The landing is still paths and permission. Then arc deploy --server ships the artifact to production ARC. The session can end. The machine is still there.

Flip who is the computer and who is the hands, and the join becomes a different product: install the ARC runtime into their /workspace, and let the session be the computer. That demotes an OS to a process inside someone else's loop. An Agents API sandbox is an execution environment for a job. It is not a DID Space, not a long-lived blocklet, and not an identity that stays continuous if you change operators. What actually fits in that box is usually a subset of the CLI. That subset is what the outside world will think ARC is.

The right way around, ARC fits this architecture for a mechanical reason, not a rhetorical one. They want a plugin; we have skill booklets and arc mcp. They want commands in the environment; we have the arc binary. They want files and intermediate artifacts; AFS already treats databases, tools, and memory as paths. They turned the long loop into something you can plug in; we were not going to rebuild compaction and subagent orchestration anyway. The missing piece is auth in a hosted sandbox. Today's CLI still likes to open a local browser to collect credentials. There is no user browser on OpenAI's VM, and a plugin archive must not carry secrets. A short-lived capability goes into an environment variable. The user finishes DID Connect on their side. The sandbox holds a scoped token and talks to production. That is an engineering problem, and it sits on bearer_token_env_var, which they already documented.

The boundary has to stay honest. The plugin is packaging we are building. It is not an install button in the public directory. AFS, the arc CLI, arc mcp, and arc deploy --server are current. Turning them into a plugin the Agents API understands, and getting auth right in a hosted sandbox, is the layer being wired now. For a short job, their hosted sandbox is the right tool; you do not first move into ARC. ARC starts to matter when an agent has to stand for you over time, leave state across tools, and you care whether the identity and the history are yours.

The default picture in the market will be "an agent that can run for a long time." The Agents API will make that picture easy. The sentence to hold onto is smaller. The loop can be a commodity. The computer cannot be thrown away with the session.

They took the Codex harness and made it an API, with official interfaces for the loop, the files, and the plugin. That is good. The box will get easier to use. Join it at the seam they already cut, and an agent can have a pair of maintained hands and a computer that still has a name.

References