OpenAI Agents API Human Approval with ActionBox

OpenAI Agents API human approval fits at the point where a managed session asks your application to return a function result. The session pauses with a required_actions entry. Your application can send that pending call to ActionBox, wait for a typed human decision, and return the result with the same turn_id and call_id.

OpenAI released the Agents API in public beta on September 10, 2026. It manages the agent harness, long-running session state, context compaction, tool use, recovery, sandboxes, and subagents. ActionBox handles a different part of the workflow: the request a person must review before your application performs a consequential operation.

OpenAI managed session
        |
        | agent.session.requires_action
        v
Your application validates the pending function
        |
        v
ActionBox creates a durable human request
        |
        | web or mobile decision
        v
Your application returns agent.session.input.tool_result
        |
        v
The same OpenAI session continues

This article explains the boundary, shows why OpenAI's own incident-response example creates a useful integration point, and covers the checks needed before an approval can authorize real work.

Agents API and ActionBox own different state

The Agents API keeps the agent session. It knows the conversation, the configured tools, the sandbox, and which function result is still pending. ActionBox should not copy or replace that state.

ActionBox stores the human request and response. It gives the reviewer a bounded description, typed choices, expiry, assignment, notification, and history. Your application remains responsible for credentials, policy enforcement, and the actual side effect.

That last distinction matters. A person can approve an attempt to roll back a service, but the rollback can still fail. Store the approval and execution result as separate facts.

Why requires_action is the integration point

The OpenAI function tools guide says a session emits agent.session.requires_action when it needs a function result. Each pending function call includes its turn_id, call_id, name, and arguments. Your application returns agent.session.input.tool_result with the same IDs, and the harness continues the turn.

The pause alone is not a complete approval system. Your application still needs to decide which functions require a person, what information the person may see, who is allowed to answer, how retries map to the same request, and what happens when the decision expires.

OpenAI's SRE incident-response example makes that division concrete. The agent investigates an incident and proposes a rollback. The application deliberately leaves propose_rollback without an automatic handler, posts approval controls to Slack, then returns the decision to the OpenAI session. The example tells production teams to persist approved remediation decisions and verify the responder's identity and production access.

ActionBox can replace that custom reviewer workflow while the OpenAI session remains unchanged.

What the ActionBox adapter changes

The adapter needs four pieces of OpenAI identity:

1. The session ID locates the managed agent session.
2. The turn ID identifies the turn waiting for a result.
3. The call ID identifies the exact pending function.
4. The function name lets the application apply an explicit allowlist.

Hash the session, turn, and call IDs into the ActionBox idempotency key. If OpenAI redelivers the webhook or your worker restarts, the same logical function call recovers the same Action instead of notifying the reviewer twice.

Do not copy the full function arguments into the Action. Tool arguments can contain access tokens, customer data, internal URLs, or fields that do not help the decision. Validate the function schema, then create a small review object from an allowlist.

For a rollback request, useful fields might be:

• Service name and environment
• Current and proposed version
• Evidence supporting the rollback
• Expected customer impact
• Rollback plan and verification step

The reviewer should see enough to judge the proposal without receiving the agent's private working state or unrelated credentials.

Return a decision without claiming execution

An approved rollback result can look like this:

{
  "type": "agent.session.input.tool_result",
  "turn_id": "turn_123",
  "call_id": "call_123",
  "success": true,
  "output": "{\"decision\":\"approved\",\"executed\":false,\"action_id\":\"act_123\"}"
}

Here, success: true means the application returned the requested function result. It does not mean the rollback ran successfully. The human answer is inside output.decision, and executed remains false until the protected operation finishes.

A rejection is still a valid function result:

{
  "decision": "rejected",
  "executed": false
}

This lets the same OpenAI session continue, explain that the proposal was rejected, and choose a safe next step. Use success: false for an application error that prevented the function from producing a meaningful result, not for an ordinary human rejection.

Streaming and webhook event names differ

There is one naming detail worth testing early. The streaming session event is agent.session.requires_action. OpenAI's project webhook example subscribes to agent.session.action_required and then retrieves the session to read the current required_actions collection.

Whichever delivery path you use, treat the retrieved session as authoritative. Do not act on an old function-call item from history. Confirm that the call is still pending before creating or resolving the matching ActionBox request.

For workers that may restart while a person is deciding, the webhook model is a better fit than keeping one process and stream open. Persist the session ID and ActionBox Action ID, verify webhook signatures, and let idempotency handle repeated delivery.

Use MCP when the agent may ask for help

The Agents API also supports remote HTTP MCP servers. ActionBox exposes a hosted MCP endpoint at https://api.actionbox.cloud/mcp with tools such as ask_human and get_action.

That creates a second integration path:

The MCP call is voluntary. An agent can decide whether to invoke it, so it should not be the only barrier in front of a protected production function. Put mandatory allow, ask, or deny policy in the application or gateway that controls the operation.

When OpenAI connects directly to ActionBox MCP, restrict the exposed tools to the smallest set the session needs. Keep the Source key in a secret manager or OpenAI vault credential. Do not include resolve_action when the goal is to collect a human response, because that tool records a Source-selected resolution rather than a human decision.

What reviewers can use today

Reviewers can receive and answer an Action through the hosted ActionBox web inbox or mobile app. The response remains attached to the Action that contains the bounded function context.

Slack review is available as an assisted Team beta. It requires separate workspace configuration and has current limitations around multi-reviewer approval policies. Describe it that way in implementation plans instead of treating Slack as a universal default.

For stricter decisions, ActionBox can restrict an Action to named reviewers and use supported approval policies in the hosted web or mobile experience. The application that owns the side effect should still verify the current actor and its own production authorization rules before executing.

Production checks for OpenAI Agents API human approval

Before connecting a real function, test these paths with synthetic data:

• OpenAI delivers the same required-action webhook more than once.
• The worker restarts after creating the Action but before returning the result.
• The Action expires or the local wait times out.
• The reviewer rejects the proposal.
• The pending function arguments change before the response arrives.
• The Action version or fingerprint no longer matches what the reviewer saw.
• The protected system rejects the approved operation.
• Returning the tool result succeeds, but the client loses the response.

Timeout, cancellation, malformed response, and stale context must all fail closed. An approval should apply to one exact function call, not every future call with the same name.

What we changed in ActionBox

The core ActionBox service did not need a new workflow type for this integration. The existing Action contract already covers the human request, typed response, stable idempotency, decision binding, expiry, notifications, and history.

We added a dedicated Agents API adapter pattern that:

• Accepts only allowlisted pending function names
• Requires an explicit review-context builder
• Routes concurrent pending functions to distinct Actions
• Binds the response to the Action version and fingerprint
• Cancels a still-open Action when the local approval wait expires
• Returns the typed decision to the original OpenAI session

The OpenAI Agents API integration guide contains the implementation and the direct MCP configuration. The existing OpenAI Agents SDK guide remains separate because its pause and resume contract uses result.interruptions and RunState rather than managed session events.

A practical first demo

Start with a synthetic propose_rollback function. Use fictional service names and a non-production target. Ask the agent to prepare a rollback proposal, route the pending function to ActionBox, answer from the mobile or web inbox, and verify that the same OpenAI session receives the decision.

Keep the first version from executing a deployment. Return executed: false and confirm the approval lifecycle works across duplicate events, rejection, and timeout. Add the real operation only after the application rechecks production access and can record the execution result separately.

OpenAI's launch expands the number of managed agents that can run for long periods and reach consequential function calls. Those calls need a clear human boundary. The Agents API keeps the agent running; ActionBox keeps the human decision durable and reviewable.

Create a free Source · Read the Agents API guide · Review MCP security

Need help choosing the first function and review fields? Email info@actionbox.cloud with a short description of the operation.

Sources

• OpenAI Agents API overview
• OpenAI Agents API function tools
• OpenAI SRE agent for incident response
• OpenAI Agents API MCP connections
• ActionBox MCP server
• ActionBox decisions and outcomes

OpenAI and Agents API are referenced for interoperability. ActionBox is an independent product and is not endorsed by OpenAI.