Vercel announced its integration with the OpenAI Agents API: you can now deploy long-running agents where OpenAI manages the loop and the session state, while Vercel hosts the application and connects each session to Vercel Sandbox for code execution and file access. Reconnecting to the Sandbox goes through signed OpenAI webhooks and Vercel Queues, and the architecture is scale-to-zero, with no worker running around the clock. The Agents API documentation hit the top of Hacker News the same day, so the interest is anything but marginal.
Why it matters
The signal isn't "another agents API shipped." The signal is which piece stopped being yours. Over the last year and a half, anyone who built a serious agent hand-wrote three things: the reasoning and tool-calling loop, state persistence between turns, and a live worker waiting for the model to finish thinking. That third piece is the one that breaks the serverless model: an agent that takes eight minutes doesn't fit in an ephemeral function.
What this integration does is split the responsibility down the middle. OpenAI keeps the loop and the state. Vercel keeps the hosting and the isolated execution environment. And the glue between them —the part we'd all been improvising with homemade queues and polling— becomes provided infrastructure: signed webhooks plus Queues.
Writing that glue properly is harder than it looks. Reconnecting a session to its sandbox after the function died, guaranteeing the webhook doesn't get processed twice, keeping the workspace with the files the agent generated on the previous turn: that's distributed systems work dressed up as a product feature. Getting it handed to you solved changes the math on whether the agent is worth it.
What changes in practice
The concrete change is the disappearance of the always-on worker. Let's compare the two ways of sustaining a long-running agent:
| Aspect | Your own worker | Agents API + Sandbox |
|---|---|---|
| Agent loop | Yours, you write it and maintain it | Managed by OpenAI |
| Session state | Your own database or cache | Managed by OpenAI |
| Process at rest | Always on | Scale-to-zero |
| Code execution | Container you manage | Sandbox isolated per session |
| Files between turns | Your own volume or storage | Persistent workspace |
| Portability | High | Tied to both vendors |
The flow looks like this:
┌──────────┐ instruction ┌───────────────┐
│ App on │ ──────────────► │ Agents API │
│ Vercel │ │ loop + state │
└────┬─────┘ └───────┬───────┘
│ │ signed
│ │ webhook
│ ┌──────────────┐ │
└───────►│Vercel Queues │◄──────┘
└──────┬───────┘
│ create / reconnect
▼
┌─────────────────┐
│ Vercel Sandbox │
│ persistent │
│ workspace │
└─────────────────┘For anyone working with this every day, what gets simpler is the infrastructure code, not the product code. You still define your tools, you still decide what the agent is allowed to touch, you still write the prompt. What you no longer write is the sandbox reconnection retry or the session state machine.
Cost moves around too. An always-on worker is paid for by time, traffic or no traffic. Scale-to-zero is paid for by usage. For a product with irregular load —which is nearly every internal-use agent— that's a real difference. But careful: Vercel's material publishes no pricing or cold-start latency benchmarks, so the concrete economic comparison has to be measured in your case, not assumed.
When NOT to use it
First the obvious and most expensive part: this couples you to two vendors simultaneously for a single piece of functionality. It's not just OpenAI: it's OpenAI for the loop plus Vercel for the runtime, with signed webhooks between them as the contract. Switching models stops being a matter of swapping an HTTP client and becomes redesigning your session architecture. If your product needs to be able to change model provider —for price, for regulation, for a client demanding another vendor— this path makes that a lot more expensive.
Second: if your agent's session state contains sensitive data, it now lives on OpenAI's infrastructure. That's a compliance decision, not an architecture one, and your legal team makes it before you do. There's no detail in the announcement about retention or residency of that state, so if your domain is healthcare, finance or public sector, that's the first question you have to ask, not the last.
Third: if your "agent" is really a chain of two or three deterministic calls, you need none of this. An endpoint with explicit logic is cheaper, faster to debug and easier to test than a loop that decides on its own. The temptation to call a workflow an agent is strong because the term sells; resist it. A managed loop makes sense when the number of steps is genuinely unpredictable.
Fourth, and this applies to the whole ecosystem: there's an asymmetry between what gets announced and what can be audited. The same news cycle brought OpenAI's report on Navier-Stokes, where the coverage mentions enormous numbers of agents running in parallel and the process ended up under public discussion. That's not an argument against the Agents API —they're different things— but it is a reminder that the orchestration layer you don't control is also the layer you can't inspect when something goes wrong. Debugging someone else's loop is harder than debugging your own.
And something minor but practical: the per-session isolated sandbox with a persistent workspace is convenient right up until you need two sessions to share state, or an external process to read those files. That's where the isolation they sold you as a feature becomes the wall you run into.
What I'd do today
I'd try it on something internal and disposable: an agent running maintenance tasks over a repo, or processing files that are already ours. There the coupling doesn't hurt because the cost of throwing it all out and starting over is low, and you learn how session reconnection behaves under real load.
For production with clients, I'd wait. Not because the integration is badly built —the design with signed webhooks and Queues is sensible— but because there's still no public data on cost, cold-start latency or behavior under failure. And also because the same day brought the announcement of GPT-Live-1 for full-duplex voice: the rate of change on this API surface is so high that tying down architecture today is betting the contract won't move tomorrow.
My rule stays the same: adopt managed infrastructure when the problem it solves has already genuinely hurt you. If you've never written a sandbox reconnection retry, you don't yet know what it's worth to have it handed to you.