A small business should consider Google's new Gemini Decisions API for narrow, repeatable choices such as routing an enquiry, spotting missing information or deciding which approved workflow comes next. It should not use a model score as final authority for payments, food safety, customer eligibility, legal decisions or commitments the operating team has not confirmed.
Google released the API through Gemini API and Google AI Studio on 11 November 2026. It returns typed yes-or-no, fixed-choice or rubric scores with probabilities and confidence, rather than drafting an open-ended answer. That can make a decision layer easier to inspect, but the business still has to define the options, test the errors and own the outcome.
What Google actually shipped
The Decisions API is powered by Gemini Decision 1 and is available for developers to start testing in Google AI Studio. It can evaluate text, images, audio, video and PDFs, and return one of three typed results: a yes-or-no probability, a choice from a fixed list or a score against an ordered rubric.
This is different from asking a generative model to write an answer and then trying to parse the prose. The response is designed for software to branch on directly. Google also returns a confidence value, which can be used to send uncertain cases to a person rather than forcing an automatic result.
The important limitation is structural: a choice question distributes probability across the options provided, even when none is a good fit. Google's documentation therefore recommends a catch-all option or a separate scope check, plus thresholds based on labelled examples from the organisation's own traffic.
Use it where the options are real and bounded
Start with a decision the business already understands. The options should come from the operating process, not from whatever labels sound plausible during implementation. A support enquiry might be routed to sales, delivery, billing or human review. A food enquiry might be marked complete, missing delivery details or requiring an allergen question.
A property team could use the same pattern to identify whether an enquiry contains a preferred area, move date and contact route. The output may help a person choose the next approved message. It must not approve an applicant, invent availability or describe a viewing as booked before the responsible system confirms it.
For food orders, a model may flag that a delivery time is missing. Capacity, ingredients, price, payment and kitchen acceptance still come from the relevant records and people. The API can help organise the handover; it does not become the source of business truth.
Run a four-step proof loop before automating
Clear now: write the decision in one sentence, name the approved options and identify the cases that must remain human. If the team cannot agree what each option means, the model is not the first problem to solve.
Build now: create narrow questions, include an explicit other or human-review route and keep the confidence threshold configurable. Record which business source supplies the input and who owns corrections.
Launch now: test in shadow mode on labelled historical or synthetic examples. Do not send customer messages, release an order or change a record from the score alone. Compare the model's route with the route an authorised person assigns.
Proof loop: count false routes, missed escalations, review time and running cost over an equal test period. Examine false positives and false negatives separately because their consequences differ. Keep, revise or stop the workflow on that evidence—not on one impressive demonstration.
The founder question is authority, not just accuracy
A fast probability can still be wrong. The commercially useful design separates a reversible routing suggestion from a decision that spends money, makes a promise or affects a person. Give the first category a measured path to automation; keep the second behind an approval or an authoritative system check.
That is the practical opportunity in the release. A small team can build a clearer control layer between unstructured enquiries and the next approved action. The value does not come from calling every workflow intelligent. It comes from making the options, evidence, owner and fallback visible.
Choose one recurring handover this week and map its real options before selecting a model. If the decision cannot be explained to the colleague who owns the result, it is not ready to be automated.
Sources & further reading
Klarnow editorial analysis of Google's 11 November 2026 release and current API documentation, checked on 12 November 2026. The API returns probabilistic scores, not guaranteed decisions. Food and property examples are illustrative. No first-hand product test or performance result is claimed.