Last Updated on September 19, 2026
For years, progress in artificial intelligence has largely meant building models that can generate better answers, write better code, and reason through increasingly complex problems.
But AI systems are moving beyond answering questions.
Agents and copilots can now choose tools, retrieve knowledge, route work, evaluate results, and trigger workflows. That creates a different architectural question:
Does every AI decision actually need a generative response?
That question is central to Jev AI, the first public System One Model released by TypeSafe AI on September 15, 2026.
Instead of focusing on open-ended text generation, Jev is designed for machine-facing decisions such as:
- Classification
- Routing
- Scoring
- Verification
- Filtering
- Branching
- Escalation
TypeSafe describes Jev as a model that takes unstructured state and returns typed probabilistic decisions that software can use directly.
That distinction matters because many steps inside an AI workflow do not require a paragraph, explanation, or newly generated response. Sometimes the system only needs to determine what something is, which option applies, how strongly a condition is present, or what should happen next.
In TypeSafe’s published workflow evaluations, Jev achieved up to 193.6× faster execution and 444.6× lower cost than the LLM comparison setup. TypeSafe also cautions that those figures represent the higher end of the real-world gains it expects. (Source)
The broader agentic AI market is moving toward specialization as well. Gartner’s September 2026 analysis of 107 agentic AI deployments predicts that 80% of tangible agentic AI ROI will come from specialized, domain-specific agents by 2028, rather than broad general-purpose agents. (Source)
Jev does not replace generative AI models, reasoning systems, or AI agents. It introduces another intelligence primitive: a model optimized for the frequent, bounded judgments that sit between a request and an action.
To understand why that matters, it helps to look at Jev’s interface rather than simply comparing model sizes.
DECISION FOUNDATION
What Is Jev AI and What Is a System One Model?
Jev is TypeSafe AI’s first public System One Model, a class of AI models designed to make fast, structured decisions inside software.
A traditional large language model typically receives context and generates a sequence of tokens. That flexibility makes LLMs useful for tasks such as writing, coding, summarization, explanation, and open-ended reasoning.
Jev is optimized around a different interaction.
Instead of asking:
“Write an explanation of which department should handle this support ticket.”
software can ask:
“Which department should handle this support ticket?”
The possible outcomes are defined in advance, and Jev evaluates them probabilistically.
This makes the model particularly relevant when an application needs a selection, score, classification, judgment, or routing signal rather than newly generated content.
The difference is therefore not simply that Jev is a smaller or faster language model. TypeSafe has designed the model around a different interface between AI judgment and software control.
In practical terms:
Unstructured information → bounded AI judgment → probability-aware software action
That architecture becomes clearer when we look at the concepts TypeSafe calls state and typed questions.
INTERFACE MECHANICS
How Does Jev AI Work?
Jev evaluates one or more typed questions against a supplied state.
The state contains the information relevant to the decision. It might include a customer message, product details, policy information, transaction data, tool output, or other application context.
The application then defines the judgments it wants Jev to make.
TypeSafe currently exposes three primary decision primitives: Choice, Score, and Noul. Questions can be evaluated independently against the same state, including multiple questions within one request.
State: The Information Jev Evaluates
Think of state as the evidence available to the decision.
For a customer-support workflow, the state might contain:
- The customer’s message
- Account type
- Recent orders
- Previous support activity
- Relevant company policy
The model should not necessarily receive every piece of information the organization owns. TypeSafe recommends supplying the context needed for the current judgment and keeping deterministic calculations in code.
This distinction is important for systems that also use retrieval-augmented generation. Retrieval can identify the context relevant to a request, while a bounded decision model can judge or classify that context before another component generates an answer or performs an action.
Choice, Score and Noul: Jev’s Three Decision Primitives
Jev’s three primitives map different types of judgments to structured outputs.
| Primitive | What It Asks | Example | Typical Use |
|---|---|---|---|
| Choice | Which predefined option best applies? | Billing, technical support, account management | Classification, routing, selection |
| Score | Where does this state fall on an ordered rubric? | Calm → frustrated → very frustrated | Quality scoring, severity, prioritization |
| Noul | How likely is a statement to be true? | “Does this customer explicitly request a refund?” | Verification, gating, detection |
TypeSafe documents Choice as returning an option plus probabilities and confidence; Score returns an ordered evaluation with probabilities and confidence; Noul returns a value between 0 and 1 representing the modeled likelihood of the proposition.
Consider a support ticket:
State:
A customer says they were charged twice and asks when the duplicate payment will be returned.
The application could ask several independent questions:
- Choice: Which team should handle this request?
- Noul: Is the customer explicitly requesting a refund?
- Score: How frustrated does the customer appear?
Rather than forcing one prompt to make every judgment and generate an explanation, each decision can remain narrow and inspectable.
The surrounding application can then combine those outputs using business rules.
Why Atomic Questions Matter
This is one of the more important ideas behind System One workflows.
A broad question such as:
“Is this an urgent, high-value customer problem that should be escalated?”
contains several judgments.
A more inspectable workflow might ask separately:
- Is the issue urgent?
- Is the customer high value?
- Is account access blocked?
- Has the problem occurred previously?
- Does policy require escalation?
The application can then determine how those factors should be weighted.
TypeSafe explicitly recommends breaking broad judgments into narrow, atomic questions and composing their results in code.
That produces an architecture in which AI supplies judgment while software owns policy.
MODEL CONTRAST
Jev vs LLMs: Decision Intelligence vs Text Generation
Jev and generative LLMs solve overlapping but different kinds of problems.
| Dimension | Jev / System One Model | Generative LLM |
|---|---|---|
| Primary purpose | Structured judgment | Open-ended generation and reasoning |
| Output space | Defined before inference | Potentially unrestricted |
| Typical output | Choice, score, probability | Text, code, explanation, structured response |
| Sampling | Parallel decision outputs | Usually sequential token generation |
| Uncertainty | Probabilities; confidence for Choice/Score | Depends on model and implementation |
| Best fit | Classification, routing, scoring, verification | Writing, coding, synthesis, complex reasoning |
| Application role | Decision primitive inside software | General intelligence/generation component |
TypeSafe describes Jev’s sampling process as parallel rather than conventional token-by-token autoregressive generation and trains it with Reinforcement Learning for Calibrated Decisions (RLCD).
Is Jev Just a Smaller LLM?
No. The important distinction is not simply model size.
A smaller LLM is still generally designed to generate tokens. Jev is designed around predefined, typed decision spaces and probability-aware outputs.
That changes what the model is expected to do.
A generative model may be asked to:
“Analyze this request and explain the best response.”
Jev is better represented by questions such as:
“Which workflow applies?”
“How severe is this case?”
“Does this result satisfy the requirement?”
Those results can then determine whether the application calls an LLM, executes code, selects a tool, retrieves more information, or asks a person to review the case.
How Is Jev Different From JSON Mode or Structured Outputs?
Generative LLMs can also return JSON, schemas, enums, and other structured responses.
That makes format alone an insufficient distinction.
Structured-output modes generally constrain a generative model’s response into an expected schema. Jev, by contrast, is designed around bounded decisions themselves: the application defines the possible outcomes, the model evaluates those outcomes, and the result includes probability information that software can use as a control signal.
So the practical comparison is not:
Structured vs unstructured output
It is closer to:
Generation constrained into a structure vs intelligence trained around bounded probabilistic decisions
Both approaches can be useful. Which one fits depends on whether the application needs to create an answer or make a judgment among defined possibilities.
CALIBRATION CONTROLS
How RLCD, Probability and Confidence Make Jev Decisions Usable in Software
Jev uses Reinforcement Learning for Calibrated Decisions (RLCD), TypeSafe’s training approach for producing probability-aware decisions.
Calibration matters because software needs more than a label.
Suppose a classifier returns:
Billing
That result does not tell the application how uncertain the model was.
A probability distribution can communicate more:
- Billing: 0.82
- Account: 0.12
- Technical: 0.06
The software can now treat the decision differently from a result where Billing is only narrowly ahead of Account.
Probability vs Confidence
For Choice and Score questions, TypeSafe returns the underlying probability distribution and a separate confidence value derived from its shape.
A concentrated distribution means the model sees a clearer answer. A flatter distribution indicates greater uncertainty.
Noul works differently: its 0-to-1 value already expresses the modeled probability of the proposition and does not carry the same separate confidence field.
The distinction matters because probability describes the possible outcomes, while confidence helps the application decide how strongly it should trust the separation between them.
Type-Safe Does Not Mean Always Correct
Type safety solves one problem: whether software receives an output that conforms to the allowed structure.
It does not eliminate every model error.
Jev can still select the wrong valid option, misunderstand a condition, or perform poorly on a task that does not fit the model well. TypeSafe’s own documentation explicitly notes that calibration is measured across groups of predictions and does not guarantee that any individual answer is correct.
That distinction is essential:
Valid structure ≠ guaranteed semantic correctness
Production systems still need evaluation, thresholds, guardrails, and fallback behavior.
How Confidence Thresholds Control Automation
Confidence becomes useful when it changes what software does next.
A simple architecture could use three bands:
| Confidence State | System Behavior |
|---|---|
| High | Proceed automatically |
| Medium | Verify, gather more context, or ask for confirmation |
| Low | Do not act; route elsewhere or escalate |
The appropriate threshold should depend on the consequence of an error.
Showing the wrong help article is relatively recoverable. Approving a financial action is not.
TypeSafe therefore recommends changing confidence gates according to the risk of the downstream action rather than applying one threshold to every decision.
This is also a useful principle for teams investigating broader production AI project failure modes: model capability alone does not determine reliability. Architecture determines how uncertainty is handled.
SUITABILITY BOUNDARIES
What Is Jev Good At—and Where Does It Struggle?
Jev is most useful when the model is making a bounded semantic judgment.
Good candidates include:
| Strong Fit | Example |
|---|---|
| Classification | Which support category applies? |
| Routing | Which specialist should receive the task? |
| Scoring | How severe or relevant is this case? |
| Verification | Did the previous action satisfy the requirement? |
| Filtering | Is this retrieved passage relevant? |
| Guardrails | Does this request trigger a policy condition? |
| Branching | Which predefined workflow path should run next? |
But specialized models also have boundaries.
TypeSafe’s current Jev documentation identifies weaknesses around tasks including precise arithmetic, counting, date comparison, complex indirection, overly large states containing irrelevant information, adversarial content, and text generation.
The architectural response is not to force Jev to solve every problem.
| Poorer Fit | Better Approach |
|---|---|
| Exact arithmetic | Calculate in code |
| Counting | Use deterministic logic |
| Date ordering | Parse and compare programmatically |
| Multi-step open-ended reasoning | Use a reasoning-capable model |
| Writing an email or explanation | Use a generative model |
| Huge irrelevant context | Retrieve/filter first |
| Low-confidence judgment | Escalate or use another system |
This division of responsibility is useful beyond Jev.
Efficient AI systems increasingly depend on choosing the right component for each task instead of sending every request to the largest available model. That same principle is central to AI token cost optimization: cost should be evaluated across the complete workflow, not only as the price of an individual model call.
AGENTIC INTEGRATION
Why Jev Matters for AI Agents
An AI agent rarely completes a complex task in one step.
It may need to:
- Understand the user’s objective.
- Select relevant information.
- Choose a tool.
- Execute an action.
- Inspect the result.
- Determine whether the action worked.
- Retry, change strategy, or escalate.
This repeated loop is one reason AI agent architectures create so many decision points.
Anthropic describes routing as a workflow in which an input is classified and directed toward an appropriate downstream process. It also notes that simpler tasks can be routed differently from harder ones rather than forcing every request through the same execution path. (Source)
The same problem becomes more important as agents gain access to large tool libraries.
Through ecosystems such as the Model Context Protocol (MCP), agents can interact with external services, files, databases, development tools, and business applications. As the number of possible tools grows, correctly deciding which tool should be used, whether it should be used, and what should happen after it returns becomes a meaningful part of agent reliability.
Jev Is a Decision Component, Not an AI Agent
This distinction is important.
Jev does not independently plan an objective, choose an arbitrary next action, execute tools, and continue looping until a goal is complete.
TypeSafe’s own architecture guidance describes System One as a component for AI-powered software rather than an autonomous agent: code keeps control of workflow and side effects while the model handles narrow judgments over unstructured information.
That creates a useful separation:
Jev → judgment
Application or agent → control flow
Tool → action
LLM → generation or deeper reasoning where required
In other words, Jev can participate inside an agentic system without becoming the entire agent.
Where Jev Can Sit Inside an Agent Workflow
Consider an incoming customer request.
The system might use a decision layer to determine:
Request → classify intent → choose handler → execute → verify result → continue or escalate
Depending on the result, the handler might be:
- Deterministic application code
- A specialized AI agent
- A generative LLM
- A business workflow
- A retrieval system
- A human reviewer
This makes decision models potentially useful at several points:
Before execution:
Which tool, model, agent, or workflow should receive the request?
During execution:
Is the available information sufficient? Is this retrieved result relevant?
After execution:
Did the action succeed? Should the system retry, change strategy, or escalate?
For long-running systems, those decisions interact closely with agent memory and context management, because what an agent retains, retrieves, or exposes to the next decision can affect both accuracy and cost.
Jev’s significance for agents is therefore not that it replaces the intelligence doing complex work. It illustrates how an AI architecture can specialize the smaller judgments that determine what happens next.
PERFORMANCE PROFILE
Jev AI Pricing, Speed and Benchmark Claims
As of September 2026, TypeSafe publishes the following figures for Jev:
| Metric | TypeSafe-Published Figure |
|---|---|
| Input price | $0.042 per million input tokens |
| Output pricing | No metered output-token charge |
| Reported response time | Approximately 70–500 ms |
| Workflow evaluation peak | Up to 193.6× faster |
| Workflow cost comparison peak | Up to 444.6× cheaper |
| Availability at launch | Early access |
These figures come from TypeSafe and should be interpreted in that context. The company says the 193.6× speed and 444.6× cost comparisons come from its workflow evaluations and are likely toward the higher end of real-world gains. It also discloses methodological considerations around its evaluations.
The more durable takeaway is architectural rather than numerical:
A bounded decision may not require the same inference process as an open-ended generative task.
As models become more specialized, system designers can increasingly decide not only which model is best, but whether the step needs generation at all.
ORCHESTRATION STACK
How Knolli Uses AI Agent Routing and Orchestration
This is where the Jev discussion becomes particularly relevant to business copilots.
Jev operates at the model layer, producing structured judgments.
Knolli operates at the application and orchestration layer, where a user’s request can be understood and connected with the AI capabilities, knowledge, agents, and workflows required to move that request toward an outcome.
The underlying problem is broader than answering a prompt.
A business copilot may need to determine:
- What does the user actually want?
- Which knowledge source is relevant?
- Which specialist should handle the request?
- Does the task need a generative model?
- Should a workflow be triggered?
- Is the result sufficient?
- What should happen next?
Knolli uses LLM-based classification and routing logic to help make those application-level decisions across configured execution paths.
Classify Intent Before Routing the Task
Different requests should not automatically receive the same treatment.
Consider a sales copilot. It may receive requests involving:
- Product information
- Competitor research
- Lead qualification
- Account context
- Follow-up assistance
- Internal sales guidance
Classification gives the orchestration layer a semantic understanding of the request before deciding what capability should handle it.
This matters because routing is only useful when the system understands what it is routing and why.
Route Work Across Models and Specialized Agents
Once intent is understood, configured routing logic can determine which execution path is appropriate.
Different tasks may require different capabilities.
A factual lookup may need a knowledge source.
A complex analysis may need a capable reasoning model.
A narrowly defined domain task may be better handled by a specialized agent.
A deterministic action may need a workflow or integration rather than another generated response.
This produces a more modular architecture than sending every request through one fixed AI path.
Apply Business Knowledge Before Acting
Routing is also connected to context.
Business copilots often need organization-specific information before they can answer or act appropriately. That may include policies, product documentation, customer information, operational procedures, or other proprietary knowledge.
A useful orchestration path therefore looks less like:
Prompt → LLM → response
and more like:
Understand intent → select expertise → apply relevant knowledge → execute the appropriate workflow
That separation helps preserve business context while allowing different forms of intelligence to specialize.
Orchestrate the Task From Request to Outcome
Routing determines where work should go.
Orchestration determines how the pieces work together.
A request might require several connected steps:
User request → intent classification → specialist selection → knowledge retrieval → action → verification → next step
This is why AI orchestration is becoming a distinct architectural concern.
The objective is not simply to generate a good answer. It is to coordinate models, agents, knowledge, integrations, and workflow logic so the system can move from an ambiguous human request toward a useful business outcome.
That is also where Jev and Knolli occupy different levels of the stack.
| Layer | Primary Responsibility |
|---|---|
| Jev / decision model | Make bounded machine-facing judgments |
| Generative or reasoning model | Create, analyze, explain, or reason |
| Specialized agent | Pursue a domain-specific task |
| Knowledge layer | Supply relevant business context |
| Tool / integration | Perform an external action |
| Knolli orchestration layer | Coordinate the configured components and execution path |
Jev therefore should not be viewed as a Knolli alternative.
It represents a model-level approach to specialized decision intelligence. Knolli addresses the application-level problem of connecting user intent with the broader system that can actually complete the job.
WORKFLOW ACTIVATION
Ready to Build an AI Copilot Around Your Business Knowledge?
Turn your documents, expertise, and business knowledge into a copilot that can answer questions, support users, and help streamline repetitive work across functions such as sales, support, marketing, HR, finance, and operations.
Explore Knolli’s AI copilot platform to see how business knowledge can become an interactive AI experience.
BUSINESS OUTCOME
From Better AI Answers to Better AI Decisions
The significance of Jev is larger than one newly released model.
It highlights a change in how AI systems can be designed.
The first wave of generative AI focused heavily on one question:
How capable is the model generating the response?
Agentic systems introduce several additional questions:
Should this request be generated at all?
Which component should handle it?
How certain is the system about that choice?
What should happen when uncertainty is high?
Which decisions belong to AI, and which belong to deterministic code?
Jev’s answer is to specialize bounded machine-facing judgment.
Generative models remain valuable for open-ended reasoning and creation.
Agents coordinate multi-step work.
Code provides deterministic control.
Orchestration layers connect those components with knowledge and business processes.
The resulting architecture is not one model doing everything.
It is a system in which different forms of intelligence handle the tasks they are best suited to perform.
And for business AI, that may be the more important shift: moving from systems that simply know how to respond toward systems that can determine what should happen next.
READER QUESTIONS
FAQs About Jev AI and Decision Models
Is Jev AI an LLM?
TypeSafe describes Jev as a System One Model, not a conventional generative LLM. Like an LLM, it can interpret natural-language information, but its interface is designed around typed decisions and probabilities rather than open-ended text generation.
Is Jev just a smaller LLM?
No. The primary distinction is not model size. Jev is designed for bounded decision tasks with predefined answer spaces, parallel decision outputs, and probability-aware results. Conventional generative LLMs are designed to produce sequences of tokens for tasks such as writing, coding, explanation, and open-ended reasoning.
What are Choice, Score and Noul in Jev?
Choice selects among predefined alternatives. Score evaluates a state against an ordered rubric. Noul returns a 0-to-1 value representing the modeled likelihood that a proposition is true. These primitives allow software to ask different types of structured questions about the same state.
How is Jev different from JSON mode or structured LLM outputs?
JSON mode and structured-output features constrain the format returned by a generative model. Jev is designed around the decision itself: the answer space is bounded in advance, and the model returns probabilities that software can use for branching, thresholds, routing, or escalation.
Can Jev still make the wrong decision?
Yes. Type safety means the response conforms to the expected structure; it does not guarantee that every selected answer is semantically correct. TypeSafe documents known Jev failure modes and recommends evaluation, narrow questions, relevant context, confidence gating, and deterministic code where appropriate.
What happens when Jev has low confidence?
The application decides. A low-confidence result can be routed to human review, sent to another model, given additional context, or stopped before an action occurs. TypeSafe recommends matching confidence thresholds to the consequences of the downstream action.
When should developers use a decision model instead of a generative LLM?
Use a decision-focused model when the system needs to select, classify, score, verify, or judge among defined outcomes. Use a generative model when the task requires newly created text, code, explanations, synthesis, or deeper open-ended reasoning.
Can Jev work alongside generative AI models?
Yes. A decision model can determine which path a request should follow, while a generative model handles the open-ended work on that path. For example, Jev could classify a support request and assess uncertainty before an LLM generates a detailed response.
Does Jev replace AI agents?
No. Jev provides bounded judgments rather than autonomous goal-directed execution. An agent or application can call Jev at points such as routing, verification, filtering, scoring, tool selection, or escalation while retaining control over the larger workflow.
How is Knolli different from Jev AI?
Jev operates primarily at the model layer, where it produces structured machine-facing decisions. Knolli operates at the application and orchestration layer, where user intent can be connected with configured models, specialized agents, business knowledge, integrations, and workflows.
