The next chapter in the Agents SDK's evolution

If you're a developer building AI agents that run for hours, touch multiple tools, and handle real files, OpenAI's latest Agents SDK update deserves your attention. The company has rolled out native sandbox execution alongside a model-native harness, two changes designed to make it easier to build agents that are both secure and capable of running over extended periods without breaking.

This article walks through what changed, why sandboxing matters for agent safety, and what the update means for teams shipping agent-powered products.

What the Agents SDK Update Includes

The Agents SDK is OpenAI's toolkit for developers who want to build agentic applications — software where a model can plan, call tools, and act on results over multiple steps. The new update brings two headline features:

Native sandbox execution. Instead of letting agents run code directly on your infrastructure, the SDK now supports executing code inside an isolated sandbox environment. This means any code an agent writes and runs stays contained, separated from your production systems, sensitive data, and the wider network.

A model-native harness. The update also introduces a harness built around the model itself, giving agents a more structured way to manage their own execution loop. In practical terms, this helps agents stay organized and consistent across long sessions — think of it as scaffolding that keeps the agent on track as it moves between reasoning steps, tool calls, and file operations.

Together, these features aim at the same goal: letting developers build agents that can work autonomously for longer stretches without exposing their systems to unnecessary risk.

Why Sandboxing Matters for Agent Safety

Autonomous agents introduce a specific security problem that traditional apps don't have. When a model can write and execute its own code, you're essentially running output you didn't fully review. If an agent hallucinates a dangerous command, or if a prompt injection tricks it into misbehaving, the consequences land on whatever system that code runs on.

A sandbox solves this by creating a contained environment where agent code can execute safely. Files the agent creates stay inside the sandbox. Network access can be restricted. System resources are limited. If something goes wrong, the damage is contained rather than cascading into your production environment.

For teams that have hesitated to deploy agents on real workloads because of these risks, native sandbox support removes a significant blocker. You no longer need to build and maintain your own isolated execution environment — a genuinely hard engineering problem involving containers, resource limits, and network policies.

Building Agents That Work Across Files and Tools

The other half of the update focuses on making agents better at multi-step, multi-tool work. Modern agents rarely do just one thing. A research agent might search the web, download documents, extract data into files, run analysis scripts, and produce a summary. Each of those steps involves different tools and different failure points.

The model-native harness addresses this by giving the agent a more reliable structure for coordinating these steps over time. Long-running sessions are where agents tend to fall apart — context gets muddy, instructions drift, and tool calls get out of sync. A harness designed around the model helps maintain coherence across hundreds or thousands of steps.

For developers, the practical benefit is fewer bespoke workarounds. Teams building agent products have historically written a lot of custom orchestration code to handle retries, state management, and step sequencing. Having this handled closer to the model layer means less glue code to write and maintain.

What This Means for Developers

If you're already using the Agents SDK, the update is worth exploring for two reasons. First, sandbox execution lets you expand what your agents are allowed to do. Code execution has always been one of the most powerful agent capabilities — and one of the riskiest. With native sandboxing, you can offer it without the same level of infrastructure investment.

Second, the harness improvements make long-running agents more viable as products. Use cases like overnight research tasks, multi-hour coding projects, or continuous monitoring workflows become more practical when the execution environment is designed for them from the start.

If you're evaluating agent frameworks more broadly, this update strengthens OpenAI's position in a competitive field. Alternatives like LangChain, CrewAI, and various open-source frameworks each take different approaches to orchestration and tool use, and the right choice depends on your stack and requirements. Native sandboxing, however, is a meaningful differentiator for teams where security review is a hard requirement.

As always with newly shipped developer features, it's wise to test the sandbox behavior against your own threat model. Isolation quality, resource limits, and network policies are details worth verifying directly rather than assuming.

Getting Started

Developers with an existing Agents SDK setup can start experimenting with sandbox execution by checking the updated SDK documentation for configuration details. If you're new to the SDK, OpenAI's docs cover the basics of defining agents, wiring up tools, and running the execution loop — and the new sandbox options slot into that same workflow.

The sensible path is to take an existing agent prototype, enable the sandbox, and observe how behavior changes under the harness before rolling anything into production. Long-running agent behavior is hard to predict on paper, so real testing is essential.