Engenharia de contexto: por que seu agente de IA erra mesmo com o melhor prompt
Você escreveu um prompt bom. Testou no chat, ajustou, deixou redondo. Aí colocou o mesmo texto dentro de um agente que roda sozinho na operação e a qualidade despencou. A culpa quase nunca está na redação do prompt. Está no que o agente tem na frente dele na hora de decidir. Essa camada tem nome, e virou a disciplina central de quem coloca IA pra trabalhar de verdade: engenharia de contexto.
Engenharia de contexto é o trabalho de escolher, montar e manter o conjunto de informação que o modelo enxerga a cada passo. O prompt é um pedaço disso. O resto é histórico da conversa, retorno de ferramenta, dado do cliente, arquivo aberto, memória do que já foi feito ontem. Neste guia a gente mostra por que contexto demais piora a resposta, o que os dados dizem sobre onde as operações travam e as táticas que a gente usa pra manter agente de marketing rodando com qualidade em produção.
O prompt deixou de ser o gargalo
Em 2023 e 2024, escrever prompt era a habilidade que separava quem tirava resultado de quem não tirava. Fazia sentido. O regime de uso era um chat: você pergunta, o modelo responde, a conversa acaba. Todo o resultado cabia dentro da qualidade daquele texto.
Agente é outro regime. Ele planeja, chama uma ferramenta, lê o retorno, avalia, decide de novo, chama outra ferramenta. Cada volta desse loop escreve mais coisa dentro da janela do modelo. Quando a tarefa termina, o que está na frente dele tem pouca semelhança com o prompt que você escreveu no começo. O prompt virou a primeira linha de um documento que o próprio agente foi enchendo sozinho.
É por isso que times experientes pararam de brigar com o texto da instrução. O problema mudou de lugar e virou engenharia de contexto. A pergunta agora é quais tokens entram, quais saem, em que ordem e em que momento.
O que é engenharia de contexto na prática
A Anthropic define engenharia de contexto como o conjunto de estratégias pra curar e manter o grupo ideal de tokens durante a inferência. A distinção que ela faz em relação ao prompt é útil na prática: escrever prompt é uma tarefa discreta, você faz uma vez e usa. Engenharia de contexto é iterativa, acontece a cada passo do loop, porque a cada passo o agente produz mais informação candidata a ocupar espaço.
O prompt continua existindo, num escopo menor
A instrução de sistema segue importante. Ela define papel, regra de marca, critério de qualidade, o que o agente pode e não pode fazer sozinho. Só que ela passou a ser uma fatia do total. Numa tarefa longa, a instrução costuma ocupar uma parcela pequena do que o modelo está lendo na hora de decidir.
O que entra na janela a cada passo
Vale mapear as camadas, porque cada uma cresce de um jeito diferente e cada uma exige um controle diferente.
Instrução
System prompt, regras da marca, formato de saída. Tamanho fixo. Você controla direto.
Histórico
Tudo que já foi dito e feito na tarefa atual. Cresce sozinho, a cada volta do loop, e é a camada que mais estoura.
Ferramentas
A descrição de cada ferramenta disponível mais o retorno de cada chamada. Uma resposta de API pode injetar milhares de tokens de uma vez.
Conhecimento
Documento, planilha, base de dados, resultado de busca. É onde a maioria das operações exagera, jogando arquivo inteiro quando bastava um trecho.
Memória
O que precisa sobreviver entre uma sessão e outra: preferência do cliente, decisão já tomada, erro já corrigido. É a camada que quase ninguém monta.
Context rot: por que mais contexto piora a resposta
A intuição de quem está começando é que janela grande resolve. Se o modelo aceita um milhão de tokens, joga tudo lá dentro e deixa ele achar o que precisa. Os dados dizem outra coisa.
A explicação técnica é a de orçamento de atenção. O transformer cria relações entre cada par de tokens, o que significa n² relações pra n tokens. Conforme a janela cresce, essa capacidade de atenção se espalha mais fino. Some a isso o fato de que os modelos foram treinados majoritariamente em sequências curtas, então têm menos experiência com entradas muito longas. O efeito prático ganhou o apelido de context rot: a precisão de recuperar informação cai conforme o número de tokens sobe.
A Chroma testou isso em 18 modelos de ponta, incluindo Claude, GPT, Gemini e Qwen. O resultado se repetiu em todos, inclusive em tarefas simples de recuperar um dado ou copiar um texto. Três achados importam pra quem opera:
- Quanto menos parecida a pergunta é do trecho que responde ela, mais rápido o desempenho cai com o aumento do contexto. Pergunta ambígua sofre mais.
- Um único distrator, ou seja, um trecho parecido com a resposta mas errado, já derruba o acerto em relação ao contexto limpo. Quatro distratores derrubam mais.
- No teste de memória de longo prazo, os mesmos 18 modelos foram significativamente melhores quando receberam só o trecho relevante, na casa de 300 tokens, do que quando receberam o contexto completo de 113 mil tokens. A informação estava lá nos dois casos. A diferença foi o ruído em volta.
Esse último ponto é o que mais muda a cabeça de quem monta operação. Colocar o dado na janela não garante que o modelo vá usar o dado.
Dado
Contexto longo cobra um preço, e o mercado já está pagando
Testes controlados de contexto e projeção de mercado de IA agêntica
Fontes: Chroma Research, Context Rot, 2025; Gartner, junho de 2025.
Onde a operação trava, segundo os dados
O relatório do MIT NANDA sobre o estado da IA nos negócios mapeou 300 implantações públicas, 150 entrevistas com líderes e 350 respostas de funcionários. O funil que ele desenha é duro: muita empresa avalia, poucas pilotam, quase nenhuma chega a produção.
Dado
O funil que quase ninguém termina
% das organizações que avaliaram sistemas corporativos de IA generativa
Fonte: MIT Project NANDA, The GenAI Divide: State of AI in Business 2025.
O diagnóstico do relatório sobre a causa é o que interessa aqui. O relatório aponta o aprendizado como barreira principal, acima de infraestrutura, regulação ou disponibilidade de gente boa. A maior parte dos sistemas de IA generativa não retém feedback, não se adapta ao contexto e não melhora com o tempo. Um dos entrevistados resume o sintoma de um jeito que todo mundo que já usou IA no dia a dia reconhece. A ferramenta é ótima pra rascunho, só que não guarda a preferência do cliente, não aprende com as correções anteriores, repete o mesmo erro e exige que você reescreva o contexto inteiro a cada sessão.
Isso é uma falha de engenharia de contexto descrita com outras palavras. E é resolvível.
Como o problema aparece numa operação de marketing
Sai do abstrato. Alguns sintomas que a gente encontra com frequência quando entra numa operação que já tem IA rodando:
- O agente de conteúdo recebe a brand bible inteira, os últimos 40 posts e o briefing do mês de uma vez. O texto que sai é correto e genérico, porque a regra que importava estava na página 14 de um bloco enorme.
- O agente de mídia tem 30 ferramentas conectadas, com três que fazem quase a mesma coisa. Ele escolhe a errada com frequência e ninguém entende o critério.
- Uma correção que o time fez na terça reaparece como erro na quinta. Não existe camada de memória, então a decisão morreu junto com a sessão.
- O agente puxa o relatório completo da API quando precisava de três métricas. Enche a janela de número irrelevante e ainda infla o custo por entrega.
Nenhum desses casos se resolve trocando de modelo. Todos se resolvem com engenharia de contexto, mudando o que entra na janela.
Cinco táticas de engenharia de contexto que a gente aplica
Essas cinco táticas de engenharia de contexto cobrem a maioria dos casos numa operação de marketing. Elas se combinam.
Recuperação sob demanda
Em vez de pré-carregar todo o material, o agente carrega identificadores leves: caminho de arquivo, link, consulta salva. Ele abre o que precisa na hora que precisa. A brand bible continua acessível sem ocupar espaço permanente na janela. É a tática que mais economiza espaço em operação de conteúdo.
Compactação
Quando a conversa se aproxima do limite, você resume e recomeça a partir do resumo. O detalhe que separa compactação boa de compactação ruim é o critério do que preservar: decisão tomada, restrição da marca, pendência aberta e o que já foi tentado e falhou. O resto pode ir embora.
Anotação estruturada
O agente escreve nota fora da janela, num arquivo ou base, e lê de volta quando volta ao assunto. É a resposta direta pro problema de memória que o MIT descreveu. Preferência de cliente, tom aprovado, correção recorrente: tudo isso vira registro persistente em vez de virar prompt repetido toda semana.
Subagentes
Um agente especialista faz a tarefa pesada num contexto próprio e devolve pro orquestrador só um resumo destilado, tipicamente na casa de mil a dois mil tokens. A janela do orquestrador fica limpa. É o mesmo princípio de arquitetura de agentes com squad orquestrada que a gente descreveu no pilar do cluster, visto agora pelo ângulo do consumo de contexto.
Ferramentas enxutas
Cada ferramenta precisa ser autocontida, clara no propósito e sem sobreposição com outra. Se duas ferramentas fazem quase a mesma coisa, você criou um ponto de decisão ambíguo, e o agente vai errar nele. Vale revisar o inventário de conexões da operação, principalmente em quem já liga agentes às ferramentas via MCP e foi acumulando integração ao longo dos meses.
Como saber se o problema é de engenharia de contexto ou de modelo
Tem um teste barato pra separar as duas coisas. Pegue uma tarefa que o agente errou. Monte à mão o contexto mínimo pra ela: só a instrução, só o trecho de referência que importa, só a ferramenta necessária. Rode de novo.
Se o resultado ficar bom, o problema era contexto, e você tem cinco táticas acima pra atacar. Se continuar ruim mesmo com o contexto curado, aí sim vale investigar modelo, decomposição da tarefa ou critério de qualidade mal definido.
Esse teste de engenharia de contexto é a versão de bancada. A versão de operação é montar um conjunto de casos e medir sempre, do jeito que a gente descreveu em avaliação de agentes de IA. Sem medição, a discussão sobre contexto vira opinião.
Por onde começar a engenharia de contexto na sua operação
Quatro passos, na ordem, pra quem já tem agente rodando e quer arrumar a casa.
1. Registre o que entra na janela hoje
Pegue uma tarefa real e liste tudo que o agente recebe: instrução, arquivos, retorno de ferramenta, histórico. A maioria dos times nunca fez isso e se surpreende com o tamanho.
2. Corte o que não é usado
Documento inteiro que serve por um parágrafo vira trecho recuperado sob demanda. Ferramenta que ninguém chama há um mês sai do inventário. Esse corte costuma ser o ganho mais rápido.
3. Mova o permanente pra memória
O que vale pra sempre, como preferência de cliente e regra de marca, não deveria ser reescrito no prompt toda semana. Vira registro persistente que o agente lê quando precisa. Isso depende de ter a base de dados organizada antes.
4. Meça antes e depois
Rode o mesmo conjunto de casos com o contexto antigo e com o novo. Compare acerto, retrabalho e custo por entrega. Sem esse número, você não sabe se melhorou.
Perguntas frequentes sobre engenharia de contexto
Engenharia de contexto e engenharia de prompt são a mesma coisa?
Não. Engenharia de prompt é escrever bem a instrução: papel, regra, formato de saída. Engenharia de contexto é decidir tudo o que o modelo enxerga a cada passo, e o prompt é só uma fatia disso. Numa tarefa longa de agente, a instrução ocupa uma parte pequena da janela. O resto é histórico, retorno de ferramenta, documento e memória. Quem cuida só do prompt está otimizando a menor parte do problema.
Preciso de um modelo com janela maior pra fazer engenharia de contexto?
Janela maior ajuda menos do que parece. O teste da Chroma com 18 modelos mostrou que a precisão cai conforme o contexto cresce, mesmo em tarefa simples. Engenharia de contexto funciona no sentido contrário: reduzir o que entra, deixar só o trecho que responde a pergunta. Um modelo mediano com contexto limpo costuma entregar melhor do que um modelo grande lendo um bloco enorme de material irrelevante.
Quanto contexto é demais?
Depende da tarefa, mas o sinal é claro: se o agente recebe um documento inteiro pra usar um parágrafo, ou 30 ferramentas pra chamar 3, já passou do ponto. A regra prática que a gente usa em engenharia de contexto é carregar identificador leve (caminho, link, consulta) e abrir o conteúdo só na hora que ele é necessário. A janela fica reservada pro que decide a resposta.
Engenharia de contexto vale pra chat ou só pra agente?
Vale pros dois, mas o impacto é diferente. No chat, a conversa é curta e você corrige na hora. No agente, cada volta do loop escreve mais coisa na janela e ninguém está olhando. É aí que a engenharia de contexto deixa de ser detalhe e vira a diferença entre um agente que roda em produção e um que precisa de babá.
Como a engenharia de contexto reduz o custo de IA?
Token que entra na janela é token cobrado. Um agente que puxa o relatório completo da API quando precisava de três métricas paga por milhares de tokens inúteis em cada entrega, e ainda erra mais por causa do ruído. Recuperação sob demanda, compactação e subagentes cortam esse desperdício. Na prática, engenharia de contexto é uma das alavancas mais diretas pra derrubar custo por entrega sem derrubar qualidade.
Quem cuida da engenharia de contexto numa agência?
Quem desenha a operação. Não é tarefa de quem escreve prompt nem de quem só usa a ferramenta. Alguém precisa mapear o que entra na janela de cada agente, decidir o que vira memória persistente, o que vira recuperação sob demanda e o que sai do inventário. Na Hipercode, isso faz parte da arquitetura de agentes de cada conta e é revisado junto com a avaliação dos agentes, com número na mão.
O que a gente leva desse dado
A conclusão prática é que a qualidade de um agente em produção depende menos da frase que você escreveu e mais da engenharia de contexto em volta dele. Modelo bom com contexto sujo entrega pior do que modelo mediano com contexto limpo. Essa é a inversão que a engenharia de contexto trouxe pra quem opera.
Pra uma agência ou um time de marketing, isso é uma boa notícia. Significa que a diferença competitiva está numa camada que você controla, que não custa caro e que não depende do próximo lançamento de modelo. Depende de curadoria, de disciplina e de medir.
É esse trabalho de arquitetura que a gente faz nas operações que roda. Se você quer entender como a gente monta uma operação de marketing com IA do zero, ou já tem agentes rodando e quer um diagnóstico do que está entrando na janela deles, fala com a gente. Começa por uma conversa de trinta minutos sobre onde sua operação está travando hoje.