OpenAI Agents API: What Managed AI Agents Mean for Business Workflows

What OpenAI announced

On 10 September 2026, OpenAI introduced the Agents API as a public beta. OpenAI describes it as a way to build and run cloud agents using the Codex harness, with OpenAI managing infrastructure involved in long-running work. Its documentation names sessions, orchestration, context compaction and recovery among the services it manages. Developers supply tools and choose the execution environment.

OpenAI’s documentation describes agents that can work in sandboxes, execute code, edit files, connect to MCP servers and produce artifacts. It also describes durable sessions that can receive later input. These are OpenAI’s descriptions of the product. MindFish has not implemented or tested the Agents API for this article.

From answering questions to carrying out defined work

Our interpretation is that the release reflects a broader move from a single chatbot response toward systems that plan steps, call tools and return work products. For a business, that can mean investigating a request, gathering information from approved sources and preparing an output for review. The useful question is not whether a model can chat, but whether the surrounding workflow is safe and repeatable.

Managed infrastructure can reduce the amount of runtime machinery a development team has to build. It does not decide which records the agent may access, which actions require approval or what happens when information conflicts. Those choices belong to the business and the people designing the workflow.

Costs and claims need careful reading

OpenAI’s pricing documentation says model use is charged at the selected model’s rates, with tool and hosted sandbox usage charged at their standard rates. Managed does not mean free. A longer agent run, repeated tool use or large context can change the operating cost, so measurement should cover complete tasks rather than one isolated request.

OpenAI’s announcement includes customer testimony about evaluation and latency improvements. Treat that as an attributed vendor-published account, not an independent benchmark or prediction for another organisation. Results depend on the task, data, model, tools and evaluation method.

Where businesses still carry responsibility

A useful agent design limits tools to the minimum needed. Reading a customer record is different from changing it, and changing it is different from sending a message or approving a refund. Permissions, logging and human approval should reflect those differences.

Tool results and documents should be treated as information rather than instructions with authority. Testing should include missing data, contradictory sources, unavailable tools and attempts to make the agent exceed its role. The business also needs an owner for monitoring, cost limits, credential renewal and changes to the workflow after launch.

A cautious first use case

A sensible first pilot might be read-only: investigating a support or operations request using approved documents and producing a summary with references. The agent would not alter systems or contact customers. A staff member would check whether the summary is accurate and useful. This is an illustrative suggestion, not a tested implementation.

If the read-only version is reliable, a business could consider proposing actions for approval. Expanding authority should be a deliberate decision based on evidence from its own tests, not an assumption that a more capable runtime makes autonomous action appropriate.

What this means for Australian businesses

An Australian SMB does not have to build directly on an agent API to assess its relevance. Vendors and implementation partners may use managed agent infrastructure inside products and workflows. Ask what data is processed, where actions are approved and who supports the system.

Assess privacy, security and supplier obligations before connecting customer or employee information. Beta availability, account terms and current product details should be checked at the time of any project.

Practical next steps

1. Identify one bounded task where an agent would add value beyond fixed automation.
2. Start with read-only access and outputs that a staff member reviews.
3. List permitted tools, data, step limits and prohibited actions.
4. Test cost, failures and contradictory information on representative examples.
5. Assign ownership for monitoring, maintenance and expansion decisions.

Explore business AI agents