A janela de contexto do seu modelo cresceu para 200 mil tokens. Talvez um milhão. O instinto diz: joga tudo lá dentro. Documentação, histórico, todas as ferramentas, e deixa o modelo se virar.
Esse instinto falha com frequência. A evidência mostra que contexto a mais, sem curadoria, pode degradar o resultado em vez de melhorar. O trabalho real se chama context engineering.
Em 2026, o tema parece batido. O termo tem um ano e já rendeu uma pilha de artigos. Mesmo assim, este vale a leitura, e por três razões que o próprio texto desenvolve.
O problema segue aberto e segue sendo medido: em fevereiro de 2026, o benchmark LOCA-bench registrou de novo a degradação de agentes conforme o contexto cresce. A prática também segue mudando. Posts de engenharia da Anthropic de março e abril de 2026 trazem modos de falha e táticas novos: context anxiety, context resets, trimming. E esperar a próxima janela maior não encerra a discussão. O artigo que consolidou a disciplina avalia como provável que, no futuro previsível, janelas de qualquer tamanho sigam sujeitas a poluição de contexto. A ressalva é do próprio texto: ao menos onde se busca a performance mais forte de agentes.
Origem do termo
A popularização do termo cabe em uma semana de junho de 2025. As fontes desta seção são de 2025 por necessidade: elas documentam o nascimento do termo.
Em 19 de junho, Tobi Lütke, CEO da Shopify, publicou um tweet:
I really like the term “context engineering” over prompt engineering.
It describes the core skill better: the art of providing all the context for the task to be plausibly solvable by the LLM.
Em 23 de junho, Harrison Chase, da LangChain, publicou The rise of “context engineering”, com a definição operacional que vamos usar neste artigo.
Em 25 de junho, Andrej Karpathy amplificou o termo:
+1 for “context engineering” over “prompt engineering”.
People associate prompts with short task descriptions you’d give an LLM in your day-to-day use. When in every industrial-strength LLM app, context engineering is the delicate art and science of filling the context window with just the right information for the next step. […]
Em 27 de junho, Simon Willison registrou a adoção e avaliou que o termo “may have sticking power”.
Em 29 de setembro, a Anthropic publicou Effective context engineering for AI agents, que consolida a disciplina.
O que é context engineering
A definição de Chase:
Context engineering is building dynamic systems to provide the right information and tools in the right format such that the LLM can plausibly accomplish the task.
Três palavras carregam o peso:
- Sistema: o contexto vem de várias fontes. Desenvolvedor, usuário, interações anteriores, chamadas de ferramenta, dados externos.
- Dinâmico: partes do contexto chegam em tempo de execução. A montagem do prompt final precisa ser lógica de runtime, não texto estático.
- Plausível: o modelo não lê mentes.
Chase resume: na maior parte das vezes, quando um agente não performa de forma confiável, a causa é contexto, instruções ou ferramentas que não chegaram ao modelo.
A Anthropic posiciona a disciplina como a progressão natural do prompt engineering. Prompt engineering otimiza a escrita de instruções, em especial o system prompt. Context engineering administra o estado inteiro da janela a cada passo de inferência: instruções, ferramentas, dados externos, histórico de mensagens.
O princípio guia, nas palavras do artigo: encontrar o menor conjunto possível de tokens de alto sinal que maximiza a probabilidade do resultado desejado.
Prompt engineering pergunta “como escrevo a instrução?”. Context engineering pergunta “o que entra na janela neste passo, e o que fica de fora?”.
Por que jogar tudo no contexto falha
A raiz é arquitetural. Na atenção do transformer, o número de relações entre tokens cresce de forma quadrática com o tamanho do contexto. A Anthropic chama a consequência de orçamento de atenção (attention budget): cada token novo consome parte do orçamento. A ligação entre esse custo e a degradação observada é empírica, não uma consequência matemática automática.
E a degradação está medida. O Context Rot, relatório do time de pesquisa do Chroma, avaliou 18 modelos, incluindo GPT-4.1, Claude 4 e Gemini 2.5. O resultado central: a performance não é uniforme conforme o input cresce, mesmo em tarefas simples. Um único distrator (conteúdo parecido com a resposta, mas errado) já reduz a performance; quatro degradam mais. E no LongMemEval, com prompts de cerca de 113 mil tokens, os modelos vão bem quando recebem só o conteúdo relevante. Quando precisam achar o relevante no meio do irrelevante, a degradação é consistente.
O relatório é de julho de 2025, mas a linha de pesquisa continuou. Em fevereiro de 2026, o LOCA-bench levou a medição para agentes. Em vez de busca num trecho estático, o benchmark controla o estado do ambiente para regular o crescimento do contexto. Dois achados do abstract. A performance dos agentes em geral degrada conforme os estados ficam mais complexos. E técnicas de gerenciamento de contexto podem melhorar substancialmente a taxa de sucesso.
O fenômeno também aparece fora de benchmark. O relatório técnico do Gemini 2.5 descreve o agente que joga Pokémon, numa observação que o próprio texto qualifica como anedótica:
As the context grew significantly beyond 100k tokens, the agent showed a tendency toward favoring repeating actions from its vast history rather than synthesizing novel plans.
Bem acima de 100 mil tokens, o agente tende a repetir ações do próprio histórico em vez de sintetizar planos novos. Para modelos menores, o teto é mais baixo. Um estudo da Databricks mediu que a correção do Llama 3.1 405b começa a cair por volta de 32 mil tokens, e antes disso em modelos menores.
E não é só o tamanho: a forma de chegada do contexto também derruba a performance. Um time da Microsoft e da Salesforce fatiou prompts de benchmark em várias mensagens, simulando uma conversa em que os requisitos chegam aos poucos. Queda média de 39% no resultado. O o3 caiu de 98.1 para 64.1.
Os quatro modos de falha
Drew Breunig organizou essas falhas em uma taxonomia que vale memorizar, em How Long Contexts Fail. Tabela adaptada das definições dele:
| Falha | O que acontece | Evidência citada |
|---|---|---|
| Context Poisoning | Uma alucinação entra no contexto e passa a ser referenciada como fato | Gemini com goals envenenados persegue metas impossíveis no Pokémon |
| Context Distraction | O contexto fica tão longo que o modelo foca no histórico e ignora o que aprendeu no treinamento | Gemini bem acima de 100k tende a repetir ações; Llama 3.1 405b cai a partir de ~32k |
| Context Confusion | Conteúdo supérfluo no contexto influencia a resposta | Modelos chamam ferramentas irrelevantes mesmo quando nenhuma se aplica |
| Context Clash | Informações dentro do contexto conflitam entre si | Prompts fatiados: queda média de 39% |
A confusão com ferramentas merece um número próprio, porque atinge direto quem conecta MCPs a tudo. Breunig aponta dois padrões no Berkeley Function-Calling Leaderboard: todo modelo performa pior quando recebe mais de uma ferramenta, e todos os modelos ocasionalmente chamam ferramentas irrelevantes.
O estudo Less is More traz um exemplo medido. Uma variante quantizada do Llama 3.1 8b falha em uma query do benchmark GeoEngine com as 46 ferramentas do benchmark no prompt. Com o conjunto reduzido a 19, a query tem sucesso. O problema era confusão, não a janela.
As táticas
As táticas conhecidas respondem a quatro perguntas. Tabela adaptada de How to Fix Your Context (Breunig) e do artigo da Anthropic:
| Pergunta | Tática | Exemplo |
|---|---|---|
| O que entra? | RAG, tool loadout, retrieval just-in-time | Carregar só as ferramentas relevantes para a tarefa |
| O que sai? | Pruning, sumarização, compaction | Resumir a conversa perto do limite e recomeçar com o resumo |
| O que mora fora? | Offloading, notas estruturadas, filesystem | Agente escreve notas em arquivo e relê depois |
| O que se isola? | Quarentena de contexto, sub-agentes | Sub-agente pesquisa com janela própria e devolve só o resumo |
Cada linha tem evidência por trás, das mesmas fontes.
O que entra. O paper RAG-MCP aplicou RAG às descrições de ferramentas. Em vez de servir o catálogo inteiro ao modelo, o sistema recupera as candidatas por similaridade e injeta no prompt só o schema mais bem ranqueado. Resultado relatado: corte de mais de 50% nos tokens de prompt e acurácia de seleção mais que triplicada (43,13% contra 13,62% do baseline). A alternativa da Anthropic é o retrieval just-in-time: o agente mantém identificadores leves (caminhos de arquivo, queries, links) e carrega o dado na hora, via ferramenta. O Claude Code usa o modelo híbrido: arquivos CLAUDE.md entram direto no contexto, e primitivas como glob e grep buscam o resto sob demanda.
O que sai. Compaction costuma ser a primeira alavanca da Anthropic para tarefas longas: resumir a conversa perto do limite da janela e reiniciar com o resumo. No Claude Code, o resumo preserva decisões de arquitetura, bugs não resolvidos e detalhes de implementação, e descarta outputs redundantes de ferramentas. O risco, admitido no próprio artigo: compaction agressiva demais perde contexto sutil cuja importância só aparece depois.
A família cresceu em 2026. O post de abril sobre Managed Agents adiciona o context trimming: remoção seletiva de tokens que pararam de ajudar, como outputs antigos de ferramentas e blocos de thinking. E o post de março sobre harness design descreve a context anxiety. Alguns modelos começam a encerrar o trabalho cedo demais quando se aproximam do que acreditam ser o limite de contexto. A resposta é o context reset: limpar a janela por completo e iniciar um agente novo, com um handoff estruturado que carrega o estado e os próximos passos. Nos testes do time, o Claude Sonnet 4.5 exibia context anxiety forte o bastante para compaction sozinha não bastar, e o reset virou peça essencial do harness.
O que mora fora. Com o Claude Sonnet 4.5, a Anthropic lançou uma memory tool baseada em arquivos. Com ela, o agente guarda e consulta informação fora da janela, entre sessões. Breunig põe na mesma categoria a ferramenta “think” da Anthropic, um espaço para o modelo registrar raciocínio intermediário sem obter informação nova. Pareada com um prompt de domínio, rendeu 54% de melhora relativa no domínio de aviação do tau-bench (0.570 contra 0.370 do baseline). Uma nota de dezembro de 2025 na própria página atualiza o conselho. Com a evolução do extended thinking, a Anthropic recomenda esse recurso no lugar da ferramenta dedicada na maioria dos casos.
O que se isola. Na arquitetura de sub-agentes descrita pela Anthropic, cada sub-agente explora com a própria janela. Ele pode gastar dezenas de milhares de tokens, mas devolve ao agente principal um resumo destilado, muitas vezes entre 1.000 e 2.000 tokens. O detalhe da busca fica isolado no sub-agente; o principal só carrega a síntese.
Prompt ruim vs prompt bom
Um exemplo ilustrativo, montado com as táticas desta seção. Os números de tokens são inventados para dar escala, e não há teste comparativo aqui. A tarefa é um agente que corrige um bug.
O prompt ruim trata a janela como depósito:
[system] 12,000 tokens: every rule for every edge case, pasted upfront
[tools] 47 MCP tools registered, all of them
[docs] the entire API documentation: 40,000 tokens
[history] every message and raw tool output since turn 1
[task] "fix the timeout bug"Cada linha ilustra um risco discutido neste artigo. Dezenas de ferramentas registradas tendem a degradar a seleção; foi o padrão do caso GeoEngine, com 46. A documentação inteira e o histórico bruto consomem o orçamento de atenção e podem aumentar o risco de distração. E a tarefa vaga esbarra na definição de Chase: o modelo não lê mentes.
O prompt bom trata a janela como orçamento:
[system] 800 tokens: goals and heuristics for this domain, not every rule
[tools] the 5 tools this task can actually use
[docs] file paths and URLs only; content loaded on demand
[history] compacted summary; past errors kept visible
[task] "fix the 504 timeout in POST /orders; stack trace below"Mesma tarefa, mesmo modelo. O que mudou foi a curadoria: loadout reduzido, retrieval just-in-time, compaction com erros preservados e uma tarefa que o modelo consegue plausivelmente resolver.
As lições de produção da Manus
O relato mais concreto de context engineering em produção veio da Manus. Em julho de 2025, Yichao “Peak” Ji publicou Context Engineering for AI Agents: Lessons from Building Manus. E ele fala de dinheiro, assunto que os outros textos tratam pouco.
O ponto de partida é uma assimetria estrutural no loop de um agente:
turn 1: [system | tools | task] -> action 1
turn 2: [system | tools | task | action 1 | obs 1] -> action 2
turn 3: [system | tools | task | action 1 | obs 1 | ...] -> action 3
Input grows each turn. Output (usually a short
function call) stays relatively short.
Average input:output ratio in Manus: 100:1.Com essa proporção, o grosso do processamento está no input. A defesa é o KV-cache: prefixos idênticos de contexto não precisam ser reprocessados. Ji argumenta que, se tivesse que escolher uma única métrica, a taxa de acerto do KV-cache seria a mais importante de um agente em produção. No preço que ele cita para o Claude Sonnet, input com cache custa 0,30 USD por milhão de tokens; sem cache, 3 USD. Uma diferença de 10x.
Disso saem sete regras práticas que parecem detalhes e não são:
- Prefixo estável. Um timestamp com precisão de segundos no início do system prompt invalida o cache a cada chamada. Um token diferente invalida tudo dali em diante.
- Contexto append-only. Não edite ações ou observações passadas. E garanta serialização determinística: muitas linguagens não garantem ordem estável de chaves em JSON.
- Mascare ferramentas, não remova. Mexer nas definições no meio da tarefa invalida o cache. Pior: deixa o histórico referenciando ferramentas que não existem mais, o que confunde o modelo. A solução da Manus é uma máquina de estados que mascara os logits durante o decoding. Ela impede (ou força) a seleção de certas ações, sem mexer nas definições.
- Filesystem como contexto final. Ilimitado, persistente, operável pelo próprio agente. O conteúdo de uma página web pode sair do contexto desde que a URL fique: o agente relê quando precisar.
- Recitação. Uma tarefa típica da Manus leva em média cerca de 50 chamadas de ferramenta. Por isso o agente mantém um todo.md e o reescreve a cada passo, empurrando o objetivo global para o fim do contexto, dentro da atenção recente do modelo.
- Deixe os erros no contexto. Apagar uma ação que falhou remove a evidência. Com a falha e o stack trace visíveis, o modelo atualiza as crenças implícitas e reduz a chance de repetir o erro. Ji considera a recuperação de erros um dos indicadores mais claros de comportamento agêntico real.
- Cuidado com few-shot em agentes. O modelo imita o padrão do próprio contexto. Em tarefas repetitivas, o agente muitas vezes cai num ritmo, o que leva a deriva e, às vezes, alucinação. A correção da Manus: variação estruturada em templates de serialização e formatação, para quebrar o padrão.
Uma ressalva de fidelidade: são lições autorrelatadas de um time sobre o próprio produto, sem medição pública. O próprio Ji descreve o processo como ciência experimental. O framework do agente foi reconstruído quatro vezes, e ele apelida o método de “Stochastic Graduate Descent”. É o estado da prática de um time, não um manual fechado.
O que o context engineering não resolve
Os limites merecem o mesmo destaque das táticas.
Primeiro, os números deste artigo não são tetos universais. A tendência de repetição bem acima de 100 mil tokens é do Gemini 2.5 jogando Pokémon, e o próprio relatório a chama de anedótica. Os 32 mil são do Llama 3.1 405b em um benchmark da Databricks. O Chroma mostrou que a degradação existe em todos os 18 modelos testados, e também que ela não é uniforme. Não dá para transferir um limiar de um modelo ou tarefa para outro sem medir.
Segundo, as táticas têm custo próprio. Compaction pode descartar o detalhe que importava. Compressão irreversível carrega risco por definição, como o post da Manus argumenta. Sub-agentes multiplicam chamadas. E cada camada de gerenciamento de contexto é código que você mantém. A Anthropic voltou a esse limite no post sobre Managed Agents. Decisões irreversíveis de reter ou descartar contexto podem levar a falhas, porque é difícil saber quais tokens os próximos turnos vão precisar.
Por fim, a direção da sofisticação é a oposta: modelos mais capazes exigem menos engenharia prescritiva. O conselho final da Anthropic é fazer a coisa mais simples que funciona. Context engineering é medir onde o contexto falha e aplicar a tática mínima que resolve.
Como começar
- Trate a janela como orçamento, não como depósito. Meça quantos tokens cada componente consome: system prompt, ferramentas, histórico, outputs de ferramentas.
- Corte o loadout de ferramentas. Exponha só as relevantes para a tarefa. Dezenas de ferramentas simultâneas degradam a seleção, e o efeito é pior em modelos menores.
- Estabilize o prefixo e mantenha o contexto append-only. No preço citado pela Manus, token que acerta o cache custa 10x menos; a economia real depende da taxa de acerto.
- Mova o que é grande para fora da janela. Guarde referências leves (caminho, URL, query) e carregue o conteúdo sob demanda.
- Compacte com critério. Preserve decisões, erros e estado; descarte o redundante.
- Deixe as falhas visíveis no contexto. O erro que o modelo vê é o erro que ele tende a não repetir.
- Em tarefas longas, use recitação (uma todo list reescrita a cada passo) ou sub-agentes que devolvem resumos curtos.
O ponto central
Prompt engineering escreve uma boa instrução. Context engineering decide o que ocupa a janela a cada passo, sob um orçamento de atenção finito e um medidor de custo ligado.
Repare na conexão com o artigo anterior desta série. O harness é a estrutura que você constrói ao redor do agente. Context engineering é a disciplina que decide o que dessa estrutura entra na janela em cada momento. Pense no AGENTS.md de 100 linhas do experimento da OpenAI, que aponta para docs/. Ele é as duas coisas ao mesmo tempo: um guia do harness e uma decisão de contexto. O menor conjunto de tokens de alto sinal, com o resto carregado just-in-time.
A janela de um milhão de tokens não aposentou essa disciplina. Ela aumentou o tamanho do erro que cabe dentro dela.
Fontes
- Tobi Lütke, tweet, 19 jun 2025
- Harrison Chase (LangChain), The rise of “context engineering”, 23 jun 2025
- Andrej Karpathy, tweet, 25 jun 2025
- Simon Willison, Context engineering, 27 jun 2025
- Drew Breunig, How Long Contexts Fail, 22 jun 2025
- Drew Breunig, How to Fix Your Context, 26 jun 2025
- Kelly Hong et al. (Chroma), Context Rot, 14 jul 2025
- Yichao “Peak” Ji (Manus), Context Engineering for AI Agents, 18 jul 2025
- Anthropic, Effective context engineering for AI agents, 29 set 2025
- Anthropic, Harness design for long-running application development, 24 mar 2026
- Anthropic, Scaling Managed Agents, 8 abr 2026
Estudos e relatórios citados:
- Google DeepMind, Gemini 2.5 technical report (PDF)
- Databricks, Long Context RAG Performance of LLMs
- Microsoft/Salesforce, LLMs Get Lost in Multi-Turn Conversation
- Berkeley Function-Calling Leaderboard
- Less is More (arXiv 2411.15399)
- RAG-MCP (arXiv 2505.03275)
- Zeng, Huang e He, LOCA-bench (arXiv 2602.07962), 8 fev 2026
- Anthropic, The “think” tool
Deixe um comentário