Rent the Agent Harness, Own the Success Signal

A long-running agent can stop while the work is still unfinished. OpenAI opened the Agents API to public beta for all developers on 10 September 2026. For product designers and engineering leads shipping long-running agents, the build-versus-buy question is which layer creates the trust users can see and verify.

Rent orchestration, not the user's trust

It exposes the managed orchestration stack — session handling, context compaction, subagent coordination, and hosted sandboxes — and is described as the same infrastructure behind Codex and ChatGPT for Work. If your product does not need to replace that internal loop, rent session state and orchestration. The client stays thin: it asks the harness to continue a session and surfaces milestones, while the platform handles the internal work.

The harness itself is not billed as a separate charge. That removes a cost reason to rebuild session bookkeeping, but it does not remove the design question. The platform can carry the internal loop, while your team keeps the user-visible contract: the state users can inspect, the execution boundary they can understand, and the success signal they can rely on. When a team spends weeks on retries, token budgets, and subagent handoffs, ask whether that work changes what the user sees. Rent the layer when it does not. Keep it close enough to test, audit, and redesign when it does change what the user sees.

Put execution behind the data boundary

Choose execution after the success contract, not before it. You can point work at OpenAI's hosted sandbox, your own environment, or a connected sandbox provider. OpenAI has named nine sandbox partners for the API, which gives the product team a shortlist of execution environments. The options are useful, but the data and control constraints still shape the product.

Session state remains with the service, data residency is currently limited to the United States, and zero-data-retention support is unavailable. Treat those limits as product constraints when your users are in regulated industries. The execution choice should be visible in the product, not hidden in an architecture diagram. A decision memo should name the execution path, the data boundary, and the control points your team must keep. If your team must keep execution inside its own boundary, say so plainly in the user flow. If the answer is a partner sandbox, the flow should name the provider and the tools it enables. If you need provider-specific tooling, make that tradeoff part of the success contract.

Make success a receipt, not a green check

A finished turn should not be treated as confirmation that all tool calls worked, and an idle event on its own does not indicate success. The UI should separate platform completion from the state your users can rely on. A completion panel can list which tools ran, which artifacts changed, which checks passed, and what the user should verify next in plain language.

The trap is a green check that appears when the agent goes quiet. The redesign is a receipt that clearly shows the work, the evidence, and the next human action. Silent tool-call failures need a visible state, not a missing row. A subagent that changes a file should show the file, the change, and the timestamp. A user who cannot tell what happened has no finished product; the agent only stopped.

Build the success contract before the first demo. The receipt should answer four questions:

• What outputs the user expects
• Which tools may run on their data
• What data leaves the client
• What verification marks completion

When a turn ends, the interface should audit rather than celebrate. Show what the agent attempted, what it verified, what it could not verify, and what the user should do next. A finished turn is a transport event; the product outcome is the artifact, the changed state, and the evidence the user can inspect. Keep the receipt visible until the user confirms the result, not until the spinner stops or the agent goes idle.