The OpenAI Agents SDK started life in March 2025 as a clean-room rewrite of the experimental Swarm project. Where Swarm was exploratory, a minimal framework to demonstrate agent handoffs and multi-agent coordination, the Agents SDK was meant to be something you could actually ship against. Core primitives: Agent (instructions plus tools), Runner (the loop), Handoff (delegation between agents), and Guardrail (validation hooks around inputs and outputs).
The latest update pushes further in a direction the original release only gestured at: native sandbox execution and a model-native harness for long-running agents that work across files and tools.
Both terms are worth unpacking, because they describe two distinct problems the SDK is solving.
The Client-Side Loop Problem
Most agent frameworks operate through what you might call a client-side loop. The framework sends a request to the model, receives a response with tool calls, dispatches those calls to whatever functions you have registered, packages up the results, and sends another request. This works for simple workflows, but creates genuine friction at scale.
First, the orchestration logic lives entirely on the client. If your agent process dies mid-run, the state is gone. If you are running multiple concurrent agents, each one is managing its own loop with no shared infrastructure. Long-running tasks, the kind that might span hundreds of tool calls over many minutes, require you to build persistence, resumption, and error recovery on top of the framework yourself.
Second, code execution is messy. If your agent needs to run code, you either wrap OpenAI’s hosted code interpreter (opaque, limited in configuration) or spin up your own execution environment and manage the security implications yourself. Neither is a good answer when you want repeatable, auditable behavior.
What Native Sandbox Execution Actually Means
The phrase “native sandbox execution” refers to a built-in, isolated execution environment that the SDK manages on your behalf. Rather than treating code execution as just another tool call whose output you paste into the next message, the sandbox is a first-class part of the agent’s runtime.
In practice, this means the agent gets a persistent filesystem within its execution context. Files created in one tool call are available in the next. A Python script that writes intermediate results to disk is not throwing those results away at the boundary of each API request. An agent processing a large dataset can write chunks to a temp file, reference them later, and pass the final output back without the whole dataset needing to live in the context window.
The isolation piece matters as much as the persistence. Proper sandboxing means one agent’s execution environment does not bleed into another’s. In multi-tenant systems or workflows running many agents concurrently, this is the difference between a tool you can trust in production and one you have to babysit.
Sandbox implementations at this layer typically combine container isolation (Docker or Firecracker microVMs are common choices), filesystem namespacing, and network egress controls. OpenAI has been running similar infrastructure for ChatGPT’s code interpreter since 2023, and the SDK bringing this to the API layer means developers do not have to solve that hard infrastructure problem themselves. The defaults are secure; the extension points are explicit.
The Model-Native Harness
This is the more conceptually interesting piece. A model-native harness suggests that the agent execution loop is no longer primarily a client-side concern. Instead of your code driving the loop, the model’s own understanding of its tool-calling workflow becomes structural.
OpenAI’s Responses API already moved in this direction. Unlike the Chat Completions API, which treats each call as stateless, the Responses API maintains a conversation object server-side and handles multi-step tool-use sequences with less back-and-forth on the client. The model-native harness in the updated Agents SDK builds on this: you submit an agent task, and the model manages the sequencing of tool calls against the available tool schemas, reporting back at defined checkpoints rather than requiring the client to manually thread each step together.
This architecture has a meaningful implication for reliability. When the client drives the loop, any disruption in that process (network drop, process crash, rate limit) risks losing agent progress. When the loop is handled server-side with a durable state object, the client can reconnect, poll for progress, and resume without losing context. That is a significant shift in the failure model.
It also has implications for parallelism. A model-native harness can identify tool calls that do not depend on each other and dispatch them in parallel without requiring the developer to write that fan-out logic explicitly. This is something LangGraph exposes through its graph primitives, useful, but requiring the developer to model the dependency structure upfront. The model-native approach infers it from the tool call graph at runtime.
How This Compares to Other Frameworks
LangGraph is the most direct structural comparison. It gives you fine-grained control over agent state, branching, and persistence via an explicit graph abstraction. You define nodes (agent steps), edges (transitions), and state schemas. For complex, well-understood workflows, that design effort pays off. For exploratory or generative workflows, it is friction.
Microsoft’s AutoGen takes a different approach: multi-agent conversation patterns where agents communicate through messages. Flexible and expressive for collaborative agent architectures, but it pushes more orchestration responsibility onto the developer.
Anthropic’s Claude Agent SDK occupies a similar philosophical space to what OpenAI is building here. Both are moving toward a model where the execution harness is opinionated and the developer focuses on defining capabilities rather than coordinating execution. The difference is in the tool surface: OpenAI’s SDK has deeper integration with its hosted tools (file search, web search, code interpreter) because those are first-party infrastructure, whereas Anthropic’s approach relies more on the developer providing tool implementations.
The OpenAI SDK is positioning itself toward the “define your agent and let us run it” end of the spectrum. Less graph design, less manual state management, more trust placed in the model’s own sequencing capabilities. For general-purpose task agents and developer tooling, that is a reasonable trade. For specialized workflows with strict ordering requirements or custom execution semantics, you will still want more explicit control.
What Changes in Practice
For a concrete example of what the sandbox changes, consider an agent that processes uploaded files. In the previous model, you would receive the file, pass its contents into context, run analysis, and hope everything fits. With the sandbox, the agent can receive a file reference, write it to its persistent workspace, run processing scripts against it, and maintain intermediate state across multiple analysis steps without cramming everything into a single context payload.
A rough sketch of what this looks like with the SDK:
from agents import Agent, CodeInterpreterTool, FileSearchTool, Runner
agent = Agent(
name="data-analyst",
instructions="Analyze the provided data files and produce a summary report.",
tools=[
CodeInterpreterTool(), # native sandbox execution
FileSearchTool(), # vector store access
],
)
result = await Runner.run(agent, input="Process the attached CSV and identify anomalies.")The CodeInterpreterTool now hooks into the native sandbox rather than just wrapping a hosted endpoint. The files the agent writes during execution persist within the run context. The runner handles the multi-step loop server-side.
For the kind of work I tend to do, building automation, wiring up bots, running small agentic workflows that touch files and call external APIs, the sandbox and harness updates address two genuine pain points. Code execution has always been the sharp edge of agent development. An agent that can read, write, and run files in a secure, persistent context removes a whole category of scaffolding I would otherwise write myself.
The Tracing Dependency
The model-native harness is where I will be watching most carefully. The promise is real, but so is the risk of opacity. When the loop is client-side, every step is visible and every failure is debuggable. When the loop moves server-side, you need solid tracing and observability tooling to understand what happened when something goes wrong.
The SDK has included tracing hooks since the original release, with support for exporting to systems like Langsmith and custom tracing backends. That infrastructure will matter significantly more as execution moves further from the client. A server-managed harness that you cannot introspect is not an improvement; it is just failure hiding. OpenAI’s track record with the code interpreter’s observability has been mixed, and that is worth keeping in mind as this execution model expands.
The direction the SDK is taking is correct. Shifting the reliability burden for long-running execution from application code to platform infrastructure is how these systems become usable at production scale. Whether the implementation holds up under real workloads is the question that only shipping against it will answer.