O maior erro da indústria de IA neste momento: todo mundo está empurrando os agentes para trabalhar mais rápido sem antes verificar se o ambiente em que eles operam está devidamente construído.
Essa frase é de Andrej Karpathy. Ele não está discutindo teoria — ele validou isso com um projeto open-source de 90 mil estrelas: o maior gargalo no desempenho dos agentes nunca é o modelo em si; é o sistema de execução ao redor do modelo que ninguém se deu ao trabalho de construir direito.
Dois conjuntos de dados experimentais confirmam isso.
Mesmo Modelo, Harnesses Diferentes: um Gap de 76 Pontos
O engenheiro de ML da Hugging Face Joel Niklaus realizou um experimento de controle meticuloso. Ele pegou o modelo open-source DeepSeek-V4-Pro, congelou todos os pesos — sem fine-tuning, sem troca de modelo, sem mudanças de prompt — e permitiu que apenas uma variável mudasse: o código e a lógica de execução envolvida ao redor do modelo, o chamado Agent Harness.
Os resultados foram impressionantes: mesmo modelo, mesmas tarefas, mesmo avaliador — e simplesmente trocando entre cinco Harnesses diferentes, a pontuação composta oscilou loucamente entre 3,5% e 80,1%.
Mas a parte mais chocante veio em seguida. Nos testes iniciais, as saídas de raciocínio jurídico do modelo estavam, na verdade, todas corretas — mas ele continuava salvando os resultados no nome de arquivo errado, então o programa de teste nunca conseguia lê-los. Pontuação: 0%. Ou seja, aquele 0% nunca estava medindo a inteligência do modelo. Estava medindo se o Harness funcionava ao menos.
Niklaus então executou cerca de 22 rodadas de otimização iterativa automatizada de código no melhor Harness. O DeepSeek-V4-Pro — com os pesos completamente intocados — melhorou de 63,4% no Harness original para 80,1%, igualando o líder closed-source de ponta Claude Sonnet 4.6 com um sétimo do custo de execução. Mais criticamente, o Harness otimizado foi transferido para o menor DeepSeek-V4-Flash e ainda entregou um ganho de 14,4 pontos. Isso prova: mecanismos de execução em nível de código são muito mais fáceis de acumular e transferir entre modelos do que ajustes de prompt.
700 Iterações Automatizadas, Encontrando 20 Melhorias que 20 Anos de Experiência Não Viram
O projeto AutoResearch de Karpathy tomou um caminho diferente — não otimizar o Harness em si, mas submeter o agente a um loop de “propor mudança → rodar experimento → avaliar automaticamente → manter a melhoria”. Ele deixou seu próprio modelo ajustado à mão — construído com 20 anos de experiência — rodando por dois dias inteiros enquanto o agente executava autonomamente 700 experimentos, encontrando 20 melhorias de código que até ele havia deixado passar — incluindo um multiplicador escalar ausente no mecanismo de atenção que fazia a atenção se dispersar demais entre as múltiplas cabeças. O tipo de otimização minuciosa e de granularidade fina que exaure os humanos após uma dúzia de rodadas — o agente nunca se cansa de fazer.
O CEO da Shopify, Tobi Lutke, testou o método durante a noite com um modelo interno e acordou para descobrir que a qualidade melhorou 19% enquanto o tamanho do modelo otimizado foi reduzido pela metade. Pesquisadores então propuseram a “autopesquisa bilevel”: um loop interno otimizando o modelo, um loop externo otimizando a lógica de busca do loop interno. Usando o mesmo modelo base, o desempenho melhorou 5× em relação ao benchmark de Karpathy — inteiramente a partir de melhorias arquiteturais, não de ganhos na capacidade do modelo.
O “Sistema Operacional” Ignorado: uma Estrutura de Três Camadas para a Capacidade dos Agentes
Ambos os experimentos apontam para o mesmo ponto cego estrutural. Os dados de Niklaus nos dizem: os benchmarks nunca medem o modelo puro — eles medem “modelo mais Harness” como um sistema combinado. Quando você não consegue nem verificar se sua ferramenta de teste tem bugs, você nunca consegue determinar se o gargalo de desempenho é o modelo ou o código wrapper com bugs ao redor dele. Se um agente é um computador, o estado atual da indústria é: todo mundo discute se a CPU deve ser Intel ou AMD, e ninguém percebe que o computador não tem sistema operacional instalado.
O ex-engenheiro da Lightning AI, Akshay, ofereceu uma analogia precisa: um LLM puro é uma CPU sem memória ou disco rígido. O Harness é o sistema operacional que gerencia memória, I/O e drivers. Um Harness de nível de produção contém pelo menos 12 componentes essenciais: orquestração, invocação de ferramentas, armazenamento em camadas, gerenciamento de contexto, tratamento de erros… nenhum deles sexy individualmente, mas qualquer falha única zera a pontuação do modelo mais forte. Um exemplo concreto: quando um modelo coloca informações críticas no meio da sua janela de contexto, o desempenho cai mais de 30%. Harnesses maduros já dispõem de métodos de engenharia completos para esse “context rot” — compressão do histórico, mascaramento de saídas obsoletas, sumarização dinâmica — cuja essência é o máximo de resultado com o mínimo de tokens de alta densidade.
Essas tarefas de engenharia não têm nada a ver com “capacidade do modelo” — e ainda assim determinam quanta dessa capacidade se concretiza. Isso nos leva a uma estrutura de três camadas para a capacidade dos agentes: Camada um, a camada do Modelo: escala de parâmetros, arquitetura, dados de treinamento — o tema que a mídia adora e a indústria adora discutir. Mas os experimentos de Karpathy e Niklaus mostram em conjunto que os retornos marginais dessa camada estão diminuindo. Camada dois, a camada do Harness: todo o sistema de engenharia além do modelo — manipulação de arquivos, gerenciamento de contexto, orquestração de chamadas de ferramentas, recuperação de erros. É aqui que se encontra o verdadeiro gargalo da maioria das equipes de agentes. O experimento de Niklaus deixou claro: mesmo modelo, Harness certo, diferença de 76 pontos. Camada três, a camada do Loop: o mecanismo para os agentes se autoaperfeiçoarem continuamente. Os 700 experimentos de Karpathy provam que o verdadeiro valor da IA não é responder corretamente uma vez, mas convergir para soluções ótimas por meio de tentativa e erro de baixo custo. Mas essa camada requer três essenciais para funcionar: um verificador confiável, arquivos de estado persistentes e condições de parada claras.
A maioria das equipes está presa na camada dois enquanto pensa que é um problema da camada um — então trocam de modelo e compram GPUs rodada após rodada, e ninguém verifica se o “wrapper” do modelo consegue sequer salvar um arquivo no lugar certo. A correção não é cara: audite seu Harness contra os 12 componentes essenciais, execute as verificações de validação de I/O, meça sua taxa de context rot e só então decida se o modelo em si é o gargalo. Na maioria dos casos, não será.
A implicação para a indústria é clara: as equipes que vencerão em 2026 não serão as que tiverem os melhores modelos, mas as que tiverem os melhores wrappers ao redor dos mesmos modelos. O modelo open-source de Niklaus igualando um líder closed-source por um sétimo do custo não é uma anomalia — é uma prévia do que acontece quando a disciplina de engenharia alcança a capacidade dos modelos. A lacuna entre o que os modelos conseguem fazer e o que os agentes realmente entregam é o maior ganho de eficiência não colhido da indústria, e ele vive inteiramente na camada dois.
