A model can suggest a route. Your team still needs to define the categories, handle uncertainty and test what a wrong route costs.
OpenAI made its Decisions API generally available on 22 October 2026 with gpt-6-luna. The update supports shared-input caching, images in individual question instructions, JSON input and up to 400 questions per request.
The practical opportunity is straightforward: a team can ask a model to classify incoming work in a form an application can use. The hard part is deciding what each answer should mean for the business.
A useful routing policy defines the categories, the exceptions and what happens when a request lands in the wrong place.
Start with a narrow decision
Consider an incoming support request. A team might define billing, technical support and shipping as separate routes. Each needs a clear description and examples of what belongs there. A request that says “I was charged twice and my order never arrived” exposes a policy choice: which issue takes priority, or should both teams receive it?
OpenAI's Decisions guide describes three question types: a predicate estimates the probability that a condition is true; a choice selects from supplied options; and a score evaluates ordered levels. Choice and score also return distributions over the options. Those are different tools for different questions. A severity scale needs ordered definitions; departments are categories, not a severity scale.
The API returns typed answers. Your application decides what to do with them. It does not know whether a billing label should create a ticket, send a customer message or change an account.
Give uncertainty somewhere to go
Add an “other” or “unknown” route, and define what happens there. Include incomplete requests, multiple intents, conflicting information and cases outside the categories. A general review queue can be useful, but only if someone is responsible for checking it and the queue has a workable response time.
Also decide what happens when a result is refused, unavailable or too uncertain for the action. The guide recommends setting thresholds using labeled examples from the application and considering the costs of false positives and false negatives. A returned probability or confidence value is an estimate to evaluate against real examples, not a guarantee that the route is correct.
A wrong route is not always equally costly. Sending a routine shipping question to billing may cause a delay. Sending an account-access problem to a low-priority queue may have a larger consequence. Write those costs down before selecting a threshold. The right threshold for suggesting a queue may differ from the threshold for taking an action that is difficult to reverse.
Test the policy before connecting actions
Build a representative, labeled set of past or simulated requests that the team is permitted to use. Include ordinary examples, rare cases, ambiguous language, multiple intents and inputs that do not fit any category. Have reviewers agree on the expected route or explicitly mark the case as disputed. Protect customer information when assembling the set.
Run the proposed categories against that set and inspect errors by route, not just an overall accuracy number. How many urgent access issues were sent elsewhere? How often did “other” catch an unfamiliar request? How many valid requests were unnecessarily held for review? Check whether reviewers can handle the resulting queue volume.
Start by showing the suggested route to a person. Compare it with the final route and record why a reviewer changed it. Only after the team understands the errors should it consider automating a bounded next step. Recheck the labeled set when categories, inputs or model behavior change.
Start with clear categories, test the difficult cases and decide which actions the evidence supports. The API can reduce integration work; your team owns those decisions.