Browser work enters the managed agent stack
OpenAI added computer use to the Agents API on 29 September. The company says agents can complete tasks in an OpenAI-hosted browser, with website access approvals and sign-in handled by the developer’s application. That changes the practical scope of a managed agent session. Instead of working only through purpose-built APIs and text returned by tools, an agent can navigate pages and operate a browser interface when a service has no suitable API or when the user’s task is inherently visual.
The documentation names testing a website, collecting information and using an application through its interface as examples. These are useful categories, but they are not promises that every site or workflow will work. Interfaces change, pages load unpredictably and authenticated services may require steps an agent cannot safely complete without a person. The feature should therefore be treated as a controlled automation surface, not as a substitute for stable integrations where those exist.
How the session is structured
An application starts an Agents API session and follows its events while the agent observes the hosted browser and decides what to do next. The documented setup includes the computer-use tool and an OpenAI-hosted environment with desktop access enabled. The sequence then moves through a browser session, a task, site-access requests and any sign-in challenge. The application remains responsible for those approvals; the agent does not simply receive unrestricted access to every website.
OpenAI advises developers to wait for the agent’s turn to finish and verify the result. It also describes recovering the same session after a connection drop, reviewing saved browser activity and deleting the session when finished. Those steps are important because a browser task can have side effects. A submitted form or changed setting may not be obvious from a final natural-language summary, and a network interruption is not evidence that an earlier action failed.
Approval boundaries are the product decision
The most consequential design choice is which origins the agent may visit and what to do when it reaches a login. A read-only information-gathering task has a different risk profile from an agent allowed to update a billing account or publish content. Developers should define an approval policy before deployment, provide a clear account of requested access to the user, and make the human checkpoint explicit for consequential actions. The platform’s approval hooks support that control, but the application must implement it sensibly.
Access should be narrow and task-specific. A broad instruction such as “finish the setup” can hide several decisions that require human judgement, including accepting terms, selecting a plan or sharing data. The agent may be capable of clicking through them, but capability is not authority. For organisations, audit records should capture the instruction, browser origin, approval decision and observed result so reviewers can reconstruct what happened.
Verification must be independent
Browser automation often produces convincing narratives even when the underlying action did not stick. A robust workflow checks the destination state after the agent reports completion. For a site test, that might mean a screenshot plus an independent assertion about the rendered page. For a business process, it might mean a read-back of the updated record or a confirmation from the relevant API. If the target site exposes neither, the product should describe the remaining uncertainty plainly.
Recovery deserves the same discipline. Replaying a task after an ambiguous interruption can duplicate an order, message or configuration change. OpenAI’s advice to recover the same session is a reminder that agents need durable state and idempotent application design. Developers can reduce risk by separating observation from mutation, making high-impact steps require explicit confirmation and checking existing state before any retry.
Where it fits
Hosted browser computer use is particularly attractive for workflows that span several services and cannot be completed by search alone. It may also help teams prototype an integration before investing in a dedicated connector. Its limitations will be clearest where a site blocks automation, relies on dynamic controls or presents sensitive decisions. The correct performance measure is not how many clicks an agent makes, but whether it reaches the intended state safely and repeatably.
The 29 September announcement establishes the feature’s arrival; the Agents API guide explains its current operation. Teams considering deployment should run supervised trials with limited accounts, explicit access rules and a written success check. That approach preserves the benefit of browser flexibility while keeping responsibility for credentials, permissions and final outcomes with the application and its users. Before a broad rollout, they should also test accessibility variants, session timeouts, unexpected pop-ups and changes to a site’s navigation. These mundane interruptions often determine whether an automation is genuinely dependable in everyday business use. Publishing a clear audit trail and a manual recovery procedure will matter more than a flawless demonstration on a single page.