O que é context engineering (engenharia de contexto) e como difere de prompt engineering

Context engineering, ou engenharia de contexto, é escolher o que o modelo lê antes de cada resposta. Contexto é tudo o que está na janela do modelo naquele momento: as instruções, as ferramentas que ele pode usar, os exemplos, o histórico da conversa e os dados trazidos de fora. O prompt é uma dessas peças.

A Anthropic descreve a mudança assim: construir com modelos de linguagem está deixando de ser achar as palavras certas para o prompt e passando a responder “que configuração de contexto tem mais chance de gerar o comportamento que queremos?”. Prompt engineering, na definição deles, são os métodos para escrever e organizar as instruções. Context engineering é a curadoria de todo o conjunto de informação que chega ao modelo, inclusive o que não é prompt.

A diferença só aparece quando o sistema deixa de responder uma vez e passa a trabalhar em ciclo. Um agente gera dados a cada volta, e parte deles será útil na próxima. Escolher o que entra, o que fica e o que sai da janela deixa de ser uma tarefa de escrita e vira um trabalho que se repete a cada passo.

A intuição comum é que mais contexto é sempre melhor: se cabe, põe. A fonte diz o contrário. Estudos com testes de agulha no palheiro mostraram o que chamam de context rot: à medida que o número de tokens na janela cresce, a capacidade do modelo de recuperar com precisão a informação dentro dela diminui. Alguns modelos degradam mais devagar que outros, mas o efeito aparece em todos.

Por isso a Anthropic trata o contexto como recurso finito, com retorno decrescente. Assim como as pessoas têm memória de trabalho limitada, o modelo tem um “orçamento de atenção”, e cada token novo gasta uma parte dele. O princípio que a fonte tira daí é o centro do assunto: encontrar o menor conjunto possível de tokens de alto sinal que maximize a chance do resultado desejado. Menor não quer dizer curto: quer dizer sem o que não ajuda.

Pergunte o que aconteceria se a premissa mudasse: e se a janela fosse infinita e de graça? O problema dos tokens desapareceria, e a fonte mesmo diz que não é isso que se espera, porque janelas de qualquer tamanho continuam sujeitas à poluição de contexto. Mas há uma segunda camada que nenhuma janela resolve: o que nunca esteve escrito em lugar nenhum.

Numa empresa, grande parte do que faz um processo funcionar não está em documento, em sistema nem em histórico. Está na cabeça de quem opera: a exceção que todo mundo conhece, o cliente que precisa de tratamento diferente, a regra que mudou numa reunião e nunca foi atualizada. Um agente com a melhor engenharia de contexto do mundo lê o que existe, com precisão e sem desperdício, e age com confiança sobre um retrato incompleto.

Daí a inversão. A pergunta de quem constrói costuma ser “como faço caber mais contexto?”. A pergunta que decide se o agente funciona é outra: quem na empresa é dono de cada pedaço do contexto, e onde fica o que só as pessoas sabem? Context engineering, numa empresa, começa antes do modelo: começa em olhar o processo como ele acontece e escrever o que sempre foi dito de boca. É por isso que trabalhar dentro da operação, como faz um engenheiro implantado no cliente, rende mais que afinar texto à distância.

A fonte percorre cada peça da janela e dá uma regra para cada uma.

1. 01

   Instruções na altitude certa

   Os dois erros comuns são o prompt cheio de regras “se isso, então aquilo”, que fica frágil e caro de manter, e o prompt vago, que supõe um contexto que o modelo não tem. A recomendação é começar com um prompt mínimo no melhor modelo disponível, testar, e acrescentar instruções e exemplos conforme as falhas aparecem. Mínimo não significa curto.

2. 02

   Ferramentas enxutas e sem sobreposição

   Um dos defeitos mais frequentes que a fonte relata é o conjunto de ferramentas inchado, com decisões ambíguas sobre qual usar. Se uma pessoa que engenha não consegue dizer qual ferramenta serve a cada situação, não se pode esperar que o agente consiga.

3. 03

   Poucos exemplos, bem escolhidos

   Exemplos continuam sendo uma boa prática, mas despejar uma lista de casos de borda no prompt não é recomendado. O conselho é curar um conjunto pequeno de exemplos diversos e canônicos, que mostrem o comportamento esperado.

4. 04

   Dados trazidos na hora, não todos de uma vez

   Em vez de carregar tudo antes, o agente guarda referências leves (caminhos de arquivo, consultas salvas, links) e carrega o dado quando precisa, por ferramentas. A abordagem é mais lenta que ter tudo pré-calculado, e exige boas ferramentas de navegação. A fonte cita uma versão híbrida, em que parte vem de antemão por velocidade e o resto o agente explora, como a mais adequada a conteúdo menos dinâmico, como o jurídico e o financeiro. Segundo a fonte, muitas equipes já combinam a busca prévia por embeddings com essa busca na hora.

Para a busca prévia, vale ler o guia de RAG; para as ferramentas que o agente chama, o de MCP, cujas definições também ocupam a janela.

Para trabalhos que passam de dezenas de minutos até horas, como migrar um código grande ou fazer uma pesquisa extensa, a fonte descreve três técnicas. Esperar por janelas maiores não é a resposta que eles dão.

Compactar, anotar ou dividir

1. 01

   Compactação

   Resumir uma conversa que se aproxima do limite e recomeçar uma janela nova com o resumo. A arte está em escolher o que manter: um corte agressivo demais perde um detalhe cuja importância só aparece depois. A forma mais leve e segura, segundo a fonte, é limpar o resultado bruto de ferramentas já usadas.

2. 02

   Anotação estruturada

   O agente escreve notas num arquivo fora da janela, como uma lista de tarefas ou um NOTES.md, e as lê de volta depois. É memória persistente com pouco custo, e serve a trabalhos com marcos claros.

3. 03

   Subagentes

   Agentes especializados trabalham cada um numa janela limpa, exploram à vontade e devolvem só um resumo condensado (a fonte fala em 1.000 a 2.000 tokens) ao agente principal. Serve a pesquisas em que explorar em paralelo compensa.

A escolha depende da tarefa: compactação para muita conversa de ida e volta, notas para desenvolvimento com marcos, subagentes para análise complexa. O próprio harness do agente é o que decide quando compactar e o que guardar. E há um risco que a conta de tokens não mostra: o que foi resumido passa a ser a verdade do agente. O Insight sobre a IA que não mentiu, só bateu a meta mostra o que muda quando o agente trabalha sobre o próprio resumo da tarefa, e o texto sobre quem conta os tokens que a empresa paga trata do outro lado do orçamento: cada token na janela também é uma linha na fatura.

Se o resumo ou a nota guardam algo errado, o erro se repete em todos os passos seguintes. Medir se o contexto escolhido produz a resposta certa é trabalho para evals, e o texto das instruções, quando fala em nome da empresa, é o que o Insight sobre o texto que diz ao chatbot o que não falar chama de política da empresa.