Um assistente recebe um pedido e precisa decidir qual ferramenta usar. Um modelo de linguagem poderia escrever uma explicação e, dentro dela, indicar a ferramenta. Mas o programa que vai executar a ação precisa de algo mais simples: uma escolha entre opções conhecidas. É nessa diferença que o Jev, da TypeSafe, se encaixa.
Esta série acompanha seis situações em que uma decisão curta pode mudar o desenho de um produto. Começamos pelo mecanismo: o Jev recebe um estado em texto e devolve respostas tipadas a perguntas específicas. Ele não escreve a resposta final para a pessoa, não gera imagens e não substitui sozinho o agente inteiro.
Três perguntas, três formas de resposta
Imagine o estado de um atendimento: a mensagem recebida, o histórico necessário e as ações permitidas. O aplicativo pode perguntar qual fila deve receber o caso, se há indício de urgência e quão bem a mensagem corresponde a um assunto. A documentação da TypeSafe organiza esse trabalho em três primitivas:
| Primitiva | Pergunta típica | Resultado útil |
|---|---|---|
| Choice | Qual opção se encaixa melhor? | Uma escolha entre alternativas delimitadas. |
| Noul | Esta condição está presente? | Um julgamento binário com probabilidade. |
| Score | Em que grau isto se aplica? | Uma nota em uma escala definida. |
O programa continua responsável por definir as opções, executar ou vetar ações e registrar o que aconteceu. Se nenhuma alternativa serve, inclua explicitamente uma opção como “nenhuma das anteriores”. Sem essa saída, até um caso fora do escopo será forçado para alguma categoria.
O que muda no fluxo
O padrão convencional costuma enviar contexto ao modelo, pedir uma resposta em linguagem natural ou JSON e depois interpretar o texto devolvido. Com o Jev, a aplicação formula a pergunta como uma decisão delimitada. Isso pode simplificar roteamento, filtros e checagens que se repetem muitas vezes. O restante do fluxo — regras de negócio, banco, permissões, ferramenta externa e eventual texto ao usuário — permanece na aplicação ou em outros modelos.
No catálogo de casos do portal, um harness de agente usa julgamentos curtos para verificar se uma etapa funcionou e se a tarefa terminou. A ideia interessante não é dar autonomia irrestrita ao modelo: é separar uma verificação repetitiva do trabalho de planejar e escrever. Esse exemplo vem de um projeto apresentado pela comunidade; o desempenho dele precisa ser testado no seu próprio ambiente.
Um primeiro teste sensato
Escolha uma decisão frequente e reversível, como separar solicitações em três filas. Reúna casos reais sem dados pessoais, inclua casos ambíguos e compare Jev com a regra ou processo atual. Anote erros por classe, tempo, custo completo e quantos itens ainda exigem revisão. Só então decida se a automação melhora o trabalho.
Nos próximos capítulos, esse mesmo princípio aparece em um navegador, na escolha de skills e na busca. No fim da série, voltamos ao ponto decisivo: quando confiar no julgamento e quando chamar uma pessoa.
