The New Agents API Makes the Harness a Product Decision

For a long time, agent demos made the model call look like the product. Give a model a task, expose tools, loop until it stops. Production work has been steadily teaching the opposite lesson: the surrounding harness decides whether the agent can hold context, recover after interruption, use tools safely, show evidence, and finish a job that lasts longer than one request. OpenAI’s new Agents API makes that harness available as managed infrastructure. I see that as more important than the convenience of creating an agent session with one API call.

The unit is now a durable session

The Agents API announcement describes sessions that can run in hosted or connected environments, use MCP and other tools, stream progress, compact context, recover, and delegate to subagents. That is a different product surface from a stateless prompt and response.

It means teams need to decide what a session is allowed to know, where intermediate files live, how long state remains useful, and what happens when the original requester returns hours later. Persistence is valuable, but stale authority and stale assumptions persist too.

Environment choice is part of the threat model

A hosted sandbox reduces the operational burden of building execution infrastructure. A private environment may be necessary for data locality, network controls, or specialized dependencies. The correct choice is not purely about speed or price.

I would classify tasks by data sensitivity, required connectivity, compute profile, and blast radius. A documentation refactor and a production incident investigation should not automatically receive the same filesystem, secrets, or network.

Tools are contracts, not capabilities to sprinkle in

An agent becomes useful through tools, but every tool creates authority. A read-only search is different from sending an email, editing a record, deploying code, or spending money. Tool schemas should expose the narrow business action, validate inputs, return structured evidence, and separate preparation from commitment where a human confirmation is appropriate.

The safest useful agent is not the one with no tools. It is the one whose tools make authority legible.

This is also a product-design concern. Users need to understand what the agent is about to do without reading internal implementation details.

Multi-agent work needs an economic reason

Parallel subagents can shorten independent research or analysis, but delegation adds tokens, coordination, and another place for context to diverge. I would use it when work can be separated cleanly and recombined against an explicit acceptance test.

Three agents editing the same small file are not collaboration; they are a merge problem. Three agents independently checking deployment, error, and dependency evidence can be useful if a coordinator owns the final claim.

The evaluation should measure recovery

A happy-path score misses the distinctive risks of long-running agents. I would test interrupted sessions, expired credentials, unavailable tools, partial writes, user corrections, changed external state, and resumption after context compaction. The output should include what changed, what remains uncertain, and where the evidence came from.

For business owners, the question is not “did the agent generate a plausible answer?” It is “can this workflow be supervised, audited, and safely resumed at a cost lower than the work it replaces?”

Cost controls belong in the workflow definition too. Durable sessions can accumulate model usage, browser time, storage, and repeated tool calls long after a synchronous request would have timed out. I would set budgets for elapsed time, tokens, external calls, and retries, then require the session to summarize progress before asking for more. A useful stop condition can be as important as a capable model.

Human takeover should preserve state rather than restart the job. The reviewer needs the current plan, completed actions, pending commitments, artifacts, and exact reason the agent paused. If handoff produces only a transcript, the person must reconstruct the workflow under time pressure. Structured checkpoints turn supervision into a continuation of the work instead of an audit after the fact.

Data retention deserves a lifecycle as well. Intermediate screenshots, cloned repositories, tool outputs, and uploaded documents can outlive the useful session unless cleanup is intentional. I would attach retention to the workflow’s business record, not let every execution environment become a permanent shadow archive.

I would expose a compact session status to the customer: running, waiting for approval, waiting on an external system, completed, failed safely, or stopped by budget. Those states make long work understandable and reduce the temptation to start duplicate sessions because nothing appears to be happening.

I would start with one bounded workflow

Choose a job that already has written inputs, a controlled environment, observable outputs, and a human review point—perhaps preparing a release package, reconciling a report, or investigating a known class of support issue. Define success and forbidden actions before adding tools.

The Agents API lowers the cost of obtaining a capable harness. It does not remove the need to design the workflow around it. In fact, by making orchestration easier to buy, it makes the remaining product decisions clearer: environment, authority, evidence, recovery, and the point where an agent must hand control back to a person.

Photo by Ibrahim Boran on Pexels.