Como criar um harness com Jev | Uma conversa entre LangChain e TypeSafe

Autoria: LangChain · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: How To Build A Harness With Jev | A LangChain x TypeSafe Conversation · Canal: LangChain · 47:40 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Engenharia de prompts e contexto, Engenharia de software com IA, Modelos de IA

Resumo

Allie, da TypeSafe, explica que Jev é uma classe de System 1 models voltada a tomar decisões rápidas e tipadas, em vez de gerar texto como um LLM. A conversa apresenta três tipos de pergunta — choice, score e Noul — e mostra como integrar Jev a um agent harness para classificar ações arriscadas e encaminhar tarefas a modelos diferentes. Os participantes também discutem observabilidade, auditoria, calibração de probabilidades e a importância de definir com cuidado as instruções e o estado enviado ao modelo. Por fim, abordam casos de uso em tempo real, limites conhecidos de contexto e a necessidade de testar cada aplicação antes de colocá-la em produção.

Pontos-chave

Jev é um modelo de decisão, não um modelo generativo de texto nem um produto de uso final independente; ele é acessado por API e integrado a software.
System 1 models atendem a perguntas delimitadas que pessoas poderiam responder rapidamente, enquanto código e modelos de raciocínio podem compor decisões mais elaboradas.
Jev oferece três tipos de pergunta: choice para selecionar uma opção, score para avaliar um estado em um eixo e Noul para verificar se uma afirmação é verdadeira.
No agent harness, Jev pode classificar chamadas de ferramenta potencialmente destrutivas antes da execução e ajudar a escolher entre modelos rápidos ou mais capazes.
A integração com middleware e tracing permite inspecionar as chamadas ao Jev e acompanhar as decisões tomadas no fluxo do agente.
As instruções e os critérios usados por Jev devem ser claros, centralizados e fáceis de ajustar; auditar as chamadas ajuda a depurar o sistema.
Probabilidades e confidence precisam ser interpretadas de acordo com o caso de uso; confidence baixa nem sempre significa que uma decisão deve ser rejeitada.
Aplicações em tempo real, como filtragem de mensagens ao vivo e o demo de Doom, são possibilitadas pela velocidade e pelo baixo custo do modelo.
O estado enviado ao Jev deve conter apenas as informações necessárias; contextos muito grandes podem reduzir a precisão, por isso é importante testar e ajustar.

Capítulos

Início	Capítulo	Resumo
00:02	Abertura e apresentação dos convidados	A conversa começa com uma apresentação da LangSmith e dos participantes da LangChain e da TypeSafe.
03:20	O que é Jev e o conceito de System 1	Allie descreve Jev como um modelo de decisão rápida, distinto de modelos que geram texto.
07:35	Por que Jev é voltado a código	A conversa explica a motivação para usar um formato nativo de máquina em decisões entre sistemas.
11:54	Tipos de pergunta: choice, score e Noul	Allie apresenta os três formatos de decisão do Jev e explica como definir perguntas e critérios.
16:58	Jev em agentes e no agent harness	Os participantes discutem como incorporar Jev a aplicações com agentes sem tratá-lo como substituto direto de um LLM.
19:33	Demo: segurança de chamadas de ferramenta	Hunter demonstra como Jev pode identificar uma ação destrutiva e impedir sua execução automática.
23:17	Roteamento de modelos e observabilidade	A demonstração mostra Jev encaminhando tarefas a modelos diferentes e registrando as decisões em traces.
30:36	Limites de contexto e casos de uso	Allie esclarece os limites de contexto citados e fala sobre aplicações em tempo real e a evolução do produto.
37:50	Treinamento, thresholds e interpretação de confidence	A conversa aborda os dados de treinamento do Jev e como avaliar probabilidades e confidence para cada domínio.
43:31	Contextos longos e Model Jaggedness	Allie recomenda limitar o estado ao que é necessário e testar o efeito de entradas grandes na precisão.
47:09	Encerramento e comunidade	Os participantes encerram o webinar agradecendo aos convidados e convidando a comunidade a compartilhar projetos.

Citações

Jev não gera texto. — 03:20

São perguntas que você deveria poder apresentar a um painel de pessoas muito inteligentes, e elas responderiam em cinco segundos. — 05:55

Coloque todas as instruções e critérios em um lugar centralizado, que você possa ajustar facilmente. — 27:57

Teste seu domínio e seu caso de uso; não coloque Jev em produção às cegas. — 39:23

Você não deve simplesmente jogar o mundo inteiro para ele e pedir uma decisão sobre uma pequena parte. — 44:33

Conceitos e entidades

Jev (modelo): Modelo de decisão apresentado como uma opção rápida e de baixo custo para responder a perguntas delimitadas com saídas tipadas.
System 1 models (conceito): Modelos voltados a decisões rápidas e intuitivas, em contraste com processos de raciocínio em várias etapas.
System 2 thinking (conceito): Forma de pensamento que envolve raciocínio em várias etapas, conexões entre informações e composição de resultados.
agent harness (conceito): Estrutura que organiza o loop do agente e pode incorporar decisões auxiliares, como classificação de risco e roteamento de modelos.
LangChain (empresa): Empresa e projeto de código aberto que desenvolve ferramentas para criar agentes e integrar diferentes modelos.
TypeSafe (empresa): Empresa associada ao desenvolvimento de Jev e à criação de software com decisões tipadas.
LangSmith (ferramenta): Plataforma mencionada para visualizar traces, inspecionar decisões e avaliar aplicações com agentes.
choice (conceito): Tipo de pergunta do Jev que seleciona uma opção entre uma lista de alternativas.
score (conceito): Tipo de pergunta do Jev que classifica um estado ao longo de um único eixo definido por níveis.
Noul (conceito): Tipo de pergunta do Jev usado para verificar se uma afirmação é verdadeira.
Jevify (ferramenta): Skill citada na conversa que ajuda um coding agent a identificar decisões que poderiam usar Jev no lugar de um LLM.
Model Jaggedness (conceito): Página de documentação que registra limitações conhecidas do Jev, incluindo possíveis efeitos de contextos longos.
Allie (pessoa): Profissional de developer relations na TypeSafe que explica Jev e compartilha orientações de uso.
Hunter (pessoa): Líder técnico da equipe open source da LangChain que demonstra integrações do Jev com um agent harness.
Sydney (pessoa): Product manager da equipe open source da LangChain e parceira de Hunter no trabalho com Jev.

Tradução completa (pt-BR)

00:02 Agents são um novo tipo de software. Entradas infinitas e saídas não determinísticas. Construa-os do jeito antigo e eles quebram. Conheça a LangSmith, a plataforma de engenharia de agents. Ela é independente de modelo, de nuvem e de framework. As organizações que lançam os melhores agents iteram com um sistema, e chamamos esse sistema de ciclo de desenvolvimento de agents. Construir, testar, fazer deploy e monitorar. Você constrói com nossos frameworks open source.

00:35 Deep Agents, LangChain ou LangGraph. LangSmith Fleet permite que qualquer pessoa construa agents. Sem código. Teste agents usando evals e experimentos. Faça deploy das alterações com um clique usando o LangSmith deployment. Monitore cada interação em um único painel.

01:05 A governança está integrada a cada etapa do ciclo de desenvolvimento de agents, com o LLM Gateway da LangSmith. O LangSmith Engine ajuda você a aprimorar agents de forma autônoma e a avançar mais rapidamente pelo ciclo de desenvolvimento. O LangSmith Engine é seu agent para engenharia de agents.

01:44 - Pessoal, sejam bem-vindos. Estamos muito animados para começar este webinar sobre construir um harness com Jev, LangChain e TypeSafe. Então, primeiro quero apresentar nossos dois convidados de hoje: Allie, da TypeSafe, e Hunter, da LangChain. Vocês querem se apresentar? - Claro, oi, sou a Allie. Trabalho com relações com desenvolvedores na TypeSafe. Vocês veem meu nome por todo o nosso Discord.

02:15 Se vocês já estiveram por lá, vão me ver muito mais, com mais vídeos de demonstração e, de modo geral, por aqui ensinando as pessoas a usar TypeSafe, a pensar em TypeSafe e a pensar em modelos System 1 em geral. E estou muito animada por estar aqui. E eu sou o Hunter. Sou um dos líderes técnicos da equipe open source aqui na LangChain. Estou muito animado com Jev. Passei praticamente o tempo todo experimentando com ele nos fins de semana. É algo muito empolgante. E estou muito feliz por estar aqui e conversar com todo mundo.

02:49 - E eu sou a Sydney, gerente de produto da nossa equipe open source na LangChain e parceira próxima do Hunter em todo o nosso trabalho recente com Jev. Acho que todo mundo perdeu um pouco de sono na última semana experimentando e aprendendo tudo o que há para aprender sobre Jev, então estamos muito animados para conversar mais sobre isso hoje. Allie, talvez você possa começar. Você poderia explicar, em termos simples, o que é Jev? Por que todo mundo está tão animado com isso?

03:20 - Essa vai ser a pergunta mais difícil de responder durante toda a conversa: como explicar Jev em termos simples. Jev é uma classe de modelo completamente diferente daquela de que falamos na maior parte do tempo hoje, quando falamos de modelos: estamos falando de LLMs. Jev é diferente. Fundamentalmente, Jev não gera texto. Não é uma IA generativa nesse sentido, de criar texto ou imagens.

03:50 Jev serve para tomar decisões rápidas com base em perguntas de escopo bem definido, cada uma com schemas type-safe. Jev se encaixa no panorama geral da IA, em que, nos últimos dois anos, vimos um grande aumento no uso desses LLMs muito pesados para realizar o que, no fim das contas, é uma decisão pequena, como, por exemplo: para qual departamento este chamado de suporte deve ser encaminhado

04:20 ? Ou este e-mail é uma promoção, é spam ou é outra coisa? Ou esta chamada de ferramenta é segura, isto é, realiza alguma operação de escrita, coisas assim? Então, Jev é uma nova classe de modelo que chamamos de modelos System 1, e se encaixa nesse panorama. Outra coisa que sempre gosto de dizer, embora este seja um público da LangChain e talvez nem precisasse dizer, é que isso confunde algumas pessoas: Jev não é, desde o início, um produto para usuários finais. É um produto de API.

04:51 Ele não faz nada até que um programador, seja uma pessoa ou uma IA, o incorpore a um software. A primeira pergunta que aparece é: como faço para simplesmente apontar o OpenCode para Jev? E a resposta é: bem, é um pouco mais complicado do que isso. Você o usa dentro do seu software para criar o que gosto de chamar de software inteligente. Sim, acho que essa foi uma ótima explicação simples de Jev. Você mencionou que ele é chamado de modelo System 1. O que isso significa?

05:22 Isso vem de um livro chamado Thinking, Fast and Slow. Eu sempre esqueço o nome do autor, mas ele criou essa maneira de classificar duas formas diferentes de pensar. O pensamento System 1 é o lado rápido e intuitivo do pensamento. São determinações rápidas, enquanto o pensamento System 2 envolve raciocínio em várias etapas, certo? Você precisa pensar sobre uma coisa, combiná-la com outra, conectar os pontos e então obter uma resposta. Então, um modelo System 1, como Jev,

05:55 é um modelo rápido, baseado na intuição. Às vezes, gosto de descrevê-lo assim: as perguntas que você deve fazer a Jev devem ser perguntas que você poderia apresentar a um painel de pessoas superinteligentes, e elas conseguiriam responder em cinco segundos, certo? Não é algo em que você precise investigar e construir argumentos de raciocínio em várias etapas para entender a resposta. É muito, muito inteligente, mas as perguntas do tipo que envolvem pensamento System 1 são de outro tipo.

06:26 Elas são um subconjunto de todos os problemas que você pode encontrar no mundo. Sim, sim, é uma boa explicação. Você diria que os LLMs tradicionais se encaixam nesse pensamento System 2? É uma boa pergunta. Acho que, antes dos modelos de raciocínio, os LLMs eram, em geral, muito mais parecidos com o pensamento System 1, certo? Eles simplesmente respondiam rápido. Mas, naquela época, as respostas eram muito intuitivas e, muitas vezes, não eram confiáveis.

07:01 Agora, com o raciocínio, eu diria que muitas vezes isso é claramente pensamento System 2, certo? Quando você envia uma solicitação para um grande LLM de ponta, ele vai procurar informações, especialmente se estiver em um loop agentic, e vai estabelecer conexões para encontrar a resposta. Mas outra coisa que também costumo considerar pensamento System 2, muitas vezes integrado ao nosso System 1, é o seu código. O código, em grande parte, é pensamento System 2: é juntar peças e conectá-las,

07:35 compondo várias decisões System 1 para chegar a uma espécie de resposta final fundamentada. Sim, faz sentido. Você mencionou algumas vezes que Jev é muito útil quando você o incorpora ao código. Pode falar um pouco mais sobre os tipos de decisões que Jev consegue tomar bem no código e por que este é um modelo que prioriza o código? - Sim, vou começar pela parte final

08:05 da sua pergunta: por que ele é um modelo que prioriza o código? Muito disso vem simplesmente de observarmos o que é necessário no mundo, certo? Vemos o futuro e acho que provavelmente nem é controverso dizer que a grande maioria das automações no futuro será automação de máquina para máquina, certo? Será comunicação de máquina para máquina. Uma enorme parte da infraestrutura mundial já consiste em comunicação de máquina para máquina: APIs se comunicando por toda parte e um monte de coisas funcionando em conjunto, certo?

08:37 É assim que funciona a maior parte do nosso mundo digital: código se comunicando com outro código. Então, Jev, tanto o conceito de modelo System 1 quanto o próprio Jev dizem respeito a se encaixar nesse panorama. Nossos computadores já precisam se comunicar com outros computadores. Então, quando queremos trazer o incrível poder da IA, a inteligência que queremos acessar por meio desses modelos, por que ela não deveria começar em um formato nativo para máquinas?

09:10 Esse é o pensamento fundamental por trás do formato de Jev. Para expandir um pouco, há algum tempo gosto de desenvolver com LLMs e de incorporá-los a esses pontos de decisão. Antes de começar a trabalhar na TypeSafe e ver isso, eu os usava para muitas dessas coisas. Mas sempre havia uma inquietação no fundo da minha cabeça: isso não é absurdo? Não é completamente maluco que nós

09:40 tenhamos essa máquina grande, enorme e pesada — essa máquina de LLM — realizando uma quantidade enorme de computação para produzir linguagem humana, para produzir texto. E depois usamos isso para fazer chamadas de ferramentas ou invocar CLIs, por exemplo, que por sua vez são interfaces humanas. Uma CLI foi projetada para permitir que uma pessoa interaja com um sistema de computador de uma forma semântica e fácil de memorizar.

10:12 Mas, no fim das contas, ele transforma isso de volta em código de máquina bruto e segue fazendo o que precisa. Então, temos essa ponte estranha no meio, em que, para fazer um computador usar um computador [áudio cortado] [áudio cortado]

10:52 voltando à sensatez, à realidade de que, se é uma interação de máquina para máquina, não deveria haver um modelo gerador de prosa no meio, a menos que você precise gerar prosa para a saída. Tudo bem. Ainda há um espaço enorme para os LLMs em tudo isso, mas há muitos casos em que eles não deveriam estar. Sim. Acho que o Hunter compartilhou essa analogia recentemente. É mais ou menos como se, sabe, os LLMs tivessem se popularizado e a gente tivesse pensado:

11:23 “Nossa, isso é uma ferramenta tipo martelo. Tudo parece um prego, né? Vamos usar isso para tudo. Ela dá conta do recado.” Mas muitas vezes eles não se encaixam muito bem no código. Então, meio que criamos essas pontes improvisadas, como tool calling e saídas estruturadas, para permitir o uso de LLMs em aplicações orientadas por código. Especificamente, acho que as saídas estruturadas foram bastante transformadoras nos primórdios dos LLMs. Tipo, tudo bem, ele produzia texto e também algo

11:54 que seguia um esquema JSON. Mas, de novo, investindo muito além do necessário em computação. E isso aparece tanto no custo quanto na latência das respostas dos LLMs em muitas decisões que, eu diria, são bem simples. Então, tenho mais uma pergunta. O Jev tem, basicamente, três tipos de decisão que pode tomar, ou de perguntas que pode responder. Talvez você possa explicar cada um. Acho que tenho um slide aqui. Sim, você poderia falar um pouco sobre isso?

12:26 — Sim, isso é a manifestação concreta dessa comunicação de máquina para máquina, certo? A pergunta com tipos seguros. Quando você faz uma chamada ao Jev, fornece um estado como entrada. É o que está ali em cima: “Estou tentando conectar minha conta do Stripe há três dias”, certo? Então, o estado é aquilo que você está avaliando. Depois, você fornece um array de perguntas. Pode fornecer uma ou cem, mas cada pergunta é de um de três tipos.

12:57 Então, temos aqui a escolha, que serve para selecionar uma opção de uma lista. Neste exemplo, é algo como: “Qual equipe deve cuidar disso? Cobrança, suporte técnico ou vendas?”, certo? Ela funciona melhor quando há uma resposta claramente predominante e as opções não se sobrepõem muito. Mas, quando digo que funciona melhor, sempre há um zilhão de nuances e maneiras diferentes de falar sobre isso. E até a nossa documentação só arranha a superfície; estamos acrescentando mais informações à medida que aprendemos com a comunidade. Então, uma escolha é selecionar uma opção de uma lista.

13:28 É o análogo mais próximo do que as pessoas chamariam de classificador, certo? É simplesmente: “Qual destas opções corresponde a esta coisa?” Eu diria que escolha é provavelmente o tipo de pergunta que mais uso, talvez só fique atrás de Noul. A pontuação serve para avaliar o estado ao longo de um eixo. Você recebe de volta um valor de zero a N. Você define quantos níveis existem. Vamos imaginar que fosse de zero a quatro, certo?

13:59 Ou, na verdade, aqui está: temos de zero a dois — calmo, frustrado, muito irritado — neste exemplo. Então, você pergunta o quão frustrado o cliente parece estar. A pontuação serve para avaliar o estado em um único eixo de determinação. E isso é o mais importante que você precisa saber ao usá-la. Na verdade, isso vale para praticamente todas as nossas perguntas: você precisa decompor as perguntas até que não possam mais ser divididas. Certifique-se de não fazer uma pergunta composta.

14:29 Não coloque vários eixos de critérios diferentes em uma única pontuação. Se houver, de fato, dois eixos de informação, você deve usar duas pontuações. O grande poder da pontuação vem da forma como você define os níveis. Não dá para ver isso nesta visão geral rápida, mas cada um dos níveis — calmo, frustrado e muito irritado — é definido por uma descrição semântica do que significa. Neste caso, talvez diga apenas calmo, frustrado, muito irritado,

14:59 mas sempre funcionará melhor se você fornecer isso a ela. Você deve conseguir definir claramente o que significa um nível 1 na sua escala. E, de novo, é como entregar isso a um painel de pessoas, certo? A definição deve ser boa o bastante para que um painel de pessoas possa dizer: “O nível 1 está muito bem definido; o nível 2 está muito bem definido.” Isso significa que, quando você usa a mesma pergunta com os mesmos critérios para avaliar vários estados diferentes — talvez sejam documentos, mensagens de chat ao vivo ou muitas outras coisas —, pode confiar que as pontuações de 1, 1,5 ou 2 significam a mesma coisa. Como elas atendem aos mesmos critérios bem definidos, isso torna a escala muito mais poderosa. Pode ser uma linha de registro ou uma saída em um sistema de observabilidade.

15:33 você pode confiar que uma pontuação de 1, 1,5 ou 2 significa a mesma coisa em vários itens diferentes. Como eles atendem aos mesmos critérios bem definidos, isso torna a escala muito mais poderosa. Se você usasse apenas uma escala arbitrária, em que o nível zero fosse, sabe, calmo, e o nível 10 fosse muito irritado, sem descrições para os níveis intermediários, você pensaria: “Mas, afinal, o que é um 6? O que é um 7? O que é um 4? Dá mesmo para ter certeza de que isso tem uma descrição precisa?”

16:03 Essa é a pontuação. E a última é Noul. Noul é, de certa forma, a mais simples. Ela consiste apenas em perguntar se a resposta a uma pergunta é “sim” ou se a afirmação é verdadeira. Você faz uma pergunta simples e direta, como: “A mensagem transmite urgência ou é sensível ao tempo?” Sempre há um pequeno sinal de alerta quando você coloca um “ou” numa Noul, porque isso levanta a questão: será que ela está perguntando

16:58 algo que admite uma resposta booleana, mas não é um estado binário. É contínuo, de zero a um. — Legal. Sim, acabei de ver a coisa de Bernoulli antes disso, mas gostei mais da sua abordagem. Na LangChain, pensamos muito em como ajudar as pessoas a criar agents. E um dos nossos principais pilares fundamentais na LangChain é que queremos ajudar as pessoas a criar agents com qualquer modelo, certo? O modelo adequado para uma tarefa

17:29 não será adequado para outra. Além disso, sabe, surgem modelos novos toda semana, e eles são bons em coisas diferentes. Então, ficamos muito animados com o lançamento do Jev e com a possibilidade de ajudar as pessoas a criar agents com ele. Hunter, talvez você possa falar um pouco mais sobre isso. É uma pergunta com duas partes, mas como vemos o Jev se encaixando nos agents e como você pode incorporá-lo ao harness do seu agent? Também posso deixar você compartilhar a tela, se quiser. — Sim, preparei uma demonstração,

17:59 que acho que posso usar para explicar melhor do que só com palavras. Mas, sim, na LangChain, temos conversado bastante sobre o que torna um agent harness bom e como obter a saída mais útil de um modelo. Geralmente, interagimos com isso por meio de algum harness opinativo para o agent loop, entre outras coisas, simplesmente porque é assim que as outras pessoas também interagem com os modelos. Desenvolvemos muitas opiniões sobre como queremos que isso funcione da melhor maneira.

18:30 Quando o Jev foi lançado, inicialmente pensamos que havia alguns problemas muito interessantes que poderíamos resolver diretamente dentro do harness. É só fazer isso: há perguntas que queremos ver respondidas, mas não há uma maneira muito boa de fazer isso. Se usássemos LLMs para tomar decisões por nós a cada etapa, ficaria muito caro e demorado. Isso traz uma série de complicações. Então, deixem torcer por mim.

19:02 Eu sei que demonstrações ao vivo são uma maldição, mas vamos tentar mesmo assim. Vamos ver. Então… Só… Ah, pode falar. Sim, você… algo que eu quero dizer… Eu posso… Eu ia começar outra demonstração, mas… Sim, eu só ia acrescentar um pouco de contexto: pensamos no loop básico de um agent mais ou menos assim: enviar uma solicitação a um modelo, mais especificamente, a um LLM. E então o LLM pode raciocinar e chamar ferramentas

19:33 e continuar nesse loop de tool calling até decidir que terminou uma determinada tarefa. E, como a Allie mencionou, não dá simplesmente para conectar o Jev no lugar de um LLM, como substituto direto. Não é assim que o Jev foi projetado, tanto em termos de funcionalidades quanto de API. Mas, sim, o Hunter vai explicar como pensamos em integrá-lo ao agent harness, porque ele ainda é muito útil em aplicações agênticas. — Sim, especificamente para o agent harness, há alguns pontos. Se você já usou o codex ou o Claude code,

20:05 ou algo parecido, talvez tenha notado que, quando ele executa determinadas ações, geralmente as classifica como arriscadas. Acho que todo mundo já ouviu o caso clássico em que um agent apaga um banco de dados de produção e, de repente, tudo pega fogo, e temos que culpar o LLM por isso. O que Claude e Codex adotaram bem cedo foi algum tipo de etapa de classificação. Isso ficava abstraído no harness e na forma como eles o implementavam, para classificar se uma decisão era arriscada ou não.

20:37 Agora, com o Jev, como ele é tão barato e custa tão pouco, podemos usar um paradigma muito parecido diretamente no agent harness. Então, este exemplo básico que tenho aqui — e este é um código bem LangChain Forward, se vocês conhecem — vocês podem consultar nossa documentação. Acho que há muitos conceitos aqui. Também podemos conversar sobre eles separadamente, mas, sim, só quero… Então, começando do início ao fim, temos estas duas ferramentas aqui. Dá para ver que estamos atualizando alguma coisa no CRM,

21:10 ou excluindo a conta de um cliente. Podemos classificar isso como uma ação bastante destrutiva. Em geral, queremos uma intenção explícita antes que isso aconteça. Não queremos que um agent faça isso automaticamente. Para adicionar isso ao agent, os agents do LangChain têm essa noção de middleware, que basicamente nos permite escolher o que fazer em diferentes pontos do loop e organizar o contexto de diferentes maneiras. Então, com o LangChain TypeSafe, se vocês instalarem o LangChain TypeSafe, podem usar isso diretamente.

21:41 Especifico o middleware do modo automático. Isso significa que, no Claude e no Codex, esse tipo de comportamento é chamado de modo automático. Especificamos algumas ferramentas, as duas que temos aqui em cima. Especificamos algumas instruções para dizer se a ação será perigosa ou não. Definimos alguns dos critérios que a Allie mencionou, que determinam quando queremos que essas ferramentas sejam rejeitadas ou não. Agora, deixa eu executar isso rapidinho. Se eu executar isto aqui, o resultado é bastante seguro.

22:14 Cliente, sim, C123, adicione as notas internas. São ações bastante seguras, podemos executar. Sim, certo, nota adicionada ao CRM. Não houve problema, o status foi de sucesso. Se fizermos algo como uma chamada destrutiva, por exemplo, se eu disser: “Quero excluir este cliente, não quero confirmação”, e executar isso, então, neste ponto, o Jev, logo antes de a chamada da ferramenta ser feita,

22:46 vai decidir se é arriscado ou não, de acordo com os critérios que temos aqui em cima. E então, status de erro: sim, foi classificado como arriscado, então não queríamos executar a ferramenta. Então, perdemos… — É só que… — Na tela compartilhada, aliás. — Desculpa por isso. — Foi agora mesmo. — Beleza. Sim, enfim, dá para ver que deu erro. Foi classificado como arriscado, então não executamos.

23:17 Outro caso de que gostamos — sim, isso é bem empolgante porque, antes, para fazer isso, tínhamos que fazer outra chamada a um LLM, o que era bem caro. Também havia muita latência, porque o modelo precisava raciocinar sobre a chamada da ferramenta e, sim, sim, a implementação era bem ingênua. Mas, com o Jev, fica muito mais simples. Um segundo caso que adotamos quase imediatamente foi essa ideia de roteamento de modelos. Sei que alguns modelos são bons para certas tarefas.

23:48 Não quero usar o Astra em todas as tarefas possíveis. Então, podemos especificar um modelo rápido ou um modelo mais aprofundado. É muito parecido com o exemplo anterior; este é outro middleware que você pode exportar de… >> Perdemos o compartilhamento de tela de novo. >> Interessante. >> Estou só acompanhando o chat. >> Sim. Não, agradeço. Agradeço. Vamos tentar isto. Talvez funcione um pouco melhor.

24:19 Está funcionando? >> Sim. Estamos vendo. >> Legal. Sim. Especifique o roteador da mesma forma. Sim, especifique as instruções para indicar quando devemos usar modelos diferentes. Vamos tentar executar isso mais uma vez. Posso executar isto: “reescreva”, uma construção bem básica. Vamos usar um modelo de fronteira barato para isso. Sim, ele selecionou a rota rápida.

24:50 Então, dá para ver que ele optou por usar o Luna neste caso específico. O Jev tomou essa decisão, e por isso foi muito rápido. Também podemos fazer este aqui. Provavelmente vai demorar um pouco, porque o Sol vai lá e faz as coisas dele, mas, quero dizer, dá para deduzir isso. Vai levar um tempo para executar. Isso significa que, sabe, vamos escolher este caminho. E outra coisa interessante que vem disso é que, com isso, como estamos usando este middleware,

25:20 temos rastreamento do sistema pronto para usar. Então, podemos ver exatamente o que está acontecendo. Podemos ver todas as decisões que ele está tomando. Acho que este é um dos… sim, este era o middleware de roteamento de modelos que vimos. Se eu olhar aqui, posso ver que, antes de o agent executar — é isso que a etapa “before agent” faz —, estamos fazendo uma chamada de classificação ao Jev e determinando qual é a saída. Então, passamos alguns detalhes sobre os diferentes modelos

25:52 que o Jev pode escolher, passamos parte do estado com a consulta inicial e coisas assim. E então, na saída, podemos ver que aparece “fast”, o que significa que optamos por usar o Luna neste caso. — E uma coisa interessante que o Hunter está mostrando aqui é que, com LLMs, acho que é bastante sabido que você quer ter observabilidade do que eles estão fazendo, certo? LLMs são meio que uma caixa-preta. Você quer conseguir descobrir quais foram minhas entradas? Quais foram minhas saídas?

26:22 Posso avaliar? Como… avaliar o desempenho das minhas aplicações agênticas e mudar a configuração do meu agent para que ele tenha um desempenho melhor. A observabilidade e as evals ainda são muito importantes, mesmo para essa classe de modelos de decisão, como o Jev. E o LangSmith é uma ótima maneira de visualizar o estado e a saída de estado, e avaliar o desempenho para seus casos de uso. — Sim. — Então, gostei muito de você ter mostrado essa observabilidade

26:54 porque uma das principais dicas que dou às pessoas quando começam a desenvolver com o Jev é: seja qual for o sistema em que você esteja, crie uma forma de auditar as chamadas feitas ao TypeSafe. Porque o mais provável, especialmente se você começar com vibe coding — que é como muita gente está fazendo —, é que os modelos disponíveis sejam bastante bons em entender como pensar sobre questões de System 1

27:26 e combiná-las. Descobrimos que, em geral, eles não são muito bons em escrever as instruções e os critérios propriamente ditos. Achamos que isso vai melhorar com o tempo, à medida que forem treinados com mais projetos que usam o Jev e modelos System 1. Mas gosto de dar duas dicas: primeiro, garanta que você tenha uma forma de inspecionar todas as chamadas feitas ao Jev, para poder examinar as respostas enquanto depura e descobre o que está funcionando. E, segundo, tem uma coisa de que me esqueci.

27:57 Ah, especialmente se você estiver fazendo vibe coding, peça ao seu agent para colocar todo o texto, todas as instruções, os critérios, qualquer coisa que esteja sendo fornecida a eles em um único lugar centralizado, ou em algum lugar onde você possa entrar e ajustar tudo facilmente. Porque, se nada mais no seu código receber um toque humano e você não abrir nenhum outro arquivo de código, vai querer olhar para esse. Porque dá para obter um ganho enorme de desempenho — por exemplo, aumentar a precisão — só pegando algumas perguntas

28:29 que às vezes são formuladas muito mal e simplesmente tornando-as mais sensatas. — Sim, obrigado pela demonstração, Hunter, e pelas dicas, Allie. Acho que este é um tipo de modelo muito novo, então todo mundo vai precisar aprender aos poucos como desenvolver melhor com ele. Um recurso interessante que encontrei se chama Jevify. É basicamente uma skill. Vou colar o link no chat. E isso é um prompt que você pode dar a um coding agent para ajudar a examinar e analisar o código do seu agent

29:03 e descobrir, por exemplo, onde estou usando um LLM para tomar decisões que seriam muito melhores com um decision model e como podemos integrar isso? Como podemos arquitetar isso para economizar em latência e custo? E também, o que é importante, em que situações um LLM é a ferramenta certa? E, nesse caso, precisamos deixar isso como está. Estou muito animado com isso. Acho que seria ótimo se pudéssemos… — Vi esse projeto específico e adorei. Queríamos, se tivéssemos tido mais tempo antes do lançamento, conversamos bastante sobre criar

29:33 uma skill de brainstorming, que basicamente é exatamente o que essa pessoa criou. Porque muitas vezes há melhorias fáceis de implementar, especialmente em um software integrado a um LLM. Geralmente há melhorias fáceis para o Jev substituir, e depois algumas coisas menos óbvias. Então, essa skill Jevify é muito legal. Tem mais uma coisa que posso mostrar? Porque fiz algumas promessas, e isso chegou literalmente cinco minutos atrás ao LangSmith. Só quero, desculpa interromper rapidinho,

30:04 mas isso é o que eu adoro em trabalhar em startups: conseguimos lançar coisas muito rápido. Agora temos uma renderização melhor, então você pode entrar e realmente interpretar algumas das coisas que estão dentro do seu trace do LangSmith. Antes, vocês viram que estava bem feio [o áudio falha] >> Sim, esses estão funcionando no LinkedIn.

30:36 Ótimo. Bem, vamos reservar um tempo no final para perguntas da comunidade, mas, Allie, primeiro temos algumas perguntas para você, tanto as que vimos no Twitter quanto algumas internas, dos usuários avançados do Jev na LangChain. Uma coisa que gostaríamos de saber: acredito que o tamanho do context window do Jev é de 32K tokens no momento. Está correto? É basicamente isso, mas é um pouco complicado. São 32K para o estado mais a sua pergunta mais longa.

31:11 Então, imagine que o estado e a pergunta juntos somem 32K; depois, há um limite de cerca de 64K para o estado mais todas as perguntas juntas. É aí que você precisaria dividir isso em várias chamadas. — Certo, legal. Vocês têm planos de aumentar esse context window ou oferecer suporte a outros tipos de conteúdo, como multimodalidade? Como é o roadmap nessa área? — Nossa resposta oficial à pergunta “oferecemos suporte a imagens?” é “ainda não”, sem dar mais detalhes sobre essa promessa vaga

31:45 E eu daria a mesma resposta a coisas como aumentar o context window. Também queremos ficar mais rápidos e mais baratos — isto é só o começo. E, se você ler a publicação do lançamento no nosso site, escrita por Diogo, ela realmente explica em que ponto estamos. Vemos isso como o início dessa revolução que queremos ajudar a impulsionar. Então, sim, esperamos melhorar em todos os aspectos. Mas não vou dar detalhes específicos

32:18 nem fazer promessas sobre prazos ou qualquer coisa assim. Mas acompanhem a gente, porque estamos avançando rápido. — Sim, sim, ótimo. Também vi que Diogo publicou um conteúdo interessante, acho que ontem, sobre como pensar no Jev para coding agents e como ele pode se integrar a algumas dessas partes. Parece que alguns casos de uso interessantes destacados foram relacionados à divulgação progressiva e à seleção de ferramentas. E também RLMs e code mode pareceram

32:51 um caso interessante. Há outros casos de uso realmente convincentes que você tenha visto, ou algum uso do Jev em produção que seria interessante as pessoas conhecerem? É tão amplo o que as pessoas estão fazendo, e elas estão avançando tão rápido. Dá vontade de dizer: “Deixa eu abrir meu feed do Twitter e ver as dez principais publicações”. Aposto que todas elas vão me deixar impressionado a esta altura, certo? E essa é a coisa mais empolgante sobre o momento em que estamos: sabíamos que a comunidade ia pegar muitas dessas coisas e sair usando.

33:24 E é isso que estamos vendo. Você já mencionou alguns dos casos que eu chamaria de melhorias fáceis de implementar, como usar o Jev para classificação de segurança de tool calls, roteamento de modelos, especialmente no início, quando você pensa: “Ah, essa pergunta geral exige isto, aquilo ou outra coisa?”. Meu maior entusiasmo pessoal é pelos projetos que vejo em casos de uso em tempo real,

33:57 em tempo real. E o tempo real foi um grande momento de descoberta para nós internamente, porque sempre dizíamos que sabíamos que éramos muito rápidos e muito baratos. Aí, de repente, tive uma epifania uma noite: “Espera, quando você é rápido e barato, isso viabiliza o tempo real”. Se algo é caro demais, tentar usar em tempo real se torna proibitivo. E, se é lento demais, simplesmente não dá para acompanhar o tempo real. Para mim, tempo real significa, por exemplo, filtrar o chat em tempo real. Fiz uma demonstração disso no início, mas acabamos não usando nas demonstrações do lançamento.

34:29 E agora as pessoas já criaram versões melhores de filtragem ao vivo de transmissões enormes da Twitch, com um fluxo de chat cheio de mensagens, muitas e muitas mensagens, em canais que chegam a ter cem mil espectadores, certo? Dá para filtrar tudo isso ao vivo, com um atraso de apenas cerca de 100 a 150 milissegundos para a mensagem aparecer; parece tempo real. Nem faz diferença. Há mais latência do que isso só para a Twitch exibir as mensagens, certo? Então dá para, dá para, dá para

35:00 como você pode atribuir uma pontuação às mensagens em um eixo, dá até para permitir que o usuário mova um controle deslizante para definir o quanto quer filtrar. Quer ver apenas as perguntas mais produtivas e interessantes ou quer todas as mensagens cheias de emojis, certo? E dá literalmente para girar um botão. É muito legal poder fazer isso. E, nessa chamada paralela, também dá para classificá-las como perguntas, afirmações ou mensagens de empolgação, tudo ao mesmo tempo, nos mesmos 100 milissegundos para cada mensagem, sem gastar uma fortuna.

35:32 Então, sim, tem muita coisa. Essa foi só a primeira que me veio à cabeça. — Fico feliz que você tenha mencionado o aspecto do tempo real, porque acho que, em uma das publicações do lançamento, vi a demonstração que vocês fizeram, em que o Jev jogou Doom em tempo real. Foi um daqueles momentos em que pensei: “Isso é incrível. Agora as coisas são tão baratas e rápidas que vão abrir todo um novo paradigma”. — Sim, esse era meu xodó. A demonstração de Doom foi minha coisa favorita para trabalhar nos últimos meses. — Legal, sim, fiquei impressionado.

36:04 Acho que muita gente ficou impressionada. Então, parabéns a você e a toda a equipe por terem criado isso. — Sim, concordo. Acho que o Twitter fez coisas incríveis com o Jev nos últimos seis dias, mais ou menos. Sinto que descubro um novo caso de uso a cada cinco minutos. Antes de passarmos às perguntas da comunidade, há outros itens interessantes do roadmap que você queira compartilhar? Sei que vocês querem ficar mais rápidos e mais baratos,

36:35 Obviamente, isso dá muito trabalho para a Neural Zen. — Não, eu diria que não especificamente, sabe? É algo para ficar de olho. Nunca se sabe o que vai acontecer na semana que vem, considerando a demanda incrível que tivemos. Certo, neste momento, estamos trabalhando para aumentar a capacidade e receber mais pessoas. Pelo menos no início, nossas inscrições continuaram pausadas enquanto administrávamos a demanda e garantíamos um serviço de alta qualidade

37:19 [áudio cortado] [áudio cortado] — Ah, não muito. Não muito. Tem sido uma loucura. E todo mundo está trabalhando muito, muito duro. Mas também há muitos sorrisos. Há tantos sorrisos por aqui, as pessoas estão animadas. A energia no escritório está eletrizante. — Incrível. Bem, então vamos passar a algumas perguntas do pessoal que está acompanhando o webinar.

37:50 a mais votada neste momento é: Jev foi treinado com os mesmos dados que um LLM típico? — Então, é… desculpem, estou lendo minhas anotações sobre isso, porque não trabalho com isso; não sou uma pessoa de ML e não estou envolvida no treinamento em si e coisas do tipo. Usamos uma mistura de modelos pré-treinados para treinar o nosso. Os dados que usamos para treinar nosso modelo

38:22 são todos dados sintéticos criados internamente. E isso faz parte da nossa fórmula secreta. Mas o processo vai muito além do pós-treinamento. Há muita coisa que não podemos detalhar, porque também temos avanços importantes, o que é parte do motivo pelo qual conseguimos criar algo tão incrível. Então, por enquanto, vamos guardar um pouco dessa fórmula secreta. — Legal. Estou percebendo uma espécie de tema comum em

38:53 algumas dessas perguntas: como vocês ajustam a confiança ou as probabilidades definidas no código como limites? Por exemplo: se a confiança estiver acima de X, fazemos isto; ou, se a probabilidade estiver acima de X… Isso parece bastante específico do domínio. Como vocês pensam sobre isso? — Eu diria que é exatamente isso: depende do domínio. Acho que escrevemos em vários lugares, nas dicas da nossa documentação, algo como:

39:23 você deve testar no seu domínio, testar seus dados e seu caso de uso de verdade, para entender… Primeiro, certifique-se de que isso está dentro da distribuição; certifique-se de que Jev é adequado ao seu caso de uso. Não o coloque às cegas em produção sem testar. Mas é aí também que você deve observar quais são os limites. Sabe, se você perceber que está definindo um limite muito baixo, especialmente abaixo de 50% para Noul, isso quase certamente significa que há um problema e que este é um aspecto

39:54 em que nosso modelo é irregular: talvez ainda não sejamos bons nesse caso de uso específico. Ou talvez suas perguntas precisem de ajustes significativos. Então, é preciso testar. Também vou dizer que uma parte importante de usar Jev com eficácia é entender que os limites de confiança são apenas uma maneira de usar as probabilidades. Acho muito importante saber

40:25 que a confiança retornada pela nossa API é um cálculo estatístico feito sobre o mapa de probabilidades que você recebe. É um cálculo determinístico que você mesmo poderia fazer. Não é uma solução mágica. Ela representa, nos casos de uso mais comuns, eu acho, uma boa aproximação da confiança. Mas isso vale para os casos em que se espera uma única resposta dominante.

40:55 A confiança é, em grande parte, uma medida de quanto há discordância, de quão distribuído está o mapa de probabilidades. Você pode ter casos de uso em que realmente espera que duas ou três opções possíveis disputem a maior probabilidade. Nesse caso, sua confiança vai ser muito, muito, muito baixa, porque ela mede a confiança de que existe uma única resposta dominante. Mas, em alguns desses casos de uso, isso é normal e está tudo bem. Também percebo que os agentes de programação gostam muito de ver essa confiança e pensar:

41:25 “É, sempre devemos fazer algo diferente se a confiança for baixa.” Nem sempre é assim. Por exemplo, criei um carrinho de compras. Na verdade, a demonstração de Doom é um ótimo exemplo. A demonstração de Doom pergunta: para qual monstro devemos olhar em cada quadro? Para este monstro, para aquele, devemos olhar para aquele item, e assim por diante. Nenhuma dessas opções é do tipo: “Ah, sim, essa vai ter 100% e todas as outras vão ter 1%.” Não, não, não: na verdade, há várias opções boas. Então, simplesmente escolhemos a que ficou em primeiro lugar.

41:56 Você pode até fazer coisas mais sofisticadas, como acrescentar um pouco de decaimento para tornar mais estável a opção escolhida mais recentemente, exigindo uma mudança maior para trocá-la. Acho que esse é um padrão interessante para experimentar. Mas, se fizéssemos isso de maneira ingênua — e algumas das primeiras versões da inteligência da demonstração de Doom criadas com vibe coding usavam um bloqueio por confiança —, o agente pensava: “Ah, a confiança está baixa, então devo voltar a olhar para a frente ou algo assim.” Não, não, não, não, não, não. É um uso ruim da confiança, porque ela simplesmente não se aplica à situação

42:26 em que esperamos respostas concorrentes. Só queremos escolher a melhor. Esse é apenas um entre muitos exemplos possíveis de por que você não deve confiar cegamente que a confiança vai funcionar no seu caso de uso específico. É um atalho útil para muitos casos de uso simples, mas teste sempre, confira sempre e seja criativo. Há outras maneiras de calcular probabilidades. Às vezes, você só quer usar a probabilidade mais alta, o percentual bruto, como limite. Às vezes, pode usar a probabilidade mais alta menos a segunda mais alta, ou dividir a mais alta pela segunda maior, o que dá um resultado diferente. Todas essas são abordagens estatísticas diferentes

42:59 para lidar com isso. >> Sim, isso é muito interessante. Como exemplo pessoal, eu estava trabalhando em uma aplicação bem ingênua de Jev, usando-o apenas para me ajudar a adicionar rótulos a novas issues do GitHub, para automatizarmos mais a triagem. Fiquei intrigada com algumas das probabilidades e confianças que recebi em alguns resultados e pensei: “Preciso investigar melhor como interpretar isso corretamente para este caso de uso.” Eu, como desenvolvedora, é que preciso me calibrar.

43:31 Sim, acho que talvez dê tempo para mais uma pergunta. Esta me parece interessante. Diz: pelo que entendi, o limite de tokens de entrada de estado do Jev é de cerca de 32k, como conversamos. Há consequências de degradação da decisão em entradas grandes? Como devemos pensar nisso no caso de Jev? É uma ótima pergunta. Temos uma página na documentação chamada Irregularidades do modelo. Recomendo muito que vocês deem uma olhada.

44:02 Isso faz parte de um dos pilares da cultura da nossa empresa e da nossa marca: a honestidade. Não queremos dizer que Jev é melhor em algo do que realmente é, certo? Não temos uma cultura de prometer demais. Então, o artigo sobre irregularidades é uma lista das limitações conhecidas do modelo, das coisas em que sabemos que ele não se sai tão bem. E acredito — tenho lido tantas coisas recentemente que posso estar errada —, mas tenho quase certeza de que uma

44:33 das coisas mencionadas ali são contextos longos e o fato de que a precisão pode cair quando você fornece uma quantidade enorme de estado. Eu diria que a orientação é garantir que você só inclua no estado o que é realmente necessário para tomar a decisão. Você não deve simplesmente jogar o mundo inteiro para ele e pedir que tome uma decisão sobre uma parte que é só uma fatia minúscula daquilo. Mas, às vezes, você não tem outra opção, certo?

45:04 Às vezes, você realmente está avaliando algo grande e desestruturado, como uma parede de texto, e não consegue reduzir isso no código. É por isso que você tenta usar um modelo de IA para avaliar; nesse caso, itere nas perguntas, descubra o que funciona melhor e teste. Mas, em muitos casos, estamos construindo o estado a partir de vários dados que temos no código. Então, cabe ao designer do sistema — a você, como programador — considerar: essa parte é realmente necessária? Você precisa adicioná-la ao estado? Precisa adicionar isto ao estado?

45:34 Também é melhor e mais econômico não gastar mais tokens com algo de que você não precisa. Jev é tão barato que, na maioria das vezes, você pode simplesmente acrescentar mais e não se preocupar. Mas é bom prestar atenção ao que está incluindo e, com certeza, testar isso. Essa é uma questão importante. E, na demonstração de Doom, também experimentei bastante com o nível de detalhe a fornecer no estado. Em certo momento, eu tinha um array de ações recentes. Era tudo o que tinha acontecido recentemente, mas estava detalhado demais. Incluía cada bala que causava dano e coisas assim,

46:06 e isso ocupava uma parte enorme do estado. E fez a inteligência geral cair um pouco. Então pensei: “Tudo bem, devemos limpar isso. Esse nível de detalhe é meio inútil.” Dá para fazer bons ajustes nisso. Dito isso, tudo na página Model Jaggedness são coisas que achamos que podem melhorar ainda mais no futuro. Sim. Sim, valorizo muito essa transparência. E acho ótimo pensar, voltando às coisas do Jevify: onde devemos usar Jev? Onde não devemos? Ele não é a resposta para todos os casos de uso,

46:39 mas pode ser ótimo para alguns. E acho que é muito apropriado terminar esta conversa falando basicamente de engenharia de contexto para Jev. Já demos vários nomes para isso no passado. Na verdade, já fizemos webinars sobre engenharia de harness, engenharia de loop e sobre preencher o, sabe… Agora talvez estejamos falando de engenharia de Jev, mas acho que continua sendo importante pensar: ainda é um modelo; como podemos otimizar o que entra para otimizar o que sai?

47:09 E, com isso, só queria agradecer muito a Allie e Hunter por participarem deste webinar quase emergencial sobre como construir um harness com Jev. Estamos muito animados com o entusiasmo em torno do lançamento do Jev. Estamos bastante otimistas quanto ao uso dele e de outros decision models internamente. E, sim, muito obrigado por participarem. E obrigado a todos que acompanharam e fizeram boas perguntas. — Obrigado. E também vou aproveitar para divulgar nosso Discord. Queremos ver o que vocês estão criando. Queremos ver seus projetos legais. Se o Discord não for a sua praia,

47:40 vocês também podem publicar no X e marcar a gente. Isso também é legal, mas muita gente está mostrando coisas muito legais no nosso Discord, e vários dos nossos desenvolvedores também interagem com a comunidade por lá, então adoraríamos ver vocês por lá. Posso confirmar que o Discord é um lugar bem legal. Estou acompanhando por lá há um tempinho. Sim. Certo.

Transcrição original

[00:02] Agents are new kind of software. Endless inputs and not deterministic outputs. Build them the old way and they break. Enter LangSmith, the agent engineering platform. It’s model agnostic, cloud agnostic, and framework agnostic. Organizations shipping the best agents iterate with a system, and we call that system the agent development life cycle. Build, Test, Deploy, and Monitor. You build with our open source frameworks.

[00:35] Deep Agents, LangChain, or LangGraph. LangSmith Fleet enables anyone to build agents. Without code. Test agents using evals and experiments. Deploy changes in one click with LangSmith deployment. Monitor every interaction from a single dashboard.

[01:05] Governance is built into every stage of the agent development cycle, with LangSmith’s LLM Gateway. LangSmith Engine helps you improve agents autonomously and move through the development lifecycle more quickly. LangSmith Engine is your agent for agent engineering.

[01:44] - Folks, welcome. We are super excited to get started with this building a harness with Jev, LangChain and TypeSafe webinar. Yeah, so first I wanna introduce our two guests today. Allie from TypeSafe and Hunter from LangChain. Do you guys wanna introduce yourself? - Sure, hi, I am Allie. I am developer relations at TypeSafe. You see my name all around our Discord.

[02:15] If you’ve been in there and you’ll be seeing a lot more me and more demo videos and generally just out here teaching people how to use TypeSafe, how to think in TypeSafe, how to think about System 1 models in general. And yeah, super excited to be here. Yeah, and then I’m Hunter. I’m one of the technical leads on the open source team here at LangChain. Super excited about Jev. I’ve been pretty much nonstop experimenting with it over the weekends. Yeah, super exciting stuff. and I’m super glad to be here and talk to everybody.

[02:49] - And I’m Sydney, the product manager for our open source team at LangChain, close partner with Hunter on all of our recent Jev work. Yeah, I think everybody’s lost a little bit of sleep in the past week experimenting and yeah, learning all there is to learn about Jev, so we’re super excited to chat more about it today. Allie, maybe you could start, Could you kind of explain in simple terms, what is Jev? Why is everyone so excited about it?

[03:20] - That’s gonna be the hardest question to answer this entire time, is like how to explain Jev in simple terms. So Jev is an entirely different class of model from when we’re talking about, most of the time today when we’re talking about models, we’re talking about LLMs. And Jev is different from that. Fundamentally, Jev does not generate text. It is not a generative AI in that sense, where it is to create text or create images.

[03:50] Jev is about making fast decisions from specifically well-scoped questions with type safe schemas for each of them. So Jev fits into the overall picture of AI, where we’ve seen over the past couple of years a huge increase in using these very heavy LLMs to do what is ultimately like a tiny decision, like, oh, which department should this support ticket

[04:20] be routed to? Or is this email a promotion, or is it spam, or is it whatever? Or is this tool call like a safe tool call, like does it perform any right operations, stuff like that? And so, Jev is a new class of model that we call System 1 models, and it fits into that picture. Then the thing I always like to say, although this is a LangChain audience, so probably don’t need to say, but it does confuse some people. Jev is not an end-user product out of the gate. It is an API product.

[04:51] It does not do anything until a programmer, whether a meatspace programmer or an AI programmer, until it puts that into software. That’s the first question that comes up is, how do I just point OpenCode at Jev? And it’s like, well, it’s a little more complicated than that. Like you use it inside your software to make what I like to call smart software. Yeah, I think that was a great simple explanation of Jev. You mentioned it’s called a system one model. What does, what does that mean?

[05:22] So it comes from, and I always forget the author’s name, but there’s a book called Thinking, Fast and Slow. And, uh, and the author of that came up with this way of labeling like kind of two different ways of thinking. And system one thinking is the like, it’s the fast intuition side of thinking. It is quick determinations, where system two is like multi-step reasoning thinking, right? You have to think about this and put it together with that and connect the dots and then you have output. And so system one model, like Jev,

[05:55] is a fast intuition based model. It is about, I like to describe it sometimes to be like, The questions you should ask, Jev, you should be able to present it to a panel of super smart humans and they could answer in five seconds, right? It’s not a you have to dig through and make multi-step reasoning arguments to understand the output. It is very, very smart, but the system one thinking type of questions is a different type.

[06:26] It is a subset of all of the problems you might have in the world. Yeah, yeah, that’s a good explanation. Would you say that like traditional LLMs kind of fall into that like system two thinking? It’s a good question. I think before reasoning models, I think LLMs were much more like system one thinking in general, right? They would just kind of like answer quickly. But it was very intuitive and oftentimes like not trustworthy answer back in those days.

[07:01] Now with reasoning, I would call that like very much, oftentimes that is system two thinking, right? When you send off a request to like a big frontier LLM, right, it’s going and it’s like looking, especially if it’s in an agentic loop, it’s like looking things up, it is making connections in order to like, to find that. But what I also like to think of as like, the system two oftentimes, that is integrated with our system one is your code. Like code, a lot of code is the system two thinking, It is the putting pieces together, connecting them together,

[07:35] composing a bunch of system one decisions into a sort of reasoned final output. Yeah, that makes sense. You mentioned a couple of times, like, Jev is really helpful when you like embed it in code. Can you say a little bit more about like, what kinds of decisions Jev is good at making in code and kind of why it’s this like code first model. - Yeah, so I’ll start with the end of that

[08:05] where you talked about it, like why is it a code first model? And a lot of that just comes from us seeing what is needed in the world, right? We see the future, and I think this is probably not even, like, I bet it’s not controversial to say that like, the vast majority of automation in the future will be machine to machine automation, right? is machine to machine communication. Already a huge amount of the world’s infrastructure is machine to machine communication. Like API is talking all over the place and a whole bunch of things working together, right?

[08:37] So that’s how like most of our digital world works is code talking to other code. And so, Jev, like the system one model concept and Jev is about fitting into that picture. It is like we already need our computer to talk to another computer. So when we wanna bring the incredible power of AI, the intelligence that we want to access from these models, why shouldn’t it be a machine native format to begin with?

[09:10] And that is the foundational thinking behind why Jev is shaped the way it is. And to expand on it a little bit, I’ve for a while, I like developing with LLMs, I like putting LLMs into these decision points. Before I started working at TypeSafe and saw this, I was using it for a lot of those. But it always, there was always an itch in the back of my head that I thought, isn’t this absurd? Like, isn’t this completely zany that we are,

[09:40] we have this big, huge, heavy machine, this LLM machine that is doing a huge amount of computation to output human language, to output text. And then we use that to do tool calls or invoke CLIs, for example, which themselves, a CLI is a human interface. It was designed to allow a human to interact with a computer system in a way that’s semantic and that we can memorize.

[10:12] But ultimately it turns it back into just raw machine code and goes off and does its thing. So we’ve got this weird bridge in the middle where to get a computer to use a computer [audio drops out] [audio drops out]

[10:52] down into sanity, coming back into reality of if it’s machine to machine, there should be no prose-generating model in the middle of that, unless you need prose generated for your output. That’s fine. That’s still a huge place for LLMs to sit in all of this, but there’s a lot of places where it ought not to be. Yeah. I feel like, I think Hunter shared this analogy recently. It kind of feels like we, you know, LLMs became popularized and we were like,

[11:23] “Oh my gosh, like this is a hammer tool. Like everything looks like a nail, right? Like let’s just use this for everything. It can do a good enough job.” But often they don’t like fit super well in code. And so we kind of made these like tack on bridges, like tool calling and structured outputs to be able to support LLMs in code driven applications. Specifically the structured outputs, I think they were pretty transformative in the early LLM days. Like, okay, it produced text and then also something

[11:54] adhering to a JSON schema. But again, way over investing in the computation. And that shows both in the like cost and latency that we see from LLM responses for a lot of, I think pretty simple decisions. So one other question that I had, Jev has kind of three types of like decisions that it can make or questions. Maybe you could talk through those. I think I have a slide here. Yeah, could you talk through kind of these?

[12:26] - Yeah, so this is like, this is the actual manifestation of like that machine to machine communication, right? The type safe question. So when you do a call to Jev, you are giving it like a state as input. That’s what you got up there. The high I’ve been trying to connect my Stripe account for three days, right? So the state is like the thing that you are evaluating. And then you give it an array of questions. You can give it one, you can give it 100 of them, but each of the questions is one of three types.

[12:57] So we’ve got choice here, which is to pick one option from a list. So in this example, it’s like, oh, which team should handle this? Billing, technical or sales, right? So it’s like, it works best when there’s like going to be one dominant answer and the choices don’t have a huge amount of overlap, But when I say it works best, there’s always like a gazillion different like nuances and ways to talk about this. And we like, even our docs only scratched the surface and we’re like adding to it as we learn from the community. But so a choice is to pick one option from a list.

[13:28] It’s like, it’s the closest analog to like what people would call a classifier, right? It’s just like, which of these is this thing? And I would say choice is like probably the question type I use the most, like maybe second to Noul. Score is about rating the state along an axis. So you’re gonna get back a value from like zero to N. You define how many levels there are. Let’s just pretend we were doing zero to four, okay?

[13:59] So, or actually here we go. We got zero to two, calm, frustrated, very angry in this example here. So you’re saying how frustrated the customer appears. So score is all about rating the state on a single axis of determination. And that’s like the most important thing to know about it when using it. And it actually goes for kind of all of our questions is you really need to break down the questions to the point where they can’t be broken down anymore. Make sure you’re not asking a compound question.

[14:29] Don’t put multiple different like axes of criteria in a single score. You should do two scores if there are actually like two axes of information. So the huge power from score comes from the way that you define the levels. So we don’t see it here in this like quick overview, but the calm, frustrated and very angry, each of those is defined by semantic description of what those levels are. In this case, it might just say calm, frustrated, very angry,

[14:59] but it’ll always work best if you like give it, you should be able to like clearly define what a one means in your scale. And again, it’s like giving it to a panel of humans, right? It should be defined well that a panel of humans could be like, oh, one is very well-defined, two is very well-defined. And what that means is when you use that same question with the same criteria to evaluate a whole bunch of different states, maybe they’re a bunch of documents, maybe they’re live chat messages, there’s a whole bunch of different things. It could be log lines, output in an observability system.

[15:33] you can trust that if you got a score of like one or 1.5 or two across multiple different things that they mean the same thing, that like because they meet the same well-defined criteria, it makes it so much more powerful than just like a blind scale from like, if you just did like level zero is like, you know, calm and level 10 is very angry with no descriptions in the middle, you’d be like, well, what it actually is a six, what is a seven, what is a four? Like, can you really be sure that that has a firm description?

[16:03] So that’s score. And then the final one is Noul. Noul is kind of the simplest. It really is just asking if the answer to a question is yes, or if the statement is true. So you just ask like a simple straightforward thing, like the message conveys urgency or time sensitivity. There’s always like a little bit of a yellow flag if you’re putting an or in a Noul, ’cause that’s like, oh, is that actually asking

[16:58] like a Boolean answer, but it’s not a binary state. It is continuous from zero to one. - Nice. Yeah, I just saw the Bernoulli thing before this, but I like your take better. So at LangChain, we think a lot about, how can we help people build agents? And one of kind of our biggest foundational pillars at LangChain is like, we wanna help people build agents with any model, right? the model that’s right for one task

[17:29] is not gonna be right for another. And then also, you know, there are new models every week and these new models are good at different things. So we were very excited to see Jev come out and help support people building agents with Jev. Maybe Hunter, you could talk a little bit more. This is a bit of a two-prong question, but how do we see Jev fitting into agents and kind of how can you build it into your agent furnace? I can let you screen share as well as if you want. - Yeah, I got a little bit of a demo cooked up,

[17:59] which I think I can use to demonstrate better in words. But yeah, at LangChain, we’ve been talking a lot about what makes a good agent harness, how do we get the most useful output out of a model? Usually the way that we interface with that, just because that’s how other people interface with models is some kind of opinionated to harness the agent loop, that sort of thing. We develop a ton of opinions about how we want that best to look.

[18:30] When Jev first came out, we initially thought of it as there’s a couple of super interesting problems that we can solve directly inside of the harness. Just straight to do, there’s questions that we wanted answered, and not that great of a way to do it because if we threw LLMs to make decisions for us at every step, then gets very expensive, very lengthy. There’s just like a ton of complications that come with it. So let me and pray for me.

[19:02] I know that live demos are a curse, but we’re going to try it anyways. Let’s see. So– Just– Oh, go ahead. Yeah, do you– something I want to say I can– I was going to start another demo, but– Yeah, I was just going to say to add like a little bit of color, we think about the core kind of agent loop as like send a request to a model, an LLM to be specific. And then the LLM can kind of reason, call tools

[19:33] and do this like tool calling loop until it decides it’s done with a given task. And as Allie mentioned, like you can’t just plug in Jev for like an LLM as a direct substitute. That’s not the way that Jev is designed both in terms of its like functionality and API. But yeah, Hunter is gonna kind of cover how we think about plugging it into the harness because it is still very useful in agentic applications. - Yeah, for the agent harness specifically, there’s a couple of points. If you are anyone that’s used like codex or Claude code

[20:05] or something of that variety, you might notice that when it takes certain actions, it usually classifies it as risky. I think everybody’s heard the like pattern case where an agent goes and deletes a production database and then all of a sudden everything’s on fire and we have to blame the LLM for it. Sort of what Claude and Codex adopted pretty early was to have some kind of classification step. This was like abstracted away behind their harness and how they implemented it to classify if a decision was risky or not.

[20:37] Now with Jev just because it’s so cheap and inexpensive, we can leverage a very similar paradigm just in the agent harness. So this like basic example I have here, and this is very LangChain Forward code, if you guys are familiar. You can go look at our docs. I think there’s a lot of concepts here. We can chat about separately too, but yeah, just wanna, so like to go front to back, we have these two tools right here. You can see that we just are updating some thing in CRM,

[21:10] or we’re deleting a customer account. We can classify this as like a pretty destructive action. We usually want like some explicit intent before this happens. We don’t want an agent to just do this automatically. The way that we can add this into the agent, LangChain agents have this notion of middleware, which is basically just at different points in the loop, we can choose what to do and organize context in different ways. So with LangChain TypeSafe, this is something that if you go and install LangChain TypeSafe, you can take this straight to boot.

[21:41] I specify auto mode middleware. This is saying in Claude and Codex, this sort of behavior is called auto mode. We specify some tools, the two tools that we have up here. Specify some instructions saying if this action is going to be dangerous or not. We set some of those criteria that Allie mentioned, kind of went as the true and false of when we want these tools to be rejected or not. And then let me run this real quick. And then if I run this here, this is a pretty safe result.

[22:14] customer, yeah, C123, add the internal notes. Pretty safe actions, we can go ahead and run it. Yeah, okay, CRM note added. This was fine, the status was success. If we take something like a destructive call, if we say, I want to delete this customer, I don’t want confirmation, if I run this, Then at this point, Jev, right before the tool call gets made,

[22:46] is going to decide if it’s risky or not, according to the criteria that we have up here. And then status error, yep, it was classified as risky, so we didn’t wanna execute the tool. So we lost– - That’s just like– - In share, by the way. - Sorry about that. - It’s just a moment ago. - Cool. Yeah, anyways, you could see that it aired out. It was classified as risky, so we didn’t execute it.

[23:17] Another case that we like, so yeah, this is pretty exciting because before the way that we had to do this was make another LLM call, which was pretty expensive. It was like very latent just because model had to reason over the tool call and yeah, yeah, the implementation was pretty naive, but with Jev makes it a lot simpler. A second kind of case that we pretty immediately latched on to was this idea of model routing. So depending on the task, I know models are going to be good for certain things.

[23:48] I don’t want to slam Astra on every single task that’s possible. So we could specify a fast model or a more in-depth model. So very similar before, this is another middleware that you can export from. >> We lost your screen sharing again. >> Interesting. >> I’m just being the chat. >> Yeah. No, I appreciate it. I appreciate it. Let’s try this. This might be a little bit better.

[24:19] Does that work? >> Yeah. We got it. >> Cool. Yeah. Specify the router in the same way. Yeah, it’s specified the instructions for when we should use different models. We’re going to try running this one more time. So I can run this, rewrite, like super basic construction. We’re going to use a cheap frontier model for it. Yep, it selected the fast route.

[24:50] So you can see that it’s opted to use Luna for this specific case. Jev made that decision and it was super fast because of it. We can also do this one. This is probably going to take a while because Sol’s going to go and do Sol things, but I mean, it’s like, yeah, we can intuit that. like it’s gonna take a while to execute. That means that, you know, so we’ll pick this path. And the other interesting thing to come out of this is with this, we can, because we’re using this middleware,

[25:20] we get tracing into the system out of the box. So we can see exactly what’s happening. We can see all the decisions it’s making. I think this is one of the, yeah, so this was the model router middleware that we saw. So I look in, I can see that before the agent runs, that’s what this before agent thing is doing. We’re running a classifier call against Jev and determining what the output is. So we pass in some details about the different models

[25:52] that Jev can choose from, pass in some of the state with the initial query and things like that. And then in the output, we can see that it shows fast, which means that we opted to use Luna for this case. - And one interesting thing that Hunter is showcasing here is like, you know, with LLMs, I think it’s pretty common knowledge that you want kind of observability into what they’re doing, right? Like LLMs are sort of a black box. You want to be able to tell, you know, what were my inputs? What were my outputs?

[26:22] Can I score? How, you know, evaluate how my agentic applications are doing and, you know, change my configuration for my agent to make it perform better and observability and evals are still like very important for even though like decision model class that Jev is. And so LangSmith is one great way to kind of visualize your state and state out and score how that’s doing for your use cases. - Yep. - So I really like you showing that observability

[26:54] because one of the like top tips that I give to people when they start building with Jev is to, like no matter what system you’re in, build a way to get auditability of the actual TypeSafe calls. Because the most likely, especially if you’re like vibe coding to start, which a lot of people that’s like how they’re doing it, the models out there are pretty good at like understanding how to think about like system one

[27:26] questions and kind of like compose them together. We have found that they are not typically very good at actually writing the instructions and the criteria. We think that’ll get better with time as they become more trained on more projects that use like Jev and System 1 models. But I like to give two tips, which is like make sure that you have a way that you can like inspect all of the calls that happen to Jev so you can like look at what the answers are like as you’re debugging and figuring out like what’s working. And then the second is something that I forgot.

[27:57] Oh, especially if you’re vibe coding, tell your agent to put all of the copy, all of the instructions, criteria, anything that’s being fed into those into one centralized place, or someplace that you can easily go in and tweak it. ’Cause that’s gonna be, if nothing else gets a human touch in your code base and you don’t open up a single other code file, you are gonna wanna look at that one. Because you’re gonna be able to get huge performance, like an accuracy increases by just taking some questions

[28:29] that sometimes are written very poorly and just making them more sensible. - Yeah, thank you, Hunter, for the demo and Allie for the tips. I think this is just a very new type of model and so everyone’s gonna need to slowly learn how we can best develop with it. One interesting resource that I stumbled upon was this resource called Jevify. It’s just basically a skill. I’ll paste the link in the chat. And this is like a prompt that you can give a coding agent to help it look over and scan your agent code

[29:03] and figure out like, where am I using an LLM for decisions that actually would be much better with a decision model and how can we plug that in? How can we architect that to save on latency and cost? And then also importantly, like, where is an LLM the right tool here? And like, we need to leave that. So excited about that. I think it would be great if we could– - I saw that specific project and love it. Like we wanted to, if we had had like more time leading up to launch, we talked a lot about creating

[29:33] like a brainstorming skill, which basically is exactly what the person has created. Like because there’s oftentimes like low hanging fruit, especially in like an LLM integrated piece of software. There’s usually low hanging fruit for Jev to be like a swap in and then sometimes less obvious things. And so the Jevify skill there is pretty darn cool. is there one more thing I can show, ’cause I made some promises and this landed literally five minutes ago inside of LangSmith. I just want to, sorry to hijack real quick,

[30:04] but this is the thing that I love about working at startups is that we can ship so quick. We have nice rendering now, so you can go in and actually interpret some of the things that are inside of your LangSmith trace. So you saw it before that it was like pretty ugly [audio drops out] >> Yeah, those are working at LinkedIn.

[30:36] Awesome. Well, we’re going to save some time at the end for community questions, but Allie, we have a couple of questions for you first, both that we’ve seen on Twitter and just internally from LangChain, Jev Power Users. So one thing that we’re curious about, I believe the context length for Jev is 32K tokens right now. Is that correct? It’s basically, it’s slightly complicated. It’s 32K for the state plus your largest question.

[31:11] So like if you imagine a state and the question together is 32K and then there’s around a 64K cap for the state plus all of the questions together. That’s just when you would need to like separate it into multiple calls. - Okay, nice. Is there, do you guys have plans to like extend that context length or support other types of content, like multimodal, what’s your roadmap like there? - So our official answer to multimodal do we support images is not yet, with no further expanding upon that vague

[31:45] promise. And I would also give the same answer to things like increased context length. We also want to go faster, cheaper, like this is the beginning. And if you read like the launch blog post on our website, like written by Diogo, it really does explain like where we’re at in this. We see this as like the beginning of this revolution that we that we want to help, you know, drive forward. And so yes, improving in every angle is what we expect. But no, I’m not not putting any specifics

[32:18] or promises on timing or any of that. But follow us because we’re we’re we’re moving fast. Yeah, yeah, that’s great. I saw also Diogo put out some cool content, I think yesterday about like, how to think about Jev for coding agents. And like, how it can plug into some of those pieces, it seems like, interesting use cases that were highlighted were along the dimensions of like progressive disclosure and tool selection. And then also, like RLMs and code mode seemed

[32:51] like an interesting case. Are there any other really compelling use cases that you’ve seen or like Jev in production that’s interesting for folks to know about? It’s like it’s so it’s so vast like what people are doing and they’re moving so fast. I want to be like let me just open my Twitter feed and like look at the top 10 posts. I bet all of them will blow me away at this point, right? And that’s the most exciting thing about where we’re at right right now is like, we knew the community would take a lot of these things and run with it.

[33:24] And we are seeing that. You already talked about some of the, I think, what I’d call low hanging fruit, like using it for safety classification of tool calls, model routing, especially up front where you’re like, oh, is this overall question, does it require this, that, the other thing. I, my personal like biggest excitement is the projects that I see that are in the real time,

[33:57] real time use cases. And real time was like a, it was a big like aha moment for us internally because we always called like, we knew that we were very fast and we knew that we were very cheap. And then all of a sudden it was like, I had an epiphany one night, I was like, wait, when you’re fast and cheap that unlocks real time. Like if you’re too expensive, trying to use something in real time, it’ll just become cost prohibitive. And if you’re too slow, you just can’t keep up with real time. But real time means that like real time chat filtering to me, I made a demo for this early on, but we didn’t end up using it for our launch demos.

[34:29] And now people have already made better versions of like live filtering, a massive streaming Twitch stream of, tons and tons and tons of chat when you get these channels that have got like a hundred thousand viewers, right? You can filter those live And it only around 100, 150 millisecond delay in making it appear, it feels like real time. Like it doesn’t even matter. There’s like more latency than that just from like Twitch’s like displaying it, right? So you can, you can, you can,

[35:00] because you can score them along an axis, you can even make it where the user can just like move like a scrubber of like how filtered do you want it? Do you want only the most like productive, like interesting questions being asked or do you want all the emoji spam, right? And you can just like literally just like turn a dial. And like that’s just like so cool to be able to do that. And in that parallel call, you can also classify them as questions or statements or hype messages like all at the same time, all in that 100 milliseconds for every single message and it won’t break the bank.

[35:32] So yeah, I just, there’s so much. That’s just like the first one that came to my head. - I think one of the, I am glad you mentioned the real time element of it ’cause I think in like one of the launch posts, I saw the demo you guys did where you got Jev to play Doom real time. That was like one of those moments that was like, this is incredible, things are so cheap and fast now, it’s gonna open up like a whole new paradigm. - Yeah, that was my baby. The Doom demo has been my favorite thing to work on the last couple of months here. - Nice, well yeah, it blew me away.

[36:04] I think it blew a lot of people away. So props to you, props to the whole team for building it. - Yeah, I agree. I think Twitter has really done something else with Jev over the past six days or so. I feel like I’ve learned about a new use case every five minutes. Are there any other interesting, before we pivot to the community questions, any other roadmap items that you wanna share? I know faster and cheaper is,

[36:35] Like obviously, this is a lot of work on neural Zen. - Not, I would say not specifically, you know? It’s like a watch this space. You never know what next week will be with like how much incredible demand there has been. Right like in this immediate moment, we are like working on increasing capacity to get more people in. At least at the start of this, our signups were still paused as we managed demand and make sure that we have like high quality service

[37:19] [audio drops out] [audio drops out] - Oh, not a lot. Not a lot. It’s been wild and crazy. And everyone is working like incredibly hard. But it’s also so many smiles. It’s so much smiles here, like people are excited. The energy is just electric in the office. - Amazing. Well, with that, let’s pivot to a couple of the questions from folks on the webinar.

[37:50] the most upvoted one right now is, is Jev trained on the same data as a typical LLM? - So the, so it is, it is, sorry, I’m like reading my, reading my notes on this one, ’cause I don’t do, I’m like not an ML person, and I’m not involved in like the actual training and stuff. We do use a mixture of pre-trained models to train ours. our data that we use to train our model

[38:22] is all synthetic data created in-house. And that’s part of our secret sauce. But it goes far beyond, the process goes far beyond post-training. And there’s a lot of hand-waviness in there because we do have breakthroughs, which is part of why we’re able to create what we’ve created for it to be this amazing. And so we’re going to hold on to some of that secret sauce for now. - Nice. I’m kind of aggregating a theme that I’m seeing across

[38:53] some of these questions, which is like, how do you kind of tailor the either like confidence or probabilities that you set in your code as thresholds for like, okay, if the confidence is above X, then we’ll do this or if the probability is above X, is that, yeah, it seems pretty domain specific. How do you think about that? - I would say that’s exactly right, is that it is domain specific. My, I think it was written like multiple places in the like tips in our documentation where it’s like,

[39:23] you should test your domain, like test your actual like data and use case to make sure that you under like, first of all, make sure that it’s like in distribution, make sure that like, “Jev is good for your use case, “don’t blindly shove it into production without testing.” But also like, that’s where you should be looking at like what the thresholds are. you know, if you’re finding yourself setting a threshold like super low, like especially like below 50% for Noul, because that almost certainly means that either there’s a problem and like this is like an aspect

[39:54] of our model jaggedness where maybe we just like aren’t good at that particular use case yet. Or it means that maybe your questions need some significant tweaking. But so it is about testing it. And then I will also say that a big thing about using Jev effectively is to, like confidence thresholds is only one way to use the probabilities. What I think is really important to know

[40:25] is that the confidence that’s returned by our API, that is a computation, is like a statistics computation on the probability map that you get back. It is a deterministic computation that you could do yourself. That is not a silver bullet. It does not, it represents in, in I think primary use cases, it’s a good analog for confidence. But that is the cases where you are expecting like a single dominant answer.

[40:55] The confidence is mostly a measure of how much is there like disagreement, how much is there a distributed spread in the probability map. And you could have use cases where you actually expect two or three of the possible options to be competing for top probability, and in which case your confidence is gonna be like super, super, super low, because that’s the confidence in there being a single dominant answer. But in some of these use cases, that’s actually normal and okay. And so I also find that coding agents, they really like to see that confidence and be like,

[41:25] yeah, we should always do a different thing if confidence is low. That’s not always the case. Like I built a shopping cart. Actually, the Doom demo is a great example. The Doom demo says, which monster, where should we be looking each frame, right? Like this monster, that monster, should we be looking at that item, et cetera, et cetera. None of those is like, oh yeah, that one’s gonna be like 100% and everything else is gonna be 1%. No, no, no, there’s like actually a lot of solid options. And so we just take whatever one is the top choice.

[41:56] You could even do some fancy things, like adding a bit of like decay where you make the most recently picked choice stickier. and so it requires more of a swing to change it. Like that’s an interesting pattern I think to play with. But if we were to like naively, and what some of the first like vibed up versions of the Doom demo brains used confidence gating, it was like the agent was like, oh, confidence is low on this, so I should just fall back to like looking forward or something, it’s like, no, no, no, no, no, no, it’s like a bad use of confidence because it just doesn’t apply in the situation

[42:26] because we expect there to be competing answers. We just wanna pick the best one. So that’s like just one of many potential examples you don’t want to just blindly trust confidence to work in your particular use case. It’s a good shortcut for a lot of simple use cases, but like always test, always check and be creative. There could be other probability math. Sometimes you just want like the top probability, raw percentage that you’d wanna threshold on. Sometimes it might be the top probability minus the second highest, or divided by the second highest probability gives you a different thing. Like all of these are different like

[42:59] statistics math approaches to how to deal with it. >> Yeah, that’s super interesting. Anecdotally, I was working on a pretty naive application of Jev just using it to help me add labels to new GitHub issues so that we could automate more of our triage. I was perplexed by some of the probabilities and confidences that I was getting back in some of the results and was like, “I need to dig more into how to properly understand this for this use case.” Just calibrate myself as the developer.

[43:31] Yeah, I think so maybe time for one more question. I think this one is interesting It says as far as I understand Jev’s status input token limit is yeah around the 32k that we talked about Are there any decision degradation? Consequences on large inputs. How should we think about that for Jev? It’s a really good question We have a a doc page in our docs called Model Jaggedness. And I highly recommend checking it out.

[44:02] It is our, this is a part of our, like one of our like cornerstones of our company culture and like our brand is honesty. Like we don’t, we’re not, we don’t wanna say Jev is better at anything that it actually is, right? We are not an over promise culture here. And so the Jaggedness article is like our list of like known ways that we know that the model doesn’t do great in. And I believe, as I’ve read so much things recently, so I could be wrong, but I’m almost positive that one

[44:33] of the things in there is talking about long contexts and that it can degrade accuracy if you put in a huge amount of state. I would say the guideline for that is make sure you’re only providing in the state what is actually necessary for making the determination. You don’t wanna just like throw the whole world at it and then ask it to make a determination about a part that is like just a tiny slice of it. Now, sometimes you don’t have any other choice, right?

[45:04] Sometimes you truly are evaluating a large unstructured like wall of text and you can’t trim that down in code. That’s why you’re trying to use an AI model to like to evaluate in which case, iterate on questions, figure out like what works best, test it. But in a lot of cases, we’re constructing the state from multiple bits of data that we have in code. And so that comes down to the system designer to you as the programmer to consider, is this part actually needed? Do you need to add that to the state? Do you need to add this to the state?

[45:34] It’s also better, more cost effective to not throw more tokens at something you don’t need. Jev is so cheap that most of the time you can just throw extra at it and not care. But you should be mindful about what you’re including and definitely test that. That’s like a big thing. And also in the Doom demo, like the state, I played a lot with like how much detail to provide in the state. And at one point I had like a recent actions array. This is like everything that happened recently, but it was so granular. It was like every like bullet of damage and stuff

[46:06] that it would aid up a huge amount of the state. And it did cause the like the overall intelligence to drop a little. So I was like, okay, we should like clean that up. That’s like kind of a pointless amount of detail. So there is like good tweaking to work with that. That being said, every single thing on the Model Jaggedness page is things that we think could get even better in the future. Yeah. Yeah, I really appreciate that transparency. And I think it’s great thinking back to the Jevify stuff. It’s like, where should we use Jev? Where should we not? It’s not an answer for all use cases,

[46:39] but can be really great for some. And I think it feels very full circle to end this conversation talking about basically context engineering for Jev. We have come up with many names for that in the past. In fact, we’ve run webinars on harness engineering, on loop engineering, on filling the, you know, now we’re talking about Jev engineering maybe, but yeah, I think it’s still important to think about like, this is still a model, like how can we optimize what goes in in order to optimize what comes out.

[47:09] And with that, I just wanted to say, thank you so much, Allie and Hunter, for joining for this almost emergency webinar on building a harness with Jev. We are so excited to see the enthusiasm around the Jev launch. We’re very bullish on using it and other decision models internally. And yeah, thank you so much for joining us. And thanks folks for joining in your good questions. - Thank you. And I will also take an opportunity to plug our Discord. We wanna see what you’re building. We wanna see your cool projects. If Discord’s not your thing,

[47:40] you can also like tweet it to us on X. That’s also cool, but like a lot of people showing a lot of really cool stuff on our Discord and a lot of our developers are engaging with the community in there too so we’d love to see you. I can plus one the Discord it’s a pretty cool place I’ve been I’ve been lurking in there for a little bit. Yeah. Okay.