O Design de Harness para Agentes da Anthropic Mudou Minha Forma de Pensar Sobre Sistemas de IA

Eu estava havia quatro horas assistindo uma IA construir uma estacao de trabalho de audio digital. Nao era uma demo de brinquedo — era uma DAW no navegador com a Web Audio API, edicao multitrack e um visualizador de forma de onda. O agente vinha rodando de forma autonoma o tempo todo. Sem ajuda manual. Sem correcoes no meio da sessao. Apenas uma IA avancando funcionalidade apos funcionalidade, fazendo commits, testando o proprio trabalho e seguindo em frente.

Entao ele parou.

Nao porque travou. Nao porque ficou sem contexto. Parou porque uma IA separada — o avaliador — informou que o timing da reproducao de audio estava deslocado em 12 milissegundos e que a renderizacao da forma de onda nao correspondia aos dados reais de frequencia. O agente gerador voltou, corrigiu ambos os problemas e submeteu novamente. O avaliador testou pela segunda vez, confirmou as correcoes e aprovou o sprint.

Essa interacao — dois agentes de IA discutindo sobre qualidade como um desenvolvedor e um engenheiro de QA — e o nucleo do que a Anthropic publicou em seu design de harness para desenvolvimento de aplicacoes de longa duracao. E isso reconfigurou completamente como eu penso sobre a construcao de sistemas autonomos.

O modelo nao e o produto. O harness e.

Por Que Seu Agente de IA Continua Falhando em Tarefas Complexas

Aqui esta um padrao pelo qual eu ja passei dezenas de vezes. Voce da a um agente de IA um projeto complexo — construir uma aplicacao full-stack, refatorar um codebase grande, criar um design system de multiplas paginas. O agente comeca forte. Os primeiros 20 minutos parecem promissores. Entao, por volta dos 45 minutos, as coisas comecam a desandar. Etapas sao puladas. A qualidade cai. O agente declara o projeto "concluido" quando esta talvez 60% pronto.

Eu costumava culpar o modelo. "O Sonnet nao e inteligente o suficiente para isso." "Preciso de prompts melhores." "A janela de contexto e pequena demais."

A pesquisa da Anthropic inverteu completamente esse diagnostico. O modelo raramente era o gargalo. O harness era.

Um harness de agente e o framework de software que envolve um modelo de IA — gerenciando prompts, orquestrando ferramentas, impondo restricoes, lidando com loops de feedback e validando a saida. Pense da seguinte forma: o modelo de IA e um motor. Potencia bruta. O harness e o carro. Volante, freios, transmissao, GPS. Sem o carro, o motor fica numa bancada fazendo barulho.

Essa distincao importa mais do que a maioria dos engenheiros de IA percebe. Voce pode trocar um V6 por um V8 (Sonnet por Opus), e tera uma melhoria incremental. Mas redesenhe o carro — mude como o motor se conecta as rodas, adicione um sistema de navegacao, instale freios melhores — e toda a experiencia de direcao se transforma.

Foi isso que a Anthropic demonstrou. Nao um modelo melhor. Um sistema melhor ao redor do modelo. E os resultados foram dramaticos o suficiente para que eu reconstruisse meus proprios workflows de agentes dentro de uma semana apos ler o artigo deles.

Mas antes de entrar no que eles construiram, voce precisa entender o que continua dando errado — porque esses modos de falha estao escondidos em todo sistema de agente de longa duracao que ja vi, incluindo os que eu mesmo construi.

Os Dois Modos de Falha Sobre os Quais Ninguem Fala Honestamente

A Anthropic identificou dois modos criticos de falha em agentes de longa duracao. Eu vivenciei ambos tantas vezes que ler a analise deles pareceu como se alguem tivesse instalado cameras no meu ambiente de desenvolvimento.

Ansiedade de Contexto: Quando Seu Agente Entra em Panico

Ansiedade de contexto e o que acontece quando um modelo de IA percebe que esta se aproximando dos limites de sua janela de contexto. O comportamento e sutil e insidioso. O agente nao trava. Nao lanca um erro. Em vez disso, comeca a apressar tudo. Etapas sao comprimidas. Explicacoes ficam curtas. Subtarefas complexas que deveriam exigir planejamento cuidadoso sao descartadas com um aceno. O agente comeca a encerrar prematuramente — declarando vitoria em um projeto pela metade porque algum sinal interno esta gritando "voce esta ficando sem espaco."

Notei isso pela primeira vez com o Sonnet 4.5 durante um projeto de refatoracao. Por volta da marca de 80K tokens, o agente mudou de um trabalho cuidadoso e metodico para o que so posso descrever como speed-running ansioso. Parou de ler arquivos antes de edita-los. Pulou execucoes de teste. Comecou a gerar comentarios como "os itens restantes sao diretos e seguem o mesmo padrao" — que e linguagem de agente para "estou desistindo e torcendo para voce nao perceber."

A solucao da Anthropic envolve duas tecnicas complementares.

Compactacao de contexto resume e condensa o historico da conversa, preservando as informacoes essenciais enquanto libera espaco de tokens. A IA essencialmente escreve para si mesma um briefing compactado de tudo que aconteceu ate agora e trabalha a partir desse briefing em vez do historico bruto. Ha perda — alguns detalhes sao descartados — mas uma boa estrategia de compactacao preserva as decisoes criticas e o estado atual.

Resets de contexto vao alem. Em vez de comprimir o contexto existente, voce da ao agente uma janela de contexto completamente nova para cada sprint ou subtarefa. O agente comeca limpo, apenas com as informacoes necessarias para a parte atual do trabalho. O progresso nao vive na memoria do modelo — vive em arquivos, commits git e artefatos estruturados no disco.

Aqui esta o avanco que importa para quem constroi: o Opus 4.6 com sua janela de contexto de 1 milhao de tokens eliminou amplamente a ansiedade de contexto como preocupacao pratica. A janela e tao enorme que a maioria das sessoes autonomas de varias horas nunca chega perto de preenche-la. A Anthropic descobriu que poderia abandonar completamente os resets de contexto com o Opus 4.6 e depender apenas da compactacao. O que antes exigia um sistema complexo de handoff entre multiplas sessoes agora roda como uma unica sessao continua.

Isso nao significa que o gerenciamento de contexto esteja resolvido para sempre. Force o Opus 4.6 o suficiente — uma sessao autonoma de um dia inteiro com leitura extensiva de arquivos — e voce atingira os limites. Mas o limiar mudou de "um problema serio apos 45 minutos" para "um caso extremo apos 6+ horas." Para a maioria das tarefas do mundo real, essa e a diferenca entre precisar de uma solucao alternativa no harness e nao precisar de nenhuma.

Falha de Autoavaliacao: O Agente Que Acha Que Tudo Que Faz E Otimo

O segundo modo de falha e mais perigoso porque e mais dificil de detectar.

Quando voce pede a um agente de IA para avaliar seu proprio trabalho, ele mente. Nao deliberadamente — mas de forma consistente. O padrao e previsivel: o agente gera uma saida, a revisa e conclui que a saida e boa. Mesmo quando, para um observador humano, a qualidade e obviamente mediana.

Ja assisti isso acontecer em tempo real. Um agente constroi uma landing page com elementos desalinhados, espacamento inconsistente e uma paleta de cores que parece ter sido escolhida por um gerador de numeros aleatorios. Voce pede ao agente para avaliar o resultado. "O design e limpo e profissional, com boa hierarquia visual e espacamento consistente." Ele esta descrevendo o design que pretendia construir, nao o que realmente construiu.

Isso nao e um problema de prompting. Voce pode adicionar "seja critico" e "procure falhas" ao system prompt, e o agente vai concordar, fingir ser critico e entao aprovar seu proprio trabalho com algumas ressalvas superficiais. "Embora haja espaco para melhoria na paleta de cores, o design geral comunica efetivamente a mensagem da marca." Traducao: "Estou fingindo ser critico sem mudar nada."

O diagnostico da Anthropic e direto e, na minha experiencia, preciso: tornar um gerador autocritico e um problema fundamentalmente mais dificil do que construir um critico separado e dedicado. A solucao arquitetural nao e tornar o gerador melhor em autoavaliacao. E separar os papeis completamente.

O que nos leva a arquitetura que realmente funciona.

A Arquitetura de Tres Agentes: Planejador, Gerador, Avaliador

O design final de harness da Anthropic usa tres agentes especializados trabalhando em conjunto. Se voce ja trabalhou em uma equipe com um product manager, um desenvolvedor e um engenheiro de QA — isso vai parecer familiar. Porque e exatamente essa dinamica que eles replicaram.

O Planejador

O Planejador recebe um prompt simples — "construa um aplicativo de gerenciamento de projetos com um quadro Kanban" — e o expande em uma especificacao detalhada de produto. Listas de funcionalidades. User stories. Requisitos tecnicos. Direcao de design visual.

O Planejador e deliberadamente ambicioso. A Anthropic descobriu que um planejamento conservador levava a resultados decepcionantes. Quando o Planejador mirava alto, o Gerador produzia aplicacoes mais criativas e mais completas — mesmo que nao atingisse todos os alvos. Uma spec que pede "uma interface bonita, com qualidade de museu e elementos 3D" produz resultados melhores do que uma que pede "uma UI limpa e funcional." O listao alto puxa a saida para cima.

Uma coisa que a Anthropic aprendeu da maneira dificil: o Planejador deve focar no que e no por que, nao no como. Quando o Planejador incluia detalhes granulares de implementacao tecnica, esses detalhes propagavam erros em cascata pelo trabalho do Gerador. Um Planejador que diz "implemente colaboracao em tempo real" e melhor do que um que diz "use WebSockets com um padrao pub/sub no Redis" — porque o Gerador pode encontrar uma abordagem melhor que a especificidade prematura do Planejador teria impedido.

O Gerador

O Gerador trabalha em sprints, implementando uma funcionalidade por vez. Cada sprint tem um escopo claro derivado da spec do Planejador, e o Gerador faz commits de codigo incrementalmente — o que significa que o progresso e preservado no git independentemente do que aconteca com o contexto do agente.

Essa abordagem baseada em sprints e onde vejo o paralelo mais forte com a forma como ja uso o Claude Code. Quando estou trabalhando com a arquitetura de enxame de agentes do Claude Code, o mesmo principio se aplica: divida trabalho complexo em partes discretas, torne o progresso visivel por meio de artefatos (arquivos, commits, grafos de tarefas) e nunca dependa da memoria do modelo como fonte da verdade.

O Gerador tambem inclui uma etapa de autoavaliacao embutida antes de entregar ao Avaliador — uma verificacao rapida de sanidade. Isso captura os problemas obvios (erros de sintaxe, imports faltando, builds quebrados) sem depender do Avaliador para coisas que o Gerador deveria pegar sozinho. Pense nisso como um desenvolvedor rodando seus proprios testes antes de abrir um PR. Voce ainda precisa de code review, mas nao deveria desperdicar o tempo do revisor com problemas que seu linter pegaria.

O Avaliador: Onde Esta a Verdadeira Inovacao

O Avaliador e o que torna essa arquitetura genuinamente diferente de qualquer coisa que eu ja construi.

A maioria dos sistemas de avaliacao de IA revisa codigo de forma estatica — le os arquivos fonte, analisa a estrutura e da feedback. O Avaliador da Anthropic nao apenas le codigo. Ele usa a aplicacao. Atraves de automacao de navegador com Playwright, o Avaliador navega pela aplicacao em execucao, clica em botoes, preenche formularios, tira screenshots, testa endpoints de API e investiga estados do banco de dados. Ele interage com o produto ao vivo da mesma forma que um engenheiro de QA humano faria.

Os criterios de avaliacao tambem nao sao vagos. A Anthropic definiu quatro dimensoes especificas:

Qualidade de Design — A saida visual atende a padroes profissionais? Layout, tipografia, cores, espacamento — medidos em relacao a spec do Planejador, nao a ideais abstratos.

Originalidade — A saida parece o tipico conteudo generico de IA, ou tem identidade criativa genuina? Esse criterio existe especificamente para combater o problema de "tudo que a IA constroi parece igual." Quando li isso, imediatamente pensei no guia de design systems para IA que escrevi — o problema de interfaces geradas por IA convergindo todas para a mesma estetica e real, e a Anthropic esta explicitamente avaliando contra isso.

Acabamento — Qualidade de execucao tecnica. Codigo limpo, tratamento adequado de erros, layouts responsivos, performance. O tipo de coisa que um engenheiro senior notaria durante um code review.

Funcionalidade — A funcionalidade realmente funciona? Nao "o codigo parece correto" — o botao faz o que deveria fazer quando voce clica nele?

O Avaliador classifica cada sprint de acordo com esses criterios. Se as notas nao atingem o limiar, o Gerador volta e itera. Isso cria um loop de feedback estruturalmente identico a como funcionam as GANs (Redes Adversariais Generativas) — um gerador tentando produzir saida que engane o discriminador, e um discriminador ficando melhor em detectar deficiencias.

Eis o que me surpreendeu: acertar o Avaliador exigiu multiplas iteracoes. Os avaliadores iniciais da Anthropic baseados no Claude tinham o mesmo problema da autoavaliacao — eram lenientes demais. Aprovavam trabalho mediano com feedback encorajador. Foi necessaria engenharia de prompt deliberada para tornar o Avaliador genuinamente adversarial. Um system prompt cetico. Instrucoes explicitas para procurar tipos especificos de falha. Permissao para rejeitar trabalho e exigir revisoes.

Este e o insight-chave ao qual continuo voltando: calibrar um avaliador dedicado para ser cetico e um problema fundamentalmente mais tratavel do que tornar um gerador autocritico. O avaliador tem um unico trabalho — encontrar problemas. O gerador tem um incentivo conflitante — ele quer terminar. Separar esses papeis nao e apenas boa arquitetura. E necessario.

O Contrato de Sprint: Alinhando Gerador e Avaliador Antes do Trabalho Comecar

Um detalhe do design da Anthropic que nao vi sendo discutido o suficiente em outros lugares e o contrato de sprint.

Antes de cada sprint comecar, o Gerador e o Avaliador negociam um contrato. O Gerador propoe o que vai entregar. O Avaliador confirma que entende os criterios de aceitacao. Ambos os agentes concordam sobre o que significa "pronto" antes que uma unica linha de codigo seja escrita.

Isso parece burocratico. Nao e. E a diferenca entre um PR que e aprovado na primeira revisao e um que vai e volta cinco vezes porque o desenvolvedor e o revisor tinham expectativas diferentes.

Sem o contrato, ja assisti agentes avaliadores rejeitarem trabalho por nao atender a padroes que nunca foram comunicados. O Gerador constroi uma funcionalidade de um jeito, o Avaliador queria de outro, e o loop de iteracao queima tokens discutindo requisitos que deveriam ter sido definidos antecipadamente.

O contrato resolve isso tornando as expectativas explicitas. "O Sprint 3 implementara o editor de niveis com posicionamento de sprites por drag-and-drop, uma paleta de tiles com pelo menos 20 itens e suporte a desfazer/refazer. O Avaliador verificara a funcionalidade criando um nivel de teste, posicionando sprites e confirmando que o desfazer funciona para pelo menos 5 operacoes sequenciais."

Essa especificidade — nomear testes de aceitacao exatos — elimina toda uma classe de iteracoes desperdicadas. E e um padrao que comecei a emprestar para meus proprios workflows de agentes, mesmo fora do design de harness da Anthropic.

O Que os Experimentos Realmente Mostraram

Teoria e uma coisa. A Anthropic rodou tres experimentos que colocaram essa arquitetura sob pressao real. Os resultados contam historias diferentes dependendo de qual voce analisa.

Experimento 1: O Site do Museu de Arte Holandes

A tarefa: criar o site de um museu de arte holandes ficticio. Este e um desafio subjetivo, fortemente focado em design, onde "bom" e dificil de definir e mais dificil de avaliar.

O harness passou por mais de 10 iteracoes de feedback entre o Gerador e o Avaliador. As versoes iniciais eram genericas — o tipo de paginas com cara de template que qualquer IA produz. Por volta da iteracao 7 ou 8, o design havia evoluido para algo genuinamente incomum: uma visualizacao 3D de uma sala com piso quadriculado, obras de arte exibidas em paredes virtuais e uma navegacao que parecia como caminhar por uma galeria.

O ponto nao e que o design final era perfeito. E que o loop adversarial iterativo empurrou a saida para alem do plato de "bom o suficiente" que a geracao de IA em passagem unica sempre atinge. O Gerador continuava buscando solucoes mais criativas porque o Avaliador continuava rejeitando as seguras. Essa dinamica — pressao para exceder, nao apenas atender, padroes — nao acontece quando um agente avalia a si mesmo.

Experimento 2: O Criador de Jogos 2D Retro

Este foi o experimento mais revelador. Duas execucoes da mesma tarefa: construir um criador de jogos 2D retro com um editor de niveis, editor de sprites e sistema de comportamento.

Execucao 1 (harness solo — apenas Gerador): A saida parecia visualmente aceitavel em screenshots. Mas quando voce realmente tentava usa-la, o jogo nao funcionava. Sprites nao se moviam. O editor de niveis nao conseguia salvar niveis. Era uma vila Potemkin de um criador de jogos — apresentavel por fora, oco por dentro.

Execucao 2 (harness completo — Planejador + Gerador + Avaliador): O Planejador criou specs detalhadas com definicoes explicitas de pronto para cada sprint. O Avaliador testou cada funcionalidade interativamente usando Playwright, capturando falhas funcionais que o Gerador teria declarado como "concluidas." O resultado: um criador de jogos funcional. Nao com qualidade AAA, mas funcional. Voce podia criar sprites, construir niveis, atribuir comportamentos e realmente jogar o resultado.

A diferenca entre essas duas execucoes e todo o argumento a favor da engenharia de harness em um unico exemplo. Mesmo modelo. Mesma tarefa. Mesmo orcamento computacional. A unica diferenca foi o sistema envolvendo o modelo.

Experimento 3: A DAW no Navegador

O teste mais ambicioso: construir uma estacao de trabalho de audio digital no navegador usando a Web Audio API, rodando no Opus 4.6.

Este experimento foi concluido em aproximadamente 4 horas a um custo de cerca de US$ 125 em chamadas de API. O resultado era funcional — audio multitrack, visualizacao de forma de onda, edicao basica — mas nao de nivel profissional. Mais importante, este experimento demonstrou como melhorias no modelo simplificam os requisitos do harness.

Com a janela de contexto de um milhao de tokens do Opus 4.6, a Anthropic abandonou os sprints completamente. Sem resets de contexto. Sem negociacao de contrato entre Gerador e Avaliador. Apenas uma sessao continua com compactacao automatica gerenciando o crescimento do contexto. O harness que o Sonnet 4.5 precisava — complexo, com multiplas sessoes, gerenciando cuidadosamente os limites de contexto — se tornou desnecessario.

Este e o aprendizado mais importante para quem constroi: suas premissas sobre o harness precisam evoluir com o modelo. Um harness projetado para as limitacoes do Sonnet 4.5 vai super-engenheirar a camada de orquestracao quando rodar no Opus 4.6. E um harness projetado para as capacidades do Opus 4.6 vai quebrar quando o proximo modelo introduzir novos comportamentos ou eliminar os antigos. Engenharia de harness nao e uma configuracao unica. E uma pratica continua.

Se voce prefere que alguem construa esse tipo de sistema de harness multi-agente para o seu caso de uso, eu aceito projetos personalizados de desenvolvimento de agentes de IA. Voce pode ver o que ja construi em fiverr.com/s/EgxYmWD.

Como Isso Se Conecta a Padroes Que Voce Ja Conhece

O design de harness da Anthropic nao existe no vacuo. Ele se posiciona ao lado de dois outros padroes que todo construtor serio de agentes deveria entender — porque eles resolvem pecas adjacentes do mesmo quebra-cabeca.

O Loop Ralph Wiggum

Criado por Geoffrey Huntley e formalizado por Boris Cherny (Head do Claude Code na Anthropic) no final de 2025, o Loop Ralph Wiggum e elegante em sua simplicidade. Voce roda um agente em um loop bash. Apos cada iteracao, voce verifica a saida contra algo que nao pode mentir — um linter, um verificador de tipos, uma suite de testes. Se passar, voce para. Se falhar, repete o loop.

O insight-chave: o progresso vive em arquivos e no historico do git, nao na janela de contexto do modelo. Cada iteracao comeca com contexto limpo. O agente le o estado atual do codebase, trabalha nele e faz commit das mudancas. Se o loop precisa continuar, a proxima iteracao le os arquivos atualizados com zero de divida acumulada de contexto.

Esse padrao agora e um plugin nativo do Claude Code. Voce pode rodar /ralph-loop "Fix all TypeScript errors" --max-iterations 20 --completion-promise "ALL_FIXED" e ir fazer outra coisa.

Onde o Loop Ralph Wiggum difere do harness de tres agentes da Anthropic: ele funciona melhor para tarefas objetivamente verificaveis. "Corrigir todos os erros de linting" tem uma verdade binaria — o linter passa ou nao passa. "Construir um criador de jogos bonito e funcional" nao tem. Essa lacuna subjetiva e exatamente o que o avaliador adversarial preenche.

Desenvolvimento Orientado a Especificacao

A terceira peca do quebra-cabeca e estruturar requisitos antes que o agente comece a codar. Frameworks como o Spec Kit do GitHub, o BMAD-METHOD e o OpenSpec resolvem todos o mesmo problema: agentes que comecam a codar antes de entender o que estao construindo.

Isso se mapeia diretamente ao agente Planejador no design da Anthropic. O Planejador e essencialmente um escritor automatizado de specs. Mas voce nao precisa de um agente Planejador dedicado para obter o beneficio. Escrever uma spec clara — funcionalidades, criterios de aceitacao, definicao de pronto — antes de entregar trabalho a um agente produz resultados dramaticamente melhores do que jogar um prompt vago em um modelo e torcer pelo melhor.

A abordagem orientada a especificacao tambem explica por que o experimento do criador de jogos mostrou resultados tao diferentes entre as execucoes solo e com harness completo. A execucao solo nao tinha spec. O agente improvisou conforme avancava, reduzindo ambicoes a cada passo ate que "criador de jogos" se tornou "alguns elementos de UI que parecem relacionados a jogos." A execucao com harness completo tinha uma spec explicita com definicoes de pronto — e um avaliador que as aplicava.

Venho usando uma versao disso no meu proprio trabalho desde que construi o guia do Anthropic Agent SDK. Toda tarefa complexa de agente agora comeca com uma spec escrita. Nao porque o agente nao consegue trabalhar sem uma — mas porque a spec e a ancora que impede desvio de escopo, conclusao prematura e a morte lenta da ambicao que aflige toda sessao longa de IA.

O Que Isso Significa Para Como Voce Constroi Agentes Agora Mesmo

Aqui e onde quero ser pratico. A pesquisa da Anthropic e construida sobre o Claude Agent SDK, mas os principios se aplicam independentemente de qual modelo ou framework voce esta usando. Se voce esta construindo qualquer coisa que roda de forma autonoma por mais de 15 minutos, eis o que eu tiraria deste trabalho.

Separe geracao de avaliacao. Sempre.

Esta e a unica mudanca de maior alavancagem que voce pode fazer em qualquer workflow de agente. Se seu agente gera saida e avalia essa saida no mesmo contexto, voce tem um problema de confiabilidade. Pode nao aparecer em tarefas simples. Mas no momento em que a complexidade aumenta — mudancas em multiplos arquivos, requisitos subjetivos de qualidade, interdependencias entre funcionalidades — a autoavaliacao falha silenciosamente.

Voce nao precisa de um sistema adversarial sofisticado para comecar. Um segundo agente com um system prompt cetico que revisa a saida do primeiro agente e suficiente para pegar as falhas de autoaprovacao mais graves. Eu rodo uma versao disso no meu pipeline de conteudo, e o avaliador rejeita aproximadamente 30% dos primeiros rascunhos — rascunhos que, sem verificacao, teriam sido publicados com problemas estruturais que eu pegaria durante a revisao manual.

Use artefatos, nao memoria, como sua fonte da verdade

Cada peca de progresso deveria existir fora da janela de contexto do modelo. Commits git. Arquivos JSON de tarefas. Specs em Markdown. Logs estruturados. Se a sessao do seu agente travar e o unico registro do que aconteceu estiver no historico da conversa — voce construiu um sistema fragil.

Este e o mesmo principio por tras da arquitetura de grafo de tarefas persistente do Claude Code. O grafo de tarefas vive no disco. Agentes o leem, atualizam e escrevem de volta nele. Janelas de contexto vem e vao. O grafo de tarefas persiste.

Combine a complexidade do seu harness com as capacidades do seu modelo

A propria evolucao da Anthropic prova esse ponto. O harness que eles construiram para o Sonnet 4.5 — com resets de contexto, limites de sprint, negociacao de contrato — era necessario porque o modelo precisava disso. O harness que construiram para o Opus 4.6 abandonou metade desses componentes porque a janela de contexto de um milhao de tokens do modelo e sua consistencia aprimorada os tornaram desnecessarios.

Audite seu proprio harness. Voce esta rodando gerenciamento complexo de contexto porque o modelo realmente precisa, ou porque voce projetou o sistema seis meses atras quando o modelo precisava? Super-engenheirar a camada de orquestracao desperdicara tokens, adicionara latencia e introduzira pontos de falha que o modelo atual poderia simplesmente resolver sozinho.

Defina "pronto" antes de comecar

O padrao de contrato de sprint — onde Gerador e Avaliador concordam sobre criterios de aceitacao antes do trabalho comecar — se aplica a toda interacao com agente, nao apenas a sistemas multi-agente. Quando voce solicita a um agente "construa um dashboard," defina o que o dashboard deve incluir, como voce verificara cada funcionalidade e qual barra de qualidade voce espera. Quanto mais explicita for sua definicao de pronto, menos espaco o agente tera para declarar vitoria prematura.

As Limitacoes Honestas: O Que a Engenharia de Harness Nao Resolve

Eu estaria prestando um desservico se deixasse voce sair achando que engenharia de harness e uma bala de prata. Nao e. Apos semanas implementando esses padroes, aqui estao os muros que encontrei.

O custo se acumula rapido. O experimento da DAW no navegador custou US$ 125 em chamadas de API para aproximadamente 4 horas de trabalho autonomo. Um sistema de tres agentes queima aproximadamente 3x os tokens de uma abordagem de agente unico porque voce esta rodando tres modelos (ou tres sessoes do mesmo modelo) em coordenacao. Para projetos de hobby e experimentos, tudo bem. Para sistemas em producao rodando 24/7, a economia precisa de modelagem cuidadosa.

A qualidade do avaliador e o teto. Seu sistema so pode ser tao bom quanto a capacidade do seu avaliador de detectar problemas. Se o avaliador nao consegue identificar um desalinhamento sutil na UI ou uma condicao de corrida em codigo assincrono, esses problemas vao para producao. A Anthropic reconheceu isso — seus avaliadores iniciais perdiam bugs sutis e aprovavam implementacoes superficiais. Acertar o avaliador exigiu iteracao, nao apenas ajustes de prompt.

Qualidade subjetiva continua dificil. O experimento do museu holandes mostrou melhoria impressionante por meio de iteracao adversarial. Mas "impressionante para IA" e "impressionante comparado a um designer humano com 10 anos de experiencia" sao listoes diferentes. A engenharia de harness reduz essa lacuna. Nao a fecha. Para trabalho criativo subjetivo — design, escrita, musica — avaliacao humana continua necessaria na etapa final.

Debugar o harness e uma habilidade propria. Quando um unico agente produz saida ruim, o debug e direto: leia a conversa, encontre onde deu errado, corrija o prompt. Quando um sistema de tres agentes produz saida ruim, a falha pode estar na spec do Planejador, na implementacao do Gerador, nos criterios do Avaliador ou na interacao entre quaisquer dois deles. Passei mais tempo debugando interacoes de harness do que jamais passei debugando prompts de agentes individuais.

Essas sao limitacoes reais. Elas nao invalidam a abordagem — o experimento do criador de jogos prova que a arquitetura de tres agentes produz resultados dramaticamente melhores do que a geracao solo. Mas significam que a engenharia de harness e uma pratica que exige iteracao, monitoramento e refinamento continuo. Nao um padrao que voce implementa uma vez e esquece.

Para Onde Isso Vai

A Anthropic publicou dois artigos sobre este topico — o primeiro em novembro de 2025 focado no padrao de inicializador e agente de codificacao, e o follow-up de marco de 2026 introduziu a arquitetura completa de tres agentes com avaliacao adversarial. A trajetoria indica para onde isso esta indo.

Melhorias no modelo simplificam o design do harness. O Opus 4.6 eliminou a necessidade de resets de contexto. A proxima geracao pode eliminar a necessidade de compactacao explicita de contexto. Mas melhorias no modelo nao eliminam a necessidade de orquestracao e avaliacao. Mesmo um modelo hipoteticamente perfeito — com contexto infinito, memoria perfeita e zero erros de raciocinio — ainda produziria saida melhor com um avaliador separado desafiando seu trabalho. Isso nao e uma limitacao do modelo. E um insight fundamental sobre como qualidade emerge de pressao adversarial.

A previsao pratica que eu faria: dentro de 12 meses, plataformas de harness-as-a-service serao tao comuns quanto plataformas de RAG-as-a-service sao hoje. Ferramentas como o Ralph Loop Agent da Vercel e o ecossistema crescente em torno de frameworks de desenvolvimento orientado a especificacao como o Spec Kit do GitHub sao sinais iniciais. A materia-prima — modelos, capacidades de uso de ferramentas, APIs de avaliacao — ja esta pronta para producao. O que falta e a camada de orquestracao empacotada que torne isso acessivel para engenheiros que nao querem construir infraestrutura de harness do zero.

Para quem esta construindo neste espaco agora, a oportunidade e clara. O harness e o produto. O modelo e uma commodity. As equipes e engenheiros que ficarem bons em design de harness — que aprenderem a decompor tarefas, construir avaliadores confiaveis, gerenciar contexto de forma eficaz e iterar seus padroes de orquestracao junto com melhorias de modelo — construirao sistemas de IA que funcionam em producao enquanto todos os outros ainda estarao lutando com prompts de agente unico que desmoronam apos 30 minutos.

Aquela sessao da DAW que assisti? Quatro horas de codificacao autonoma que produziram uma aplicacao funcional. Nao porque o modelo era magico. Porque o sistema ao redor dele foi engenheirado para manter o modelo honesto, mante-lo focado e mante-lo iterando ate que o trabalho estivesse realmente pronto.

Essa e a licao. Nao IA melhor. Sistemas melhores ao redor da IA.

Perguntas Frequentes

O que e um harness de agente em desenvolvimento de IA?

Um harness de agente e o framework de software que envolve um modelo de IA para gerenciar prompts, ferramentas, loops de feedback e validacao — transformando um modelo bruto em um sistema autonomo confiavel. Pense nele como o carro que torna o motor util: direcao, freios, navegacao e tudo mais. Para uma explicacao mais detalhada, veja a secao "Por Que Seu Agente de IA Continua Falhando" acima.

Como a ansiedade de contexto afeta agentes de IA?

A ansiedade de contexto ocorre quando modelos de IA percebem que estao se aproximando dos limites da janela de contexto e comecam a apressar, pular etapas ou declarar tarefas concluidas prematuramente. O Sonnet 4.5 exibia esse comportamento por volta dos 80K tokens. A janela de um milhao de tokens do Opus 4.6 elimina amplamente o problema para sessoes de menos de 6 horas. Veja a secao de modos de falha para estrategias de mitigacao.

Qual e a diferenca entre compactacao de contexto e reset de contexto?

A compactacao de contexto resume o historico da conversa para liberar espaco de tokens preservando informacoes-chave — com perdas, mas continua. O reset de contexto inicia o agente com uma janela de contexto completamente nova para cada subtarefa, dependendo de arquivos e artefatos para manter o estado. Modelos mais novos com janelas de contexto maiores favorecem compactacao em vez de resets.

Como a avaliacao adversarial melhora a saida de agentes de IA?

A avaliacao adversarial separa a geracao de conteudo da avaliacao de qualidade usando dois agentes distintos — inspirada na arquitetura de GANs. O agente avaliador usa ferramentas como Playwright para testar interativamente aplicacoes em execucao, capturando falhas funcionais que a revisao de codigo sozinha nao detecta. Os experimentos da Anthropic mostraram que isso produz aplicacoes funcionais onde a geracao solo produz saidas visualmente similares, mas nao funcionais.

Posso implementar padroes de harness de agente sem o Claude Agent SDK?

Sim. Os principios — decomposicao de tarefas, estado baseado em artefatos, avaliacao separada, contratos de sprint — sao agnosticos em relacao a modelo e framework. O Claude Agent SDK fornece abstracoes convenientes, mas voce pode implementar os mesmos padroes com qualquer API de modelo, uma camada de orquestracao em Python e ferramentas padrao como Playwright para avaliacao.

Vamos Trabalhar Juntos

Quer construir sistemas de IA, automatizar workflows ou escalar sua infraestrutura tech? Adoraria ajudar.

• Fiverr (builds e integracoes personalizadas): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (solucoes enterprise): ramlit.com
• ColorPark (design e branding): colorpark.io
• xCyberSecurity (servicos de seguranca): xcybersecurity.io