Why we're already testing Jev against real enterprise decisions

We're already testing TypeSafe's new decision model against the judgments that sit inside every Maven conversation, ticket classification, Intelligent Fields, and quality checks included. In our own early testing it ran about 12 times faster than our current approach on classification work, and it did not get slower as we added more classifications to the same request. 

A customer request contains more than one decision

Consider a customer who writes: "Our bill doubled, half my team can't log in, and I need this fixed before renewal tomorrow."

Resolving that request involves several kinds of work: the agent needs to recognize the billing and access issues, understand the urgency, check the customer's account, and follow the appropriate policies. If a person needs to step in, the conversation must reach the right team with enough context to continue.

Some of that work requires reasoning and explanation. Some requires a direct lookup. Some comes down to a focused judgment: which issues are present, how urgent they are, or whether the customer has asked for a human.

That last category is where Jev becomes interesting. 

We started putting Jev through the same evaluation discipline we built for voice models the moment it left early access, because a claim like this is worth checking against how a customer's actual workflow behaves, not just a vendor benchmark.

Jev is like a classifier, with a twist: give it context and bounded questions; it returns choices, scores or probabilities. TypeSafe AI's new model is designed to return structured decisions that software can use directly. For an enterprise platform like Maven, it creates an opportunity to improve the many judgments that sit between a customer's request and its resolution.

What Jev does differently than an LLM

TypeSafe calls Jev a "System One" model. A developer supplies context, questions, and the possible answers. Jev returns choices, scores, and probabilities. Several independent questions about the same context can be evaluated in parallel. It does not generate free-form text like an LLM.

For the request above, a system could ask whether it contains a billing issue, whether access is blocked, and whether the customer has stated a deadline. Each answer becomes an input to the next step in the workflow.

Conventional LLMs can already produce schema constrained outputs. Jev's proposition is a model built specifically for this work, with parallel output generation and training that TypeSafe calls Reinforcement Learning for Calibrated Decisions. The aim is to make uncertainty useful to software, alongside lower latency and cost.

Early users have also reported substantial speed improvements on specific tasks. In our own testing, Jev came back about 12 times faster than our current approach. That is early prototyping, not a benchmark, and it is not running in production for our customers. Others are reporting similar numbers on their own tasks: Vercel's Guillermo Rauch measured up to 18 times faster at the 95th percentile on the command safety review his agent runs, with higher accuracy than the GPT-5.6-Luna reviewer it replaced.

Intelligent Fields are a natural place to evaluate it

Maven shipped Intelligent Fields in spring 2026. Teams define what they want to understand about a conversation, such as product area, sentiment, refund intent or escalation signal, and the resulting fields feed reporting, routing and agent configuration.

What makes that good today is how little it asks of you. You write a plain-language definition of what you want to know and Maven evaluates every conversation against it. No labeled training set, no model to maintain per label, no analyst tagging tickets by hand a week later. Each value comes back with a confidence score and the rationale behind it, available through the API and the analytics views, which means a human can audit why a conversation was marked a churn risk instead of taking the label on faith.

Each field is its own evaluation, by design. That separation is what lets every value arrive with its own confidence score and its own rationale, rather than one blended verdict about the conversation that nobody can audit.

A decision model like Jev maps onto that structure cleanly. Independent questions over the same context evaluate in parallel, so a set of field evaluations can be batched into a single request and still come back as separate, individually scored answers. The shape of the output does not change. What changes is how many questions can be in flight at once.

So we do not expect Intelligent Fields to work differently under Jev. We do expect to gain efficiencies and reduce costs. 

‍

‍

These are candidate mappings to evaluate. Jev would need to preserve the meaning of each field and the behavior of any workflow that depends on it. Its narrower output also matters: open ended summaries and written explanations would still need a generative model or another source.

The opportunity is especially relevant when a team wants more detail from each interaction. A lower cost per evaluation could make it practical to track additional product issues, cancellation reasons, and escalation signals without making every new field another expensive model call.

We do not put week-old models in front of enterprise customers

Everything above is testing and design thinking. Jev is not running in any customer workflow, and a model released days ago is not going anywhere near one until it has been through the same evaluation discipline we apply to any new model. You can see how we’ve been testing GPT-Live-1 and other voice models. We measure decision quality against our current approach on representative cases, including the ambiguous ones and the ones where the deciding context is missing, then comparing latency, cost per accepted result and customer outcome before anything touches live routing.

A broader choice of models for enterprise work

Jev expands the options for building an enterprise AI agent. Conversation, reasoning, classification, and verification can each have different model requirements.

For Maven, the opportunity is to evaluate Jev where it could make features like Intelligent Fields more efficient, while preserving the context and controls required to resolve the customer's request.

Bring Maven a workflow where repeated decisions slow the experience down: a ticket that keeps changing queues, a field that is expensive to evaluate, or a quality check that runs too late. That is where a new model can earn its place.

That's possible fast because Charters, Segments, and Intelligent Fields already define the decisions that matter here. Swapping in a faster judgment layer underneath them is a configuration change we can test in days, not a rebuild that takes quarters.