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. Context engineering começa exatamente onde esse instinto falha.
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. Três coisas mudaram desde então.
O LOCA-bench mostra queda com contexto crescente e a Anthropic reporta novos modos de falha: ansiedade de contexto, resets e trimming. E mesmo que janelas maiores cheguem, a poluição ainda será uma realidade, especialmente onde buscamos o melhor desempenho dos agentes.
Se você tem 30 segundos
- Contexto a mais, sem curadoria, degrada o resultado. O Chroma mediu isso em 18 modelos, e um único distrator já reduz o desempenho.
- As falhas cabem em quatro tipos: envenenamento, distração, confusão e conflito. A confusão por excesso de ferramentas atinge direto quem pluga MCP em tudo.
- As táticas respondem a quatro perguntas: o que entra, o que sai, o que mora fora e o que se isola.
- No preço que a Manus cita, input com cache custa 10x menos. Prefixo estável e contexto append-only são a alavanca de custo.
- Nenhum modelo deste artigo transfere de um para outro. Meça onde seu contexto falha e aplique a tática mínima.
Origem do termo
A popularização do termo aconteceu em uma semana de junho de 2025.
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.
Na maior parte das vezes, quando um agente não entrega resultado confiável, a causa é contexto, instruções ou ferramentas que não chegaram ao modelo.
A Anthropic posiciona a disciplina como a evoluçã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.
No fundo, são técnicas para 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: o desempenho não é uniforme conforme o input cresce, mesmo em tarefas simples. Um único distrator (conteúdo parecido com a resposta, mas errado) já reduz o desempenho; 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 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. O desempenho 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.
Como o contexto chega também derruba o desempenho. 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, 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 tem desempenho 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 (/compact) 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. 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.
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). 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:
- 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.
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 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.
De volta ao harness
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