TL;DR
OpenAI's Decisions API is a fast classifier, not an authority engine. It evaluates supplied text, images, or JSON and normally returns one of three typed answer shapes: a probability for a predicate, one choice from a fixed set, or a score against ordered levels. It can return a refusal instead.
OpenAI made the API generally available on October 22, 2026 and says it can return typed answers up to 10 times faster than GPT-6 Luna through the Responses API. The same launch added native GPT-Live integration, which makes bounded classification practical while a voice conversation is still happening.
The useful architecture is:
evidence → typed decision → policy threshold → authority gate → action → receipt
The API can estimate whether a condition is true or choose among allowed labels. Your application still defines the labels, tests the classifier, selects thresholds, handles refusals and outages, enforces permissions, asks for human approval where needed, executes the action, and verifies the result.
That boundary matters for personal AI. A fast model can route a possible task to a review queue. It cannot decide that a person accepted an owner, granted permission, or authorized a message merely because the transcript sounded confident.
What OpenAI launched
The Decisions API is a dedicated endpoint for bounded questions inside applications and agent workflows. Instead of asking a model for prose and parsing the answer, a developer supplies shared evidence plus one or more typed questions.
The developer guide documents three question types:
| Type | Question shape | Result |
|---|---|---|
predicate | Is this condition true? | A probability from 0 to 1 |
choice | Which supplied category fits? | One supplied value, plus confidence and option probabilities |
score | Where does this input sit on an ordered rubric? | A probability-weighted score across the supplied levels |
The API currently supports GPT-6 Luna. It can evaluate text, image, and native JSON inputs, including ordered conversation messages and tool results. A single request can contain up to 400 questions. Each question can return a refusal instead of an answer without preventing other questions in the request from completing.
These are product facts from OpenAI, not independent performance findings. The "up to 10 times faster" claim is OpenAI's comparison with Luna through its Responses API. Customer speed, cost, and accuracy quotes on the launch page are customer reports selected by OpenAI. They should not be treated as a benchmark for a different workflow.
Why the GPT-Live connection matters
Voice interfaces have less tolerance for delay than offline document processing. A long pause after every sentence breaks conversational rhythm, but acting too early can turn an unfinished thought into a task or commitment.
OpenAI's new GPT-Live integration allows Decisions requests to trigger as input or output transcript events arrive. The launch demo uses a bounded choice to select an avatar expression from a fixed palette. The same mechanism could classify a support request, route a clarification, or decide whether a narrow workflow should pause.
That does not mean every transcript fragment should trigger an action. Low latency changes when a classification can run. It does not change what the classification proves.
Consider these phrases:
- "I can probably own that."
- "Let's send it tomorrow."
- "The customer approved the plan, I think."
Decision output is not business authority
OpenAI's own Agents SDK documentation draws this boundary clearly. It describes using the Decisions API for classification alongside an agent run, with the application choosing thresholds, refusal fallbacks, guardrails, approval callbacks, and model-selection mappings.
The documentation also states that a classifier implementing an editorial policy does not determine user authorization. Permissions must be enforced separately in trusted application code.
That separation produces five distinct controls:
1. Model answer: What probability, category, or score did the model return? 2. Policy: What threshold or rule maps that answer to a route? 3. Authority: Who or what is permitted to approve the exact external effect? 4. Execution: Which trusted code performs the bounded action? 5. Verification: What receipt proves what happened at the destination?
Collapsing those controls into one "AI decision" makes a workflow difficult to inspect. A confidence value is evidence about the model's output. It is not permission.
A six-step pattern for live personal AI
Use this pattern when voice or visible context should feed a bounded workflow.
1. Define the smallest useful question
Good questions have explicit answer spaces:
- Is the speaker asking for clarification?
- Which reviewed project does this action refer to?
- Does this draft contain a date that needs confirmation?
- Is this proposed action low, medium, or high consequence under the approved rubric?
2. Supply only the required evidence
The API can accept rich input, but capability is not a reason to send more context. Use the minimum permitted transcript segment, visible text, image, or structured record required for the question. Remove unrelated content before the request where the application can do so reliably.
The application, not the classifier, owns the privacy decision about what may leave the device or cross an organizational boundary.
3. Preserve the typed answer and uncertainty
Store the question name, answer type, selected option or score, probabilities, model version, and refusal state needed to reproduce or audit the route. Do not flatten a 0.54 and a 0.98 probability into the same silent "yes."
Do not store private conversation content merely to make the telemetry convenient. A useful receipt can identify the rule and outcome without becoming a second transcript archive.
4. Apply an explicit policy
Write the rule outside the prompt.
if refusal or API error:
stop and use the safe fallback
if probability < tested threshold:
ask for clarification
if consequence is high:
require the named human owner
otherwise:
route to a reversible draftThe threshold in sample code is not your threshold. Choose it from labeled examples that reflect the real input distribution and the cost of false positives and false negatives.
5. Check authority at the action boundary
Classification can route a draft to the correct queue. It should not silently grant access, send a message, accept a customer commitment, edit a public page, or change a consequential record.
For an external effect, check the authenticated actor, exact target, allowed fields, current state, and approval requirement in trusted code. Show the person the final payload when the consequence deserves review.
6. Execute and verify
After authorization, perform one bounded action and capture a destination receipt. A successful classifier call does not prove that the calendar event, ticket, message, or document update succeeded. Verification belongs after execution.
Worked example: from a meeting phrase to a project update
Imagine a product meeting where someone says, "Mina can take the onboarding experiment, and we should update the launch plan after design signs off."
A weak voice workflow extracts an owner and immediately edits the project tracker.
A bounded workflow asks three different questions:
| Question | Type | Configured answers or levels |
|---|---|---|
| Is an owner explicitly accepting responsibility? | predicate | Probability only |
| What state is the proposed work in? | choice | proposal, approved, blocked, unclear |
| How consequential is the proposed write? | score | draft, internal record, external commitment |
The phrase names Mina but does not show Mina accepting ownership. It also says design sign-off is still required. The safe route is therefore not "write approved owner and launch change." It is:
1. preserve the source moment; 2. draft an unconfirmed action for Mina; 3. mark the launch-plan update as blocked on design sign-off; 4. ask the accountable person to confirm owner, state, and destination; 5. write only after confirmation; 6. record the project system's response.
The Decisions API can make the first routing step fast. The workflow makes it trustworthy.
How to evaluate a bounded decision
Do not evaluate only whether the selected label sounds plausible. Build a small set from the cases the workflow actually sees.
Include:
- explicit and implied requests;
- corrections and speaker reversals;
- partial transcript fragments;
- missing screen or document context;
- inputs outside the allowed taxonomy;
- refusals, timeouts, and API errors;
- examples near the policy threshold;
- high-consequence cases that must always route to a person.
| Measure | Why it matters |
|---|---|
| False-positive rate | A wrong "yes" can trigger the unsafe route |
| False-negative rate | A missed case can strand useful work |
| Calibration by band | A stated probability should mean something on your examples |
| Refusal and failure behavior | The safe path must work when no answer arrives |
| End-to-end latency | The classifier is only one part of a live workflow |
| Human correction time | A fast answer that creates review debt may not save time |
Evaluate the policy and action boundary separately from the model. A classifier can be accurate while the surrounding threshold is wrong. The threshold can be sensible while the permission check is missing. A permitted action can still fail at the destination.
What Datadog's example does and does not show
OpenAI's launch page quotes Datadog as using Decisions to score the risk of agent-generated commands before execution. That is a customer statement published by the vendor, not an independently reproduced benchmark.
The public Datadog rshell repository is still useful architectural evidence. It documents a restricted shell where commands, filesystem access, environment inheritance, writes, remediation, and system services are denied by default and enabled through explicit grants. A privileged helper verifies a signed task and applies operating-system controls before execution.
The important pattern is layered control. A model-generated risk score can inform a route. It does not replace the allowlist, read-only default, signed request, sandbox, write grant, or recovery behavior. Fast classification belongs inside a security boundary, not instead of one.
Where Shadow fits today
Shadow is an AI interface for Mac that sees, hears, and runs. Current Meeting Skills can produce notes, action items, drafts, or structured results from meeting context. Current Action Skills can use voice, screen, or selected-text context and present a result for review.
Shadow does not currently claim to use OpenAI's Decisions API, GPT-Live, or the six-step architecture in this article. The framework is a design guide for personal AI workflows, not a description of Shadow's implementation.
The relevant product principle is that capture, classification, authority, action, and verification are different jobs. A personal AI interface can make the context available and produce a bounded result. It should not turn a model label into an external commitment without the checks the consequence requires.
What is real now, what is interpretation, and what remains unproven
Real now
- OpenAI made the Decisions API generally available on October 22, 2026.
- It currently supports GPT-6 Luna and returns predicate, choice, score, or refusal answers.
- OpenAI documents text, image, JSON, conversation-history, tool-call, caching, and GPT-Live support.
- The Agents SDK documentation places thresholds, refusal fallbacks, approvals, and permissions in application logic.
- Datadog's public restricted shell documents default-deny execution controls independently of the launch performance claims.
Interpretation
- The six-step pattern in this article is an original frame for separating low-latency classification from trusted action.
- Voice and personal AI workflows benefit from fast typed answers only when uncertainty remains visible and ambiguous statements can route to clarification.
- A destination receipt is part of the workflow result, not optional logging.
Unproven or limited
- OpenAI's speed comparison does not prove the same latency or accuracy on your inputs.
- Vendor-published customer reports do not replace a production-equivalent evaluation.
- A confidence value does not prove calibration on your task.
- Low latency does not grant permission, resolve ambiguity, or verify an external action.
- The Decisions API does not remove the need for deterministic rules, authentication, human review, sandboxing, or recovery.
- This article does not claim Shadow currently uses the Decisions API or GPT-Live.
The decision rule
Use the Decisions API when the question is bounded, the answer set is explicit, the latency matters, and the surrounding application can test and safely handle every answer, refusal, and failure.
Do not use a fast classifier as a shortcut around a missing policy or owner. If the result could create a promise, publish something, change a consequential record, spend money, expose data, or act outside the user's authority, place a real gate after the model answer.
If your workflow starts with meetings, voice, or visible Mac context, download Shadow and begin with one bounded Skill whose result you can inspect. Treat every external action as a separate decision with its own authority and receipt.
Sources and verification date
This article was researched and verified on October 26, 2026.
- OpenAI: Build more responsive apps with the Decisions API, October 22, 2026, for general availability, product scope, GPT-Live integration, vendor speed claims, customer reports, and published examples.
- OpenAI developer guide: Decisions, accessed October 26, 2026, for supported inputs, question types, model, request limits, caching, conversation history, and GPT-Live triggers.
- OpenAI API reference: Create a decision, accessed October 26, 2026, for answer fields, probabilities, confidence, score behavior, and refusals.
- OpenAI Agents SDK: Decisions API, accessed October 26, 2026, for application-owned thresholds, refusal handling, guardrails, approval callbacks, and the separation between classification policy and authorization.
- Datadog
rshell, accessed October 26, 2026, for the independent public implementation evidence on default-deny commands, filesystem access, write modes, signed tasks, and operating-system enforcement.
This article was written by Chad Oh, Shadow's AI writer. While we strive for accuracy, AI-generated content may contain errors. If you spot something off, let us know.