Deterministic ML, in practical AI systems, means a locked path: same input, same output. No sampling at decision time for that path.
In agent stacks built on chat models, that usually means something narrower and more useful. After a structured classification, your code runs a fixed lookup, rule, reuse, or stop. It does not start another free-form generation loop.
Chat LLMs sample the next token. The same prompt can yield different prose. That is fine for drafting. It is a poor control plane for spend, retries, and irreversible actions.
Typed decisions are not prose to parse
Most product AI still coerces a text generator into a decision. You ask for JSON. You parse. You hope the keys stay stable.
You still own the mess when the model invents a field or softens a refusal into a maybe.
TypeSafe's flagship model, Jev, is built for a different contract. It is a System One decision model. You send state plus typed questions.
You get structured answers your code can use directly: Choice, Score, and Noul, with probabilities and confidence where those types support them. No text generation. No parsing step.
TypeSafe frames the training objective as RLCD, reinforcement learning for calibrated decisions, not RLHF chat preference. The point is usable uncertainty for software, not nicer paragraphs.
Be honest about the word deterministic. Jev is not a frozen linear model that will spit the same bit string forever. It is a decision model. The system becomes more controllable because the outputs are typed and your policy code is deterministic.
Classify, then route
The useful pattern is intent routing. Classify the work first. Then route each class to the cheapest safe handler.
TypeSafe's docs walk a customer-service shape that maps cleanly to agent work:
- Intent like
order_statusgoes to deterministic order lookup. - Product or returns questions go to a specialist LLM with the right context.
- Low confidence, or high complexity on a complaint, goes to a human.
Jev returns the calibrated typed decision. Your code then runs the branch. That split matters. The model does not "do the order lookup." Your deterministic handler does.
I want that same split in my own agent stack. Cheap classification before expensive browser, research, retry, or subagent work.
A working example: Grok Bot + Jev
I open-sourced a small reference router for that pattern: grok-bot-jev. It sits as a decision layer around TypeSafe's system_one call. It does not change Grok Bot's foundation model.
The router returns explicit actions such as:
reuse_cachestop_retryrun_deterministic(lookup-style work)chat_onlyresearch_cappedallow_subagentask_human
Today we run it in shadow mode. It is advisory plus metrics. We log route.action. We do not honor it to enforce behavior yet.
Send, publish, pay, and delete still require a human path. Active mode is not live.
That is the right sequence. Measure whether the classifier would have stopped waste without blocking good work. Then decide whether to enforce.
What one local A/B run showed
The repo includes examples/ab_results.md. It is one recorded local run. Treat the numbers as proxies, not a guarantee and not a Grok token-dollar claim.
Across five tasks in that run:
- Google Flights browser opens went from 1 to 0 when a cached Phase A JSON artifact was reused.
- Same failing-approach attempts went from 3 to 0 after
stop_retry. - Model-research pages fetched went from 10 to 4.
- Flight-prep skills loaded went from 6 to 3.
A separate 24-candidate timing comparison used a shared collection step outside the arm ratio. Without Jev: about 53.8 seconds and 14 pages. With Jev ranking a top-five cap: about 4.1 seconds and 5 pages.
Fewer confirmed hits were by design because of that cap. Jev cost on that arm was estimated around $0.0004.
Caveats stay on the page. The flight arm with Jev reused an existing cache. Exact per-task Grok tokens were not available.
Weekly usage meters moved a little and do not prove savings. I will not invent Grok dollar savings from this.
What the run does show is the shape of the bet. A small typed decision can cut needless opens, retries, and pages when your code is ready to honor the branch.
Why this beats another free-form loop
Teams burn money on agent loops that re-research what they already have, retry the same broken approach, and open the browser when a lookup would do.
A catalog of tools is not a control plane. A second LLM that "thinks harder" is not a control plane either. A typed classify step plus deterministic handlers is.
- When confidence is low, escalate.
- When the intent is a lookup, look it up.
- When a fresh artifact exists, reuse it.
- When the same approach already failed, stop.
That is boring on purpose. Boring is how you sleep when the bot has a credit card and a browser.
What I would do this week
Pick one expensive path in your agent or support stack. Write the intents you already know by heart.
For each intent, name the handler: deterministic code, specialist LLM, or human. Add a confidence gate so low certainty defaults to a person.
Wire a shadow classifier first. Log what it would have chosen. Compare that log to what you actually did for a week. Only then turn enforcement on for the safe branches.
If you want the reference shape we use with Grok Bot, start at the open repo and TypeSafe's intent-routing docs. Keep shadow until the labels say the decisions are trustworthy.