Jev Agent Architecture: Where TypeSafe's Decision Model Fits in an AI Agent

What Jev is: a decision model, not a chatbot

Jev is the first model from TypeSafe AI, released in early access in mid-September 2026 (September 15, 2026). TypeSafe calls it a System One model: it reads natural-language input like an LLM, but it never writes text. You send it a state (a string, JSON object, or array of text) plus a map of typed questions, and it returns one typed answer per question with a probability attached.

That single design choice is what makes Jev interesting for agent builders. A large share of what an agent does on every loop is not writing at all. It is deciding: which tool, which handler, is this document relevant, should I retry, does this need a human. Today most agents send each of those decisions through a general-purpose LLM, pay for the tokens, wait for generation, then parse prose back into a value. Jev removes the generation and the parsing. It can only return one of the options you declared, so a tool-selection step can't invent a tool that doesn't exist. It can still pick the wrong one, and that difference matters for the rest of this article.

Jev vs an LLM inside an agent

The two are not competitors inside a well-built agent. They do different jobs. This is how they compare on the decision-shaped steps where you would consider swapping one for the other:

The practical reading: Jev replaces the LLM calls that were only ever answering a closed question. It does not replace the LLM calls that produce language or reasoning a user will read.

The Jev agent architecture: code controls, Jev decides, the LLM writes

Here is the part most coverage of Jev skips. TypeSafe's own guide, How to build with TypeSafe, states plainly that System One is for building AI-powered software, not agents. It does not choose its own next action. The docs contrast three architectures: traditional software (a decision tree of reliable primitives), LLM agents (a model chooses each next step, and every loop is another chance to go off the rails), and AI-powered software, where code owns the control flow and the model appears only where the system needs judgment over unstructured data.

So a "Jev agent" is not an agent where Jev is the brain. It is an agent whose loop has been pulled back into code, with Jev sitting at the decision points and an LLM kept for the steps that genuinely need language. Three layers:

1. Code controls. The loop, state, deterministic rules, permissions, and every side effect (API calls, database writes, payments) live in code. Anything code can compute exactly stays in code: dates, counts, thresholds, whether a tool is destructive.
2. Jev decides. At each fork where the answer is one of a known set (route this request, pick this tool, is the evidence sufficient, should this step retry, does this need approval), code sends a narrow state and a batch of atomic questions to Jev and branches on the typed result.
3. The LLM writes and reasons. Customer replies, summaries, generated arguments that can't be enumerated, and genuinely open-ended investigation go to a text model. It is also the escalation target when Jev is unsure.

The shift in cost profile comes from where the calls go. In a classic ReAct-style loop, every iteration is an LLM call. In the Jev architecture, most iterations are a code branch plus one fast Jev request, and the LLM is invoked only at the edges: to write the final answer, to fill free-form arguments, or to handle the low-confidence cases Jev routes to it.

Decision points worth moving to Jev

• Tool or handler selection from a declared list, including a list built dynamically from an MCP server's tool descriptions.
• Relevance filtering of retrieved chunks before they enter an LLM's context window.
• Stop, retry, or escalate after a tool result comes back.
• Trace verification: TypeSafe's guide includes an example that checks an LLM's tool-call trace with separate questions (right tool? arguments match the schema? date and unit match the request?) instead of one broad "is this correct?"
• Input and output screening such as credential requests, off-topic requests, or policy violations, each as its own true/false question.

Choice, Score, Noul: mapping agent decisions to Jev primitives

Jev answers three question types. Designing a Jev-backed agent is mostly the work of turning each decision into one of them:

The rule TypeSafe calls the most important concept in its guide is decomposition: ask narrow, atomic questions rather than one broad one. "Is this spam?" hides several judgments behind one number. "Does the body request a password?", "Does the sender's display name conflict with the email domain?", "Does it create time pressure?" each expose one judgment you can inspect, tune, and weight in code. Because questions over the same state run in parallel, decomposing does not add round trips.

Two design consequences that are easy to miss:

• Questions in one request can't see each other's answers. They are evaluated independently. If question B genuinely depends on the answer to A, that is two requests with code in between, not one.
• Extraction becomes selection. Jev can't name a value it wasn't offered. When your instinct is "extract the order ID", find the candidates with a regex or a text model first, then ask Jev which candidate is the right one.

A Jev decision step in Python

Below is one iteration of a support agent for an online store, written the Jev way. Deterministic facts (the ticket is closed, a tool is destructive) are settled in code. Jev answers four atomic questions in one request. The LLM is called only to write the reply or when Jev isn't confident. Class and field names follow TypeSafe's Python SDK as shown in its docs.

from typesafe_sdk import Choice, Noul, TypeSafeClient

TOOLS = {
    'get_order_status': {'what': 'Where an order is, delivery dates, tracking', 'destructive': False},
    'start_return':     {'what': 'Customer wants to send an item back',        'destructive': False},
    'issue_refund':     {'what': 'Customer asks for money back',               'destructive': True},
    'escalate_human':   {'what': 'Legal threats, abuse, or anything else',     'destructive': False},
}

def agent_step(ticket, open_orders):
    # 1. Code decides what code can decide.
    if ticket['status'] == 'closed':
        return 'no_action'

    # 2. Send only the context these questions need.
    state = {'message': ticket['message'], 'open_orders': open_orders}

    questions = {
        'tool': Choice(
            instructions='Which tool should handle `message`?',
            criteria={name: t['what'] for name, t in TOOLS.items()},
        ),
        'names_open_order': Noul(
            instructions='Does `message` refer to one of `open_orders` by id or details?',
        ),
        'asks_for_credentials': Noul(
            instructions='Does `message` ask us to reveal a password, code, or API key?',
        ),
        'in_scope': Noul(
            instructions='Is `message` about an order, return, or refund with this store?',
        ),
    }

    with TypeSafeClient() as client:
        a = client.system_one(state=state, questions=questions).answers

    # 3. Code composes the answers and gates on confidence.
    if a['asks_for_credentials'].noul >= 0.5 or a['in_scope'].noul < 0.3:
        return escalate(ticket)
    if a['tool'].confidence < 0.8:
        return ask_llm_to_plan(ticket)          # reasoning model handles the hard case

    tool = a['tool'].choice
    if TOOLS[tool]['destructive']:
        return queue_for_approval(ticket, tool)  # irreversibility is a code rule, not a model guess

    result = run_tool(tool, ticket, needs_order_id=a['names_open_order'].noul < 0.7)
    return llm_write_reply(ticket, result)       # the only place language is generated

Notice what is not asked of Jev. Whether issue_refund is destructive is a static property of the tool, so it lives in the TOOLS table, not in a Noul. The 0.8 and 0.5 thresholds are placeholders: set yours by running labeled examples and plotting confidence against accuracy, which is the method TypeSafe's docs recommend.

Routing on confidence instead of trusting the answer

A structurally valid answer is not a correct answer. What Jev adds over a structured-output LLM call is a calibrated probability on every answer, trained with a method TypeSafe calls Reinforcement Learning for Calibrated Decisions (RLCD). Calibration is measured across groups of predictions. It does not promise that any single answer is right. It means that across many answers reported at 0.9, roughly nine in ten should be correct, which is exactly what you need to set thresholds.

In an agent this gives you a three-way branch at every decision instead of a binary one:

• High confidence: act automatically.
• Middle band: escalate to a reasoning LLM with the full context, or ask the user a clarifying question.
• Low confidence or high stakes: route to a person.

Match the threshold to the cost of being wrong, not to a global number. Picking the wrong FAQ article can run at a lower bar than approving a refund. For irreversible actions, treat Jev as one input to the gate alongside hard code rules, never the only lock.

If this is the part of your stack you'd rather not build alone, our AI automation and agent workflow service covers exactly this kind of decision-layer design: which steps stay in code, which move to a decision model, and where the LLM still earns its cost.

What Jev costs per agent decision

Per TypeSafe's Models page, the current model is jev-1.13.0, billed on input tokens only. Output is free, which fits a model that returns a handful of typed values.

Worked example: an agent making one million routing decisions a month, each with about 2,000 input tokens of state and questions, uses 2 billion input tokens. At $42 per billion, that is $84 a month for the decision layer. Put the same volume through your current LLM's input and output pricing to see the gap for your own workload. The caveat is TypeSafe's, not ours: pricing and the speed claims come from the vendor during early access, and the company has said it can't yet prove the price is sustainable.

Pin the version if you tune thresholds

jev-latest moves when a new release ships, so the answers behind it can change without any change on your side. The response's model field reports the versioned ID that answered. Log it, and if you have tuned confidence thresholds, send jev-1.13.0 explicitly and upgrade on your own schedule after re-running your labeled set.

Where Jev breaks: the documented weak spots

TypeSafe publishes a "jaggedness" page listing what jev-1.13 does badly. Read as an agent designer, every item points to the same fix: do more in code, ask Jev less per question.

One more limit matters for anyone serving non-English users: TypeSafe says English is Jev's primary training language and other languages, CJK included, are handled but not equally well. If your tickets, listings, or chats are in Vietnamese, Thai, or another language, build a labeled test set in that language and check calibration before routing real traffic on Jev's confidence.

When to keep Jev out of your agent

• The answer space is open. If you can't list the options, it's a generation task.
• Code can answer it exactly. Schema checks, date math, permission checks, and counts are cheaper and fully reliable in code. Jev adds nothing but risk there.
• The step needs real reasoning. Debugging an outage, comparing architectures, or planning a multi-step task belongs to a reasoning model. Jev is fast judgment, not deliberation.
• Your volume is tiny. If an agent makes a few hundred decisions a day, the savings may not justify another vendor, another API key, and another model to monitor. The case for Jev grows with decision volume and latency sensitivity.
• You need non-text input. Jev 1.13 takes text only. Images, audio, and video must be turned into text or structured fields first.

How to start moving an existing agent onto Jev

1. Log your agent's LLM calls for a week and tag each one: does it produce language for a human, or does it answer a closed question?
2. Pick the highest-volume closed question, usually tool selection or routing, and rewrite it as one Choice plus a few supporting Nouls.
3. Build a labeled set of a few hundred real inputs and run Jev in shadow mode alongside the LLM. Compare accuracy and plot confidence against correctness.
4. Set per-action thresholds, pin jev-1.13.0, and switch the step over with an LLM fallback for the low-confidence band.
5. Repeat for the next decision point. The LLM calls left over are the ones that were always its job.

Not sure which of your agent's steps are decisions and which need a real LLM? Book a free consultation with Netalith and we'll map your agent's loop with you, no cost and no commitment.