Como usar o Jev para pontuar urgência e ordenar a fila de tarefas do time

Fila de tarefas onde TUDO é urgente é fila sem prioridade nenhuma

E aí o time acaba atendendo quem grita mais alto no chat, não quem realmente está com o problema mais sério… já vi isso acontecer mais vezes do que gostaria haha

Fala aí, beleza? A TypeSafe AI lançou o Jev, o primeiro System One Model público dela, e a proposta é bem diferente de um chat: em vez de devolver texto livre, ele devolve decisões tipadas

Ou seja, você pergunta "quão urgente é isso?" e recebe um número estruturado, pronto pra entrar no seu código, sem precisar ficar parseando parágrafo 🙂

Neste post tu vai ver como desenhar uma pergunta do tipo Score pra pontuar urgência, como essa pontuação vira ordem de atendimento, o que fazer com empates e o que fazer com aquelas tarefas que a rubrica simplesmente não descreve bem

Bora ver na prática?

O que você precisa antes de começar:

Primeiro, uma conta e uma chave de API no console da TypeSafe

O Jev foi lançado em acesso antecipado limitado a partir de 15/09/2026

O cadastro aberto no console veio depois e teve uma novela: abriu em 20/09, pausou em 22/09 e reabriu em 27/09/2026

Hoje não tem lista de espera, mas se liga: contas novas não recebem mais o crédito grátis de US$ 5 e precisam cadastrar um meio de pagamento

O custo atual é de US$ 0,042 por milhão de tokens de entrada, e os tokens de saída não são cobrados

A referência de tudo é a documentação oficial, que também traz um SDK Python documentado em docs.typesafe.ai/sdk/python

Por último, e esse é o ponto que mais trava gente: você precisa ter acesso à fila de tarefas do seu sistema, com o texto de cada tarefa disponível

É esse texto que vai virar o state da pergunta

Passo a passo: da rubrica de urgência à fila ordenada

1. Urgência é caso de Score?

O Jev tem três tipos de pergunta (as primitivas): Choice, Score e Noul

• Choice escolhe uma opção de uma lista que você define
• Score posiciona o estado numa rubrica ordenada de níveis descritivos
• Noul avalia uma proposição de sim ou não e devolve a probabilidade de "sim"

Score é a escolha quando a resposta é uma posição num espectro que dá pra descrever em degraus, tipo a gravidade de um bug ou a satisfação de um cliente

Urgência encaixa direitinho nisso: não é "isso ou aquilo", é "quanto"

Se o seu problema fosse separar em categorias sem ordem entre elas, como acontece na moderação de conteúdo enviado, o Choice faria mais sentido

O erro comum deste passo: usar Choice com opções "baixa", "média" e "alta" e perder a noção de ordem

Com Score, a ordem é parte da pergunta, e é justamente isso que vai permitir ordenar a fila depois

2. Escreva a question de urgência:

O melhor molde é o exemplo oficial da documentação, que avalia a gravidade de um bug

A pergunta é How severe is the reported issue? e os níveis são:

• Cosmetic; no impact to functionality
• Broken or degraded feature, but workaround exists
• Blocking issue; no workaround exists

O state do exemplo é um botão de exportar que derruba a página de configurações no Safari

Repara como a pergunta é curta e direta, e quem carrega o significado são os níveis

Pra urgência, algo como "Quão urgente é atender esta tarefa?" já resolve

O erro comum deste passo: colocar critério dentro da pergunta ("quão urgente, considerando cliente, prazo e impacto…")

A pergunta pergunta, a rubrica explica

3. Defina os níveis da rubrica:

Aqui mora o trabalho de verdade

A API aceita no mínimo 2 e no máximo 10 níveis, e cada nível deve ser uma frase descritiva e observável, algo que alguém lendo a tarefa consegue conferir

Um exemplo de rubrica de urgência em cinco degraus:

• Nível 0: melhoria ou ajuste sem prazo, ninguém está bloqueado
• Nível 1: tarefa interna ou problema pontual, existe contorno e pode esperar o próximo ciclo
• Nível 2: funcionalidade quebrada ou degradada para clientes, mas existe contorno
• Nível 3: bloqueia o trabalho de um cliente ou de um time, sem contorno
• Nível 4: sistema fora do ar, perda de dados ou risco de segurança em andamento

Perceba que cada degrau acrescenta um fato novo (cliente afetado, contorno, bloqueio), então eles não se sobrepõem

O erro comum deste passo: níveis vagos como "baixa", "média" e "alta"

O modelo não tem como saber onde termina o "média" e começa o "alta", e o resultado é probabilidade espalhada entre os níveis

Tome cuidado também com dois níveis que dizem quase a mesma coisa com palavras diferentes, isso dá o mesmo problema

4. Monte a requisição:

A requisição leva três peças:

• question: a pergunta
• criteria: um array ordenado com a descrição dos níveis, do mais baixo para o mais alto
• state: o texto avaliado, no caso a tarefa da fila

Um JSON ilustrativo só com esses três campos fica assim:

{
  "question": "Quão urgente é atender esta tarefa?",
  "criteria": [
    "Melhoria ou ajuste sem prazo, ninguém está bloqueado",
    "Tarefa interna ou problema pontual, existe contorno e pode esperar o próximo ciclo",
    "Funcionalidade quebrada ou degradada para clientes, mas existe contorno",
    "Bloqueia o trabalho de um cliente ou de um time, sem contorno",
    "Sistema fora do ar, perda de dados ou risco de segurança em andamento"
  ],
  "state": "Cliente relata que o checkout não finaliza no app desde hoje cedo. Pelo site funciona."
}

Endpoint, autenticação e o resto do envelope da chamada você confere na doc, beleza?

O erro comum deste passo: inverter a ordem do array e colocar o mais urgente primeiro

Já imaginou? A fila inteira vira de cabeça pra baixo e o "sistema fora do ar" vai parar no final kkk

5. Leia a resposta:

A resposta de Score devolve:

• type: score
• score: a soma de cada nível vezes a sua probabilidade
• probabilities: a probabilidade de cada número de nível
• legend: mapeia o número do nível de volta para a descrição
• confidence: um número de 0 a 1

E o que significa esse score ser uma soma?

Que ele é uma média ponderada pelas probabilidades, então pode cair entre dois níveis

O exemplo oficial mostra isso: 0 x 0.0 + 1 x 0.57 + 2 x 0.43 = 1.43, com confidence 0.35

Ou seja, o modelo ficou dividido entre o nível 1 e o nível 2, e o score ficou fracionário

Já o confidence é calculado a partir de como as probabilidades se distribuem: um pico único num nível significa confiança alta, e probabilidade espalhada por vários níveis significa confiança baixa

No exemplo, 0.57 contra 0.43 é bem dividido, por isso o 0.35

O erro comum deste passo: olhar só o score e ignorar o confidence

Um 1.43 com confiança alta e um 1.43 com confiança baixa contam histórias bem diferentes

6. Transforme o score em ordem de atendimento:

Como a rubrica vai do menos para o mais urgente, quanto maior o score, mais urgente

Então é só ordenar a fila de forma decrescente pelo score

Junto de cada tarefa, guarde três coisas:

• o score
• o confidence
• o nível de maior probabilidade, já traduzido em texto pela legend

Esse último ajuda muito o time, porque na tela aparece "Bloqueia o trabalho de um cliente, sem contorno" em vez de um número solto

O erro comum deste passo: arredondar o score

Se tu arredonda 2.4 e 2.9 pra 2 e 3, até funciona, mas se arredonda 2.4 e 2.6 pra 2 e 3, você cria uma diferença que não existe… e se arredonda 2.1 e 2.4 pra 2, você joga fora a diferença que existia

Guarde o valor cheio, a granularidade é justamente o ponto forte do Score

O que fazer com empates e tarefas que a rubrica não descreve bem

Aqui tem dois cenários que aparecem em toda fila: tarefas empatadas (ou quase) no score e tarefas que não se encaixam em nenhum nível da rubrica

Bora ver um de cada vez

Sintoma A: empate ou scores muito próximos

Causa: geralmente a rubrica tem poucos níveis ou níveis parecidos demais, e várias tarefas acabam no mesmo ponto

Solução: criar uma regra de desempate no seu código: o Jev entrega o score e o confidence, e a ordem final entre tarefas empatadas é decisão de design sua

Uma sugestão simples: desempatar pelo confidence (o mais confiante primeiro) e, se ainda empatar, por um critério do seu sistema, como a data de criação da tarefa

Em Python puro, com as tarefas já pontuadas e guardadas no seu banco, fica algo assim:

fila = sorted(
    tarefas,
    key=lambda t: (-t["score"], -t["confidence"], t["criada_em"])
)

Nada de SDK aqui, é só uma ordenação comum em cima dos campos que você salvou no passo 6 😀

Pode trocar a data por cliente, plano, SLA ou o que fizer sentido pro seu time

Sintoma B: tarefa que a rubrica não descreve bem

Sintoma: a probabilidade vem espalhada por vários níveis e o confidence vem baixo

Causa: a tarefa é de um tipo que a rubrica não cobre (tipo uma dúvida de faturamento caindo numa rubrica pensada para incidentes técnicos)

Não existe orientação oficial sobre o que o Score faz nesse caso, o que dá pra afirmar é só isso: probabilidade espalhada gera confidence baixo

Solução: defina um limite de confidence abaixo do qual a tarefa não entra direto na fila e vai pra triagem humana

Qual valor? Não tem número oficial pra isso, então você calibra olhando os seus próprios dados

Opcionalmente, dá pra colocar uma pergunta Noul antes do Score, algo como "esta tarefa é sobre um problema técnico do produto?"

Como o Noul devolve a probabilidade de "sim", você filtra o que a rubrica cobre e só manda pro Score o que faz sentido pontuar

Como prevenir:

• Revise de tempos em tempos as tarefas que foram pra triagem humana
• Procure padrões: se o mesmo tipo de tarefa cai sempre lá, falta um nível ou um nível está mal escrito
• Reescreva ou acrescente níveis, lembrando que o máximo é 10
• Depois de mexer na rubrica, recalibre o seu limite de confidence

A rubrica não nasce pronta, ela amadurece com a fila 🙂

Onde a pontuação de urgência com Score funciona bem

Fila de bugs reportados

É o caso mais natural, porque o próprio exemplo oficial é de gravidade de bug

Dá pra partir dos três níveis da doc (cosmético, quebrado com contorno, bloqueante sem contorno) e acrescentar degraus como "afeta só um usuário" ou "afeta todos os clientes" conforme a sua realidade

Tickets de suporte

A satisfação do cliente é citada na doc como exemplo de espectro, e ela conversa direto com urgência no suporte

Uma rubrica possível:

• cliente com dúvida simples, tom tranquilo
• cliente com problema, mas paciente e com alternativa
• cliente frustrado, problema afetando o trabalho dele
• cliente irritado, falando em cancelar ou escalar

Assim o ticket do cliente prestes a cancelar sobe na fila mesmo que ele não tenha escrito "URGENTE" em caixa alta haha

Backlog interno do time

Aqui a urgência costuma ser sobre prazo e dependência:

• melhoria sem data, ninguém depende dela
• tarefa com data, mas sem ninguém esperando
• tarefa que trava outra pessoa do time
• tarefa que trava uma entrega já combinada com cliente

E a mesma lógica de rubrica em degraus serve fora da engenharia também, por exemplo pra qualificar e priorizar leads num funil de vendas

Próximo passo: rode a rubrica numa amostra da sua fila

Recapitulando o fluxo:

• rubrica ordenada, do menos para o mais urgente, com níveis descritivos e sem sobreposição
• score em ordem decrescente, sem arredondar
• confidence pra desempatar (junto com uma regra sua) e pra mandar o que a rubrica não cobre pra triagem humana

O próximo passo prático é criar a conta no console, ler a doc com calma e pegar uma amostra de tarefas que o seu time já classificou na mão

Roda a rubrica nessa amostra e compara: o Jev ordenou parecido com o time? Onde discordou? Foi rubrica mal escrita ou tarefa fora do escopo?

Só depois de ajustar isso vale automatizar a fila inteira, beleza?

E aí, a sua fila hoje é ordenada por critério ou por quem grita mais alto? xD

Até o próximo post!