Typed Decisions vs Free Text: Why Agents Need a Decision Layer
Agents parse free text to make routing and gating calls. A typed decision layer returns a choice plus probabilities instead. See how two small Jev projects show the difference.
There is a quiet inefficiency in most agent code. A step needs to know something simple: is this an invoice, is this action safe, which of three tools fits. The agent sends that question to a general model, receives a paragraph, and then runs brittle code to extract the answer. The model did more work than needed, the parsing adds a failure mode, and there is no clean number to threshold on.
A decision layer replaces that with a typed contract: here is the context, here are the options, give me the selected option and probabilities. TypeSafe AI's Jev model is built around that contract, and small open-source projects have started to show what it looks like in practice. This piece uses two of them, and is careful about what they do and do not prove.
Key Takeaways
- Routing and gating do not need generated text. They need a selection and a confidence.
- A typed result removes the parsing step. The output is already a choice, score or boolean.
- Probabilities enable thresholds. Act when confident, escalate when not.
- Demos are demos. The projects here are tiny and self-described as experiments, not benchmarks.
- Someone still owns policy. A decision model says what it thinks; your code decides what is allowed.
The demo that routes an email
typesafe-jev-workflow is a small async LangGraph workflow (4 stars as of September 2026). It sends a mocked email to Jev and receives a typed Choice, either invoice or general. The graph then routes deterministically: invoice goes to an accounts_payable handler, general goes to general_inbox. The handlers only set a destination in graph state. They do not send email or move money.
Note what the code does not need: no prompt asking the model to "reply with exactly one word," no regex, no fallback for a chatty answer. The README is also candid about limits. The demo set is ten labeled examples (five invoice, five general), described as a smoke check rather than an accuracy benchmark. It exposes confidence, but the workflow always routes to one of the two handlers regardless of confidence, so there is no threshold in the shipped version. A real system would add one. You can find it on aiskill.market as typesafe-jev-workflow.
The chat UI that only decides
jevchat (1 star) is more playful and more revealing. It is a chat interface where, by default, Jev answers Yes or No. Under the hood, per its README, it sends a choice question whose criteria are the style's answers, "so Jev itself picks which answer to give." Built-in styles include Yes/No/Maybe, Mom, Pirate and tabloid headlines, and users can define custom answer sets. A details toggle shows the calibrated probability for every option.
That last feature is the point. The interface is a joke; the mechanism is not. Every reply is a selection from a closed set, so you can always see how the probability mass was distributed. Try building that with free text. See it at jevchat.
Where free text still wins
Be even-handed: a decision layer is not a replacement for generation.
| Need | Better fit |
|---|---|
| Pick among known options | Typed decision |
| Score a criterion, gate an action | Typed decision |
| Draft, explain, transform content | Text model |
| Open-ended reasoning with unknown options | Text model |
The closed-set requirement is the constraint. LightJev, a training framework for typed-decision models, states it plainly: it is not a chat model, it classifies among predefined candidates, and its reported results are "synthetic-task, single-seed." Decision models are precise tools with a narrow surface.
There is also a trust boundary. Typed does not mean verified. The jev-mcp server by jkudish reports latency of about 150-500 ms in the author's own words and cautions that typed output does not guarantee factual accuracy and thresholds need calibration. Those are author statements, not independent tests.
A practical pattern
- Define the options as a closed list.
- Ask one typed question per decision point.
- Set a confidence threshold from labeled data (see calibrating Jev thresholds).
- Route low-confidence cases to a larger model or a human.
- Keep permissions and risk policy in your own code, not in the model's probabilities.
Step 5 is how JevRouter is designed: its README says Jev owns the decision probabilities while the router owns availability, permissions, risk and confirmation.
What to do next
- Clone one of the demos above and swap in your own labels.
- Find one place where your agent parses a model's prose into a category. Sketch it as a typed choice.
- Read the Jev primer if you skipped it, then continue with browser decisions.
- Keep the full radar handy: awesome-jev-projects.