OpenAI’s Agents API Is in Public Beta: What Businesses Still Need to Control

Giving an AI system a longer memory, more tools and more time to work does not simply make it more useful. It also increases the number of places where cost, permissions, data exposure and recovery can go wrong.

That is the practical significance of OpenAI’s Agents API, which entered public beta on 10 September 2026. The release is not another model announcement. It is a managed layer for running cloud agents with the Codex harness: sessions can continue across long tasks, work with files, call tools, create artefacts and coordinate subagents.

For developers and small businesses, the attraction is clear. Less orchestration infrastructure may need to be built from scratch. But a managed harness does not remove the buyer’s responsibility for workflow design, data governance, permissions, evaluation, human review or cost control.

What OpenAI has actually introduced

OpenAI describes the Agents API as a public-beta service for building and running cloud agents through the same managed harness used by Codex. A developer defines the model, tools, environment and task; the service supplies the orchestration layer.

The current product includes several capabilities that previously required more custom engineering:

• long-running sessions: context can be managed across work that spans multiple context windows;
• tool discovery and use: tools can be loaded when relevant, including MCP servers, custom functions and built-in tools;
• programmatic tool calling: generated code can coordinate multiple calls and filter results before returning them to the model;
• subagent coordination: a root agent can delegate independent work to specialist subagents;
• managed environments: developers can choose an OpenAI-hosted sandbox, their own infrastructure or a supported sandbox partner;
• session records and artefacts: the API exposes sessions, turns, traces, subagents and generated artefacts for inspection.

This changes the build-versus-buy calculation for agent infrastructure. A team can spend less time assembling a harness, but it becomes more important to understand which responsibilities remain with the application owner.

The harness is infrastructure, not governance

A managed agent can still receive an unsuitable instruction, call an overpowered tool, expose a secret, repeat an expensive action or produce a plausible but incorrect result. Infrastructure can make those actions easier to orchestrate; it cannot decide which business risks are acceptable.

The distinction is easier to see as a responsibility table:

Managed capability	Business control still required
Long-running sessions	Maximum duration, cancellation, checkpointing and stale-context rules
Tool access	Least-privilege scopes, approved destinations and action-level approvals
Subagents	Delegation limits, concurrency budgets and responsibility for combined output
Hosted sandbox	File, secret, package and network exposure decisions
Tracing	Retention, access control, incident review and privacy handling
Model choice	Task-specific evaluation, fallback behaviour and quality thresholds

NIST’s AI Risk Management Framework core treats governance as a continuous organisational responsibility. It calls for defined human roles, documented processes and accountable leadership across an AI system’s lifecycle. Buying a managed agent service does not transfer those obligations to the vendor.

Permissions are the first production boundary

The most important question is not “How intelligent is the agent?” It is “What can the agent reach, change and send?”

OpenAI’s current sandbox security guidance states that agent-generated code can access the files, credentials and network resources made available to its environment. That makes configuration part of the security model.

• Give each agent only the data and tools required for one defined workflow.
• Separate read, draft, approval and execution permissions.
• Keep payment, deletion, publication and permission changes behind explicit approval gates.
• Restrict outbound network access to approved services where possible.
• Use task-specific secrets rather than broad credentials shared across workflows.
• Make revocation fast: a compromised or misbehaving agent should be stoppable without disabling the whole business.

A sandbox limits exposure only to the boundary that the operator configures. If a powerful production key is placed inside it, the agent may still be able to exercise that power.

Long-running work needs recovery, not only completion

Short demonstrations usually reward reaching an answer. Production workflows must also handle interruption, partial progress and an incorrect intermediate decision.

Before allowing an agent to run for hours or days, define:

• what state is saved after each meaningful step;
• which actions are safe to retry and which must be idempotent;
• how duplicate emails, orders, uploads or database changes are prevented;
• what triggers an automatic stop;
• when a human must review the work;
• how the workflow resumes without repeating completed actions.

This is why a useful agent test should include timeouts, unavailable tools, malformed data, revoked permissions and contradictory instructions—not only the happy path. The MaryChuks guide A Successful AI Agent Can Still Be Unsafe provides a broader permission, recovery and handoff test.

Measure one complete workflow

OpenAI’s observability documentation says operators can inspect token usage for root-agent and subagent turns, review tool calls and export session traces. Its agent-evaluation guidance recommends using traces to diagnose workflows before formalising graders.

That data becomes useful only when it is connected to a business definition of success. Measure the complete task, not the most flattering model response.

• Outcome: Did the workflow complete the correct business task?
• Evidence: Can a reviewer see which sources, files and tool results supported the outcome?
• Intervention: How often did a human correct, rescue or reject the run?
• Recovery: Did the agent stop safely and resume correctly after failure?
• Cost: What was the total model, tool, storage, sandbox and human-review cost per accepted result?
• Latency: How long did the end-to-end task take, including approvals and retries?

OpenAI says there is no separate Agents API fee during the public beta; users pay for the models and tools they consume. That does not make a workflow costless. Multi-agent delegation, long sessions, hosted environments, external tools and human review can all increase the total cost of a successful task.

Check data location and retention before the pilot

The current Agents API overview states that the service supports data residency only in the United States and does not support Zero Data Retention. Those conditions may change after public beta, but they are material now for teams handling client, employee, health, financial or other regulated information.

Before uploading real data, identify the information involved, its lawful basis, contractual restrictions, retention requirement and permitted processing location. If the answer is uncertain, use synthetic or carefully minimised test data while legal and security review catches up.

Who should pilot it—and who should wait

The public beta may suit a team that has a defined multi-step workflow, technical capacity to integrate an API, representative test cases and a person accountable for the result. Examples include internal research packs, software maintenance in a controlled repository, document review with fixed policies or back-office preparation that ends in human approval.

A team should wait if it cannot define the workflow, has no evaluation set, needs unsupported data-residency or retention guarantees, or intends to give the agent irreversible production access on day one. A conventional script, a single model call or a human-operated checklist may be cheaper and safer for a narrow, stable task.

A seven-control pilot plan

1. Choose one bounded workflow with a measurable accepted outcome.
2. Build a representative test set, including failure and recovery cases.
3. Grant the smallest practical tool, file, secret and network permissions.
4. Place irreversible or external actions behind human approval.
5. Set time, token, tool-call and subagent-concurrency budgets.
6. Review traces, interventions, costs and errors after every pilot run.
7. Expand only when the workflow repeatedly meets its quality, safety and cost thresholds.

The Agents API lowers part of the engineering barrier to long-running agent systems. It does not lower the standard of evidence required before those systems are trusted with real work. The competitive advantage will not come from having the longest-running agent. It will come from designing the clearest boundary between what the agent may do, what it must prove and what a human must still decide.

---

Featured image disclosure: conceptual editorial illustration generated with AI.