Meta Harness: a camada que falta na engenharia de agentes

Se o Agent Harness é o sistema ao redor do modelo, o Meta Harness é o sistema ao redor dos harnesses.

Essa distinção parece pequena, mas muda a arquitetura. O harness define como um agente pensa, usa ferramentas, guarda estado, monta contexto, pede aprovação e verifica resultado. O meta harness aparece quando isso deixa de caber em um único agente, uma única sessão ou um único repositório.

É a camada que responde perguntas que o agente sozinho não deveria tentar resolver:

• quais agentes participam desta tarefa?
• quais repositórios importam?
• qual trabalho anterior deve ser reaproveitado?
• quais permissões valem nesta organização?
• quando uma execução deve parar?
• como um erro de hoje vira melhoria no sistema amanhã?

Esse é o ponto em que AI Engineering deixa de ser “escolher o melhor agente” e vira engenharia de plataforma.

O harness não sumiu

O erro é tratar meta harness como substituto do harness. Não é.

Um agente ainda precisa de um bom loop, ferramentas estreitas, contexto bem montado, limites de custo, trilha de auditoria, evals e mecanismos de rollback. Sem isso, você só colocou uma camada bonita em cima de um executor frágil.

O meta harness entra quando o problema passa da fronteira local.

Um agente de código pode editar um repositório. Mas a mudança real talvez exija ajustar três clientes, validar contratos downstream, abrir PRs coordenados, reaproveitar uma decisão tomada por outro time ontem e lembrar que uma abordagem parecida já falhou mês passado.

Isso não é prompt. Também não é só contexto. É operação.

Existem três leituras úteis

“Meta harness” ainda é um termo novo, então vale separar as leituras.

A primeira é a leitura de pesquisa. O paper Meta-Harness: End-to-End Optimization of Model Harnesses usa um agente para otimizar harnesses. O sistema executa candidatos, salva código, scores e traces, e deixa um agente proponente inspecionar esse histórico via filesystem para escrever uma versão melhor.

O ponto importante não é “LLM gera código”. Isso já sabemos. O ponto é que o feedback não é comprimido para uma nota ou resumo curto. O proponente pode ler logs, erros, prompts, outputs e mudanças anteriores. Ele pode diagnosticar causa, não apenas reagir a score.

A segunda leitura é a de interoperabilidade. O Omnigent, da Databricks, chama de meta harness a camada comum acima de agentes como Claude Code, Codex, Pi e agentes customizados. A ideia é padronizar sessão, sandbox, política, colaboração, custo e composição sem depender do harness específico de cada agente.

A terceira leitura é organizacional. A Nx descreve o meta harness como uma espécie de Next.js para agentes: os agentes permanecem focados no núcleo, e a camada acima fornece o que falta para operar em organizações reais. O Polygraph, nessa visão, resolve principalmente duas limitações: espaço e tempo. Espaço, porque o agente precisa atravessar repositórios. Tempo, porque a organização precisa de memória entre sessões.

Essas três leituras não competem. Elas apontam para a mesma direção: o valor está subindo de camada.

O problema é espaço e tempo

A limitação mais óbvia de um agente é o contexto. A limitação mais cara é a continuidade.

Um agente normalmente nasce dentro de uma sessão. Ele vê um pedaço do mundo, executa uma tarefa e desaparece. Se outro agente ou outro desenvolvedor continuar depois, boa parte do conhecimento volta para a cabeça humana: por que essa opção foi descartada, quais arquivos eram relevantes, qual teste falhava, qual tradeoff foi aceito.

Esse é o gargalo de tempo.

O gargalo de espaço é parecido. Um agente preso a um repositório pode parecer produtivo e ainda assim quebrar o sistema. Ele altera uma API sem atualizar consumidores. Corrige um pacote sem validar exemplos. Refatora uma lib sem enxergar aplicações downstream.

Em empresas com muitos repositórios, o produto real não mora em um repo. Mora no grafo.

Um meta harness decente precisa tratar esse grafo como superfície de execução. Não basta clonar mais código no contexto. Ele precisa saber quais repositórios importam, quais contratos ligam as partes, quais pipelines validam a mudança e quais PRs precisam andar juntos.

A memória útil é operacional

Memória de agente costuma ser vendida como uma base vetorial com anotações antigas. Isso é pouco.

Para engenharia, memória útil é mais concreta:

• traces de execução;
• decisões aceitas e rejeitadas;
• PRs relacionados;
• falhas de CI;
• comandos rodados;
• diffs anteriores;
• evals que pioraram;
• incidentes que mudaram uma regra;
• preferências que viraram política.

Essa memória precisa ser consultável por agentes e auditável por humanos. Se ela vira apenas “lembranças” soltas em um prompt, o sistema volta a depender de sorte.

O insight do Meta-Harness acadêmico é forte justamente por isso: logs completos e navegáveis valem mais do que resumos bonitos. O agente não precisa receber tudo no contexto. Ele precisa conseguir procurar.

Coordenação não é chat entre agentes

Multi-agente é uma palavra fácil de estragar.

Colocar três agentes conversando não cria arquitetura. Muitas vezes cria latência, custo e uma sensação falsa de revisão. Coordenação útil é mais chata:

• dividir trabalho por fronteiras reais;
• isolar worktrees;
• manter ownership de arquivos;
• escolher revisores diferentes de autores;
• propagar contexto entre sessões;
• bloquear ações que violam política;
• sincronizar PRs e CI;
• preservar estado quando um agente falha.

Isso é meta harness. Não porque tem vários agentes, mas porque existe uma camada governando como agentes entram e saem do trabalho.

O meta harness também otimiza o harness

A parte mais interessante da pesquisa de Stanford é tratar o harness como artefato otimizável.

Hoje, a maioria dos times melhora agentes de forma artesanal. Alguém lê uma falha, ajusta o prompt, adiciona uma regra no AGENTS.md, muda uma ferramenta, roda de novo e torce. Isso funciona por um tempo, mas escala mal.

Um meta harness fecha esse ciclo:

1. executa tarefas reais ou evals;
2. salva traces completos;
3. compara score, custo e trajetória;
4. identifica regressões;
5. propõe mudanças no harness;
6. valida antes de promover.

Isso aproxima AI Engineering de engenharia de performance. Não se debate apenas opinião sobre prompt. Mede-se o sistema.

O risco é criar uma plataforma mágica

Toda nova camada vira tentação de abstração.

Um meta harness ruim tenta esconder a realidade. Ele promete que qualquer agente serve, qualquer repo entra, qualquer memória ajuda e qualquer fluxo vira automação. O resultado é uma plataforma que ninguém consegue depurar.

Um meta harness bom faz o contrário: torna o trabalho mais legível.

Ele mostra quais fontes foram usadas, quais decisões foram herdadas, quais ações foram bloqueadas, quais custos foram gastos, quais traces sustentam a mudança e qual parte do grafo foi afetada. Ele não transforma incerteza em confiança artificial. Ele reduz a quantidade de coisa que o humano precisa carregar na cabeça.

A régua prática

Se eu fosse avaliar um meta harness hoje, usaria perguntas bem objetivas:

1. Ele preserva traces completos ou só resumos?
2. Ele atravessa repositórios com modelo explícito de dependência?
3. Ele separa sessão, memória, política e execução?
4. Ele permite trocar agente sem perder histórico?
5. Ele coordena PRs, CI e revisão como uma única mudança?
6. Ele aplica permissões fora do prompt?
7. Ele mede custo, latência, taxa de sucesso e regressão?
8. Ele consegue otimizar o harness com base em falhas reais?
9. Ele falha de forma auditável?
10. Ele melhora o julgamento humano ou só tenta substituí-lo?

A última pergunta é a mais importante.

O objetivo não é colocar uma camada autônoma acima de outra camada autônoma e chamar isso de maturidade. O objetivo é construir um sistema onde agentes executam mais, mas a organização entende melhor o que está acontecendo.

O próximo gargalo

O modelo já não é o único gargalo. O agente também não será.

O próximo gargalo é a camada que permite que agentes trabalhem dentro de uma organização sem depender de um humano como cola entre sessões, repositórios, decisões e permissões.

Esse é o espaço do meta harness.

Ele não é uma ferramenta específica. É uma categoria arquitetural: a camada operacional acima dos agentes. Parte otimizador, parte memória, parte orquestrador, parte sistema de controle.

Times pequenos vão sentir isso como “quero que meu agente lembre o que já fiz”. Times grandes vão sentir como “quero que mudanças atravessem o grafo da empresa sem virar coordenação manual”. Laboratórios vão sentir como “quero que o sistema melhore o próprio harness com base em traces”.

São problemas diferentes, mas a resposta tem a mesma forma.

O agente escreve. O harness controla. O meta harness coordena, lembra e melhora.

Referências

• Meta-Harness: End-to-End Optimization of Model Harnesses
• Meta-Harness project page
• stanford-iris-lab/meta-harness
• Introducing Omnigent: A Meta-Harness to Combine, Control and Share Your Agents
• Meta Harnesses, Agents, and Lessons from the Framework Wars
• Announcing Polygraph: A Meta-Harness for Maximum Agent Autonomy
• Harness engineering: leveraging Codex in an agent-first world