Agents API: an agent is not yet a workflow

The announcement — and the more important question behind it

On 10 September 2026, OpenAI introduced the Agents API in public beta. Developers can start long-running cloud agents and specify the model, tools and execution environment in one request. The platform handles parts of the technical foundation: sessions, context management, tool use and, optionally, coordination between subagents. Teams can choose OpenAI-hosted sandboxes, their own infrastructure or partner environments.

This matters because a significant share of agent projects has gone into the layer around the actual use case: preserving state, continuing long jobs, describing tools, collecting outputs and recovering interrupted runs.

That foundation is becoming easier to access. The product work does not disappear. Once an agent does more than answer — reading files, querying systems or preparing changes — its job, permissions and accountability need to be more explicit than they were in a chat window.

Start with a job that can actually finish

“Help our sales team” is not an agent workflow. It is a direction. A reliable first job has a clear trigger and a result that somebody can verify.

For example: after a lead has been qualified, the agent gathers public information about the company, maps the enquiry to a service, prepares a call brief and saves it for review in the CRM. It does not send a message or change pricing.

That definition settles five important points:

• Trigger: A person has marked an enquiry as relevant.
• Inputs: Form content, approved CRM fields and the public website.
• Output: A structured brief with sources and open questions.
• Boundary: No sending, no proposal and no change to commercial data.
• Owner: A named team member reviews the work and decides what happens next.

Those boundaries do not make the job less intelligent. They make it fit for production.

An agent is not a permission system

A capable model can explain why it wants to use a tool. It should not decide by itself which data it may see or which actions it may take.

Tools therefore need permissions just like any other software interface. A research agent may need read access to selected CRM fields, not an export of the entire customer database. A release-preparation agent may run tests and draft release notes, but it should not switch production without approval.

In practice, we separate tools into three groups:

1. Read: search, retrieve, compare and summarise.
2. Prepare: create drafts, files or proposed changes with no external effect yet.
3. Execute: send, publish, pay, delete or change permissions.

The third group gets additional checks and usually human confirmation. This separation belongs in the technical interface. A sentence in a prompt is not access control.

Long sessions must be resumable

The new API is explicitly designed for work that may outlast one model response. Context compaction helps carry relevant information across long sessions. A product needs more than model context, however.

A multi-step job also needs observable state outside the model:

• a unique job identifier;
• known phases and saved intermediate outputs;
• a time and cost budget;
• explicit waiting, running, approval-needed, failed and completed states;
• safe retries that cannot produce duplicate emails or records;
• a way to stop the run and resume it deliberately later.

If a two-hour process fails because a login expired, “start everything again” is not a recovery strategy. The last confirmed milestone must be visible. Durability is less about how patient a model is and more about how well the surrounding system keeps its books.

Build tools as small, honest contracts

The Agents API supports MCP, custom functions and built-in tools. The important measure is not how many tools an agent has, but how clearly each one behaves.

A tool called “solve customer problem” hides too many decisions. Narrow capabilities such as “read order by ID”, “retrieve delivery status” or “save reply draft” are easier to reason about. Each capability defines valid input, a compact result and understandable failure modes.

Good tools:

• validate input before changing anything;
• return only what the next step needs;
• distinguish not found, not allowed and temporarily unavailable;
• use a stable operation identifier for writes;
• log the action without copying unnecessary sensitive content.

The agent can plan flexibly while the system enforces hard rules.

The environment is a product decision

OpenAI separates agent logic from its execution environment: teams can use a hosted sandbox, their own infrastructure or a partner environment. This is not only a DevOps choice.

A short-lived hosted environment may suit an agent that inspects public websites and produces a Markdown document. Internal files, regulated data or existing private networks may call for an environment with tighter network and storage boundaries.

Before choosing, answer:

• Which data enters the environment?
• Which network destinations can it reach?
• Where do files and secrets live during the run?
• What remains after the job ends?
• Which records are required for support, privacy and billing?

The best environment is not the one with the most capabilities. It is the smallest one in which the defined job can be completed reliably.

Use subagents only for genuinely independent work

Running several agents in parallel sounds faster by default. It pays off only when a job can be divided cleanly.

For a competitive review, three subagents can inspect independent websites and write results into one shared schema. For a pricing decision where each step depends on the previous answer, parallel work is more likely to create coordination overhead and contradictions.

Three questions help before splitting a job:

1. Can the subtasks proceed without sharing intermediate state?
2. Do they have one common output format?
3. Who resolves contradictions and checks the combined result?

A coordinating agent should do more than concatenate text. It needs rules for missing evidence, conflicting assessments and incomplete subtasks.

Observability before autonomy

An agent run is no longer one API call. To understand failure, a team needs to see the path: job, tools used, approvals, intermediate outputs, duration, cost and stop reason.

This is not an argument for storing every internal thought. What matters are verifiable events and decisions. For the sales workflow, a dashboard might show which sources were read, which CRM fields were used, where information remains uncertain and who approved the final brief.

Before a broad rollout, run the agent against a fixed test set. Include ordinary cases, missing data, unavailable tools, manipulated web pages, duplicate triggers and jobs that must be refused. A public beta is a good moment for controlled pilots, not invisible full autonomy in critical processes.

Example: preparing a discovery call

A new enquiry arrives through the website. A person marks it as relevant, and the job begins.

The agent reads only approved fields, inspects the company's public website and collects evidence about its market, product and likely technical problems. A second independent step checks the sources and labels assumptions. The final output is a call brief with a summary, five specific questions and a list of unknowns.

The system saves the draft in the CRM and waits. A team member decides which information is sound, whether to offer a call and which message leaves the company. If research is interrupted, the run continues from the last complete step. If it reaches its budget, it stops with a visible reason.

The benefit does not come from maximum autonomy. It comes from faster repeatable preparation while the commercial decision stays with the right person.

A sensible pilot in eight steps

1. Choose a frequent, bounded job with low external risk.
2. Write down its trigger, inputs, output and responsible owner.
3. Separate read, prepare and execute permissions technically.
4. Build narrow tools with unambiguous errors.
5. Define milestones, budgets, stops and safe retries.
6. Test with realistic and deliberately awkward cases.
7. Make every run visible for support and domain review.
8. Add permissions or subagents only after reliability is measurable.

The foundation gets easier; responsibility does not

The Agents API moves a meaningful part of agent infrastructure into a managed platform. That can remove a great deal of custom orchestration work. It does not replace process design, access control, testing or a clear owner.

The right starting point is not a universal digital employee. It is a bounded job that shows its sources, respects limits, can be interrupted and ends with work a person can inspect. That is where an impressive agent demo becomes a useful product.

Sources

• OpenAI: Introducing the Agents API, 10 September 2026
• OpenAI Developers: Agents API overview