By Greg Nowak. Last updated 2026-09-23.
OpenAI’s Agents API takes a sizeable chunk of infrastructure off an agent builder’s plate. It can maintain sessions, orchestrate work, compact context and resume activity across long-running tasks. That makes it useful for support triage, research, reporting and file processing—work that may take far longer than a single request.
There is still an important gap to close. A durable agent session does not automatically give you a recoverable business process.
The session may persist while the surrounding workflow is left in an uncertain state. An idle event can arrive even though the latest turn failed. A completed turn can contain failed tool calls. A disconnected executor can run out its connection window, leaving your application to decide whether a retry is safe.
So the operational question is not simply, “Can the agent continue?” It is, “Can we tell exactly what happened, avoid repeating real-world actions and return the work to a known safe state?”
OpenAI manages the harness. You still own the outcome.
OpenAI introduced the Agents API in public beta on September 10, 2026. Its announcement describes a managed Codex harness for agents that may work for hours or days. The service covers context management, tool use, subagent coordination and infrastructure for retaining intermediate work. Automatic compaction allows a session to continue across context windows without requiring each application team to build that mechanism itself.
The API overview also draws a clear line around responsibility. OpenAI manages sessions, orchestration, context compaction and recovery. The customer supplies the tools and chooses the execution environment.
That distinction matters as soon as a tool can change something outside the session: write a file, update a ticket, send information or trigger another system. OpenAI may preserve and operate the agent session, but your application must still decide whether the tools did what they were meant to do—and whether the business task is genuinely finished.
| Signal you receive | What it actually tells you | What your application should do |
|---|---|---|
| Session in progress | A turn has started processing | Track elapsed time and the expected next state |
| Session action required | A function result or environment connection is needed | Retrieve the current session before acting |
| Session idle | The session can accept more input | Inspect the latest turn and its tool results |
| Turn completed | The turn reached completion | Validate the output and every material tool call |
| Connection wait expired | The submission failed | Reconcile current state before retrying |
Model the states the business cares about
A production integration needs its own state model alongside the agent session. A reporting workflow, for example, might move through accepted, running, awaiting tool input, validating, delivered, failed and escalated. Support triage could need separate states for classified, enriched, proposed and approved.
Those labels should describe business progress, not merely echo API events. The webhook documentation explains that an action-required event identifies whether a session needs a function result or an environment connection. To make the next decision, however, the application must retrieve the session and inspect the relevant call IDs, arguments or environment details. The retrieved state—not the event payload by itself—should drive the next action.
Ownership belongs in the model too. Which component records that a file was written? What proves a ticket update succeeded? When does an output become visible to the customer? Who gets notified when automatic recovery stops?
If those questions have no clear answers, the session may keep running while the people responsible for the process cannot tell whether it is safe.
Use webhooks as prompts to check, not final verdicts
The session webhook documentation describes signed HTTP events for lifecycle changes. Verify the signature before processing an event. Move slower work out of the request path so the endpoint can acknowledge the event without waiting for every downstream task to finish.
An idle event only means the session is ready for more input. It does not confirm that the latest turn succeeded. Your application should inspect the turn status or observe the corresponding completed, failed or cancelled event. Even when a turn is marked completed, individual tool calls may have failed. Their results and the final response still need checking.
The validation rule should say what evidence is required. If a research task must produce three checked artefacts, confirm that all three exist. If the agent was meant to change a file, verify the target and the resulting file state. If it proposes a support action, check that mandatory fields are present and approval rules have been met before anything is published.
In a sound workflow, “completed” opens the validation gate. It does not wave the work straight through.
Decide what a safe retry looks like
With self-hosted execution, the API can request an initial connection or reconnection and wait for up to five minutes. The documentation is explicit that this waiting period is not a durable input queue. If it expires, the submission fails. A process crash or client disconnection may also leave the application needing to retry.
Retries therefore need application-level rules. Give each business operation a stable workflow key. Record every attempted side effect. Before repeating an action, check the current external state.
Regenerating an analysis may be harmless. Sending a message, overwriting a file or updating a record for a second time is not. Unless the tool and the surrounding workflow can recognise earlier success, a technical retry can become a duplicate real-world action.
It also helps to separate transient failures from terminal ones. A connection timeout may justify a bounded retry after reconciliation. Invalid tool arguments may need correction. A rejected approval or an external system that keeps failing should usually send the work to human review. Limits on attempts, elapsed time and permitted spend prevent recovery logic from turning into an open-ended loop.
Make the manual route part of production
Fallback planning is not an academic exercise. OpenAI’s September 14 incident report says customers experienced delays or could not start turns in managed sessions. OpenAI applied mitigations, monitored the recovery and later reported that managed sessions were processing normally again.
A resilient workflow assumes that a managed dependency may be temporarily unavailable. Operators need a clear view of affected work and the ability to stop automatic retries, inspect the last confirmed state, resume later or finish the task manually. For customer-facing processes, the fallback should also define what users are told and which commitments must not quietly expire while the automation is unavailable.
Test failure before the workflow matters
Before an agent takes on operational work, deliberately exercise the awkward cases. Disconnect an executor during a turn. Return a failed tool result. Deliver an idle event after a failed turn. Take a downstream system offline, then restart the worker responsible for recovery.
The dashboard, alerts and audit trail should all tell the same story. A retry should not repeat a completed side effect. An operator should be able to see where the work stopped, what has already happened and what remains safe to do.
Greg can help map the business and API states, harden signed webhook handling, define timeout and retry behaviour, validate tool results, set spending and attempt limits, and establish a workable escalation path. The goal is not to pretend every run will succeed. It is to make failure visible, contain its effects and give the team a reliable way forward.
The Agents API provides the durable foundation. Production confidence comes from the layer built around it: explicit states, verified outcomes, bounded recovery and a manual route that works when the automation does not.
Related on GrN.dk
- Cloudflare Service Keys: Audit Old Automation Before September 30
- Your AI Gateway Can Name the User. Decide What That Log Is For
- An AI Voice Agent Needs More Than a Phone Number and a Realtime Model
Need help with this kind of work?
Review your agent workflow Get in touch with Greg.
