Code and dense tables are folded away. Open any of them on demand.
What is a decision model for AI agents?
A decision model for AI agents is a fast classifier that answers the small, typed judgements around an agent's language model: is the input safe, what is the intent, which tool fits, should a human take over. It returns probabilities over defined options instead of text, so each check is cheap, quick and easy to threshold.
A modern agent loop, in the style popularised by ReAct (Yao et al., 2022) and tool-using models such as Toolformer (Schick et al., 2023), alternates between thinking, choosing an action and observing the result. Around that core, production agents add a ring of smaller judgements:
- Before the turn: is the input a jailbreak or a prompt injection, does it contain sensitive data, what language is it in?
- Understanding: what is the intent, how urgent is it, how frustrated is the user?
- Acting: which tool, which queue, which sub-agent, which model tier?
- After the turn: does the draft reply leak data or violate policy? Should a human review it?
Each of these is a typed decision with a small answer space. In many stacks, each is also a separate call to the same large language model that writes the replies.
Why not let the LLM decide everything?
Using the LLM for every decision is simple and often accurate, but it has costs that grow with the agent's reach:
| Issue | Effect in an agent |
|---|---|
| Latency per call | Serial decisions add up; see latency budgets for agents |
| Cost per call | Every decision re-sends the context and pays for output tokens |
| Free-text output | Every decision needs parsing and validation |
| No usable probability | Hard to set thresholds or escalate by confidence |
| Same model judging itself | A guardrail that shares the planner's model shares its blind spots and its attack surface |
The last point is easy to miss. A guardrail implemented as a prompt to the same LLM can be steered by the same injected text it is supposed to catch, and it can respond with text. A separate, non-generative decision model can be fooled into a wrong score, but it cannot be talked into writing anything.
System 1 and System 2 in an agent
Kahneman's Thinking, Fast and Slow (2011) describes two modes of human cognition: System 1 is fast, automatic and intuitive; System 2 is slow, deliberate and effortful. The analogy maps cleanly onto agent design:
| System 1 layer | System 2 layer | |
|---|---|---|
| Model | Encoder decision model (e.g. Laya) | Large generative LLM |
| Job | Classify, score, flag, route | Plan, reason, write, call tools |
| Output | Typed answers with probabilities | Text and tool calls |
| Latency | Tens of milliseconds | Hundreds of milliseconds to seconds |
| When it runs | On every input and draft | When needed |
Laya's model card describes it as a "non-autoregressive System 1 decision model." The agent uses it for the high-volume, well-defined judgements and escalates to System 2 when the decision needs reasoning or when System 1's calibrated confidence is low. See System 1 vs System 2 AI and act or escalate.
Where a decision model plugs in
Laya's package ships question presets that map onto the agent ring:
| Preset | Questions | Agent stage |
|---|---|---|
guard_questions | jailbreak, prompt_injection, sensitive_data (noul); harm_severity (score); topic (choice) | Input guardrail |
router_questions | difficulty (score); domain (choice); needs_tools, is_sensitive (noul) | Model tier and tool routing |
triage_questions | intent (choice); is_urgent, refund_requested, churn_risk (noul); frustration (score) | Understanding |
moderation_questions | toxic, harassment, threat, spam (noul); severity (score) | Output or content checks |
email_questions | category (choice); is_spam, is_phishing, needs_reply (noul); urgency (score) | Inbound triage |
A common pattern is one decision request per stage, with all of that stage's questions batched into a single forward pass. Routing to a cheaper LLM for "trivial" requests and a stronger one for "hard" ones, using the difficulty score, is a direct cost saving.
Designing the state for agent decisions
What you send as the state matters as much as the questions. Three habits help. First, send structure, not transcripts: an object such as {"last_user_message": ..., "channel": "email", "plan": "enterprise"} is serialised to JSON, so the model can see which field is which, and instructions can refer to fields by name. Second, put the decisive text first, because long states are truncated from the end. Third, keep the state stable across questions in one request, so every answer is about the same input and the answers can be combined without contradiction.
Honest limits for agent builders
Where Laya fits badly, according to its own model card:
- Large tool catalogs. Options share a token budget, and accuracy falls sharply with dozens of options (0.425 on 77-label Banking77). For big catalogs, shortlist first. The open-source package includes an opt-in embedding shortlist that keeps the top 20 options by cosine similarity before scoring, the coarse-to-fine pattern reported in issue #102. With the hosted API, do the shortlist client-side with your own embeddings, or group tools into categories and ask two questions.
- Complex policy decisions zero-shot. The base checkpoints are near chance on the multi-field typed-decisions benchmark without fine-tuning (0.362 against a 0.461 majority-class baseline).
- The act head. Every answer includes
action.act_probability, but the card says it "carries no usable signal yet" (AUROC 0.30). Gate onconfidence(AUROC 0.77 on the same items). - Calibration. The checkpoints ship over-confident; fit temperatures on your traffic before using fixed thresholds.
noullabel-following. Check yes/no flags on your data; use a two-optionchoiceif they look stuck.- Context. 512 tokens per question on the English checkpoint. Send the latest message and relevant fields, not the whole transcript.
A per-turn decision request to Laya Studio
One call before the planner runs, covering guardrail and routing questions together:
Show technical detailsHide technical details· bash sample
Then wire the answers into the loop:
Show technical detailsHide technical details· python sample
Four questions read the turn four times, billed per input token. Start with 5 free runs at /signup; the docs cover response fields and the routing block.
Frequently asked questions
Should an agent use a separate model for guardrails?
Can Laya choose which tool an agent should call?
Does Laya replace the LLM in an agent?
How do I pass conversation history to Laya?
How many decisions per turn are practical?
What decisions does an AI agent make in a turn?
Can I run agent guardrails on sensitive data in Switzerland?
Sources
- Kahneman (2011), Thinking, Fast and Slow
- Yao et al. (2022), ReAct: Synergizing Reasoning and Acting in Language Models
- Schick et al. (2023), Toolformer: Language Models Can Teach Themselves to Use Tools
- Laya model card
- Laya source code (presets.py, shortlist.py)
- Laya issue #102: coarse-to-fine shortlisting for large label sets
Last updated . Laya Studio is an independent hosted service for the open-source Laya model (Apache-2.0, © Convai Innovations) and is not affiliated with Convai Innovations or TypeSafe.
Next articleWhat is Laya? The open-source AI model for fast, calibrated decisionsLaya is an open-source AI model that answers typed questions about any text with calibrated probabilities in one fast pass. How it works, limits and use.