OpenAI Agents API: What Moves Out of Your Application

The OpenAI Agents API moves the machinery that runs an agent into a managed service: the model-and-tool loop, session orchestration, context compaction and recovery. Your application still owns the product around that machinery. It connects users to sessions, implements private tools, checks permissions and decides whether the requested business outcome actually happened.

OpenAI announced the public beta on September 10, 2026 in its release notes. This guide evaluates the documentation reviewed on September 12. The decision is whether maintaining your own agent loop is useful differentiation, or infrastructure you would prefer to delegate. A managed loop can reduce implementation work without removing the need for an application server.

The harness is the software that repeatedly calls a model, dispatches tools and feeds their results back into the task. In the Agents API overview, OpenAI exposes the Codex harness through an API. An agent supplies instructions and tools; a session is a durable instance of that agent doing work; events and items represent its inputs and outputs.

That is a meaningful architecture choice for teams whose application currently maintains its own loop. Compare the code you can remove with the behavior you must preserve. A custom retry policy, context-selection rule or tool scheduler may be deliberate product behavior. Establish how it maps to the managed service before treating the migration as an endpoint change.

For example, a research assistant may need search, document retrieval and a saved conversation, but no writable computer. A report-building assistant may also need packages, a working directory and an exported file. These are different execution requirements even when both assistants use the same model.

The architecture guide separates the harness from its execution environment. Without an environment, the agent can use configured remote MCP tools or application functions. Built-in Bash, apply-patch and workspace files are unavailable in that configuration.

With an OpenAI-hosted environment, OpenAI provisions and manages the sandbox while you configure the files, packages and network access the task needs. With a self-hosted environment, your application provisions compute and connects an executor. You then own its reconnection, shutdown and file preservation.

A private network requirement can make self-hosted execution useful, but it also leaves more operations work with your team. Choose it because of a concrete dependency or control requirement. Do not add an environment merely because agents are often demonstrated with a terminal.

Function tools still need code that receives a call, executes it and returns a result. If that handler is unavailable, the agent can wait for the missing response. Managed orchestration does not make a private database or business service available by itself.

Use the authenticated user and the specific operation to decide what a tool may do. A model-generated argument can identify a proposed target, but it should not grant access to it. Store an operation record when an action has consequences, and return the authoritative result instead of an optimistic sentence.

Consider a hypothetical document workflow. Generating a draft is one action; publishing it to a customer portal is another. The application should preserve that distinction even if the agent describes both in one plan. The draft, saved and published reference addresses the wider status vocabulary; here the migration must keep those application checks intact.

The sandbox lifecycle documentation explicitly separates session life from environment life. Reusing an environment ID does not restore files on replacement compute. It also says pending input is not guaranteed to recover after a process crash. Check the actual request or session result before retrying.

Build a recovery exercise around an interrupted task. Retain the session ID, the application operation ID and the location of any required artifact. Reconnect or replace compute as appropriate, then inspect whether the original tool succeeded. If the result is uncertain, query the system that owns it before submitting a duplicate action.

A stream ending tells you about the connection. A final agent message tells you what the agent reported. Your acceptance check should inspect the output or external state you promised the user. The session-state responsibility reference provides a field-by-field inventory for that review.

The Agents API overview lists model usage at the selected model’s API rates, tools at their standard rates and hosted sandboxes at container rates. It does not make the cost of a task a single model-token figure. Your own tool services and any self-hosted compute also belong in the comparison.

For a pilot, record the same accepted task under the current and proposed architecture. Include engineering maintenance, failed runs, waiting compute and review effort. Keep those categories separate so an infrastructure simplification is not reported as an unmeasured model-quality improvement.

Use the AI access expansion evidence guide for the decision record. A beta can be worth evaluating while still leaving unanswered questions about your workload. Verify account access, applicable data terms and required operational support before making a production dependency.

Select a task with a clear result and a bounded set of tools. Write down the current behavior, including interruptions, user corrections and failure messages. Then assign each responsibility to the managed harness, the environment or your application. Any unassigned responsibility is a migration gap.

Exercise successful completion, a missing function handler, a dropped stream and replacement compute. For each case, check both what the user sees and what remains in the authoritative store. These are proposed pilot checks, not tests performed for this article.

Keep the existing path available until the managed version can produce the required result and recover within your operating constraints. For implementation planning, our AI transformation service starts with that task boundary and its acceptance evidence.

As-of date. September 12, 2026. The article is dated September 10, 2026; current documentation was reviewed later.

Method. Primary documentation and research were reviewed for the cited distinctions. Tables, worksheets and pilot checks are Digital Applied proposed methods, not observed deployment results.

Limitations. No production API workflow, vendor benchmark or participant study was executed for this article. Documentation can change; verify the selected configuration before implementation.

The guide’s first four decisions each have a tempting shortcut. The illustrative migrations below take one shortcut each. They are patterns drawn from the documentation’s own boundaries, not observed deployments.

Each shortcut is cheap to avoid at design time and expensive to discover in production. The responsibility map in the next section is the design-time tool.

The pilot section asks for every responsibility to be assigned to the managed harness, the environment or your application, and says an unassigned one is a migration gap. The map is a short table with those three columns and a row per responsibility. The rows that recur: the model-and-tool loop; context compaction; session durability; execution of built-in tools such as Bash and apply-patch; function handlers for private tools; permission checks on the authenticated user; operation records for consequential actions; artifact retrieval; compute reconnection and shutdown; and acceptance of the result.

An illustrative map for a report-building assistant puts the loop, compaction and session durability under the managed harness, as the overview describes. Built-in commands and the working directory go under a hosted environment, with the application configuring packages and network access. Function handlers, the permission check on who may request which report, the operation record for each export and the acceptance check that the exported file opens and contains every section stay with the application, because the documentation reviewed here does not move them. Compute reconnection belongs to the environment column for hosted compute and to the application column if the team self-hosts.

Two rows are easy to leave blank on the first pass: who preserves artifacts across replacement compute or environment expiry, and who decides the result is accepted. Acceptance stays with the application. For artifacts, an OpenAI-hosted environment publishes files saved under /workspace/outputs when a turn completes, but the application still has to direct output there and download what it must keep; a self-hosted environment leaves preservation entirely to the application. Both are the rows the lifecycle section warns about. Fill them before the pilot, then run the four exercises the pilot section lists against the map, checking what the user sees and what remains in the authoritative store for each.

Draw the map for one workflow this week, with the three columns and the rows above. Where the application column is longer than expected, that is the honest size of the migration; where the harness column is long, that is the work the managed service removes.