Por um tempo, \"engenharia de prompts\" foi o nome que demos à arte de obter bons resultados de grandes modelos de linguagem. Fazia sentido nos primeiros dias. A maioria das pessoas usava interações de uma única vez, e a principal alavanca realmente parecia ser a formulação: perguntar com mais clareza, adicionar um exemplo, restringir o formato, e o modelo se comportava melhor.
Esse enquadramento agora é pequeno demais para o problema real.
Quando um sistema de IA falha em produção, o problema geralmente não é que o modelo precisava de mais uma frase inteligente no prompt do sistema. O problema é que o modelo não viu as informações certas, viu informações irrelevantes demais, viu as informações certas no formato errado, ou não conseguiu carregar o estado correto de uma etapa para a próxima. Em outras palavras, o problema não era apenas o prompt. O problema era o pipeline de contexto inteiro.
É por isso que o termo engenharia de contexto ganhou força. A expressão entrou no debate mainstream de IA em meados de 2025, quando Tobi Lütke e Andrej Karpathy argumentaram que \"engenharia de prompts\" subestimava o trabalho real envolvido na construção de sistemas LLM confiáveis.[1] Mas a disciplina subjacente é mais antiga que o nome. Se você já construiu RAG, chamadas de ferramentas, sistemas de memória, sumarização ou loops de avaliação, já fez partes da engenharia de contexto. O que mudou é que finalmente temos um nome que descreve o trabalho completo.
Se você quiser a imagem mais simples possível, a engenharia de contexto é a camada entre o mundo externo e a memória de trabalho do modelo.
flowchart TD\n U[\"Requisição do usuário\"] --> CE[\"Motor de contexto\"]\n\n I[\"Instruções e políticas\"] --> CE\n R[\"Conhecimento recuperado\"] --> CE\n M[\"Memória e estado salvo\"] --> CE\n T[\"Definições e resultados de ferramentas\"] --> CE\n H[\"Histórico recente da conversa\"] --> CE\n\n CE --> W[\"Janela de contexto do modelo\"]\n W --> L[\"LLM raciocina e age\"]\n L --> O[\"Resposta ou chamada de ferramenta\"]\n O --> S[\"Nova memória, logs e estado\"]\n S --> CEEsse é o jogo inteiro.
O modelo é o motor de raciocínio. O motor de contexto decide sobre o que o modelo pode raciocinar.
Uma razão pela qual o termo ressoa é que ele une vários fios que vinham evoluindo separadamente.
A Geração Aumentada por Recuperação, ou RAG, nos ensinou que os modelos precisam de acesso a conhecimento externo no momento da inferência.[2] O ReAct nos ensinou que raciocínio e ação funcionam melhor quando os modelos podem chamar ferramentas, observar resultados e continuar a partir daí.[3] A pesquisa sobre memória nos ensinou que assistentes de longa duração precisam de estratégias de indexação, recuperação e leitura, em vez de acumulação interminável de transcrições.[4] A avaliação de contexto longo mostrou que simplesmente inserir mais tokens em um modelo não é a mesma coisa que dar a ele uma memória de trabalho melhor.[5][6][7]
Visto dessa forma, a engenharia de contexto não é uma substituição para essas ideias. É o guarda-chuva acima delas.
Esse guarda-chuva importa porque os sistemas de IA modernos não são mais prompts isolados. São sistemas dinâmicos que montam instruções, documentos, dados estruturados, saídas de ferramentas e estado anterior em uma janela de contexto temporária para o próximo passo. A LangChain descreveu isso bem ao definir engenharia de contexto como o trabalho de fornecer as informações e ferramentas certas no formato certo para que o LLM possa plausavelmente completar a tarefa.[8]
A expressão \"plausavelmente completar a tarefa\" está fazendo muito trabalho aí. É o teste certo.
Se um agente falha, a primeira pergunta não deve ser: \"Como faço o prompt ficar mais inteligente?\"
A primeira pergunta deve ser: \"Eu realmente dei ao modelo o que ele precisava para ter sucesso?\"
A engenharia de prompts ainda importa. Ela simplesmente se tornou um subconjunto de uma disciplina maior.
O antigo modelo mental era:
| Engenharia de prompts | Engenharia de contexto |
|---|---|
| Escrever instruções melhores | Construir o ambiente de informação completo |
| Foco em uma única requisição | Foco em sistemas de múltiplas etapas |
| Majoritariamente estático | Dinâmico e com estado |
| Otimizar a formulação | Otimizar seleção, estrutura, memória e ferramentas |
| Melhorar uma única chamada ao modelo | Melhorar o loop inteiro |
Essa distinção fica óbvia no momento em que você constrói um agente.
Suponha que você esteja construindo um agente de suporte para software empresarial. O usuário pergunta: \"Por que nossas requisições de API estão expirando?\"
Se você pensa apenas em termos de prompt, pode melhorar a formulação:
Essas são melhorias válidas. Mas não são suficientes.
As perguntas reais do sistema são mais difíceis:
Isso é engenharia de contexto.
O prompt é apenas um item dentro dela.
Na prática, o contexto inclui tudo que o modelo vê no momento da inferência, não apenas o prompt visível.[8][9]
Isso geralmente significa:
É por isso que a expressão \"preencher a janela de contexto\" se tornou tão central. A janela de contexto não é apenas um lugar onde o texto vai. É a memória de trabalho temporária do modelo. Tudo que entra nela compete por atenção.
E competição é a palavra-chave.
Cada token extra não é apenas informação adicional. É também distração adicional.
Um dos equívocos mais comuns no mercado atual de IA é que janelas de contexto maiores tornaram a engenharia de contexto menos importante.
A pesquisa aponta na direção oposta.
Lost in the Middle mostrou que os modelos frequentemente usam contextos longos de forma desigual, tendo melhor desempenho quando informações relevantes aparecem perto do início ou do fim, e pior quando informações importantes ficam no meio.[5] O estudo de RAG de contexto longo da Databricks descobriu que, embora adicionar mais documentos recuperados possa ajudar, apenas um pequeno número de modelos de ponta manteve forte desempenho acima de 64k tokens.[6] O relatório Context Rot da Chroma foi ainda mais longe: mesmo tarefas simples se tornam menos confiáveis à medida que o comprimento da entrada cresce, especialmente quando ambiguidade e distrações são introduzidas.[7]
Essa é a parte que muitas equipes aprendem da maneira difícil.
Janelas maiores não eliminam a necessidade de escolher. Elas tornam o custo de más escolhas menos óbvio no início e mais doloroso depois.
Um prompt longo pode falhar de pelo menos quatro maneiras diferentes:
É por isso que a engenharia de contexto não é sobre maximizar tokens. É sobre maximizar a densidade de sinal dentro da janela de contexto.
É aqui que uma das melhores ideias recentes entra em cena.
Jason Liu argumentou que o próximo passo após o RAG clássico baseado em chunks é parar de pensar apenas em \"as passagens mais similares\" e começar a pensar sobre a forma do espaço de busca.[10] Seu enquadramento é especialmente útil porque mapeia uma progressão pela qual muitas equipes já estão passando:
Os três primeiros são melhorias no que é recuperado.
O quarto é mais interessante. Ele melhora o que o agente aprende sobre o próprio corpus.
As facetas dão ao modelo algo como visão periférica. Em vez de retornar apenas os poucos chunks mais relevantes, o sistema também pode retornar metadados agregados:
Isso importa porque a busca por similaridade é tendenciosa em direção ao que é mais fácil de corresponder, não necessariamente ao que é mais importante inspecionar.[10] Um sistema de recuperação pode super-surfaçar incidentes resolvidos bem documentados e sub-surfaçar incidentes esparsos ainda abertos. Uma busca jurídica pode super-surfaçar contratos assinados e esconder os não assinados que realmente precisam de atenção. As facetas ajudam o agente a ver não apenas \"o que correspondeu\", mas \"o que mais existe por perto\".
Essa é uma mudança conceitual importante.
RAG era principalmente sobre recuperação.
A engenharia de contexto é cada vez mais sobre navegação.
A maneira mais fácil de tornar a engenharia de contexto concreta é dividi-la nos trabalhos reais que ela realiza.
O primeiro trabalho é decidir o que merece entrar na janela.
Isso inclui recuperação, classificação, filtragem, escolha de fonte e verificações de atualidade. Parece óbvio, mas ainda é onde uma enorme quantidade de qualidade é ganha ou perdida. Benchmarks como o BRIGHT mostram que a recuperação realista é muito mais difícil do que a correspondência semântica superficial sugere.[11] Se a qualidade da sua recuperação é fraca, nenhuma quantidade de polimento de prompt downstream salvará completamente o resultado.
Seleção não é apenas \"encontrar chunks relevantes\". É:
Bons sistemas frequentemente recuperam menos do que sistemas ingênuos, mas recuperam de forma mais intencional.
O segundo trabalho é decidir como o contexto escolhido é representado.
A mesma informação pode ser útil ou inútil dependendo da formatação. A orientação de uso de ferramentas da Anthropic é explícita sobre isso: descrições e interfaces de ferramentas moldam fortemente o comportamento do modelo.[9] A orientação de prompting de contexto longo faz recomendações similares para marcação XML, rotulagem de fontes e seções de documentos claramente separadas.[12]
Na prática, estrutura significa:
Um resultado curto e bem rotulado frequentemente supera um blob JSON gigante.
O terceiro trabalho é reduzir o contexto sem destruir o que importa.
É aqui que muitos sistemas de agentes ficam muito melhores ou muito piores.
Compressão pode significar:
A documentação de cache de prompts da OpenAI mostra que a ordem do prompt importa economicamente além de cognitivamente: prefixos compartilhados estáticos são mais baratos e rápidos quando colocados no início porque os acertos de cache dependem da reutilização exata do prefixo.[13] O trabalho mais recente da OpenAI na API Responses sobre compactação leva a mesma ideia adiante, tratando o histórico de agentes de longa duração como algo que deve ser comprimido em uma representação mais eficiente em tokens antes que a janela se esgote.[14]
Compressão não é opcional. A única questão é se você a faz deliberadamente ou deixa a janela de contexto degradar por conta própria.
O quarto trabalho é decidir o que deve persistir além do turno atual.
É aqui que muitas equipes cometem o mesmo erro: confundem memória com retenção de transcrição.
Mas boa memória não é \"guardar tudo para sempre\". O LongMemEval enquadra a memória de longo prazo como um problema de três estágios: indexação, recuperação e leitura.[4] Essa é a maneira certa de pensar sobre isso. Um sistema de memória deve ajudar o modelo a recuperar o fato anterior certo no momento certo, não afogá-lo no passado completo.
Isso leva a uma distinção útil:
Se tudo fica na memória de trabalho, o modelo se distrai.
Se tudo é empurrado para fora, o modelo perde continuidade.
A engenharia de contexto decide o que pertence a cada camada.
O quinto trabalho é tornar as ferramentas legíveis para o modelo.
Essa é uma parte subestimada da disciplina. Uma superfície de ferramenta não é apenas design de API de software. É também design de contexto.
O modelo precisa entender:
É por isso que as descrições de ferramentas importam tanto.[9] É também por isso que a ênfase de Jason Liu nos resultados de ferramentas é importante.[10] A saída de uma ferramenta não apenas responde à consulta atual. Ela ensina o agente como pensar sobre a próxima consulta.
Quando a superfície de ferramentas se torna padronizada por meio de um protocolo como o MCP, isso se torna ainda mais importante. O MCP facilita a conexão de ferramentas, recursos e prompts a aplicações LLM, mas não decide quais informações devem ser surfaçadas, como devem ser filtradas ou quanto delas deve ser injetado na próxima chamada ao modelo.[15] O protocolo é o encanamento. A engenharia de contexto ainda é o ofício.
O sexto trabalho é decidir quando não compartilhar contexto.
Essa é uma das maiores diferenças entre demos de brinquedo e agentes em produção.
Às vezes a resposta certa não é um prompt compartilhado maior. São múltiplos prompts menores com escopos isolados.
O sistema de pesquisa multi-agente da Anthropic é um exemplo forte.[16] Seus subagentes rodam em paralelo com janelas de contexto separadas, o que os ajuda a explorar diferentes ramificações de um problema sem contaminar uns aos outros com cada detalhe intermediário. A LangChain descreve um padrão similar sob \"isolar\": às vezes a melhor maneira de melhorar a confiabilidade do agente é dividir contextos em vez de acumulá-los.[17]
Isso importa porque contexto compartilhado tem um custo oculto. Ele cria dependência de caminho. Um único ramo ruim pode influenciar o próximo passo, e o próximo, e o próximo.
Isolamento é uma forma de limitar o raio de explosão.
Em 2025, a engenharia de contexto era principalmente um nome útil para um problema que as pessoas já sentiam. Em 2026, está começando a se solidificar em uma arquitetura.
A primeira grande mudança é que os construtores estão movendo o estado duradouro para fora da janela de contexto bruta. A edição de contexto e a ferramenta de memória da Anthropic separam explicitamente o que fica ativo na janela de trabalho do que deve persistir entre sessões.[18] O cookbook de janeiro de 2026 da OpenAI sobre personalização faz o mesmo movimento de uma forma diferente: objetos de estado estruturados que persistem entre execuções e são deliberadamente injetados de volta na memória de trabalho no início de cada execução.[19] A API Responses da OpenAI então leva isso um passo adiante com compactação nativa, para que loops de agentes de longa duração não exijam que cada equipe construa um subsistema de sumarização personalizado do zero.[14]
Os Managed Agents da Anthropic tornam o padrão subjacente incomumente explícito: a sessão não é a janela de contexto do modelo.[20] Essa é uma ideia crítica de 2026. A janela é memória de trabalho transitória. O log de sessão é o objeto duradouro. O harness decide como fatiar, compactar e reidratar esse contexto duradouro de volta para a próxima chamada ao modelo.
A segunda mudança é que a recuperação está se tornando mais just in time e mais nativa de interface. Em vez de pré-carregar cada token possivelmente relevante, as equipes estão dando aos agentes superfícies de recuperação que eles já sabem como operar. O ChromaFs da Mintlify é um bom exemplo: em vez de inicializar um sandbox completo para recuperação de documentação, ele apresenta os docs como um sistema de arquivos virtual navegável com ls, cat e grep, reduzindo a criação de sessão p90 de cerca de 46 segundos para cerca de 100 milissegundos.[21] O AgentFS da Turso leva a mesma intuição em direção à execução geral de agentes: uma abstração de sistema de arquivos copy-on-write com armazenamento portátil em arquivo único e auditoria integrada.[22]
A terceira mudança é que os grafos de contexto estão se tornando uma direção de implementação, não apenas uma metáfora. A tese da Foundation Capital tornou o termo visível, mas a afirmação mais forte é arquitetural: quando os agentes estão no caminho de execução, eles podem capturar rastros de decisão como artefatos duradouros, não apenas emitir saídas finais.[26][27] Sistemas de código aberto como o Graphiti e plataformas comerciais como o Zep operacionalizam isso como grafos de contexto temporais com janelas de validade, episódios de proveniência e recuperação híbrida entre semântica, palavras-chave e estrutura de grafo.[23] O TrustGraph adota uma abordagem relacionada, tratando o contexto como um artefato versionado: grafo, embeddings, evidências e políticas agrupados em \"núcleos de contexto\" portáteis que podem ser promovidos ou revertidos como saídas de build.[24][25]
A quarta mudança é que a engenharia de contexto agora é visível na prática real de software, não apenas em blogs de plataformas. O artigo MSR de 2026 sobre engenharia de contexto em software de código aberto estudou 466 repositórios e descobriu que arquivos de contexto de IA como AGENTS.md estão se espalhando, mas ainda sem estrutura de conteúdo estável.[28] Isso importa porque marca uma mudança da teoria para artefatos operacionais. O contexto não é mais apenas algo inferido em tempo de execução. Está sendo criado, versionado, revisado e minerado como parte do ciclo de vida do software.
Se você quiser o modelo mental de 2026 em uma imagem, ele se parece com isso:
flowchart LR\n E[\"Log de sessão / eventos\"] --> A[\"Montador de contexto\"]\n F[\"Arquivos, docs e ferramentas\"] --> A\n G[\"Grafo de contexto / memória\"] --> A\n P[\"Políticas e AGENTS.md\"] --> A\n\n A --> W[\"Janela de contexto de trabalho\"]\n W --> X[\"Ação do agente\"]\n\n X --> E\n X --> GEssa é uma arquitetura muito diferente de \"prompt + busca vetorial\".
Uma razão pela qual essa conversa fica confusa é que as pessoas usam engenharia de contexto e grafo de contexto como se significassem a mesma coisa. Não significam.
Engenharia de contexto é a disciplina mais ampla. É o trabalho de decidir o que vai para a próxima janela de contexto, o que fica de fora, o que é comprimido e o que é recuperado sob demanda.
Um grafo de contexto é um possível substrato de memória de longo prazo dentro desse sistema maior.
Essa distinção importa porque nem todo agente útil precisa de um grafo de contexto. Um assistente de documentação sobre conteúdo majoritariamente estático pode precisar de boa recuperação, design de ferramentas e compactação, mas não de um grafo. Um agente de codificação pode chegar surpreendentemente longe com instruções de repositório, um log de sessão duradouro e uma abstração de sistema de arquivos.[20][21][22][28]
Os grafos de contexto se tornam convincentes quando o problema tem quatro características:
É por isso que a melhor definição de um grafo de contexto, na minha visão, não é \"um banco de dados de grafo para IA\". É uma representação duradoura de precedente.
É também por isso que os rastros de decisão importam tanto. O enquadramento da Foundation Capital é útil aqui: regras dizem ao agente o que deve acontecer em geral; rastros de decisão dizem o que aconteceu em um caso específico, sob restrições reais, com exceções reais.[26] Uma vez que esses rastros são vinculados entre entidades e tempo, você obtém algo muito mais valioso do que memória genérica. Você obtém julgamento pesquisável.
Se eu estivesse construindo uma stack séria de engenharia de contexto hoje, não começaria pelo grafo. Começaria pelas interfaces e regras de promoção.
Cada ação, resultado de ferramenta, observação e artefato intermediário importante deve pousar em um log de sessão append-only ou armazenamento de eventos. Esse é o seu objeto de contexto recuperável.[14][20]
Não confunda a janela de contexto ativa com a fonte da verdade.
A janela é para raciocínio.
A sessão é para recuperação, replay, depuração e reidratação seletiva.
O montador deve gerenciar explicitamente:
Essa é a camada que decide o que o modelo vê agora. Deve ser observável, testável e barato de mudar.[18][19][14]
Dê ao modelo handles leves primeiro: caminhos de arquivo, IDs de objetos, URLs, templates de consulta, IDs de tickets, IDs de incidentes. Então deixe-o puxar detalhes apenas quando necessário.[9][18][21]
É aqui que sistemas de arquivos, ferramentas MCP, APIs de busca e consultas estruturadas se tornam mais valiosos do que dumps gigantes de top-K.
Nem tudo deve se tornar memória.
Eu promoveria quatro classes de artefatos:
Todo o resto deve ficar no log de sessão até provar que merece promoção.
Essa é a parte que muitas equipes invertem.
O grafo não deve ser sua transcrição bruta em forma de grafo. Deve ser a camada curada que fica acima das sessões e abaixo da montagem em tempo real:
Se você pular a etapa de promoção, o grafo se torna um depósito de lixo.
Se você acertar a promoção, o grafo se torna a memória de como a organização realmente raciocina.[23][26]
Em 2026, uma das ideias mais promissoras é tratar o contexto como um artefato versionado. Em projetos de software, isso aparece como AGENTS.md e outros arquivos de contexto específicos do repositório.[28] Em sistemas nativos de grafo, aparece como núcleos de contexto: pacotes portáteis de ontologia, estrutura de grafo, embeddings, proveniência e política de recuperação.[24][25]
Isso importa porque mudanças de contexto precisam da mesma disciplina operacional que mudanças de código:
Uma vez que o contexto se torna um artefato, ele se torna governável.
Você precisa de ambas:
Essas não são a mesma coisa.
Quero saber:
Se você não consegue responder a essas perguntas, ainda está depurando prompts no escuro.
Se você está tentando avaliar onde seu próprio sistema se encontra, este modelo de maturidade é mais útil do que definições abstratas.
Você tem um prompt de sistema, uma mensagem do usuário e talvez alguns exemplos.
Isso pode funcionar surpreendentemente bem para tarefas estreitas. Quebra rapidamente quando a tarefa requer conhecimento atualizado, persistência ou ferramentas.
Você adiciona documentos em tempo de execução.
É aqui que muitas equipes param. É também onde muitas equipes começam a ver as limitações de chunking ingênuo, classificação e inchaço de contexto.
Você agora gerencia histórico, resultados de ferramentas, memória e formatação intencionalmente.
Esse é o primeiro nível onde \"engenharia de contexto\" se torna um termo útil, porque o sistema não é mais apenas prompt mais recuperação. Está montando múltiplas formas de contexto dinamicamente.
O sistema muda como constrói o contexto com base na tarefa.
Pode:
Neste ponto, a construção de contexto é parte da lógica central da aplicação.
O sistema trata o contexto como uma superfície de engenharia de primeira classe.
Tem:
É para onde os sistemas de produção mais fortes estão caminhando.
Se eu tivesse que reduzir toda a disciplina a uma lista de verificação, seria assim:
Nada disso é glamoroso. É exatamente por isso que importa.
A engenharia de prompts se tornou popular porque soava como um atalho.
A engenharia de contexto importa porque descreve o trabalho real.
O centro de gravidade da IA está se movendo.
A questão de fronteira costumava ser: Quão inteligente é o modelo?
A questão aplicada é cada vez mais: O que o modelo consegue ver antes de ter que agir?
Esse é um problema de engenharia diferente. É menos sobre prompts únicos e mais sobre design de sistemas. Menos sobre formulação e mais sobre fluxo de informação. Menos sobre qualidade de saída de uma única vez e mais sobre se um agente consegue se manter confiável ao longo do tempo.
É por isso que a engenharia de contexto vai continuar crescendo como disciplina. Quanto melhores os modelos ficam, mais as falhas restantes parecem falhas de contexto. Estado ausente. Ferramenta errada. Recuperação ruim. Histórico inchado. Formatação ruim. Evidências conflitantes. Memória fraca. Loops ilimitados.
A ironia é que isso faz os sistemas de IA parecerem mais com software clássico, não menos. Estamos de volta a construir pipelines, interfaces, máquinas de estado, hierarquias de memória, caches e camadas de observabilidade. A novidade é que todas essas peças agora existem a serviço de um motor de raciocínio probabilístico.
O nome pode ser novo. A direção não é.
Sistemas de IA confiáveis serão construídos por equipes que tratam o contexto como uma superfície de produto de primeira classe.
Todos os outros continuarão chamando o modelo de instável.
Referências:
[1] Simon Willison. (2025, 27 de junho). Context engineering.
[2] Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.
[3] Yao, S. et al. (2023). ReAct: Synergizing Reasoning and Acting in Language Models.
[4] Wu, D. et al. (2025). LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory.
[5] Liu, N. F. et al. (2023). Lost in the Middle: How Language Models Use Long Contexts.
[6] Leng, Q. et al. (2024). Long Context RAG Performance of Large Language Models.
[8] LangChain. (2025, 23 de junho). The rise of \"context engineering\".
[9] Anthropic. How to implement tool use.
[10] Jason Liu. (2025, 27 de agosto). Beyond Chunks: Why Context Engineering is the Future of RAG.
[12] Anthropic. Long context prompting tips.
[15] Model Context Protocol. What is the Model Context Protocol (MCP)?
[16] Anthropic. (2025, 13 de junho). How we built our multi-agent research system.
[17] LangChain. (2025, 2 de julho). Context Engineering.
[18] Anthropic. (2025, 29 de setembro). Managing context on the Claude Developer Platform.
[20] Anthropic. Scaling Managed Agents: Decoupling the brain from the hands.
[21] Mintlify. (2026, 24 de março). How we built a virtual filesystem for our Assistant.
[22] Turso. AgentFS.
[23] Zep. Graphiti: Build Real-Time Knowledge Graphs for AI Agents.
[24] TrustGraph. The context development platform.
[25] TrustGraph. Working with Context Cores.
[26] Gupta, J., and Garg, A. (2025, 22 de dezembro). AI's trillion-dollar opportunity: Context graphs.
[27] Garg, A. (2026, 16 de janeiro). Why context graphs are the missing layer for AI.
", "source_hash": "sha256:352e42d5b8ff71176c26e2e3f9853217033b811bae4f0beaef2cc91e2401caa9", "model": "claude-sonnet-4-6", "generated_at": "2026-04-23T20:55:21.848050+00:00" }