Em 2026, surge um novo consenso na indústria de IA: o que determina se um produto de IA é bom ou mau já não é o próprio modelo, mas sim a camada por fora do modelo chamada «harness». À medida que os modelos subjacentes usados por Claude Code, Cursor e OpenClaw se aproximam cada vez mais, a diferença real entre produtos é determinada pelo design do harness. O blogue técnico de Martin Fowler, a declaração do responsável pelo produto na Anthropic trq212 e as recentes intervenções de Andrej Karpathy apontam todos na mesma direção: o próximo campo de batalha da IA é a Harness Engineering.
O que é um Agent Harness
Um agente de IA pode ser dividido em duas partes: o modelo (Model) e o harness. O modelo é o cérebro, responsável por compreender a linguagem e fazer inferência. O harness é tudo o que está para além do modelo — chamadas de ferramentas, gestão de memória, montagem do contexto, persistência do estado, tratamento de erros, proteções de segurança (guardrails), escalonamento de tarefas e gestão do ciclo de vida.
Com uma analogia intuitiva: um LLM é um cavalo, e o harness é a estrutura de arreios — as rédeas, a sela e o conjunto de ligação ao carro. Sem arreios, mesmo que o cavalo seja forte, não consegue puxar o carro. Um agente de IA é igual: mesmo que o modelo seja inteligente, sem um bom harness não é possível executar tarefas reais de forma fiável.
Akshay Pachaar propôs, num tweet amplamente divulgado, outra analogia: «um LLM “nu” é como uma CPU sem sistema operativo — consegue calcular, mas sozinho não faz nada de útil.» O harness é exatamente o sistema operativo.
Porque é que, de repente, a Harness Engineering se tornou tão importante em 2026
Há três razões:
Primeiro, as capacidades dos modelos estão a convergir para um padrão semelhante. As diferenças entre o GPT-5.4, o Claude Opus 4.6 e o Gemini 3.1 Pro na maioria dos testes de referência já se reduziram a poucos pontos percentuais. Quando o modelo deixa de ser o gargalo, a diferenciação do produto passa naturalmente para a camada do harness.
Segundo, o agente passa do laboratório para a produção. Em 2025, a maioria dos agentes eram demonstrações; em 2026, os agentes têm de correr em ambientes empresariais — precisam de lidar com recuperação após interrupções, execução por longos períodos, tarefas de vários passos e controlo de permissões. Tudo isto é trabalho do harness.
Terceiro, os LLMs são naturalmente sem estado. Cada nova session começa do zero; o modelo não se lembra da conversa anterior. O harness é responsável por persistir memória, contexto e progresso do trabalho, permitindo que o agente trabalhe de forma contínua como um verdadeiro «colega».
Componentes centrais de um Harness
Um harness completo de agente normalmente inclui as seguintes camadas:
Componente Função Analogia Orchestration Loop Controla o ciclo «pensar → agir → observar» do agente, como o ciclo principal de um sistema operativo Tool Management Gere as ferramentas que o agente pode utilizar (leitura e escrita de ficheiros, chamadas de API, operações com browser, etc.) Driver Program Context Engineering Decide que informações enviar ao modelo em cada chamada, e quais cortar Gestão de memória State Persistence Guarda o progresso do trabalho, o histórico de conversas e resultados intermédios Hard disk Error Recovery Deteta falhas e volta a tentar automaticamente ou recua Tratamento de exceções Safety Guardrails Limita o âmbito de ação do agente, evitando operações perigosas Firewall Verification Loops Faz com que o agente verifique a qualidade das saídas, de forma autónoma, Testes unitários
Três camadas de engenharia: Prompt, Context e Harness
As práticas de engenharia em torno de LLM podem ser divididas em três camadas concêntricas:
A camada mais interna é a Prompt Engineering — conceber as instruções a enviar ao modelo, determinando «como» o modelo pensa. Esta era a competência dominante em 2023.
A camada intermédia é a Context Engineering — gerir o que o modelo «vê». Determina que informações entram no context window em que momentos e quais devem ser cortadas. À medida que o context window se expande para milhões de tokens, a importância desta camada começa a surgir em 2025.
A camada mais externa é a Harness Engineering — abrange as duas anteriores e ainda toda a infraestrutura base da aplicação: orquestração de ferramentas, persistência do estado, recuperação de erros, ciclos de verificação, mecanismos de segurança e gestão do ciclo de vida. Este é o campo de batalha central em 2026.
Exemplo: por que o mesmo modelo tem desempenhos tão diferentes em produtos distintos
O Claude Opus 4.6 consegue, no Claude Code, passar uma hora a reestruturar todo o repositório de código. Mas ao usar o mesmo modelo via API, ligando-o a um harness rudimentar, ele pode nem sequer conseguir corrigir bugs que atravessam vários ficheiros. A diferença não está no modelo; está no harness.
O que o harness do Claude Code fez?
Procura automaticamente todo o repositório de código em busca de ficheiros relevantes, em vez de exigir que o utilizador os especifique um por um
Lê o conteúdo dos ficheiros antes de fazer alterações; depois executa testes para validar
Quando os testes falham, analisa automaticamente o erro e volta a tentar
Liga-se a ferramentas externas através de MCP (GitHub, base de dados, etc.)
O sistema de memória preserva preferências do utilizador e o contexto do projeto entre sessions
A estratégia Advisor faz com que modelos com capacidades diferentes trabalhem em conjunto e se repartam tarefas
Tudo isto é mérito do harness.
Feedforward e Feedback: dois modos de controlo do Harness
De acordo com a análise do blogue técnico de Martin Fowler, os mecanismos de controlo do harness dividem-se em duas categorias:
Feedforward (controlo antecipado) — define regras antes da ação do agente, prevenindo saídas indesejadas. Por exemplo: regras de comportamento no system prompt, lista branca de ferramentas e permissões de acesso a ficheiros.
Feedback (controlo com retroação) — verifica o resultado após a ação do agente, permitindo correção automática. Por exemplo: executar testes para confirmar que o código está correto, comparar as saídas com o formato esperado, detetar alucinações e gerar novamente.
Um bom harness usa simultaneamente os dois tipos de controlo: limita o âmbito de ação e, ao mesmo tempo, mantém flexibilidade.
A productização do Harness Engineering: como a Anthropic o faz
As atualizações de produto lançadas de forma intensiva pela Anthropic em abril de 2026 são, quase todas, a productização do harness engineering:
Managed Agents — transformar a infraestrutura do harness (sandbox, escalonamento, gestão de estado) em serviço gerido; os programadores só precisam de definir o comportamento do agente
Advisor strategy — arquitetura de mistura de modelos ao nível do harness que determina automaticamente quando consultar um modelo mais forte
Cowork versão empresarial — oferece um harness completo (controlo de permissões, gestão de custos, análise de uso) para utilizadores não técnicos, para que não precisem de compreender a tecnologia subjacente
A forma como o responsável pelo produto na Anthropic, trq212, se expressou é a mais precisa: «Prompting é uma competência para dialogar com o agente, mas é mediado pelo harness. O meu objetivo central é aumentar a largura de banda entre humanos e agentes.»
O que isto significa para programadores: uma nova profissão e novas competências
A Harness Engineering está a tornar-se um campo de engenharia independente. O conjunto de competências de que necessita é diferente tanto da engenharia backend tradicional como da engenharia de ML:
Compreender limites de capacidade e modos de falha dos LLM
Conceber processos fiáveis de chamadas a ferramentas e de tratamento de erros
Gerir o context window — quando inserir que tipo de informação
Construir observabilidade — acompanhar o percurso de decisão do agente e o uso de ferramentas
Segurança por design — limitar o âmbito de ação do agente sem sufocar a sua capacidade
Para quem está a aprender Vibe Coding ou a usar ferramentas de IA para desenvolver, compreender o conceito de harness ajuda-te a colaborar de forma mais eficaz com agentes de IA — porque saberás se o problema está no modelo ou no harness, e como melhorar os resultados ajustando as definições do harness (e não mudando prompts repetidamente).
Conclusão: a disputa pela infraestrutura da próxima década
A concorrência entre modelos de IA não vai parar, mas o benefício marginal está a diminuir. A competição na camada do harness está apenas a começar — quem conseguir construir o harness mais fiável, mais flexível e mais seguro conseguirá transformar as mesmas capacidades do modelo em melhores experiências de produto.
Isto também explica porque é que a Anthropic, a OpenAI e a Google estão a transitar de «empresas de modelos» para «empresas de plataforma»: o que vendem já não é apenas uma API de modelos, mas sim toda a infraestrutura de harness. Para programadores, compreender harness engineering não é uma opção; é uma competência essencial para construir produtos na era da IA.
Este artigo, o que é Harness Engineering? O próximo campo de batalha da IA não é o modelo, mas sim a camada de arquitetura fora do modelo, aparece pela primeira vez em Liannews ABMedia.
