{"id":34986,"date":"2026-09-20T23:19:35","date_gmt":"2026-09-20T21:19:35","guid":{"rendered":"https:\/\/www.angulararchitects.io\/blog\/using-jev-for-agentic-ui-just-a-trend-or-a-game-changer\/"},"modified":"2026-09-20T23:30:36","modified_gmt":"2026-09-20T21:30:36","slug":"using-jev-for-agentic-ui-just-a-trend-or-a-game-changer","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/using-jev-for-agentic-ui-just-a-trend-or-a-game-changer\/","title":{"rendered":"Using Jev for Agentic UI: Just a Trend or a Game Changer?"},"content":{"rendered":"

Questionnaires instead of prompts: what a System One model brings to chat assistants and generated dashboards<\/em><\/p>\n

Agentic UI puts a model between the user and the application. Every message leads to at least one model call that picks a tool, fills in its arguments, and decides which widget to show. With an LLM, this call often takes seconds, and it costs money every time. For a user interface, both hurt.<\/p>\n

Jev takes a different route. It is the first model of a class that its vendor TypeSafe calls System One. Such a model does not write text. It answers predefined questions with predefined options, and it needs about 100 milliseconds for that. I was lucky enough to get an early preview. In this article, I summarize what you can expect from Jev for Agentic UI.<\/p>\n

\ud83d\udcc2 Source code<\/a><\/p>\n

The repository has two branches. The branch main<\/code><\/a> combines Angular, CopilotKit, AG-UI, and Jev. The branch console-chat<\/code><\/a> only uses Jev on the console and gives a quick overview.<\/p>\n

What Is Jev?<\/h2>\n

An LLM receives a prompt and generates text token by token. If an application needs a decision, it has to ask for structured output, parse it, and validate it. Jev skips these steps. It receives a state<\/em>, for instance the conversation so far, and a set of typed questions<\/em>. For each question, it returns one of the answers you defined, together with a probability for every option.<\/p>\n

A good mental model is a questionnaire. You hand the model a form along with the text it should judge. The model ticks one box per question. It cannot write anything in the margins. Your code reads the ticked boxes and decides what happens next: call a tool, show a widget, or ask the user a follow-up question.<\/p>\n

\"A<\/p>\n

Two properties follow from this design. First, the answers are typed. What reaches your code is always a value your code expects. Second, all questions of a request are answered in parallel and independently of one another. According to TypeSafe, adding questions barely changes the response time.<\/p>\n

The Example Application<\/h2>\n

The example is a small flight assistant with two views. In the chat, users ask for flights or for their bookings. Jev picks the tool and its arguments. The server runs the tool and streams the result via AG-UI. On the client side, CopilotKit displays each flight as a widget:<\/p>\n

\"Chat<\/p>\n

The dashboard goes one step further. Users describe the tiles they want to see. Jev answers a larger questionnaire about this description: which tiles are requested, for which route, with how many entries, and in which order. The server then calls the needed tools and sends the dashboard to the client as A2UI:<\/p>\n

\"Dashboard<\/p>\n

Getting Started<\/h2>\n

The SDK comes via npm:<\/p>\n

npm install @typesafe-ai\/sdk<\/code><\/pre>\n
TypeSafe also provides a skill that teaches coding agents the question types, patterns, and best practices. For Claude Code, it is installed as a plugin. For other agents, the skills<\/code> CLI does the job:<\/p>\n
# Claude Code\nclaude plugin marketplace add typesafe-ai\/skills\nclaude plugin install typesafe@typesafe-ai\n\n# Other agents\nnpx skills add typesafe-ai\/skills --skill typesafe-ai<\/code><\/pre>\n
Defining the Questionnaire<\/h3>\n
The questionnaire for our chat consists of three questions. The first one selects the tool. The other two determine its arguments:<\/p>\n
import { choice } from '@typesafe-ai\/sdk';\n\n[...]\n\nconst CITIES = {\n  'Berlin': null, 'Bremen': null, 'Dresden': null, 'Frankfurt': null,\n  'Graz': null, 'Hamburg': null, 'Innsbruck': null, 'Linz': null,\n  'London': null, 'M\u00fcnchen': null, 'Paris': null, 'Rome': null,\n  'Salzburg': null, 'Stuttgart': null, 'Wien': null, 'Z\u00fcrich': null,\n} as const;\n\nconst CITY_OPTIONS = {\n  ...CITIES,\n  'NOT_DEFINED': 'No place is named for this end of the journey.',\n  'NOT_SUPPORTED': 'A place is named, but it is not one of the cities listed here.',\n} as const;\n\nconst CITY_NAMES = Object.keys(CITIES);\n\nconst QUESTIONS = {\n  tool: choice(\n    'A traveller writes to an assistant that searches flights and lists the flights ' +\n      'they have booked. conversation<\/code> is the exchange so far; the last entry is the ' +\n      'new message. What do they want now?',\n    {\n      flights: 'To travel somewhere, or to see connections between two places.',\n      bookings: 'To see the flights they have already booked: their own reservations.',\n      none:\n        'Neither: a greeting, a thank-you, or something this assistant cannot do, ' +\n        'such as hotels or trains.',\n    },\n  ),\n\n  from: choice(\n    'Which city does the traveller now name as the start of the journey, the place departed ' +\n      'from? The last entry of conversation<\/code> is the new message; earlier entries count only ' +\n      'when the new message builds on them, as a return flight does.',\n    CITY_OPTIONS,\n  ),\n\n  to: choice(\n    'Which city does the traveller now name as the end of the journey, the destination? ' +\n      'The last entry of conversation<\/code> is the new message; earlier entries count only when ' +\n      'the new message builds on them, as a return flight does.',\n    CITY_OPTIONS,\n  ),\n};<\/code><\/pre>\n
Each question is a choice<\/code>. It takes the question text and an object with the possible answers. The keys are the options, and the values describe them. If a key speaks for itself, as the city names do, null<\/code> is enough. The name conversation<\/code> in the question texts points to the property of the same name in the state that we pass along later.<\/p>\n
The possible answers must be defined up front. This is why the two city questions get two additional options. NOT_DEFINED<\/code> covers messages that name no city. NOT_SUPPORTED<\/code> covers cities the airline does not serve. Without these options, the model would have to tick one of the 16 cities even when the message names none of them.<\/p>\n
Currently, a question can have up to 255 options. Larger sets call for some creativity. I come back to this at the end of the article.<\/p>\n
Further Question Types<\/h3>\n
Besides choice<\/code>, there are two further question types:<\/p>\n