"We took an agent that worked in PoC into production, only for it to stall from a triple punch of stopping on mysterious errors, memory corruption, and runaway loops"—as an answer to this typical pattern, OpenAI added sandbox execution and memory control in its Agents SDK update (April 16).
The design pieces for "agents that don't break in production," which used to be handcrafted in custom development, have essentially shifted to the SDK side. In this article, we examine how to use these two new features in v2 and how to restructure the scope of client projects.
What has changed
There are three major additions to OpenAI Agents SDK v2.
- Sandbox execution environment: Tool calls and generated code can run in an isolated environment
- Tiered memory: Manage state across three tiers: short-term, long-term, and session-shared
- Replay on failure: Rerun sessions that failed midway, starting from the immediately preceding safe state
Previously, this was an area where developers in custom projects compensated by building their own frameworks within Claude Code routines or what we outlined as "harnesses for next-generation agents." Having these as standard SDK features brings the secondary benefit of reducing the maintenance burden of custom code and improving profit margins on client projects.
Sandbox implementation patterns
Minimal configuration
from openai_agents import Agent, Sandbox
sandbox = Sandbox(
network="egress-deny", # 外部通信はホワイトリストのみ
fs="ephemeral", # ファイルシステムはセッション終了で破棄
cpu_limit="500m",
memory_limit="1Gi",
timeout=30,
)
agent = Agent(
name="invoice-processor",
tools=[query_db, send_email],
sandbox=sandbox,
)The standard rule is to close network egress by default and allow only necessary external traffic on a case-by-case basis. Egress control like this can prevent 90% of accidents like the incident where exposed Firebase keys burned through 54,000 euros in 13 hours.
Three tiers of privilege separation
In production operations, the sandbox is divided into three tiers based on permissions.
| Layer | Permission | Application |
|---|---|---|
| Read-only | DB read / external API read | Dashboard generation and aggregation |
| Write-guarded | DB write (HITL required) | Order processing and status updates |
| Privileged | Fund transfers and external transmissions | Supervisor approval + audit log required |
Because the SDK rejects calls that cross tiers, attempts to escalate privileges via prompt injection are naturally stopped as well.
Three-tier design for memory control
The tiered memory in v2 is used as follows according to purpose.
| Memory type | Retention period | Application | Examples |
|---|---|---|---|
| Short-term | 1 session | Preserve conversational flow | "The previous customer," "the next one" |
| Long-term | Persistent per user | Personal preferences, past support history | "Show amounts tax-included," "Assigned CS is Tanaka" |
| Shared | Shared across teams | Business knowledge, FAQ | "Recall procedures for this product" |
A common design mistake is storing too much personal information in long-term memory. Design the system so that phone numbers, email addresses, and the like are not saved in long-term memory, but retrieved via MCP at runtime instead.
Three principles to prevent memory corruption
- Write gating: Screen user statements using summarization and confidence scores rather than putting them directly into long-term memory
- TTL configuration: Automatically expire outdated information (e.g., 90 days for customer info / 1 year for business knowledge)
- Auditing support: Maintain logs that can trace which statement was stored in which memory
These three are often omitted in PoCs, only to surface 2 to 3 months into production as incidents where "the AI inexplicably gives bizarre answers."
Reducing SRE costs with replay on failure
In v2, an agent's execution history is preserved as "checkpoints," allowing restarts from the last safe point in the event of failure. Previously, developers had to implement mechanisms to ensure idempotency on their own, but the scope that can now be offloaded to SDK mechanisms has expanded.
try:
result = agent.run(task, checkpoint=True)
except SandboxError as e:
# 直前の安全状態からリプレイ
result = agent.resume_from_last_checkpoint(task)With this replay mechanism, the operational task of rerunning failed nighttime batch sessions the next morning shrinks from manual effort by operations staff to a single command. The loop of observability → replay → recurrence prevention that we described in observability platforms for AI development with Langfuse is finally becoming a reality.
Impact on development scope
The arrival of Agents SDK v2 alters the allocation of effort in agent development projects. Because steps that previously required building sandboxes, memory controls, and replay mechanisms by hand can now rely on SDK standards, the custom implementation required in each phase becomes lighter.
| Phase | Duration (prior to v2) | Duration (after adopting v2) |
|---|---|---|
| Agent PoC | 6–8 weeks | 4–6 weeks |
| Transition to production | 3–5 months | 2–3 months |
In the operations phase as well, replay on failure reduces manual recovery tasks, lowering the operational burden on SREs directly. Overall, the timeline from PoC to production is shortened by 2 to 4 weeks, allowing effort once spent maintaining custom harnesses to be redirected toward domain-specific implementations.
Prerequisite checklist for adoption
Before adopting v2, check the following four points.
- Existing agents use OpenAI API or Azure OpenAI
- Project is in the pre-production PoC phase, or undergoing a major post-production refactoring
- Internal foundation exists for running sandboxes (containers, audit logs)
- Involves personal information or payment processing (= provides positive ROI on safety investments)
If at least 3 of these 4 points apply, transitioning to v2 is in a phase where investments are readily recouped.
Summary — Offload "custom harnesses" to the SDK
When building agents in custom development, the code volume of custom harnesses has exerted a lingering maintenance burden on developers for years. The release of v2 marks a turning point where this burden shifts back to the vendor. Moving forward, we are adopting a policy of leaning on SDK standards for sandboxes, memory control, and replay, while limiting custom code strictly to truly domain-specific logic.
If you are thinking, "Our PoC works, but we are stuck on moving to production" or "Maintaining custom frameworks is becoming too heavy," please feel free to reach out via our contact form.
