How OpenAI's Agents API Changes the Economics of AI Work

OpenAI's Agents API is built to run cloud agents across lengthy sessions, equipped with tools, sandboxes, files, context handling and subagents working in parallel. An agent can look into a problem, run code, hand work to others, keep intermediate results and carry on until the job is finished.

That shifts more than how developers build agents. It shifts how a company should count what they cost.

A single request can now trigger a chain of model turns, tool calls, sandbox operations, retries, stored artifacts and human approvals. Tokens still appear on the invoice, yet they no longer tell you what the work really cost. The unit worth tracking is the finished task: correct, recoverable, auditable, and worth what it took to produce.

A request is not a unit of work anymore

An ordinary model call has a clear edge. The application sends input, the model returns output, and the application goes on with its day.

The Agents API is designed for a different kind of run. The agent receives an objective and chooses how to pursue it. Say you ask one to look into a jump in 5xx errors:

Find out why service-api has seen an unusual increase in errors over the last 30 minutes and recommend a safe mitigation.

A conventional assistant would describe how an engineer might investigate. An agent wired into the right systems can start doing it. It checks recent deployments, queries application logs, compares dependency versions, looks at infrastructure metrics, delegates separate analyses, runs diagnostic code, saves evidence and waits for approval before changing anything.

The user sees one request. The system carried out a whole workflow.

OpenAI's practical guide to building agents calls this a "run": a loop that continues until the agent completes the task, produces a final output, hits an error or reaches a configured limit. The cost builds up inside that loop.

The runtime has a hidden bill

Tokens are part of the bill. They're just the part that's easiest to see.

Back to the production incident. First the agent pulls recent error rates from a monitoring tool, then reads the deployment history, then searches the logs. Every one of those calls has a price, a delay, a set of permissions and its own way of breaking.

Then the logging tool returns 500 records. That sounds helpful until you follow what happens next. The records have to be moved, processed and placed in the model's context. Most are irrelevant, and the model spends time reading noise before it finds the five events that explain the incident.

So tool design is cost design. A search tool that returns a short structured summary can be cheaper and more dependable than one that exposes every matching record. The API's answer is tool search plus programmatic tool calling, which can reveal tool definitions only when needed and filter or combine results before they reach the model.

The same logic covers sandbox execution. A diagnostic script consumes CPU, memory, storage, package-installation time and perhaps network access. If it produces a report or an evidence bundle, those artifacts must be stored, indexed, reviewed or retained.

Long agent runs produce more than text, too. Investigating an incident, the evidence behind a diagnosis can outweigh the written summary. In coding work the patch is one piece of the output, while test results and a dependency analysis can be just as valuable.

A small Agents SDK example shows where the execution boundary sits:

from agents import Agent, Runner, function_tool
@function_tool
def get_error_rate(service: str, minutes: int = 30) -> str:
    """Return the recent error rate for a service."""
    return f"{service}: 8.4% errors over {minutes} minutes"
investigator = Agent(
    name="Incident investigator",
    instructions=(
        "Investigate the incident, use evidence, and recommend "
        "the safest next action. Do not change production state."
    ),
    tools=[get_error_rate],
)
result = Runner.run_sync(
    investigator,
    "Investigate the elevated 5xx rate in service-api."
)

The function is tiny. The economics aren't. All of this is up to the agent: whether it gets called, called a second time, how its result is read, and whether another tool or a human approval is needed.

Reliability, control and acceptance define success

The SDK supplies the runtime pieces behind that loop: agents, runners, tools, handoffs, sessions, guardrails and tracing. They matter because real workflows seldom succeed in one clean pass.

The log query might time out, so the agent retries. The second query works but returns incomplete data. It rewrites the query, pulls a bigger dataset and asks a specialist agent to examine deployment history. In the end the investigation succeeds.

To the user, the agent finished the task. In economic terms, the task also included failed attempts, extra model turns, more tool calls and more elapsed time.

Retries aren't automatically waste. A retry that recovers from a transient failure may be exactly what makes an agent dependable. The trouble comes from folding those retries into one headline success figure.

Parallel agents trade time for spend

The API can split complex work among subagents that run side by side. An incident investigation might give one specialist the deployment history, a second the application errors and a third the dependency changes, while a coordinator merges their findings.

Wall-clock time may shrink since everything runs at once. The total bill may grow, because you now pay for several separate model contexts, multiple tool-call chains, coordination, a synthesis step and, quite possibly, the same ground being covered twice.

That's why multi-agent systems look like distributed systems with language models in the loop. The coordinator acts as a scheduler, the specialists are workers, external tools are services, and files and databases become shared state. The familiar troubles follow: partial failure, retries, inconsistent state, repeated work, concurrency limits and murky cost attribution. More agents don't automatically mean better reasoning. Parallelism should be justified by how the task is structured and what time is worth.

Acceptance is the finish line

Generation can end long before the real work does. For a support case, acceptance could mean the customer's problem was solved without needless escalation. For a coding task, it could mean tests pass, review standards are met and the change gets merged. In incident response it could mean a diagnosis was backed by evidence and led to a safe mitigation. The metric that follows from this:

cost per accepted task =
    total execution cost / tasks accepted without rework

If an agent answers in ten seconds and a person then spends ten minutes fixing it, the ten-second answer wasn't the cheap outcome. It was only the cheap attempt.

Having a person review the output doesn't mean the automation failed. For high-risk work, sign-off may be what makes automating it acceptable at all. What you want is the smallest human effort that still leaves real human control.

The SDK offers input, output and tool guardrails, and its documentation separates agent-level checks from tool-level ones: setups with delegated specialists may need checks around single function-tool and MCP operations. Guardrails cost effort and sometimes extra model calls. They can also head off far bigger costs from wrong actions, data exposure, policy violations or regulatory trouble. Output becomes a completed task only after quality checks and the right degree of human control.

From traces to business value

Each new tool widens what an agent can do. It also widens the system's permissions, latency, failure modes and governance needs.

The API supports custom functions, built-in tools and MCP servers. MCP standardises how AI applications connect to external tools, resources and prompts. That lowers integration friction, but it doesn't make a remote tool trustworthy by default. The MCP specification warns that tool descriptions and annotations from untrusted servers shouldn't be trusted automatically, and it recommends visible tool invocation and human approval for operations. Remote authorisation brings extra concerns such as validating the token audience, storing tokens securely, PKCE and preventing confused-deputy attacks. Every added capability creates a new authorisation, audit and governance boundary.

Traces are accounting data

The final answer reveals little of how it was reached. You can't see which tools were weighed, how many ran, whether a subagent broke down, or what prompted a person to be pulled in.

The SDK ships tracing that covers generations, tool calls, handoffs, guardrails and custom events. Tracing is usually introduced as a debugging aid, but it's also an accounting system. A trace can reveal that one tool causes most of the latency, that a workflow keeps repeating the same search, or that one model choice yields higher acceptance with fewer retries. Without traces, teams optimise averages. With them, they can optimise individual workflow stages.

The scorecard should join execution data to outcome data: the cost of each accepted task alongside how many model turns and tool calls were used, time in the sandbox, how often retries happen and how often they recover, plus rework, reviewer minutes, escalations and the value delivered. The exact dashboard depends on the workflow. A support team might care about cases closed without escalation, a platform team about incidents mitigated, a product team about revenue protected or staff time saved. What changes is what you divide by.

The strategic decision

Organisations shouldn't start by asking how to make an agent cheaper per call. The harder question comes first:

Is this agent able to handle this kind of work dependably enough that the full cost comes in under what the current process costs?

For that you need an honest baseline for the current process, covering staff time, waiting in queues, repeated handoffs, infrastructure, errors and their rework, lost opportunities and compliance effort. An agent costing $2 per accepted task can be an excellent investment when the existing process costs $20. One costing $0.10 per attempt can be a poor one if only half its outputs are accepted and every failure needs human repair.

A sensible optimisation plan begins with the simplest system able to finish the task. Use smaller models for routing, filtering or plain validation, and escalate to stronger ones when deeper reasoning is required. Make tools return compact, structured results. Parallelise only independent work. Validate consequential actions. Keep enough evidence to support review and recovery.

The SDK pays off when the runtime itself needs to handle turns, tools, sessions, handoffs, guardrails or coordination between agents. The Responses API stays appropriate when a team prefers to own the loop and the state handling itself. That choice is architectural, and it's financial too.

Measure work, not words

The Agents API makes it easier to build agents that operate across tools, environments, sessions and subagents, and the SDK provides application-level primitives to coordinate them, protect them with guardrails and inspect them through traces. Together they point to a different way of thinking about AI economics.

The request that arrives is merely the entry point, not the unit of account. The unit is the finished task, one that can be accepted as correct, recovered if something goes wrong, inspected after the fact and defended on cost. Per-token pricing is still handy as one line item. Everything else, tools, compute, storage, retries, latency, security and human attention, sits elsewhere on the invoice.

The best agent systems won't be the ones producing the fewest tokens. They'll be the ones finishing the most valuable work for a total cost that makes sense.