Showing posts with label llms. Show all posts
Showing posts with label llms. Show all posts

What Is Jev? What Pain Points in LLMs Does It Solve?

 The Jev model has been gaining attention across social media platforms such as Twitter and LinkedIn over the past few days, with many people welcoming this new type of frontier model.

In this post, we’ll take a closer look at what Jev is, and why it has attracted so much attention, and what pain points of existing LLMs it aims to address.


What is Jev?

According to Typesafe —the startup behind Jev, the company founded in 2024, raised $40M in seed funding, and remained in stealth for about two years before publicly launching in September 2026:

Jev is Typesafe’s first System One Model: a new class of frontier models built to make fast, structured decisions that software can use directly.

What does “system one model” mean?

The name inspired by Daniel Kahneman’s popular book Thinking, Fast and Slow. The model class name draws on Kahneman’s distinction between two modes of human thinking:

  • System 1: fast, intuitive, and automatic thinking
  • System 2: slow, deliberate, and effortful reasoning

The idea behind a System One Model is therefore to emphasize fast, structured decision-making

You give it:

  • some state/context — e.g. a social media post
  • one or more questions
  • a predefined answer space

and it returns a structured decision rather than generating text.

For example, suppose we give Jev a social media post

{
"post": "Blackpink member Lisa's new song Sawadika is so awesome! I highly recommend it!"
}

and questions

{
"lisa-mention": {
"type": "noul",
"instructions": "Is Blackpink member Lisa mentioned?",
"criteria": {
"true": "",
"false": ""
}
},
"sentiment": {
"type": "noul",
"instructions": "Is the sentiment of the post postive?",
"criteria": {
"true": "",
"false": ""
}
}
}

it can then return a structured results like:

{
"model": "jev-1.13.0",
"answers": {
"lisa-mention": {
"type": "noul",
"noul": 0.99,
"stats": {}
},
"sentiment": {
"type": "noul",
"noul": 0.98,
"stats": {}
}
},
"usage": {
"input_tokens": 348,
"output_tokens": 41
},
"request_id": "playground_145bf5fb0a91b2e44fd9add60eeece28811",
"evaluation_time_ms": 158.65631199994823
}

What pain points does Jev solve?

LLMs and LLM-powered agents have become increasingly popular, so why has a new frontier model like Jev attracted so much attention all of a sudden?

The answer lies in a fundamental difference in what Jev is designed to do. Rather than generating text for humans to read, Jev is designed to make structured decisions that software can consume directly.

This addresses several important pain points when using conventional LLMs in production.

First, structured output is not guaranteed.

If you have deployed LLMs in production workflows, you probably know the problem: asking an LLM to return a specific JSON schema does not necessarily guarantee that the output will always conform to that schema.

LLMs generate output token by token, and their outputs are inherently probabilistic. Even when the probability of producing an invalid response is very low, a single malformed JSON response can still break a downstream workflow. In production systems, even a small failure rate can become significant when a model is called millions of times.

This is one of the areas where Jev takes a fundamentally different approach. Its outputs are type-safe structured values, with the possible output structure defined in advance. TypeSafe claims that Jev cannot produce type errors because the model does not generate arbitrary strings that need to be parsed and validated.

Second, cost.

The cost of frontier LLMs has fallen significantly, especially with the growing number of open-weight and highly competitive models. However, inference is still generally priced around input and output tokens, with output tokens often costing substantially more than input tokens.

Jev takes a different approach. TypeSafe currently lists its input price at $0.042 per million tokens, while its structured outputs have no metered output-token cost.

This matters particularly for large-scale automation, where a system may need to make millions or even billions of relatively small decisions.

Third, latency.

LLMs generate text sequentially, producing one token at a time. Even with highly optimized inference systems, generating a response can introduce substantial latency — especially when reasoning is involved.

Jev uses a different sampling approach: instead of autoregressively generating a sequence of output tokens, it generates its structured outputs in parallel. TypeSafe reports 70–500 ms end-to-end response times for Jev, compared with 3–329 seconds for the frontier LLMs in its comparison. The company says this translates to roughly 40×–200× faster performance for comparable System One tasks.

Taken together, these differences point to a different role for AI models. Traditional LLMs are optimized to generate flexible language for humans, while Jev is designed to provide fast, structured, machine-consumable decisions.

source: https://typesafe.ai/blog/introducing-system-one-models-and-jev?utm_source=chatgpt.com

Although Jev addresses a subset of the problems that LLMs struggle with, it is clearly not designed to replace LLMs altogether. Instead, it can complement them by handling certain tasks in a cheaper and faster way, rather than using a full LLM for every decision.

So obviously, you cannot have a conversation with Jev in the way you would with a traditional LLM.

In fact, this Twitter post by @ryanvogel shows this quite nicely. He conducted an interesting experiment: he tried to turn Jev into a chat model by asking it to predict which character should come next. The results were predictably poor — which makes sense given that Jev is designed for structured decision-making rather than open-ended text generation.

It is also important to distinguish output reliability from prediction accuracy. Eliminating hallucinations in the output schema and guaranteeing a valid structured response does not automatically make the underlying decision correct.

Jev may be cheap and fast, but the real question is how accurate its decisions are across different tasks and use cases. Ultimately, we need to look beyond latency and cost and evaluate how well Jev performs on the problems it is designed to solve.

For example, this LinkedIn post describes another interesting test. The author asks Jev to assign probabilities to the outcome of an unfair coin flip, where the coin is known to land on heads 60% of the time. Given that information, we would expect the probabilities for the next flip to be 60% heads and 40% tails.

However, Jev reportedly returned 99% heads and 1% tails.

This is a useful example of why a guaranteed structured output does not necessarily mean a correct output. Jev can reliably return a valid answer in the expected format, but the quality of the underlying decision still needs to be evaluated.


What is the gist of training Jev?

At this point, we should have a good understanding of how Jev works and how its outputs differ from those of traditional LLMs.

Although not many technical details about the training process have been revealed so far, Jev is optimized with RLCD (Reinforcement Learning for Calibrated Decisions). The goal is to teach the model not only to make decisions, but also to accurately reflect its probability of being correct — in other words, to make calibrated decisions.

This is different from how LLMs are commonly optimized. RLHF (Reinforcement Learning from Human Feedback) trains models to produce responses that humans tend to prefer, while RLVR (Reinforcement Learning with Verifiable Rewards) optimizes models against rewards that can be objectively verified, such as whether a mathematical answer or piece of code is correct.

In simplified terms, we can think of the difference as:

  • RLHF: “Give an answer that people prefer.”
  • RLVR: “Give an answer that can be objectively verified.”
  • RLCD: “Make a decision and be well-calibrated about how likely you are to be correct.”

The community is responding to this idea pretty quickly. There are already open-source System One models trained with RLCD, such as laya, emerging.


Jev represents an interesting shift in how we think about frontier models. Rather than trying to make an LLM generate better and longer responses, it focuses on a different problem: making fast, structured decisions that software can use directly.

This approach addresses some practical pain points of using LLMs in production, particularly the cost and latency of inference and the difficulty of guaranteeing structured outputs. At the same time, these engineering advantages should not be confused with decision accuracy. A model can be fast, cheap, and perfectly structured while still making the wrong decision.

For this reason, Jev is perhaps better viewed not as a replacement for LLMs, but as another component in the AI stack. LLMs remain useful for open-ended language generation and complex reasoning, while a System One model like Jev could handle the many smaller, faster, structured decisions that surround them.

The most interesting question, then, is not whether Jev will replace LLMs, but where this new class of models fits — and how much of the work currently done by LLMs can ultimately be handled more efficiently by specialized decision models.

Demystifying Open-source System One Models

 System One models are designed around a simple but powerful idea: instead of generating an answer as text, evaluate a predefined set of possible answers and return a decision distribution.

But there is no single architecture for building such a system.

In this post, I look at four open-source approaches that illustrate some of the most interesting architectural choices:

  • Laya — an encoder-based approach that scores candidate options at dedicated [MASK] positions.
  • Strands Decider — a decoder-only LLM whose language-model head is replaced by a learned pointer head that scores candidate options.
  • SemIf / OpenJev — a decoder-only LLM that directly reuses the model’s native logits for predefined answer tokens, followed by calibration.
  • Contrastive Language Models (CLMs) — a representation-based approach that learns to match a state representation against embeddings of candidate actions using contrastive learning.

These models are particularly interesting to compare because they arrive at a similar System One-style interface through fundamentally different architectures.

At a high level:

Laya: score options at marker positions
Strands: learn a pointer to score option representations
SemIf/OpenJev: read the LLM’s own answer-token logits
CLM: compare state and action embeddings

There is also a second dimension that is easy to overlook: how much the underlying language model is adapted for the decision task. Laya fully fine-tunes its encoder backbone; Strands Decider adapts its Qwen backbone with LoRA; CLM trains its representation model with a contrastive objective; while SemIf/OpenJev demonstrates how a frozen causal LLM can itself be repurposed as a decision engine.

So rather than treating “System One model” as a single architecture, this post uses these models to explore four different ways of turning language-model representations into decisions.


Laya

HuggingFace: https://huggingface.co/convaiinnovations/laya

Laya is an encoder-based System One model, or Jev-alike open-source decision model.

At first glance, Laya looks relatively simple. But there are several interesting components worth looking at in more detail:

  • Backbone
  • Option-marker
  • Act/Escalation head
  • Router

Which backbone does it use?

Laya uses encoder backbones such as ModernBERT-large for English and mmBERT-base for multilingual.

Unlike decoder-only LLMs, these are bidirectional encoders: each token can attend to tokens on both sides of it, allowing the model to build a representation using the full input context.

What is the Option-Marker Scorer?

The Option-Marker Scorer is the component that turns the model into a variable-choice decision model.

Each candidate option gets its own marker, represented by a [MASK] token. The model produces a score at each option marker, and those scores are then softmaxed across the options belonging to that particular question.

This is important because the answer space does not have to be fixed when the model is trained.

What is the Act/Escalate head?

The Act/Escalate head is another component of Laya’s decision head.

Its purpose is different from simply predicting which option is most likely. It estimates whether the decision is reliable enough to be automatically acted upon or should instead be escalated for human review.

Instead of relying solely on simple, rigid confidence thresholding rules (e.g., “if probability is greater than 0.8, act”), the Act/Escalate head learns a non-linear decision boundary by combining semantic textual context with statistical properties of the option distribution.

What is the Router?

Laya actually consists of multiple specialized checkpoints built around different backbone models.

The Router is a pre-inference dispatcher that determines which checkpoint should handle a request. The project recommends using the Router in production; it detects language/script characteristics and dispatches the request to the appropriate checkpoint.

The current family includes:

  • English Base (convaiinnovations/laya): Built on a ModernBERT-large backbone (395M backbone + 26M decision head = 421M total parameters). Optimized for English text classification, email triage, and guardrails with a 512-token context window.
  • Multilingual (convaiinnovations/laya-multilingual): Built on an mmBERT-base backbone (322M total parameters). Supports over 100 languages and non-Latin scripts, runs ~2.2x faster, and handles longer context windows (up to 8,192 tokens).
  • Typed-Decisions Specialist (convaiinnovations/laya-typed-decisions): Also built on ModernBERT-large, but specialized and fine-tuned for specific structured workflow benchmark domains.

Is Laya really for zero-shot use?

This is where comparisons with Jev become interesting.

Because System One models accept the answer space at inference time, it is tempting to assume that they automatically provide strong zero-shot decision-making.

But the architecture alone does not guarantee that.

The underlying backbone still matters enormously. A roughly 400M-parameter encoder should not automatically be expected to have the same broad semantic capability as a multi-billion-parameter LLM.

Laya itself is quite explicit about this limitation:

Laya is a fast base to specialise, not a zero-shot decision engine.

Strands Decider

Github repo: https://github.com/strands-labs/strands-decider

Strands Decider takes a noticeably different architectural approach from Laya.

Rather than using an encoder, it uses a decoder-only causal LLM: Qwen3.5–2B-Base.

In a causal decoder, each token can attend only to previous tokens, rather than the bidirectional attention used by an encoder.

There are three components worth looking at:

  • Backbone / LLM torso
  • Pointer head
  • LoRA adaptation

What is the backbone?

Strands Decider uses Qwen3.5–2B-Base as its backbone, or what the project calls the LLM torso.

The idea is to retain the Transformer layers that provide the model’s language understanding capabilities, while removing the standard language-model head responsible for generating the next token.

The Strands team describes the 2B model as a useful trade-off: small enough for local experimentation while still large enough to provide meaningful semantic capabilities.

What is the pointer head?

The core idea of Strands Decider is that we take a pre-trained LLM torso (Qwen3.5–2B), and remove the LM head, taking away its ability to generate text. The LM head is replaced with a pointer head which scores the answers offered by the torso for each option. It does this by scoring the hidden state at each option position against the hidden state at the <answer> position. This head is pretty small, just over a million total parameters.

When people refer to the LLM Torso (or “Backbone Torso”) in the context of a decision model or “decider” system, it refers to the main stack of Transformer layers acting as a high-capacity feature extractor, while stripping away or bypassing the standard text-generation head.

The pointer head is very small — just over one million parameters — compared with the roughly 1.9B-parameter torso.

What is LoRA used for?

The Qwen3.5–2B torso is adapted using a rank-16 LoRA adapter.

The important point is that Strands is not simply taking an off-the-shelf Qwen model and asking it to choose an answer.

The torso is adapted specifically for the decision-model task. The dataset is also available on Github: https://github.com/strands-labs/strands-decider/tree/main/data.

Is Strands Decider zero-shot?

Potentially, but with an important qualification.

The model can accept new questions and candidate options without creating a new classifier head for every task. That gives it a form of task-level zero-shot flexibility.

However, that does not mean that every arbitrary domain will work well without additional adaptation.

The underlying Qwen3.5–2B model is substantially larger than Laya’s ~400M-parameter encoder, and Strands additionally trains it with decision-oriented data.

So it is reasonable to expect stronger generalization in some settings — but zero-shot performance remains task-dependent.

This distinction is important when comparing System One models:

Variable answer spaces make a model architecturally adaptable; they do not automatically make it universally (well-performing) zero-shot.

Did Strands Decider also use calibration?

Yes — and this is an important part of the design.

Calibration is not merely an implied property of the pointer head.

The Strands training recipe has a separate calibration stage after training and before evaluation/serving. The documentation explicitly states that the published reference checkpoint is already calibrated, while other checkpoints should be calibrated before serving.


SemIf / OpenJev

https://github.com/TheoLeeCJ/SemIf-OpenJev

Unlike Strands Decider, which adds a learned pointer head to score arbitrary option representations, SemIf/OpenJev directly repurposes the LLM’s own logits over predefined answer tokens, followed by calibration. It is conceptually similar to NVIDIA’s LogitsProcessorZoo multiple-choice approach.


Contrastive Language Models (CLMs)

https://github.com/AmesianX/clm

Contrastive Language Models (CLMs) are a new class of System One model trained with a contrastive learning objective that connects states and actions. Unlike earlier approaches, CLM uses embedding-based similarity to match an input state with a set of candidate actions.

A typed question is a state plus a closed set of candidate actions (the options and their descriptions); a softmax over CLM’s scores is the answer distribution, and the same call ranks best-of-N trajectories, routes tools, shortlists retrieval pools and answers typed decisions with no per-task setup.

To achieve this, CLM first trains separate state and action encoders on a large-scale dataset using a contrastive InfoNCE objective. During training, the model learns to pull each state representation closer to the representation of the ground-truth action while pushing it away from the representations of alternative actions.

What are the differences and relationship between MCP and A2A protocol?

 

What are the differences and relationship between MCP and A2A protocol?

After MCP (Model Context Protocol) from Anthropic getting popularity, recently Google has introduced another protocol - A2A (Agent to Agent Protocol). A natural question arises is how are they related to each other? Are they complementing or competing with each other?

In this post, let’s try to demystify the two protocols.

Current AI Agentic System (or Multi-agent System) development has two challenges:

  • Integrating agent with tools and data
  • Agent to agent communications

In a nutshell, MCP (Model Context Protocol) tackles the first challenge, and A2A (Agent to Agent Protocol) aims to tackle the second one.

MCP

MCP (Model Context Protocol) from Anthropic is an open protocol that standardizes how applications provide context to LLMs, like USB-C port for AI applications.

Just as USB-C provides a standardized way to connect your devices to various peripherals and accessories, MCP provides a standardized way to connect AI models to different data sources and tools. - MCP documentation

According to HuggingFace, an agent has an LLM as its brain and capabilities and tools as its body.

  • Tools available to an agent allow it to access new knowledge beyond the knowledge cut-off date, such as retrieving social media data or the current weather.
  • Capabilities represent everything the agent is equipped to do. One popular capability example is using a memory component to remember things, such as previous conversations and external data.

Look into the example provided by Anthropic, an agent (MCP host) can access additional context from local data sources or remote services via MCP protocol.



  • MCP Hosts: Programs like Claude Desktop, IDEs, or AI tools that want to access data through MCP
  • MCP Clients: Protocol clients that maintain 1:1 connections with servers
  • MCP Servers: Lightweight programs that each expose specific capabilities through the standardized Model Context Protocol
  • Local Data Sources: Your computer’s files, databases, and services that MCP servers can securely access
  • Remote Services: External systems available over the internet (e.g., through APIs) that MCP servers can connect to

The MCP Server is a foundational component which provides tools, resources, and capabilities to clients via APIs and endpoints. More specifically:

  • Exposing tools that clients can discover and execute
  • Managing resources with URI-based access patterns
  • Providing prompt templates and handling prompt requests
  • Supporting capability negotiation with clients
  • Implementing server-side protocol operations
  • Managing concurrent client connections
  • Providing structured logging and notifications

A2A

A2A (Agent to Agent Protocol) from Google is an open protocol that provides a standard way for agents to collaborate with each other, regardless of the underlying framework or vendor.

A2A facilitates communication between a "client" agent and a “remote” agent.

A client agent is responsible for formulating and communicating tasks, while the remote agent is responsible for acting on those tasks in an attempt to provide the correct information or take the correct action.

This interaction involves several key capabilities:

  • Capability discovery: Agents can advertise their capabilities using an “Agent Card” in JSON format, allowing the client agent to identify the best agent that can perform a task and leverage A2A to communicate with the remote agent.
  • Task management: The communication between a client and remote agent is oriented towards task completion, in which agents work to fulfill end-user requests. This “task” object is defined by the protocol and has a lifecycle. It can be completed immediately or, for long-running tasks, each of the agents can communicate to stay in sync with each other on the latest status of completing a task. The output of a task is known as an “artifact.”
  • Collaboration: Agents can send each other messages to communicate context, replies, artifacts, or user instructions.
  • User experience negotiation: Each message includes “parts,” which is a fully formed piece of content, like a generated image. Each part has a specified content type, allowing client and remote agents to negotiate the correct format needed and explicitly include negotiations of the user’s UI capabilities–e.g., iframes, video, web forms, and more.

Google highlighted A2A is a complementary to MCP rather than an alternative.

Model Context Protocol (MCP) is the emerging standard for connecting LLMs with data, resources, and tools. We already observe MCP standardizing ‘function calling’ across different models and frameworks. This is creating an ecosystem of tool service providers and dramatically lowering the complexity to connect agents with tools and data. We expect this trend to continue as more frameworks, service providers, and platforms adopt MCP.
A2A is focused on a different problem. A2A is an application level protocol that enables agents to collaborate in their natural modalities. It allows agents to communicate as agents (or as users) instead of as tools. We hope that A2A gains adoption as a complement to MCP that enables ecosystems of agents and will be working in the open with the community to make this happen.

Simply put, MCP for tools and A2A for agents.

Google even recommends that applications model A2A agents as MCP resources (represented by their AgentCard). The frameworks can then use A2A to communicate with their user, the remote agents, and other agents as illustrated below.


Discussion

With a peaceful coexisting scenario of the two standards, each agent (MCP host) can have their own connected MCP servers for accessing tools and resources via the MCP protocol. Additionally, these agents communicate with each other through the A2A protocol, as discussed in SwirlAI’s post. This applies when we treat agents as agents as independent entities rather than tools. However, this might change when agents are treated as special tools that can also be exposed via MCP servers.

It will be interesting to see how developers decided choose to adopt these standards - wheter one or both - as their decisions will eventually shape the future of these protocols. Also, MCP and A2A are both new and will keep evolving, with the possibility to extend functionalities to be better positioned in Agentic AI ecosystem.

References

What are current examples of AI agents?

 There are predictions that 2025 will be . With the first quarter of the year already behind us, we might be curious about recent announcements from major companies regarding AI agents.

Below, we provide an overview of current AI agents introduced by major companies, along with  videos to give a quick sense of what they do, followed by final remarks.

Adobe Orchestrator

Adobe has introduced a set of specialized agents with different responsibilities such as site optimization agent, content production agent, and workflow optimization agent etc., in their business-oriented platform ().

Agentforce (Salesforce)

Salesforce is a cloud-based customer relationship management (CRM) platform that helps businesses manage customer interactions, sales, marketing, and support services. Their AI agent product — Agentforce — allows to create virtual agents that are capable of doing jobs fit into configured (via easy-to-use user interface for prompt engineering and a set of predefined actions) topics and guardrails.

Claude (Anthropic)

General AI agent, while differing from Chatbot, it can navigate screens, move the cursor, click buttons, type text, and perform other actions to complete tasks on a computer.

Copilot as User Interface for Agents (Microsoft)

Copilot is an AI-powered assistant integrated into Microsoft products to help users with tasks, improve productivity, and enhance creativity. Microsoft is using the Copilot as the user interface (UI) for agents.  (as shown in the second video below). The custom agents are similar to those we can see from Agentforce.

Gemini Robotics (Google)

Google’s Gemini Robotics brings AI agent to the physical world, which can follow general (various) instructions, understand the 3D world, and react to changing environment, think and act, and interact with other agents for completing the given task.

Manus

 is a general AI agent that bridges minds and actions. Manus has gained a lot of attention after , and it claims that it excels at various tasks in work and life, getting everything done while you rest.

Nova Act (Amazon)

Amazon’s Nova Act is a Web AI agent to execute tasks within a web browser. At the time of writing, it is available as a research preview through the .

Operator (OpenAI)

Operator is also a web-based AI agent that can perform tasks within a browser, such as grocery shopping, booking tickets, and making restaurant reservations.

Final Remarks

As we can see, AI agents are primarily developed to automate workflows and improve our productivity, with a main focus on using Web browsers, computers, and hardware such as robots.

Subscription-based B2C (Business to Customer) companies like OpenAI and Antrhopic aim to provide AI agents to tend users for automating general daily workflows. B2B (Business to Business) companies like Microsoft, on the other hand, focus on offering AI agents integrated into their ecosystems to automate business workflows for their custormers.

As the year of AI agents progresses, we can expect more and more agents to be announced by various companies. MIT maintains an  that highlights state-of-the-art agents, with a focus on those already deployed in industry, to keep track of up-to-date AI agents.

One key remaining question is whether the investment in these agents is worthwhile for end users and businesses. On Reddit, there are some communities discussing their experiences regarding these agents like O, and .

What has your experience been using these agents so far, if you have been using any of them in daily life or at the workplace?