10 patterns where Jev, not your frontier model, should decide

TypeSafe shipped something unusual this month: a model that never writes a sentence. Jev takes in a state and returns a typed decision, a choice, a score, or a probability, in roughly 70 to 500 milliseconds, for about four hundredths of a cent per call. Route the same decision through a frontier model and you’re paying thirty to a few hundred times as much and waiting noticeably longer for it. It’s already showing up in real infrastructure, not just a launch post: Vercel added it to the AI Gateway within days.

Most of what an agent does in production isn’t reasoning. It’s deciding: which sub-agent takes this step, is this tool call safe, does this ticket go to billing or engineering. TypeSafe calls Jev a “System One” model on purpose, borrowing Kahneman’s language for the fast, pattern-matching kind of thinking, and leaving the slow, deliberate model for the handful of steps that actually need it.

One honest caveat before the list: the accuracy numbers below come from TypeSafe’s own four-workflow benchmark, not an independent audit, and the gap to a frontier model varies a lot by task. Treat this as where I’d start piloting, not a verdict.

Ten places I’d point it before a frontier model

1. Choosing which sub-agent takes the next step. An orchestration loop makes this call constantly, and it’s a fixed menu of options, not open-ended generation. A model built to output a calibrated choice is the better architectural fit than spending a full chat turn on it.

2. Confidence-gated autonomy. Set a probability threshold per action, scaled to what a wrong call costs, instead of one blanket number for the whole system. Act automatically above it on cheap, reversible steps, ask a human to confirm the expensive ones, and escalate to the frontier model only when the score comes back genuinely unsure. I wrote about the cost of skipping this math in the autonomy budget.

3. Guardrails before a tool call executes. Safe, needs confirmation, or blocked is a plain probability estimate, and running it at production-line speed catches the expensive mistake before the action happens, not after a full model turn already committed to it.

4. Pruning what the agent remembers. A long session accumulates tool-call traces until the context window is mostly noise. Scoring each trace’s ongoing relevance and dropping the low scorers is housekeeping, and on TypeSafe’s own trace-observability set the accuracy gap to a frontier model is close, 71.6 percent against 76.6. Paying reasoning prices to do this every few turns was never worth it.

5. First-touch ticket and request triage. Routing an incoming message to the right queue is a calibrated read of the text, not a reasoning problem, and it’s where the benchmark gap is smallest, 76 percent against 78.3 on customer-service classification. This is the pattern I’d trust first.

6. Fraud and risk scoring at the edge. A downstream system consumes a probability, not a paragraph of justification, so a model that returns exactly that, fast, fits the shape of the problem better than a chat-shaped API call per transaction.

7. Content moderation at volume. High-volume, latency-sensitive classification is the exact profile this model class was built for, and the small share it flags as uncertain is what’s worth sending to a person.

8. Invoice and expense flags, carefully. This is a fit in principle, but it’s also where the gap is widest on TypeSafe’s own numbers, 61.8 percent against 79.1 on their invoice-processing set. I’d keep a human or the bigger model in the loop above a modest dollar threshold, not remove them.

9. Security alert triage, with the same caution. It’s on the vendor’s own use-case list, and the gap here is moderate, 61.7 percent against 66.2, but a missed real incident is expensive enough that I’d use it to clear obvious noise, never as the last word on an actual alert.

10. The gatekeeper question. The most useful pattern isn’t any single decision above. It’s putting a cheap model at the front door of an expensive one, deciding in milliseconds whether a request needs real reasoning at all before it goes anywhere near a model priced by the token.

Where I’d still send it to the bigger model

Anything that has to explain itself in prose to a customer, anything genuinely novel and outside a known set of options, and, per the numbers above, invoice review and security incidents above a low-confidence floor. The pattern isn’t “replace the frontier model.” It’s “stop paying reasoning prices for decisions that were never reasoning problems,” which is the same logic I laid out in point your AI where the checking is cheap: the win comes from matching the tool to the shape of the task, not from chasing the smartest available model.

There’s a bigger shift hiding in a niche-looking launch. For two years, the “which small model should I fine-tune for this classification task” question spawned its own tooling industry. A general, calibrated decision model that’s cheap and fast enough to call on every agent turn quietly undercuts a lot of that market, the same way managed vector databases absorbed what used to be a bespoke embeddings pipeline. And it moves the engineering effort somewhere more durable: less time tuning a prompt, more time deciding exactly what decision you’re asking for and defining its output cleanly. That’s a better problem to be good at.

If you’re mapping which decisions in your own agent stack could get faster and cheaper without losing the accuracy that matters, that’s exactly the kind of audit I run in an AI advisory hour.