Engenharia de contexto: o que vai no prompt (e o que NÃO vai)

Seu agente não fica burro por falta de contexto. Fica burro por excesso. E essa é a parte que quase ninguém te conta quando vende "janela de 1 milhão de tokens" como se fosse vantagem grátis.

Engenharia de contexto é a disciplina de decidir o que entra no prompt do modelo a cada chamada — e, principalmente, o que não entra. System prompt, exemplos, histórico da conversa, dados recuperados de um banco vetorial: tudo isso disputa o mesmo espaço escasso. Quem entope esse espaço acha que está ajudando o modelo. Está sabotando.

Neste post você vai entender por que mais contexto degrada a resposta, qual é o critério para decidir o que sobe pro prompt e o que fica de fora, e como tratar a janela de contexto pelo que ela é: um recurso finito que você administra, não um balde que você enche.

TL;DR

• O que é: engenharia de contexto é curar o conjunto de tokens que o modelo vê na hora da inferência — a evolução natural da engenharia de prompt.
• Por que importa: atenção do modelo é um orçamento finito. Encher de contexto irrelevante derruba a precisão, mesmo em modelos de fronteira.
• O que muda na prática: você para de pensar "que prompt mágico escrevo?" e passa a pensar "qual a menor configuração de contexto que produz o comportamento que eu quero?".
• Leitura-base: Effective context engineering for AI agents (Anthropic) e a pesquisa Context Rot (Chroma).

O que é engenharia de contexto (e por que virou a habilidade que importa)

A Anthropic define engenharia de contexto como o conjunto de "estratégias para curar e manter o conjunto ótimo de tokens durante a inferência" do modelo (Anthropic). Repara na palavra: curar. Não é escrever mais. É escolher.

Engenharia de prompt era sobre achar as palavras certas para uma tarefa única. Engenharia de contexto é sobre o ambiente inteiro de informação que o modelo enxerga: instruções de sistema, definições de ferramentas, exemplos, memória, histórico e o que você recuperou de fora. A analogia que circula é boa: prompt engineering é escrever o memorando; engenharia de contexto é decidir o que está em cima da mesa quando a pessoa vai ler.

A diferença prática é o ciclo. Prompt você escreve uma vez. Contexto você decide a cada passo do agente — porque um agente rodando em loop gera um universo de informação que cresce sozinho a cada chamada: saída de ferramenta, documento recuperado, raciocínio intermediário, resposta do usuário. Alguém precisa decidir o que desse monte chega na memória de trabalho do modelo. Esse alguém é você.

Isso não é hype. É engenharia. E é exatamente o tipo de decisão que separa um agente que aguenta produção de um que quebra na terceira interação. Não à toa, virou a skill nº1 que recrutador procura num AI engineer em 2026.

Atenção é orçamento, não dádiva — o tal do "context rot"

Aqui está o ponto que quebra a intuição de muita gente: jogar mais informação no prompt não melhora a resposta. Frequentemente, piora.

O motivo é arquitetural. Um transformer cria relações entre todos os pares de tokens — para n tokens, são n² relações. Conforme a janela enche, a capacidade do modelo de recuperar a informação certa com precisão cai. A Anthropic chama isso de "context rot" e descreve a degradação não como um penhasco abrupto, mas como um gradiente: cada token novo gasta um pedaço de um orçamento de atenção finito (Anthropic).

E não é teoria. A Chroma testou 18 modelos de fronteira e mediu o efeito: todos pioram conforme o input cresce, de forma não-uniforme e às vezes surpreendente (Chroma Research). O detalhe mais contraintuitivo do estudo: os modelos foram melhor em "palheiros" embaralhados do que em documentos logicamente coerentes. Ou seja — em vários casos, dar mais contexto bem-estruturado piorou o resultado.

Traduzindo pro seu produto: a janela de contexto não é espaço de armazenamento que você preenche até a borda. É um recurso que você gasta. Cada token irrelevante que você empurra pra dentro é sinal competindo com ruído — e o ruído ganha mais vezes do que você imagina.

O que entra no prompt (e como decidir)

A pergunta certa não é "o que eu posso colocar?". É "qual a menor quantidade de informação de alto sinal que faz o modelo se comportar como eu preciso?". Componente por componente:

System prompt — na altitude certa. O erro dos dois extremos: ou você crava lógica rígida e frágil (if cliente == X faça Y), tentando antecipar todo caso, ou despeja orientação vaga demais ("seja útil"). A Anthropic chama o ponto bom de "right altitude": específico o suficiente para guiar comportamento, flexível o suficiente para servir de heurística forte. Instrução, não roteiro.

Ferramentas — poucas e sem sobreposição. Toda definição de tool ocupa contexto e ainda força o modelo a escolher. Tool sets inchados, que cobrem funcionalidade demais e se sobrepõem, são uma falha comum (Anthropic). Se duas ferramentas fazem quase a mesma coisa, o modelo hesita. Funda em uma.

Exemplos (few-shot) — curados, não empilhados. Exemplos valem mais que descrição abstrata. Mas a tentação é colar uma lista enorme de casos extremos achando que cobre tudo. O caminho é o oposto: poucos exemplos diversos e canônicos, que mostram o comportamento típico. Qualidade de amostra, não volume.

Histórico — o que serve à tarefa atual. Nem toda conversa anterior precisa estar inteira no prompt. Decisões tomadas e bugs em aberto, sim. Dez chamadas de ferramenta que já deram certo, não.

Dados recuperados — just-in-time, não tudo de uma vez. Aqui mora o vício do RAG mal feito: recuperar 20 chunks "por garantia" e despejar todos. Recupere o que a pergunta atual pede, no momento em que pede. Contexto é puxado sob demanda — não pré-carregado por medo.

O que NÃO entra

Mais curto e mais importante. Corte sem dó:

• Documentação inteira "por precaução". Se o modelo não vai usar agora, é ruído. Recupere o trecho, não o manual.
• Histórico de conversa que não muda a decisão atual. Saída de ferramenta já consumida, passos já concluídos, confirmações redundantes.
• Exemplos repetidos que ilustram o mesmo ponto. Cinco variações do mesmo caso não ensinam mais que uma boa.
• Instruções para casos que nunca vão acontecer naquele fluxo. Cada if hipotético no system prompt é atenção gasta à toa.
• Dados de cliente sem mascarar. Esse não é só questão de contexto — é segurança. Não jogue PII crua no prompt.

A regra mental é uma só: na dúvida, fica de fora. É mais barato adicionar um pedaço de contexto que faltou do que recuperar a precisão que você perdeu afogando o modelo.

Tarefas longas: compaction, notas e sub-agentes

E quando a tarefa é grande demais pra caber em uma janela, por mais enxuto que você seja? Aí entram três técnicas que a Anthropic descreve para agentes de horizonte longo (Anthropic):

• Compaction. Perto do limite da janela, resuma a conversa preservando o que importa — decisões de arquitetura, bugs não resolvidos — e descarte saída de ferramenta redundante. Você comprime o passado em vez de carregá-lo inteiro.
• Notas estruturadas (note-taking). O agente escreve notas persistidas fora da janela de contexto e recupera depois. Memória de longo prazo com overhead mínimo no prompt.
• Sub-agentes. Em vez de um agente segurar tudo, agentes especializados atacam subtarefas e devolvem só um resumo condensado — na faixa de 1.000 a 2.000 tokens — em vez do trabalho bruto inteiro. É o padrão pesquisador/executor/validador que destrinchamos em subagentes na prática.

Todas as três são a mesma ideia aplicada de jeitos diferentes: manter o sinal alto e o token count baixo.

Limitações e pontos de atenção

Engenharia de contexto não é bala de prata, e tratar como tal é o próximo erro depois de tratar contexto como balde.

• Cortar demais também quebra. Tirar contexto que o modelo precisava gera alucinação por falta de base. O alvo é o suficiente, não o mínimo absoluto. Calibragem, não dieta cega.
• A janela máxima não é a janela útil. Um modelo anunciar 1M de tokens não significa que ele raciocina bem com 1M de tokens preenchidos. O context rot vale mesmo dentro do limite suportado.
• Isso muda com cada modelo. O ponto ótimo de contexto varia por modelo e por tarefa. Tem que medir — com avaliação real, não no olhômetro.
• Compactar perde coisa. Todo resumo descarta informação. Se o resumo comer uma decisão crítica, o agente vai repetir um erro já resolvido. Defina o que é sagrado antes de compactar.

FAQ rápido

Engenharia de contexto substitui engenharia de prompt? Não — engloba. Escrever um bom system prompt continua sendo engenharia de contexto. A diferença é que agora isso é um componente de uma decisão maior: o que, no total, ocupa a janela em cada chamada.

Se o modelo tem janela enorme, ainda preciso me preocupar com isso? Sim, e mais. A pesquisa da Chroma mostrou os 18 modelos testados piorando com input maior. Janela grande aumenta o teto, não a qualidade — encher até a borda é justamente onde a precisão cai.

Qual a diferença prática entre RAG e engenharia de contexto? RAG é uma das fontes que abastecem o contexto. Engenharia de contexto é a decisão de o que daquilo recuperado realmente entra no prompt — e quando. RAG sem curadoria é só mais uma forma de entupir a janela.

Por onde começo no meu agente? Meça quanto da sua janela é sinal e quanto é ruído. Corte saída de ferramenta redundante, encurte o system prompt para heurística, e troque "recuperar tudo" por "recuperar o que a etapa pede". Depois avalie se a qualidade subiu.

Conclusão

O recurso mais escasso de um agente não é o modelo. É a janela de contexto. E a habilidade que separa quem brinca de quem entrega produto é saber administrar esse orçamento: colocar o sinal certo, cortar o ruído, e resistir à tentação de "mandar tudo por garantia".

O próximo passo dessa história é ainda mais arquitetura. Compaction, memória externa, sub-agentes, recuperação just-in-time — montar um agente que aguenta produção é cada vez menos sobre o prompt e mais sobre o sistema em volta dele. É exatamente esse tipo de decisão de arquitetura — o que o agente carrega, o que ele busca, o que ele esquece — que a gente coloca na mesa, com código rodando, no Workshop Arquitetando Soluções de IA.

Seu agente não precisa de mais contexto. Precisa do contexto certo. Decidir o que fica de fora é metade da engenharia.