OpenAI Agents API Adds Computer Use and Multi-Agent Tools

OpenAI’s Agents API now supports computer use, allowing an agent to operate software through its user interface instead of relying solely on a purpose-built integration. At DevDay on September 29, OpenAI also announced multi-agent capabilities, tool search and calling, and context compaction for the API.

The API itself is not new. OpenAI introduced it in public beta earlier that month, with a managed agent loop and options for where agents run code. The DevDay announcement expands what developers can put inside that setup.

An agent that can use software interfaces, coordinate with other agents, and keep running on managed infrastructure can take on more than a prompt-response task. Builders also have to consider access, cost, and how much authority to give an agent over a real account or application.

The Agents API Was Already Running Before DevDay

OpenAI’s original Agents API announcement preceded DevDay. In a September 10 developer community announcement, the company described a public beta in which OpenAI runs the agent loop, coordinating model calls, tool use, and context during a task. Developers define the agent’s capabilities and choose an environment for its code and files.

Managed orchestration and sandbox options were part of that earlier launch. The September 29 update adds computer use to the Agents API and puts greater emphasis on agents working together, finding tools, and managing context over longer tasks.

OpenAI’s DevDay developer roundup describes the Agents API as a public beta with hosted execution, memory, tools, and multi-agent support. Public beta signals developer access. It does not promise that every feature is enabled for every account or suitable for an unattended production workflow.

Computer Use Extends Agents Beyond Custom Integrations

Computer use lets an agent operate software through its UI, according to OpenAI. Some applications have no suitable API for a particular action; others expose only part of what a person can do on-screen. A UI-capable agent may be able to work through those gaps.

Software interfaces also introduce different failure modes. A tool call to a defined API has a specified operation and response. A UI can change layout, show an unexpected dialog, or contain text the agent should treat as data rather than an instruction. Developers need to decide which applications an agent can reach, which actions require approval, and how to check that an intended change actually occurred.

The announcement does not give an agent unrestricted control of a developer’s own laptop. It concerns agents operating software through a UI within the Agents API’s execution setup. The device, account, permissions, and environment available to an agent depend on how the developer configures that setup. OpenAI’s computer-use documentation is the relevant place to check implementation details before granting access to a live system.

There is a useful difference between attempting an action and verifying its outcome. An agent might navigate to a form and submit it, but a successful run is not, by itself, proof that the underlying record changed correctly. For consequential workflows, the application’s resulting state needs to be checked separately.

Multi-Agent Work Adds Coordination, Not Automatic Reliability

OpenAI says the expanded API supports multiple agents, tool search and calling, and context compaction. Each addresses a different problem. Multi-agent support lets developers divide work among agents. Tool search helps an agent locate a relevant tool without having every option placed in front of it at once. Context compaction helps manage the information an agent carries through a longer-running task.

A developer could design a process in which one agent gathers information, another acts on it, and a further step checks the result. The capabilities make that kind of workflow feasible; they do not guarantee it will run correctly without configuration or supervision.

Each handoff is another place for incomplete or misleading information to travel. A managed runtime does not make such mistakes disappear. Developers still have to specify what each agent may do, what information it may pass along, and where human review belongs. Teams using context compaction should also test whether details essential to an approval, instruction, or audit trail remain available as a task continues.

OpenAI Hosts the Loop, but Developers Choose the Sandbox

“Hosted execution” can obscure an architectural choice. OpenAI said at the API’s launch that it manages the agent loop on its infrastructure. Developers separately choose where an agent runs code and works with files.

One option is an OpenAI-hosted sandbox. In its September launch post, OpenAI said developers could supply files, install packages, and add skills or plugins while it provisioned and managed that environment. The company also described options for connecting other sandbox providers or using a developer-controlled environment.

An agent handling internal files may need different network access, secrets, storage, and isolation from one producing a disposable artifact. A hosted agent loop does not mean OpenAI must host every file or every piece of code the agent touches. Choosing an external sandbox does not remove the need to control which tools and accounts the agent can use.

Developers can use OpenAI-managed orchestration without assuming a single execution environment fits every workload. They still have to evaluate that environment’s permissions and cost.

Access and Pricing Need Separate Checks

OpenAI lists the expanded capability as available through the API and in Codex and ChatGPT Work for Pro 500 and Enterprise customers in its DevDay recap. These are different ways of accessing OpenAI products. A ChatGPT or Codex subscription is not interchangeable with API access, and the announcement does not establish identical eligibility for every capability across those surfaces.

For API builders, the earlier public-beta launch is the clearer starting point. OpenAI’s September 10 community post said the Agents API was available to all developers in public beta. It also said there was no additional fee simply for using the API; developers paid for the tokens and tools their agents used. In the same discussion, an OpenAI representative said OpenAI-hosted sandboxes used standard container rates, with model usage billed separately.

That launch-era description is not a complete price quote for every configuration announced at DevDay. A computer-use workflow may consume model tokens, invoke tools, and keep a paid environment running. Developers planning to deploy one should check current rates and account eligibility for their specific model, tools, and sandbox rather than assume “hosted” means included.

The supplied announcements do not establish feature-by-feature quotas, regional access, or whether an individual account needs additional enablement. A team deciding whether to prototype through the API, use a product surface, or commit to a production rollout will need those details.

Final Thoughts

Computer use now sits alongside multi-agent coordination in an API whose agent loop OpenAI already manages. Developers have a more direct route to agents that work across software interfaces, while responsibility for permissions, costs, and outcome checks remains with them.

I’d judge this update by how well developers can constrain and inspect real workflows, particularly when one agent hands work to another or acts through a UI designed for a person. Broader capabilities make an agent easier to deploy; clear boundaries and verifiable results determine whether it is safe to rely on.