IA & automação · Guia

O que é harness engineering e quando ele importa para a empresa

Harness engineering é o trabalho de projetar tudo o que fica em volta do modelo de IA para que um agente seja confiável: instruções, ferramentas, permissões, verificações e o loop de execução. O nome ganhou força em 2026, entre times que usam agentes de código; a ideia central é transformar cada erro recorrente em uma regra ou verificação permanente.

Master TimmAtualizado em 1 de outubro de 20266 min de leitura

De onde veio o termo, e o quanto ele é consolidado

O nome se espalhou no começo de 2026. Em fevereiro, Mitchell Hashimoto, cofundador da HashiCorp, descreveu a prática de criar uma solução a cada erro de um agente, para que o mesmo erro não volte, e escreveu que não sabia de um termo aceito pela indústria, mas passara a chamá-la de harness engineering.

No mesmo período, um time da OpenAI publicou um relato com o mesmo nome sobre construir um produto com o Codex, e Birgitta Böckeler, da Thoughtworks, organizou a ideia em um artigo no site de Martin Fowler. Lá, o harness aparece como tudo o que existe em um agente além do modelo: agente = modelo + harness.

É jargão de praticante, não um padrão: não existe especificação nem definição oficial, e a própria Böckeler observa que o termo muda de sentido conforme o contexto. A ideia por trás dele, porém, é estável e pode ser verificada no repositório.

O que compõe um harness

Ferramentas como Claude Code e Codex já trazem um harness embutido: o loop, as ferramentas de arquivo e de terminal, as permissões e a gestão do contexto. A documentação do Claude Code chama essa camada em volta do modelo de harness agêntico. Harness engineering, no uso de 2026, é sobretudo o que o time constrói por cima dela, no próprio repositório.

Guias, sensores e limites: as partes do harness que o time constrói
Controle	Quando age	Exemplos
GuiasOrientam o agente antes de agir	Antes da ação	AGENTS.md e CLAUDE.md, skills, ADRs, scripts e modelos de projeto
SensoresConferem o resultado e permitem a autocorreção	Depois da ação	Testes, linters, checagem de tipos, revisão feita por outro agente
LimitesDefinem até onde o agente pode ir	Durante toda a execução	Permissões por ferramenta, hooks que bloqueiam comandos, aprovação humana, teto de passos e de custo

Guias e sensores vêm do artigo de Böckeler, que também separa os controles determinísticos, como testes e linters, dos inferenciais, como a revisão por IA, que são mais lentos, mais caros e menos previsíveis.

Harness, context engineering e loop do agente: a diferença

Os três termos se sobrepõem, e cada autor traça a fronteira em um lugar diferente. Uma forma prática de separá-los é pela pergunta que cada um responde.

Context engineering, harness engineering e loop do agente: a pergunta de cada um
Termo	Pergunta que responde	Exemplos
Context engineeringO que entra na janela de contexto a cada passo	O que o agente sabe agora?	Seleção de contexto, compactação, memória, orçamento de tokens
Harness engineeringO ambiente inteiro em volta do modelo	O que o agente pode fazer, e como um erro é barrado?	Regras, ferramentas, permissões, hooks, testes
Loop do agenteO ciclo de reunir contexto, agir e verificar	Quando o agente continua e quando para?	Limite de turnos, orçamento de custo, condição de parada

Na leitura de Böckeler, construir um harness para um agente de código é uma forma específica de context engineering: guias e sensores só funcionam se chegam ao contexto do agente na hora certa. O desenho dos loops ganhou nome próprio em meados de 2026, loop engineering, e tem um guia à parte.

Quando harness engineering importa para a empresa

O harness passa a importar quando o agente deixa de ser um experimento de uma pessoa e vira parte do trabalho do time. Os sinais costumam ser estes:

O mesmo erro volta: O agente repete o comando errado ou a API antiga, porque a correção ficou no chat e não no repositório.
Revisões repetitivas: Quem revisa os pull requests do agente aponta sempre os mesmos problemas.
O agente age em sistemas: Ele abre chamados, altera dados ou faz deploy, e alguém precisa saber o que ele pode e o que não pode fazer.
Perguntas de segurança: Alguém precisa responder o que o agente pode ler, executar e enviar para fora.
Troca de modelo ou de ferramenta: O time quer mudar de agente sem perder as regras, que por isso precisam morar em arquivos versionados.

Para uso ocasional, como pedir uma função ou a explicação de um trecho de código, o harness embutido da ferramenta basta. No programa em que atuamos para a The Hackett Group, o modelo operacional usa 12 agentes, 25 skills e hooks de quality gate.

Riscos e limites de um harness

Um harness também é software, e envelhece como software. Os problemas aparecem quando ele cresce sem dono.

Regras que se contradizem: Guias e sensores criados em momentos diferentes passam a apontar em direções opostas, e o agente escolhe uma delas.
Falsa segurança: Um sensor que nunca dispara pode indicar código bom ou uma verificação fraca; sem medir, não dá para saber.
Custo e tempo: Verificações feitas por IA são mais lentas e mais caras que testes; elas complementam os testes e não os substituem.
Permissão demais: Hooks e skills podem liberar ferramentas sem aprovação, e um harness com acesso amplo transforma um erro do agente em incidente.
Dependência de um fornecedor: Regras guardadas no formato de uma única ferramenta dificultam a troca; Markdown, scripts e AGENTS.md no repositório viajam melhor.

Böckeler resume o objetivo assim: um bom harness não tenta eliminar o trabalho humano, e sim levá-lo para onde ele mais importa.

Serviço relacionado

Automação de software com IA

Agentes de código no seu time, com specs e quality gates.

Pedir conversa inicial Ver o serviço

Conversa inicial gratuita · Resposta em até 1 dia útil

Veja também: Engenharia de IA & LLM e Mentoria em tecnologia e IA.

Perguntas frequentes

Qual a diferença entre harness e framework de agentes?

Na classificação da LangChain, um framework dá abstrações para começar (LangChain), um runtime roda agentes em produção (LangGraph) e um harness é um pacote pronto, com ferramentas embutidas, para agentes de tarefas longas (Deep Agents, Claude Agent SDK). O harness engineering de um time é a camada que ele constrói por cima de qualquer um deles: as regras, as verificações e os limites do próprio repositório.

Dá para comprar um harness pronto?

Em parte: Claude Code, Codex e SDKs como o Claude Agent SDK já trazem loop, ferramentas e permissões. O que nenhum produto traz é a parte do seu time: as regras do repositório, os testes, os scripts e os limites de cada ferramenta, que precisam ser escritos e mantidos como código.

Quem mantém o harness depois que ele está pronto?

O próprio time de engenharia, do mesmo jeito que mantém o CI. O harness fica no repositório, muda por pull request e cresce a cada erro recorrente: quando um problema aparece pela segunda vez, a correção vira regra, script ou verificação, e não só um ajuste no prompt.

Como saber se o harness está funcionando?

Pelos erros que não voltam e pelo retrabalho que cai. Vale acompanhar quantos pull requests do agente são aprovados sem pedido de mudança, quais falhas os gates barram antes da revisão humana, quantos erros se repetem e o custo de cada tarefa nos traces.

Fontes

Master Timm · Atualizado em 1 de outubro de 2026