On September 10th, OpenAI launched the public beta version of Agents API, handing over the proxy framework that supports Codex and ChatGPT Work to developers. In the past, teams had to manage context, tool calls, task continuation, environment isolation, and multi-proxy orchestration manually. Now, a single call with API can initiate long-running tasks. Developers can still choose their running environment: they can use OpenAI-hosted sandboxes, their own infrastructure, or sandboxes provided by partners. What has changed is the entry point for development; however, "proxy reliability" has not become an automatically acquired capability.
This release is noteworthy not because there is another agent interface added to the market, but because the execution layer outside of the model has begun to be productized. Ordinary model requests usually conclude within a few seconds or minutes, whereas proxy tasks can last for hours or even days. During this time, they involve reading files, running code, saving intermediate results, calling external services, and having to know where to continue in case of failure. As long as there is no status record for any one of these steps, no matter how robust the model is, it may end up placing orders repeatedly, overwriting files, or losing work that has already been completed during retries.
What is managed is a long-task execution framework, not taking on business responsibilities for enterprises.
According to the official explanation, Agents API adopts a continuously evolving approach based on Codex and harness. It is responsible for compressing and managing context, utilizing tools effectively, coordinating sub-proxies, and saving the working state for long sessions. OpenAI manages sandboxes that provide pre-configured file systems and code execution environments, allowing enterprises to keep the execution environment within their own infrastructure. The latter approach is more suitable for regulated data and internal systems, but it means that enterprises are still responsible for network policies, image maintenance, credential injection, and log retention.
A single “API call” can easily lead to the misconception that agents can complete all tasks unsupervised. In reality, a call merely establishes a sustainable task container. Developers still need to define the objectives, range of tools, termination conditions, and format of the output, as well as determine which actions are read-only, which will modify data, and which must be approved by humans. Especially when agents are connected to email systems, payments, production databases, or release systems, permissions cannot be determined solely by whether a tool is usable; it is also necessary to limit resources, amounts, time, targets, and the number of calls.
The public beta version also has clear limitations in terms of its status. This means that the interface is now available for developers to test, but the version, quotas, features, and behaviors may still be subject to adjustments and should not be considered as mature and stable final specifications. Official customer case studies show that one user's evaluation score increased from 0.71 to 0.85, and the latency of the sub-proxy process was reduced by four times; these are test results for specific systems and cannot be directly generalized to all businesses. Due to differences in task structure, tool response times, and acceptance standards, there can be significant variations in outcomes.
For enterprises, the most important aspect of design is not to make agents “more autonomous,” but to ensure that every action has auditable evidence. A qualified execution record should at least include task inputs, models and versions, tool parameters, external responses, file hashes, manual approvals, and the final status. In the event of a network interruption, the system must be able to determine whether the last write operation was successful, and should prefer to retrieve existing results rather than submitting again. Otherwise, the more automated long tasks become, the greater the risk of duplicate payments, repeated releases, and the creation of redundant resources.
To move from demonstration to production, it is necessary to establish mechanisms for pausing, resuming, and acceptance first.
Long tasks require explicit checkpoints. After the proxy completes data collection, plan generation, code modification, and formal deployment, it should save the status at each stage, rather than waiting until the end to produce a summary. This way, even if the session is interrupted, it can be resumed from the most recent verified stage. When multiple proxies are involved, the main proxy also needs to prevent multiple sub-tasks from modifying the same resource simultaneously, and to check for conflicts, sources, and versions before merging them.
Acceptance cannot merely rely on the agent's claim of "completion." For code tasks, tests must be run and the deployment side must be checked; for data tasks, samples and total values must be verified. For content publication, the title, body, and author must be rechecked from the public page. What Agents API provides is a running framework, but whether the business is successful still needs to be proven by observable external results. It is best for companies to define acceptance criteria as boolean items that machines can check, and to set "partially completed," "awaiting approval," and "external failure" as separate statuses.
The costs will also shift from a single token fee to the entire execution chain. Long tasks will consume model inference, sandbox computing, storage, network resources, and third-party API quotas. Multiple proxies can reduce waiting times, but they may increase the total number of calls. Before going live, the full cost of each successful task should be measured, rather than just comparing the price per million token for a particular model. Failed retries and manual reviews also need to be taken into account; otherwise, the efficiency improvements demonstrated in the early stages can easily be offset by exceptional handling when scaling up.
Agents API has transformed a set of complex yet repetitive infrastructure into a public product, lowering the barriers to development. This step may enable more teams to move from "chatbots" to systems that actually perform tasks, but public testing does not mean that the control mechanisms can be bypassed. The most prudent approach is to start with reversible tasks that require low permissions and whose results are easy to verify, and then gradually allow write operations. How long a proxy can run is not the key metric; whether it can clearly indicate what it has done at each step, leave evidence, and stop when encountering uncertainties is what determines whether it can be put into production.
