Você construiu um agente. Funcionou em teste. Colocou em produção. Ele começou a fazer coisas estranhas — loop infinito, memória contaminada, ações que você não autorizou. A primeira hipótese: "o modelo está alucinando". A hipótese correta: o harness não existe.
O agente não é a parte difícil de um sistema agêntico. O harness é. E a maioria dos practitioners que constrói agentes hoje ainda não tem um.
O que é harness agêntico — e por que o nome importa
O termo vem da metáfora do arnês de cavalo: rédeas, sela, freio. O conjunto completo de equipamento que canaliza um animal poderoso e imprevisível na direção correta. Sem arnês, o cavalo vai onde quer. Com arnês, o cavaleiro dirige.
Em sistemas de IA, a equação é: Agente = Modelo + Harness. O modelo é a capacidade de raciocínio. O harness é tudo que governa como o modelo percebe o ambiente, decide o que fazer, executa ações e valida resultados.
O problema é que a maioria dos courses de "construa seu agente em 15 minutos" ensina apenas o modelo. Você aprende a chamar a API, encadear prompts, conectar tools. Não aprende a construir o arnês. E quando o agente vai para produção sem arnês, você descobre o custo real disso.
Os 7 padrões que fazem um harness funcionar em produção
Engenharia de harness agêntico não é uma técnica única — é um conjunto de padrões que, combinados, tornam sistemas agênticos previsíveis, auditáveis e seguros para rodar sem supervisão constante.
1. Harness de restrição (Constraint Harness)
Reduz o espaço de solução do agente antes da geração começar. Funciona como type system para agentes: define como o output "correto" deve parecer antes de qualquer token ser gerado.
Exemplos práticos: arquivos de regras que forçam convenções de código, linters que rodam antes da execução, system prompts que delimitam o escopo exato de atuação. O Claude Code usa CLAUDE.md exatamente assim — antes de qualquer ação, o agente já sabe o que pode e não pode fazer.
2. Feedback loops estruturados
Retornam sinais de erro estruturados ao agente, permitindo auto-correção autônoma. O ciclo: agente gera → validator valida → feedback retorna → agente refina. Sem feedback estruturado, o agente nunca sabe se acertou ou errou — repete o mesmo erro indefinidamente.
A diferença crítica: feedback não estruturado ("deu erro") vs. feedback estruturado ("linha 47, tipo incompatível, esperado string, recebido int"). O segundo permite correção. O primeiro gera loop.
3. Permission gates (controles de permissão)
Infraestrutura que decide o que o agente pode fazer — com granularidade real. O agente nunca toca o sistema de arquivos, banco de dados ou API diretamente. O harness intercede: "Este comando de leitura é permitido? Este write é seguro? Esta ação é irreversível?"
A pesquisa de taxonomia de falhas da Microsoft com 145 practitioners identificou que 15,2% das falhas mais frequentes em sistemas agênticos são violações de constraints de tarefa — o agente faz o que não foi autorizado a fazer. Permission gates são a solução direta para esse problema.
4. Arquitetura de memória com transparência
A memória do agente precisa ser inspecionável e editável. O maior risco de sistemas agênticos sem harness é o que a indústria chama de "memory poisoning" — contexto corrompido que faz o agente agir de forma imprevisível.
O Claude Code usa MEMORY.md (Markdown simples): não opaco, não caixa-preta. Os primeiros 25KB carregam automaticamente no início de cada sessão. O usuário pode ler, editar, deletar, versionar. Isso não é detalhe de implementação — é decisão arquitetural consciente de que memória auditável é pré-requisito para sistemas confiáveis.
5. Isolamento de ferramentas (Tool Isolation)
Agentes não executam ferramentas diretamente — o harness executa. Cada tool call passa por validação → execução → sanitização de output → compactação de contexto. Agentes com acesso direto a ferramentas sem isolamento são vetores de risco: um único prompt malicioso pode escalar para ações que destroem dados.
Sub-agentes em sistemas multi-agente não compartilham acesso direto a ferramentas. Coordenam via orchestrator, que mantém o estado global e controla o fluxo de permissões.
6. Orquestração de sub-agentes
Padrões para múltiplos agentes trabalhando juntos sem deadlock, sem dominância de um agente sobre os outros, sem estados inconsistentes. Os padrões mais estáveis: orchestrator-worker (orquestrador centralizado, workers especializados), planner-generator-evaluator (planejamento separado de execução) e consensus (múltiplos agentes validam antes de executar).
O princípio crítico: ownership de estado. O orchestrator possui o estado do workflow. Agentes fornecem julgamento limitado. Ferramentas executam ações determinísticas. Quando ownership é ambíguo, sistemas multi-agente inevitavelmente entram em deadlock.
7. Fases de ciclo de vida explícitas
Estrutura Plan → Work → Review → Execute com gates entre fases. Impede que agentes saiam do caminho sem checkpoint. A transição entre fases é explícita e auditável — não é o agente que decide quando avançar, é o harness que autoriza a progressão.
As três falhas mais comuns em sistemas sem harness
A pesquisa da Microsoft identificou que 83,8% dos practitioners reportaram que a taxonomia de falhas cobria situações que eles pessoalmente enfrentaram. Três delas dominam o cotidiano de quem constrói agentes sem harness:
Memory poisoning: Um usuário (ou input malicioso) injeta instruções no histórico de contexto. O agente, sem camada de validação, segue as instruções injetadas como se fossem legítimas. Sem harness de memória, não há como distinguir contexto legítimo de contexto injetado.Context overflow e erros em cascata: O agente acumula erro após erro. Cada erro gera mensagem de erro longa. A memória cresce até o limite do contexto. No token limite, o agente perde o fio condutor e começa a improvisar — o que practitioners descrevem como "alucinar". Com harness: detecção de loops (repete 3x? Falha rápido), compactação inteligente de contexto, circuit breakers.
Deadlock de coordenação: Agent A aguarda resposta de Agent B. Agent B aguarda aprovação humana. Sistema inteiro trava indefinidamente. Com harness: timeouts explícitos em handoffs, escalation automática, estados claramente definidos com ownership explícito.
Por que 2026 é o ano do harness — não dos agentes
2025 foi o ano em que agentes provaram que funcionam. 2026 é o ano em que a indústria aprende que o agente não é a parte difícil — a infraestrutura é. O modelo está ficando comoditizado. O diferencial competitivo está no harness.
Um sinal concreto: em agosto de 2025, OpenAI, Google, Cursor e Factory lançaram o AGENTS.md — especificação aberta para documentação de agentes, funcionando como "contrato" entre modelo e harness. Não é coincidência que as maiores empresas de AI da indústria estejam convergindo em torno de padrões de harness, não em modelos mais potentes.
O guidance oficial da Anthropic sobre sistemas agênticos confiáveis resume em três princípios: simplicidade no design, transparência (o planejamento do agente deve ser visível), e interfaces bem definidas entre agente e ferramentas. Os três são componentes de harness, não de modelo.
O que separa o praticante do engenheiro de harness
Existe uma distinção que a maioria dos cursos de IA ignora deliberadamente, porque é mais difícil de vender: usar ferramentas de IA é diferente de construir sistemas agênticos confiáveis.
- Usar ferramenta: Claude responde uma pergunta. ChatGPT gera texto. O modelo faz o trabalho.
- Construir sistema agêntico sem harness: Agente em loop, conectado a tools, com memória crescente e sem validação. Funciona uma vez.
- Construir sistema agêntico com harness: Constraint harness + permission gates + memory architecture + feedback loops. Funciona em produção, é auditável, degrada de forma previsível quando algo dá errado.
A diferença não está no modelo. Está na infraestrutura ao redor do modelo. E é exatamente essa infraestrutura que cursos de "construa seu agente em um fim de semana" consistentemente pulam.
Leia também
- Quando o governo cria portal de IA para trabalhadores, a pergunta certa não é "vou perder o emprego?"
- A OpenAI tem previsões internas catastróficas de receita. A resposta deles: mais urgência para você
- O ChatGPT Plus vai de 44 milhões para 9 milhões de assinantes. Isso não é fracasso de negócio
Perguntas frequentes
O que é harness agêntico em sistemas de IA?
Harness agêntico é o conjunto de componentes de infraestrutura que governam como um agente de IA percebe seu ambiente, seleciona ações e valida resultados. A equação é: Agente = Modelo + Harness. O modelo é a capacidade de raciocínio; o harness é tudo que torna esse raciocínio seguro e previsível em produção — permission gates, arquitetura de memória, feedback loops, fases de ciclo de vida explícitas.
Por que sistemas agênticos sem harness falham em produção?
Sem harness, sistemas agênticos falham de formas previsíveis: loops infinitos sem circuit breakers, memória corrompida por injeção de contexto, agentes executando ações não autorizadas, e deadlocks em sistemas multi-agente. A pesquisa da Microsoft com 145 practitioners identificou que 15,2% das falhas mais frequentes são violações de constraints — o agente faz o que não deveria fazer porque não há harness que impeça.
Qual é a diferença entre um agente e um sistema agêntico com harness?
Um agente é o modelo de IA que raciocina e gera ações. Um sistema agêntico com harness é o agente mais toda a infraestrutura que o governa: controles de permissão que determinam o que ele pode fazer, arquitetura de memória auditável, feedback loops que permitem auto-correção, e fases de ciclo de vida explícitas com gates de aprovação. Sem harness, você tem capacidade de raciocínio. Com harness, você tem sistema confiável.
O Claude Code usa harness agêntico?
Sim. O Claude Code implementa vários padrões de harness: CLAUDE.md como constraint harness (define o que o agente pode e não pode fazer), MEMORY.md como arquitetura de memória auditável (plain-text Markdown inspecionável pelo usuário), permission gates para ações que exigem aprovação humana, e compactação automática de contexto para prevenir context overflow. É um exemplo concreto e público de como harness engineering funciona na prática.
Como começar a implementar harness engineering nos meus agentes?
Comece pelos três componentes mais críticos: (1) Defina explicitamente o que seu agente pode e não pode fazer — constraint harness via system prompt estruturado ou arquivo de regras. (2) Implemente permission gates para ações irreversíveis — antes de deletar, enviar email ou chamar API externa, o harness deve solicitar confirmação. (3) Torne a memória auditável — não acumule contexto opaco; mantenha um arquivo de estado legível que você consegue inspecionar e editar. Esses três já eliminam as falhas mais comuns em produção.
