# ai_decide is the cheap model you put in front of the expensive one > ai_decide is a Beta AI Function that answers structured questions over text with probabilities. Use it to route and triage before ai_query. By Sushruth Aeluguri, 6 October 2026. Databricks Field Guide, TechFabric. Canonical: https://databricks.techfabric.com/notes/ai-decide-is-the-cheap-model-you-put-in/ Databricks announced `ai_decide` on its blog on 30 September 2026 ([announcement](https://www.databricks.com/blog/introducing-aidecide-make-fast-decisions-your-governed-data)). It's a new AI Function, in Beta, powered by a decision model rather than a language model. You hand it some text and a set of questions, and it hands back decisions with probabilities attached, in what Databricks calls a fraction of a second. Databricks introduces it with TypeSafe AI's Jev as the example of a decision model, and the function is compatible with the TypeSafe AI API for teams already using it. The release notes didn't carry it. It went out on the blog, and the SQL reference page was updated the day before. ## What it actually returns Three question types, and you can mix them in one call. A `noul` question returns a probability between 0 and 1 that something is true. A `choice` question picks one label from up to 255 you define and gives the probability of every label. A `score` question rates the input against an ordered scale of 2 to 10 descriptions and returns a probability-weighted average, so a three-step scale can come back as 1.5. All of it arrives as a VARIANT with `response`, `metadata` and `error_message`. That last field matters in a pipeline. A row that fails returns a null response and a message, instead of failing the query, so you can count failures like any other column. Here is the shape for support tickets, following the [SQL reference](https://docs.databricks.com/aws/en/sql/language-manual/functions/ai_decide). We haven't run this against a production table yet, so treat it as the syntax rather than a benchmark: ```sql SELECT ticket_id, d:response.answers.team.choice::string AS team, d:response.answers.needs_escalation.probability::double AS escalate_p, d:error_message::string AS error FROM ( SELECT ticket_id, ai_decide( body, '{ "team": {"type": "choice", "instructions": "Which team should handle this ticket?", "criteria": {"shipping": "Delivery or shipment issues", "billing": "Payment or invoice issues", "technical_support": "Product technical problems"}}, "needs_escalation": {"type": "noul", "instructions": "Does this ticket need immediate escalation?"} }' ) AS d FROM support.tickets ); ``` The questions argument has to be a constant, so one call applies one rubric to every row. The input can be a string or the VARIANT that `ai_parse_document` or `ai_extract` produced, which means a parsed PDF can go straight into a decision without a reshaping step. ## Where it earns its place Most of what teams send to `ai_query` today isn't generation. It's which bucket, which team, is this urgent, does this answer follow the policy. A language model can do all of that, and you pay for it to write a paragraph of reasoning nobody reads. Databricks' own examples are the honest list: tagging reviews, routing a prompt to a cheaper or stronger model, judging generated answers against a policy, and picking an app's next action in real time. The routing case is the one we'd start with. Put `ai_decide` in front of [Foundation Models and the AI Gateway](https://databricks.techfabric.com/guide/foundation-models/), score each request's difficulty, and only send the hard ones to the large model. ```mermaid Routing a request with ai_decide before ai_query flowchart LR A["User request"] --> B["ai_decide scores difficulty"] B -->|"routine"| C["Small model through ai_query"] B -->|"hard"| D["Large model through ai_query"] ``` The same pattern works inside [Agents on Databricks](https://databricks.techfabric.com/guide/agents/) for choosing a tool or a branch, where every step that skips a full LLM call is time and money back. > **Our position**: Move classification, triage and judging work off general-purpose LLM calls and onto `ai_decide`, starting with whichever `ai_query` job runs most often. Keep it out of anything a regulator reads until it leaves Beta, and log the probabilities, because a 0.51 and a 0.99 are not the same decision. ## The fine print It's Beta, so a workspace admin has to switch it on from the Previews page. It doesn't run on Databricks SQL Classic, it needs Databricks Runtime 15.4 LTS or later, and it's only available in some regions. The reference also says Databricks may swap the underlying model if a better one benchmarks higher, which is fine for routing and worth knowing for anything you've calibrated thresholds against. Pin `map('version', '1.0')` in the call so at least the function version is explicit, and keep a labelled sample around to rerun when the model changes. Pricing sits on the Databricks SQL pricing page. We'd measure a day of real traffic against what the same job costs through `ai_query` before believing either number, the same way [Cost and Performance](https://databricks.techfabric.com/guide/cost-and-performance/) suggests for anything new on the bill. ## Questions people ask ### What is ai_decide in Databricks? It's a Databricks AI Function, announced on 30 September 2026, that evaluates one or more questions against text or structured data. For each question it returns a probability, a choice from labels you define, or a score on an ordered scale. ### Is ai_decide generally available? No. It's in Beta, a workspace admin enables it from the Previews page, it needs Databricks Runtime 15.4 LTS or later, and it doesn't run on Databricks SQL Classic. ### How is ai_decide different from ai_query? ai_query calls a general-purpose model that generates text. ai_decide is powered by a decision model and returns structured decisions with probabilities, which Databricks says gives lower latency and cost than an LLM on similar tasks.