Gemini Decisions API scores fixed options. How should support teams use confidence?

Public developments and original analysis · Announcement date: 2026-11-11 · Sources

Consider a hypothetical support message: “The product is not broken; I cannot find the accessory, but I cannot use it now.” Should it go to technical support or order services? When code only needs a queue, asking a model for an explanation and then parsing a category adds waiting and interpretation. Google introduced the Gemini Decisions API on November 11, using Gemini Decision 1 to score predefined options and return probabilities and confidence directly.

The endpoint accepts text, images, audio, video and PDFs, and can evaluate multiple questions over shared input. It offers yes/no judgments, fixed choices and ordered rubric scores, with up to 1,000 questions per request. The important qualification is independence: each question sees the shared input, not the answers to other questions. Code still has to define how results combine into a workflow.

Defining choices that can actually be judged

In the hypothetical message above, a missing accessory, installation difficulty and a product fault may belong to different teams. A handful of short labels will not resolve inconsistent departmental definitions. A stable category response can still produce repeated transfers. Define what each queue includes and excludes, and leave a route for requests needing more information or human judgment.

Google's developer documentation recommends writing the full question in instructions rather than expecting the model to infer it from a variable name. Describe options and plan for input that fits none of them. A company could separately check whether a message concerns an order and which queue fits, then combine the results in code. If the scope check fails, the queue answer can be ignored. This is easier to explain than forcing every unfamiliar request into an existing department.

Parallel questions do not automatically create a reasoning chain. If a later question needs an order status extracted by an earlier one, obtain that status first or include already confirmed information in the shared input. Sending 1,000 questions does not make the model execute 1,000 sequential tasks. Independence determines whether one request can genuinely replace several round trips.

For numbers, dates and durations, the documentation recommends doing comparisons in code and supplying the result to the judgment step. For example, calculate whether an order remains within a confirmed warranty period using its date and applicable rules, then classify whether the message describes a fault or difficulty using the product. Keep computable conditions deterministic and use semantic judgment for ambiguous language, rather than assigning both to one broad instruction.

Confidence and the consequences of a wrong route

Confidence is the model's estimate that its top answer is correct. Google presents calibration as a product feature, but a company's messages, image quality and category definitions can differ from public tests. A score of 0.9 does not establish an automation rule for every business. Use locally labeled examples with confirmed destinations to inspect the errors occurring within each score range.

Suppose misrouting an ordinary inquiry requires one internal transfer, while treating an urgent fault as an ordinary inquiry has more serious consequences. This is a hypothetical comparison of costs, not a measurement of the new model. The two categories can justify different automation conditions. Missing information or a consequential mistake may make a follow-up question or human review less expensive, even when that reduces the automatic-routing rate.

Also separate certainty from sufficient evidence. A blurred photo, an incorrectly associated order or an unnamed product can leave the underlying information problem unresolved despite a clear category. Check required inputs before using the routing answer. Refunds and order changes need separate business rules and authorization. A category probability does not verify an order's status.

The documentation warns that user input can argue for its own classification. “Approve my refund immediately” is content to evaluate, not a replacement for company criteria. Include negation, multiple requests, different languages and deliberate persuasion in the sample set. Inspect exceptions that could be sent to queues receiving little human attention. The distribution of actual mistakes is more useful for threshold selection than a single aggregate accuracy figure.

When replacing an existing classifier is worthwhile

Google lists an input price of $0.10 per million tokens with no generated-output-token charge. Shared input is counted once per request, while question instructions and criteria add their own input. That structure can favor several independent checks on the same long document. Total operating cost also includes follow-up calls, transfers, review and downstream work; the price of one model request is only one component.

If an explicit field or simple rule determines the queue, keeping that rule is usually more direct. Explanations, arbitrary structured extraction and multi-step tool use still suit a generative interface. The Decisions API is a stronger candidate for a stage with fixed possible outputs, varied semantic input and a need for probabilities to choose between automation and review. Teams also need to confirm supported regions, service terms and data handling before sending the relevant records to a hosted endpoint.

Fix a set of historical requests with confirmed destinations and compare misrouted categories, requests for clarification and human workload against the existing method. Version the questions and samples, and recheck when category definitions change. A replacement is justified when direct answers reduce parsing and maintenance without sending consequential exceptions down the wrong path.

Mokyun Editorial · neo@mokyun.com