JEV no CRM: a IA que decide em milissegundos, e o que muda no Kommo com a Bytebio

O que você vai encontrar neste artigo:

• Por que a IA generativa, tão boa em conversar, é lenta e cara quando o trabalho é decidir
• O que é o JEV, o modelo "System One" da TypeSafe AI, e o que ele devolve no lugar de texto
• As três perguntas que ele responde: escolha, nota e sim ou não, sempre com probabilidade e confiança
• Onde isso se aplica no CRM: qualificação, score, etiquetas, roteamento de etapa e fila de atendimento
• Uma demonstração com um lead do Kommo, do payload à ação no card
• Os números de custo e velocidade publicados pela TypeSafe e os de um teste independente
• O que o JEV não faz, e por que ele complementa o agente de IA em vez de substituí-lo
• Como fica no ecossistema da Bytebio: Kommo, Harnz, ByteGPT e ByteCapture

Quase toda empresa que usa CRM já colocou um modelo de linguagem em algum ponto do processo: um agente no WhatsApp, um resumo automático da conversa, uma classificação de lead disparada pelo n8n. E quase toda esbarrou no mesmo trio de problemas quando o volume cresceu. A resposta demora segundos, o custo por chamada acumula em escala, e o mesmo lead recebe classificações diferentes em dias diferentes.

Isso não é defeito dos modelos generativos. É desvio de função. Eles foram feitos para escrever, e a maior parte do trabalho de um CRM não é escrever. É decidir: este lead está quente ou frio, esta mensagem é dúvida de suporte ou intenção de compra, este card fica onde está ou avança de etapa.

Em setembro de 2026, uma empresa de São Francisco chamada TypeSafe AI colocou em acesso antecipado um modelo feito só para essa segunda tarefa. Ele se chama JEV, e vale entender o que muda.

O que é o JEV

A TypeSafe descreve o JEV como o primeiro modelo de uma classe nova, que ela chama de System One. O nome vem de Daniel Kahneman, em Rápido e Devagar: o Sistema 1 é o pensamento rápido e intuitivo, o Sistema 2 é o lento e deliberado. Um modelo generativo é Sistema 2: raciocina em texto, uma palavra depois da outra. O JEV é Sistema 1: recebe um estado (um texto, um JSON, uma lista de eventos), recebe uma ou mais perguntas tipadas, e devolve respostas que o código consome sem interpretar.

A diferença aparece logo no formato da resposta. Um modelo generativo, pedido para classificar um lead, devolve um texto que precisa ser lido, validado e, com alguma frequência, corrigido, porque ele escreveu "Olá, aqui está o JSON" antes do JSON. O JEV não gera texto. Ele devolve a opção escolhida, a probabilidade de cada opção e um número de confiança. É uma função, não um interlocutor.

A TypeSafe resume o posicionamento em três palavras: "decisions, not strings". Decisões, não textos.

As três perguntas que ele responde

Toda pergunta ao JEV é de um dos três tipos, e é isso que faz a saída ser previsível.

Dois detalhes importam para quem monta automação.

O primeiro é a confiança. Nas perguntas de escolha e de nota, ela mede o quanto a probabilidade está concentrada numa única resposta. Quando o modelo divide a probabilidade entre duas opções, a confiança cai, e a documentação recomenda usar isso como segundo eixo da decisão: a resposta diz o quê, a confiança diz se dá para agir sozinho. Alta, o código age. Média, o código pede confirmação ou marca para revisão. Baixa, uma pessoa decide.

O segundo é o lote. Várias perguntas vão na mesma requisição, cada uma avaliada de forma independente contra o mesmo estado, sem que a resposta de uma contamine a outra. Como o estado é enviado uma vez só, perguntar dez coisas custa pouco mais do que perguntar uma.

Determinismo não; consistência sim

A pergunta que todo engenheiro faz é se o JEV é determinístico. A resposta honesta, e a própria TypeSafe faz essa distinção, é que ele é consistente. Determinismo estrito seria devolver a mesma resposta idêntica para a mesma entrada idêntica. Consistência é tomar a mesma decisão quando o significado se mantém, mesmo que a frase mude.

Para quem já tentou classificar mensagens de WhatsApp, isso resolve um dilema antigo. Expressão regular é frágil demais: basta o cliente escrever "quero um orçamento" em vez de "quero proposta" e a regra falha. Modelo generativo é imprevisível demais: uma vírgula a mais no prompt muda o comportamento. O JEV fica no meio. Entende semântica como um modelo de linguagem e responde com a estrutura de uma função.

Em teste publicado pela TypeSafe com treze perguntas repetidas cinco vezes sobre o mesmo documento, a maioria das respostas não variou nada entre as rodadas.

Onde isso entra no CRM

Um modelo que decide rápido e barato muda o lugar da IA dentro do CRM. Em vez de ficar só no atendimento, ela vira a camada de decisão que roda em segundo plano, a cada evento, sem que ninguém precise perguntar nada. O mapa de casos de uso da TypeSafe lista, para vendas, exatamente o que uma operação comercial precisa: aderência ao perfil de cliente ideal, maturidade da empresa, dor, intenção de compra, priorização e roteamento.

Traduzido para o Kommo, com os sistemas que a Bytebio já integra ao CRM, fica assim.

Qualificação contínua do lead. A cada mensagem ou evento, o histórico inteiro do card (mensagens, cliques, tempo de resposta, origem) é avaliado e o campo de estágio de relacionamento é atualizado. Nada de qualificação feita uma vez na entrada e esquecida.

Score de engajamento. Uma nota numa escala definida pela empresa, com critério escrito para cada nível, gravada num campo numérico do card. O vendedor ordena a fila por esse campo em vez de pelo instinto.

Etiquetas de interesse. Uma pergunta de escolha por assunto (agendamento, integração com o ERP, atendimento com IA, preço) vira etiqueta no lead. A segmentação para campanha e para relatório passa a ter base no que o cliente disse, não no que o vendedor lembrou de anotar.

Intenção comercial contra dúvida de suporte. Um sim ou não que separa quem quer comprar de quem quer ajuda, e encaminha cada um para a fila certa antes que uma pessoa leia.

Roteamento de etapa. Quando a probabilidade de fechamento passa de um limiar, o card avança de etapa e o vendedor recebe uma tarefa. Quando cai, o card volta para nutrição.

Urgência e risco de perda. Em base ativa, o mesmo mecanismo lê sinais de esfriamento e abre uma tarefa de reativação antes de o cliente sumir.

Guardrail do agente de IA. Antes de o agente responder, uma pergunta de sim ou não confere se a mensagem pede algo fora do escopo ou traz dado sensível, e desvia para uma pessoa quando a resposta é sim.

O ponto comum é que em nenhum desses casos o JEV escreve nada para o cliente. Ele decide, e o CRM executa.

Demonstração: um lead do Kommo avaliado pelo JEV

O exemplo abaixo adapta ao Kommo a prova de conceito apresentada na palestra que motivou este artigo, feita originalmente em n8n com outro CRM. O fluxo é o mesmo: ler o card e a linha do tempo, montar o estado, perguntar, e escrever a resposta de volta no card.

O estado é um resumo do lead. Repare que ele já chega estruturado, porque o JEV avalia texto e JSON, e que a origem vem do rastreamento do ByteCapture.

{
  "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."
    }
  }
}

A resposta volta com a estrutura que a API do JEV usa. Os valores abaixo são ilustrativos, mas a forma é a real.

{
  "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 }
}

Não há texto para interpretar. O que existe é um conjunto de números, e a partir deles a regra de decisão fica no código, onde dá para ler, testar e versionar. É assim que a integração da Bytebio escreve no Kommo:

Os limiares são da empresa, não do modelo. A orientação da TypeSafe é começar conservador e ajustar com dados reais, e gradar por consequência: mover um card exige menos certeza do que descartar um lead, e descartar um lead exige menos do que prometer um desconto.

Os números

Há dois conjuntos de números para olhar: os que a TypeSafe publica e os de um teste independente.

O que a TypeSafe publica. O preço, a página de modelos e as receitas de exemplo trazem medidas verificáveis.

Na página inicial, a TypeSafe afirma ainda que o JEV é 193,6 vezes mais rápido e 244,6 vezes mais barato do que modelos generativos em tarefas deste tipo. É afirmação da fabricante, sem método publicado na mesma página, e por isso fica registrada como afirmação.

O teste independente. Os números abaixo vêm de um teste apresentado em palestra por um especialista em automação, que enviou o mesmo histórico de contato (cerca de 18 mil tokens de linha do tempo) para o JEV e para dois modelos generativos, dentro de um fluxo n8n, com o mesmo pedido de classificação estruturada. Os nomes dos modelos generativos são os usados na apresentação.

O tempo de resposta dos generativos ficou entre 3 e 5 segundos para gerar e validar o JSON. O JEV respondeu em fração de segundo, o que permite chamada síncrona dentro do fluxo, sem fila nem espera.

Um detalhe do teste vale a nota: o JEV contou mais tokens de entrada do que os generativos (26,6 mil contra 17,7 mil), pela forma como ingere o estado. Mesmo assim ficou cerca de 82% mais barato por análise, porque não cobra a saída e cobra a entrada por uma fração do preço.

O que esses números significam na prática: analisar cem mil conversas ou contatos por mês passa a custar pouco mais de cem dólares. Qualificação contínua de base inteira, que antes só cabia em orçamento de grande empresa, passa a caber numa operação com um vendedor e um CRM.

O que o JEV não faz

Para que o entusiasmo não vire piloto que quebra, a própria TypeSafe mantém uma página de limitações conhecidas. Os pontos que mais importam no CRM:

• Ele não escreve. Nada de resposta ao cliente, resumo ou proposta. Isso continua com o modelo generativo.
• Ele não calcula. Contar mensagens, somar valores e comparar datas é trabalho do código, antes da pergunta. Pergunte "há mais de três cliques?" já com a contagem feita, não com a lista bruta.
• Ele lê ao pé da letra. A instrução tem de dizer o que é sinal e o que não é. Foi por isso que a pergunta de intenção comercial acima avisa que uma leitura isolada não conta.
• Ele se distrai com estado grande e sujo. Filtrar o histórico antes de enviar melhora a resposta e reduz o custo.
• Ele não desconfia do texto. Instrução embutida numa mensagem de cliente pode influenciar a resposta, então o guardrail continua sendo de código e de processo.

A conclusão prática é que o JEV não substitui o agente de IA. Ele tira do agente o que o agente faz mal e caro (decidir), e deixa com ele o que faz bem (conversar).

Como fica no ecossistema da Bytebio

A Bytebio é Parceira Expert da Kommo e mantém sistemas próprios que se integram ao CRM: classificação de leads, score, atualização de campos, etiquetas e movimentação de etapa. O que o JEV acrescenta é um motor de decisão mais rápido, mais barato e mais consistente nesses pontos. A arquitetura que a Bytebio propõe tem quatro camadas.

1. Canal e CRM. O WhatsApp entra no Kommo, e cada card guarda a conversa, a origem e os campos. O ByteCapture garante que a origem do lead chegue certa, o que vira um dos sinais da avaliação.
2. Agente de IA. O ByteGPT ou um agente do Harnz conversa com o cliente, com o Documento Verdade da empresa como fonte normativa e escalonamento para uma pessoa quando precisa.
3. Decisão. A cada evento relevante, o Harnz monta o estado do lead, pergunta ao JEV e recebe as respostas tipadas.
4. Ação no Kommo. As regras do Harnz para o Kommo traduzem a resposta em campo, etiqueta, etapa e tarefa, sempre pelos limiares que a empresa definiu, e devolvem para a fila humana o que ficou abaixo da confiança mínima.

O Harnz é a peça que faz isso aguentar produção. Cada pergunta, cada critério e cada limiar é versionado; mudança só entra com aprovação humana e pode voltar atrás; toda decisão fica no log com a resposta do modelo e a ação tomada; e o custo por fluxo aparece separado, o que, com um modelo que cobra centavos por mil análises, deixa de ser preocupação e vira indicador. O centro de testes do Harnz permite rodar um lote de conversas reais contra um conjunto novo de perguntas antes de ligar qualquer ação no CRM.

O que a Bytebio entrega, nessa frente, é o desenho das perguntas com critério de aceite, a integração ao Kommo, a calibração dos limiares com a base real da empresa e a sustentação depois que roda.

Como começar sem parar a operação

O caminho que a Bytebio usa para colocar uma camada de decisão no CRM segue a mesma jornada das outras frentes: diagnóstico, arquitetura, implantação em etapas e operação.

1. Escolher uma decisão. Uma só, com dono e com consequência clara. Priorizar a fila de atendimento é um começo comum, porque erra barato e rende rápido.
2. Escrever as perguntas e os critérios. Em português claro, com o que conta e o que não conta em cada nível. Esse texto é a regra de negócio, e é ele que o Harnz versiona.
3. Calibrar com a base real. Rodar algumas centenas de leads já classificados por pessoas e comparar. É aí que os limiares de confiança ganham número.
4. Rodar em sombra. O JEV decide, o Harnz registra, e o card não muda. Por uma ou duas semanas o time confere as decisões no log.
5. Ligar as ações, uma por vez. Primeiro o campo, depois a etiqueta, depois a etapa. Cada uma com critério de aceite e com o caminho de volta pronto.
6. Medir e ajustar. Taxa de decisões automáticas, taxa de revisão humana, acerto na amostra e custo por lead. O que a operação aprende volta para os critérios.

Nenhuma dessas etapas termina em piloto. Cada uma entra com entregável e com critério de aceite.

A conclusão que interessa a quem decide

A discussão sobre IA no CRM passou dois anos presa no atendimento, e o atendimento é só uma parte do processo comercial. A parte maior é a decisão silenciosa que acontece a cada mensagem: para quem vai, com que prioridade, em que etapa, com que etiqueta. Até agora essa decisão era cara e lenta demais para ser feita por IA em cada evento, e por isso era feita uma vez, na entrada, e depois abandonada.

Um modelo que decide em milissegundos e cobra centavos por mil análises muda essa conta. Não muda, porém, o que faz a decisão valer: critério escrito, limiar definido, log de cada ação, aprovação para mudar e alguém que responde quando quebra. Sem isso, um modelo barato só produz erro mais rápido.

Estrutura primeiro. Automação depois. O JEV resolve a velocidade e o custo da decisão. A Bytebio responde pela estrutura em volta dela.

Como a Bytebio pode ajudar

A Bytebio é uma casa de engenharia de Ribeirão Preto, desde 2009, que coloca IA, automação e CRM em produção dentro de empresas que dependem da operação para faturar, e fica responsável pelo que constrói. É Parceira Expert da Kommo, criadora do ByteGPT, vencedor do Kommo Partners Award 2024 como melhor integração local, e mantém o Harnz, a estrutura de controle da IA no WhatsApp, com versionamento, aprovação de mudança, log completo e custo por fluxo.

Se a sua operação já tem CRM e agente de IA rodando e a qualificação ainda depende de quem leu a conversa, fale com a Bytebio. Começamos por um diagnóstico curto do funil e das decisões que ele exige, e dizemos com franqueza qual delas vale automatizar primeiro.