A Crise do Contexto: Três Apostas Que Encolhem o Mundo do Agente Para Fazê-lo Funcionar

Setenta e dois por cento. Essa foi a fração de uma janela de contexto de 200.000 tokens que uma equipe de engenharia consumiu com definições de ferramentas antes de o agente processar uma única mensagem do usuário. 143.000 tokens gastos com o protocolo. 57.000 restantes para o trabalho real.

Sinalizamos esse padrão três semanas atrás. Em O Imposto Operacional, reportamos a descoberta de Kan Yilmaz de que o MCP despeja 15.540 tokens de schemas de ferramentas na janela de contexto ao iniciar uma sessão. O número já era preocupante. Os dados novos da Apideck tornam a situação pior: com 40 ferramentas MCP, o custo inicial ultrapassa 55.000 tokens. Escale para o catálogo completo e você está pagando aluguel de uma casa onde não consegue morar.

O que mudou entre fevereiro e agora não são apenas os números. Três equipes de engenharia independentes, trabalhando em problemas não relacionados, chegaram à mesma conclusão arquitetural. As soluções parecem diferentes na superfície. Por baixo, compartilham um princípio que reescreve como devemos pensar design de agentes.

Os Números da Apideck

Samir Amzani, da Apideck, executou um benchmark sistemático comparando chamadas de ferramentas MCP com equivalentes em CLI. Os resultados são contundentes.

Uma tarefa simples (listar repositórios do GitHub) custou 44.026 tokens via MCP. A mesma tarefa via CLI: 1.365 tokens. Um multiplicador de 32x. Para uma tarefa moderadamente complexa, a proporção caiu para 4x, mas o custo absoluto do MCP permaneceu alto.

O desperdício de tokens é só metade da história. O servidor GitHub Copilot do MCP apresentou 28% de taxa de falha no benchmark da Scalekit. Quase uma em cada três chamadas falhou. O protocolo que deveria padronizar a interação com ferramentas é ao mesmo tempo caro e pouco confiável em escala.

A alternativa proposta por Amzani: substituir catálogos de ferramentas MCP por comandos CLI que usam revelação progressiva. Em vez de carregar 55.000 tokens de schema de uma vez, o agente carrega um único ponto de entrada CLI a aproximadamente 80 tokens. Descobre subcomandos sob demanda, pagando 50 a 200 tokens por etapa de descoberta. O orçamento de contexto inverte de pré-carregado para pague-conforme-usar.

Existe uma dimensão de governança aqui que MCP Morreu; Vida Longa ao MCP explorou: a aplicação de permissões em CLI vive no código binário, não em guardrails baseados em prompt. Um CLI aceita o comando ou rejeita. Não há ambiguidade para o modelo explorar, nenhum vetor de injeção de prompt na descrição da ferramenta. A fronteira de segurança é estrutural.

A Aposta do Manus

Um líder de backend do Manus, a empresa de agentes de IA, publicou uma confissão direta este mês: a equipe parou de usar function calling por completo. Nenhum catálogo tipado de ferramentas. Nenhuma definição de schema. Uma ferramenta. Um único comando “run” que aceita comandos no estilo Unix.

Este é o extremo radical do espectro. Onde a Apideck reduz a superfície de ferramentas de 40 para um CLI com revelação progressiva, o Manus reduz para uma ferramenta. O agente compõe comportamento a partir de comandos pequenos e encadeáveis em vez de selecionar de um menu de funções predefinidas.

O raciocínio é prático, não ideológico. Catálogos grandes de ferramentas confundem agentes. Cada definição adicional de ferramenta é mais um ponto de decisão, mais uma fonte de parâmetros alucinados, mais uma oportunidade para o modelo escolher a ferramenta errada. Reduzir o catálogo a uma ferramenta elimina erros de seleção por completo. O agente não pode escolher a ferramenta errada quando só existe uma.

É a filosofia Unix aplicada à arquitetura de agentes: ferramentas pequenas, pipelines composíveis, texto como interface universal. Funcionou para sistemas operacionais nos anos 1970. Parece funcionar para agentes em 2026. A razão subjacente é a mesma. Composabilidade escala melhor que enumeração.

A contrapartida é real. Uma interface de comando único sacrifica a validação estruturada que schemas tipados fornecem. O agente precisa construir strings de comando corretas a partir dos dados de treinamento em vez de preencher campos tipados. Para equipes com infraestrutura sólida de testes, essa troca compensa. Para equipes sem ela, a camada de validação ausente vai se manifestar como falhas em produção.

O Sinal do CursorBench

O problema de avaliação do Cursor parece não ter relação com janelas de contexto. Tem.

Naman Jain publicou o CursorBench este mês, explicando por que o Cursor construiu um sistema proprietário de avaliação em vez de depender de benchmarks públicos. A descoberta central: benchmarks públicos estão contaminados. A OpenAI identificou que quase 60% dos problemas não resolvidos em benchmarks tinham testes com defeito. Os próprios testes estavam errados.

Quando seus testes de avaliação estão errados, sua seleção de modelos opera sem governança. Você está escolhendo modelos com base em pontuações que medem a coisa errada. Esse eco é o que documentamos em Metade dos Seus Benchmarks Estão Errados: a infraestrutura de verificação vira um passivo quando não pode ser confiável.

O CursorBench resolve isso com o que Jain chama de “Cursor Blame”, uma integração que extrai tarefas de avaliação de sessões reais de edição no Cursor. Quando a sugestão de um modelo é rejeitada ou desfeita por um usuário, essa interação vira um caso de teste. Os dados de avaliação vêm do comportamento em produção, não de datasets estáticos que os modelos memorizaram.

A conexão com a arquitetura de contexto é indireta, mas importante. O CursorBench produz maior separação entre modelos na fronteira, exatamente onde benchmarks públicos estabilizam. Modelos que pontuam de forma idêntica no HumanEval ou SWE-bench mostram diferenças mensuráveis em tarefas do CursorBench. A razão: tarefas reais de codificação exigem que o modelo trabalhe dentro de restrições apertadas de contexto. Interpretar o arquivo relevante. Ignorar os irrelevantes. Produzir uma edição precisa sem reescrever a função inteira.

Os modelos que vencem no CursorBench são os que usam contexto com eficiência. Não os que consomem mais.

A Convergência

Três equipes. Três problemas diferentes. Um princípio.

A Apideck resolveu desperdício de tokens substituindo carregamento antecipado de schemas por revelação progressiva via CLI. O Manus resolveu confusão de ferramentas colapsando o catálogo inteiro para um único comando. O Cursor resolveu contaminação de benchmarks extraindo avaliações de sessões reais com restrições de contexto.

Cada solução encolhe o mundo do agente. Menos ferramentas carregadas ao mesmo tempo. Menos decisões a tomar. Restrições de contexto mais apertadas. O agente performa melhor não apesar da superfície menor, mas por causa dela.

Isso é contraintuitivo. O instinto natural em engenharia de plataforma é dar aos agentes mais: mais ferramentas, mais contexto, mais capacidade. A evidência das três equipes aponta na direção oposta. Agentes não são humanos que se beneficiam de ter a caixa de ferramentas completa ao alcance do braço. Agentes são sistemas estatísticos que degradam conforme o espaço de decisão se expande.

Cada token de definição de ferramenta competindo por espaço na janela de contexto é um token indisponível para raciocinar sobre a tarefa real. Cada ferramenta adicional no catálogo é mais uma ramificação na árvore de decisões que o modelo precisa percorrer. O custo não é apenas computacional. É cognitivo, no sentido de aprendizado de máquina. A atenção do modelo é um recurso finito, e definições de ferramentas a consomem.

O Que Isso Significa para a Arquitetura

As implicações práticas se dividem em três níveis.

Para desenvolvedores individuais: a abordagem CLI-first já é o padrão correto. Se você está rodando agentes contra codebases locais, pule o catálogo MCP. Use as ferramentas que seu agente já conhece dos dados de treinamento. Pague por contexto sob demanda, não antecipado.

Para equipes de plataforma: audite a superfície de ferramentas. A pergunta não é “que ferramentas o agente poderia usar?” mas “que ferramentas o agente precisa usar para esta tarefa específica?” Carregamento dinâmico de ferramentas, seja via Tool Search da Anthropic ou revelação progressiva CLI, deveria ser o padrão. Catálogos estáticos que despejam tudo no início da sessão são um cheiro de arquitetura.

Para organizações: eficiência de contexto está se tornando um proxy para qualidade de agentes. A descoberta do CursorBench é relevante aqui. Modelos que usam contexto bem superam modelos que o consomem indiscriminadamente. O mesmo princípio se aplica às arquiteturas que você constrói ao redor desses modelos. Um sistema de agentes que carrega 40 ferramentas para uma tarefa que precisa de três não é mais capaz. É mais confuso.

O ângulo de governança vale ser reafirmado. Como exploramos em Contexto É o Novo Perímetro, a janela de contexto é uma fronteira. O que entra nessa fronteira determina o que o agente pode fazer, o que ele sabe, e onde pode errar. Encolher a superfície de ferramentas não é só otimização. É uma decisão de segurança. Menos ferramentas significa menos vetores de ataque, menos gatilhos de alucinação, menos caminhos para comportamento não intencional.

A Pergunta Que Permanece

As três soluções descritas aqui otimizam para restrições diferentes e aceitam contrapartidas diferentes. A Apideck preserva descobribilidade enquanto reduz custo inicial. O Manus maximiza simplicidade ao custo de validação estruturada. O Cursor otimiza fidelidade de avaliação ancorando-a em dados de produção.

Nenhuma é universalmente correta. A abordagem certa depende da maturidade de testes da sua equipe, dos seus requisitos de governança, e de se você está construindo para desenvolvedores individuais ou para implantação organizacional. Essa distinção, como MCP Morreu; Vida Longa ao MCP argumentou, permanece a linha de fratura em todo debate sobre arquitetura de agentes.

O que as três compartilham é o reconhecimento de que mais não é melhor. O mundo do agente deve ser tão pequeno quanto a tarefa exige. Não menor. Não maior. No tamanho certo.

A janela de contexto não é armazenamento ilimitado. É um orçamento. Gaste-o com o trabalho.

Fontes

Amzani, Samir. “Your MCP Server Is Eating Your Context Window.” Apideck, março 2026.
Jain, Naman. “How We Compare Model Quality in Cursor.” Cursor, março 2026.
Equipe de engenharia do Manus. Insights sobre arquitetura de agentes, março 2026.

A Victorino projeta arquiteturas de agentes que maximizam capacidade enquanto minimizam desperdício de contexto — governança por restrição, não por prompts: contato@victorino.com.br | www.victorino.com.br