Determinismo é uma feature: agentes precisam de trilhos

Existe um demo que todo mundo nessa indústria já viu. Um agente recebe uma instrução vaga, "se vira", encadeia uma dúzia de chamadas de ferramenta e entrega o resultado enquanto a sala aplaude. É genuinamente impressionante. E é também, sem cortes, exatamente o comportamento que vira relatório de incidente quando você pluga isso em sistemas que importam.

Essa é a posição sobre a qual tocamos nossa empresa: determinismo é uma feature. Agentes em produção precisam de trilhos, não de vibes. Os times que estão colocando sistemas agênticos de pé — e sobrevivendo ao contato com operação real — convergiram todos para a mesma arquitetura fora de moda: um esqueleto determinístico, com o modelo acionado só nos pontos em que o julgamento realmente mora. Todo o resto é disciplina de engenharia que um bom time de software reconheceria vinte anos atrás.

O mercado vende o contrário, por motivos que a gente chega lá. Mas primeiro, o argumento.

Pare de pedir confiabilidade ao modelo

Modelos de linguagem são probabilísticos. Isso não é um defeito a ser corrigido — é justamente a propriedade que os torna valiosos. Eles lidam com ambiguidade, interpretam intenção, redigem, avaliam, classificam o inclassificável. Certeza nunca esteve no rótulo.

O pecado de engenharia, portanto, não é "o modelo errou". Modelos vão errar a alguma taxa para sempre. O pecado é colocar probabilidade onde o processo exigia certeza — deixar um modelo decidir como o dinheiro se move, o que é enviado, qual registro é gravado, quando uma máquina de estados simples poderia ter decidido isso perfeitamente, toda vez, de graça.

Então inverta a pergunta. Não pergunte "como tornamos o modelo confiável?". Pergunte "como tornamos o sistema confiável, dado um componente que é utilmente não confiável?". Essa é uma pergunta que engenheiro sabe responder. A gente constrói sistemas confiáveis a partir de peças não confiáveis — redes, discos, pessoas — desde que a computação existe.

A arquitetura: esqueleto e nós de julgamento

Todo sistema agêntico que entregamos na Gravitnomad se decompõe da mesma forma:

O esqueleto é código. Movimentação de dados, validação, formatação, retries, idempotência, transições de estado, agendamento, permissões, logging. Tipado, versionado, com teste unitário e code review. Se um passo pode ser especificado, ele tem que ser especificado — uma chamada de modelo no lugar onde deveria haver um if não é inteligência, é negligência com marketing melhor.
Nós de julgamento são chamadas de modelo, colocadas de propósito. "Em qual categoria essa solicitação se encaixa?" "Escreva a resposta para este e-mail atípico." "Esta cláusula foge dos nossos termos padrão, e como?" Cada nó tem um trabalho delimitado, recebe contexto curado e devolve saída dentro de um schema.
Nada do que um nó de julgamento diz é aceito cru. As saídas são validadas contra schemas e regras de negócio antes de o esqueleto agir. Uma resposta malformada ou fora de política não derruba o fluxo nem, pior, atravessa ele — ela dispara um retry, um fallback ou um humano.
Consequência tem portão. Tudo que sai porta afora — um e-mail, um pagamento, uma página publicada — passa por um gate de aprovação humana até que o histórico de evals tenha conquistado mais autonomia. Autonomia é concedida como promoção: aos poucos, com evidência.

Use o modelo onde mora o julgamento. Em todo o resto, escreva código. Código chato é a tecnologia de agentes mais avançada que temos.

Em volta do esqueleto ficam os guardrails que fazem a palavra significar alguma coisa: ações em allowlist (o agente pode fazer estas doze coisas e, estruturalmente, mais nada), tetos de orçamento para gasto e iterações, kill switches que um humano pode acionar e traces — cada passo, cada entrada, cada decisão logada, para que "o que aconteceu às 03:14 de domingo" seja uma query, não uma sessão espírita.

Evals: testes de regressão para julgamento

O esqueleto é coberto por testes comuns. Os nós de julgamento precisam do próprio instrumento, e é aqui que a maioria dos projetos de agente voa às cegas: suítes de avaliação.

Para cada nó de julgamento, mantemos um golden set — casos históricos reais com respostas conhecidas como boas, mais os adversariais: o e-mail ambíguo, o contrato com a cláusula esquisita, o input desenhado para confundir. Toda mudança no sistema — um ajuste de prompt, uma troca de modelo, uma nova fonte de contexto — roda contra a suíte antes de ir para produção. "Continua funcionando?" vira um número, não um sentimento.

É isso também que torna a rotatividade de modelos entediante, no melhor sentido. Quando aparece um modelo melhor ou mais barato — todo trimestre, sem falha — você troca por trás dos nós de julgamento, roda os evals e promove se passar. As garantias do sistema moram nos trilhos e nos testes, não nas release notes de nenhum fornecedor. Essa é a resposta arquitetural para a bagunça que descrevemos em O abismo entre a demo e a produção: demos exibem o teto do modelo; produção é sobre levantar o piso do sistema.

Por que a indústria vende vibes

Se trilhos são tão obviamente certos, por que o mercado insiste em comprar improviso?

Porque demo de autonomia levanta rodada e trilho não. "Agente totalmente autônomo substitui seu time de operações" é uma frase financiável. "Motor de workflow determinístico com chamadas de modelo delimitadas, validadores e fila de aprovação" é apenas verdadeira. Fornecedores demonstram o teto — o melhor caso deslumbrante. Você, comprador, vai operar o piso — o pior caso, em volume, numa sexta à noite. O buraco entre os dois é onde projetos de agente morrem, e nenhum benchmark mede isso.

Existe um segundo motivo, mais delicado: trilhos exigem entender o processo que você está automatizando. Improviso permite pular o trabalho desconfortável de especificar o que significa "correto". As vibes são estruturais justamente porque a especificação não existe.

Como isso fica na prática

Regra da casa: nada de clientes inventados, nada de números fictícios de uptime. Nossos próprios sistemas, que operamos todo dia, e um arquétipo.

O motor por trás deste site é o exemplo mais puro. Nosso motor multi-tenant renderiza sites inteiros — páginas, seções, mídia, artigos — a partir de dados estruturados de marca. Geração e julgamento (o que dizer, como a marca soa) acontecem antes, com modelos envolvidos; a camada de renderização em si é deliberadamente determinística. Mesmos dados na entrada, mesmo site na saída, toda vez, testável. Quando algo parece errado, a gente sabe qual metade interrogar.

O hub de publicação que produziu o artigo que você está lendo passa um briefing por agentes de escrita e depois por um pipeline determinístico — formatação, links cruzados, agendamento — com um gate de aprovação humana antes de qualquer coisa ir ao ar. A camada criativa é probabilística; nada probabilístico encosta no "publicar".

O assistente deste site responde a partir de retrieval sobre nossas páginas reais, com memória persistente, e seu comportamento mais importante é determinístico: quando o embasamento é fraco, ele diz isso e oferece um humano em vez de improvisar. (Memória, aliás, é a outra metade do que torna agentes confiáveis — o argumento de Agentes precisam de memória, não de modelos maiores.)

O arquétipo: um agente de recebimento de notas fiscais numa empresa de porte médio. O esqueleto captura, faz o parsing, cruza com ordens de compra e roteia; um nó de julgamento cuida só das correspondências genuinamente ambíguas; qualquer coisa abaixo de um limiar de confiança, acima de um limiar de valor ou fora da política cai numa fila humana com contexto completo. O agente nunca aprova os próprios casos de borda. É assim que a automação agêntica se parece quando espera passar por uma auditoria — e é o padrão de coordenação que generalizamos em Um orquestrador, muitas mãos.

Quanto determinismo é determinismo demais?

Honestidade intelectual exige o aviso inverso: dá para apertar os trilhos além da conta. Se você enumera todos os casos em código e deixa para o modelo apenas perguntas de múltipla escolha, você reconstruiu a fragilidade do no-code numa linguagem melhor — e vai sentir isso como um novo tipo de falha: o sistema que nunca erra e nunca serve.

A heurística que aplicamos: consequência determinística, interpretação probabilística. Tudo que move dinheiro, envia mensagens ou grava registros roda sobre trilhos, com portões. Mas a leitura de uma situação confusa — o que este e-mail está de fato pedindo, que tipo de documento é este, como enquadrar essa solicitação atípica — merece pista larga, porque a pista estreita só transfere a ambiguidade para uma fila humana.

O contexto também mexe no dial. Cargas de exploração — pesquisa, rascunho, análise de opções — podem improvisar com segurança, porque a saída é texto que um humano vai avaliar, não uma ação que o mundo vai absorver. Cargas de execução, não.

E fique de olho nos sintomas de aperto excessivo, porque eles são mensuráveis: nós de julgamento respondendo "outros" em taxa alta, humanos sobrepondo validadores toda hora, filas de exceção enchendo de falso positivo. Cada um deles significa que as paredes se fecharam demais. O ofício não é maximizar trilhos. É colocar trilhos exatamente onde mora a consequência, e confiar no julgamento em todo o resto.

Confiança é previsibilidade sob estresse

Times não adotam agentes porque a demo foi mágica. Eles adotam agentes cujos modos de falha são conhecidos, delimitados e visíveis — sistemas que falham como um bom colega falha: alto, cedo e dentro de um processo que segura a queda. Essa propriedade não emerge sozinha. Ela é projetada, e o projeto se chama trilhos.

Se você está avaliando um sistema agêntico — o nosso ou o de qualquer um — faça uma pergunta antes de todas: "me mostra o que acontece quando ele erra". Se a resposta for um schema, um limiar, uma fila e um trace, você está falando com engenheiros. Se a resposta for uma demo, você está falando com um pitch. A gente gosta de receber a versão difícil dessa pergunta: fale com a gente e traga seu workflow mais carregado de consequência. Vamos te mostrar as partes chatas primeiro — na nossa página de sistemas, as partes chatas são o pitch.