Skip to content

Decision model vs LLM: when agents should classify, route, and gate

When should an agent use a decision model vs an LLM? A practitioner look at TypeSafe Jev use cases for tool approval, routing, and typed Choice/Score outputs.

Railway signals in fog: classify, route, and gate

TypeSafe just shipped Jev, a System One decision-only model: state plus typed questions in, Choice / Score / Noul out (with probabilities, and confidence on Choice and Score). No prose. No parsing a paragraph into a boolean. Docs are live at docs.typesafe.ai/introduction.

This is not a long-running production diary either. It is a practitioner frame for decision model vs LLM, plus three Jev use cases worth trying first if your agents still classify, route, or gate with chat replies.

Why the split exists

Here is the failure mode Jev is aimed at. An agent “approves” a tool call in perfect English. The paragraph says the shell command only inspects logs, risk is low, proceed. Your harness greps for safe or approve and runs it. The command is a compound pipeline: the front half reads a log, the back half deletes a scratch credentials file from two turns earlier. The prose was confident. The file is gone.

That is the wrong job for a text model. LLMs are built to generate. Classify, route, and gate need something else: state in, typed answer out, your code branches. Decision model vs LLM is that job split, not a brand war.

Decision model vs LLM (the frame)

Napkin sketch comparing LLM generation to decision model typed outputs
LLMs shine at open-ended prose; classify, route, and gate belong on a typed decision model that branches in code.
JobPreferWhy
Draft a plan, explain a diff, write codeLLMOpen-ended text is the product
Classify urgency / intent / riskDecision modelTyped label + probabilities beat a paragraph
Route to model A vs B vs humanDecision modelChoice your code can switch on
Gate a tool call (clear vs caution)Decision modelFixed options, no free-text approval theatre
Invent a novel approach under ambiguityLLMThen decide with typed checks

Three Jev use cases to try first

Napkin sketch of tool-call gate clear vs caution vs block
A proposed tool call hits the decision model; confidence informs policy , CLEAR runs, CAUTION escalates to a human, BLOCK stays optional.

These are evaluation targets for a model that is days old, not a tour of Bluelupin production history.

1. Tool approval (clear vs caution)

The language model proposes run_terminal or apply_patch. Before the executor sees the call, ask Jev a Choice over a closed set such as clear / caution (add block if your policy needs it). Put tool name, arguments, and recent turns in the state. Read the typed result in code.

Public early wiring already looks like this: Vercel eve’s approval: auto() asks Jev to classify a proposed tool call as clear or caution. Clear runs; caution pauses for a person. (Vercel KB)

Keep allowlists, sandboxes, and scoped credentials underneath. A classifier is a sensor, not a permission system.

2. Model or tool routing

Simple lookup should not burn a frontier model. Hard architecture work should. Ask Jev a Choice over an allowlist of models (or “escalate to human”) from the same state the agent already has. Your router switches on the Choice. It should not have to interpret a chat suggestion.

LangChain’s TypeSafeClassifier is an early hook for that style of classify / route step next to a generative model. (LangChain: Building a Harness with Jev)

3. Risk and claim checks before the next step

“Tests pass” and “refactor only” are decisions about evidence. Score them on a rubric, or use Noul for “this statement is true given the gate output,” instead of inviting another reassuring paragraph. Mix questions in one call; TypeSafe documents parallel evaluation against the same state.

Typed answers you can branch on

Napkin sketch of atomic questions composed in code
Small Score and Choice questions feed weights in code; change a coefficient, not the prompt.

Jev’s primitives, as TypeSafe documents them:

  • Choice: pick from a closed set. Returns the choice, per-option probabilities, and confidence.
  • Score: rate against ordered levels. Returns score, distribution, confidence.
  • Noul: probability that a statement is true (0 to 1).

The docs push atomic questions: one gut-check each, then compose policy in your code. When priorities shift, change a coefficient in git. You should not have to rewrite a mega-prompt every Tuesday.

How to sit Jev next to an LLM

A practical loop for a first spike:

  1. Put state in front of Jev: tool name, arguments, recent turns, repo path, whatever the gate needs.
  2. Ask typed questions, not “should we proceed?” essays.
  3. Read Choice / Score / Noul (and confidence where present) in application code.
  4. Keep the LLM for drafting, explaining, and multi-step reasoning after the gate says clear.

Optional middleware such as LangChain’s experimental AutoModeMiddleware shows the same idea: check configured tool calls before execution. Attribute those write-ups to their authors. They are early integrations, not Bluelupin case studies.

What stays with the LLM

You are not replacing the generative agent with Jev.

  • Writing and refactoring stay generative.
  • Long-horizon planning stays generative, then you chop the plan into typed checks.
  • User-facing explanation stays generative. The audit log can store both the Choice and the paragraph that explained it.
  • Novel tool use under incomplete schemas may need an LLM to propose; the gate that allows the call should still be typed.

If the only model in the loop is a chat model, every control decision inherits chat failure modes. Jev is one way to add a decision lane where the answer must be branchable.

Checklist before you wire a first Jev gate

  1. Is the output a closed set (or a score on a rubric) that code will consume?
  2. Would a wrong fluent paragraph be worse than a wrong label? (Usually yes for tools.)
  3. Can you write the policy as atomic questions + code, instead of one mega-prompt?
  4. Do you have a caution / escalate path when confidence is low or the review fails?
  5. Are allowlists and sandboxes still enforcing blast radius after the model says clear?

If (1) is yes, prefer a decision model. If the job is open-ended text, keep the LLM.

Close

The credentials-file story is the problem class Jev is built for. What is new is a decision-only model aimed at that interface: judgment your code can branch on, without free-text theatre.

If you try Jev this week, start with one use case (one dangerous tool, clear vs caution) and measure false clears before you spray middleware everywhere. Cite TypeSafe, LangChain, or eve from their docs and posts. We are mapping a fresh release onto agent harness pain, not claiming a long production run.

Leave a comment

Building something in this space?

Thirty minutes with an engineer, not a salesperson.

Start Your AI Journey