GPT-Live native Decisions: integration and acceptance checks

What changed on October 15

OpenAI added native Decisions integration to GPT-Live on October 15, 2026. The Decisions API beta had already launched on October 6; this is an integration update, not its initial release. This guide reviews official documentation for teams selecting or building a voice workflow. uAgentKit has not run an API call or measured latency or billing for this integration.

Choose the decision boundary

Native delegation lets Live call Decisions directly; custom delegation routes that call through your app. Use session.delegation for recognized requests, or session.triggers for input/output transcript deltas. These are different activation paths. Neither removes the application’s responsibility for authorizing and verifying actions.

Keep delegation configuration and events aligned

Require api.decisions.write; use ordinary Live headers, without a Decisions-specific alpha header. The delegation type is fixed at session creation. Send session.update for question changes and await matching session.updated before adding the next decision item. Voice examples use choice questions. For delegated actions, correlate session.delegation.created and decision.event by delegation ID. Read named answers on decision.completed; none means no action. Execute, verify the actual state, then use session.commentary.append with that request’s delegation ID.

Handle transcript results separately

Transcript triggers run independently of delegation; the official result example has delegation_id: null. Allow decision.event and the configured transcript events through filters. Associate results by trigger_id, source_event_type and source_event_id, not an assumed delegation ID. Pending deltas may combine and results may arrive out of order.

Define application acceptance before connecting an account

Start with an offline fixture and one reversible action, such as selecting a view in a demo dashboard. Write the authorized action list, allowed targets and the person who can approve expansion. Validate answer type, question name and choice value against the active configuration. An unexpected value should create a reviewable failure, not a guessed action. This is our suggested application policy, not a provider guarantee. Extra services used by the application need their own permission review.

Use a small failure matrix

The following are proposed checks using synthetic events. They have not been executed against the API. Decide the expected application state before implementation so an apparently successful voice reply cannot substitute for evidence.

Make freshness a workflow rule

Choose how long a decision remains relevant to your task and when a newer input supersedes it. Keep separate input and output histories, track the configuration revision, and record why an event was accepted or ignored. These are proposed controls for your application, not a documented universal timeout. Ask the user to clarify when a late event cannot safely be tied to the current request.

Evaluate the complete task

If an authorized trial follows, record recognition, decision delivery, application execution, state verification and spoken confirmation separately. Count failures and retries as well as successes. Inspect actual usage and charges before comparing costs. The skipped application round trip is an architectural difference; it does not establish a measured speedup for your workflow. Use the evaluation guide below to set acceptance thresholds, or contact us with a workflow-selection question.

Continue your comparison

Evaluate an agent with a small, reviewable task →

Place human review in an agent workflow →

Compare no-code workflow approaches →

Discuss a workflow selection question →