Decisions API Routing with an Explicit Fallback

OpenAI introduced the Decisions API in public beta on 6 October 2026. It gives applications a narrower interface for classification and scoring. For a small business integration, the useful first question is whether it can route a defined set of work more reliably or quickly than the current process.

Choose a reversible use such as placing a support request in a suggested queue. Keep the operational result measurable. “Add intelligence to support” is too broad to evaluate; “suggest billing, technical, delivery or manual review” gives you a bounded experiment.

Match the answer type to the job

The Decisions guide documents three question types: a predicate probability, a choice from supplied values and a score over ordered levels. At this check, the beta uses gpt-6-luna through POST /v1/decisions.

Use a choice for departments with no natural order. Use a score only where increasing levels have a defined meaning. A numerical severity score is not an amount to refund, a service deadline or a business priority until the application maps it through an agreed rule.

Keep the taxonomy small enough for the team to label consistently. If two support leads disagree about “technical” versus “installation”, fix the category definitions before tuning the model. Include a category for work outside the intended scope rather than forcing every message into an unsuitable queue.

Keep classification separate from execution

A proposed route can populate a review field. It should not also grant the destination team access to restricted records, send a customer message or change a contractual deadline.

That distinction matters even with typed output. OpenAI's Structured Outputs documentation explicitly notes that structured results can contain mistakes. A valid category is still capable of being the wrong category.

Validate the response envelope and question names. Handle refusals, missing answers and unexpected result types. The application should take these to a known fallback, not substitute the first available label. Check that the destination queue exists and that the current user may route this ticket there.

The approval versus permission note covers access boundaries. Here the extra control is a narrow mapping from an observed model result to one permitted application transition.

Calibrate the threshold on your own examples

A probability returned by a model should not be treated as a verified percentage chance of correctness for your business. Test it against labelled examples from the workflow.

Build a set covering short messages, quoted threads, mixed requests, misspellings and requests the classifier should reject. Remove unnecessary personal data. Keep separate development and release sets, and ask a second reviewer to label ambiguous cases.

For each candidate threshold, count correct routes, wrong routes and manual reviews. Pay particular attention to the costly mistakes: a service outage routed to a general enquiry queue may matter more than the reverse. Choose thresholds by that consequence, not by maximising the overall percentage of automated decisions.

For an initial deployment, it can be reasonable to suggest all routes to staff while changing none automatically. That collects disagreement evidence with a simple return path: turn off the suggestion field and continue using the existing queue.

Measure the whole routing service

Record the time from ticket arrival to usable route, including network calls, application validation and any fallback. Vendor latency claims describe their measured setup; they are not your service-level commitment.

Also record how many cases the new step sends to people, how often a person changes the suggestion and whether the route remains stable when irrelevant quoted material is added. A cheap classifier that creates extra queue transfers may cost the team more overall.

Set a request timeout and a budget for retries. If the classifier is unavailable, preserve the ticket in the original intake queue with a visible status. An unavailable AI service should not make the work itself disappear.

Version the decision rule

Save the question wording, category definitions, thresholds and model identifier as reviewed configuration. Name the owner of each rule. A category change is a workflow change and should trigger the labelled test set again.

Roll out one queue family first. Compare the pilot with the old process on correction rate and time to the right owner. Widen only when the evidence supports it. Keep the beta status in the implementation record and recheck the API contract before upgrading the SDK or depending on a new feature.

The first useful deliverable is a small table showing which cases can be routed, which need a person and what happens when the API fails. Use that record to expand the taxonomy in measured steps.

References

• OpenAI, API changelog, Decisions API announcement, 6 October 2026. Accessed 17 October 2026.
• OpenAI, Decisions API guide. Accessed 17 October 2026.
• OpenAI, Structured model outputs, handling mistakes. Accessed 17 October 2026.