O mesmo LLM, usado em dois ambientes diferentes, produz resultados radicalmente diferentes. A inteligência crua do modelo é constante; o que varia é a infraestrutura ao redor dele. Essa infraestrutura tem um nome: harness.
O gargalo dos agentes atuais não é mais o modelo. É a qualidade do harness — as instruções, as ferramentas, os sensores, o ambiente de execução, os mecanismos de validação. Este artigo cobre o conceito do início ao fim: o que é harness, do que ele é feito, como os agentes falham quando ele é fraco e qual a arquitetura emergente para projetos que precisam ir além de features isoladas.
O Que É um Harness
"Harness" não tem tradução direta. Na prática, é o ambiente operacional que envolve o modelo: system prompt, ferramentas, sandbox, arquivos de contexto, linters, testes, scripts de bootstrap, mecanismos de memória e tudo o mais que executa ao redor do LLM. Se não é o modelo, é o harness.
Uma analogia útil: o modelo é um engenheiro recém-contratado, tecnicamente capaz, mas sem contexto. Largado num repositório sem README, sem arquitetura documentada, sem CI, sem testes, ele vai produzir saídas inconsistentes. Não por falta de inteligência — por falta de onboarding. O harness é esse onboarding, formalizado em código e configuração.
Agente = Modelo + Harness
Outra forma de dizer a mesma coisa, atribuída a Simon Willison: um agente é um LLM com acesso a ferramentas rodando em loop. A inteligência mora no modelo; a operação mora no harness.
Por Que o Modelo Sozinho Não Basta
Modelos de linguagem fazem uma coisa: recebem tokens e devolvem tokens. Não executam código, não persistem estado entre interações, não consultam dados em tempo real, não verificam o próprio output. Todas essas capacidades vivem no nível do harness.
Mesmo a interação mais básica — uma janela de chat — já é um harness mínimo: cada turno é anexado ao histórico, criando continuidade. É essa camada que separa uma chamada isolada de API de uma conversa contínua, e é também onde está a maior alavanca de melhoria para quem opera modelos.
A Anatomia de um Harness
Um harness não é monolítico — é um conjunto de componentes que, combinados, dão capacidades ao modelo. Cada um deles é também uma alavanca de tuning: pequenas mudanças aqui alteram qualidade, custo de tokens e latência.
System Prompt
A instrução-mestre: identidade do agente, missão, tom, restrições. Mudanças aqui têm efeito amplificado em todo o comportamento — e é também o componente mais subestimado.
Ferramentas e MCPs
Funções que o agente pode invocar para agir no mundo: ler arquivos, consultar APIs, gravar em banco. Cada ferramenta carrega uma descrição que ensina o modelo quando usá-la. Mais ferramentas significa mais capacidade, mas também mais ruído na decisão.
File System e Sandbox
Acesso controlado ao disco, para persistir estado, e ambiente isolado para executar código sem comprometer o host. Sem isso, o agente é amnésico e potencialmente perigoso.
Lógica de Orquestração
Como o agente principal dispara sub-agentes e roteia trabalho. Inclui roteamento de modelos: usar um modelo barato e rápido para exploração e um modelo capaz para decisões críticas.
Hooks e Middlewares
Lógica determinística em pontos específicos do ciclo: linter após cada edição, type check antes do commit, compactação ao se aproximar do limite de contexto. É como se injeta determinismo num sistema probabilístico.
Memória e Conhecimento
Memória persistente, busca vetorial, acesso à internet, CLIs de scraping ou documentação como Firecrawl e Context7. Tudo o que estende o conhecimento pré-treinado para a tarefa em mãos.
Skills
Arquivos .md carregados sob demanda (progressive disclosure). Em vez de despejar todo o conhecimento no contexto, o agente puxa apenas o que é relevante para a tarefa corrente.
Loops de Verificação
Mecanismos que permitem o agente conferir o próprio trabalho — testes, screenshots via Playwright, MCPs de avaliação. Base para autocorreção antes da entrega.
Feed Forward e Feedback: os Dois Pilares
O vocabulário vem da engenharia de controle e estrutura qualquer harness sério em dois pilares.
Feed Forward — Orientação antes da execução
Tudo que o agente recebe antes de tocar em código: specs, AGENTS.md, regras de arquitetura, skills, exemplos. É preventivo — direciona a execução para o caminho certo desde o início.
Feedback — Verificação depois da execução
Tudo que observa o resultado depois da execução e força correção: linters, testes, type checkers, agentes revisores. São sensores objetivos — não dependem do julgamento do próprio agente.
Analogia útil: o GPS traça a rota (feed forward) e recalcula quando você erra a saída (feedback). Sem rota, você sai sem direção; sem recálculo, você se perde no primeiro erro. Spec Driven puro é feed forward — extremamente valioso, mas só metade do harness. Fechar o loop exige feedback.
Os Cinco Padrões de Falha de Agentes Sem Harness
A Anthropic documentou os modos de falha mais comuns de agentes operando sem infraestrutura adequada. São padrões previsíveis — cada um tem uma contramedida específica no harness.
One-Shot Hero
O agente tenta entregar a aplicação inteira numa única sessão. Estoura janela de contexto no meio do caminho, alucina para preencher lacunas e deixa features pela metade. A próxima sessão começa em um campo minado.
Contramedida: decomposição via Spec Driven — quebrar o trabalho em tarefas pequenas, com critérios de conclusão explícitos e ordem definida.
Vitória Prematura
O agente declara "pronto" sem ter terminado. Tipicamente, isso acontece em contextos longos: a definição de pronto fica nebulosa e o modelo opta pelo encerramento.
Contramedida: spec com critérios de aceite verificáveis em cada tarefa. "Pronto" vira uma condição objetiva, não opinião do executor.
Amnésia Entre Sessões
Cada nova sessão começa do zero. O agente seguinte gasta metade dos tokens tentando reconstruir o que aconteceu antes. É como uma equipe que troca de turno sem passagem de bastão. A spec diz o que fazer, não o que já foi feito.
Contramedida: progress files versionados, disciplina de commits descritivos, scripts de bootstrap que reconstroem o contexto e memória persistente fora da janela. Aqui o Spec Driven sozinho não resolve.
Validação Falsa
O agente marca uma feature como pronta sem testar de fato. Dispara um curl, vê um 200 e segue adiante — mas o fluxo end-to-end está quebrado. O problema estrutural: quem julga o trabalho não pode ser quem o executou.
Contramedida: sensores externos obrigatórios — test runner, linter, type checker, smoke tests. O agente não decide se passou; o exit code decide.
Slope Acumulado
O código compila mas viola arquitetura, duplica lógica e ignora padrões locais. Cada sessão piora um pouco. Em projetos grandes, 5% de degradação por feature compõe até tornar a base inviável.
Contramedida: guard rails contínuos — agentes revisores, validação automatizada a cada passo e contratos arquiteturais explicitados no harness, não confiados à memória do modelo.
Arquitetura Emergente: Implementação e Validação em Processos Separados
A solução para validação falsa não é orientar melhor o agente implementador. É tirar dele o papel de validador. Um processo executa a implementação; outro processo, completamente independente, executa a validação — janela de contexto separada, system prompt separado, missão separada.
A razão é incentivada por design. Um agente cuja missão é implementar vai otimizar para entregar — inclusive removendo obstáculos como testes "chatos". Um agente cuja missão é validar vai otimizar para reprovar — vai cavar até achar uma quebra. Misturar as duas missões cria conflito de interesse interno e leva a auto-aprovação enviesada.
Na prática, uma camada de orquestração coordena: dispara o implementador, recebe o output, dispara o validador, alimenta o feedback de volta ao implementador, repete até convergir. É essa arquitetura que aparece nos pipelines de geração massiva de código documentados pela OpenAI e pela Anthropic.
Contratos Entre Agentes
Para que dois agentes independentes cooperem, precisa haver um contrato — uma lista acordada do que será entregue, conferida contra a spec antes da execução. O implementador propõe a lista; o validador confirma que ela atende ao escopo; só então o trabalho começa.
O contrato resolve três problemas práticos:
- Evita scope creep: sem lista acordada, o validador começa a sugerir coisas fora do escopo e o implementador entra em loop infinito.
- Garante completude: o validador percorre item por item; nada é marcado como pronto até todos passarem.
- Habilita autocorreção: falhas retornam ao implementador com referência ao item específico do contrato, não um relatório aberto.
Tracing e Avaliação Automatizada
Harness engineering depende de observabilidade. Sem registro do que o agente fez — quais ferramentas chamou, com quais parâmetros, quanto tempo cada passo durou, quantos tokens consumiu — não há como saber o que otimizar. Ferramentas como LangSmith, Langfuse ou traces nativos de plataformas como o Open Code servem para essa instrumentação.
Um trace bem feito alimenta decisões concretas no harness:
- "Toda vez que peço X, ele tenta Y antes" → ajuste no system prompt.
- "Chama a mesma ferramenta três vezes com parâmetros similares" → cache ou hook de deduplicação.
- "Inventa parâmetros fora do schema" → restringir o tipo no enum da ferramenta.
Em cima do trace roda a avaliação propriamente dita: o agente validador atribui scores por item do contrato — testes unitários, integração, Playwright, linters, type checks. Cada critério tem um mínimo objetivo. "Vai gastar mais tokens?" Sim. A troca é a mesma do code review humano: mais custo de processo, menos custo de regressão em produção.
O Casamento Entre Modelo e Harness
Produtos como Claude Code e Codex são pós-treinados dentro do harness em que vão rodar. Anthropic e OpenAI não otimizam seus modelos no vácuo — eles ajustam o modelo para o ecossistema específico onde ele opera. Por isso o mesmo modelo costuma render mais nas ferramentas oficiais do que via chamadas genéricas de API.
O outro lado dessa moeda é o espaço para construção própria. Um harness customizado, bem ajustado a um caso de uso específico, pode entregar resultados superiores aos do produto oficial para aquele recorte. O ganho disponível não é marginal: há relatos documentados de saltos de dezenas de posições em benchmarks públicos como Terminal-Bench apenas trocando o harness, sem trocar o modelo.
O Fundamento
Os modelos continuarão evoluindo. O que vai separar agentes que executam trabalho real de agentes que só fazem demo não é a próxima versão do LLM — é a qualidade da infraestrutura ao redor dele. Feed forward orientando antes; feedback objetivo corrigindo depois; agentes especializados em implementar e outros em validar; contratos formais ligando os dois; observabilidade alimentando o ciclo de tuning.
Em resumo:não foque apenas em escolher o modelo "mais inteligente". Foque em construir o harness que faça esse modelo render no contexto que importa. É onde está, em 2026, a maior alavanca disponível para quem opera IA em produção.