Vercel's OpenAI Agents API integration adds sandboxed code execution and persistent sessions

What Vercel announced

On September 10, 2026, Vercel announced an integration for building and deploying applications on OpenAI's Agents API. The move was recapped in a dev.to post by Ashutosh Maurya, who describes the division of labor: OpenAI runs the agent loop and holds session state, while Vercel connects each session to Vercel Sandbox, an isolated compute environment for code execution with persistent workspaces.

In other words, the model provider manages orchestration while the hosting platform manages execution, with a deliberate seam between the two.

How the architecture flows

The layout Maurya sketches runs roughly like this: a user interacts with a Next.js app hosted on Vercel, the app calls the OpenAI Agents API, the API opens an agent session, and that session reaches into a Vercel Sandbox where files are kept and code is actually executed.

That split lets each side do what it is positioned to do well. OpenAI maintains the loop of model calls, tool use and session continuity, while Vercel supplies isolated, disposable compute paired with a filesystem that persists across steps.

Scale to zero instead of always on

According to the post, Vercel frames the integration around a scale-to-zero architecture with no permanently running worker. Maurya characterizes the broader shift as a move away from always-on workers, containers and GPUs, toward a cycle in which a request lands in an agent session, runs on ephemeral managed execution, has its state persisted, and then scales back down.

That profile suits workloads that are bursty or asynchronous — agents that sit idle most of the time and spike when invoked — where paying for idle compute is the main cost problem.

Caveats and trade-offs

The Agents API is currently in public beta, so Maurya cautions that both its interfaces and capabilities should be expected to evolve.

He also lists trade-offs worth weighing before adoption:

• Managed runtime versus control. Offloading infrastructure cuts operational work, but teams with strict compliance or specialized infrastructure needs may prefer to own their execution environment.
• Autonomy versus safety. More capable agents are more useful, and they also carry a larger blast radius when something goes wrong.
• Parallelism versus cost. Concurrent agents can reduce latency while driving up compute and token consumption.
• Long-running state versus complexity. Persistent sessions are powerful, but demand deliberate handling of state, recovery, timeouts, cleanup, permissions and observability.

For teams evaluating the stack, he suggests growing into it incrementally rather than starting with a large autonomous system — for example beginning with a single agent, then tool calling, a backend service, durable state in PostgreSQL, tool protocols such as MCP, sandboxing, human approval gates, parallel subagents, and finally evaluation and observability.

Why it matters

The notable part of this integration is not simply another endpoint from OpenAI. As Maurya argues, the agent runtime is being promoted to a first-class component of the application: the model supplies reasoning, the runtime supplies execution, and the backend still owns deterministic business rules and security.

For agent developers, Vercel's offering is a concrete, deployable answer to two persistent problems — where untrusted code runs and where session state lives — without keeping servers warm. Production AI is drifting away from wiring up a model call and toward assembling a reliable system around an autonomous process, and this integration is a sign that managed infrastructure is catching up to that requirement.