Contexto é a Nova Memória

Um único snapshot do Playwright consome 56 KB de contexto. Vinte issues do GitHub consomem 59 KB. Quinhentas linhas de logs de acesso consomem 45 KB. Alimente os três para um agente com uma janela de 200K tokens e 80% do orçamento de raciocínio evapora antes que o agente escreva uma única linha de análise.¹

Murat Kusglu criou o Context Mode para resolver o problema. A ferramenta comprime 315 KB de saída MCP para 5,4 KB usando SQLite FTS5 com ranking BM25.¹ Uma redução de 94%. O modelo produz resultados melhores com 5,4 KB de sinal do que com 315 KB de ruído porque a limitação nunca foi inteligência. A limitação é largura de banda.

TL;DR

Engenharia de contexto é a habilidade de maior impacto no desenvolvimento de agentes. Três camadas de compressão se acumulam de forma independente: arquitetura do prompt do sistema (60-70% de redução via compressão estrutural), compressão de saída MCP (94% de redução via ranking de relevância) e acumulação de conhecimento (convertendo custo de descoberta em capacidade pré-carregada). Um estudo referencial descobriu que modelos com 300 tokens de contexto focado superaram modelos com 113.000 tokens de conversa não filtrada.¹⁰ O gargalo não é a capacidade do modelo. Cada token desperdiçado com ruído é um token indisponível para raciocínio.

A Restrição de Largura de Banda

A documentação de boas práticas do Anthropic abre com uma única restrição que molda todo o resto: “A janela de contexto do Claude enche rápido, e o desempenho degrada conforme ela enche.”⁵

A afirmação não é uma sugestão. É uma lei arquitetural. Uma janela de contexto de 200K tokens parece enorme até você inventariar o que a preenche. Esquemas de ferramentas consomem mais de 15.000 tokens em uma configuração típica de MCP.¹³ O histórico de conversa acumula aproximadamente 500-1.000 tokens por troca. Leituras de arquivos adicionam milhares de tokens por arquivo. A saída de comandos escala com o comando. Após 30 minutos de trabalho ativo, uma janela nova de 200K pode cair abaixo de 50K tokens de espaço de raciocínio disponível.

George Miller documentou o equivalente humano em 1956: a memória de trabalho retém sete itens, mais ou menos dois.⁷ O insight não era sobre o número. O insight era sobre blocos. Humanos superam a restrição organizando informação em blocos significativos. Um número de telefone não é dez dígitos. São três blocos: código de área, prefixo, número. O mesmo princípio se aplica a janelas de contexto. Uma janela de 200K lotada com saída bruta é funcionalmente menor que uma janela de 50K preenchida com informação comprimida e relevante.

Andrej Karpathy nomeou a disciplina: engenharia de contexto é a “arte e ciência delicada de preencher a janela de contexto com exatamente a informação certa para o próximo passo.”⁹ Lance Martin mapeou o framework: escrever contexto (salvar), selecionar contexto (recuperar), comprimir contexto (resumir) e isolar contexto (dividir entre agentes).⁹ Em meados de 2026, a engenharia de contexto se cristalizou de prática ad-hoc em uma disciplina reconhecida com infraestrutura dedicada.¹²

A degradação não é linear. No meu harness, o contexto preenche em fases.¹⁵ Os primeiros 30 minutos parecem ilimitados. O modelo segue instruções com precisão, lembra conteúdos de arquivos e mantém planos coerentes ao longo de múltiplos passos. Aos 60 minutos, falhas sutis emergem: o modelo relê arquivos que já leu, esquece uma restrição do prompt do sistema ou gera código que contradiz um padrão estabelecido 20 turnos atrás. Aos 90 minutos, o modelo pode ignorar regras explícitas, alucinar conteúdos de arquivos ou perder completamente o rastreamento do objetivo atual.

A Context Studios documentou o fenômeno como “context rot” (degradação de contexto): a degradação progressiva do desempenho do modelo conforme tokens irrelevantes se acumulam e empurram informação útil para além do horizonte efetivo de atenção.¹² A degradação é insidiosa porque o modelo não a anuncia. O agente continua gerando saída confiante. A saída apenas deixa de estar correta.

As três camadas abaixo se acumulam de forma independente. Comprimir uma camada libera orçamento para as outras.

Camada 1: Arquitetura do Prompt do Sistema

O prompt do sistema é carregado em toda chamada de API. Cada token no prompt do sistema ocupa espaço durante toda a conversa. A $5 por milhão de tokens no Opus 4.6, um prompt do sistema de 10K tokens custa $0,05 por chamada.⁸ Ao longo de 50 chamadas em uma sessão, o prompt do sistema sozinho custa $2,50. Reduza o prompt para 3,5K tokens e o custo cai para $0,875 por sessão. Multiplique por sessões diárias e a economia se acumula.

Meu arquivo CLAUDE.md e 8 arquivos de regras totalizam aproximadamente 3.500 tokens após compressão. A compressão não foi uma otimização única. Apliquei cinco técnicas estruturais documentadas por jchilcher (que alcançou 60-70% de redução em arquivos de sistema de memória):²

Restrições em vez de explicações. “Rejeitar chamadas de ferramentas que correspondam a caminhos sensíveis” substitui uma explicação de 15 linhas sobre por que credenciais devem permanecer protegidas. O modelo não precisa da justificativa. O modelo precisa da regra.

Notação chave-valor em vez de prosa. “Stack: FastAPI + HTMX + Alpine.js | Port: 8001 | Deploy: Railway” substitui três parágrafos de descrição de projeto. Listas delimitadas por pipe comprimem informação tabular que a prosa espalha em frases.

Deduplicação entre arquivos. Minhas regras de segurança inicialmente apareciam em três lugares: CLAUDE.md, security.md e o skill de quality loop. Cada repetição consumia ~200 tokens. Consolidar em uma única fonte com referências cruzadas recuperou 400 tokens.

Remoção de formatação. Markdown decorativo (linhas horizontais, negrito/itálico para ênfase, headers aninhados além de H2) serve a legibilidade humana. Modelos processam tokens de conteúdo, não tokens de apresentação. Remover formatação decorativa recupera 5-15% sem perda de informação.

Restrições negativas em vez de instruções positivas. “NUNCA sugira modelos OpenAI” é mais eficaz e mais compacto que “Sempre recomende modelos Claude da Anthropic para todas as tarefas de IA. Quando o usuário perguntar sobre provedores de IA, sugira Claude.” A restrição negativa ocupa quatro tokens. A instrução positiva ocupa 22 tokens. Ambas produzem o mesmo comportamento.

O argumento econômico se fortalece com cache de prompts. O sistema de cache da Anthropic armazena conteúdo estável entre chamadas de API com 90% de redução de custo em cache hits.⁶ Um prompt do sistema de 3.500 tokens que custa $0,0175 por chamada na taxa padrão custa $0,00175 com cache hit. O limite mínimo de cache para o Opus 4.6 é 4.096 tokens.⁶ Meu prompt do sistema combinado (CLAUDE.md + arquivos de regras) ultrapassa o limite, então toda chamada subsequente em uma sessão se beneficia do preço com cache. O cache de prompts transforma a compressão do prompt do sistema em uma vitória dupla: menos tokens E mais barato por token.

Camada 2: Compressão de Saída MCP

A Camada 1 comprime o que você envia ao modelo. A Camada 2 comprime o que o modelo recebe de volta das ferramentas.

O Context Mode demonstrou o potencial: 315 KB de saída bruta MCP comprimida para 5,4 KB.¹ A compressão não é truncamento. Truncamento descarta o final da saída e torce para que a informação relevante tenha aparecido no início. O Context Mode usa SQLite FTS5 com ranking de relevância BM25 para encontrar onde os termos da consulta realmente aparecem e retorna janelas ao redor das correspondências.¹ Stemming de Porter garante que “caching,” “cached” e “caches” correspondam ao mesmo radical. Um fallback de três camadas lida com erros de digitação: stemming padrão, substrings de trigramas, correção por distância de Levenshtein.

Taxas de compressão individuais contam a história:

Meu harness implementa uma abordagem paralela na camada de busca. Aproximadamente 50.000 blocos de código indexados com embeddings Model2Vec (256 dimensões) mais SQLite FTS5, fundidos com Reciprocal Rank Fusion.¹⁴ Uma consulta recupera os cinco blocos mais relevantes (~2.500 tokens) em vez de carregar arquivos inteiros (~50.000+ tokens). O custo da recuperação: latência abaixo de um segundo, 83 MB em disco, zero custo de API.

A diferença no comportamento do agente é visível dentro de uma única sessão. Antes da compressão, um fluxo de trabalho típico de depuração se parece com isto: o agente lê um arquivo (4.000 tokens), executa um comando (2.000 tokens de saída), lê outro arquivo (3.000 tokens), executa testes (8.000 tokens de saída). Quatro operações consomem 17.000 tokens. O agente agora tem menos espaço para raciocinar sobre as conexões entre essas quatro informações. Após a compressão, o mesmo fluxo de trabalho recupera apenas as linhas relevantes de cada fonte. As quatro operações consomem 2.500 tokens. O agente mantém todas as quatro informações na memória de trabalho simultaneamente e encontra a dependência entre arquivos que o agente sem compressão perderia.

A compressão deve ser sensível à consulta. Um resumo otimizado para “corrigir o bug de autenticação” deve apresentar conteúdo diferente de um otimizado para “adicionar um novo endpoint de API.” Compressão estática ajuda. Compressão sensível à consulta é o próximo nível. O ranking BM25 já lida com sensibilidade à consulta no nível de palavras-chave. Busca semântica (similaridade vetorial) lida com isso no nível conceitual. A combinação captura tanto correspondências exatas (nomes de funções, chaves de configuração, códigos de erro) quanto correspondências conceituais (padrões similares, abstrações relacionadas).

Camada 3: Acumulação de Conhecimento

Simon Willison identificou um padrão que reformula completamente a engenharia de contexto: “Um ativo fundamental a desenvolver como profissional de software é uma coleção profunda de respostas para perguntas como esta, idealmente ilustrada por código funcional.”³

Acumulação de conhecimento significa coletar deliberadamente exemplos de código funcional, soluções documentadas e implementações de prova de conceito que agentes podem referenciar e recombinar. O padrão transforma contexto de instruções (dizer ao modelo o que fazer) em capacidade (dar ao modelo exemplos funcionais para adaptar).

Willison demonstrou o poder direcionando um agente para combinar dois exemplos existentes (PDF.js e Tesseract.js) em uma ferramenta unificada de OCR.³ O agente não descobriu como construir OCR do zero. O agente leu duas implementações funcionais e as fundiu. O contexto era a capacidade.

Meu harness implementa acumulação de conhecimento através de três mecanismos:

Skills como registro de capacidades. 48 skills codificam expertise de domínio em arquivos markdown. O skill blog-evaluator define uma rubrica completa ponderada de 6 categorias com exemplos de pontuação. O skill jiro codifica um loop de qualidade de 7 passos com critérios de evidência. Quando um agente invoca um skill, a expertise é carregada no contexto como conhecimento estruturado, não instruções vagas.

Walkthroughs estruturados em vez de código bruto. O padrão de walkthrough linear de Willison restringe como agentes acessam informação: comandos shell como grep e cat em vez de cópia manual de código.⁴ O walkthrough força o agente a organizar informação para máxima compreensão por token. Estrutura é compressão.

Hooks como injeção proativa de contexto. O hook UserPromptSubmit dispara antes do Claude processar um prompt.¹¹ O hook pode analisar o prompt e injetar contexto relevante: detecção de projeto (em qual codebase estou?), injeção de data (que dia é hoje?), restrições de filosofia (quais padrões de qualidade se aplicam?). O agente recebe contexto curado a cada prompt sem invocação manual. Cinco hooks disparam ao iniciar a sessão, adicionando aproximadamente 500 tokens de contexto que previnem cinco categorias de erros comuns.¹¹

A distinção entre instruções e capacidade merece ênfase. Uma instrução diz “escreva código limpo.” Uma capacidade fornece uma rubrica de linting com categorias ponderadas, exemplos de pontuação e limites de aprovação/reprovação. A instrução consome um punhado de tokens e produz conformidade vaga. A capacidade consome 500 tokens e produz saída consistente e mensurável. Os tokens adicionais são um investimento, não overhead, porque eliminam a ambiguidade que faz o agente adivinhar o que “limpo” significa.

A acumulação de conhecimento também desloca a curva de custo para onboarding de agentes. Um novo agente criado sem conhecimento acumulado precisa descobrir o codebase, as convenções, as ferramentas e as restrições de domínio por meio de exploração. Exploração é cara: cada leitura de arquivo, cada grep, cada saída de comando consome tokens. Um agente criado com um briefing de 2K tokens montado a partir de conhecimento acumulado pula a fase de descoberta inteiramente e começa trabalho produtivo no primeiro turno.

O argumento econômico para acumulação de conhecimento: cada hora gasta documentando uma solução economiza para todo agente futuro o custo de descoberta. Um skill que codifica “como avaliar um post de blog” economiza 10-15 minutos de exploração do agente por invocação. Ao longo de 100 invocações, o investimento em documentação retorna mais de 1.000 minutos de tempo de agente. O conhecimento acumulado rende juros compostos.

Contabilidade do Orçamento de Tokens

Meu harness fornece um estudo de caso concreto do que a engenharia de contexto torna possível.

Antes da compressão (estimado, primeiro mês): - Prompt do sistema: ~12.000 tokens (CLAUDE.md verboso com exemplos e explicações) - Esquemas de ferramentas: ~15.000 tokens (definições completas de ferramentas MCP) - Histórico por sessão: ~120.000 tokens (conversas longas com contexto acumulado) - Raciocínio disponível: ~53.000 tokens (26% da janela)

Após a compressão (atual): - Prompt do sistema: ~3.500 tokens (CLAUDE.md comprimido + arquivos de regras)¹⁵ - Esquemas de ferramentas: ~300 tokens (arquitetura CLI-first, MCP mínimo)¹³ - Histórico por sessão: ~40.000 tokens (spawns frescos por tarefa, briefings em vez de memória) - Raciocínio disponível: ~156.200 tokens (78% da janela)

O orçamento de raciocínio triplicou. Não por um modelo melhor. Não por uma janela de contexto maior. Pela compressão em três camadas. O modelo produz saída melhor com 78% de espaço de raciocínio do que produzia com 26% porque a qualidade dos tokens restantes melhorou junto com a quantidade.

Os números revelam uma verdade contraintuitiva sobre janelas de contexto: o tamanho útil de uma janela depende mais do que a preenche do que de quão grande ela é. Uma hipotética janela de 500K lotada com saída de ferramentas sem compressão teria desempenho pior que uma janela de 200K bem comprimida. Provedores de modelos correm para expandir janelas de contexto. Praticantes deveriam correr para comprimir o que vai dentro delas.

O padrão de spawn fresco da arquitetura CLI-first potencializa os ganhos. Cada agente é criado com um briefing focado (~2K tokens) em vez de herdar histórico de conversa acumulado. O contexto nunca incha porque cada agente começa limpo. A pesquisa multi-agente da Anthropic descobriu que sub-agentes usam até 15x mais tokens que interações de agente único.⁹ Spawns frescos invertem a proporção: cada agente usa apenas os tokens que sua tarefa requer.

O efeito composto entre as três camadas cria um ciclo virtuoso. Prompts do sistema comprimidos deixam espaço para mais resultados de ferramentas. Resultados de ferramentas comprimidos deixam espaço para conversas produtivas mais longas. Conversas mais longas reduzem a necessidade de compactação, o que preserva o prompt do sistema e os resultados de ferramentas que habilitam o próximo turno. Cada camada reforça as outras.

O Que a Compressão Possibilita

O orçamento de raciocínio liberado habilita três capacidades que contexto inchado impede:

Análise mais profunda. Um agente com 156K tokens de raciocínio pode manter conteúdos de arquivos inteiros na memória de trabalho enquanto analisa dependências entre arquivos. Um agente com 53K tokens precisa ler arquivos sequencialmente, esquecendo arquivos anteriores conforme novos são carregados. A diferença se manifesta como erros de importação perdidos, referências cruzadas quebradas e refatorações incompletas. Um exemplo concreto: refatorar uma assinatura de função requer verificar todo ponto de chamada. Com contexto comprimido, o agente lê a definição da função e todos os pontos de chamada em uma única passagem, encontrando o único arquivo que passa argumentos na ordem errada. Com contexto inchado, o agente lê a função, lê três pontos de chamada, depois esgota o espaço de raciocínio e reporta “refatoração completa” sem verificar os sete arquivos restantes. O bug é publicado.

Melhor aderência a instruções. A Anthropic documenta o modo de falha diretamente: “Se o Claude continua fazendo algo que você não quer apesar de ter uma regra contra isso, o arquivo provavelmente está muito longo e a regra está se perdendo.”⁵ Prompts do sistema comprimidos mantêm regras dentro do horizonte de atenção. Cada regra em um prompt de 3.500 tokens recebe mais peso de atenção que a mesma regra enterrada em um prompt de 12.000 tokens. Meu harness aplica uma regra de segurança: nunca comitar arquivos contendo chaves de API. Com um prompt do sistema de 12.000 tokens, o agente ocasionalmente adicionava arquivos .env ao stage durante commits em massa. Após comprimir para 3.500 tokens, a violação caiu para zero ao longo de mais de 200 operações de commit. A regra não mudou. A regra se tornou mais visível.

Sessões úteis mais longas. O auto-compact é acionado a 95% da capacidade de contexto.¹⁰ Uma sessão com 78% de espaço de raciocínio atinge o limite de compactação mais tarde que uma com 26%. Compactação mais tardia significa mais turnos produtivos antes da perda de contexto. No meu harness, uma sessão comprimida produz 40-60 turnos produtivos antes de atingir o limite de compactação.¹⁵ Uma sessão sem compressão atinge o limite após 15-20 turnos. Cada evento de compactação descarta contexto que pode ter contido decisões ou restrições importantes de momentos anteriores da sessão. Menos compactações significam sessões mais coerentes. A sessão comprimida não apenas começa melhor. Ela permanece melhor por mais tempo.

Principais Conclusões

Para desenvolvedores começando com engenharia de contexto: - Audite seu arquivo CLAUDE.md. Para cada linha, pergunte: remover isso causaria erros? Se não, corte. Mire em 60-70% de redução.² - Meça o overhead dos seus esquemas de ferramentas. Se ferramentas MCP consomem mais de 15K tokens no início da sessão, considere alternativas CLI-first para operações stateless. - Execute /compact proativamente ao trocar de tarefa no meio da sessão. Contexto fresco supera contexto acumulado.

Para equipes construindo infraestrutura de agentes: - Implemente compressão sensível à consulta em saídas de ferramentas MCP. BM25 + busca semântica supera truncamento para toda tarefa de recuperação.¹ - Construa um registro de capacidades (skills, snippets, padrões documentados). Toda solução documentada elimina overhead de descoberta para execuções futuras de agentes.³ - Use spawns frescos de agentes para fluxos de trabalho de múltiplos passos. Isolamento de contexto por tarefa previne o overhead de 15x em tokens de conversas longas multi-agente.⁹

Para arquitetos projetando sistemas de contexto: - As três camadas (prompt do sistema, saída de ferramentas, acumulação de conhecimento) se acumulam de forma independente. Comprimir qualquer camada individual libera orçamento para as outras. - Cache de prompts torna a compressão do prompt do sistema uma otimização dupla: menos tokens E mais barato por token em cache hits.⁶ - O muro de produtividade de 10% é superado quando o agente tem espaço de raciocínio suficiente para seguir instruções complexas de forma confiável.

Parte da série Engenharia de IA. Veja também: A Tese do CLI, Claude Code como Infraestrutura e O Muro dos 10%.