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.
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.
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.
O modelo você troca. O harness você engenheira, e é ele que decide se o agente funciona.