OpenAI Decisions API in beta: classify tickets and requests with controllable answers

OpenAI Decisions API serves to obtain a decision in a defined format, instead of a free response to interpret. The public beta is available from 6 October 2026, as reported in OpenAI changelog. It is a date distinct from the initial announcement: the news is about the opening of public access to the beta, not the debut of the idea.

For an SME the most immediate case is the sorting of requests: technical assistance, commercial information, administration or switching to an operator. The practical difference to a chat is the contract of the answer. The system receives a value expected from integration, but this value still needs to be corrected. Controlled format and reliable decision are two separate requirements.

What does the Decisions endpoint return?

The Official Guide describes the endpoint /v1/decisions and, at launch, the model gpt-6-luna. Inputs can be text and images; the expected decision types are predicate, choice and score. Supported versions and models should be checked in the same documentation before developing an integration. These details do not imply that each ticket archive is already ready to be processed. The choice also depends on what the system must produce: the comparison between JEV and generative LLM separates a typed outcome from a written response for the client.

A predicate responds to a defined condition, for example if a request contains a readable order number. A choice selects from alternatives prepared by the company, such as sales department or assistance. A score expresses an assessment according to the set criterion. The criterion must not remain implicit: words such as urgent, important or interesting take on different meanings between departments and produce inconsistent labels if they are not explained.

The difference between endpoint and complete process is also central to the guide to AI API. A well-formed value makes it easier to connect to systems; it does not establish who can act and with what consequences.

How to build categories that operators recognize?

Starting from the list of departments is often not enough. A request may contain a commercial application and a technical problem, or speak of an invoice without requiring an administrative correction. The team must decide whether to classify the dominant theme, the first necessary action or all the intentions present. This choice changes the expected response and must be taken before comparing model and operators.

A short sheet is prepared for each category: definition, examples included, examples excluded and destination. The assistance category, for example, may include a failure on a product already purchased and exclude a question about the features before purchase. Border examples are also needed. If two experienced operators assign different labels to the same message, the priority is to clarify the rule, not ask the model for more security.

A residual category must be useful. Other may become an invisible landfill; to be verified it indicates instead that an operator must read the request. The register shall retain the proposed label, the final label and the reason for the amendment. Over time this difference signals new categories, product changes or criteria that no longer reflect the real work of the company.

Why should the probability be calibrated on your tickets?

A probability is a signal to be evaluated, not a certificate. The relationship between declared trust and correctness can change with abbreviations, customer language, image quality and new product lines. The company must observe whether the cases declared to be safer are actually more reliable in their own sample. Without this verification, a threshold chosen because it seems prudent remains arbitrary.

The sample should be separated between examples used to define the instructions and examples kept aside for evaluation. It must contain frequent requests and expensive cases to be mistaken. An overall average can hide a problem: a lot of well-classified business information can compensate for refunds or mishandled complaints. The result should therefore be read by category, highlighting confusions between classes with different consequences.

In a hypothetical example, only one low-risk category could be automated after satisfactory verification and all others kept under review. There is no universal threshold suitable for any SME. The manager decides what error is acceptable, how much it costs to correct it and when the operator needs to intervene before the customer perceives a consequence.

Where does classification end and automation begin?

A ticket labeled as returned should not automatically produce a refund. Valid order, business conditions, status of the goods and an authorized role can be used to authorize the payment. The value returned by Decisions can initiate a verification, but the action must be protected by independent application rules. This separation makes it possible to correct the model without rewriting the entire administrative process.

The integration should retain a request identifier and record the status of the next step. If the CRM is temporarily unavailable, a retry must not create two identical tasks. If the label is corrected, the operator must see who received the case and whether anything has already been done. It is a problem of CRM Automation, not just of linguistic quality.

When the flow becomes more articulated, the distinction between classifier and Corporate AI Agent It helps to choose architecture. A task with fixed alternatives may require simple integration. Adding autonomy and tools only makes sense if the process really requires research, planning, or interaction with other systems.

Can an e-commerce separate deliveries, returns, and commercial requests?

Hypothetical scenario. A small Italian e-commerce wants to order the service queue. The initial categories were delivered, returned, information before purchase and request to be verified. The input includes the message and, when necessary, an attached photograph. The first pilot proposes only one destination: the operator maintains the response to the customer and can correct the label before opening the practice.

The evaluation must include messages such as "it hasn't arrived, I want to cancel" or "the product has arrived but a piece is missing". Both talk about delivery, but the first action may be different. The company prepares a rule on the operational meaning of the category and checks whether the proposal really helps to reduce the steps between departments. The number of reassignments is more useful than just the presence of a label.

To read the cost you also need input tokens, processed attachments and repeated attempts. The price of the model does not coincide with the cost of the completed practice. The comparison with the Sonnet caching prompt Remember that each endpoint has its own cost structure: you don't have to transfer discounts or mechanisms of one service to another. Control time and integrations remain separate entries in the pilot's budget.

Can a maintenance company recognize operational priorities?

Second hypothetical scenario. An SME that maintains facilities receives requests from buildings and shops. The classifier can distinguish an ordinary signal from a message that requires immediate reading by a person in charge. It does not decide for itself whether an installation is safe or replaces a technical assessment. The category serves to bring out the case and direct it to the competent person.

Vague descriptions, incomplete photographs, and messages with alarming words used colloquially enter the sample. False negatives deserve specific analysis: an important request classified as ordinary can stay in the queue. The project can then include model-independent conservative rules and a revision for uninterpretable inputs. The goal is to support reading, not promise an automatic diagnosis.

The operator must be able to understand what criterion has produced the proposed priority, without reconstructing the whole technical conversation with the model. A tab with original text, category and reason of the rectification makes the process verifiable. The results of the pilot should be discussed with those who manage the calls and with those who perform the interventions: the administrative and technical priority do not always coincide.

How much does it cost and what conditions to check in Italy?

The guide indicates 0.10 USD per million token input, no charge for output or cache; the expected rewards for long context and region may apply. These are conditions of the Documentation Decisions, to be verified at the time of implementation. The price does not automatically include integration work, archiving or classification review.

Italy is present in Supported API countries. Data residency, Zero Data Retention and other dedicated regimes require the required requirements and do not automatically result from the use of the endpoint, as the Service Guide. For the project you need to verify the account, contract and actual configuration before sending business data.

Consumption must also be compatible with API Build, Launch and Grow limits. An economic classification can still stop during a peak if queues and attempts are not managed. Cost and capacity are two distinct checks, to be conducted on the same expected traffic profile.

What tests to do before awarding tickets automatically?

The first test is a parallel execution: the system ranks, operators continue ordinary work and compare outcomes. The second concerns faulty inputs, such as illegible images, missing attachments, and texts citing instructions unrelated to the request. The third simulates an unavailability of the service. In any case there must be a clear destination, without loss of practice and without false confirmation of success.

The most frequent errors are overlapping categories, thresholds copied from other projects, a single accuracy average, and irreversible actions linked directly to the label. Even a good classification can become harmful if the message is passed to the wrong department by a CRM rule. Testing must follow the request until its final state, not stop at the API response.

How to Read a Wrong Classification

Compare original input, wait label and proposed category. Ask if education was understandable, if categories were distinguishable, and if information was missing. It then records the operational consequence: simple reassignment, delay or improper action. Correct the level that caused the problem and try again on the sample held aside.

How to keep labels reliable when changing jobs?

The category catalogue should be treated as an element of the process, with a manager and a history. When a new service is introduced, tickets may no longer fall within the initial definitions. Changing a label in the CRM without updating the classifier instructions produces a silent discrepancy: the API returns a valid value, but the next procedure interprets it with a different meaning.

A change should then include examples, destination rules, and sample verification. Before activating it, the previous version is kept and how to deal with the already queued practices. The register can indicate which version of the categories each proposal has produced, without needlessly saving the entire content of the message in technical logs. This makes it possible to analyze an error after an update without confusing old and new behavior.

Human review must also produce consistent data. If each operator corrects according to a personal preference, the model is measured against a mobile target. A brief discussion of the controversial cases allows instead to improve definitions and identify exceptions. The manager can decide that some requests always remain manual, because ambiguity is part of the work and not a defect to be eliminated at any cost.

Continuity finally requires periodic testing of newly arrived cases. A perfect historical champion does not necessarily tell the new questions of customers, the photographs from a new channel or the messages related to a promotion. The goal is to notice the change before they increase reassignments and delays, keeping the classifier within a task understandable to the team.

To compare tools on the same task, the in-depth study on Perplexity Decider and the Odds in Tickets proposes another point of observation. The comparison should be made using consistent categories and sample, without inferring reliability from the shape of the response or the name of the product.

When should a simpler procedure be maintained?

If the message already contains an explicit code or comes from a module with a mandatory category, a deterministic rule may be sufficient. Decisions become interesting when the content is variable and needs to be interpreted, but remaining within defined choices. Before introducing it it it is better to improve the module, clarify the responsibilities of the departments and check if the necessary data already exists in the management software.

If instead the action passes through a portal without integration, the browser use with Claude SDK concerns a later level and requires additional controls. Separating reading, decision and action helps keep the project proportionate. To evaluate a driver on real categories and switch to operator, the route on AI agents can start with a labeled archive and only one automatable outcome.