Como montar um workflow de automação combinando decisões do Jev em código

Fala aí, beleza? Se o teu "workflow de IA" hoje é um prompt gigante que classifica, decide, escala e ainda tenta devolver um JSON no fim, esse post é pra ti

A proposta aqui é outra: quebrar o processo em decisões pequenas e tipadas, e deixar o encadeamento delas no código, onde ele sempre deveria ter ficado

O Jev é o primeiro modelo da classe System One da TypeSafe AI. Ele recebe um estado não estruturado mais perguntas tipadas e devolve decisões tipadas com probabilidades, em vez de texto livre: é um modelo de decisão estruturada, sem geração de texto

Ou seja: ele não escreve a resposta pra você, ele responde a pergunta que você fez, no formato que você definiu

No fim deste post tu sai sabendo desenhar o fluxo, escolher entre Choice, Score e Noul pra cada julgamento, e definir o que acontece em cada ramo 🙂

O que você precisa antes de começar

Primeiro o acesso, porque ele é o gargalo hoje

O Jev foi anunciado em 15 de setembro de 2026 em early access, com lista de espera, e as chaves de API saem pelo console da TypeSafe conforme a fila avança

Tem um caminho alternativo: o modelo está listado no OpenRouter, hospedado por um único provedor, sem escolha de roteamento, como typesafe/jev-1.13 e ~typesafe/jev-latest

Ambiente:

O SDK Python oficial instala assim:

python -m pip install typesafe-sdk

Ele pede Python >= 3.10, lê a variável TYPESAFE_API_KEY do ambiente e chama jev-latest por padrão. O alias jev-latest aponta sempre pra versão mais recente da família, e hoje resolve pra jev-1.13

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Se teu stack é JS/TS:

npm install @typesafe-ai/sdk

Node.js 20 ou mais novo, pacote com ESM, CommonJS e declarações TypeScript. Os dois SDKs oficiais já tratam retries automaticamente pela política padrão, então não precisa reinventar esse pedaço

E se tu preferir bater direto no HTTP, o endpoint é POST /v1/systemone (https://api.typesafe.ai/v1/systemone), com o campo model escolhendo o modelo

Dois limites que mudam o desenho do fluxo:

A janela de contexto do Jev 1.13 é de 32.000 tokens. Isso não é detalhe de rodapé, isso é decisão de arquitetura: tu não vai empurrar a base de conhecimento inteira pra dentro do state

O preço é US$ 0,042 por milhão de tokens de entrada e US$ 0,00 por milhão de tokens de saída, ou seja, cobrança só na entrada. Traduzindo pro desenho: o que pesa no teu custo é o tamanho do estado que tu manda, não a quantidade de perguntas que tu faz sobre ele

Guarda essa frase, ela vai voltar no passo 4 😀

Dando contexto da API pro teu agente de código:

A TypeSafe publica um agent skill pra isso. No Claude Code:

claude plugin marketplace add typesafe-ai/skills
claude plugin install typesafe@typesafe-ai

Depois é só invocar com /typesafe:typesafe-ai

Em outros agentes:

npx skills add typesafe-ai/skills --skill typesafe-ai

A instalação é project-local por padrão, e tem -g pra global

Passo a passo: do processo em prosa ao workflow em código

Antes de abrir o editor, uma ressalva importante de arquitetura: a recomendação da própria TypeSafe é manter fluxo de controle, regras determinísticas e efeitos colaterais no código, quebrar julgamentos amplos em perguntas estreitas e tipadas, e dar a cada pergunta só o contexto de que ela precisa

Código no comando, modelo só nos pontos de julgamento sobre dado não estruturado

Bora montar?

1. Desenhe o processo como fluxograma antes de escrever qualquer linha

Pega o processo em prosa ("chega um e-mail de suporte, alguém lê, decide se é reembolso, checa a política, responde ou escala") e transforma em caixinhas

Agora passa em cada caixinha e marca com duas cores: aqui tem julgamento sobre dado não estruturado ou aqui tem regra determinística?

"O cliente está pedindo reembolso?" é julgamento sobre texto solto. "A compra tem menos de 30 dias?" é uma comparação de datas no teu banco, não pergunta pra modelo nenhum

O erro comum deste passo: deixar o modelo decidir o fluxo. Se a tua caixinha é "o que eu faço agora?", ela ainda não foi quebrada o suficiente. Vale lembrar também que o encadeamento entre chamadas fica por conta do teu código, então o fluxograma É o teu programa

2. Quebre cada julgamento em perguntas estreitas e escolha a primitiva certa

A API System One oferece três tipos de pergunta:

Se você conhece aquele esquema de enum, escala e flag booleana no teu código, é exatamente isso, só que respondido sobre texto não estruturado

O erro comum deste passo: uma pergunta que embute duas decisões. "O cliente pediu reembolso e a política permite?" é DUAS perguntas coladas com um "e". Quebra em duas Noul e resolve o "e" no teu if, que é onde o "e" mora

3. Separe state e questions

O state carrega o conteúdo e os fatos de apoio. As questions definem os julgamentos sobre aquele material

No exemplo clássico da doc: o pedido de reembolso e a política vão pro state, e as perguntas são se o cliente pediu reembolso e se a política sustenta o pedido

{
  "model": "jev-latest",
  "state": {
    "mensagem_cliente": "...texto do e-mail...",
    "politica_reembolso": "...trecho aplicável da política..."
  },
  "questions": { }
}

O erro comum deste passo: despejar tudo no state. Lembra do preço: a cobrança é na entrada. Estado inchado é conta mais alta, contexto mais disputado dentro dos 32.000 tokens e pergunta mais confusa. Dá a cada pergunta só o contexto de que ela precisa

4. Monte a request com N perguntas em paralelo

Aqui tá a parte que muda o desenho do fluxo de verdade

Você pode enviar várias perguntas na mesma requisição. Todas veem o mesmo estado, são avaliadas de forma independente e voltam sob o ID que você escolheu

E tem um detalhe que a doc deixa explícito: a resposta de cada pergunta não depende das outras perguntas presentes na requisição. Um documento e N perguntas, mandando 1 request com N perguntas ou N requests com 1 pergunta, dá o mesmo resultado, porque cada pergunta é pontuada sozinha contra o estado

from typesafe_sdk import TypeSafeClient, Choice, Noul, Score

client = TypeSafeClient()  # lê TYPESAFE_API_KEY do ambiente

O ganho de mandar junto é não fazer round trips seriais: o código recebe todos os sinais de uma vez e combina do jeito que quiser

E a saída é type-safe por construção: decisões e probabilidades saem nos tipos e no JSON schema que teu código espera, sem ninguém extraindo valor de texto gerado com regex 😛

O erro comum deste passo: encadear chamadas seriais achando que a pergunta A alimenta a pergunta B. Não alimenta. Se B realmente depende do resultado de A, então A é um ramo do teu fluxo, e aí sim tu faz uma segunda chamada com um state diferente

5. Escreva os ramos no código, usando a confiança como segundo eixo

A decisão em si é um eixo. A confiança é o outro

A documentação sugere dividir a confiança em três faixas com comportamentos diferentes: alta confiança age automaticamente, e os casos incertos vão pra revisão humana ou escalam pra um modelo de raciocínio mais caro

SEGURO = 0.90      # ajuste com os teus dados reais
DESCARTE = 0.10

if p_reembolso >= SEGURO and p_politica_permite >= SEGURO:
    aprovar_reembolso(ticket)          # age sozinho
elif p_reembolso <= DESCARTE:
    rota_padrao(ticket)                # nem é reembolso, segue o baile
else:
    fila_revisao_humana(ticket)        # ou escala pro modelo caro

Repara numa coisa: a escalada é lógica da aplicação sobre a probabilidade retornada, sem nova pergunta e sem segunda chamada de API. O sinal pra escalar já veio junto com a resposta

Esse desenho de faixa incerta virando fila de gente é a mesma ideia de quem já montou automação com revisão humana no meio do fluxo: a diferença é que aqui o gatilho da revisão é um número tipado, não um chute do prompt

O erro comum deste passo: tratar a faixa do meio como se fosse a faixa de cima só pra não montar a fila de revisão. Aí não tem workflow, tem torcida

6. Feche com efeitos colaterais e observabilidade no código

O e-mail que sai, o registro no banco, o webhook disparado: tudo isso é código teu, não é responsabilidade do modelo

Loga o ID da pergunta, a decisão e a probabilidade em cada execução. É isso que vai te deixar ajustar os cortes do passo 5 daqui a duas semanas com dado na mão, em vez de achismo

E retry tu não precisa escrever: os SDKs oficiais já tratam automaticamente pela política padrão

O erro comum deste passo: colocar efeito colateral irreversível na faixa incerta. Estorno, exclusão, e-mail pro cliente: os rm -rf da vida ficam na faixa de alta confiança ou passam por gente. Já me ferrei uma vez por causa disso 😅

Três desenhos de workflow que dá pra copiar

Os casos que a TypeSafe cita pra decisões dentro de software cobrem classificação, roteamento, scoring e extração, em cenários de atendimento ao cliente, tratamento de faturas, alertas de segurança e revisão de execuções de agentes

Dá pra encaixar quase tudo isso em três desenhos:

1. Intent routing:

O padrão de intent routing da TypeSafe classifica a requisição que chega e roteia cada caso pro handler adequado: lógica determinística, LLM especialista ou humano

Primitiva natural aqui: Choice, uma opção por handler

A sacada é que nem todo ramo precisa de IA. "Segunda via de boleto" cai numa função. "Reclamação complexa" cai num modelo especialista. "Ameaça jurídica" cai numa pessoa

Quem já brincou de roteamento com agentes de IA no n8n reconhece o desenho na hora: muda que a classificação vira tipada e o roteamento vira match no teu código

2. Cascata SDE:

Tem um cookbook de cascata (SDE cascade) que mantém a resposta barata e só escala pra um modelo de raciocínio caro quando um sinal verificador dispara

É extração de dados estruturados com escalonamento condicional. Aplicado a faturas: o caminho barato resolve o grosso, e a fatura estranha, a que o verificador marcou, sobe pro modelo caro

O desenho é: barato por padrão, caro por exceção. Nunca o contrário

3. Triagem com scoring e revisão humana:

Perfeito pra alerta de segurança e pra revisão de execuções de agentes

Score contra níveis ordenados e descritivos, e o corte de nota define se fecha automático, se entra na fila ou se acorda alguém

E repara no combo: nada impede de mandar o Score de severidade, um Noul de "tem dado sensível envolvido?" e um Choice de categoria na MESMA requisição, já que todas veem o mesmo estado e voltam sob os IDs que tu escolheu

Como foi montar isso na prática (e o papel do agente de código)

Um ponto honesto antes de tudo: a comparação de 20 a 200 vezes mais rápido e 40 a 400 vezes mais barato que LLMs comparáveis em tarefas de decisão estruturada é claim do fornecedor, divulgado pela própria TypeSafe no material de lançamento

Não é medição independente, e eu não vi benchmark de terceiro pra confirmar. Trata como hipótese a testar no teu caso, não como fato

Sobre o agente de código: é exatamente pra isso que existe o skill que te mostrei lá em cima, dar contexto da API pro agente em vez de você colar trecho de doc no chat toda hora

E é aqui que entra a experiência que eu venho tendo com esse jeito de trabalhar. No vídeo do canal eu mostro um workflow que combina Claude Opus e Gemini dentro do Antigravity: peço ao Opus, em modo de planejamento, que assuma o papel de product manager e gere um PRD completo, e depois troco pro Gemini pra executar a implementação a partir daquele documento

No exemplo, o PRD saiu completão: requisitos, lista de funcionalidades, user stories, esquema de banco e endpoints. Com praticamente dois prompts (um pro PRD, outro pra implementação inicial) a aplicação já estava rodando como MVP, e eu testei na mão: adicionar pergunta, preview, salvar, tudo funcionando

Depois disso, o ciclo é sempre o mesmo: pede a funcionalidade, testa, pede a próxima. É o mesmo princípio do post inteiro, viu? Decisão pequena, verificação, próxima decisão

Pra começar do zero com essa ideia de combinar assistentes de IA dentro do teu fluxo de trabalho, o vídeo abaixo mostra o processo completo:

Próximo passo: comece pelo ramo mais caro do seu processo

A ideia central é uma só: código no comando, modelo só nos pontos de julgamento sobre dado não estruturado

Não tenta converter o processo inteiro de uma vez, isso quase sempre acaba em prompt gigante disfarçado de arquitetura

Escolhe UM ponto de decisão do teu fluxo atual, de preferência o mais caro (aquele que hoje come tempo de gente ou que erra feio quando erra). Transforma ele numa pergunta tipada, escolhe a primitiva, roda contra os casos que tu já tem arquivados e olha a distribuição das probabilidades

Com esse dado na mão tu define os cortes das faixas de confiança com critério. Aí sim encadeia o resto

E lembra do acesso: o early access tem lista de espera, com as chaves saindo pelo console da TypeSafe conforme a fila anda, e ainda existe o caminho do OpenRouter pra quem quiser testar antes

Agora me conta: qual é o ponto do teu fluxo que tu converteria primeiro? Bora trocar uma ideia

Até o próximo post! 🙂