Decisions API, October 2026 beta: build a classifier that knows when to hand off

Documentation snapshot: October 14, 2026. This guide discusses the dated release described below; check the linked official documentation for current API behavior and account availability before implementation.

Not every AI feature needs a conversation. Sometimes the application needs one bounded answer: which queue should receive this ticket? OpenAI's Decisions API entered beta with GPT-6 Luna on October 6, 2026. The official guide describes typed decisions; the changelog provides the release date. Documentation was checked on October 14. I would start with routing, where a human can easily correct a mistake.

Define the labels before the prompt

Suppose the queues are access, billing, and product support. Write what belongs in each and provide boundary examples. “I cannot see my invoice because sign-in fails” could involve two teams. Decide whether the classifier chooses the first blocking issue, allows a review queue, or delegates ambiguity. Otherwise two reviewers can disagree while both think the model is wrong.

Keep the input small: a sanitized issue description and the minimum context needed to route it. Treat text inside the ticket as data, including requests to ignore your rules. Do not include account secrets merely because the model could probably read them.

Separate classification from action

Use the current official SDK example to construct the typed question; beta request schemas can evolve. Then place your own validation layer between its answer and the ticket system. This is application pseudocode, not an undocumented API signature:

allowed = {"access", "billing", "product"}
if refused or choice not in allowed or needs_review:
    queue = "human-review"
else:
    queue = choice

A confidence value is an input to your decision policy, not a universal probability of correctness. Choose any threshold from measured performance on your own held-out cases. Never let an unavailable response default to the most convenient business action.

Evaluate the expensive mistakes

Build a confusion matrix from reviewed tickets. Look at each label's false positives and misses, not just overall accuracy. If product questions dominate the dataset, predicting product every time can look deceptively good. Include short messages, mixed-language messages, ambiguous requests, refusals, and timeout behavior.

For the first deployment, run in shadow mode: compute the suggested queue while the current process remains authoritative. Compare the suggestion with the reviewed outcome, then enable a reversible subset. Record request identifiers, model configuration, and routing outcome without storing unnecessary message contents.

A typed classifier can reduce parsing work. It does not remove the need for a definition of the task, an uncertainty path, or a person who owns routing failures. Start with one narrow decision and make its mistakes visible before adding more autonomy.