From model to agent: Building a computer environment for the Responses API

If you've been curious about how OpenAI actually runs AI agents safely at scale, this article is for you. We'll walk through the three core pieces of OpenAI's agent infrastructure—the Responses API, the shell tool, and hosted containers—and explain how they work together to let agents handle files, use tools, and maintain state across steps without compromising security or performance. No deep engineering background required.

The Challenge: Agents Need More Than a Chat Endpoint

Running an AI agent is fundamentally different from answering a single question. An agent works in loops: it plans an action, executes it, looks at the result, and decides what to do next. Along the way, it may need to write and read files, run code, call external tools, and remember everything it has done so far in a session.

Traditional chat APIs weren't designed for this. They handle a single request-and-response exchange, leaving developers to stitch together their own infrastructure for file storage, tool execution, and conversation state. That means every team building an agent has to solve the same hard problems: How do you let a model execute code without putting your systems at risk? How do you keep files available between steps? How do you track multi-turn state without rebuilding it from scratch every time?

OpenAI's answer is a purpose-built agent runtime—a managed environment where agents can operate with real resources while staying contained and secure.

The Responses API: A Single Entry Point for Agent Workflows

At the heart of this system sits the Responses API. Think of it as the control plane for agent interactions. Instead of treating every model call as an isolated event, the Responses API is designed to support the back-and-forth nature of agentic work.

The key idea is that state becomes a first-class concept. Rather than developers manually resending the full conversation history with each request, the API can reference and build on prior context. This matters enormously for agents, which often take dozens or hundreds of steps to complete a task. Each of those steps produces output that the agent needs to reason about later.

The Responses API also provides a unified way to wire up tools. Whether an agent needs to search, execute code, or interact with files, the tool-calling mechanism flows through the same interface. This reduces the glue code developers have to write and makes agent behavior more predictable and easier to debug.

The Shell Tool: Giving Agents Hands Without Giving Them Keys

An agent that can only produce text is limited. Real tasks—analyzing a dataset, processing documents, running scripts—require the ability to actually execute commands. That's where the shell tool comes in.

The shell tool lets the model issue commands and receive their output as part of its workflow. The agent can inspect files, run programs, install dependencies, and iterate on its work based on what the commands return. This tight feedback loop is what makes agentic behavior genuinely useful: the model doesn't have to guess whether its code works, because it can run it and see.

Of course, handing an AI model the ability to execute arbitrary shell commands raises an obvious question: isn't that dangerous? If an agent runs on your laptop or your company's servers, a flawed command could delete files, expose data, or break things in ways that are hard to undo. OpenAI's solution to this problem is the third piece of the puzzle.

Hosted Containers: Sandboxing as a Design Principle

OpenAI runs agent workloads inside hosted containers—isolated, managed environments where the agent's actions take place. Instead of executing commands on the developer's own infrastructure, the runtime spins up a sandboxed container that the agent can work in freely.

This design has two major benefits.

Security through isolation. Because everything happens inside a container, the blast radius of any mistake is contained. An agent can't touch your production systems, your local files, or anything outside its sandbox. The container acts as a boundary between what the agent can do and what actually matters to you.

Scalability without the operational burden. Running secure sandboxes yourself is genuinely hard. You need to provision environments, manage their lifecycle, clean up after sessions, and scale capacity up and down with demand. By hosting the containers, OpenAI takes that operational weight off developers' shoulders. Teams can spin up agent sessions on demand without maintaining their own sandbox fleet.

Files, Tools, and State: The Full Picture

Put the three pieces together and you get a complete runtime for agentic applications:

• Files live in the managed environment, so an agent can upload, create, modify, and read documents across multiple steps of a task without developers manually shuttling data in and out.
• Tools are invoked through a consistent interface, with the shell tool as the standout example, letting agents take real actions rather than just describe them.
• State persists across the agent's workflow through the Responses API, so long, multi-step tasks don't collapse because the model lost track of what it had already done.

This combination addresses what is arguably the hardest part of shipping agents in production: making them capable enough to do real work while keeping that work contained, observable, and repeatable. An agent that can execute code but can't be trusted is a liability. An agent that's safe but can't act is a toy. The runtime approach aims for the middle ground—real capability inside firm boundaries.

Why This Approach Matters for Developers

For teams building agent products, the significance of this architecture is that it shifts the hard infrastructure work from the developer to the platform. You no longer need to design your own sandboxing, build your own state management, or figure out how to give a model safe access to a filesystem. The building blocks—API, tool, container—are provided as a coherent whole.

It also signals where the industry is heading. As agents move from demos to production, the winners won't just be the teams with the smartest models, but the ones with the most reliable runtime: environments where agents can work for long stretches, recover from errors, and operate within clear security boundaries.

OpenAI's agent runtime—Responses API, shell tool, and hosted containers working in concert—represents a bet that the future of AI applications is agentic, and that the platform layer, not just the model layer, is where that future gets built. For developers, that's good news: the plumbing is increasingly handled for you, so you can focus on what your agent should actually do.