applied AI

JEV in CRM: AI that decides in milliseconds, and what changes in Kommo with Bytebio

What is JEV, TypeSafe AI's System One model, and how does it qualify leads, score engagement, and move leads through the sales process? Kommo, under the governance of Harnz.

Team Bytebio 17 min read

Model in light stone of a Y-shaped path on a dark slab: a row of stone spheres awaits at the entrance and a green glass sphere has just been guided by one of the branches, leaving a luminous trail, against a black background.
This page
  1. What is JEV?
  2. The three questions he answers
  3. Determinism, no; consistency, yes.
  4. Where does this fit into the CRM?
  5. Demonstration: a lead from Kommo evaluated by JEV
  6. Numbers
  7. What JEV does not do
  8. How does it fit into the ecosystem of Bytebio
  9. How to start the operation without stopping.
  10. The conclusion that matters to the decision-maker.

What you will find in this article:

  • Why is generative AI, so good at conversation, slow and expensive when it comes to decision-making?
  • What is JEV, TypeSafe AI's "System One" model, and what does it return in place of text?
  • The three questions he answers: choice, rating, and yes or no, always with probability and confidence.
  • Where this applies in CRM: qualification, scoring, labels, step routing, and service queue.
  • A demonstration with a lead from Kommofrom payload to action on the card
  • The cost and speed figures published by TypeSafe and those from an independent test.
  • What the JEV doesn't do, and why it complements the AI ​​agent instead of replacing it.
  • How does it fit into the ecosystem of Bytebio: KommoHarnz, ByteGPT ByteCapture

Almost every company that uses CRM has implemented a language model at some point in the process: a WhatsApp agent, an automatic conversation summary, a lead classification triggered by n8n. And almost all have run into the same trio of problems when the volume increased. Responses take seconds, the cost per call accumulates on a large scale, and the same lead receives different classifications on different days.

This isn't a flaw in generative models. It's a deviation from their function. They were designed for writing, and most of a CRM's job isn't writing. It's deciding: is this lead hot or cold, is this message a support question or a purchase intent, does this card stay where it is or advance to the next stage?

In September 2026, a San Francisco-based company called TypeSafe AI released an early access model specifically designed for this second task. It's called JEV, and it's worth understanding what changes.

What is JEV?

TypeSafe describes JEV as the first model of a new class, which it calls System One . The name comes from Daniel Kahneman in Thinking, Fast and Slow : System 1 is fast and intuitive thinking, System 2 is slow and deliberate. A generative model is System 2: it reasons in text, one word after another. JEV is System 1: it receives a state (a text, a JSON, a list of events), receives one or more typed questions, and returns answers that the code consumes without interpreting.

The difference is immediately apparent in the response format. A generative model, asked to classify a lead, returns text that needs to be read, validated, and frequently corrected because it wrote "Hello, here is the JSON" before the JSON. JEV doesn't generate text. It returns the chosen option, the probability of each option, and a confidence number. It's a function, not a conversation starter.

TypeSafe sums up its positioning in three words: "decisions, not strings".

The three questions he answers

Every question to the JEV falls into one of three types , and that's what makes the outcome predictable.

Question type Example in CRM What returns
Choice (choiceWhich of these options? Lead stage: active, passive, inactive, or dormant The winning option, the probability of each, and the confidence.
Note (scoreAt what level? Engagement on a scale of 0 to 4, with written criteria per level. The score, which can fall between levels, indicates higher probabilities and confidence.
Yes or no (noulIs this true? Is there an intention to buy in this conversation? A value from 0 to 1, which is already the probability of a "yes" answer.

Two details are important for those who install automation systems.

The first is confidence . In multiple-choice and rating questions, it measures how much probability is concentrated on a single answer. When the model divides the probability between two options, confidence drops, and the documentation recommends using this as the second axis of the decision: the answer says what, confidence says whether it can act on its own. High confidence means the code acts. Medium confidence means the code requests confirmation or a mark for review. Low confidence means a person decides.

The second is batch processing . Several questions go into the same request, each evaluated independently against the same state, without the answer to one contaminating the others. Since the state is sent only once, asking ten things costs little more than asking one.

Determinism, no; consistency, yes.

The question every engineer asks is whether JEV is deterministic. The honest answer, and TypeSafe itself makes this distinction, is that it is consistent. Strict determinism would be returning the same identical answer for the same identical input. Consistency is making the same decision when the meaning remains the same, even if the sentence changes.

For anyone who has tried to classify WhatsApp messages, this solves an old dilemma. Regular expressions are too fragile: if the customer writes "I want a quote" instead of "I want a proposal," the rule fails. Generative models are too unpredictable: an extra comma in the prompt changes the behavior. JEV is somewhere in between. It understands semantics as a language model and responds with the structure of a function.

In a test published by TypeSafe with thirteen questions repeated five times about the same document, most of the answers did not vary at all between rounds.

Where does this fit into the CRM?

A model that makes quick and inexpensive decisions changes the role of AI within CRM. Instead of just being in customer service, it becomes the decision-making layer that runs in the background, for each event, without anyone needing to ask anything. TypeSafe's use case map lists, for sales, exactly what a commercial operation needs: alignment with the ideal customer profile, company maturity, pain points, purchase intent, prioritization, and routing.

Translated into Kommowith the systems that the Bytebio It's already integrated into the CRM, so it'll stay like this.

Continuous lead qualification. With each message or event, the entire card history (messages, clicks, response time, origin) is evaluated and the relationship stage field is updated. No one-time qualification upon entry and then forgotten.

Engagement score. A score on a scale defined by the company, with written criteria for each level, recorded in a numerical field on the card. The salesperson sorts the queue by this field instead of relying on instinct.

Interest tags. A multiple-choice question by subject (scheduling, ERP integration, AI support, price) becomes a tag for the lead. Segmentation for campaigns and reports is then based on what the customer said, not what the salesperson remembered to write down.

Commercial intent versus a need for support. A simple yes or no that separates those who want to buy from those who need help, and directs each to the correct queue before anyone even reads it.

Stage routing. When the probability of closing exceeds a threshold, the card advances to the next stage and the salesperson receives a task. When it falls below that threshold, the card returns to the nurturing stage.

Urgency and risk of loss. On an active basis, the same mechanism reads cooling signals and opens a reactivation task before the customer disappears.

AI agent guardrail. Before the agent responds, a yes or no question checks if the message requests something outside the scope or contains sensitive data, and redirects to a person when the answer is yes.

The common thread is that in none of these cases does the JEV (Executive Value Proposition) write anything for the client. They decide, and the CRM (Customer Relationship Management) executes.

Demonstration: a lead from Kommo evaluated by JEV

The example below adapts to Kommo The proof of concept presented in the talk that inspired this article was originally done in n8n with another CRM. The flow is the same: read the card and the timeline, assemble the state, ask the question, and write the answer back on the card.

The state is a summary of the lead. Note that it arrives already structured, because JEV evaluates text and JSON, and that the origin comes from ByteCapture tracking.

{
  "model": "jev-latest",
  "state": {
    "lead": { "etapa": "Contato realizado", "origem": "Instagram Ads, via ByteCapture" },
    "contato": { "empresa": "Clínica com 12 profissionais", "cargo": "Gestora administrativa" },
    "linha_do_tempo": [
      { "quando": "há 6 dias", "evento": "Clicou no anúncio e mandou a primeira mensagem no WhatsApp" },
      { "quando": "há 6 dias", "evento": "Perguntou se a IA agenda consultas e lembra os pacientes" },
      { "quando": "há 4 dias", "evento": "Recebeu a apresentação em PDF e abriu em três minutos" },
      { "quando": "há 2 dias", "evento": "Pediu proposta com valores para 12 agendas" },
      { "quando": "ontem", "evento": "Perguntou o prazo de implantação e se integra ao sistema da clínica" }
    ]
  },
  "questions": {
    "estagio_relacionamento": {
      "type": "choice",
      "instructions": "Considerando a linha do tempo, qual é o estágio atual de relacionamento deste lead?",
      "criteria": {
        "ativo": "Interações recentes e recorrentes, iniciadas pelo lead.",
        "passivo": "Poucas interações, esporádicas.",
        "inativo": "Recebe mensagens recentes, mas não responde.",
        "adormecido": "Sem interação há um período prolongado.",
        "evidencia_insuficiente": "O histórico não permite decidir."
      }
    },
    "engajamento": {
      "type": "score",
      "instructions": "Qual é o nível de engajamento demonstrado? Considere frequência, variedade e recência.",
      "criteria": {
        "0": "Nenhuma interação relevante.",
        "1": "Uma interação isolada ou antiga.",
        "2": "Algumas interações, irregulares.",
        "3": "Interações recorrentes, sobre mais de um assunto.",
        "4": "Interações frequentes, recentes e consistentes."
      }
    },
    "intencao_comercial": {
      "type": "noul",
      "instructions": "O histórico mostra sinais consistentes de intenção de compra? Uma leitura isolada de mensagem não conta.",
      "criteria": "Pedido de proposta, pergunta sobre prazo, preço ou integração, ou mais de um clique em material comercial."
    }
  }
}

The response returns the structure that the JEV API uses. The values ​​below are illustrative, but the format is the actual one.

{
  "model": "jev-1.13.0",
  "answers": {
    "estagio_relacionamento": {
      "type": "choice",
      "choice": "ativo",
      "confidence": 0.91,
      "probabilities": { "ativo": 0.91, "passivo": 0.05, "inativo": 0.02, "adormecido": 0.01, "evidencia_insuficiente": 0.01 }
    },
    "engajamento": {
      "type": "score",
      "score": 3.62,
      "confidence": 0.71,
      "probabilities": { "0": 0.00, "1": 0.01, "2": 0.04, "3": 0.28, "4": 0.67 }
    },
    "intencao_comercial": { "type": "noul", "noul": 0.94 }
  },
  "usage": { "input_tokens": 1180, "output_tokens": 0 }
}

There is no text to interpret. What exists is a set of numbers, and from them the decision rule resides in the code, where it can be read, tested, and versioned. That's how the integration of... Bytebio write in Kommo:

JEV's response What happens on the card of Kommo
"Active" stage with confidence 0,91 The "Relationship Stage" field is marked as Active.
Engagement 3,62 on a scale of 0 to 4 The "Engagement Score" field receives a score of 90, on the company's scale of 0 to 100.
Commercial intent at 0,94 Label "purchase intent", card advances to Proposal, task for the salesperson with a one-hour deadline.
Any question with a confidence level below 0,5 The card doesn't change; the conversation enters the human review queue with the justification.

The thresholds are set by the company, not the model. TypeSafe's guidance is to start conservatively and adjust with real data, scaling accordingly: moving a card requires less certainty than discarding a lead, and discarding a lead requires less certainty than promising a discount.

Numbers

There are two sets of numbers to look at: those published by TypeSafe and those from an independent test.

What TypeSafe publishes. The pricing, templates page , and sample recipes provide verifiable measurements.

Size Price Pig iron
entry price US$0,042 per million tokens; no exit fee. Models
13 questions in one call, versus 13 separate calls. 12,2 times cheaper and 10 times faster: 0,27 s versus 2,71 s Recipe for parallel questions
Classification into 75 groups, with a shift to the broadest category when confidence falls. Useful answers increase from 65% to 80%; above 0,9 confidence, 90% accuracy. Trust-based rating recipe
Limit per request 64 tokens, with 32 for the state plus the biggest question Models

On its homepage, TypeSafe also claims that the JEV is 193,6 times faster and 244,6 times cheaper than generative models in tasks of this type. This is a claim from the manufacturer, without any published methodology on the same page, and therefore it is recorded as a claim.

The independent test. The numbers below come from a test presented in a lecture by an automation expert, who sent the same contact history (approximately 18 timeline tokens) to the JEV and to two generative models, within an n8n flow, with the same structured classification request. The names of the generative models are those used in the presentation.

Volume of analyses JEV 1.13 GPT-5.6 Luna GPT-4.1 Mini
1.000 US$ 1,12 US$ 6,21 US$ 8,70
10.000 US$ 11,17 US$ 62,09 US$ 87,01
100.000 US$ 111,74 US$ 620,89 US$ 870,12

The response time for generative methods ranged from 3 to 5 seconds to generate and validate the JSON. JEV responded in a fraction of a second, allowing for synchronous calls within the flow, without queuing or waiting.

One detail from the test is worth noting: JEV counted more input tokens than generative tokens (26,6 versus 17,7), due to the way it ingests the state. Even so, it was about 82% cheaper per analysis because it doesn't charge for exit and charges for entry at a fraction of the price.

What these numbers mean in practice: analyzing one hundred thousand conversations or contacts per month now costs just over one hundred dollars. Continuous qualification of the entire database, which previously only fit within the budget of a large company, now fits within an operation with a salesperson and a CRM.

What JEV does not do

To prevent enthusiasm from turning into a failed pilot project, TypeSafe itself maintains a page outlining known limitations . The most important aspects of the CRM are:

  • He doesn't write. No customer response, summary, or proposal. This remains the case with the generative model.
  • He doesn't calculate. Counting messages, summing values, and comparing dates is the job of the code, before the question is asked. Ask "are there more than three clicks?" after the count has been done, not with the raw list.
  • He reads it literally. The instruction must specify what constitutes a signal and what does not. That is why the question of commercial intent above warns that a single reading does not count.
  • He gets distracted by the large and dirty state. Filtering the history before sending improves response time and reduces costs.
  • He doesn't suspect the text. Embedded instructions within a client message can influence the response, so the guardrail remains both code and process-related.

The practical conclusion is that the JEV does not replace the AI ​​agent. It takes away from the agent what the agent does poorly and expensively (deciding), and leaves with it what it does well (conversing).

How does it fit into the ecosystem of Bytebio

A Bytebio é Expert Partner of Kommo and maintains its own systems that integrate with the CRM: lead classification, scoring, field updates, labels, and stage movement. What JEV adds is a faster, cheaper, and more consistent decision engine in these areas. The architecture that... Bytebio The proposal has four layers.

  1. Channel and CRM. WhatsApp enters KommoEach card stores the conversation, its origin, and its fields. ByteCapture It ensures that the lead's origin is correct, which becomes one of the indicators in the evaluation.
  2. AI agent. O ByteGPT Or a Harnz agent speaks with the client, using the company's Truth Document as a normative source and escalating to a person when needed.
  3. Decision. For each relevant event, the Harnz It assembles the lead's status, queries the JEV, and receives the typed responses.
  4. Action in Kommo. Harnz's rules for Kommo They translate the response in the field, labeling, step, and task, always within the thresholds defined by the company, and return to the human queue what falls below the minimum confidence level.

Harnz is the key component that makes this production sustainable. Every question, every criterion, and every threshold is versioned; changes only go into effect with human approval and can be reverted; every decision is logged with the model's response and the action taken; and the cost per flow appears separately, which, with a model that charges cents per thousand analyses, ceases to be a concern and becomes an indicator. Harnz's test center allows you to run a batch of real conversations against a new set of questions before triggering any action in the CRM.

What Bytebio Delivery, in this respect, involves designing the questions with acceptance criteria, and integrating them into... Kommo, calibrating the thresholds with the company's actual data and providing support after it's running.

How to start the operation without stopping.

The path that Bytebio The process used to add a decision layer to CRM follows the same path as the other areas: diagnosis, architecture, phased implementation, and operation.

  1. Choosing a decision. One single line, with an owner and clear consequences. Prioritizing the service queue is a common starting point because it's a cheap mistake that pays off quickly.
  2. Write the questions and criteria. In plain Portuguese, outlining what counts and what doesn't at each level. This text is the business rule, and it's what Harnz versions.
  3. Calibrate with the actual data. Run through a few hundred leads that have already been qualified by people and compare them. That's where trust thresholds become numerically significant.
  4. Driving in the shade. The JEV decides, Harnz records it, and the card doesn't change. For a week or two, the team reviews the decisions in the log.
  5. Connect the actions, one at a time. First the field, then the label, then the step. Each with its own acceptance criteria and a prepared return path.
  6. Measure and adjust. Automated decision rate, human review rate, sample accuracy, and cost per lead. What the operation learns feeds back into the criteria.

None of these stages end in a pilot phase. Each one comes with a deliverable and acceptance criteria.

The conclusion that matters to the decision-maker.

The discussion about AI in CRM has been stuck in customer service for two years, and customer service is only one part of the sales process. The bigger part is the silent decision that happens with each message: who it goes to, with what priority, at what stage, with what label. Until now, this decision was too expensive and slow to be made by AI at each event, and therefore it was done once, at the beginning, and then abandoned.

A model that makes decisions in milliseconds and charges pennies per thousand analyses changes that equation. However, it doesn't change what makes the decision valid: written criteria, a defined threshold, a log of each action, approval for changes, and someone to respond when it breaks. Without that, a cheap model only produces errors faster.

Structure first. Automation later. The JEV solves the speed and cost of the decision. Bytebio It is responsible for the structure around it.

How Bytebio can help

A Bytebio It's an engineering house of Ribeirão PretoSince 2009, it has been putting AI, automation, and CRM into production within companies that depend on operations for revenue, and it is responsible for what it builds. Expert Partner of Kommo, creator of ByteGPT, winner of Kommo Partners Award 2024 for best local integration, and maintains the Harnz, the AI ​​control structure on WhatsApp, with versioning, change approval, full logging, and cost per flow.

If your operation already has CRM and an AI agent running, and qualification still depends on who read the conversation, talk to the BytebioWe begin with a brief diagnosis of the funnel and the decisions it requires, and we frankly state which ones are worth automating first.

Want to turn AI into real results?

Talk to our team about the challenges you're facing in your business.

Tell us about your challenge.
Talk on WhatsApp