O Rato no Labirinto: por que Harness e Determinismo são a peça central dos Agentes Autônomos
Uma analogia clássica da psicologia comportamental revela o princípio mais ignorado na construção de agentes de IA: sem paredes, não há caminho.
Indice
Em 1930, Edward Tolman colocou ratos em labirintos e fez uma das observações mais importantes da psicologia do aprendizado: ratos que exploravam livremente, sem restrições, demoravam significativamente mais para encontrar a saída do que aqueles cujo caminho era limitado por paredes e portões. O rato “livre” vagava, repetia becos, circulava, gastava energia sem convergir. O rato guiado pelas paredes do labirinto aprendia mais rápido, errava menos e, eventualmente, internalizava o mapa cognitivo do trajeto.
Oito décadas depois, estamos repetindo exatamente o mesmo experimento, mas com Large Language Models no lugar dos ratos. E cometendo o mesmo erro de acreditar que liberdade total equivale a desempenho máximo.
Este artigo é sobre paredes. Sobre a infraestrutura determinística que envolve um modelo probabilístico e transforma potencial bruto em execução confiável. Sobre o conceito que a indústria passou a chamar de harness, e sobre por que a filosofia determinism-first é a peça que faltava para que agentes autônomos saiam do laboratório e entrem em produção.
O labirinto, o rato e o LLM
A analogia do rato no labirinto não é meramente ilustrativa. Ela é estruturalmente precisa. Um LLM, quando recebe acesso irrestrito a ferramentas e decide livremente a cada passo o que fazer, se comporta como o rato sem paredes: pode eventualmente chegar ao objetivo, mas o caminho será longo, errático, custoso e imprevisível. Ele repete ações, explora becos sem saída, perde contexto acumulado e, em cenários complexos, entra em loops de autocorreção que consomem tokens sem produzir progresso.
A engenharia de harness reconhece que o modelo é o rato: inteligente, adaptativo, capaz de raciocinar. Mas que inteligência sem estrutura não escala. As paredes do labirinto não tornam o rato menos inteligente; elas canalizam sua inteligência para que a exploração seja produtiva. De forma análoga, o harness não limita o LLM. Ele define as fronteiras dentro das quais a capacidade probabilística do modelo pode operar com eficiência máxima.
Definição Central. Agente = Modelo + Harness. O harness é toda a infraestrutura de software que envolve o LLM: orquestração de workflow, validação determinística, gerenciamento de contexto, memória de estado, feedback loops, sensores, guias e gates de aprovação. É tudo aquilo que não é o modelo, mas que determina se o modelo opera de forma confiável.
Birgitta Böckeler, Distinguished Engineer na Thoughtworks, sistematizou este conceito em seu trabalho sobre harness engineering para agentes de código. Ela divide os controles do harness em duas categorias: guias (controles feedforward que antecipam o comportamento do agente e o orientam antes da ação) e sensores (controles de feedback que observam o resultado e permitem autocorreção). Cada um desses pode ser computacional (determinístico e rápido) ou inferencial (semântico, usando outro LLM como juiz).
A combinação de guias e sensores cria o que ela descreve como um ciclo virtuoso: sem guias, o agente repete os mesmos erros porque nunca recebeu a regra; sem sensores, o agente segue regras mas nunca descobre se elas funcionaram. É a parede e o mapa. É o labirinto que simultaneamente restringe e ensina.
O caso contra a autonomia total
Existe uma tentação natural na comunidade de IA: se o modelo é cada vez mais inteligente, por que não dar a ele autonomia total? Que decida por conta própria quais ferramentas usar, em qual ordem, com quais parâmetros. É o que a Qodo chamou internamente de abordagem “YOLO”, um agente “all-knowing” que vasculha livremente todas as ferramentas disponíveis.
A Qodo, ao construir agentes de código com LangGraph e MCP, aprendeu por experiência que essa abordagem falha em produção. Seu princípio guia se tornou uma frase simples e poderosa: “Se você não precisa de um LLM, não use um LLM.” A equipe passou a construir fluxos com opinião, cada sub-agente com um propósito específico, cada nó do grafo classificado como estático (determinístico), LLM (gerativo) ou agêntico (com autonomia limitada). A autonomia não foi eliminada; foi posicionada nos nós onde faz diferença.
| Sem Harness (“Rato livre”) | Com Harness (“Labirinto estruturado”) |
|---|---|
| Agente decide tudo a cada passo. Tool calls em sequência imprevisível. Contexto se dilui. Erros se acumulam. Custo de tokens escala exponencialmente. | Workflow define a topologia. Nós determinísticos validam antes e depois. LLM é invocado apenas onde raciocínio semântico é necessário. Estado é persistido. |
| Resultado: inconsistente, não-auditável, impossível de depurar. | Resultado: previsível, auditável, recuperável, escalável. |
A Salesforce chegou à mesma conclusão por um caminho diferente. Ao desenvolver o Agentforce, a equipe de Phil Mui identificou o que chamou de “doom-prompting”, o ciclo vicioso de ajustar instruções, refinar dados e torcer por consistência que nunca chega. A solução deles foi o Agent Graph, uma arquitetura de “determinismo guiado” que usa máquinas de estado finito para gerenciar transições entre agentes, preservando a compreensão de linguagem natural do LLM enquanto garante fidelidade operacional.
A lição é convergente: empresas de escala diferentes, em domínios diferentes, chegaram ao mesmo insight. O raciocínio do LLM sozinho não sustenta carga empresarial. A inteligência precisa de trilhos.
Determinism-First: o princípio arquitetural
O que estamos chamando de determinism-first não é a eliminação do LLM do processo decisório. É a inversão da hierarquia. Em vez de um modelo probabilístico que ocasionalmente chama funções determinísticas, temos um motor determinístico que invoca o modelo em pontos específicos do workflow para tarefas que genuinamente requerem raciocínio semântico.
O paper “Blueprint First, Model Second” (Qiu et al., Alibaba, 2025) formaliza este princípio com o framework SOURCE CODE AGENT. A ideia é simples e radical: um procedimento operacional definido por especialistas é codificado em um blueprint de execução (código Python que define sequência de passos, lógica condicional e pontos de decisão). Um motor determinístico executa este blueprint com fidelidade total. O papel do modelo fundacional é estrategicamente reconfigurado: não é mais o decisor central, mas uma ferramenta especializada invocada em nós específicos para tarefas complexas mas delimitadas, como interpretar um log de erro ou resumir a saída de um comando.
Princípio. Separação de responsabilidades: o motor determinístico gerencia o blueprint do workflow; o modelo inteligente lida com subtarefas discretas. Cada um faz aquilo que faz melhor.
Os resultados experimentais do paper são significativos: ao impor um workflow determinístico, a abordagem melhora significativamente as taxas de sucesso em tarefas e a eficiência operacional. Um módulo de “Double-Check” (um passo codificado que intercepta ações propostas, valida contra regras e solicita reavaliação do modelo) transforma o agente de um preditor reativo em um executor metódico.
O mcp-agent, framework open-source da LastMile AI, implementa esses padrões no contexto do MCP. O projeto adicionou verificação determinística de planos antes da execução, validação que checa se o plano gerado pelo LLM é estruturalmente válido, se as dependências fazem sentido, se os recursos referenciados existem. Se a verificação falha, o orquestrador gera uma mensagem de erro estruturada e solicita um novo plano. É o sensor computacional em ação: barato, rápido, determinístico, rodando em cada mudança.
Anatomia de um Workflow Determinism-First
Input do Usuário → Roteamento Determinístico → LLM: Intent Parser → Validação de Plano → LLM: Executor → Verificação + Testes → Output Validado
O padrão é claro: o LLM aparece em dois pontos (interpretação de intent e execução), enquanto o restante do pipeline é determinístico. Roteamento, validação e verificação não precisam de raciocínio semântico. São operações codificáveis, testáveis e reproduzíveis.
MCP: o protocolo que viabiliza o harness interoperável
Se o harness é a infraestrutura que envolve o modelo, o Model Context Protocol (MCP) é o contrato que padroniza como as ferramentas dessa infraestrutura se comunicam. Desenvolvido pela Anthropic, o MCP funciona como uma interface universal entre agentes (clientes MCP) e capacidades externas (servidores MCP): bancos de dados, APIs, sistemas de arquivos, ferramentas de busca, grafos de conhecimento.
A importância do MCP para o paradigma determinism-first está na padronização. Sem um protocolo unificado, cada integração exige código ad-hoc, cada ferramenta tem sua própria interface, e o harness se torna uma colcha de retalhos frágil e impossível de manter. Com MCP, as ferramentas são expostas uma vez através de um servidor padronizado e ficam disponíveis para qualquer cliente: Claude Desktop, Cursor, agentes customizados, ferramentas de CI/CD.
O Graph Workflow, publicado no MCP Market, exemplifica a convergência entre grafos, MCP e determinismo. A ferramenta transforma documentos de requisitos (PRDs) em grafos de tarefas hierárquicos com dependências explícitas, persistidos em SQLite. O agente não improvisa a decomposição do trabalho. O grafo define a topologia, as dependências determinam a ordem de execução, e o contexto é comprimido em 70-85% para otimizar o consumo de tokens. É o labirinto construído algoritmicamente a partir do objetivo.
Projetos como o MCP Agent Graph levam a ideia além, integrando sub-agentes, memória de longo prazo e workflow visual em um sistema onde nós podem dinamicamente selecionar o próximo passo, mas sempre dentro dos limites do grafo definido. A autonomia do agente não é eliminada; é canalizada pelo grafo, como o rato pelas paredes.
Do laboratório à produção: evidências concretas
Stripe: 1.000+ PRs por semana com Minions
A Stripe revelou que seu sistema Minions (agentes de código one-shot, end-to-end) produz mais de mil pull requests fundidos por semana, todos gerados sem intervenção humana durante a execução, com revisão humana obrigatória antes do merge. A arquitetura é orientada a execução não-assistida em ambiente isolado, com testes determinísticos, remediação limitada e aprovação humana como gate de controle. A Stripe concluiu que a fonte decisiva de valor não é o modelo único, mas a qualidade do “envelope de execução” ao redor dele.
Datadog: Harness-First Engineering
A equipe de engenharia da Datadog adotou explicitamente o princípio de harness-first engineering: em vez de revisar cada linha de código gerado por agentes, investir em verificações automatizadas que determinam com alta confiança, em segundos, se o código é correto. No projeto redis-rust, eles usaram Deterministic Simulation Testing (DST) com milhões de seeds para validar invariantes: linearizabilidade, consistência de transações, garantias de ordering. Bugs que revisão humana talvez encontrasse “num dia bom” foram capturados deterministicamente, em segundos.
O padrão da Datadog é cristalino: o agente gera código, o harness verifica, telemetria de produção valida, e se algo está errado, o feedback atualiza o harness e o agente tenta novamente. O loop é fechado por observabilidade, não por esperança.
Process Street: o agente que não improvisa
A Process Street implementou workflows como servidores MCP, expondo cada etapa (formulários, gates de aprovação, lógica condicional) como ferramentas chamáveis por agentes. O resultado é um agente que opera dentro do processo, não acima dele. Quando o workflow exige aprovação gerencial, o agente para, notifica o gerente e espera. Nenhuma capacidade de agente pode ultrapassar esse gate, porque o workflow é determinístico. A aprovação não é uma sugestão. É uma restrição estrutural.
Antipadrão. Confiar no prompt para impor restrições operacionais. Um prompt pode dizer “rode testes depois de escrever código”. Mas nada impede o agente de pular essa etapa. Um harness garante que o workflow não pode avançar até que o passo determinístico de teste tenha sido executado e aprovado.
Por que agentes falham: a taxonomia estrutural
Uma análise empírica de larga escala conduzida sobre 13.602 issues em 40 repositórios open-source de agentes revelou uma taxonomia de 37 tipos de falha. A descoberta central é reveladora: a maioria das falhas origina-se de incompatibilidades entre artefatos gerados probabilisticamente e restrições de interface determinísticas. Ou seja, um problema estrutural de harness, não de capacidade do modelo.
Isso confirma a analogia do labirinto de forma quantitativa. O rato não falha por falta de inteligência; falha porque as paredes (ou a falta delas) não foram projetadas para canalizar sua exploração de forma produtiva. Da mesma forma, quando um agente gera um JSON malformado, invoca uma tool com parâmetros inválidos ou entra em loop tentando uma ação que o sistema não suporta, o problema não é o modelo. É a ausência de validação determinística entre a saída probabilística e a entrada determinística.
O paper de Natural-Language Agent Harnesses (2026) vai ainda mais longe ao propor que o controle do harness pode ser expresso em linguagem natural executável, não substituindo código determinístico, mas carregando lógica de orquestração editável e inspecionável enquanto adaptadores e scripts fornecem os hooks determinísticos (testes, linters, scrapers, verificadores). Os resultados experimentais mostram que módulos de verificação, busca multi-candidato e orquestração dinâmica concentram seus efeitos em uma fronteira de resolução, transformando tarefas que antes falhavam em sucessos, sem alterar o modelo subjacente.
Um framework para decidir o que é determinístico
A pergunta prática que emerge é: como decidir quais partes do workflow devem ser determinísticas e quais devem ser delegadas ao LLM? O framework que se consolidou na indústria segue uma heurística simples:
Se o caminho é conhecido, use workflow determinístico. Se a entrada segue um padrão, a validação pode ser codificada, o output tem formato previsível. Nesse caso, o LLM é desnecessário e contraproducente. Parse de arquivos, formatação de dados, execução de testes, roteamento por regras, verificação de schema: tudo isso é domínio do código convencional.
Se o caminho é desconhecido mas o objetivo é claro, considere um agente com harness. A ambiguidade do input, a necessidade de investigação, diagnóstico ou raciocínio sobre contexto não-estruturado: esses são os momentos onde o LLM agrega valor. Mas mesmo aqui, o agente deve operar dentro de guardrails: budget de tokens, limite de tool calls, validação de output, checkpoints de recuperação.
Se nem o caminho nem o objetivo são claros, mantenha humanos no loop. Reduzir o escopo, solicitar clarificação, não delegar para a autonomia total. Agentes autônomos funcionam quando o espaço de solução é definido, não quando é infinito.
Voltando ao labirinto
O rato de Tolman nos ensinou algo que a engenharia de IA está redescobrindo: restrições são o mecanismo do aprendizado eficiente, não seu inimigo. O labirinto não pune o rato. Ele codifica o problema de forma que o rato possa resolvê-lo de maneira produtiva. Cada parede é uma informação: “não vá por aqui”. Cada portão é um checkpoint: “valide antes de continuar”. Cada caminho é um contrato: “se você segue esta sequência, chega ao objetivo.”
Harness engineering é a disciplina de construir esses labirintos para LLMs. O Model Context Protocol é o padrão que permite que as paredes sejam interoperáveis. O princípio determinism-first é a filosofia que coloca a estrutura como fundação e a inteligência como ferramenta.
A fórmula que emerge da convergência de papers, frameworks e experiências de produção é esta: o agente mais eficiente não é o mais autônomo. É aquele cujo harness foi melhor engenheirado. A Stripe não tem o melhor modelo; tem o melhor envelope de execução. A Datadog não eliminou bugs com IA; eliminou bugs com simulação determinística que validava a IA. A Process Street não treinou agentes mais inteligentes; construiu workflows que nenhum agente pode subverter.
No fim, a pergunta não é “quão inteligente é o rato?”. A pergunta é “quão bem projetado é o labirinto?”.
Referências e Leitura Adicional
- Böckeler, B. (2026). “Harness Engineering for Coding Agent Users.” martinfowler.com
- Qiu, L. et al. (2025). “Blueprint First, Model Second: A Framework for Deterministic LLM Workflow.” Alibaba Group. arxiv.org
- Anthropic (2024). “Building Effective Agents.” anthropic.com
- Anthropic (2025). “Writing Effective Tools for AI Agents.” anthropic.com
- Datadog (2026). “Closing the Verification Loop: Observability-Driven Harnesses.” datadoghq.com
- Mui, P. (2026). “Agentforce’s Agent Graph: Toward Guided Determinism.” engineering.salesforce.com
- LastMile AI, mcp-agent: Build Effective Agents Using MCP. github.com
- Graph Workflow, MCP Market. mcpmarket.com
- Qodo (2025). “Building Agentic Flows with LangGraph and Model Context Protocol.” qodo.ai
- Process Street (2026). “Agents Do Not Improvise Well.” process.st
- Costa, R. et al. (2026). “Natural-Language Agent Harnesses.” arxiv.org
- awesome-harness-engineering, Curated Resources. github.com
- MCP Agent Graph, Multi-Agent System Built on Context Engineering. github.com
- Anthropic (2025). “Demystifying Evals for AI Agents.” anthropic.com