Native Sandboxes and the Model-Native Agent Loop: What OpenAI's SDK Update Is Actually Doing

Most agent frameworks started the same way: wrap the chat completions API in a while loop, intercept tool calls, dispatch them to Python functions, and feed results back into the next message. It works. It ships. And it quietly accumulates architectural debt the moment your agents need to do anything that takes longer than a single round trip, touches real files, or executes untrusted code.

OpenAI’s latest Agents SDK update addresses exactly that accumulated debt, with two additions that matter more than their terse descriptions suggest: native sandbox execution and a model-native harness. Together they change where the execution boundary lives and who is responsible for maintaining it.

The Problem with Generic Agent Loops

When the OpenAI Agents SDK launched in March 2025, it consolidated the patterns from the experimental Swarm library into a production-facing API. The core primitives were clean: Agent objects carrying instructions and tools, Runner to drive the loop, handoffs to pass control between agents, and guardrails at the input and output layers. Tracing was built in from the start, which was more foresight than most frameworks showed.

But the execution model inherited the fundamental shape of the completions API. Each turn was a discrete HTTP call. Tools were Python callables. State between turns was the developer’s responsibility. That’s fine for short-horizon tasks, but it creates compounding problems as agents grow more capable:

Code execution has no isolation boundary. If your agent generates and runs code, that code runs in your process, on your machine, with your filesystem and network. Sandboxing requires bolting on Docker, Firecracker, or some hosted alternative.
Long-running tasks lose coherence. Without persistent state management, an agent working across dozens of files over many minutes has to reconstruct context from scratch each turn, relying on the context window to hold everything together.
The loop is external to the model. The SDK orchestrates tool dispatch, but the model doesn’t know the difference between a tool call that took 10 milliseconds and one that spawned a subprocess and ran for two minutes. The execution context is invisible to the serving infrastructure.

These aren’t bugs in the Agents SDK specifically. They’re consequences of building on top of a stateless API that was designed for single-turn completions.

What Model-Native Harness Actually Means

The “model-native harness” framing is the more conceptually significant of the two changes. It signals that the agent execution loop is now aligned with how the model infrastructure actually processes tool use, rather than implemented as an external wrapper around it.

OpenAI’s Responses API, which underpins the current SDK, introduced server-side state management for multi-turn conversations. Instead of the client reconstructing the full message history on each call, the server maintains a session reference. This shifts the stateful burden from the developer’s loop to the serving layer.

A model-native harness takes this further. The execution context, the tool dispatch sequence, the agent’s working memory across turns, these live closer to where inference is happening rather than on the client side of an HTTP boundary. The practical consequence is that the harness can make guarantees about execution ordering, handle preemption and retry at the infrastructure level, and give the model accurate signals about what actually happened during tool execution rather than whatever the client chose to report.

For developers building on the SDK, the surface-level API doesn’t change dramatically. You still define agents and tools the same way:

from agents import Agent, Runner, function_tool

@function_tool
def read_file(path: str) -> str:
    """Read a file from the working directory."""
    with open(path) as f:
        return f.read()

agent = Agent(
    name="FileAgent",
    instructions="Analyze the provided files and summarize findings.",
    tools=[read_file],
)

result = await Runner.run(agent, "Summarize everything in /workspace/data")

What changes is what happens below that. The runner is no longer reconstructing the conversation state from scratch. Retries, interruptions, and long-running tool calls are handled by infrastructure that understands the agent’s execution context.

Native Sandbox Execution and the Security Boundary

The sandbox addition is more immediately concrete. Code execution in agent workflows has always been the sharp edge. The Code Interpreter tool that OpenAI offered through the Assistants API ran in a managed sandbox, but that was a hosted tool with limited configurability. If you wanted your own code execution environment, you were on your own.

Native sandbox execution in the Agents SDK brings that isolation boundary into the SDK layer as a first-class primitive rather than an external dependency. This matters for a few reasons.

First, the threat model for agent-generated code is different from the threat model for human-written code. An agent generating code to process data it retrieved from an external source is essentially running untrusted input. Even with a careful system prompt and guardrails, the code path from “model output” to “execution on your host” should have an isolation layer. Without native sandboxing, most teams either accept that risk, pay for a managed sandbox service, or implement their own container orchestration, all of which have significant operational overhead or security tradeoffs.

Second, sandboxing that lives at the SDK level can be tightly integrated with the tool call lifecycle. The sandbox knows when a tool call starts and ends, can enforce resource limits, and can surface execution metadata back to the harness in a way that the model can reason about. A Docker container you manage separately doesn’t have that integration.

The architecture likely resembles a lightweight execution environment per agent session, with resource caps on CPU, memory, network access, and filesystem scope. Something closer to what Deno’s permission system does for JavaScript runtimes, applied at the agent session level rather than the process level.

Long-Running Agents and the State Problem

The third piece, support for long-running agents across files and tools, is the consequence of the first two working together. If you have a stable execution harness and a sandboxed environment the agent can treat as persistent working storage, agents can work on tasks that span minutes or hours without losing coherence.

This is a harder problem than it sounds. LLM context windows are large but not infinite. An agent working through a large codebase can easily exhaust the context window before finishing the task. Long-running agent frameworks have historically handled this through compression, rolling summarization, or external memory stores, all of which introduce approximation and potential information loss.

What native SDK support enables is a more principled approach: the agent’s file workspace persists across the session, intermediate results are checkpointed at the infrastructure level, and the harness can manage context budget actively rather than reactively. Frameworks like LangGraph have explored persistent state graphs for similar reasons, and Microsoft’s AutoGen has long supported stateful multi-agent workflows. The OpenAI approach is making comparable capabilities available without requiring developers to implement their own state management layer.

How This Compares to the Broader Ecosystem

Anthropic’s position is deliberately different. Claude Code runs in a real terminal with real filesystem access, betting that the model’s judgment and constitutional constraints are sufficient guardrails, with no sandboxing layer between the agent and the host environment. That works for the use case it targets, developers who want maximum capability and accept the responsibility that comes with it.

The OpenAI SDK update is optimizing for a broader developer population building agents that interact with user data and external tools in production. For that use case, having the sandbox at the SDK level, managed by the platform, is a reasonable tradeoff. You give up some flexibility in exchange for a security posture you don’t have to maintain yourself.

LangChain’s agent executor has been moving in a similar direction with its LangSmith tracing and LangGraph Platform for deployed agents, but the execution isolation piece remains largely external. The OpenAI SDK is unusual in treating sandboxing as infrastructure rather than a library concern.

What This Means for Building Real Agents

I’ve been running a Discord bot on this codebase for a while, and the pattern I keep running into is that the interesting agent use cases, the ones that actually reduce toil, all involve file I/O, code execution, or both. Reading logs, diffing configs, running a test suite and interpreting the output. Every one of those use cases is where the current execution model shows its seams.

Native sandbox execution and a model-native harness don’t change what agents can attempt. They change what agents can do safely and reliably at production scale. The SDK is shifting from a library that helps you structure agent logic to infrastructure that manages agent execution. That’s a meaningful change in what the platform is taking responsibility for, and it’s the right direction for the ecosystem to move.

The tradeoff to watch is configurability. Managed sandboxes impose resource limits and network policies that may not fit every workload. The degree to which OpenAI exposes knobs on those limits, or allows custom execution environments alongside native ones, will determine how far the SDK can reach into serious production use cases. For now, the direction is right even if the boundaries aren’t fully settled.