Harness Engineering: A Camada de Maturidade Depois de Prompt e Context Engineering

As equipes passam semanas refinando prompts e montando pacotes de contexto, e depois culpam o modelo quando o agente trava no meio de uma tarefa. O modelo raramente é o problema. A lacuna de confiabilidade está no harness: o software ao redor do modelo que decide o que ele vê, o que ele pode fazer e o que acontece quando ele falha. Acabamos de publicar um conjunto de novos termos de glossário e recursos que nomeiam essa camada e a prática de construí-la.

O Que É um Harness de Fato

Um harness de agente é o software fora do modelo que transforma um modelo de linguagem em um agente funcional. É o loop, as ferramentas, o gerenciamento de contexto, a memória, a lógica de recuperação e as salvaguardas. O modelo fornece o raciocínio. O harness fornece tudo o que torna esse raciocínio operacional em uma base de código real.

No centro está o loop do agente: o ciclo de controle modelo-ferramenta-observação que roda até que a tarefa seja concluída ou interrompida. O modelo propõe uma ação, o harness executa uma ferramenta, o resultado retorna como uma observação e o ciclo se repete. Plan-and-execute (Wang et al., 2023, implementado no LangChain como Plan-and-Execute) e ReAct (Yao et al., 2023) são formatos específicos desse loop, não alternativas a ele.

Três decisões de design dentro do harness determinam se esse loop produz trabalho confiável:

• design de ferramentas: como as ferramentas são nomeadas, qual o nível de granularidade, o que suas mensagens de erro dizem e quando sua documentação é carregada. Uma ferramenta que retorna um erro vago não ensina nada ao agente. Uma ferramenta que retorna um erro preciso e acionável permite que o agente se autocorrija.
• compactação de contexto: reduzir o contexto acumulado do agente durante a execução por meio de sumarização ou resets completos, para que uma tarefa longa caiba na janela sem perder o estado necessário para concluí-la.
• divulgação progressiva: organizar informações por relevância e carregar apenas o que o agente precisa em cada etapa, em vez de sobrecarregar tudo de uma vez e afogar o modelo em ruído.

Nenhuma dessas é uma configuração do modelo. São decisões de engenharia, e é onde vem a maior parte da confiabilidade.

Do Claude Code aos Harnesses de Código Aberto

O conceito de harness não é abstrato. É a categoria à qual as ferramentas de programação com agentes mais comuns pertencem.

Os dois exemplos mais claros são Claude Code e Codex CLI. Claude Code é o agente de linha de comando da Anthropic: um loop nativo de terminal com edição de arquivos, execução de comandos e contexto abrangendo toda a base de código. Codex CLI é o agente de linha de comando da OpenAI que ocupa o mesmo papel para seus modelos. Ambos são harnesses no sentido preciso usado aqui. Eles envolvem um modelo em um loop, um conjunto de ferramentas e uma estratégia de contexto, e as diferenças entre eles são diferenças de design de harness, não de capacidade bruta do modelo.

Outros harnesses amplamente utilizados aplicam a mesma ideia em superfícies diferentes: Cursor e Windsurf incorporam o loop em um editor, GitHub Copilot executa um modo agente dentro do fluxo de trabalho já existente do desenvolvedor, e Aider e OpenCode são agentes de linha de comando de código aberto. O modelo por baixo é frequentemente o mesmo em várias dessas ferramentas. O que as distingue é o harness: como gerenciam o contexto, projetam suas ferramentas e se recuperam de falhas.

Essa é a conclusão prática. Quando duas equipes usando o mesmo modelo obtêm resultados diferentes, o harness geralmente é a variável.

Harness Engineering como uma Disciplina Emergente

Harness engineering é a disciplina de projetar e iterar o harness para que o agente funcione de forma confiável. É a camada de maturidade que vem depois do prompt engineering e do context engineering. O prompt engineering melhora uma única instrução. O context engineering melhora o que o agente sabe. O harness engineering melhora o sistema que executa o agente ao longo de muitas etapas, e é medido pela capacidade do agente de concluir o trabalho correto sem supervisão.

O que o harness engineering envolve na prática? É menos uma lista de verificação do que um conjunto de princípios de design, e um harness popular é o lugar mais claro para vê-los. Considere os princípios dentro do Claude Code:

• Um loop de agente fechado sobre ferramentas reais. O modelo age, observa o resultado e corrige, em vez de produzir uma grande resposta isolada.
• Gerenciamento deliberado de contexto. Memória persistente de projeto, recuperação e compactação mantêm a informação certa na janela, não tudo (context engineering).
• Ferramentas projetadas para o agente. Nomes claros e mensagens de erro acionáveis permitem que o modelo se recupere por conta própria (tool design).
• Salvaguardas e supervisão humana. Permissões e aprovações controlam ações sensíveis, em vez de confiar cegamente no agente.
• Verificação antes da conclusão. O agente verifica seu trabalho em relação à verdade fundamental — como testes e builds — antes de declarar que a tarefa está concluída.
• Interfaces estáveis sobre um núcleo em mudança. A superfície usada pelo desenvolvedor permanece estável enquanto os internos são ajustados (building effective agents).

Esses princípios, não o modelo subjacente, são o que tornam um harness confiável. A Anthropic documenta como eles se sustentam em escala em harnesses for long-running agents.

É também por isso que a maioria das empresas não deveria construir seu próprio harness. Os laboratórios de fronteira e um punhado de startups especializadas iteram nesses sistemas em tempo integral, com benchmarks privados e muito mais sinal do que qualquer organização de engenharia individual pode reunir. Para a maioria das equipes, o melhor caminho é adotar um harness maduro e investir o esforço economizado uma camada acima. Construir o harness é onde os laboratórios e startups estão melhor posicionados. Construir sobre ele é onde todos os outros criam vantagem.

O loop do agente fica dentro do harness: o modelo age, as ferramentas retornam observações, e o harness gerencia o contexto, as salvaguardas e a recuperação ao redor do ciclo.

Do Harness à Produtividade

Um harness ainda é uma tela em branco. Funciona como uma ferramenta de CI: fornece o substrato de execução, mas o valor vem do que você coloca em cima. Padrões de design, habilidades curadas ou personalizadas, processos de revisão e controles são o que transformam um harness genérico na forma como uma equipe específica constrói software.

Esse é o papel do meta-harness: a abstração que torna um harness parte das formas de trabalhar de uma empresa ou de um desenvolvedor. Na prática, isso pode significar coordenar mais de um harness, mas não necessariamente. A função essencial é a integração: codificar os padrões, habilidades e salvaguardas no harness para que eles viajem com o trabalho, em vez de existirem apenas na cabeça de uma pessoa.

A pilha: a camada do modelo é uma commodity compartilhada, o harness a torna operacional, e o meta-harness a integra às formas de trabalhar da equipe. A alavancagem aumenta conforme você sobe.

Formalmente, um meta-harness é um substrato ou plano de controle que hospeda múltiplos harnesses de agentes conectáveis e intercambiáveis em um runtime compartilhado. O novo recurso Omnigent é um exemplo concreto: um meta-harness de código aberto da Databricks que fica acima dos agentes de programação existentes — incluindo Claude Code e Codex CLI — e os torna combináveis, controláveis e compartilháveis por meio de uma única interface sob a licença Apache 2.0. O caso com múltiplos harnesses é o mais visível, mas a mesma camada de integração ainda importa mesmo quando uma equipe padroniza em um único harness.

Um harness autoaperfeiçoável vai além. Ele observa suas próprias execuções, edita seu próprio scaffolding e mantém uma mudança apenas quando ela passa em um benchmark reservado. Isso é harness engineering aplicado recursivamente, com uma salvaguarda rígida: a validação determinística contra um benchmark decide o que sobrevive, não o julgamento do próprio agente sobre seu trabalho.

Conclusões

• O harness é a variável, não o modelo. Quando os agentes têm desempenho abaixo do esperado com o mesmo modelo, audite primeiro o loop do agente, o design de ferramentas e a estratégia de contexto.
• Não construa seu próprio harness. Adote um maduro. Os laboratórios e startups especializadas estão melhor posicionados para construir harnesses; seu tempo é melhor aproveitado em outro lugar.
• Invista uma camada acima. A diferenciação vive nas suas formas de trabalhar: padrões, habilidades curadas ou personalizadas, processos de revisão e controles, integrados pela camada do meta-harness.
• Trate o modelo como uma commodity. Os mesmos modelos estão disponíveis para todos, então a vantagem sobe na pilha.

Os novos termos do glossário oferecem um vocabulário compartilhado para essa camada. A prática de construí-la bem é o harness engineering, e é o que decide se os agentes se tornam um passivo ou um multiplicador de força.