Jev, TypeSafe AI's Model, and the Agent Harness Pattern

An agent is a loop. It decides, it acts, it evaluates what came back, and then it goes round again, and most teams pay frontier-model prices for every single turn of that loop. That is why so many agent pilots die in budget review rather than in testing: the thing worked, it just cost too much per completed task to defend. The harness pattern fixes that, and it is worth being precise about what it fixes. It does not make your agent smarter. It stops you spending your best model on the steps that never needed one.

I spend a fair amount of my week listening to founders describe agents that work beautifully in a demo and cannot survive a finance conversation. Jev, released by TypeSafe AI in September 2026, is in the title because it is the clearest recent example of the fix. But the pattern matters more than the product, and it will outlast any one model.

What is an agent loop, really?

Strip away the framework and an agent is four things in a circle. It decides what to do next. It does it, usually by calling a tool or an API. It evaluates what came back. Then it repeats, until some condition says stop.

The important word is repeat. A single-shot AI feature is one call: prompt in, answer out, and you can reason about the cost on the back of an envelope. An agent is not that. An agent handling a moderately messy task might go round that loop eight or fifteen or forty times, and every pass is at least one model call. The cost of an agent is not the cost of a question. It is the cost of a question multiplied by however many turns the task happens to need, which you do not know in advance.

That multiplication is the problem. A task that takes four turns on a clean input might take twenty on a messy one, and messy inputs are what production is made of. Teams discover this in month two, when the invoice arrives and nobody can explain the variance.

What is Jev, and what is TypeSafe AI actually claiming?

Let me be exact about it, and about whose claims these are.

TypeSafe AI announced Jev on 15 September 2026 and calls it a System One model. Rather than generating prose one token at a time, the company says Jev returns type-safe structured values with calibrated probabilities and confidence scores: you define the possible answers in advance, and the model picks among them. TypeSafe AI's headline claim, in its own words as of that announcement, is that "Jev achieves similar levels of intelligence on System One tasks compared to existing LLMs, while being two orders of magnitude faster and more efficient." It puts end-to-end response time at 70ms to 500ms, prices input at $0.042 per million tokens, and lists output as free. At the time of writing it is in early access, with developers coming off a waitlist.

LangChain, writing on 17 September 2026, describes Jev as a System One model that evaluates a state and returns typed answers and probabilities, and reports figures of up to 200 times faster inference and 400 times lower cost than comparable LLMs on classification tasks. LangChain built an integration exposing Jev as a classifier, and demonstrated two patterns with it: routing between a fast model and a capable one based on how hard the task is, and classifying tool calls as risky before they are executed.

Every number above is a vendor's own claim, published within days of a launch, and I have measured none of them. Treat them as a prospectus, not a benchmark. LangChain is also straight about the limitation, which I appreciate: Jev "isn't a drop-in replacement for an LLM. It doesn't generate text." It is a different tool, not a cheaper version of the same one.

I would not rebuild an architecture around a model in early access, and that is not a criticism of TypeSafe AI; it is how early access works. What Jev tells you is that the category is real enough for someone to build a model specifically for it, and for a major framework to integrate it within days. The idea underneath is older and safer than any product: constrained components handle the mechanical steps, and the general model is kept for the genuinely general parts. You can build that today with a smaller model from whichever provider you already use, or with ordinary code and no model at all. The cheapest inference is the call you did not make.

Where does the cost actually go?

Go through the turns of a real agent loop and sort them by what each one actually requires.

Classifying an input is a short decision with a handful of valid answers. Routing to a tool is a pick from a list you wrote yourself. Calling the tool is mostly waiting on somebody else's system. Validating what came back is checking a shape you already defined. Only one step in that sequence is genuinely open-ended: working out what the result means and what it implies for the next move.

Four of those five are the kind of decision where you could write down every acceptable answer in advance. Yet in the default architecture, all five go to the same frontier model, at the same price, with the same latency. You are paying reasoning rates for a multiple-choice question, dozens of times per task, and the multiple-choice questions are the majority of the loop.

That is the economics problem stated properly: frontier models are not expensive, you are just buying them for work that does not need them.

What is a harness, and what belongs in it?

A harness is the machinery around the model that runs the loop: the code and the smaller models that decide what happens next, enforce the rules, and only call the expensive model when a step genuinely needs judgement. The term is already in use for coding assistants, where the harness is what classifies a dangerous action before it is taken rather than after.

Five kinds of work belong in the harness rather than in the reasoning model:

• Classification. What kind of thing just arrived: invoice or complaint, urgent or routine, in scope or not.
• Routing. Which tool, queue, or model handles the next step, from a list you control.
• Validation. Checking that a result has the shape you expected before anything downstream touches it.
• Guardrails. Whether an action is allowed at all, before it runs. Move this one first: a check that runs in milliseconds can sit in front of every action without anyone noticing.
• Retries and control flow. Deciding whether to try again, escalate, or stop. That is bookkeeping, and bookkeeping is code.

What stays with the reasoning model is what you hired it for: weighing things you could not enumerate ahead of time, drafting language a person will read, and the judgement call at the end.

How do you decide which step gets which model?

Two questions, in this order.

Can you list the valid answers in advance? If every acceptable output fits in a list you could write down, the step is a classification problem wearing a costume, and it belongs in the harness. If the answer could be a paragraph nobody has written yet, it needs the reasoning model.

If it goes wrong, is that cheap to catch? A misrouted ticket that a human sees in the next screen is cheap. An approval sent to the wrong counterparty is not. Where a mistake is expensive and hard to detect, keep the stronger model even when the first question said you could downgrade, or put a human in front of the consequence.

Start with guardrails and classification: the highest-volume, lowest-judgement steps in almost every loop.

How do you know the cheap model is safe?

You measure it, on your decisions, not on anyone's benchmark. This is the step teams skip, and skipping it is how a cost optimisation quietly becomes an accuracy incident.

The method is not exotic. Take a few hundred real inputs, record what your current setup decides for each, run the small model on the same inputs, and compare. Pay attention to the disagreements rather than the headline accuracy, because that is where the risk lives. Keep it running after launch, because inputs drift. Our guide on how to evaluate LLM outputs covers how to build that harness of tests properly, and it applies exactly here.

One detail worth having: a model that returns calibrated confidence gives you an escalation rule for free. Below a threshold you pick, hand the decision up to the bigger model. That turns the cheap model from a replacement into a filter, which is a much easier thing to defend in a review.

What does this mean for a lender, or a Salesforce shop?

For a lender, picture an agent working a loan file. Deciding whether an uploaded document is a bank statement or a tax return, checking an extracted field looks like a real figure, deciding whether a file is ready for an underwriter: all classification and validation, all high volume, all cheap steps wearing expensive clothes. The actual judgement, whether this borrower and this property make sense together, is the one place the strong model earns its price. The connection layer underneath is the one we describe in MCP for lenders.

For a Salesforce shop, the shape repeats. Classifying an inbound case, routing it to the right queue, validating that an update matches your data model, and deciding whether an agent is allowed to write to a record at all are harness work. Drafting the reply a customer reads is not. That split is what we design for in Agentforce work, and it is usually the difference between an agent you can afford to leave running and one you switch on for demos.

What I would do this quarter

Four things, and none of them is a rewrite.

Instrument the loop first. Count the turns per completed task and label each by what it was doing. Most teams have never looked, and the answer is usually that most calls are trivial decisions.

Move guardrails out. Put a fast check in front of any action with consequences. You get the latency win immediately and the safety argument for free.

Pick one classification step and run the comparison. One step, a few hundred real inputs, measured against what you do today.

Build the seam, not the migration. Make the model a configuration choice per step rather than a constant. Then the next cheap fast model, whoever ships it, is a config change.

My title here is Chief Intern for Life, which mostly means I still get the questions nobody else wants and I make the coffee when the machine is free. So take this as a pattern I have watched hold up, not a law. If your loop is short and your volumes are small, ignore it cheerfully.

If you are building agents and the arithmetic has started to worry you, that is usually the right moment to talk. Codiot's AI agents team builds these loops for production rather than for demo day, and our AI development work covers the evaluation and data plumbing underneath them.