In this piece
OpenAI Agents API Review: Migration, Costs and Data Controls
The OpenAI Agents API makes the Codex agent loop a managed service. It does not make your product's permissions, acceptance tests or data obligations disappear. That is the useful buying question: which infrastructure can you stop maintaining without giving up controls your customers require?
OpenAI announced the public beta on 10 September 2026. Its launch announcement describes automatic compaction, tool search, programmatic tool calling and parallel subagents, with a choice of hosted or external execution environments. This review examines that product decision, not the general definition of an AI agent harness.
What the launch numbers actually establish
The headline numbers come from different customers in OpenAI's announcement. They are useful reasons to test the API, not a combined benchmark or a promise for your workload.
| Customer | Reported result | What to avoid inferring |
|---|---|---|
| Ciridae | Evaluation score 0.71 to 0.85; fourfold latency improvement | A universal accuracy score or fourfold acceleration of every task |
| SafetyKit | 60% lower cost per case, maintaining existing performance | A 60% discount on all agent infrastructure |
| Hypha | 86% fewer failed agent responses | 86 percentage points of improvement or a published absolute failure rate |
These testimonials do not supply a shared task set, sample size or independent reproduction. Ciridae's change is 0.14 absolute score points; without its grading rubric, translating that into customer accuracy would be misleading. The right next step is a paired experiment on work you already know how to accept.
Agents API vs Agents SDK vs Responses API
The names sound interchangeable. The operational responsibility is not. OpenAI's SDK comparison distinguishes using a framework to run your loop from implementing that loop yourself. The managed Agents API adds a third hosting choice.
| Path | Who operates the loop? | Good reason to choose it |
|---|---|---|
| Responses API | Your application implements the orchestration around model requests | A narrow workflow where custom branching and direct control are valuable |
| Agents SDK | The SDK runs the loop in your application deployment | Code-level control over state, tools, approvals and infrastructure |
| Managed Agents API | OpenAI operates the Codex harness; you select the execution environment | Reducing maintenance of general-purpose, long-running agent infrastructure |
For custom functions, the documented Responses tool-calling flow still puts execution in your application: receive a proposed call, execute code, return its result. Do not assume changing the API client automatically migrates those functions, authentication or approval flows. Inventory what your existing harness actually does before deciding what to remove.
This is also distinct from Ramp Inspect's per-session sandbox architecture. A sandbox supplies a place to execute. A managed harness also supplies orchestration. Buying one does not prove you have replaced the other.
The three deployment checks that matter more than the demo
Separate where the harness runs, where tools execute and where state persists. A sandbox inside your network does not move OpenAI's managed harness into that network. Tool arguments and results may still cross that boundary. OpenAI's data-control documentation distinguishes application state, abuse-monitoring retention and endpoint-specific eligibility. A control approved for one endpoint is not evidence for another.
| Check | Evidence your team should obtain | Reason to pause |
|---|---|---|
| Residency and processing | Region support for the exact endpoint, model, session state, tools and environment | A required EU-only data path is not confirmed |
| Retention and deletion | Agents API eligibility for your retention arrangement; lifecycle of sessions, files, traces and backups | You require Zero Data Retention but cannot establish feature-level eligibility |
| Isolation and cleanup | Credentials, mounts, network access, subagent sharing, cancellation and sandbox teardown | You cannot prove tenant separation or stop and reconcile an interrupted job |
Review limitation, 13 September 2026: the launch announcement and general data guide were retrievable, but the newly linked Agents API overview was not retrievable in this review. We therefore do not present claims of US-only availability, no Zero Data Retention, or a particular session-retention period as verified endpoint facts. Recheck the current overview and obtain written confirmation for your deployment before moving sensitive data.
That is not a finding that all European or regulated work is prohibited. It is a reason to withhold production approval when a required control is unverified. A synthetic-data pilot can answer engineering questions without answering procurement questions prematurely. Our EU AI data-residency guide covers the wider architecture decision.
Zero platform fee is not zero cost per accepted task
The launch says there is no additional Agents API fee. Budget separately for model usage, tools and execution, using the current pricing documentation for the services you enable. Do not import a partner's sandbox price or a model subscription allowance into an API budget.
Cost per accepted task =
(model + tools + compute + retries + review + operations)
/ independently accepted tasksIllustrative arithmetic, not an OpenAI price quote: suppose 100 attempts cost €30 in machine usage and €70 in review. If 80 are accepted, the cost is €1.25 per accepted task. Cutting machine spend to €12 but raising review to €100 with only 70 accepted tasks produces €1.60. A cheaper call can make the workflow more expensive.
Subagents make this especially important. Cap concurrency in the pilot, measure total usage across the run and distinguish elapsed time from compute consumption. Parallel work can reduce waiting while increasing the amount of work purchased. Compaction also needs a quality test: a shorter context must still preserve the facts needed for your acceptance criteria.
A minimal Agents API example, without production access
This JavaScript example adapts the session-creation shape in OpenAI's launch post. It uses fictional input, attaches no business connectors and opts into paid execution explicitly. It is a starting point, not a complete service: the installer for this article does not run it or install an agent in your business systems.
import OpenAI from "openai";
// Opt in explicitly: this example can incur API and compute charges.
if (process.env.RUN_PAID_AGENTS_DEMO !== "yes") {
throw new Error("Set RUN_PAID_AGENTS_DEMO=yes to enable this demo.");
}
if (!process.env.OPENAI_API_KEY) {
throw new Error("OPENAI_API_KEY is required on the server.");
}
const client = new OpenAI({ maxRetries: 0 });
if (!client.beta?.agents?.sessions?.create) {
throw new Error("Install an OpenAI SDK version supporting Agents API beta.");
}
try {
const session = await client.beta.agents.sessions.create({
agent: {
model: process.env.OPENAI_AGENT_MODEL || "gpt-6-astra",
multi_agent: { enabled: true, max_concurrent_subagents: 2 },
},
environment: { type: "openai_hosted" },
input:
"Use only these fictional facts: Service A had 4 errors in 100 requests; " +
"Service B had 9 errors in 300 requests. Compare the error rates, " +
"have a second agent check the arithmetic, and save a short report " +
"under /workspace/outputs. Do not contact external services.",
});
console.log(JSON.stringify({ session_id: session.id }));
} catch (error) {
// Do not dump prompts, credentials or the complete server response.
console.error("Session creation failed. Reconcile its status before retrying.");
process.exitCode = 1;
}
Use an SDK version that exposes the beta resource, lock it after validation, and run this only on a server with an approved project and model. Printing a session ID is not proof that the report was completed. Implement observation of the documented session lifecycle, cancellation, artifact retrieval and cleanup separately. Automatic create retries are disabled here to avoid blindly starting duplicate work after an uncertain network outcome. The instruction not to contact external services is not a substitute for enforced egress policy.
A migration plan that keeps business controls intact
Start with one adapter boundary: a task enters, a session reference and eventual artifact leave. Keep your application task ID, authorization decision, tool permissions, approval record and acceptance result outside the model's instructions. OpenAI's MCP security guidance highlights external-server trust, prompt injection and approval for sensitive actions. Those principles still matter with a managed loop; use the approval contract supported by your chosen API rather than copying another endpoint's fields.
| Stage | Change | Acceptance evidence |
|---|---|---|
| Baseline | Freeze representative tasks and the current implementation | Accepted outcomes, review time, latency distribution and full cost |
| Shadow | Run the managed path against synthetic or approved read-only data | No unintended writes; comparable artifacts with source references |
| Limited rollout | Enable one reversible workflow with bounded authority | Tenant isolation, retry reconciliation and human approval tests pass |
| Expansion | Increase volume only after repeated acceptance | Stable quality and cost, plus a tested return to the previous path |
Test two experiments separately. Holding the model and tools fixed helps isolate the orchestration change. Comparing the best viable old and new stacks answers the commercial question, but cannot attribute the whole improvement to the harness. OpenAI's evaluation guidance recommends task-specific tests and continuous evaluation; add your own failure cases rather than relying on a persuasive demo.
Our proposed acceptance set includes a tool timeout after a write may have succeeded, duplicated input, expired credentials, conflicting subagent outputs, an instruction hidden in a retrieved document, loss of a client connection and a fact that must survive compaction. A fallback must reconcile the original task before starting again. Otherwise your recovery path may duplicate the very action it was meant to rescue.
Seven bounded agent pilots worth considering
These are proposed starting points, not claims that Wavect or OpenAI has validated all seven in production. Each has a reviewable artifact and a way to start without autonomous business writes.
| Pilot | Output | Initial boundary |
|---|---|---|
| Incident evidence assembly | Timeline with log references | Read-only, sanitized telemetry; no deployment changes |
| Repository change assessment | Impact report and suggested tests | Approved code snapshot; no merge credentials |
| Support investigation | Cited draft response | Scoped records; a person sends the answer |
| Document reconciliation | Differences and unresolved contradictions | Approved documents; no authoritative record updates |
| Supplier evidence review | Missing-evidence checklist | No compliance certification or purchasing decision |
| Release readiness | Checklist grounded in test results | No release or deployment authority |
| Public-source research | Brief with attributable sources | No confidential prompts or automatic external publishing |
When to migrate, and when to keep your harness
Shortlist the managed API when maintaining long-running orchestration consumes engineering time and the data, tooling and commercial requirements can be met. Keep the existing path when it is already simple and reliable, when critical behavior is unsupported, or when required deployment controls remain unverified. An attractive launch does not justify rewriting a stable transactional workflow.
OpenAI's production guidance covers operational capacity, cost management and security. For this migration, assign a named owner to version changes, regression evaluation, usage reconciliation and incident response. Maintain a configuration inventory and an exit path for task state and accepted artifacts; do not make a provider-specific session identifier your only business record.
Wavect's AI consulting and implementation can scope the data path, tool contracts and acceptance tests for one migration. The Twinsoft AI case study is adjacent delivery context, not an Agents API benchmark. Use our custom software versus off-the-shelf guide for the ownership decision, or discuss a bounded Agents API migration review with your workflow, current costs and required controls.
