O seu agente de IA esquece tudo: os truques de MCP que resolvem o inchaço do contexto

O problema que ninguém anuncia

Toda demo de um agente de programação com IA mostra a mesma coisa: um terminal limpo, uma instrução clara e um resultado organizado. Ninguém lhe mostra a terceira hora, quando o agente já leu quarenta arquivos, rodou uma dúzia de suítes de teste e encheu o seu context window com a saída ruidosa de cada comando que já executou. Nesse ponto o agente não fica mais inteligente. Fica mais burro, esquecido e propenso a repetir com confiança um trabalho que já terminou.

Este é o problema menos glamouroso e mais universal da programação agêntica. O contexto é a memória de trabalho do agente, e é finita. Tudo o que o agente lê disputa o mesmo espaço, e a maior parte do que ele lê é lixo: logs de build, stack traces, listagens de diretórios, o texto completo de arquivos dos quais só precisava de uma linha. A janela se enche de sedimento, e o raciocínio que tornava o agente útil desde o início vai sendo espremido para fora.

As ferramentas que resolvem isso não são as que vencem comparações de benchmark. São encanamento. E em outubro, foi o encanamento que subiu na lista de tendências do GitHub.

A ideia por trás do sandboxing de saídas de ferramentas

Um dos projetos mais interessantes a surgir é uma camada de otimização de contexto para agentes de programação, que ataca o problema na origem. O seu número de destaque é uma redução de cerca de 98 por cento no volume de saída de ferramentas que chega ao modelo.

O mecanismo é simples em conceito. Em vez de deixar a saída bruta de um comando escorrer direto para a conversa, você o executa num sandbox e entrega ao modelo apenas o que ele precisa do resultado: um resumo, um status de saída, as linhas específicas que corresponderam a uma consulta. A transcrição completa continua disponível para o modelo buscar de propósito, mas não fica ocupando a janela por acaso de ser relevante.

É a mesma disciplina que um bom engenheiro aplica por hábito. Você não cola um log inteiro num chat quando uma única linha de erro é o ponto. Os agentes, deixados à própria sorte, fazem exatamente o contrário.

Vem uma conta junto com isso, e é por isso que o tooling não é apenas uma gentileza de engenharia. Um context window não é de graça. Cada token que o modelo precisa processar custa dinheiro e tempo, e cada token que ele precisa lembrar custa atenção. Uma ferramenta que despeja cem mil tokens de saída de build numa sessão cobra de você duas vezes: uma pelos tokens e outra pela degradação do julgamento do modelo quando o sinal fica soterrado. Essa redução de 98 por cento é, na verdade, uma correção de qualidade disfarçada de economia.

Uma memória que sobrevive à sessão

A outra metade do problema é que os agentes esquecem entre sessões, não apenas dentro delas. Feche o terminal e o contexto se vai. Reabra amanhã e o agente não faz ideia do que você decidiu, de qual abordagem rejeitou ou por que o código está do jeito que está. Você explica de novo, o agente deduz de novo, e em algum lugar uma decisão é tomada duas vezes.

As ferramentas de memória persistente nesse campo adotam abordagens diferentes. Uma das mais visíveis captura o que o agente faz durante uma sessão, comprime com um modelo e injeta as partes relevantes nas sessões futuras. O discurso é pouco glamouroso e correto: um agente que lembra a forma do seu projeto vale mais do que um agente marginalmente mais inteligente numa única tarefa. Os principais fornecedores de modelos seguiram na mesma direção, adicionando controles que permitem a um subagent comprimir o próprio context antes da conversa pai, justamente para não carregar o histórico da sessão inteira para uma tarefa que não precisa de nada disso.

A pergunta de design interessante aqui é o que lembrar. Lembre tudo e você reconstruiu o problema original numa forma mais lenta. Lembre pouco demais e a memória é inútil. Os projetos que estão ganhando tração são os que lembram de forma seletiva, na teoria de que um bom resumo do último mês supera um registro perfeito da última hora.

O routing como estratégia de contexto

A terceira peça do quebra-cabeça é o routing: decidir, antes de uma tarefa rodar, qual modelo e quais ferramentas ela precisa, para que não seja carregada com capacidades que nunca vai usar. Um modelo que foi informado de dezessete integrações diferentes gasta contexto nas dezessete mesmo que a tarefa precise de uma só. Impor o routing em todas as plataformas soa como um detalhe de infraestrutura. Na verdade é uma decisão de orçamento de contexto disfarçada.

É aqui que o problema deixa de parecer um problema de cache e começa a parecer design de sistemas. O context window do agente é um recurso, do mesmo modo que memória e disco são recursos, e as ferramentas que o tratam assim são as que mantêm os agentes coerentes em trabalhos longos. Não é acaso que os projetos de sandboxing, memória e routing estejam convergindo: são três visões da mesma escassez.

O padrão do subagent é o exemplo mais claro. Quando um agente gera um ajudante para um trabalho estreito, esse ajudante não precisa herdar a conversa inteira. Entregar a ele um contexto limpo com apenas a tarefa em mãos é mais barato e mais preciso, e é por isso que os harnesses mais novos deixam um subagent comprimir o próprio context antes do pai. O pai mantém o histórico longo; o filho ganha uma mesa nova. As equipes que rodaram agentes em refatorações de uma semana costumam chegar a essa regra sozinhas, geralmente depois de ver um subagent gastar a janela inteira relendo uma conversa que não precisava.

Por que isso está chegando agora

Nenhum desses problemas é novo. Os agentes perdem contexto desde o primeiro que rodou. O que mudou é que agora se espera que os agentes rodem por horas, ao longo de muitas sessões, em trabalho que importa. Um brinquedo não perde nada quando esquece. Uma ferramenta da qual uma equipe depende para uma refatoração de uma semana perde muita coisa.

O mercado percebeu. Dois anos atrás, "nosso agente tem uma janela de contexto de 200k" era um argumento de venda. Agora a pergunta útil é qual fração dessa janela é gasta em sinal. Os fornecedores que entendem isso estão lançando controles de compactação e isolamento de contexto de subagents. A comunidade está lançando o encanamento que torna o resto suportável.

A conclusão pouco glamourosa

Há a tentação de ler as notícias de agentes de outubro como uma história sobre modelos mais inteligentes e plugins mais engenhosos. A história mais silenciosa e mais duradoura é sobre higiene. Os agentes ficaram úteis o bastante para rodar por longos períodos, e longos períodos expõem cada fraqueza na forma como gerenciam a própria memória.

Os projetos que escalam as listas de tendências são os que aceitam uma verdade banal: o gargalo do trabalho autônomo raras vezes é inteligência bruta. É a capacidade de permanecer na tarefa sem se afogar nas próprias anotações. Conserte a memória, coloque o ruído num sandbox, encaminhe as capacidades, e um modelo meramente competente de repente parece excelente. Erre isso e até um modelo de fronteira vai passar a tarde relendo um arquivo de log que já leu cinco vezes.