Todas as contribuições
IA & Machine Learningharnessai-agentsagent-architecture

Harness de agentes: cinco camadas e como construir o seu

As cinco camadas de um harness de agentes, o mapa dos harnesses abertos e fechados de 2026, e por que Harvey, Legora, Rogo e Hebbia venceram construindo o harness do seu setor, e não um modelo melhor.

Numoru EngineeringPublicado em 10 de setembro de 202612 min de leitura
Compartilhar

TL;DR

Um harness é todo o software que envolve o modelo e o transforma em algo que faz coisas em vez de responder mensagens. A fórmula que se firmou em 2026 é curta: agente = modelo + harness. Quase toda a atenção pública vai para a primeira parcela; quase toda a vantagem defensável está na segunda. Este artigo mapeia as cinco camadas de um harness, compara os harnesses abertos e fechados mais potentes hoje, e mostra por que os verticais que realmente funcionam — Harvey e Legora no jurídico, Rogo e Hebbia em finanças — não venceram treinando um modelo melhor. Venceram construindo o harness do seu setor. Termina com o caminho concreto para construir o seu.

5
Camadas de um harness completo
Fundação, controle, contexto, execução, supervisão
8
Componentes que precisam existir
Em qual camada colocá-los é decisão sua
~70% → 99,9%
Salto no ARC-AGI-3 ao trocar o harness
Mesmo modelo, harness modificado
20+
Harnesses sérios competindo
Abertos e fechados, set. 2026

O harness é o produto, não o modelo

Há um dado deste mesmo ano que organiza toda a discussão. Quando a OpenAI lançou o GPT-6 Astra, o número citado em todo lugar foi 99,9% no ARC-AGI-3. Esse número foi medido com um provider adapter: um harness modificado, não um modelo modificado. Sem ele, o mesmo modelo marca cerca de 70%. Contamos isso em detalhe na nossa análise do GPT-6 Astra.

Trinta pontos percentuais sobre pesos idênticos. Essa diferença é o tamanho do espaço onde vive a engenharia de harness, e é a razão pela qual a pergunta «qual modelo usamos?» ficou bem menos interessante do que «o que deixamos ele ver, o que deixamos ele tocar, e como verificamos que terminou?».

A definição de trabalho mais útil é a da Databricks: «um harness de agente de IA é a infraestrutura de software que envolve um modelo de linguagem e permite que ele atue sobre tarefas, não apenas responda a prompts». O harness decide o que o modelo vê, quais ferramentas pode chamar, onde o estado é guardado, como as observações voltam, quando a validação roda, como uma falha é recuperada, quando ele pode parar e como uma ou várias chamadas ao modelo são organizadas.

Anatomia: as cinco camadas

A literatura de 2026 converge para uma arquitetura em camadas. O survey Natural-Language Agent Harnesses (arXiv 2603.25723) as ordena assim, e é o esqueleto que vale manter na cabeça ao projetar o seu:

CamadaO que decideO que quebra sem ela
FundaçãoQual modelo, com que orçamento de raciocínio, com qual entrada e saídaNada, no começo. Depois você percebe que paga preço de fronteira por trabalho que um modelo barato resolvia
ControlePlanejamento, seleção de ações, orquestração, quando delegar e quando pararO agente fica em círculos. Repete a mesma ação que falha, ou se declara pronto na metade
Memória e contextoO que entra na janela, o que é resumido, o que é recuperado, o que sobrevive à sessãoO agente esquece a instrução do turno 3 no turno 40, ou enche o contexto de ruído e para de raciocinar
ExecuçãoFerramentas, sandbox, sistema de arquivos, como o resultado volta e como um erro é representadoÉ aqui que dados reais são destruídos. E onde um erro mal formatado envenena os 20 turnos seguintes
Supervisão e adaptaçãoRastros, métricas, detecção de falha, retentativas, aprovação humanaFunciona na demo e ninguém sabe por que falha em produção. Sem trilha de auditoria não há setor regulado

Sobre esse esqueleto, a Databricks enumera os oito componentes que precisam existir em algum lugar: prompts de sistema, ferramentas e sua execução, sandboxes, sistema de arquivos durável, gestão de memória e contexto, laços de verificação, guard-rails com humano no circuito, e observabilidade. Em qual camada colocá-los é decisão de arquitetura. Deixar um de fora não é decisão: é uma dívida cobrada em produção.

Tudo isso gira num laço ReAct: o modelo raciocina, o harness executa, o resultado volta como observação e o ciclo se repete até que algo decida que acabou. Esse «algo» — a condição de parada — é a peça mais subestimada, e a que mais separa um harness sério de um while com uma chamada de API dentro.

O mapa de 2026: aberto e fechado

O campo se povoou rápido. Estes são os harnesses que definem o estado da arte, com a propriedade arquitetural que faz cada um valer o estudo.

Abertos

HarnessArquiteturaCapacidade distintiva
OpenCodeTUI de terminal, app de desktop, embutível em IDEMais de 75 provedores de modelo, carga automática de LSP para contexto com consciência da linguagem, sessões paralelas
OpenHandsAutonomia auto-hospedávelSandbox Docker e modo API headless para CI/CD. A escolha usual quando os dados não podem sair da sua rede
Aider (MIT)Terminal, nativo de gitCada mudança é commitada com mensagem gerada: o registro auditável é o log do git, não uma transcrição opaca
ClineExtensão do VS CodeUso de ferramentas com permissão explícita: por padrão um humano aprova cada edição e cada comando
Goose (Apache 2.0, Block)Baseado em pluginsCapacidades se instalam como extensões em vez de vir num conjunto fixo. Doado à Agentic AI Foundation
PiImplementação de referência deliberadamente mínimaSó o núcleo: tarefa, ferramentas, laço, verificação. O melhor lugar para ler como um harness funciona por dentro

Fechados

HarnessArquiteturaCapacidade distintiva
Claude Code (Anthropic)Terminal, com ciclos autônomosDelegação a subagentes, hooks de ciclo de vida, memória de projeto em arquivo, permissões por operação. 86,7% no Terminal-Bench 2.1
Google AntigravityCLISandbox real no nível do sistema operacional: nsjail no Linux, sandbox-exec no macOS. Subagentes em paralelo
Muse Code (Meta)Terminal com subagentes de fundo persistentesSubagentes paralelos em worktrees isoladas do git e log prévio à execução para retomar após queda. 82,9% no Terminal-Bench 2.1
Devin (Cognition)Tarefas autônomas longasMudanças multiarquivo e automação de PR com pouca condução turno a turno
Factory / DroidPlataforma de fluxo corporativoAgentes especializados por função — revisão, migração, resposta a incidentes — e configurações de harness no nível da organização
Replit AgentNavegador, sem instalaçãoRoda em sandbox na nuvem: não há ambiente local para preparar nem para quebrar

Dois sinais de que essa camada está amadurecendo, e que não convém ignorar. Primeiro: a Linux Foundation criou em 2026 uma Agentic AI Foundation sobre três doações — o Model Context Protocol da Anthropic para ferramentas, o AGENTS.md da OpenAI para instruções, e o Goose. Segundo: Zed, OpenHands e DeepSeek Harness falam o Agent Client Protocol, ou seja, conduzem uns aos outros. As interfaces entre camadas estão se padronizando, e isso significa que construir o seu já não começa do zero.

O que separa um harness sério de um laço while

Ao comparar os harnesses acima, as diferenças não estão no prompt. Estão em sete decisões:

  • Permissões por operação. Ler não é escrever, escrever não é apagar, e apagar em staging não é apagar em produção. O Cline pede por edição; o Claude Code pede por tipo de operação. Um harness sem gradação de permissões tem exatamente dois modos: inútil e perigoso.
  • Isolamento real. Um sandbox de verdade é nsjail ou um contêiner, não uma lista de comandos proibidos. A diferença aparece no dia em que o agente compõe um comando que não está na sua lista.
  • Pontos de retorno. Os commits automáticos do Aider e as worktrees isoladas do Muse Code resolvem o mesmo problema: desfazer sem reconstruir à mão o que o agente tocou em 40 turnos.
  • Verificação que o próprio agente possa rodar. Em código é a suíte de testes: o agente sabe que terminou porque algo fica verde. Esta é a peça que cada setor precisa inventar, e a que decide se o projeto funciona.
  • Gestão de contexto. Compactar, resumir, recuperar, esquecer. Um agente que enche a janela com saída de ferramenta para de raciocinar muito antes de acabar os tokens.
  • Subagentes. Delegar uma subtarefa a uma cópia com contexto próprio evita que o trabalho de leitura contamine a linha principal. Antigravity, Claude Code e Muse Code fazem isso; a Hebbia faz em finanças separando recuperação de redação.
  • Observabilidade. Rastros por ação, não logs por sessão. Sem isso não há depuração, e em setor regulado também não há defesa.

Os verticais já chegaram: finanças e jurídico

Esta é a parte que vale ler devagar, porque é a evidência de que isto é um mercado, e não uma ideia.

Jurídico

A Harvey roda laços autônomos no formato clássico: planeja a abordagem, executa subtarefas, avalia resultados intermediários, ajusta e continua até cumprir o objetivo — com o agente decidindo quais ferramentas usar, quais documentos priorizar e quando a própria saída precisa de revisão. A vantagem declarada não é o modelo: é profundidade de plataforma, na ordem de 25.000 agentes personalizados e um Agent Builder com o qual os escritórios montam os seus.

A Legora atacou pelo lado da interface de domínio. Seu Tabular Review transforma uma pasta com centenas de contratos numa grade interativa para comparar cláusulas e extrair dados em escala. Em 2026 comprou a Walter AI para automação de fluxos nativa de agentes e a Qura para pesquisa jurídica. O que as duas vendem por baixo é o mesmo: ferramentas construídas para trabalho jurídico — revisão tabular, integração com o sistema de gestão documental do escritório, redlining, pesquisa —, aprovação humana nos pontos que importam, e trilhas de auditoria completas, em que cada ação do agente é rastreável, revisável e defensável.

Finanças

A Rogo é o caso mais literal: uma empresa vertical com a pilha inteira — dos modelos à interface — construída para profissionais de finanças. Seu agente, o Felix, executa fluxos financeiros de várias etapas: triagem de operações, geração de CIM, comparáveis, construção de modelos, preparação de pitchbooks, síntese de resultados e memorandos de diligência. Vem de fábrica com integrações a Pitchbook, Capital IQ e Datasite, modelos específicos de finanças e registro de conformidade por operação. Este último é o argumento comercial explícito contra um modelo generalista: um LLM de propósito geral não produz trilhas de auditoria apresentáveis a um regulador, separadas por deal.

A Hebbia resolve outra peça com uma decisão arquitetural interessante: subagentes especializados que separam a recuperação da formatação da saída, e uma grade de dados em que cada célula liga à sua citação de origem. É por isso que escritórios de advocacia, consultorias e times de diligência de private equity a usam para analisar data rooms.

Repare no que nenhuma das quatro fez: nenhuma venceu treinando um modelo melhor que o de fronteira. Venceram construindo as camadas 3, 4 e 5 para um ofício específico.

Traduzindo as camadas para o seu setor

A tese prática é esta: as cinco camadas são genéricas, mas o conteúdo de três delas é específico do seu ofício — e é aí que está a sua vantagem, não no laço.

CamadaNum harness de códigoNum harness financeiroNum harness jurídico
ExecuçãoLer, escrever, bash, grepCapital IQ, Pitchbook, o data room, o modelo em ExcelGestão documental, repositório de jurisprudência, modelos e playbooks do escritório
VerificaçãoOs testes passam, o linter cala, compilaOs comparáveis fecham, o modelo balanceia, cada cifra bate com a fonteCada afirmação cita uma fonte real, as cláusulas seguem o playbook, sem citações inventadas
SupervisãoO diff no PRRegistro de conformidade por operaçãoUma trilha defensável, ação por ação

A linha do meio é a que decide o projeto. Em código, a verificação vem de graça: há testes, compilador, linter, e o agente pode rodar todos sem pedir licença a ninguém. É por isso que os harnesses de código chegaram primeiro — não porque programar seja mais fácil que advogar.

A pergunta que diz se o seu processo se qualifica: existe uma checagem que uma máquina possa rodar e que distinga «terminado» de «parece terminado»? Se sim, você tem um harness. Se não, seu primeiro trabalho não é o agente — é construir essa checagem.

A boa notícia é que na maioria dos processos de back-office essa checagem já existe; só que hoje quem a executa é uma pessoa com uma lista. Conciliar uma conta, fechar um balanço, verificar que um contrato não se desvia do playbook, conferir que cada número de um relatório aparece na fonte: todas são regras explícitas que alguém aplica à mão. Escrevê-las como código é o trabalho — e é trabalho que não vence quando sai o próximo modelo.

Por que construir o seu em vez de comprar

Três razões, e nenhuma delas é «sai mais barato».

  1. Seu processo não é o processo médio do seu setor. Harvey e Rogo vendem o fluxo modal de um grande escritório ou de um banco de investimento. Quanto mais sua operação se parecer com a média, mais faz sentido comprar. Quanto mais específica for — e as operações que dão margem costumam ser as específicas —, menos o produto genérico cobre.
  2. O harness é onde mora o seu conhecimento, e ele não deprecia. Os pesos do modelo são trocados a cada poucos meses. As regras de verificação do seu ofício, suas integrações e sua definição de «pronto» sobrevivem a essa troca. O que é um bom argumento para que sejam seus.
  3. Os dados e a trilha não saem. Em setor regulado isso costuma deixar de ser preferência e virar requisito. O OpenHands existe justamente para esse caso.

Como começar sem queimar seis meses

O erro comum é começar pela camada de controle — o laço, os subagentes, o planejador — porque é a parte divertida. É também a parte já resolvida e que dá para pegar emprestada. A ordem que funciona é a inversa:

  1. Escolha um processo com final verificável. Repetitivo, com volume, e com uma checagem que uma máquina possa rodar. Se não tiver, escolha outro ou construa a checagem primeiro.
  2. Escreva a verificação antes do agente. Em código são testes. No seu ofício é um script que responde sim ou não a «isto está certo?». Sem isso você não tem um harness, tem um chat.
  3. Embrulhe seus sistemas como ferramentas, não como prompts. Um servidor MCP por sistema, com contratos tipados, idempotência e erros previsíveis. Escrevemos sobre isso à parte em templates MCP para chatbots corporativos e MCP do zero.
  4. Pegue a camada de controle emprestada. Comece com um harness existente antes de escrever um laço. Se for auto-hospedar, OpenHands. Se quiser ler um mínimo para entender, Pi.
  5. Instrumente desde o primeiro dia. Rastros por ação. Sobre memória e rastreabilidade publicamos o padrão de memória em camadas com Langfuse e Redis.
  6. Permissões antes de autonomia. Aprovação humana nas ações irreversíveis desde o início, afrouxada com evidência e não com otimismo.
  7. Meça com evals, não com demos. Uma suíte de casos reais rodando em CI. Detalhamos em evals de agentes em CI/CD.
harness-conciliacao/
├── tools/                 # camada de execução: um servidor MCP por sistema
│   ├── erp.ts             # ler lançamentos, nunca escrevê-los
│   ├── banco.ts           # extratos, somente leitura
│   └── ledger.ts          # escrita, com idempotência e operation_id
├── verify/                # a camada que decide se terminou
│   ├── fechamento.ts      # soma dos lançamentos == extrato, ao centavo
│   └── regras_fiscais.ts  # o que hoje uma pessoa confere com uma lista
├── policy/                # permissões: o que pode tocar sem perguntar
├── traces/                # supervisão: um rastro por ação, não por sessão
└── evals/                 # 40 fechamentos reais, com seus resultados

Repare no que não aparece nessa árvore: o laço. É deliberado. O laço é emprestado e trocado sem dor; os outros cinco diretórios são o ativo.

O que dá errado

  • Verificação que o agente consegue burlar. Se a checagem é fraca, o agente otimiza a checagem em vez do trabalho. É o mesmo fenômeno de um teste que passa porque a asserção foi apagada.
  • Autonomia antes dos rastros. Soltar o agente antes de conseguir reconstruir o que ele fez transforma qualquer incidente em arqueologia.
  • Ferramentas poderosas demais. Um único executar_sql é cômodo e é uma bomba. Ferramentas estreitas com contratos explícitos envelhecem melhor.
  • Confundir o piloto com o sistema. A demo funciona porque o caso foi escolhido; produção traz os 20% de casos estranhos onde mora todo o custo.
  • Comprar o vertical e não mudar o processo. Um harness não conserta um processo que ninguém escreveu. Se a definição de «pronto» mora na cabeça de uma pessoa, esse é o primeiro entregável.

Fontes

Quer resultados assim para sua empresa?

Iniciar conversa
Compartilhar