OpenAI Fixed the Biggest Agent Blocker. Now What?

OpenAI shipped The Next Evolution of the Agents SDK on April 16. The update adds native sandbox execution, configurable memory, and built-in snapshotting with state rehydration. All three features are available at standard API pricing. No premium tier. No waitlist.

Those three capabilities were the reason most enterprise teams gave for not shipping AI agents to production. Sandbox isolation, durable state, and the ability to recover from failures mid-run. Every serious deployment conversation in the last six months hit one of those walls. Sandbox isolation, durable state, and crash recovery were the consistent blockers across enterprise teams evaluating agent production readiness. The walls are gone now.

And in the same week, ADP went live with a Payroll Variance Agent across enterprise clients in more than 40 countries. Production agentic AI processing real payroll data, at global scale, under human oversight. If you’re still treating agent deployment as theoretical, you’re already behind the organizations that stopped debating and started shipping.

What Shipped

Feature	What It Does	Why It Matters
Native sandbox execution	Agents run in isolated container environments with controlled file and tool access	Code execution without risking your production infrastructure
Configurable memory	Persistent context across agent sessions	Agents retain what they learned between runs
Snapshotting and rehydration	Saves agent state; restores in a fresh container from last checkpoint	Long-running tasks survive failures without starting over
Sandbox partners	Built-in support for Cloudflare, E2B, Modal, Vercel, Daytona, Blaxel, Runloop	Bring your own sandbox or use a vetted provider
Pricing	Standard API pricing based on tokens and tool usage	No enterprise surcharge for safety features
Language support	Python now, TypeScript coming	Production-ready today for Python shops

Source: OpenAI, TechCrunch

What Were the Three Blockers?

Every conversation about deploying AI agents in a real enterprise environment eventually hits the same objections. Not “is the model smart enough?” The model has been smart enough for months. The blockers were infrastructure problems.

Blocker 1: Unsandboxed execution. An agent that can run code and access files on your system is an agent that can break your system. Without native sandboxing, teams had to build their own isolation layers or accept the risk. Most chose neither. They just didn’t ship.

Blocker 2: No durable memory. Agents that forget everything between sessions can’t handle multi-day workflows. Every run started from zero. For anything beyond a single-shot task, that’s a dealbreaker.

Blocker 3: No crash recovery. A long-running agent task that fails at step 47 of 50 previously meant starting over from step 1. Without snapshotting and rehydration, teams couldn’t trust agents with tasks that take hours to complete. The SDK now saves checkpoints and restores state in a fresh container if the original environment fails. Step 47 fails, step 48 picks up where it left off.

I wrote about why agents were failing back in March. The model wasn’t the problem. The infrastructure was. This update is OpenAI acknowledging that publicly and fixing it.

The Governance Gap Is the Real Risk Now

The technical blockers are solved. The organizational blockers haven’t moved.

OutSystems surveyed nearly 1,900 IT leaders for their 2026 State of AI Development report. 96% of organizations are already running AI agents in some capacity. Meanwhile, Deloitte’s 2026 State of AI in the Enterprise report found that only 21% have a mature governance model for autonomous agents.

That’s a 75-point gap between adoption and governance. And 94% of the OutSystems respondents said agent sprawl is increasing complexity, technical debt, and security risk inside their organizations.

This is the exact pattern I flagged in my piece on agent sprawl. Teams deploy agents without standardized oversight. Agents multiply across departments. Nobody has a clear picture of what’s running, what data it touches, or what happens when something goes wrong.

The SDK update makes the technical side of agent deployment easier. That’s good. It also makes it easier to deploy agents without governance. That’s the part you need to get ahead of.

What ADP’s Payroll Agent Proves

The same week OpenAI shipped sandbox execution, ADP deployed a Payroll Variance Agent to enterprise clients across more than 40 countries. The agent scans payroll runs for anomalies: net pay changes above threshold, unexpected variance in pay elements, compliance mismatches. It surfaces them for human review.

Users ask natural-language questions like “Which employee had a significant net pay difference this cycle?” and get answers with actionable data directly inside the ADP Global Payroll portal. Early adopters report saving up to 30 minutes per payroll cycle per administrator.

Two things matter here. First, this is production agentic AI handling financial data at multinational scale. A shipped product processing real compensation across real regulatory environments.

Second, notice the design: the agent finds and flags, but humans review and approve. That’s the governance model that works. Autonomous analysis, human-in-the-loop decisions. If you’re designing your own agent workflows, that’s the pattern to follow.

How to Deploy Production Agents This Quarter

If you’ve been stuck in pilot mode, here’s a practical path from the SDK update to a running production agent.

Step 1: Pick One Workflow (Week 1)

Choose a process that meets three criteria:

1. It’s repetitive and rule-based (data validation, report generation, document processing)
2. It has a clear human checkpoint before any external action
3. A failure costs time, not money or reputation

Payroll variance detection. Invoice reconciliation. Weekly metric summaries. Start boring. Boring ships.

Step 2: Set Up Sandboxed Execution (Week 2)

Use the SDK’s built-in sandbox support. If you’re already on Cloudflare Workers, Vercel, or Modal, plug into the provider you know. If not, E2B and Daytona are purpose-built for agent sandboxing.

The key architectural decision: the harness (agent loop, tool routing, approvals, tracing) runs on your infrastructure. The sandbox (code execution, file operations, dependency installation) runs in the provider’s isolated environment. Your production systems never share a runtime with agent-generated code.

Step 3: Add Memory and Checkpoints (Week 3)

Configure the SDK’s memory layer so your agent retains context between runs. Enable snapshotting so long tasks survive interruptions. Test failure recovery by killing a sandbox mid-run and verifying the agent resumes from the last checkpoint.

This is the step most teams skip. Don’t. The whole point of durable agents is that they handle failure gracefully. If you haven’t tested failure, you haven’t tested your agent.

Step 4: Build the Governance Wrapper (Week 4)

Before you go live, answer five questions:

1. What data can this agent access?
2. What actions can it take without human approval?
3. How do you audit what it did and why?
4. Who gets notified when it flags an exception?
5. What’s the kill switch?

Write the answers down. Make them enforceable through configuration, not policy documents nobody reads. The SDK’s built-in tracing and approval hooks give you the infrastructure for this. Use them.

I outlined a broader framework for this in my piece on Gartner’s agentic AI failure rate predictions. The short version: governance built into the agent workflow succeeds. Governance bolted on after deployment doesn’t.

Three Mistakes That Will Kill Your Agent Deployment

Skipping the sandbox because “our agents only do read operations.” Agents evolve. The read-only agent you deploy in May will need write access by July because someone on the team realized it could also update the records it’s reviewing. Start sandboxed. Stay sandboxed.

Building on one provider’s sandbox without an abstraction layer. The SDK supports seven sandbox providers today. More are coming. If you hardcode to E2B’s API surface and E2B changes their pricing or goes down, your agent stops. Build a thin abstraction. I’ve been beating this drum since I wrote about AI stack expiration dates and it applies here too.

Deploying without tracing. The SDK includes built-in tracing. Turn it on from day one. When (not if) an agent produces an unexpected result, you need the full decision log. Not “what did it output?” but “what did it see, what tools did it call, what did it decide at each step, and why?” Organizations that skip tracing spend three times longer debugging agent failures.

The Excuse Just Expired

Six months ago, “we don’t have the infrastructure to run agents safely in production” was a legitimate position. The tooling wasn’t there. Sandboxing meant rolling your own. State management was duct tape. Crash recovery was “restart and hope.”

That’s no longer true. The SDK handles sandbox isolation through vetted providers. Memory persists across sessions. Snapshots survive failures. Tracing provides an audit trail. And the whole thing runs at standard API pricing.

The remaining gap is governance. 96% of organizations are running agents. Only 21% have mature oversight. That gap is where the risk lives, and it’s the one OpenAI can’t fix with an SDK update. That’s on you.

ADP didn’t wait for perfect conditions. They shipped a payroll agent across 40+ countries with a human-in-the-loop design that handles the governance question by architecture, not afterthought. That’s the model.

Pick a workflow. Sandbox it. Add memory and checkpoints. Build governance into the system. Ship it this quarter.

The tools are ready. The question is whether your organization is.

---

Related Reading:

• Your AI Agents Are Failing. It’s Not the Model.
• Agent Sprawl Is Coming for SMBs
• Stuck in AI Pilot Purgatory? 5-Step Roadmap to Production
• Your AI Stack Has an Expiration Date