Como usar o Jev para decidir quando o agente deve parar de iterar?

Agente que itera pra sempre e agente que para cedo demais têm a mesma causa raiz: quem responde "já terminou?" é o mesmo LLM que acabou de escrever a resposta

E ele quase sempre acha que fez um ótimo trabalho, né? 😅

A TypeSafe AI anunciou em 15/09/2026 o Jev, o primeiro System One Model deles: uma classe de modelo feita pra tomar decisão rápida e estruturada que o software consome direto. Ele não é autorregressivo, não prevê o próximo token e não te devolve uma stringzinha simpática

Tu manda um estado, ele devolve decisão tipada com probabilidade

É exatamente a peça que faltava pra tirar o "parar ou continuar" das mãos de quem tem conflito de interesse

Por que deixar o LLM julgar o próprio "já terminou?" falha

O desenho clássico é esse: o agente executa, produz um resultado, e aí você manda de volta pro mesmo modelo uma pergunta tipo "a tarefa está completa? responda SIM ou NÃO"

Dois problemas nascem juntos aí

O primeiro é o conflito: o gerador é o avaliador. O segundo é mecânico e dói mais no dia a dia: a saída é texto livre. Hoje vem SIM, amanhã vem Sim, a tarefa parece estar completa, embora... e o teu if quebra

E aí entra o gambiarrão de sempre: regex, .lower().startswith("sim"), retry quando não parseia, um JSON mode que às vezes volta com campo a mais

O Jev resolve isso por construção: as saídas válidas são declaradas no schema antes da chamada. Ele só responde dentro desse espaço declarado, sempre com probabilidade associada

Curso Recomendado

Curso de Jev: Sistemas Mais Inteligentes, Rápidos e Robustos

Desenvolva sistemas mais inteligentes, rápidos e robustos com Jev

Conhecer curso

Não tem resposta fora do espaço definido, não tem erro de tipo

Que "espaço definido"? É você quem escreve: se a pergunta é sim/não, o retorno é uma probabilidade entre 0 e 1. Se é escolha, o retorno é uma das opções da tua lista. Não existe terceira via inventada no meio do caminho

E não é ideia de maluco isolado: a LangChain publicou o material Building a harness with Jev descrevendo nós de decisão dentro do loop do agente, como roteamento de modelo e gate de tool call avaliado antes da execução

Ou seja: o padrão de "decisão de controle sai do LLM e vira chamada tipada" já tá documentado por terceiro, não é só o fornecedor falando bem de si mesmo

O que você precisa antes de começar

Lista curta, beleza?

• Conta e chave de API criadas no console da TypeSafe (console.typesafe.ai)
• A chave exportada na variável de ambiente TYPESAFE_API_KEY
• SDK oficial, se você for usar: npm install @typesafe-ai/sdk ou pip install typesafe_sdk. Os dois leem a TYPESAFE_API_KEY e usam jev-latest por padrão
• Um agente com loop já existente, porque o Jev não substitui o LLM que executa a tarefa

Esse último ponto é o que mais confunde gente chegando agora: o Jev não escreve teu código, não redige teu email, não chama tua tool. Ele decide

Sobre acesso: não tem mais waitlist, a TypeSafe abriu pra todo mundo. Conta nova recebe US$ 5,00 de crédito inicial (algo em torno de 120 milhões de tokens)

O preço é US$ 0,042 por milhão de tokens de entrada, e os tokens de saída são gratuitos

Sim, tu consegue prototipar um gate de loop inteiro dentro do crédito de boas-vindas 🙂

export TYPESAFE_API_KEY="sua_chave_aqui"

Tome cuidado: chave em variável de ambiente, não hardcoded no arquivo que você vai commitar. Já viu esse filme antes

Passo a passo: transformando o "parar ou continuar" em decisão tipada

1. Desenhe o state da iteração:

O campo state aceita string, objeto JSON, array ou null. Use isso a teu favor e mande estado estruturado, não prosa

O que costuma entrar: o objetivo original, a última ação executada, o resultado da tool, quantas tentativas já rolaram e o que ainda está pendente

{
  "objetivo": "Corrigir o teste que falha em auth/login_spec.ts",
  "tentativas": 3,
  "ultima_acao": "run_tests",
  "resultado_ultima_acao": "1 failing: expected 200, got 401",
  "arquivos_alterados": ["src/auth/session.ts"],
  "pendencias": ["teste ainda falhando"]
}

O erro comum deste passo: jogar o histórico bruto da conversa inteira dentro do state

Funciona? Provavelmente. Mas você acabou de transformar uma decisão barata numa chamada gorda, e enterrou o sinal relevante (tentativas, resultado da última ação) embaixo de dez mil tokens de "claro! vou analisar isso pra você"

Estado é estado. Transcrição é transcrição

2. Escolha o tipo de pergunta certo:

O Jev aceita exatamente três tipos, e é aqui que a maioria erra o desenho

Noul é o nome que a TypeSafe dá pra pergunta sim/não, e é o tipo natural pro "já terminou?"

O erro comum deste passo: usar Choice com as opções ["parar", "continuar"] quando a pergunta é binária. Dá certo, mas você joga fora a graduação: com Noul você recebe o quanto o modelo acha que terminou, não só o lado vencedor

3. Monte a requisição:

O endpoint do Jev é próprio, não é /chat/completions. É POST https://api.typesafe.ai/v1/systemone

O corpo exige três campos: model, state e questions. O questions é um mapa do nome da pergunta pra um objeto com type e instructions

curl -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "jev-latest",
    "state": {
      "objetivo": "Corrigir o teste que falha em auth/login_spec.ts",
      "tentativas": 3,
      "ultima_acao": "run_tests",
      "resultado_ultima_acao": "1 failing: expected 200, got 401",
      "pendencias": ["teste ainda falhando"]
    },
    "questions": {
      "esta_completo": {
        "type": "Noul",
        "instructions": "O objetivo foi totalmente atingido e não há pendência aberta no estado?"
      }
    }
  }'

A resposta traz model, answers e usage

O erro comum deste passo: escrever instructions vago tipo "está bom?". Afirmação vaga gera distribuição espalhada, e distribuição espalhada é confiança baixa. Escreva a afirmação como uma frase que dá pra julgar olhando só o state

4. Faça várias perguntas de uma vez só:

As perguntas são avaliadas numa única ida e volta. Então não faz sentido chamar três vezes pra saber completude, qualidade e próxima ação

{
  "model": "jev-latest",
  "state": { "...": "..." },
  "questions": {
    "esta_completo": {
      "type": "Noul",
      "instructions": "O objetivo foi totalmente atingido e não há pendência aberta?"
    },
    "qualidade": {
      "type": "Score",
      "instructions": "Qualidade do resultado atual: 1 inutilizável, 5 pronto pra entregar"
    },
    "proxima_acao": {
      "type": "Choice",
      "instructions": "Qual a próxima ação mais útil dado o estado?",
      "options": ["rodar_testes", "editar_codigo", "ler_arquivo", "encerrar"]
    }
  }
}

O erro comum deste passo: adicionar uma pergunta pedindo pro Jev "explicar por que decidiu isso"

Ele não gera texto. Ponto. Se você precisa de justificativa legível pra humano, isso é trabalho de outro modelo, ou do teu log mostrando o state que entrou e a distribuição que saiu

5. Ligue a resposta ao controle do loop:

Agora a parte que importa: a condição de saída deixa de ser um parse de string e vira comparação numérica

const TYPESAFE_URL = "https://api.typesafe.ai/v1/systemone"

// valores arbitrários deste projeto: calibre com os seus próprios dados,
// não existe limiar oficial recomendado pela TypeSafe
const PARAR_ACIMA_DE = 0.9
const DESISTIR_ABAIXO_DE = 0.2
const MAX_ITERACOES = 12

async function decidir(state) {
  const res = await fetch(TYPESAFE_URL, {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.TYPESAFE_API_KEY}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      model: "jev-latest",
      state,
      questions: {
        esta_completo: {
          type: "Noul",
          instructions: "O objetivo foi totalmente atingido e não há pendência aberta?"
        }
      }
    })
  })
  return res.json()
}

async function rodarAgente(objetivo) {
  let state = { objetivo, tentativas: 0, pendencias: ["concluir o objetivo"] }

  for (let i = 0; i < MAX_ITERACOES; i++) {
    state = await executarUmaIteracao(state) // aqui roda o teu LLM de sempre

    const { answers, usage } = await decidir(state)
    const p = answers.esta_completo

    console.log({ iteracao: i, completude: p, usage })

    if (p >= PARAR_ACIMA_DE) return { status: "concluido", state }
    if (p <= DESISTIR_ABAIXO_DE && state.tentativas >= 3) {
      return { status: "escalar_humano", state }
    }
  }

  return { status: "limite_de_iteracoes", state }
}

O erro comum deste passo: remover o MAX_ITERACOES porque "agora o Jev decide". Não. O gate é semântico, o contador é mecânico, e os dois protegem coisas diferentes

6. Pine a versão do modelo quando precisar de estabilidade:

jev-latest é ótimo pra prototipar e péssimo pra reprodutibilidade, porque o que está por trás dele pode mudar

O jev-latest já foi observado resolvendo para jev-1.13.0, e o identificador typesafe/jev-1.13 aparece listado em provedores

{ "model": "jev-1.13.0" }

O erro comum deste passo: pinar e esquecer. Se tu pinou, anota no README por que pinou e quando revisar, senão daqui a seis meses ninguém lembra

Usando o score de confiança como trava de segurança

Aqui mora a parte mais bonita do desenho, e a mais ignorada

Respostas de Choice e Score carregam um campo de confiança separado, de 0 a 1, derivado do formato da distribuição de probabilidades

Probabilidade concentrada numa opção significa confiança alta. Distribuição espalhada entre as opções significa confiança baixa

A regra prática que a própria documentação resume é linda de simples: a resposta diz o quê, a confiança diz se você deve agir

1. Separe três faixas de tratamento:

• Confiança alta e decisão "completo": para o loop e entrega
• Confiança alta e decisão "incompleto": continua iterando, com a próxima ação que o Choice apontou
• Confiança baixa: não é pra parar nem pra insistir cegamente. É pra escalar, seja pra um humano, seja pra um modelo maior fazer uma passada de revisão

Distribuição espalhada quase sempre quer dizer que o state que você mandou não tem informação suficiente pra decidir. O modelo tá te avisando que a pergunta tá mal servida, não que a tarefa tá mais ou menos

Essa faixa do meio é a mesma discussão de autonomia do agente no Claude Code: o ponto não é dar autonomia total nem zero, é ter um sinal confiável pra saber em qual dos dois modos você está agora

2. Trate o Noul diferente:

Noul não tem campo de confiança separado. A própria probabilidade é o sinal que a aplicação usa

Ou seja: ali você não tem uma trava, você tem duas fronteiras

Perto de 1 é sim com força. Perto de 0 é não com força. E a região do meio, aquele território morno onde o modelo não se compromete, é justamente o teu gatilho de escalação

function faixaNoul(p) {
  if (p >= PARAR_ACIMA_DE) return "parar"
  if (p <= DESISTIR_ABAIXO_DE) return "continuar_iterando"
  return "escalar" // zona morna: ninguém decide por palpite
}

3. Entenda por que dá pra confiar nesse número:

O Jev é treinado com um método de calibração próprio da TypeSafe, o RLCD (Reinforcement Learning for Calibrated Decisions)

A propriedade buscada é essa: grupos de previsões com probabilidade mais alta devem acertar com mais frequência que grupos de probabilidade mais baixa

Parece óbvio, mas não é o comportamento padrão de um LLM cuspindo "tenho certeza absoluta" no meio de um parágrafo. Ali o número é texto. Aqui ele é a saída do modelo

Importante ser honesto: não existe limiar oficial recomendado pela TypeSafe do tipo "abaixo de tanto, continue". Os valores de corte são decisão sua, e a forma certa de achar é logar as probabilidades junto com o desfecho real de cada rodada e olhar os dados depois

Outras decisões de loop que valem tirar do LLM

Uma vez que o padrão entra na cabeça, você começa a ver decisão tipada em todo canto do harness

• Gate de tool call: antes de executar a ferramenta, uma pergunta avalia se aquela chamada faz sentido no estado atual. A LangChain descreve exatamente esse nó avaliado antes da execução. Noul resolve, e é o seu escudo contra os rm -rf da vida
• Roteamento de modelo: Choice entre o modelo rápido e o modelo caro, decidido pela dificuldade que aparece no state, não por um if com contagem de caracteres do prompt
• Próxima ação: Choice dentro de um conjunto fechado de ferramentas. Como as opções são declaradas no schema, é impossível o agente inventar uma tool que não existe
• Qualidade do rascunho antes de entregar: Score com rubrica ordenada, de 2 a 10 níveis. Muito melhor que "o texto está bom? sim/não"
• Detecção de loop improdutivo: Noul perguntando se o agente está repetindo a mesma tentativa com o mesmo resultado. É o gate que salva você da conta de API surpresa no domingo de manhã 😅

Se você quer ver o modelo aplicado fora do contexto de agente, os casos de uso do Jev dentro do software seguem exatamente a mesma lógica: decisão que o código consome direto, sem parse no meio

Custo e latência: por que essa camada extra compensa

O argumento contra é previsível: "você adicionou mais uma chamada de modelo por iteração"

Verdade. Então vamos olhar os dois eixos

No custo, o preço é US$ 0,042 por milhão de tokens de entrada e os tokens de saída são gratuitos. Como o state estruturado que você manda é pequeno (lembra do passo 1?), o gate custa uma fração do que custa a própria iteração do agente

Na velocidade, a TypeSafe afirma que o Jev é de 40x a 200x mais rápido que LLMs de fronteira em tarefas System One

E aqui eu preciso ser chato: isso é claim do fornecedor, não benchmark independente. Não vou vender esse número como verdade medida por terceiro, porque não é

A boa notícia é que você não depende de acreditar: a resposta traz o campo usage. Loga ele a cada gate, soma no fim do dia e compara com o custo das iterações que o gate evitou

Um agente que parava na iteração 12 por timeout e agora para na 4 porque alguém perguntou direito "já terminou?" se paga sozinho

Conclusão

A ideia central cabe em uma frase: quem decide parar não deve ser quem escreveu a resposta

O Jev encaixa exatamente aí, porque ele não compete com o teu LLM executor. Ele ocupa o espaço que hoje é preenchido por regex, retry e torcida

Próximo passo concreto, sem firula: cria a chave no console, exporta a TYPESAFE_API_KEY e coloca um único Noul de completude no loop que mais te dá dor de cabeça hoje

Roda uma semana logando probabilidade e desfecho

Só depois disso você adiciona o Score de qualidade e o Choice de próxima ação, já com número na mão pra calibrar as faixas em vez de chutar

Começa pequeno, mede, expande

Até o próximo post! 🙂