Jev Agent Builder: set up a typed decision without writing JSON
We are publishing a free visual editor for Jev, TypeSafe AI's decision model. It does one thing: take you from a business decision ("which reason?", "how urgent?", "is this a credit request?") to an API call you can test, without writing the JSON by hand.
· 8 min read
This article is for technical leads and developers in SMEs who want to test a decision model on a real flow, and for operations leads who want to understand what their team is about to test. It is not for anyone looking for a chat assistant: Jev does not chat.
Jev is TypeSafe AI's first "System One" model, announced on September 15, 2026. It does not generate text. You send it a state (an email, a ticket, a JSON object) and typed questions, and it returns a typed value and a probability distribution. No answer to parse back, no category invented outside the list.
When we tested it on our own classification cases, the bottleneck was not the model. It was writing the request: one JSON object per question, options with their descriptions, score levels, parameters to substitute, and a syntax error on every attempt. Jev Agent Builder removes that step. The code is on GitHub, under the MIT license.
A word on vocabulary, to stay consistent with our article on agents. TypeSafe calls a reusable set of questions an "agent". In the sense we used there, it is not one: Jev does not choose its steps and does not act in any tool. It is a decision step, to be placed inside a scenario whose path is written down. That is exactly what makes it interesting.
What Jev does, and what it does not
Three question types, according to TypeSafe's documentation. Choice picks one option from a list you supply, up to 255, and returns the option, the probability of each one, and a confidence. Score places the state on a scale of 2 to 10 levels that you describe, and the position can fall between two levels. Noul answers a statement with a probability between 0 and 1: near 1, a clear yes; near 0, a clear no; around 0.5, the model does not know.
Questions in the same call are evaluated in parallel and in isolation, against the same state. One question does not influence another's answer. TypeSafe therefore recommends atomic questions: a complex judgment is split into several simple questions, and your code combines them.
What changes for an SME is the probability. A chat model answers with the same assurance whether it is right or not. A decision that comes with a calibrated probability lets you write an honest rule: above a threshold, the scenario continues; below it, the request goes to a person. This is the "fast, calibrated decision" layer described on our engineering page.
What it does not do. It does not write a reply to the customer, summarize a document, or explain its decision in sentences. It knows nothing about your data beyond the state you pass it. And it does not fix a badly defined option list: if your reasons overlap, its probabilities will split between them, which is honest but unusable.
What the builder does
A form on the left, the request on the right. You name the agent, pick the model (jev-latest for the latest stable version, or a versioned id to freeze behaviour), write the state, then add your questions. The JSON for POST /v1/systemone updates on every keystroke, with an estimate of tokens and cost per 1,000 calls.
Parameters do the rest. Write {{ticket}} in the state, {{reasons}} as the option source of a Choice, and the same agent works for every ticket and for a list of reasons that changes over time. The "Agent (template)" tab exports that definition with its parameters intact, to version alongside your code. The "Request" tab shows the resolved version, with test values.
Validation follows the documentation: duplicate id, parameter used but never defined, parameter defined but unused, a Choice with a single option (Jev will always pick it), a Score level that is only a number, going over 64,000 tokens per request or 32,000 per question. One checkbox adds the none_of_the_above option, so Jev can say that nothing fits.
To leave the browser: the raw request, the reusable definition, a cURL command, or a TypeScript function that fills the parameters and calls the API. One button opens the request in TypeSafe's Playground, to test on the real model. The tool itself sends nothing: it is a single HTML file, the draft stays in the browser's local storage, and your API key is never entered into it.
An example: sorting after-sales requests
Take the flow from our industry and after-sales worked scenario: 120 requests a week, six reasons covering 72% of the volume, and one person who reads every email to route it. The state is the customer's email, passed as the parameter {{request}}. Three questions are enough.
A Choice "reason", with the six reasons each described in one sentence and none_of_the_above ticked: a request outside the list must be able to say so, rather than being forced into the nearest reason. A Score "urgency", on four levels described as situations ("machine down, production stopped"), not as degrees ("very urgent"): the builder flags a level that is only a number. A Noul "credit_request": is the customer explicitly asking for a refund or a credit note?
The rule is written in the scenario, not in the model. If the reason's confidence is above the chosen threshold, the request goes to the right queue. Otherwise, or if the answer is none_of_the_above, it goes to the person who used to sort them. If credit_request is above 0.8, the request is flagged for the after-sales manager, who remains the only one who can issue a credit note. The threshold is not guessed: it is set on a few hundred requests already sorted by hand, by looking at where the errors start.
Nothing in this flow is an agent. The path is fixed, a decision step replaces a human read, and the human keeps the uncertain cases and the action that costs money. It is exactly the "AI in one step, then a rule" pattern from the previous article.
Writing good questions
Question ids are not sent to the model: they are for your code. The whole question must therefore fit in the instructions. "reason" tells Jev nothing; "What is the main reason for the customer's request?" does.
Describe the options, not just their names. "Return" and "Exchange" blur together; "The customer wants to send the product back and get a refund" and "The customer wants the same product in working order" stay apart.
For a Score, describe a situation at each level. For a Noul, define what counts as yes and as no when the line is not obvious. And do not use a Noul for an intensity: 0.5 means the model is unsure, not "moderately".
Jev is mostly trained in English. Other languages, French included, are accepted with slightly lower accuracy. On a flow in another language, test on your own data before setting a threshold, and compare with instructions written in English if the gap matters to you.
Where we stand, and what it costs
Our position has not changed since the engineering page: we test Jev on our own cases, we do not deploy it for clients yet. The model is in early access, with a waitlist, and a component at that stage has no place in a production system without a fallback. The builder is meant for exactly this phase: write the questions, test them on real data, measure, before deciding anything.
The price announced by TypeSafe is $0.042 per million input tokens, and output is not billed. TypeSafe says it cannot guarantee that this price is not subsidized. The announced latency is 70 to 500 ms end to end, measured from the US West Coast. These are vendor figures, to be checked on your own flow. How it compares with a lightweight generative model, cost per call included, is in our Claude Haiku or Jev comparison.
And the rule from our other articles applies here too: a decision model on a list of reasons nobody maintains, or on data the team disputes, will reproduce the mess faster. The option list is reference data. It needs an owner before it needs a model.
Sources, checked on October 15, 2026
TypeSafe AI, "Introducing System One models and Jev", September 15, 2026: early access with a waitlist, $0.042 per million input tokens, output not billed, 70 to 500 ms latency, calibrated probabilities. TypeSafe AI post.
TypeSafe AI, documentation: introduction, Choice, Score and Noul question types, parallel and isolated evaluation, recommendation of atomic questions. Introduction, Primitives.
Jev Agent Builder, version 0.3, MIT license, unofficial tool not affiliated with TypeSafe AI. Live tool, source code.
In one sentence
Jev is not an agent: it is a typed decision step, with a probability that says when not to decide. The builder lets you write and test it in minutes, without JSON and without sending anything.
The right use in 2026 is not to plug a model in everywhere. It is to take one decision that comes back hundreds of times a week, write it as questions, measure it on your data, and keep a human below the threshold.
A decision that comes back every day?
Request triage, document classification, qualification: we start from the flow and the option list, not from the model. In thirty minutes we will tell you whether a rule is enough, whether the list has to be maintained first, or whether a calibrated decision step is worth testing.
The Jev Agent Builder page
What it does, what to know, and the link to open it.
Manufacturing and after-sales
An 80-person manufacturer that builds and maintains professional equipment. 400 customers under contract, around 120 after-sales requests a week across three channels. Here is a full engagement, from the audit through to the agent that handles the requests.