Jev: The Decision Layer Emerging Inside AI Agents

A browser agent needs to choose its next click. A coding agent needs to decide which tool results are still relevant. A user interface needs to select a useful arrangement of components. A graph search needs to choose which relationship to follow.

These look like different products. They contain a similar engineering problem: a small judgment, made from current evidence, that ordinary software needs to act on.

That is what caught my attention about Jev. Not another assistant that writes a better paragraph, but a model designed to return decisions that can fit inside a larger program.

In the first three articles in this series, I looked at parallel ownership, selective rebuilding, and relevant context. Jev raises a related question: which parts of an agent actually need generation?

This is a research-based look at the documented model and community projects, checked September 22, 2026. I have not personally benchmarked Jev. The interactive example is an illustration, not a live API call.

A different job for the model

TypeSafe introduced Jev in early access on September 15, describing it as its first System One model. The company's design trades unrestricted string generation for bounded, probabilistic outputs. TypeSafe's announcement.

The interface takes a state and questions about that state. It returns values the caller can branch on, combine, or rank. Several questions can share the same state and be evaluated independently in one request. TypeSafe recommends decomposing broad judgments rather than asking one question to settle several unrelated dimensions. Introduction.

I find it useful to think in terms of three jobs. Deterministic code handles exact rules. A decision model handles a well-scoped semantic judgment. A generative model creates something that does not yet exist: an explanation, a patch, or a new plan.

That is an architectural division of labor, not a requirement to put Jev in front of every function. Some tasks need no model. Others need sustained reasoning rather than a forced choice from a menu.

The interesting opportunity sits between those extremes: a distinction that is difficult to encode with a few keywords, but does not require generating a new document every time it is evaluated.

Three primitives, three different meanings

Jev exposes three question types. They should not all be flattened into a generic “AI score.”

A Choice might select code search, documentation lookup, or clarification. The documented selection is the option with the highest probability; returning a distribution does not mean the application must randomly sample an action. Include a suitable no-match route when the menu is incomplete. Choice.

A Score might place a report between described severity levels. It is a probability-weighted position on those levels, not a precise measurement of how many users are affected. Score.

A Noul might ask whether a passage actually supports a claim. A value of 0.8 means the model assigns that probability to the proposition; it does not mean the passage is “80% supportive.” Noul.

Choice and Score also include a confidence statistic derived from the distribution. Noul has no separate confidence field. A threshold must be interpreted in relation to the particular decision and its consequences, not treated as a universal certificate of correctness. Confidence.

That is a useful interface because uncertainty is available to the program. The remaining work is deciding what the program should do with it.

Keep the graph. Change how a branch is chosen.

One community explanation, shared by Hanako, contrasts repeated graph paths with routes chosen from live probabilities. The supplied summary includes an example distribution across code, search, and documentation. I use that as a conceptual lead, not as a reproduced result from the accompanying video.

There is an important correction to the “static graphs versus Jev” framing: a graph with fixed topology can already contain conditional branches and model-driven routers. Different executions do not have to follow the same path. Nor does a fixed path inevitably repeat undetected errors.

The useful distinction is narrower. At a particular fork, instead of trying to hand-code every semantic condition, the application can supply the currently eligible destinations and ask which best fits the observed state.

The graph defines possible work. The judgment helps select the next edge.

The candidate set can change between observations. A browser exposes different controls after navigation. A repository task may need a different evidence source after a failed test. That does not require letting the model invent arbitrary tools or grant itself new access.

The community project neo4jev demonstrates this idea with Neo4j: the system presents outgoing relationships as options, uses a classifier to select a traversal, and assesses progress toward the goal. The graph is still there. The semantic decision operates over its actual neighboring relationships.

A decision is not permission

A high-probability route can still be unavailable, stale, or forbidden.

Suppose the model prefers code search. Before that choice is consumed, the repository permission changes or the search index no longer corresponds to the current checkout. Picking the next-highest probability from the old response is not automatically a correct recovery. The system may need a fresh observation and a new decision.

Similarly, a model can judge that a refund is appropriate without being authorized to issue it. A completion judgment can sound convincing without a successful test or an observed result behind it.

My preferred separation is: observe eligible state, form a bounded question, interpret the answer, check current execution rules, perform permitted work, and verify the outcome. Those can be small functions rather than a new centralized platform.

Use the example below to switch between a clear route, ambiguous evidence, and a request that needs new prose. Then change the freshness, permission, or result-check condition. Its probabilities and thresholds are authored examples, not Jev outputs or recommended production settings. Nothing runs against your repository or an external service.

INTERACTIVE EXPLAINER · NO LIVE MODEL

Choose a route.
Keep the boundaries.

Change the task and see the proposed route. Then change the conditions the software must check.

1 / Observed task

Find an implementationAmbiguous evidenceWrite a new explanation

The symbol name and current repository revision are known. Locate the implementation before proposing a change.

OBSERVATIONCurrent stateEvidence + eligible menu

BOUNDED JUDGMENTJev-style decisionAuthored probabilities

Read code0.81

Inspect the known implementation.

Read docs0.17

Retrieve the documented contract.

Generate0.02

Ask a generative model for new prose.

2 / Independent software conditions

Observation is current Execution is permitted Result check passes

PROPOSED: Read code · CHECKED PATH

Illustrative checks satisfied

The fictional route is current and permitted, and its result check passes. No tool, model, repository, or account was actually accessed.

Trace this route →Reset example

Illustration only. Probabilities are authored, not returned by Jev. The 0.70 selection rule is not Jev’s confidence statistic. These controls grant no real permissions and execute nothing.

Browser actions make the separation visible

Browser Use's jev-ultrafast is a particularly clear example. It turns observed controls into an indexed action space. Jev selects an operation and compatible target; a separate language-model helper writes text when the chosen operation requires typing.

The executor resolves the selected observed element, checks freshness and occlusion, and performs the action. The documented design does not turn Jev output directly into arbitrary selectors or executable JavaScript. A DONE selection still needs an independent outcome check.

That structure is more interesting to me than treating the project name as a universal performance claim. The README also identifies unsupported browser surfaces, including frames, canvas, uploads, and pop-up tabs. Its reported timings are bounded demonstrations, not evidence that every website is handled reliably.

The principle generalizes: give the decision-maker a current representation of what exists; keep the mechanics of interacting with it somewhere explicit.

Desktop automation can follow a similar pattern, but its observation layer is different. agent-desktop centers on operating-system accessibility structure and stable references. That is a desktop-control foundation, not a claim that Jev alone can see and manipulate every application.

Context can be selected without being rewritten

Context tools offer another useful contrast.

fast-jev-compaction pairs tool calls with their results, asks bounded retention questions, and keeps, truncates, or removes the pairs. Retained content stays verbatim rather than being replaced with newly generated prose. The documented implementation pins selected recent messages and exposes failures for the caller to handle. Its SwiftUI demonstration is explicitly scripted rather than a live API benchmark.

Winnow instead describes filtering tool-result blocks before they enter the working context, while retaining originals for recall. The decision is made at a different point in the information lifecycle.

Neither pattern makes deletion harmless. A rare error message or a specific path can be essential later. Preserving the exact bytes of the material that survives does not prove that all necessary material survived.

This connects directly to my previous article. Required contracts, current instructions, and acceptance evidence should not become optional just because a model thinks they look uninteresting. A selector can help manage discretionary material while the application preserves mandatory sources and a way to retrieve more.

The interface itself can become adaptive

The experimental json-render Jev integration moves the idea beyond agent maintenance. An application supplies configured components, bindings, content, and allowed actions. Jev helps select and arrange those possibilities into an interface.

It is not generating arbitrary UI source or inventing missing prose and business data. Its guide distinguishes composition from the eventual invocation of an action: displaying a permitted action in a component does not authorize its execution. The documented APIs are experimental and unreleased as of this review.

That division is compelling. A product can retain control of its component vocabulary and data bindings while making the arrangement responsive to the current request.

It also exposes the real design work. Someone still needs to define meaningful components, valid combinations, accessible rendering, and the actions the user can actually take. A decision engine is useful only when its available choices represent a coherent product.

The application defines what can exist. The model helps choose what fits.

Review, completion, and data are different decision surfaces

jev-review stages a review through risk screening, evidence selection, classification, severity, and routing. Its documentation calls the project experimental and treats findings as prompts for review rather than proof of defects. It does not replace compilers or defect reproduction.

Canny approaches the other end of the task: evidence for completion. It records events and uses deterministic hooks alongside advisory Jev judgments. The distinction is valuable even without accepting every project claim: a model's assessment of supplied evidence and the existence of a passing check are different facts.

Database applications introduce a different boundary again. pg-jev exposes natural-language filtering, ranking, and classification over PostgreSQL rows through external judgments. It is not a vector index and does not require embeddings.

The attractive idea is a semantic predicate beside exact SQL predicates. The operating questions are less glamorous: which rows leave the database, how credentials are handled, how often calls happen, and what a timeout does to the query. A valid SQL interface does not remove those questions.

For dataset work, jev-curate describes a streaming system for screening records with typed judgments. That is another point where a decision can be more useful than a generated explanation for every row. Its reported throughput remains the project's measurement, not mine.

Games and simulated robotics reveal another boundary

The community list also includes projects that look nothing like office automation.

typesafe-mario uses structured emulator state. OneVOneJev combines a Three.js arena with TypeSafe decisions. These are examples of choosing actions from a representation of a world, not evidence that Jev has native video understanding.

jev-drone describes a MuJoCo simulation with a visual processing pipeline, tactical Jev decisions, conventional control, and a separate safety layer. Tactical choices and low-level stabilization run on different timescales. This is simulated robotics, not a certification of autonomous physical flight.

The architectural lesson is bigger than the demos. A system does not have to ask the same model to perceive, plan, steer, verify, and explain at the same frequency. Each job can have a different representation, loop, and failure response.

That is a more productive way to read the variety of projects than assuming one model suddenly performs every task end to end.

Repeated reasoning may become reusable procedure

A different pattern appears in AJ's agentrun() post. The supplied post text and screenshot describe a harness that learns repetitive work and shifts steps from LLM calls into executable code.

The post claims roughly 90% lower cost for compliance-alert processing: more than $290,000 per 100,000 alerts on its stated Opus 5 baseline, versus less than $26,000 with the harness. The accompanying chart shows declining per-alert costs across batches.

Those are attributed harness-level claims. I have not established whether the 100,000-alert totals are measured or extrapolated, whether quality is equivalent, or which operating costs are included. They should not become “Jev makes every agent 90% cheaper.”

The mechanism suggested by the claim is nevertheless worth discussing: observe a repeated procedure, identify stable portions, and move those portions into reusable code while retaining model judgment for cases that need it.

TypeSafe's model documentation says Jev uses the same weights across accounts, with domain customization supplied through request state and questions. An improving harness is not evidence of customer-specific online retraining inside Jev. Model customization.

There is also a boundary between repetition and determinism. A frequent pattern can still have rare exceptions. Generated code needs an explicit contract, review, and verification; frequency alone does not prove a shortcut preserves the original behavior.

The compelling direction is not an agent blindly hardening its habits. It is an execution system accumulating useful, checked procedure instead of paying for the same discovery indefinitely.

Parallel questions are not a fleet of parallel agents

A dense fan-out diagram can hide several different forms of concurrency.

TypeSafe's speculative fan-out pattern evaluates questions for several possible branches in advance. The program then consumes the answers relevant to the branch it actually takes. Extra questions consume input tokens even when their answers are unused.

That is distinct from launching separate workers, scheduling dependent tasks, or executing every proposed action. Predicting several possibilities does not authorize performing them all.

For example, an operation choice and several possible target choices can share one observation. But only the target compatible with the selected operation should be used. If later evidence is required, another stage still has to wait for it.

This is the same discipline behind useful agent parallelism: independent work can overlap; dependency barriers and shared resources do not vanish. A shared decision interface also does not require a single central server through which every task must pass.

What the headline numbers do and do not say

TypeSafe reports 193.6× faster and 444.6× cheaper on its workflow evaluations, and explicitly describes those figures as toward the higher end of expected gains. Its announcement also gives a 70–500 ms response-time range. These are vendor-reported results with specific measurement boundaries, not service-level guarantees for arbitrary agent workloads. Announcement and qualifications.

The published evaluation methodology holds workflow logic fixed and compares answers with reference probabilities from other strong models. That helps explain the comparison being made. It is not the same as independently measured business accuracy across every task in the community list.

As of September 22, the model page lists jev-1.13.0, input pricing of $0.042 per million tokens, free output tokens, and text-only inputs. Aliases can move, and rate limits are explicitly described as dynamic. Current model reference.

For an application, I would still care about the cost of the accepted result: preprocessing, repeated state, retries, generative fallbacks, tool execution, and review. A cheaper individual judgment and a cheaper completed workflow are related, not identical.

Type safety is not truth

The most important limit is not hidden in a benchmark chart. It is in the distinction between a valid value and a correct judgment.

TypeSafe's Jev 1.13 limitations describe difficulties with numerical precision, indirect references, irrelevant context, adversarial material, and consistency between independently evaluated questions. Exact arithmetic and required invariants still belong in code.

A model can return an allowed option that is wrong for the situation. It can assign probability to a claim supported by incomplete evidence. A safety-sounding tool name does not make its judgment an enforcement boundary.

My takeaway is to keep four responsibilities legible: the representation supplied to the model, the quality of the judgment, the authority to execute, and evidence of the actual result. Combining them into one “verified” label makes failures harder to diagnose.

That is not an argument against decision models. It is how a useful decision becomes a component of dependable software rather than a substitute for it.

A community reading map

The following twenty projects came from a community list shared by Charlie Hills. I reviewed the linked project material rather than treating the roundup as twenty independent benchmarks. Some entries are purpose-built prototypes; others add Jev to an existing framework. The shortened skills-directory links are replaced here with upstream references, not installation instructions.

The trading entries are examples of system design, not investment recommendations or evidence of profitable HFT. The linked Prism adjustment is disabled by default and limited to paper mode; jev-trader documents mock and dry-run paths. Neither a repository nor a demo establishes future returns.

The additional pg-jev project discussed above is not part of that twenty-item list. Keeping that distinction prevents a roundup from quietly changing membership as it is repeated.

The engineering shift worth watching

What connects these projects is not one universal architecture. It is the willingness to pull a decision out of a larger conversation and give it an explicit interface.

Which evidence should stay? Which route is useful now? Which configured component belongs here? Which claim needs another check? Which part of a repeated workflow can become ordinary software?

Those questions make the model's role smaller in one sense and more reusable in another. They also make the rest of the engineering easier to see: observation, contracts, permissions, state, fallbacks, and outcomes.

I do not read Jev as the end of generative agents. I read it as another reason to stop treating generation as the default implementation of every step.

Generate when something new is needed. Judge when a bounded decision is needed. Use code where the rule is known. Keep responsibility for the result.

Source notes

Primary documentation and separately labeled user-supplied post evidence. Community results are attributed, not reproduced.

1. TypeSafe's announcementSeptember 15 launch, structured-decision architecture, and explicitly attributed speed/cost headline with vendor caveats. Checked 2026-09-22.
2. IntroductionState and independently evaluated typed questions; atomic judgments composed in code. Checked 2026-09-22.
3. ChoiceHighest-probability option, distribution, and bounded candidate choices. Checked 2026-09-22.
4. ScoreProbability-weighted position on ordered described levels, not a measured business quantity. Checked 2026-09-22.
5. NoulProbability of a yes/no proposition, not an intensity score. Checked 2026-09-22.
6. ConfidenceChoice/Score confidence differs from outcome probability; Noul has no separate confidence field. Checked 2026-09-22.
7. HanakoUser-supplied post summary informs routing discussion; original video not independently inspected. Checked 2026-09-22.
8. neo4jevClassifying outgoing Neo4j relationships for graph traversal. Checked 2026-09-22.
9. Browser Use's jev-ultrafastObserved browser controls, typed action/target selection, separate text helper, freshness checks, and documented limitations. Checked 2026-09-22.
10. agent-desktopAccessibility-based desktop control foundation, distinct from Jev perception. Checked 2026-09-22.
11. fast-jev-compactionCall/result retention, pinned material, failure handling, and explicitly scripted SwiftUI demonstration. Checked 2026-09-22.
12. WinnowFiltering tool-result blocks before context entry with originals retained for recall. Checked 2026-09-22.
13. json-render Jev integrationExperimental, unreleased Jev UI composition from configured candidates; action execution remains separate. Checked 2026-09-22.
14. jev-reviewExperimental staged review triage; findings are review prompts, not defect proof. Checked 2026-09-22.
15. CannyDeterministic evidence hooks with advisory model judgments for completion. Checked 2026-09-22.
16. pg-jevExternal semantic judgments over PostgreSQL rows for filtering, ranking, and classification. Checked 2026-09-22.
17. jev-curateStreaming dataset screening with typed judgments; project throughput not reproduced. Checked 2026-09-22.
18. typesafe-marioAction selection from structured emulator state, not native video input. Checked 2026-09-22.
19. OneVOneJevUpstream project description of OneVOneJev; source review only, no installation, execution, or reproduced performance. Checked 2026-09-22.
20. jev-droneMuJoCo simulation separates perception, tactical judgment, conventional control, and safety. Checked 2026-09-22.
21. AJ's agentrun() postUser-supplied text and screenshot support attribution of harness-level savings, not independent reproduction or confirmed 100,000-alert trial. Checked 2026-09-22.
22. Model customizationJev 1.13.0 pricing and text modality as checked September 22; shared weights and moving aliases. Checked 2026-09-22.
23. speculative fan-out patternSpeculative question evaluation differs from execution of all proposed branches. Checked 2026-09-22.
24. evaluation methodologyWorkflow evaluation design and model-derived reference probabilities; not independent business-ground-truth testing. Checked 2026-09-22.
25. Jev 1.13 limitationsNumerical, context, adversarial, and cross-question limitations; typed output is not guaranteed semantic truth. Checked 2026-09-22.
26. Charlie HillsUser-supplied twenty-project list is the discovery source; upstream descriptions separately reviewed. Checked 2026-09-22.
27. typesafe-mcpUpstream project description of typesafe-mcp; source review only, no installation, execution, or reproduced performance. Checked 2026-09-22.
28. jev-mcpUpstream project description of jev-mcp; source review only, no installation, execution, or reproduced performance. Checked 2026-09-22.
29. SemDecideUpstream project description of SemDecide; source review only, no installation, execution, or reproduced performance. Checked 2026-09-22.
30. jev-codex-routerUpstream project description of jev-codex-router; source review only, no installation, execution, or reproduced performance. Checked 2026-09-22.
31. BlinkUpstream project description of Blink; source review only, no installation, execution, or reproduced performance. Checked 2026-09-22.
32. jev-traderPer-block trading prototype; mock and dry-run modes are not evidence of profitable HFT. Checked 2026-09-22.
33. PrismPinned optional stress-sizing change is paper-only and disabled by default. Checked 2026-09-22.
34. killmyideaUpstream project description of killmyidea; source review only, no installation, execution, or reproduced performance. Checked 2026-09-22.