Jev cannot write a single word, and that is the reason to care about it. TypeSafe shipped it on 15 September 2026 as a model that returns typed decisions and calibrated probabilities instead of text, priced at $0.042 per million input tokens with output tokens free, answering end to end in 70 to 500 milliseconds. So the question worth asking is never whether Jev should be your agent. It is which decisions inside your agent it should own.
Launch week produced a great deal of coverage of what Jev is, and almost none of where it goes. TypeSafe's own use-case map is the closest thing to an answer, and it is organised by business workflow rather than by the shape of an agent, so it never says where the thing sits inside a support agent as against a voice agent as against a coding agent. Four of the agent types below do not appear in it at all.
The unit worth naming: a decision seam
A decision seam is any point in an agent where code needs a judgement before it can pick the next step.
Your retriever returns twelve passages and something has to decide which reach the prompt. A user finishes speaking and something has to decide what they wanted. A draft refund is ready and something has to decide whether it goes out or goes to a person. Each of those is a seam: a join where a judgement is required, the set of possible outcomes is known in advance, and an action follows immediately.
Seams are worth naming separately from use cases because a use case is a whole workflow and a seam is one join inside it. "Customer support" is not a thing you point a model at; the escalation decision inside customer support is. Most of the disappointment I expect people to have with Jev over the next few months will come from pointing it at use cases rather than seams.
Ask this to tell one apart: can you write down every possible answer before seeing the input, and does code do something different for each one? If the answer is a sentence, it is not a seam.
What Jev returns, in ninety seconds
Three question types, and everything is built from them.
A Noul asks whether something is true and returns one probability between 0 and 1. There is no separate confidence field; the probability carries that information itself, with 0.5 meaning the model genuinely cannot tell.
A Choice asks which of a named set applies and returns the winner, a probability across every option, and a confidence number computed from how tightly that probability bunches. It selects exactly one option, and it accepts at most 255 of them.
A Score asks which level applies on a ladder you describe, between two and ten levels, and returns a fractional position on it. A 1.3 means each level number multiplied by its probability and added up, so mostly level one and leaning towards two.
You send state, which can be a string, an object or an array, and a map of questions. Every question is scored independently against the same state, and all of them run in parallel. State and questions share a budget of roughly 32,000 tokens, about 150,000 characters of English.
response = client.system_one(
state={"message": "My card was charged twice.", "order_id": "A-104"},
questions={
"is_billing": Noul(instructions="Is `message` about billing?"),
"urgency": Score(
instructions="How urgent is `message`?",
criteria=["Can wait", "Should be handled today", "Needs immediate action"]),
},
)
The objection to settle first: typed is not correct
TypeSafe's homepage advertises "Zero Hallucinations", and the Hacker News thread{target="_blank"} on the launch, past 450 comments by 17 September, spent a good deal of them pushing back on that framing. One commenter put the objection precisely: the model cannot emit an invalid type, and it can still emit a completely wrong valid value. The pushback is right and worth internalising before you wire anything up.
A Choice question cannot return an option you did not define, so the output is guaranteed to be structurally valid. That is a real guarantee and it removes a real class of bug, the one where a model returns "Billing " with a trailing space or invents a fourteenth category. It says nothing whatsoever about whether the option it picked was the correct one. Schema validity and factual correctness are different properties, and only the first is guaranteed here.
TypeSafe's own documentation is better on this than its marketing. Their study of repeated pick-one decisions carries the sentence "This experiment does not measure accuracy," and calls its own uncertainty threshold "an illustrative application policy, not a calibrated guarantee." Their cookbooks repeat throughout that thresholds must be fitted against your own labelled data rather than copied from the examples. Their training objective, which they call Reinforcement Learning for Calibrated Decisions, is defined in testable terms: outcomes assigned a probability of 0.8 should occur about 80% of the time. That is a claim you can check on 200 labelled examples, and you should, before any of the seams below go to production.
Some figures circulating in launch coverage, including an aggregate accuracy comparison against a frontier model, do not appear in numeric form on TypeSafe's own pages, where the workflow evaluation is published as a chart. Treat those as unverified until the primary source carries them.
The eleven seams
1. Customer support: the escalation gate
Support agents mostly work until they hit something they should not have tried. The costly mistake is never bad grammar; it is confidently resolving a ticket that needed a person. That gate is usually a keyword list, which is too blunt, or a second model call, which is too slow to sit in the reply path.
One call returns the intent, the frustration level on a described ladder, whether the retrieved policy actually covers this case, and whether the customer asked for a human outright. Then confidence routes, with thresholds scaled to consequence rather than set globally. TypeSafe's own worked example makes the asymmetry concrete: checking a balance is safe at 0.6 confidence, approving a transfer requires 0.85 and otherwise asks the user to confirm.
Ticket triage is the use case. The escalation gate is the seam.
2. RAG and knowledge assistants: between retrieval and the prompt
Retrieval quality problems are mostly contamination problems. Twelve passages come back, three are relevant, one contradicts a premise in the question, and all twelve enter the prompt with equal standing.
TypeSafe's passage-gating recipe{target="_blank"} screens each retrieved passage with four yes-or-no questions covering relevance, usable evidence, contradiction of the query premise, and whether the passage is trying to instruct the system reading it. Routing runs in priority order, and the order carries the insight: a passage that contradicts the premise often also scores high on usable evidence, so contradiction has to be tested first or it gets quietly filed as support. Across an 81-passage corpus with six queries, at least two thirds of retrieved passages were excluded.
Reranking is the second seam in the same pipeline and carries the strongest numbers TypeSafe has published. On a corpus of 3,565 court-opinion passages with 40 evaluation queries, BM25 alone put the correct passage first 5% of the time; rescoring the top 30 with one yes-or-no question per pair moved that to 18% at rank one, 35% in the top five and 62% in the top ten, across 1,200 calls costing $0.0645 in total on jev-1.12 in August 2026. Reranking only reorders what retrieval already returned, so it raises precision and never recall.
Both seams apply directly to a memory layer as well as to a document store. An agent fetching prior context from Maximem Synap faces the same question a retriever does, which is whether what came back is relevant, current, and consistent with what the user just said; the typed answer to that question is what decides whether the memory reaches the prompt or gets held back.
One caveat stated plainly in TypeSafe's own recipe: the prompt-injection score is informational, not a security boundary. Use it as a flag on a record. Do not use it as a control.
3. Coding agents: which tool or skill to load
Nobody has written about this one, and it is among the clearest fits.
Coding agents accumulate large tool and skill rosters, and selection accuracy falls as the roster grows. Putting 182 skill descriptions in the system prompt inflates context on every turn and makes similar skills indistinguishable once their descriptions are truncated to fit.
TypeSafe's skill-selection recipe{target="_blank"} runs two stages: a wide pick-one ranks the whole roster while a yes-or-no gate decides whether any action is warranted at all, then a second pass re-examines only the top three candidates using full descriptions rather than truncated ones. Measured over 488 requests with Claude Haiku 4.5 as the agent and jev-1.12 doing the ranking, wrong skill loads fell from 16.8% to 7.3% and unnecessary loads from 9.8% to 4.0%.
Their honest counterpoint deserves carrying: 37 requests were fixed and 7 previously correct selections were broken by confident wrong suggestions. A confident wrong hint gets followed more readily than no hint at all, which is why the gate threshold exists and why the suggestion is injected as something the agent may ignore.
A second seam for coding agents is semantic linting in continuous integration, covering team conventions that no regular expression can express. Whether a migration is reversible, whether an error is swallowed rather than handled, whether a public function's behaviour matches its name. Fractions of a cent per pull request.
4. Voice agents: intent capture inside the turn-taking budget
Latency is not a metric in voice, it is the product. Much beyond 300 milliseconds between the user stopping and the agent starting reads as a broken conversation, and speech-to-text and text-to-speech have already spent most of that.
A 111 millisecond typed classification fits inside that gap. A 1.4 second model call does not. One request resolves the intent, the domain, the target device or account, the action, whether this turn corrects the previous one, and whether the speaker sounds like they want a human, after which deterministic code can start acting while a generative model handles only the turns that genuinely need language. TypeSafe's smart-home demo runs exactly this shape, asking every question in parallel before knowing which will matter, and describes the classification step as adding negligible latency next to the language model call.
Of the eleven, this is the seam where the difference is most immediately audible.
5. Sales and SDR agents: reply triage and lead scoring
Two seams, both high volume, neither glamorous.
Reply triage is a pick-one over a closed set covering interested, not interested, wrong person, out of office, asked to be removed, and asked a question. It runs on every inbound reply, tolerates latency, and carries a direct cost per misclassification; the removal requests in particular are the ones you cannot afford to mishandle.
Lead scoring is where composite scoring{target="_blank"} fits. Score industry fit, company size fit, stated problem and buying signal as separate ladders, normalise each by dividing by the number of levels minus one, then weight them in your own code. TypeSafe's resume example shows why keeping the dimensions separate matters: the same four scores, reweighted, rank candidates differently for an individual contributor role and a management one. Your ideal customer profile changes, you change four numbers in a file, and the change shows up in a pull request rather than in a prompt nobody wants to touch.
6. Research agents: screening before you pay to read
A research agent's bill is dominated by reading. It gathers 200 candidate sources and spends tokens pulling each one into context.
Screening each candidate on its title and snippet, asking whether it is on topic, whether it is a primary source, whether it contains data rather than commentary, and whether it is recent enough, costs a fraction of a cent and cuts the reading bill hard.
Citation verification is the back end of the same pipeline, and TypeSafe's recipe{target="_blank"} is a good lesson in doing the boring part in code. Normalise whitespace and curly quotes, then plain string matching decides whether the quote exists at all, catching fabrication with no model call. Only for quotes that genuinely exist does a three-way question run: does this section support the claim, contradict it, or say nothing about it. Matching is exact after normalisation, so a lightly reworded but accurate quote comes back flagged, which is a real limitation and an argument for surfacing rather than auto-rejecting.
7. Document processing: verifying the cheap extractor
Standard trade: a small model that is cheap and invents things, against a large model that is accurate and expensive. Schema constraints do not settle it, and TypeSafe's framing of why is precise: language models rarely fail schema validation, and constrained decoding does not fix semantic hallucination. The output is well formed and wrong.
Their cascade extracts with the cheap model, then asks one yes-or-no per extracted field, covering whether the value is absent from the source, attached to the wrong entity, overstated relative to what the source says, or missing when it was required. Escalation to the expensive model happens only when a flag crosses 0.7, aggregated on the maximum rather than the mean. They report quality comparable to the top-tier model at roughly a tenth of the cost.
Two field-level techniques are worth taking whole. For exact values, a regular expression finds every candidate span in the document and the model only picks among them, so the string you get back was copied rather than composed and cannot carry a transposed digit. For dates, seven pick-one questions ask about the parts named in the text while the calendar arithmetic happens in ordinary code, on the principle that the model reads what the text says and never does the maths.
8. Personal assistants: the confirm-before-writing gate
An assistant that reads is harmless. An assistant that books, cancels, sends or pays is one misreading away from a bad afternoon. The judgement that matters is not what the user asked for; it is whether you are sure enough to act without checking.
Score how reversible the action is, how specific the request was, and whether anything in the retrieved context conflicts with it, then gate with thresholds scaled to consequence. Reading a calendar at 0.6. Moving a meeting at 0.85. Cancelling a booking never without a confirmation, whatever the number says.
Temporal resolution is the companion seam, and it is where scheduling agents actually break. "Next Tuesday", "the week after the conference", "same time as last Thursday". The parts-based date recipe handles these with a review threshold at 0.60 and with the ambiguous semantics, such as a bare weekday meaning the next occurrence on or after today, living in code where they can be unit tested.
9. Moderation and trust and safety: the policy layer
Model safety boundaries differ by provider and version, cannot be configured, and move under you on upgrade. Any platform of size ends up building its own layer, and the requirement is not only detection; it is that the thresholds are configurable, auditable and defensible to somebody who was not in the room.
TypeSafe's guardrails recipe{target="_blank"} runs one call per message carrying four hazard probabilities plus a severity ladder from 0 to 3, applied to the input and the output both, on the reasoning that a harmless prompt can still produce a harmful reply. Routing goes through thresholds the organisation sets, with review at 0.35, action at 0.70 or 0.85 depending on strictness, and a severity override that turns review into a block at 2.0.
Structural gain: policy becomes a configuration file rather than a paragraph of English inside a prompt. Different customers, different thresholds, same code. Every decision logs a number, which is what an audit actually wants.
10. Operations and approvals: the auto-approve threshold
Expense approvals, access requests, refunds, publishing, deployment gates. The value is approving the dull majority without approving the one that mattered, and the failure mode is a rule engine that reaches 400 lines and still misses the novel case.
Separate ladders for how unusual the amount is, how well it fits policy, what the requester's history looks like and how good the justification is, combined with weights in code. Two thresholds then do the work: approve above, reject below, human in the band between, with the band sized to the review capacity you actually have. Because the dimensions survive into your code before being combined, every decision explains itself as "policy fit was the weak one", which is the sentence an approver wants.
11. Model routing: the seam inside your harness
Classify each incoming prompt for domain, difficulty and risk in a tenth of a second, then choose which model gets it.
The arithmetic is the argument. Routing between a model at $0.75 per million input tokens and one at $5.00, a classifier costing $0.000043 per call that sends the easy majority to the cheaper model pays for itself thousands of times over on any real volume. Difficulty estimation is the hard part and the part worth calibrating first, because a router that underestimates difficulty degrades quality invisibly.
Five traps
A pick-one always picks something. Probabilities must sum to one, so a Choice will nominate a winner even when no option fits. Run a separate yes-or-no asking whether anything applies and treat it as the gate; the pick is only meaningful once the gate opens. This is the single most common way a seam goes wrong on cold-start or out-of-scope inputs.
Take the maximum, not the mean. When several checks feed one decision, one confident red flag is the whole signal. Averaging is how you lose it. The same logic applies inside a single call: TypeSafe's function-calling recipe reports confidence as the least certain judgement across the arguments rather than the product, on the reasoning that one wrong argument spoils the result.
Wording is load-bearing. Rewriting one question from "does this line pick up mid-sentence" to "is this the same paragraph" broke an entire pipeline of theirs, because list items score high on topic continuity. Their rule is the useful one: the question should name the narrowest fact that decides it. Treat a rubric edit as a code change that needs re-measurement, and keep the questions and thresholds together in one file so a reviewer can see them.
Asking more costs almost nothing. Questions run in parallel and you pay only the input tokens for the extra question text. Thirteen questions against a 54,000-character document, batched into one call, measured 12.2 times cheaper and 10 times faster than thirteen separate calls with the answers unchanged. So ask everything you might need, including questions that will turn out irrelevant, and discard them in code.
The limits bite at scale. 255 options per pick-one, and about 32,000 tokens shared between state and questions. A taxonomy larger than that needs a hierarchy, and TypeSafe's beam-search recipe is worth reading before you build one: greedy descent got the right leaf in 2 of 4 test hierarchies while keeping three candidate paths got 4 of 4, because one early wrong turn is unrecoverable otherwise.
Where the seam does not belong
Anything whose answer is a sentence stays with a language model. Summaries, replies, explanations, code. Jev produces no text at all, and the two-model shape that most of the launch commentary landed on is the right one: a generative model writes, a typed model decides, and ordinary code holds the control flow between them.
Anything deterministic stays in code and should never reach a model. Is the ticket closed, is the amount over the limit, is the user entitled to this record, has this document already been processed. Their own worked example opens by filtering closed tickets in Python before building any state, and that ordering is deliberate.
Anything consequential and uncertain stays with a person. The point of a calibrated probability is to identify those cases honestly rather than to eliminate them, and a system that routes 25% of decisions to review is working correctly if those 25% are the genuinely hard ones.
There is one more category, and it is the one that will disappoint people. Anything requiring multi-step reasoning over a long context is not a seam. "Given that step three failed, was step seven a reasonable recovery" is a question you have to decompose into atomic parts and rejoin in code, or hand to a reasoning model. Jev has no memory between calls, no conversation, and no ability to chain its own judgements.
Two things to settle before production
Pin the model version. In TypeSafe's own published study the alias jev-latest resolved to jev-1.13.0, and a seam whose behaviour shifts under a silent upgrade is a seam you cannot reason about. Pin it, and re-calibrate deliberately when you move.
Ask about the commercial terms, because the documentation does not carry them. There is no pricing page on the docs site; every cost figure in this piece comes from worked examples inside their cookbooks, dated August and September 2026. The API reference documents a 429 error without publishing any numeric rate limit, and no service commitment appears anywhere. For a seam sitting in a request path, the rate limit is not a detail.
What an agent looks like when the seams are typed
Trace a request through a build where every seam has been moved: a typed classification decides what the user wants, code decides what to fetch, a typed screen decides what reaches the prompt, a language model writes the reply, a typed check grades it before it ships, and a threshold decides whether it goes out or goes to a person.
Your generative model does one job in that path, the job it is good at, and every decision around it is a number your code can read, log and test. Failures stop being mysterious, because each seam logs a probability and a threshold, and a bad outcome traces to one of them.
That is the actual shift, and it is an architectural one rather than a cost one. A model that cannot write turns out to be the thing that lets you stop asking a writer to make decisions. The decisions were always the part you needed to inspect.
