OpenAI has shipped a significant update to the Agents SDK, aiming squarely at the unglamorous parts of agent development: the harness around the model, and the execution environment where an agent reads files, runs commands, and edits code. The release (dated April 15, 2026) positions the SDK as standardized infrastructure for agents that need to operate across files and tools while staying inside controlled sandbox environments.
That framing lines up with the direction OpenAI has been pushing for long-horizon work—where models and orchestration matter at least as much as raw capability.
A more capable agent harness, tuned for the “agent loop”
A central theme in the update is making the harness more “native” to how OpenAI models perform best when an agent needs to iterate: inspect artifacts, take tool actions, and continue for many steps. OpenAI highlights new additions including configurable memory, sandbox-aware orchestration, and Codex-like filesystem tools.
The SDK also standardizes integrations with several primitives that are becoming common in agent systems:
- Tool use via MCP
- Progressive disclosure via skills
- Custom instructions via AGENTS.md
- Code execution via the shell tool
- File edits via the apply patch tool
In the example provided, an agent is given a temporary “dataroom,” explicit constraints (“Answer using only files … Cite source filenames”), and a sandbox run configuration—illustrating the SDK’s focus on getting agents to reliably work from local evidence in a predictable workspace.
Native sandbox execution, with a portable workspace manifest
The other major piece is native sandbox execution: the SDK can run agents in controlled computer environments where they can read/write files, install dependencies, and run tools more safely.
OpenAI says developers can bring their own sandbox or use built-in support for Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop, and Vercel. To keep the same agent setup portable across providers, the SDK introduces a Manifest abstraction to describe the workspace: mount local files, define output directories, and pull data from storage providers including AWS S3, Google Cloud Storage, Azure Blob Storage, and Cloudflare R2.
The intent is straightforward: consistent mechanics from a local prototype to production, and a workspace that’s explicit about where inputs live, where outputs go, and how long-running work stays organized.
Separating harness from compute: security and durability as defaults
OpenAI also leans into a design pattern that’s increasingly common in production agent setups: separating the harness from the compute where model-generated code runs. The post calls out three practical upsides:
- Security: assuming prompt-injection and exfiltration attempts, credentials stay out of the execution environment.
- Durability: by externalizing agent state, a lost container doesn’t necessarily mean a lost run; the SDK supports snapshotting and rehydration to resume from a checkpoint.
- Scale: runs can invoke one or many sandboxes, route sub-tasks into isolated environments, and parallelize across containers.
That last point echoes patterns seen in multi-agent and orchestration tooling elsewhere—similar in spirit to how OpenAI has been thinking about coordinating multiple coding agents in products like Codex App for macOS.
Pricing, availability, and language support
OpenAI says the new Agents SDK capabilities are generally available via the API and use standard API pricing, based on tokens and tool use.
The new harness and sandbox capabilities are launching first in Python, with TypeScript support planned for a future release. OpenAI also notes work underway to bring additional capabilities—including code mode and subagents—to both Python and TypeScript over time.
Original source: https://openai.com/index/the-next-evolution-of-the-agents-sdk/
