The Gemini Decisions API is interesting because a useful agent spends a lot of time choosing what happens next.

Does this request belong in billing, and is the retrieved passage relevant? Should the agent ask a person before continuing?

I looked through Google's launch announcement and API documentation to work out where this endpoint could earn a place in a client workflow. My recommendation is to evaluate one bounded decision first, alongside your existing router and a simple rule.

This is an adoption checklist, not a hands-on benchmark. The sample support workflow, thresholds, workload arithmetic, and pilot below are proposals you can adapt, not results from a deployment I ran.

What changed with the Gemini Decisions API?

Google announced the endpoint on November 11, 2026, powered by gemini-decision-1. Its purpose is to score predefined outcomes rather than compose an answer, according to the Google launch announcement.

The model documentation, checked November 13, lists text, image, audio, video, and PDF input, a 262,144-token input limit, and up to 1,000 questions per request. It does not support text generation or function calling.

That makes it a candidate for the branching step inside an agent. A separate component still retrieves context, checks permissions, executes the chosen operation, and explains the result.

For the broader architecture, our guide to AI model routing explains when different requests deserve different models. Here I am narrowing the question: would this specific endpoint improve one decision you already make?

My first candidate would be support queue selection. I would leave refund execution, account access, and customer communications outside the first experiment.

1. Match the output to the job

Start with the field your application needs. A routing label, a relevance rating, and an extracted invoice number are different outputs, even if a general language model can produce all of them.

Google's question-type reference defines noul for a yes/no probability, choice for a fixed option, and score for an ordered rubric. A score is an average weighted by the level probabilities, so it may fall between levels.

I would write a contract such as: “Given an authorized support message, return a proposed queue and enough evidence in the stored record for a reviewer to inspect the input.” Do not quietly expand that into “resolve the ticket.”

Keep the current implementation in the comparison. If a verified account field already identifies the queue, use that rule as the baseline; a model call must justify its additional failure modes and operating work.

Also write the downstream behavior for every possible label. An attractive classification that no team owns is an unfinished workflow.

2. Make labels and rubrics distinguishable

For a proposed support router, I would begin with billing, delivery, product help, and other. Each needs inclusion criteria and a boundary example.

“Where is the invoice?” belongs in billing; “Where is the parcel?” belongs in delivery. “I want my money back because the parcel is late” needs an explicit business rule, not a guess about which word matters most.

Write down whether mixed requests go to a primary queue, get split, or require triage. Then ask the people who own those queues to label the same examples independently.

Disagreement between reviewers is useful evidence. Resolve the definition before tuning the model to imitate labels nobody agrees on.

For a relevance rubric, I would propose these levels: unrelated, background only, partially answers, directly answers. Keep examples beside each level, including a passage that shares the topic but cannot support the requested fact.

The middle levels deserve attention. If reviewers cannot distinguish background from a partial answer, collapse the scale and document the simpler decision.

A question name such as safe_refund is a poor substitute for a complete instruction. Google's best practices explicitly say question keys are not visible to the model.

Version the label definitions with the experiment. Changing what billing means halfway through a comparison changes the task, even if the model identifier stays the same.

3. Check Gemini Decisions API confidence on your traffic

A confidence value is useful only if it predicts correctness well enough for your task. A model can choose the right queue often while still being overconfident on the cases you most need to escalate.

Guo and colleagues' calibration research distinguishes confidence estimates from actual correctness frequency. That paper establishes the concept; it is not an evaluation of this new endpoint.

In a hypothetical group of 100 predictions near 0.9 confidence, calibration would suggest about 90 correct predictions. That is an illustration of the concept, not a guarantee about the next case or a statistically adequate pilot size.

I would group the proposed pilot's predictions by confidence and compare each group's mean confidence with observed accuracy. Show the number of cases in every group, because an empty or tiny bin says very little.

Inspect results separately for short messages, long threads, mixed intents, unfamiliar terminology, and each language you plan to serve. A reassuring overall average can hide the category that sends a client's requests to the wrong team.

Google describes favorable calibration and benchmark performance in its launch post. Those are vendor evaluations; I would not present them as proof that a particular client's labels are calibrated.

For another perspective, Artificial Analysis reported a Decision Index score of 66 when checked November 13. Its composite includes correctness and probability quality on its own evaluations; 66 is not 66% accuracy on support tickets.

Our guide to building AI agent evals covers constructing a reusable test set. Here, save the raw probabilities as well as the final label so future threshold changes can be evaluated without pretending the original choice was the only possible one.

4. Give uncertainty a real destination

I would put an explicit other route into the design and give it an owner. A missing category should result in triage, not a confident trip to whichever queue happens to be closest.

Google warns that choice questions distribute probability across the offered options even when none fits. A separate scope check can help distinguish “this is about an order” from “which order queue fits?”

For a hypothetical pilot, you might send low confidence, other, contradictory answers, and missing required fields to human triage. Keep that rule in application logic and define what the customer sees while the case waits.

Choose the threshold on development examples, then freeze it. Adjusting the threshold after inspecting the final held-out cases makes the reported evaluation less useful.

Report both the error rate among accepted decisions and the share of cases accepted automatically. A router that escalates almost everything can look accurate while providing little operational value.

The threshold should reflect consequence. A wrong internal tag and an incorrectly approved payment do not deserve the same acceptance rule.

Be careful with the yes/no field: Google's reference puts noul between 0.01 and 0.99, while confidence describes the most likely answer. High confidence can therefore mean a confident “no.”

Write assertions against the actual yes probability when your condition requires yes. Treating confidence as permission to proceed can invert the meaning of the answer.

5. Separate parallel questions from dependent decisions

Bundling several questions about a ticket could be useful: does it concern an order, which queue fits, and does it contain a cancellation threat? All can inspect the same input.

The multiple-question documentation says questions are evaluated independently and cannot see one another's answers. My inference is that a shared request is a packaging convenience, not a sequence of reasoning steps.

Suppose the workflow first determines whether a purchase is eligible and then selects a resolution under that eligibility. Either calculate eligibility in code and supply it as input, or make a subsequent request after the first result.

Do not write “use the previous answer” into a second question and assume that dependency exists.

There is another distinction: independent execution does not make mistakes statistically independent. Several checks can be wrong together because the same scan is blurry or the same input omits the crucial fact.

I would include deliberately correlated failures in the pilot: a thread with an outdated policy, a photo unrelated to the order, or a message that asks the classifier to ignore its rules. Inspect the complete disposition, not only each question in isolation.

Numeric comparisons belong in ordinary code wherever possible. Let the application verify dates and amounts, then provide those trusted facts to the classifier instead of asking it to reconstruct arithmetic from a conversation.

6. Measure request cost and the complete path

The Gemini Developer API pricing table, checked November 13, lists paid standard input at $0.10 per million tokens in USD across supported modalities, with zero output tokens. This is a usage rate, not a monthly subscription.

Shared input is billed once per request; question instructions and criteria add input tokens. The same table lists no context caching and no Batch API support for this model.

Here is hypothetical arithmetic: 10,000 requests averaging 2,000 billable input tokens each would total 20 million tokens, or $2 at that listed input rate. The assumption includes the questions, not only the customer message.

That excludes retries, fallback models, storage, infrastructure, human triage, tax, and any intermediary charges. It also says nothing about the actual token count of a PDF or recording.

Google reports 150 to 250 milliseconds end to end in its launch evaluation, with the near-flat question-count observation scoped to 1 to 100 questions and contexts up to 16K tokens. The reported latency conditions do not establish an SLA for a maximum-size request.

I would measure from workflow intake to a usable routing result, including preprocessing, upload, network time, validation, and fallback. Record median and tail latency, with cold and warm paths identified.

Use the same input, acceptance policy, and timing boundary for the existing router. Comparing a new model's compute time with the old workflow's full response time is not a fair comparison.

Finally, check data terms before choosing a tier. The pricing table marks free-tier data as used to improve products and paid-tier data as not used for that purpose; review the applicable terms and account arrangements before sending client material.

7. Prove fallback and auditability before switching

A timeout must have a deliberate result. For the proposed queue router, I would preserve the ticket and put it into triage rather than interpret a missing answer as approval.

Test a missing answer, unexpected label, malformed probability, blocked request, unavailable provider, and exhausted retry budget. Decide which can be retried and which need immediate escalation.

Use bounded retries with a deadline. If a fallback model also fails, the workflow should arrive at a known state instead of starting another invisible retry chain.

Record a case identifier, model identifier, label-definition version, policy version, returned values, chosen route, fallback reason, and final disposition. Keep enough authorized evidence to investigate mistakes without copying entire customer records into every log.

OWASP's excessive agency guidance recommends limiting functionality, permissions, and autonomy, with authorization enforced in downstream systems. I would apply that principle even if the classifier is highly confident.

Classifying a request as a refund request does not authorize a refund. An authenticated actor, verified order, current policy, and any required approval remain separate prerequisites.

Our human approval guide helps place the checkpoint where a person can still prevent the consequence. Pair it with the agent security guide when defining tool scope and incident evidence.

A proposed pilot you can actually review

I would start with one queue-routing decision and a labeled collection the client is allowed to use. Include routine cases, mixed requests, unsupported topics, missing context, and attempts to manipulate the classifier.

Keep duplicates and messages from the same underlying conversation in the same partition. Otherwise, nearly identical examples can leak between development and held-out evaluation.

Choose the split before tuning. Use development cases for label definitions and thresholds, and reserve a separate held-out set for the final comparison.

Run a deterministic rule, the current generative router, and Gemini Decision 1 on the same cases. Give all candidates access to the same allowed facts, and record exceptions instead of silently giving one candidate better context.

The rule might route a structured topic field when present and abstain otherwise. That baseline is intentionally simple; it tells you whether the semantic problem is important enough to require a model.

Have a reviewer examine disagreements without knowing which candidate produced each answer where practical. Record whether the label was wrong, the reference was ambiguous, or the input lacked enough information.

Before starting, define acceptance conditions for wrong automatic routes, review volume, tail latency, privacy, and recovery. These are client-specific limits, not universal industry thresholds.

A clean offline result earns a shadow trial: observe proposed routes while the existing workflow remains responsible. A controlled release follows only after the owner accepts the observed tradeoffs.

Where I would connect this in Pickaxe

Pickaxe's Actions documentation describes connecting agents to APIs, MCP servers, and external workflows. I would evaluate a decision endpoint behind a narrow custom integration that returns a proposed label, with execution controls kept in the surrounding service.

This article does not establish native Gemini Decision 1 support in Pickaxe. The wrapper, authentication, response handling, and deployment behavior would need implementation and testing for your setup.

For example, a client-facing agent could collect the support request, call an authenticated service that runs the approved classifier, and receive a proposed queue. That service should enforce tenant boundaries and refuse to return another client's records.

Keep provider credentials on the server. Let the integration accept only the fields it needs, and return an explicit review-required status when the decision cannot be accepted.

The Actions and MCP integration guide explains the surrounding connection pattern. Start with a read-only classification call before connecting any external write.

If your team uses a gateway, verify its specific interface. Vercel's November 11 announcement says PDF, audio, and video are supported through AI SDK 7, while its TypeSafe-compatible and Decisions interfaces support text and images.

Model capability and adapter capability are different contracts.

Failure cases I would put on the checklist

Do not let happy-path accuracy be the only thing the client sees. These proposed cases make the adoption discussion more concrete.

I would also rerun the same cases after changing labels, preprocessing, adapters, or the selected model. A classifier is part of a pipeline; changing what it receives can change behavior without changing the endpoint.

For a customer-facing pilot, rehearse the review queue too. A technically correct abstention still fails operationally if nobody reads it or the customer receives a misleading completion message.

Copy this decision record before the pilot

A short record makes the trial reviewable. I would keep the following fields together and assign one person to maintain them.

• Decision: the exact field being predicted and the actions it cannot authorize.
• Inputs: allowed fields, tenant boundary, preprocessing, attachment handling, and retention.
• Labels: definitions, mixed-intent policy, scope rule, and version.
• Evaluation: partitions, reviewers, baselines, confidence groups, and known gaps.
• Acceptance: error limits, automatic coverage, latency boundary, and total operating cost.
• Recovery: timeouts, retry budget, fallback owner, incident path, and rollback scope.

Record the final choice as adopt, continue shadowing, or retain the existing implementation. Include the reason and the unresolved limitations, so the next model release does not restart the discussion from a marketing screenshot.

If the endpoint wins only on a narrow category, keep the deployment narrow. There is no requirement to replace every routing and grading step at once.

Questions I would resolve before launch

Does this replace my generative model?

Only if that component's entire job is the bounded decision you have evaluated. Keep a suitable generative component for explanations, extraction, or responses that need prose.

Can I use confidence as a security check?

Use it as one signal in a tested acceptance policy. Identity, access, transaction limits, and required approvals should remain enforceable even when the model returns a confident answer.

Do I need to send the entire conversation?

I would start with the smallest context that contains the needed facts, then evaluate omissions. More context can add irrelevant material, cost, and data exposure without improving the decision.

Should I switch because input tokens look cheap?

Compare the full accepted-decision cost, including review and fallback. A cheaper request is useful only when the complete workflow meets the client's quality and operating requirements.

My recommendation: earn one decision first

I would evaluate the Gemini Decisions API for a narrow, repeatable branch where the labels are clear and uncertainty has somewhere useful to go. Queue selection and relevance grading are reasonable candidates for that discussion.

Keep the baseline, freeze the test, and inspect wrong confident answers. Adopt only the slice that improves the agreed tradeoff between error, review load, latency, and total cost.

If you are building the surrounding client experience, start with a focused agent in Pickaxe and connect the decision service only after the pilot supports it. A disciplined decision boundary is more valuable than another model name in the stack.