Seu agente de IA funciona muito bem nos primeiros 10 passos.
Então, por volta do passo 15, ele começa a ficar desleixado.
Chamadas de ferramentas erradas. Esquecendo suas instruções originais. Resultados de baixa qualidade.
A maioria das pessoas culpa o modelo.
Quase nunca é o modelo.
É o que o modelo está vendo.
Organizar o que o modelo vê se chama engenharia de contexto.
Ela está rapidamente se tornando a habilidade mais importante para quem constrói agentes de IA.
Aqui está o guia completo.
A engenharia de prompt morreu. A engenharia de contexto é o que importa agora.

Você já ouviu falar de engenharia de prompt.
Escrever instruções claras. Bons exemplos. Dizer ao modelo qual papel desempenhar.
Isso funciona perfeitamente para um chatbot.
Para de funcionar no momento em que você constrói um agente.
Aqui está o porquê.
Um chatbot responde uma pergunta e para.
Um agente executa ações — navegar na web, chamar APIs, escrever código, rodar comandos — passo após passo após passo, às vezes por dezenas de passos.
Cada passo individual produz um resultado que é adicionado ao contexto do modelo.
E esse contexto é finito.
A equipe de engenharia da Anthropic define assim:
"Contexto é o conjunto de tokens incluídos quando você amostra de um LLM. Engenharia de contexto é otimizar a utilidade desses tokens para alcançar consistentemente um resultado desejado."
De forma simples: garanta que seu agente veja a informação certa, no formato certo, no momento certo.
Engenharia de prompt é um subconjunto da engenharia de contexto.
Engenharia de contexto é tudo.
A janela de contexto do seu agente é a RAM. E ela está enchendo.

A LangChain tem a analogia certa para isso.
Pense em um LLM como um novo tipo de sistema operacional.
O modelo é a CPU — ele faz o pensamento.
A janela de contexto é a RAM — a memória de trabalho onde tudo que o modelo pode ver e raciocinar no momento reside.
Assim como seu computador fica lento quando a RAM enche, o raciocínio do seu agente se degrada quando a janela de contexto fica lotada.
Isso se chama podridão de contexto.
A Chroma fez um estudo avaliando 18 modelos de fronteira — GPT-4.1, Claude 4, Gemini 2.5, Qwen3 e outros.
O desempenho de todos os modelos degradou à medida que o comprimento da entrada aumentava.
Não no limite máximo. Muito antes disso.
Um modelo com uma janela de 200K tokens pode mostrar degradação significativa em 50K tokens.
O declínio é contínuo. Não é um precipício.
Por quê? Transformers funcionam fazendo com que cada token preste atenção em todos os outros tokens — criando relações n-quadrado. Conforme o contexto cresce, a capacidade do modelo de manter todas essas relações se dilui.
E então tem o problema do "Perdido no Meio".
LLMs mostram uma curva de atenção em forma de U.
→ Início do contexto: bem lembrado
→ Final do contexto: bem lembrado
→ Meio: largamente ignorado
Pesquisadores mediram uma queda de precisão de mais de 30 pontos percentuais quando a informação relevante se movia do início do contexto para o meio.
Suas instruções originais — enterradas sob 50.000 tokens de resultados de ferramentas — efetivamente desaparecem.
Usuários do Claude Code descobriram que a qualidade do resultado degrada em 40–60% da capacidade de contexto. Muito antes de qualquer limite máximo.
O que está realmente competindo por espaço no contexto do seu agente

7 categorias. Todas lutando pela mesma janela finita.
1. Prompt do Sistema
A identidade do agente. Regras comportamentais. Lógica de fluxo de controle. Instruções para diferentes tipos de tarefa. Em um agente, isso não é só "seja útil". Pode definir a arquitetura inteira.
2. Definições de Ferramentas
Cada ferramenta que o agente pode chamar precisa de um esquema descrevendo o que ela faz, quais parâmetros recebe e quando usá-la.
3. Resultados de Chamadas de Ferramentas
Cada chamada de ferramenta adiciona seu resultado ao contexto. Uma recuperação de página web: 5.000–10.000 tokens. Uma leitura de arquivo: similar. Isso acumula rápido.
4. Conhecimento Recuperado (RAG)
Documentos puxados de bancos vetoriais, resultados de busca, respostas de API — qualquer coisa recuperada para informar as decisões do agente.
5. Histórico da Conversa
A transcrição completa de tudo que aconteceu. Mensagens do usuário, respostas do agente, raciocínio, decisões anteriores. Cresce linearmente a cada turno.
6. Memória
Memória de curto prazo da sessão atual. Memória de longo prazo de sessões anteriores — preferências do usuário, resultados anteriores, padrões aprendidos.
7. Estado do Agente
Plano atual, lista de tarefas, marcadores de progresso, anotações de rascunho. A meta-informação que rastreia onde o agente está em uma tarefa de múltiplos passos.
Todos os 7 competindo pela mesma janela.
Engenharia de contexto é decidir o que vence.
As 4 Estratégias Principais
A LangChain publicou a estrutura que organiza toda técnica de engenharia de contexto em 4 categorias.
Toda técnica que você aprenderá se encaixa em uma delas.
Escrever. Selecionar. Comprimir. Isolar.

Estratégia 1 — Escrever (Agentes esquecem. Dê a eles uma forma de lembrar.)

Quando o contexto de um agente enche e é compactado, ele perde informação.
Se o agente não escreveu nada antes disso acontecer — essa informação se foi para sempre.
Escrever significa dar ao agente maneiras de persistir informações fora da janela de contexto.
Três formas:
Scratchpads (Blocos de Anotações)
Dê ao agente uma ferramenta que permita que ele faça anotações durante uma tarefa. Descobertas intermediárias. Decisões tomadas. Informações que ele sabe que precisará depois.
A Anthropic construiu uma ferramenta "think" (pensar) — um espaço dedicado para o Claude trabalhar nos problemas.
No benchmark tau-bench, isso melhorou o desempenho em até 54% em certas tarefas.
Arquivos de Regras
Memória procedural persistente.
Se você já usou o Claude Code, viu o CLAUDE.md.
Instruções carregadas no início de cada sessão — arquitetura do projeto, convenções, como rodar testes, com o que ter cuidado.
O agente lê isso toda vez que inicia.
Ele nunca esquece o fundamental.
Extração de Memória
O agente salva fatos, preferências do usuário e padrões aprendidos para que possa recuperá-los entre sessões.
Vive fora da janela de contexto completamente.
Informação que o agente precisa amanhã está lá esperando quando amanhã chegar.
Estratégia 2 — Selecionar (Não dê tudo ao agente. Dê a ele o que precisa agora.)

Um agente com 40 ferramentas, uma grande base de conhecimento e várias sessões de histórico não pode carregar tudo isso de uma vez.
Algo tem que decidir o que é relevante para este passo.
RAG Tradicional: o sistema decide.
Usuário pergunta → recuperar documentos → enfiar no prompt → pronto.
Estático. Único disparo. O modelo não tem voz.
RAG Agentic: o agente decide. Ele busca o que precisa, refina consultas, escolhe ferramentas, determina quando tem informação suficiente.
Recuperação como um processo iterativo, não um pipeline de disparo único.
Isso importa porque o que é relevante muda a cada passo — e só o agente sabe o que precisa a seguir.
O problema de seleção de ferramentas é o que mais atrapalha as pessoas.
Se seu agente tem 40+ ferramentas, isso são potencialmente 10.000 tokens de definições de ferramentas no contexto antes mesmo de qualquer trabalho começar.
A solução: RAG sobre descrições de ferramentas.
Em vez de despejar todas as definições de ferramentas em cada chamada, use busca semântica para exibir apenas as ferramentas relevantes para o passo atual.
Um artigo chamado RAG-MCP testou isso.
Precisão da seleção de ferramentas: 14% → 43% (melhora de 3x). Uso de tokens: reduzido aproximadamente pela metade.
A Anthropic chama isso de estratégia híbrida: carregue o contexto essencial no início (como CLAUDE.md), deixe o agente fazer recuperação just-in-time para todo o resto.
Carregue o básico no início. Recupere o resto sob demanda.
Estratégia 3 — Comprimir (Contexto acumula. Mantenha o significado, corte os tokens.)

Mesmo com uma boa seleção, o contexto acumula.
Cada chamada de ferramenta, documento recuperado e decisão permanece na janela.
Imagine que seu agente fez 20 chamadas de ferramentas.
Contexto: 80.000 tokens de resultados acumulados de ferramentas, histórico de conversa, traços de raciocínio.
A maior parte disso não é mais relevante. O agente já agiu sobre isso.
Mas ainda está lá, ocupando espaço, degradando a atenção, aumentando custo e latência.
Você pode comprimir em 3 pontos.
Antes da informação entrar no contexto:
→ Divida documentos grandes em partes coerentes antes da recuperação
→ Reordene para que apenas os fragmentos mais úteis entrem
→ Resuma resultados de ferramentas em tempo real antes de entrarem no contexto principal
Enquanto o agente está trabalhando:
→ Resumo contínuo do histórico da conversa — atualizado constantemente
→ Híbrido popular: mantenha as últimas 10 mensagens na íntegra + resuma tudo mais antigo
→ Corte rígido: remova mensagens mais antigas quando o contexto atingir um limite de tamanho
→ Compactação automática do Claude Code: dispara em 95% da capacidade, resume automaticamente a trajetória completa
Depois que o agente agiu sobre algo:
→ Limpeza de resultado de ferramenta: depois que um resultado de ferramenta foi usado há 15 passos, elimine-o
→ Substitua por um resumo de uma linha ou remova completamente
→ O agente não precisa do texto completo de uma página web que buscou 20 passos atrás
O objetivo: reduzir a contagem de tokens. Preservar o que realmente importa.
Estratégia 4 — Isolar (A estratégia mais poderosa. Viabiliza sistemas multiagentes.)

Aqui está o problema mais profundo com execuções longas de agentes.
Não é apenas espaço. É contaminação.
As buscas detalhadas em arquivos da fase de pesquisa ainda estão no contexto quando o agente passa para a escrita de código.
Aquele contexto de pesquisa antigo agora é ruído. Está distraindo o modelo durante uma fase em que ele precisa focar em implementação limpa.
Isolar significa dar a diferentes partes do trabalho suas próprias janelas de contexto separadas.
Subagentes
Um agente pai delega uma subtarefa focada — "pesquise na base de código todos os arquivos relacionados à autenticação" — para um subagente.
O subagente trabalha em sua própria janela de contexto limpa.
Quando ele reporta de volta, retorna apenas um resumo condensado.
Todas as operações de busca confusas permanecem isoladas no contexto do subagente e nunca poluem o pai.
Isolamento de esquema de estado (abordagem do LangGraph)
Projete o estado do agente para que diferentes campos armazenem diferentes tipos de contexto.
O LLM só vê os campos relevantes para o passo atual.
Resultados de ferramentas ficam em um campo "backstage" (nos bastidores) — invisível para o modelo até ser explicitamente exibido.
Controle refinado sobre o que o agente vê em cada passo sem precisar criar subagentes separados.
Isolamento é o que torna fluxos de trabalho complexos de múltiplos passos realmente confiáveis.
Trabalhos diferentes. Janelas de contexto diferentes. Sem contaminação.
4 Maneiras como Agentes Falham (Nomeie a falha. Corrija-a.)
Drew Breunig identificou quatro modos distintos de falha à medida que o contexto do agente cresce.
Todo agente quebrado que você já viu se encaixa em um deles.

Falha 1: Envenenamento de Contexto
Uma alucinação ou erro entra no contexto.
O agente o referencia repetidamente em passos subsequentes.
Dados ruins do passo 5 se acumulam em cada passo seguinte.
Correção: Valide os resultados das ferramentas antes de entrarem no contexto. Após se recuperar de um erro, comprima o histórico da tentativa fracassada. Não deixe 10 passos de depuração sem saída visíveis quando apenas a resolução importa.
━━━
Falha 2: Distração de Contexto
O contexto fica tão longo que o modelo começa a confiar excessivamente no histórico recente.
Em vez de sintetizar um plano novo, ele apenas repete o que fez recentemente.
Ele para de pensar. Começa a repetir.
Correção: Resuma e pode agressivamente. Mesmo quando você tem uma grande janela de contexto disponível. Janela grande não significa enchê-la.
━━━
Falha 3: Confusão de Contexto
Conteúdo supérfluo leva o modelo a decisões de baixa qualidade.
Exemplo clássico: um modelo falhando em um benchmark quando recebe 46 ferramentas — mesmo com o contexto dentro dos limites — mas funcionando bem com apenas 19 ferramentas.
As ferramentas não eram muitas para o contexto suportar.
Eram muitas para o modelo raciocinar claramente.
Correção: Gerenciamento dinâmico de ferramentas. Use RAG-MCP para exibir apenas as ferramentas relevantes para o passo atual. Mantenha o conjunto de ferramentas adequado à fase atual.
━━━
Falha 4: Conflito de Contexto
Nova informação contradiz algo já presente no contexto.
O prompt do sistema diz uma coisa. Um documento recuperado diz outra diferente.
O agente não consegue reconciliar a contradição. Produz comportamento inconsistente.
Correção: Estabeleça uma ordenação clara de autoridade. Prompt do sistema > fatos recuperados > histórico da conversa. Valide novas informações contra o contexto existente antes de injetá-las. Use tags XML e cabeçalhos claros para que o modelo saiba em qual fonte confiar.
Como Escrever Prompts de Sistema para Agentes (Não chatbots. Agentes.)

Um prompt de sistema de chatbot define um tom.
"Você é um assistente útil. Seja conciso e amigável."
Um prompt de sistema de agente define arquitetura.
Ele especifica o fluxo de controle — como abordar tipos de tarefa, quais ferramentas usar quando, o que fazer em erros, quais diretrizes seguir.
Está mais próximo de escrever uma descrição de cargo para um funcionário autônomo do que um prompt de personalidade.
A Anthropic chama isso de escrever na "altitude certa".
Muito prescritivo:"Se o usuário mencionar cobrança E mencionar um reembolso E o valor for superior a R$ 100, chame a ferramenta X." Frágil. Quebra em cada caso extremo que você não antecipou.
Muito vago:"Seja útil e use as ferramentas apropriadas." Não dá nada ao agente. Ele não consegue tomar boas decisões autônomas sem sinais concretos.
O ponto ideal:Específico o suficiente para guiar o comportamento autônomo. Flexível o suficiente para o modelo aplicar julgamento em situações novas. Heurísticas fortes. Não regras rígidas.
Dicas práticas:
→ Organize com tags XML ou cabeçalhos markdown — Contexto, Instruções, Orientação de Ferramentas
→ Comece mínimo e itere nas falhas — não tente antecipar todos os casos extremos no início
→ Mínimo não significa curto — um prompt de sistema de agente complexo pode ter milhares de tokens e tudo bem, desde que cada token ganhe seu lugar
→ Use exemplos de poucos disparos — mostre ao agente como é um bom comportamento em vez de tentar descrever cada regra em palavras
O KV-Cache: O motivo $$$ para se importar com a ordem do contexto

A maioria dos construtores de agentes não sabe que isso existe.
Quando você envia tokens para um LLM, o modelo computa representações chave-valor para cada token.
Computacionalmente caro.
Então, provedores de inferência armazenam em cache essas representações.
Se o início do seu contexto — o prefixo — permanece o mesmo entre chamadas de API, o provedor reutiliza a computação em cache e processa apenas os novos tokens no final.
Rápido. Barato.
Mas se você reorganizar ou alterar a parte inicial do seu contexto entre chamadas — você invalida o cache. O provedor recomputa tudo do zero.
A diferença de custo no Claude Sonnet:
→ Tokens de entrada em cache: $0,30 por milhão
→ Tokens de entrada não armazenados em cache: $3,00 por milhão
Diferença de 10x.
Para um agente fazendo 30–40 chamadas de API por tarefa, isso acumula rápido.
Regras práticas para eficiência do KV-cache:
→ Conteúdo estável vai no TOPO do contexto — prompt do sistema, definições de ferramentas, qualquer coisa que não mude entre turnos
→ Conteúdo dinâmico vai na BASE — histórico da conversa, passo atual, estado do agente → Não adicione e remova ferramentas dinamicamente no meio da conversa — isso invalida o cache
→ Use mascaramento de ferramentas em vez de remoção de ferramentas — mantenha todas as definições de ferramentas estáveis no prefixo (em cache), apenas marque as irrelevantes como indisponíveis para a fase atual
O Fluxo de Trabalho Que Entrega 35.000 Linhas de Código em 7 Horas

Dex Horthy (CEO da HumanLayer) apresentou isso no AI Engineer Code Summit.
Sua equipe supostamente o usou para entregar ~35.000 linhas de código em uma grande base de código Rust em uma única sessão de 7 horas.
O método: Compactação Intencional Frequente.
Estruture o trabalho do agente em fases. Cada fase produz um artefato compactado. Cada nova fase começa com uma janela de contexto limpa contendo apenas aquele artefato.
Mantenha-se deliberadamente abaixo de 40–60% da janela de contexto em todos os momentos.
Fase 1 — Pesquisa
Subagentes exploram a base de código. Leem arquivos. Rastreiam fluxos de dados. Mapeiam arquitetura.
Todos os resultados confusos de grep e conteúdos de arquivo permanecem nos contextos dos subagentes. Nunca tocam o pai. (Isolar)
Saída: um research.md compacto — caminhos de arquivo, assinaturas de funções, padrões, pegadinhas. (Escrever)
Reset de contexto: a pesquisa bruta usou 60–80% da janela. O artefato de pesquisa comprime para 15–20%. (Comprimir)
Fase 2 — Planejamento
Nova janela de contexto. Contém apenas: documento de pesquisa + definição do problema.
Agente produz um plano de implementação detalhado.
Este é o ponto de verificação de revisão humana mais importante.
Capture erros de lógica aqui, onde corrigi-los é fácil e gratuito. Mais tarde, custa horas.
Fase 3 — Implementação
Outra janela de contexto limpa. Contém apenas: o plano.
Agente o segue passo a passo.
Para tarefas complexas: um progress.md rastreia o que foi concluído e o que resta. (Escrever)
O resultado: um agente limpo e focado em cada fase. Sem contaminação. Sem podridão de contexto. Sem "passo 20 desleixado".
Como as melhores plataformas lidam com isso de forma diferente
Claude Code
Recuperação híbrida. CLAUDE.md carrega no início. Ferramentas como glob e grep lidam com navegação just-in-time na base de código.
Compactação automática em 95% — preserva decisões arquiteturais e os 5 arquivos acessados mais recentemente.
Pode gerar subagentes para subtarefas complexas, cada um com seu próprio contexto limpo.
Filosofia: "faça a coisa mais simples que funciona." Deixe o modelo ser inteligente sobre o que precisa e dê a ele ferramentas para encontrar.
Manus
Ordenação de contexto consciente do KV-cache: prefixo estável, sufixo dinâmico. Mascaramento de ferramentas, não remoção.
Pipeline de compressão de observação — todo resultado de ferramenta é processado antes de entrar no contexto do agente.
Lista de tarefas persistente para rastreamento de estado.
Sistema de arquivos como memória de estouro para contexto removido.
Construído para escala. Atendendo centenas de milhares de usuários onde eficiência é um problema de custo do negócio.
ChatGPT Agent
Abordagem visual primeiro. O agente interage com um navegador GUI.
Capturas de tela adicionadas ao contexto como instantâneos visuais. Modelo raciocina sobre o que vê.
Tokens visuais são caros, então o agente é seletivo sobre o número de capturas de tela.
Usa RL para aprender estratégias ótimas de uso de ferramentas em milhares de máquinas virtuais, em vez de programá-las explicitamente.
Google ADK
A abordagem arquitetural mais principiada.
Três princípios de design:
- Separe armazenamento de apresentação — estado durável não é o mesmo que o que aparece em cada chamada de API
- Transformações explícitas — processadores nomeados e ordenados que transformam o contexto em etapas testáveis e combináveis
- Escopo de contexto por padrão — cada chamada de modelo vê apenas a informação mínima necessária
Disciplina de engenharia sobre criação de prompt.
O pipeline universal de turno de agente
Toda plataforma séria converge para o mesmo loop de 5 passos por turno de agente:
→ Coletar — entrada do usuário, histórico da conversa, resultados de ferramentas, documentos recuperados, estado do agente
→ Selecionar — o que é relevante para este passo dentro do orçamento de token restante
→ Comprimir — resumir, truncar ou reestruturar para caber no contexto → Arranjar — conteúdo estável primeiro (cache), conteúdo dinâmico por último
→ Montar + chamar — contexto final → chamada de API → obter saída → loop
Este é o loop rodando dentro de todo agente de produção que você já usou.
Entendê-lo é o que separa construtores que entregam agentes confiáveis daqueles que se perguntam por que seu agente fica desleixado no passo 15.
O resumo
A podridão de contexto é real e começa bem antes do seu limite de contexto.
As 4 estratégias que a corrigem:
→ Escrever — persista informações fora do contexto para que agentes não esqueçam
→ Selecionar — traga apenas o necessário para este passo
→ Comprimir — corte tokens, mantenha o significado, proativamente não reativamente
→ Isolar — contextos separados para trabalhos separados, sem contaminação
Os 4 modos de falha para observar:
→ Envenenamento — dados ruins se acumulam a cada passo
→ Distração — histórico longo faz agentes repetirem em vez de pensar
→ Confusão — muitas ferramentas degrada a qualidade da decisão
→ Conflito — contradições produzem comportamento inconsistente
O KV-cache vale uma economia de 10x. Coloque conteúdo estável primeiro.
O melhor fluxo de trabalho: pesquisar → compactar → planejar → compactar → implementar. Contexto limpo em cada fase.
Engenharia de contexto não é opcional para trabalho sério com agentes.
É o trabalho.
Se isso foi útil:
→ Reposte para compartilhar com todo construtor de agente que você conhece
→ Siga @sairahul1 para mais sistemas que funcionam enquanto você dorme
→ Salve isto — você voltará à estrutura das 4 estratégias
Eu escrevo sobre IA, construção de produtos e sistemas que realmente funcionam.





