Harness engineering é a disciplina de projetar tudo o que envolve o modelo (regras, ferramentas, memória e verificação) para que um agente funcione de forma confiável em produção. Mitchell Hashimoto, criador do Terraform, nomeou a prática em fevereiro de 2026. A fórmula que a resume, Agente = Modelo + Harness, é da LangChain.
Nota: "AI harness" aqui é o conceito de software — a infraestrutura em volta de um LLM que o torna um agente confiável —, não a harness.io (plataforma de CI/CD) nem o chicote/arreio literal da palavra em inglês.
Novo por aqui? Comece pela definição canônica: o que é um AI harness.
O termo que apareceu em 2026
Harness engineering é o trabalho de engenharia sobre o harness: a camada de código, configuração e regras que fica em volta do modelo. Mitchell Hashimoto batizou a prática em "My AI Adoption Journey" (5 de fevereiro de 2026), quando escreveu que ainda não via um termo aceito pela indústria e passou a chamar isso de harness engineering. A definição dele é operacional: toda vez que o agente erra, você engenheira uma correção permanente, para que aquele erro nunca mais se repita. Não é ajustar um prompt na hora. É transformar cada falha em regra.
Não é rebrand: a prova
A pergunta óbvia é se harness engineering é só um nome novo pra prompt engineering. A resposta veio em número. A LangChain rodou o mesmo modelo (gpt-5.2-codex) no Terminal Bench 2.0 e, mudando só o harness, saiu do top 30 para o top 5: de 52.8 para 66.5, um ganho de 13.7 pontos (17 de fevereiro de 2026). Mesmo modelo, harness diferente, resultado materialmente diferente. Isso não é renomear prompt. É um benchmark só, mas o sinal é claro: a alavanca não está só no modelo.
O que compõe: guides e sensors
| Componente | O que faz | Exemplo |
|---|---|---|
| Guides (feedforward) | Antecipam e direcionam o agente antes de ele agir | Regras de operação, CLAUDE.md, ferramentas permitidas |
| Sensors (feedback) | Observam depois da ação e ajudam o agente a se auto-corrigir | Testes, linters e typecheck como sinais legíveis pelo agente |
| Memória | Converte cada erro em correção permanente que sobrevive à sessão | Regras versionadas, loop de erro para regra |
| Quality gates | Bloqueiam saída que não passa no critério | Cobertura mínima, zero warnings novos |
| Observabilidade | Torna o comportamento do agente auditável | Artefatos por fase: spec, plano, relatório |
Harness engineering não é framework, nem prompt, nem RAG
Vale separar. Um framework de agentes (LangChain, LlamaIndex) é biblioteca pra você construir o loop; harness engineering é a disciplina de projetar o ambiente inteiro em volta dele. Prompt e context engineering cuidam do que o modelo vê; harness engineering inclui isso e também o que o modelo pode fazer, o que é obrigado a cumprir e o que persiste entre sessões. RAG é um subcomponente, não sinônimo. E tem um contra-argumento honesto: Nicolas Bustamante (Model-Harness-Fit, maio de 2026) mostra que modelo e harness estão ficando inseparáveis, "você não pode simplesmente trocar de modelo". Ele tem razão, e é exatamente por isso que o harness é onde a engenharia acontece: trocar de modelo obriga a re-engenheirar o harness em volta dele.
O harness de código é a parte visível
Quase todo mundo que fala de harness engineering hoje fala do harness de código: Claude Code, Cursor, agentes que leem repositório, editam arquivo e rodam teste. Essa é a parte visível. A parte maior, e onde quase ninguém está engenheirando com disciplina, é o harness operacional: o mesmo padrão aplicado à operação de um negócio inteiro, IA além do código, conhecimento, memória e governança. É onde a Capiva trabalha. A camada de código a gente resolve com o capivaOS, o harness open-source sobre o Claude Code. A camada operacional a gente constrói em produção, e o relato está em AI Harness na Prática.
A evolução do harness: do modelo sozinho ao sistema que se melhora
O modelo é o talento; o harness é o trabalho em volta. Entre 2019 e 2026 o harness cresceu em cinco camadas — briefing, capacidades, qualidade e time, runtime sempre ligado, e auto-melhoria — e cada camada acrescentou um controle que a empresa não tinha antes. Mitchell Hashimoto nomeou a disciplina harness engineering em fevereiro de 2026: toda vez que o agente erra, você engenheira uma correção permanente no ambiente, para aquele erro não se repetir.
Linha do tempo · 2019–2026
Arraste o marcador ou use as setas do teclado para ver o harness crescer.
01 / 13Versão 0 · modelo nu
2019Modelo nu
Quase não há harness: instrução curta, pedido, modelo, saída. Sem ferramentas, sem memória, sem revisão.
Novo no harnessPedido · Modelo · Saída · Instruções
Camada 1 · Briefing: o que o assistente recebe antes de começar
O briefing é o conjunto de instruções, exemplos, playbooks e limites que o modelo vê antes de agir. Sem ele, o harness quase não existe.
O que mudou. A partir de 2019 o loop era mínimo: instrução curta, pedido, modelo, saída. Em 2020, o few-shot mostrou que exemplos bem escolhidos mudam o resultado sem retreinar nada. Em 2022, pedir o caminho antes da resposta (chain-of-thought) tornou o raciocínio legível. Depois vieram playbooks (procedimentos reutilizáveis) e limites explícitos de passos e acesso.
Para o negócio, é como… Onboarding por exemplo: em vez de descrever o formato do relatório, você entrega três prontos e diz “faça igual”.
O que destravou. Formato e tom consistentes sem retreino; adaptação a uma tarefa nova em minutos; raciocínio auditável.
Governança que você ganha. O padrão de qualidade fica por escrito. Os exemplos são a especificação contra a qual o trabalho é julgado. Limites de passos e acesso viram política, não esperança.
Leia também: o que é um AI harness · harness vs RAG e context engineering
Camada 2 · Capacidades: ferramentas, memória e o que o modelo pode tocar
Capacidades são o que o harness dá ao modelo além de texto: ferramentas e sistemas (incluindo MCP), memória editável, histórico de experiência e, quando preciso, ferramenta criada na hora.
O que mudou. De 2021 em diante o modelo deixa de “lembrar” e passa a chamar software real — calcular, buscar, consultar registro (WebGPT, Toolformer). Em 2023, MemGPT mostrou memória que o próprio modelo cria, atualiza e descarta. O Model Context Protocol (MCP), anunciado pela Anthropic em novembro de 2024, padronizou como descrever e conectar ferramentas. Em seguida veio a ferramenta escrita na hora: o assistente programa um script pequeno, executa e usa o resultado.
Para o negócio, é como… Dar ao novo contratado os logins do sistema. Ninguém espera que o analista feche o trimestre de cabeça; espera que saiba quando abrir a planilha.
O que destravou. Números exatos e informação atual; ações em sistemas reais; continuidade entre sessões; menos becos sem saída.
Governança que você ganha. Você decide, sistema a sistema, o que a IA pode ler e o que pode alterar. Memória vira dado com política de retenção. Código que o agente escreve e roda precisa de sandbox e aprovação — como qualquer mudança de software.
Leia também: como construir um AI harness · capivaOS
Camada 3 · Qualidade e time: revisor interno, subagentes e gatilhos
Em vez de uma passagem só, o harness coloca revisão antes do humano, e um assistente pode coordenar especialistas com briefs e acessos diferentes.
O que mudou. Entre 2022 e 2023, ReAct, Self-Refine e Reflexion mostraram o loop executar → revisar → corrigir. Em 2024–2025, o próprio spawn de assistentes vira ferramenta: o agente divide a tarefa, acompanha e integra. Em setembro de 2025 a Anthropic lançou o Claude Agent SDK com suporte a subagentes e hooks — o mesmo núcleo de ferramentas, gestão de contexto e permissões que alimenta o Claude Code. Gatilhos (mensagem, reunião, agenda) passam a iniciar o trabalho.
Para o negócio, é como… Peer review e um líder de projeto: escopa, delega, acompanha e consolida.
O que destravou. Menos erro chegando a cliente e decisor; projetos grandes demais para uma passagem; especialização por brief e por acesso.
Governança que você ganha. Controle de qualidade antes do humano, com registro. Orçamentos e limites capam custo e comportamento runaway. Especialistas com acesso separado reforçam segregação de funções.
Leia também: guardrails e evals · como criar subagentes no Claude Code · harness do Claude Code
Camada 4 · Runtime sempre ligado: estado salvo e retomada após falha
O assistente deixa de existir só enquanto alguém o tem aberto. O loop roda em servidor, grava estado a cada passo e retoma depois de uma queda.
O que mudou. Até aqui o harness era uma sessão. A partir de 2026, agentes always-on vivem em runtime próprio: triggers acordam o trabalho, um action check valida comandos sensíveis, e o estado sobrevive a crash. A Capiva usa esse padrão na própria operação (capivaOS): o harness fica de pé; o modelo é trocável.
Para o negócio, é como… A diferença entre um prestador que só trabalha enquanto você está na sala e um colega com mesa, login e inbox que pega o que chegou de madrugada.
O que destravou. Trabalho que sobrevive a falha e roda por dias; tarefas iniciadas por evento, não só por digitação.
Governança que você ganha. Você decide o que pode acordar o agente, quais ações um segundo modelo confere, quais esperam pessoa, e onde ficam as credenciais. Input não confiável é dado — nunca instrução.
Leia também: AI Harness na Prática · how we work
Camada 5 · Auto-melhoria: otimizador de briefs, arquivo de versões, métrica do negócio
Um harness que se auto-melhora não só executa melhor o brief — ele testa variações do brief (e, em pesquisa, da própria estrutura), arquiva cada versão e promove a que performa na métrica que você definiu.
O que mudou. Com DSPy (2023), o sistema deixa de depender só de instrução escrita à mão: dado um conjunto de bons exemplos, ele tenta muitas versões do brief, mede e combina as melhores. Em 2025, a Darwin Gödel Machine mostrou reescrever não só o brief, mas partes do próprio harness — ferramentas, helpers, revisão — com arquivo de versões. Em 2025–2026, harnesses contínuos acrescentam histórico de experiência e, em parte produto / parte pesquisa, aprendizado a partir do uso real.
Para o negócio, é como… A/B test da descrição do cargo em escala, e depois um time de operações que redesenha o próprio organograma toda semana e promove o que entrega mais.
O que destravou. Melhora sem reescrever cada instrução à mão; re-tuning rápido ao trocar modelo ou tarefa; descoberta de métodos que ninguém pensaria de testar.
Governança que você ganha. O controle migra para a métrica: o que você mede é o que o sistema otimiza. Escolha com cuidado. Toda versão fica arquivada e pode ser revertida — governança vira gestão de mudança. Quando o modelo também aprende, a supervisão cobre o que ele aprende e como esse aprendizado é revisado.
Leia também: como construir um AI harness
Prompt, contexto e harness engineering: escopos que se somam
Não são etapas que se substituem. São escopos que se ampliam: o harness inclui prompt e contexto, e ainda controla execução, ferramentas, estado, verificação e governança.
| Escopo | Cuida de | Unidade de design |
|---|---|---|
| Prompt engineering | Instruções, exemplos, formato e templates de raciocínio numa invocação | A chamada ao modelo |
| Context engineering | O que o modelo vê a cada passo: documentos, memória, interações anteriores | O estado de informação |
| Harness engineering | Prompt + contexto + ambiente de execução, ferramentas, estado persistente, ciclo de vida, observabilidade, verificação e governança | O sistema em loop fechado |
O survey Agent Harness Engineering (Li et al., 2026) trata os três como escopos que se expandem, não como eras históricas: o mais amplo inclui o mais estreito.
Leia também: harness vs RAG e context engineering
Lente de governança: cada componente é um controle
O harness é a camada onde a empresa decide permissões, memória, revisão, gatilhos e métrica. Sem harness, não há governança de agente — só um modelo que responde.
A Australian Signals Directorate (ASD / cyber.gov.au), na publicação Agentic AI harnesses (setembro de 2026), define o harness como a camada de software que conecta o LLM a dados, ferramentas, memória e fluxos de planejamento, e que impõe privilégios de ação. Se o LLM é o cérebro, o harness é o corpo — e o ponto de controle.
| Componente do harness | Controle | Risco que mitiga |
|---|---|---|
| Instruções, exemplos, limites | Política e escopo | Agente fora do mandato |
| Ferramentas / MCP / sistemas | Permissão por sistema | Acesso excessivo a dados e ações |
| Memória editável | Retenção e privacidade | Dado sensível que “gruda” sem política |
| Playbooks | Compliance operacional | Procedimento inconsistente |
| Ferramenta criada na hora | Sandbox e aprovação | Código não revisado em produção |
| Revisor interno / evals | QA antes do humano | Erro que chega a cliente ou decisor |
| Time de assistentes | Orçamento, limites, segregação | Custo runaway; privilégio acumulado |
| Triggers + runtime always-on | Confiança do gatilho, identity, secrets | Agente acordado por input hostil |
| Métrica + arquivo de versões | O que se otimiza; rollback | Otimização da métrica errada; mudança sem trilha |
Perguntas frequentes
O que é harness engineering?▼
É a disciplina de projetar tudo o que envolve o modelo (regras, ferramentas, memória, verificação e orquestração) para que um agente funcione de forma confiável em produção. Foi nomeada por Mitchell Hashimoto em fevereiro de 2026. A ideia central: cada erro do agente vira uma correção permanente no harness, não um ajuste pontual.
Quem cunhou o termo harness engineering?▼
Mitchell Hashimoto, co-fundador da HashiCorp e criador do Terraform, em "My AI Adoption Journey" (5 de fevereiro de 2026). Ele nomeou a disciplina. A fórmula Agente = Modelo + Harness é separada: veio da LangChain (Vivek Trivedy, março de 2026). Não confunda as duas atribuições.
Qual a diferença entre harness engineering e um framework de agentes?▼
Um framework é biblioteca pra construir o agente (você escreve o loop). Harness engineering é a disciplina de projetar o ambiente de execução em volta dele: regras, gates, memória e ferramentas. LangChain é framework; projetar o harness que roda sobre o Claude Code é harness engineering.
O que são guides e sensors?▼
É a taxonomia de Birgitta Böckeler (Thoughtworks), publicada no site do Martin Fowler em 2 de abril de 2026. Guides são feedforward: antecipam e direcionam o agente antes de ele agir (regras, CLAUDE.md, ferramentas permitidas). Sensors são feedback: observam depois da ação e ajudam a auto-corrigir (testes, linters, typecheck lidos pelo agente).
Harness engineering é o mesmo que context engineering?▼
Não. Context engineering cuida do que o modelo vê (recuperação e curadoria de contexto). Harness engineering inclui isso e mais: o que o modelo pode fazer, o que é obrigado a cumprir e o que persiste entre sessões. Context engineering é uma parte do harness, não sinônimo.
Como começar em harness engineering?▼
Comece pelo loop de correção: toda vez que o agente erra, escreva uma regra permanente em vez de corrigir na mão. Depois adicione guides (regras e ferramentas permitidas) e sensors (testes e linters que o agente lê). Pra camada de código, o capivaOS dá um harness pronto sobre o Claude Code; a camada operacional se desenha sobre o seu stack.
Como o AI harness evoluiu?▼
Em cinco camadas, de 2019 a 2026: briefing → capacidades (ferramentas, memória, MCP) → qualidade e time → runtime always-on → auto-melhoria. Cada camada acrescentou um controle que a empresa não tinha com o modelo sozinho.
O que é um harness que se auto-melhora (self-improving harness)?▼
É o harness que testa variações do brief (e, em pesquisa, da própria estrutura), arquiva cada versão e promove a que performa na métrica definida pelo negócio — com rollback humano.
Como o harness ajuda na governança de agentes de IA nas empresas?▼
É a camada onde permissões, memória, revisão, gatilhos e métrica são impostos de fato. Sem harness, a IA é uma caixa que responde; com harness, cada componente vira um controle (ASD, Agentic AI harnesses, 2026).
Quais componentes de um harness viram controles de governança?▼
Instruções e limites (política), ferramentas/MCP (permissão), memória (retenção), playbooks (compliance), sandbox (código gerado), revisor/evals (QA), subagentes (segregação), runtime/triggers (identity e confiança do gatilho), métrica e arquivo de versões (otimização e mudança).
O modelo você troca. O harness você engenheira, e é ele que decide se o agente funciona.