Jev Use Cases in an Agent

1. Route to the right model

The oldest cost lever in agent design is not sending every turn to the flagship. The problem has always been that deciding which model to use costs a model call. At $0.042/MTok with a 70–500ms round trip, that decision becomes nearly free.

from langchain_typesafe.experimental.middleware import (
    ModelChoice, ModelRouterMiddleware
)

router = ModelRouterMiddleware(
    choices={
        "fast": ModelChoice(model="openai:luna", criteria="Direct lookups, simple edits"),
        "powerful": ModelChoice(model="openai:sol", criteria="Architecture, multi-file changes"),
    }
)

With GPT-6 Luna at $0.10/MTok against Astra's $10, routing correctly even 70% of the time pays for itself many times over. Measure the routing accuracy, not just the savings — a cheap model on a task that needed the expensive one shows up as a retry, and two cheap attempts plus a frontier attempt costs more than going straight there.

2. Gate a destructive tool call before it runs

This is the use case we would put first for anyone running an unattended agent. Before a tool call executes, classify it:

from langchain_typesafe.experimental.middleware import AutoModeMiddleware

guardrail = AutoModeMiddleware(tools=["bash"])

A worked example from the demo video: the state was a proposed delete against a customer table, with the context that no backup had been taken that day. The question was "is this action safe?", with the criteria spelling out that safe means reversible or low impact. Jev returned yes at 0.4% and no at 96%, with a recommendation to pause and ask a human.

Note what makes that work: the context included the backup status. A gate is only as good as the state you assemble for it. This pairs with the approval rules in our security guidance — and note it is a control, not a guarantee: a 96% "no" is a strong signal, not a proof.

3. Support triage, in one request

Four questions about one message, answered together: which department, was a refund requested, is it urgent, how frustrated is the customer. In testing, a duplicate-charge message returned billing, a refund probability of 98%, urgency at 11%, and a frustration score near the calm end — correctly separating "wants money back" from "emergency".

Then the same message rewritten as "I am not asking for a refund, I only need a copy of my invoice" kept billing but dropped the refund probability to 3%. That negation handling is the behaviour worth testing on your own wording before you connect it to anything that moves money.

4. Lead scoring

A Score question across ordered levels — browsing, evaluating, ready to buy, urgent — turns an inbound email into a number your CRM can act on. In the demo, an email mentioning 40 seats, an incumbent contract ending on the 30th and a request for a security review call scored urgent with 97% confidence, with the probability distribution across the other levels returned alongside it.

The distribution is the part to keep. A 97% "urgent" and a 51%/49% split between "urgent" and "evaluating" are very different inputs to a sales workflow, and only one of them should page a human.

5. Extract a value by choosing between candidates

Jev cannot generate a string — but it can select one. Given a message containing a sender address, an old billing address and a new one, with those values supplied as the options, it selected the correct current address exactly as supplied, punctuation intact.

The limitation is the candidate list. Your code collects the possible values, Jev picks, your code copies the original. If the collection step misses the right value, no amount of confidence will produce it. Test the extractor, not just the chooser.

6. Audit an agent's own trace

A quietly powerful one: feed the agent's tool results and its final message in as the state, and ask whether the task actually succeeded. In testing, where the tool results said permission was denied and nothing was saved but the assistant claimed the draft had been saved, Jev classified the task as failed and rated the unsupported success claim at 93%.

That specific case was simple enough to catch with ordinary code. The interesting version is the messy one — several steps, partial progress, conflicting claims — which is exactly where a cheap judgement on every run beats a human spot-check once a week. It needs a real test set before you trust it.

7. Drive a browser loop

The most eye-catching demo so far: Jev Ultrafast, an open-source project from Gregor Zunic combining Jev with browser-use tooling. The loop reads the page, builds a numbered list of controls, and asks Jev to select the next operation and its target — refreshing the choices after every step. A small language model (Mercury 2.5 in the current example) generates any text that needs typing.

The published demo searched Google Flights for a one-way Zurich–London trip in about 7 seconds at a reported cost of $0.0039, at original speed. The caveats, stated by the person who tested it: the timer started after the first page observation, it was a search with no booking, and the cost excluded browser infrastructure. We have not reproduced it.

Architecturally it is the cleanest illustration of the split: Jev chose, a language model wrote, and the browser code still had to verify the target and perform the action.

How to know it is actually working

Everything above is worth exactly as much as your measurement of it. A cheap decision made a thousand times a day is a thousand chances to be confidently wrong, so before you wire any of this to an action:

1. Build a golden set from your own data. Fifty real examples with the answer you would have given beats any benchmark. Vendor speed and cost claims — TypeSafe's homepage cites 193.6x faster and 444.6x cheaper — say nothing about accuracy on your inputs.
2. Check calibration, not just accuracy. Bucket predictions by confidence and see whether the 90% bucket really is right about 90% of the time. Until you have done that, do not read a confidence number as a probability of being correct.
3. Always ship an other/unknown option plus a confidence threshold that routes to a human. Forced-choice schemas produce confident nonsense when reality does not fit.
4. Test negation and near-misses explicitly: "not asking for a refund", "asking about the refund policy", "already refunded".
5. Instruct it to treat the state as untrusted, and try to inject it. One passing injection test is not immunity, but the instruction costs nothing.
6. Pin the model version and re-run the golden set when you move it.
7. Compare bundled against separate questions. Asking four things in one request is cheaper and faster; confirm it is not also worse on your data.

Where it does not belong

• Anything that needs an explanation. Jev returns probabilities, not reasoning traces. If you need a rationale for an auditor, generate it separately with a language model — and do not present that rationale as Jev's reason for deciding.
• Open-ended categorisation. If you cannot enumerate the options, this is the wrong tool.
• Long documents, without chunking or retrieval in front: the input context is 32K.
• Images, which are not supported yet.
• As the only check on an irreversible action. Gate, then require a human for the destructive branch.