Decision models

Some steps in an application need a closed answer rather than text. Is this message urgent? Which team handles this ticket? Does this tool call need a person’s approval? A decision model answers questions like these. You give it some input and a set of questions, each with a fixed set of choices, and it returns one answer per question that your code can branch on.

When the input doesn’t support any of the choices, the decision model can answer Uncertain instead of guessing, so your code can treat “the model isn’t sure” as its own case.

How it works

A decision model has one method, ask. You call it with the input and the questions, and it returns the answers along with details about the call:

The input is what the questions are about: a string, a message’s content, or a whole conversation.
The questions each have an id you choose and their choices: yes or no, or a list of labels.
The decision model validates the questions and sends them to its backend. The LLM decision model uses a model provider; a custom decision model can use anything.
The result holds one answer per question, keyed by your ids, plus the call’s latency and token usage.

Decision models and structured output

Structured output also returns typed data, but you design the schema and the agent produces it at the end of its loop. A decision model is a single call outside the agent loop: the questions define the answer shape, and an uncertain answer is part of the result instead of a schema field you add and check yourself.

Start here

QuickstartAsk yes/no and multiple-choice questions and handle an uncertain answer.

Use decision models

Questions and answersDefine choices, control uncertainty, and read the result.

Decisions in an agentAsk from a tool and count the tokens toward the agent's request.

Choose a decision modelUse a model provider, or write your own decision model.

Observe decisionsTrace each decision with OpenTelemetry.