O determinismo é uma funcionalidade: os agentes precisam de carris, não de vibes

Há uma demo que toda a gente nesta indústria já viu. Um agente recebe uma instrução vaga, «desenrasca-se», encadeia uma dúzia de chamadas a ferramentas e acerta no resultado enquanto a sala aplaude. É genuinamente impressionante. E é também, sem edição, exatamente o comportamento que gera relatórios de incidente quando o ligamos a sistemas que interessam.

Esta é a posição que orienta a nossa empresa: o determinismo é uma funcionalidade. Os agentes em produção precisam de carris, não de vibes. As equipas que estão a pôr em campo sistemas agênticos capazes de sobreviver ao contacto com operações reais convergiram todas para a mesma arquitetura fora de moda — um esqueleto determinístico, com o modelo invocado apenas nos pontos onde o julgamento existe de facto. Todo o resto é disciplina de engenharia que uma boa equipa de software reconheceria há vinte anos.

A indústria vende o contrário, por razões a que voltaremos. Mas primeiro, o argumento.

Deixe de exigir fiabilidade ao modelo

Os grandes modelos de linguagem são probabilísticos. Isso não é um defeito à espera de correção — é a propriedade que os torna valiosos. Lidam com ambiguidade, interpretam intenções, redigem, avaliam, classificam o inclassificável. A certeza nunca constou do rótulo.

O pecado de engenharia, portanto, não é «o modelo enganou-se». Os modelos vão errar a alguma taxa para sempre. O pecado é pôr probabilidade onde o processo precisava de certeza — deixar um modelo decidir como se move o dinheiro, o que é enviado, que registo é escrito, quando uma simples máquina de estados podia ter decidido isso na perfeição, sempre, de graça.

Por isso, inverta a pergunta. Não pergunte «como tornamos o modelo fiável?». Pergunte «como tornamos o sistema fiável, tendo um componente que é utilmente pouco fiável?». Essa é uma pergunta que os engenheiros sabem responder. Construímos sistemas de confiança a partir de peças pouco fiáveis — redes, discos, pessoas — desde que a computação existe.

A arquitetura: esqueleto e nós de julgamento

Todos os sistemas agênticos que entregamos na Gravitnomad se decompõem da mesma maneira:

• O esqueleto é código. Movimento de dados, validação, formatação, retentativas, idempotência, transições de estado, agendamento, permissões, registos. Tipado, versionado, com testes unitários e revisão de código. Se um passo pode ser especificado, tem de ser especificado — uma chamada ao modelo onde devia estar um if não é inteligência, é negligência com melhor marketing.
• Os nós de julgamento são chamadas ao modelo, colocadas de propósito. «Em que categoria cai este pedido?» «Redige a resposta a este email invulgar.» «Esta cláusula desvia-se das nossas condições padrão, e em quê?» Cada nó tem uma função delimitada, recebe contexto curado e devolve output dentro de um schema.
• Nada do que um nó de julgamento diz é aceite em bruto. Os outputs são validados contra schemas e regras de negócio antes de o esqueleto agir sobre eles. Uma resposta malformada ou fora de política não parte o fluxo nem, pior, corre por ele fora — despoleta uma retentativa, um fallback ou um humano.
• As consequências têm portões. Tudo o que sai porta fora — um email, um pagamento, uma página publicada — passa por um portão de aprovação humana até o histórico de evals lhe ter merecido mais autonomia. A autonomia concede-se como uma promoção: aos poucos, com provas.

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

À volta do esqueleto ficam os guardrails que dão sentido à palavra: ações em allowlist (o agente pode fazer estas doze coisas e, estruturalmente, mais nada), tetos de orçamento para gastos e iterações, botões de emergência que um humano pode carregar, e traces — cada passo, cada input, cada decisão registada, para que «o que aconteceu às 03:14 de domingo» seja uma query e não uma sessão espírita.

Evals: testes de regressão para o julgamento

O esqueleto está coberto por testes normais. Os nós de julgamento precisam de instrumento próprio, e é aqui que a maioria dos projetos de agentes voa às cegas: as suites 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 email ambíguo, o contrato com a cláusula esquisita, o input desenhado para confundir. Cada alteração ao sistema — um ajuste no prompt, uma troca de modelo, uma nova fonte de contexto — corre contra a suite antes de entrar em produção. «Continua a funcionar?» passa a ser um número, não uma sensação.

É também isto que torna a rotatividade de modelos aborrecida, no melhor sentido. Quando aparece um modelo melhor ou mais barato — todos os trimestres, pontualmente — troca-se por trás dos nós de julgamento, correm-se os evals e promove-se se passar. As garantias do sistema vivem nos carris e nos testes, não nas release notes de nenhum fornecedor. É esta a resposta arquitetural à confusão que descrevemos em O abismo entre a demo e a produção: as demos exibem o teto do modelo; a produção trata de subir o chão do sistema.

Porque é que a indústria vende vibes

Se os carris são tão obviamente a opção certa, porque continua o mercado a comprar improviso?

Porque as demos de autonomia levantam rondas de financiamento e os carris não. «Agente totalmente autónomo substitui a sua equipa de operações» é uma frase financiável. «Motor de workflows determinístico com chamadas ao modelo delimitadas, validadores e uma fila de aprovação» é apenas verdade. Os fornecedores demonstram o teto — o melhor caso, deslumbrante. O comprador vai operar o chão — o pior caso, em volume, a uma sexta-feira à noite. É nessa distância que os projetos de agentes morrem, e nenhum benchmark a mede.

Há uma segunda razão, mais subtil: os carris exigem perceber o processo que se está a automatizar. O improviso permite a toda a gente saltar o trabalho incómodo de especificar o que significa «correto». As vibes são estruturais precisamente porque falta a especificação.

O que isto é na prática

Regra da casa: sem clientes inventados, sem números de uptime fictícios. Os nossos próprios sistemas, que operamos todos os dias, e um arquétipo.

O motor por trás deste site é o exemplo mais puro. O nosso motor multi-tenant renderiza sites inteiros — páginas, secções, media, artigos — a partir de dados estruturados de marca. A geração e o julgamento (o que dizer, como soa a marca) acontecem a montante, com modelos pelo meio; a camada de renderização é deliberadamente determinística. Os mesmos dados à entrada, o mesmo site à saída, sempre, testável. Quando algo parece errado, sabemos qual das metades interrogar.

O hub de publicação que produziu o artigo que está a ler faz passar um briefing por agentes de redação até um pipeline determinístico — formatação, ligações cruzadas, agendamento — com um portão de aprovação humana antes de seja o que for se tornar público. A camada criativa é probabilística; nada de probabilístico toca no «publicar».

O assistente deste site responde a partir de retrieval sobre as nossas páginas reais, com memória persistente, e o seu comportamento mais importante é determinístico: quando o grounding é fraco, di-lo e propõe um humano em vez de improvisar. (A memória, já agora, é a outra metade do que torna os agentes de confiança — é o argumento de Os agentes precisam de memória, não de modelos maiores.)

O arquétipo: um agente de receção de faturas numa empresa de média dimensão. O esqueleto ingere, faz parsing, cruza com as ordens de compra e encaminha; um nó de julgamento trata apenas das correspondências genuinamente ambíguas; tudo o que fique abaixo de um limiar de confiança, acima de um limiar de valor ou fora de política aterra numa fila humana com contexto completo. O agente nunca aprova os seus próprios casos-limite. É este o aspeto da automação agêntica quando espera passar numa auditoria — e é o padrão de coordenação que generalizamos em Um orquestrador, muitas mãos.

Quanto determinismo é determinismo a mais?

A honestidade intelectual exige o aviso inverso: os carris podem apertar demasiado. Se enumerar todos os casos em código e deixar ao modelo apenas perguntas de escolha múltipla, reconstruiu a fragilidade do no-code numa linguagem melhor — e vai senti-lo como um novo tipo de falha: o sistema que nunca se engana e nunca serve para nada.

A heurística que aplicamos: consequências determinísticas, interpretação probabilística. Tudo o que move dinheiro, envia mensagens ou escreve registos corre sobre carris e com portões. Mas a leitura de uma situação confusa — o que pede afinal este email, que tipo de documento é este, como enquadrar este pedido invulgar — merece uma via larga, porque uma via estreita limita-se a transferir a ambiguidade para uma fila humana.

O contexto também mexe no botão. Cargas de trabalho de exploração — investigação, rascunhos, análise de opções — podem improvisar em segurança, porque o seu output é texto que um humano vai avaliar, não uma ação que o mundo vai absorver. As cargas de execução não podem.

E atenção aos sintomas de aperto excessivo, porque são mensuráveis: nós de julgamento a responder «outro» com frequência elevada, humanos a contornar validadores por rotina, filas de exceção a encher de falsos positivos. Cada um deles significa que as paredes se fecharam demasiado. A arte não está em carris a mais. Está em carris exatamente onde vivem as consequências, e julgamento de confiança em todo o resto.

Confiança é previsibilidade sob pressão

As equipas não adotam agentes porque a demo foi mágica. Adotam agentes cujos modos de falha são conhecidos, delimitados e visíveis — sistemas que falham como falha um bom colega: alto, cedo e para dentro de um processo que o apanha. Essa propriedade não é emergente. É desenhada, e ao desenho chama-se carris.

Se está a avaliar um sistema agêntico — o nosso ou o de quem quer que seja — faça primeiro uma pergunta: «mostrem-me o que acontece quando ele se engana». Se a resposta for um schema, um limiar, uma fila e um trace, está a falar com engenheiros. Se a resposta for uma demo, está a falar com um pitch. Gostamos que nos façam a versão difícil dessa pergunta: fale connosco e traga o seu workflow mais carregado de consequências. Mostramos-lhe primeiro as partes aborrecidas — na nossa página de sistemas, as partes aborrecidas são o argumento de venda.