JEV AI Model Explained | System One AI, How It Works & Real-World Application | Will it replace LLM?

Author: At A Glance! · Watch on YouTube

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: JEV AI Model Explained | System One AI, How It Works & Real-World Application | Will it replace LLM? · Channel: At A Glance! · 17:16 · Watch on YouTube

Topics: AI agents, AI evaluation and benchmarks, AI models, RAG, search and information retrieval

Summary

The video explains JEV as a system designed to return structured, probability-backed decisions—such as classifications, choices, and scores—rather than open-ended text. It outlines how an application supplies a state and a typed question, then uses JEV’s decision in code to route requests, filter information, or control an agent workflow. The presentation discusses potential uses, speed and pricing claims, evaluation results, and limitations, while emphasizing that performance claims are context-dependent and probabilities do not guarantee correctness. Its central message is that JEV is a complement to LLMs: LLMs generate language and reason, JEV makes bounded decisions, and code enforces rules and executes actions.

Key points

JEV is intended for fast, structured software decisions rather than ordinary conversation or free-form language generation.
Its workflow takes an application state and a typed question, returns a decision, and leaves execution to application code.
The three decision primitives described are null (yes/no), choice (select from defined alternatives), and score (evaluate on an ordered scale).
The video presents applications including routing, urgency scoring, escalation, tool selection, guardrails, and checking whether retrieved text supports a question.
Unlike JSON mode, JEV uses a predefined answer space, which can constrain outputs to permitted options.
The video reports latency, pricing, and evaluation figures, but notes that these are claims or results tied to particular evaluations and are not universal guarantees.
JEV may make mistakes; probabilities are not guarantees of correctness or safety, and high-risk decisions may require human review.
The presentation says JEV is not an LLM replacement: LLMs generate and reason, JEV makes decisions, and code executes actions and enforces rules.

Chapters

Start	Chapter	Summary
00:02	What JEV does and why use structured decisions	The video introduces JEV as a way to produce typed, probability-backed decisions instead of generating text that an application must parse.
03:09	Workflow and decision primitives	It explains how state, typed questions, and application code fit together, then introduces yes/no, choice, and score decisions.
05:48	Speed, agents, and retrieval workflows	The presentation describes latency claims and shows JEV evaluating tool choices and retrieved information within application workflows.
09:26	JSON mode, evaluation, and cost claims	It compares JEV with JSON mode and reviews reported evaluation, pricing, latency, and workflow performance figures.
12:35	Where JEV fits and its limitations	The video distinguishes suitable decision tasks from generative tasks and cautions that JEV can err, its probabilities need care, and human review may be needed.
15:09	Combining LLMs, JEV, and code	The closing section presents a combined workflow in which LLMs generate or reason, JEV decides, and code executes and enforces.

Quotes

Jeff is specifically designed for fast structured probability backed software decisions rather than ordinary conversations. — 01:06

These primitives represent three different questions. Is it true? Which option? How much or how strongly? — 05:17

A probability of 0.90 does not automatically mean an action is safe. — 14:08

JE is not necessarily an LLM replacement. It is different interface for intelligence. — 15:41

LLM generates strings, Jeff generates decisions and production AI combines them. — 16:11

Concepts and entities

Jev, System One AI, LLM, null, choice e score, RAG, JSON mode, TypeSafe AI

Full transcript (original language)

00:02 [music] Hey everyone, welcome back to my YouTube channel. In this particular video, we’ll be looking into the Jeff model. So, let’s begin by understanding what Jeff does. This particular slide compares a typical question we might ask an LLM. What should I do with the ticket? You can see this question. What should I do with this ticket? with the kind of direct decision Jeff can produce.

00:33 Instead of generating a free form explanation like how an LLM does, Jeff can return a structured results. For example, you can see the result is route which is billing and it has also given a probability of 0 91. This means the selected route is billing with a probability of 91. The workflow shown here is state. It goes to the Jeff model. Then it gives a typed decision and then the code does

01:06 the action. In simple words, the application provides information. Jeff answers a defined question and the code uses that answer to take the action. This is the central idea of Jeff. Jeff is specifically designed for fast structured probability backed software decisions rather than ordinary conversations. I hope you have got an overview of what exactly Jev is. Look at this problem illustrated on this slide. In many

01:37 applications, we provide information to an LLM receive generated text. We parse that text, validate it, and then execute the required action. For a simple decision, this can introduce unnecessary steps. The output might have formatting problems. It might require retries or produce uncertainty that is difficult for application to handle consistently. For example, if the application only needs to select a route, generating a full text response and then extracting the route can be more work than

02:09 necessary. An if statement is a programming construct that executes a particular action when a condition is satisfied. The slides argument is that some AI workflows use a large language model for decisions that could be handled more directly. This particular slide compares two approaches. Chat first LLMs and system one models such as Jeff. A chat first LLM focuses on generating language. Its output is typically produced through a sequential

02:39 token generation. Jeff, by contrast, it’s designed to return decision- oriented outputs such as predefined choices, scores, and probabilities. This comparison also highlights the difference between flexible text and typed values that software can consume, as well as between confidence expressed through a prompt and probabilities returned as part of the decision. For example, one approach might explain a complaint while the other selects a Q.

03:09 The key takeaway is that these models have different design priorities. Jeff is intended to handle defined decisions while an LLM remains useful for flexible language generation. I hope you’re understanding this system one approach. Now let’s have a look at the entire workflow of Jeff. First, we provide a state. Now this could be a ticket, a retrieved text chunk, a document, a JSON data, or the current state of an AI agent. Next, we define the typed question. Jeff evaluates that question

03:42 against the provided state and returns the structured decision. Finally, the application code uses this result to route the request, filter information, continue a workflow, or send a case for review. Notice that Jeff is not shown executing the entire application by itself. It supplies the decision while the code determines what action follows. The separation is important because it allows the model’s decision-m role to remain distinct from the application’s execution logic. For example, you can see the state customer was charged twice

04:13 and wants a refund. Now, Jev here can identify exactly which queue it should go to, how urgent it is, and whether human escalation is required or not. So for decision-m things this is how Jeff works. I hope you are understanding this. Now let’s have a look at the three decision primitives of Jeff and those are null, choice and score. Now first is null. N answers a yes or no question. For example, is this true? The output

04:45 will be either yes or no. Let’s say if it is yes, then it will return yes as well as the probability of how much possibly the answer is correct. which is 94. Second is choice. Out of the given options, which one is more likely to be correct? So, choice selects among the predefined alternatives. In the routing example, billing has a probability of.82. Technical has the probability of.13 and sales has a probability of 05. So, you can see this is how it gives the probability of all the defined options.

05:17 The third is score. Score evaluates something on an ordered scale. Here urgency is represented by a score 8.2 out of 10 along with the confidence information. So these are the three decision primitives which are used in Jeff. Let’s take an example. The customer message brings three ideas together. A customer sees they were charged twice and then need their money back today. The system can choose the appropriate route,

05:48 access, assess the urgency and evaluate whether the escalation is needed or not. These primitives represent three different questions. Is it true? Which option? How much or how strongly? I hope you have understood all the three different primitives which are used in Jeff. Why Jeff is fast? Now, as we know a conventional LLM generally generates the output tokens sequentially one by one. Jeff is designed to produce its decision outputs without the same free form output token decoding process. The

06:19 presentation reports an end toend latency of 70 to 500 milliseconds. Latency means the time taken to return a result. The example illustrates a structured decision containing information such as the selected route and urgency rather than a long explanation. This can be beneficial when an application needs to make frequent decisions and act on them immediately. However, the reported latency should be understood in the context of the tested workload and infrastructure. It is not a guarantee for every application. I hope

06:51 you have understood this. I hope now you know why it can be so fast. Let’s follow the agent workflow which is shown on the left. A user submits a request. The LLM plans what to do and Jeff checks a decision before the workflow proceeds. The application then determines whether to use a tool, continue, or take another permitted action. After the chosen tool gets executed, Jeff can evaluate the result and the LLM can prepare the

07:21 response for the user. This example shows the LLM proposing refund tool. Jeff evaluates whether the tool is appropriate while the code performs the execution. The right side list possible Jeff uses tool selection routing guide rails relevant scoring escalation and workflow branching. A guardrail is a control that helps prevent unsuitable actions. The important distinction is that Jeff can support the decision while the application must still enforce permission and execution rules. For example, if we use LLM, it will say I

07:53 should call the refund tool. But if we use Jeff, it will say that is refund tool appropriate with a probability also. And accordingly, the code executes the tool. I hope you have understood how Jeff can be used inside an AI agent and how it can be better rather than using an LLM for tool calling or execution. Now let’s take a real example. This particular slide demonstrates how Jeff can act as a decision gate in a rack pipeline. Now here you can see the process starts with a user query. A

08:24 retriever searches for relevant information and returns the retrieved chunks as what happens in a rag. Jeff then evaluates whether the retrieved chunk supports the user question. So this acts as a decision gate. The example chunk says the policy allows refund within 30 days. The question is whether this chunk supports the user’s refund question. The slide illustrates the result as yes with a probability of 93. Now depending

08:55 on the result, the workflow can generate an answer, retrieve information again or ask the user for clarification. By the way, I hope you know what drag is. It is retrieval augmented generation. Retrieving relevant information to support an AI generated response. The reason Jeff fits here is that relevance checking is a bounded decision. the system can use its probability to help control the workflow rather than treating every single retrieve chunk as automatically useful. So I hope this example might have clear how Jeff can be useful in day-to-day use

09:26 cases of generative AI. Now what makes Jeff different from JSON mode? See if you don’t know JSON mode asks a language model to produce structured text. The example contains a root and a confidence value. As you can see root is billing confidence value is.91. Even when the output looks like a valid JSON the application may still need to check the schema validate the values or retry if the output is unsuitable. Jeff

09:56 instead uses a typed question with an answer space defined beforehand. For example, let’s say the permitted roots are billing, technical and sales. Here Jeff cannot generate a fourth root such as customer success. This is the main ideology behind using Jeff and how it is different from JSON mode. JSON mode if we use it behind the scenes we are using LM only and LLM can anytime generate some vague results and might uh generate some invalid JSON. So all those issues gets rid of when we use Jeff. So I hope

10:27 you have understood the difference between the JSON mode also and Jeff. This particular slide presents results from an independent evaluation of Jeff identified in the presentation as a September 2026 archive study. It covers 13 data sets and 3 lakh 46,09 request. The displayed zeroot accuracy figures are 95% on arc, 96% on heliswag, 97%age on SST2 and 97%age on IMDb. For

11:00 bleel the presentation reports 86.7 percentage of accuracy across 122 languages. This slide also reports the Jeff beat Quen 3.8 27 billion parameter model on 27 of the 37 data sets and GMA 4 E4 billion parameter model on 37 of all 37 data sets in that on all 37 data sets in that evaluation. Zeroshot means the model is evaluated without task specific examples in the prompt. These

11:31 results cover different tasks including classification, routing, reading, comprehension, moderation, and rubric scoring. We are encouraging results from the reported evaluation, but they should not be treated as a universal ranking of AI models. Now, let’s talk about the speed and cost. This particular slide represents TypeSafe AI’s published pricing and performance claims. The displayed price is 0.042 per million input tokens with output tokens listed as free. The reported end

12:03 to end latency is 70 to 500 milliseconds. There is also a claim of 193.6 times faster and 446.6 times cheaper than a vendor workflow evaluation. Now why does this matter? Consider a routing decision repeated millions of times. Even a small difference in response time or cost can become important at that scale. However, the slide explicitly qualifies these multipliers as results from the type C’s own workflow evaluations. They are not universal benchmark results.

12:35 When evaluating a model for production, we should compare the same workload, measure end to end latency, and calculate the actual cost of the complete application where Jeff fits and where it doesn’t. You can see on this displayed slide on the left side we have the good fit and on the right side we have not as the primary tool for. So basically you can use Jeff in classification, routing, scoring, guardrails, tool selection, triarch, verification, real-time decision gates on all these components you can simply put Jeff. But when it

13:06 comes to the sides where you have to write long form text, open-ended conversations you have to handle or you have to look for the creative generation, long explanations, exact arithmetic, unconstrained reasoning task. For all this, Jeff is not the correct tool that you have to use. The diagram at the bottom combines three components. The LLM, the LLM generates and reasons. The Jeff decides and gates and code handles deterministic logic. This means we don’t need to choose only one model for the entire application. For example, an LLM

13:38 can generate a response. Jeff can select a category and code can enforce the business rules. The goal is to use each of these components for the task it is designed to perform. I hope you’re understanding. Now let’s also have a look at the limitations that you should know while using Jeff. Of course, Jeff is not error-free AI. No AI is error-free. You should know where it goes wrong or where it can go wrong. See, first Jeff can make incorrect decisions for sure. Yes, wrong decisions are possible. Your probability whatever you are getting,

14:08 it’s not guaranteed. Second, its probabilities needs to be interpreted carefully. A probability of 0.90 does not automatically mean an action is safe. Third, poorly designed questions or answers pieces can lead to poor decisions. This you have to keep in mind. Fourth, performance can also vary by task particularly for low resource languages, noisy inputs and rubric based evaluation. Also, you need to remember that Jev is a closed model delivered

14:38 through a managed API with weights that are not public and that its public evidence and ecosystem are still in development. Look at the payment example. Even if Jeb outputs approved payment with a 97% probability, that does not authorize the payment automatically. Here comes the distinction between a high confidence automated path and a low confidence or high-risk path that requires human review. Hope you understand this. This particular slide contrast two

15:09 approaches. The first is to ask one AI model to do everything. The second is to use the right primitive for each step. The diagram here shows the workflow. User LLM, Jeff, code, and tools. Remember the LLM reasons or generates. The Jeff classifies scores or decides the code, executes it, and enforces. The tools perform the required operation. We can see how these responsibilities can work together. The LLM plans. Jeff chooses a tool. Code executes it. Jeff verifies the results. And LLM explains

15:41 the outcome. Notice that the workflow can involve multiple stages rather than a single decision. The central message is that JE is not necessarily an LLM replacement. It is different interface for intelligence. Remember this, it’s not a replacement for LLM. Let’s bring all together the entire presentation that we have seen so far. You can see this particular diagram. It shows how a state it shows the state question Jeff and code begin with the information available. define the

16:11 decision we need to receive a probability backed answer which Jeff gives and let the application determine what happens next. LLM generates strings, Jeff generates decisions and production AI combines them. The final example shows a customer message leading to a billing decision with.91 probability and urgency of the result is87 and a human review result of 76. The code then chooses the next step. These numbers illustrate how multiple decisions can feed into a workflow. They should not be interpreted as a guarantee

16:43 of correctness. So the overall lesson is simple. Jeff provides structured probabilistic decisions that softwares can use while LLM remains valuable for reasoning and language generation. Thank you. This brings us to the end of the introduction to Jeff. I hope you have understood every single slide and every single concept involved in this. Like this particular video, please do like, share and subscribe to my channel. Also hit the bell icon and don’t forget to follow me on Instagram. Please join me on Telegram. Thanks for watching. Have a good day ahead.

17:16 [music] >> [music]