Por um tempo, prompt engineering foi o nome que demos à arte de obter bons resultados de large language models. Fazia sentido nos primórdios. A maioria das pessoas usava interações one-shot, e a alavanca principal realmente parecia ser a redação: perguntar de forma mais clara, adicionar um exemplo, restringir o formato, e o modelo se comportava melhor.
\nEssa moldura agora é pequena demais para o problema real.
\nQuando um sistema de IA falha em produção, o problema geralmente não é que o modelo precisava de mais uma frase inteligente no system prompt. O problema é que o modelo não viu a informação certa, viu informação irrelevante demais, viu a informação certa no formato errado, ou não conseguiu carregar o estado certo de uma etapa para a seguinte. Em outras palavras, o problema não era apenas o prompt. O problema era o context pipeline inteiro.
\nÉ por isso que o termo context engineering pegou. A frase entrou na discussão mainstream de IA em meados de 2025, quando Tobi Lütke e Andrej Karpathy argumentaram que prompt engineering subestimava o trabalho real envolvido em construir sistemas LLM confiáveis.[1] Mas a disciplina subjacente é mais antiga que o nome. Se você construiu RAG, tool calling, memory systems, summarization ou evaluation loops, você já fez pedaços de context engineering. O que mudou é que finalmente temos um nome que descreve o trabalho inteiro.
\nSe você quer a imagem mais simples possível, context engineering é a camada entre o mundo exterior e a working memory do modelo.
\nflowchart TD\n U[\"User request\"] --> CE[\"Context engine\"]\n\n I[\"Instructions and policies\"] --> CE\n R[\"Retrieved knowledge\"] --> CE\n M[\"Memory and saved state\"] --> CE\n T[\"Tool definitions and results\"] --> CE\n H[\"Recent conversation history\"] --> CE\n\n CE --> W[\"Model context window\"]\n W --> L[\"LLM reasons and acts\"]\n L --> O[\"Answer or tool call\"]\n O --> S[\"New memory, logs, and state\"]\n S --> CE\nEsse é o jogo todo.
\nO modelo é o reasoning engine. O context engine decide sobre o que o modelo pode raciocinar.
\nUma razão pela qual o termo ressoa é que ele une várias linhas que vinham evoluindo separadamente.
\nRetrieval-Augmented Generation, ou RAG, nos ensinou que modelos precisam de acesso a conhecimento externo em inference time.[2] ReAct nos ensinou que reasoning e acting funcionam melhor quando modelos podem chamar tools, observar resultados e continuar a partir daí.[3] Pesquisas sobre memory nos ensinaram que assistentes de longa duração precisam de estratégias de indexing, retrieval e reading em vez de acumulação interminável de transcripts.[4] Long-context evaluation mostrou que simplesmente encher um modelo com mais tokens não é a mesma coisa que dar a ele uma working memory melhor.[5][6][7]
\nVisto assim, context engineering não é um substituto para essas ideias. É o guarda-chuva acima delas.
\nEsse guarda-chuva importa porque sistemas de IA modernos não são mais prompts isolados. São sistemas dinâmicos que montam instructions, documents, structured data, tool outputs e prior state em uma context window temporária para a próxima etapa. A LangChain descreveu isso bem quando definiu context engineering como o trabalho de fornecer a informação e as tools no formato certo para que o LLM possa plausivelmente completar a tarefa.[8]
\nA frase \"plausivelmente completar a tarefa\" está fazendo muito trabalho ali. É o teste certo.
\nSe um agent falha, a primeira pergunta não deve ser: \"Como faço o prompt mais inteligente?\"
\nA primeira pergunta deve ser: \"Eu realmente dei ao modelo o que ele precisava para ter sucesso?\"
\nPrompt engineering ainda importa. Ele apenas se tornou um subconjunto de uma disciplina maior.
\nO modelo mental antigo era:
\n| Prompt engineering | \nContext engineering | \n
|---|---|
| Escrever instructions melhores | \nConstruir o ambiente de informação completo | \n
| Focar em uma única request | \nFocar em sistemas multi-step | \n
| Principalmente static | \nDynamic e stateful | \n
| Otimizar wording | \nOtimizar selection, structure, memory e tools | \n
| Melhorar uma única model call | \nMelhorar o loop inteiro | \n
Essa distinção fica óbvia no momento em que você constrói um agent.
\nSuponha que você esteja construindo um support agent para software enterprise. O usuário pergunta: \"Por que nossas API requests estão dando timeout?\"
\nSe você pensa apenas em termos de prompt, pode melhorar o wording:
\nEssas são melhorias boas. Mas não são suficientes.
\nAs perguntas reais de sistema são mais difíceis:
\nIsso é context engineering.
\nO prompt é um item de linha dentro dele.
\nNa prática, context inclui tudo o que o modelo vê em inference time, não apenas o prompt visível.[8][9]
\nIsso geralmente significa:
\nÉ por isso que a frase \"filling the context window\" se tornou tão central. A context window não é apenas um lugar onde o texto vai. É a working memory temporária do modelo. Tudo o que entra nela compete por atenção.
\nE competição é a palavra-chave.
\nCada token extra não é meramente informação adicional. Também é distração adicional.
\nUm dos equívocos mais comuns no mercado atual de IA é que context windows maiores tornaram o context engineering menos importante.
\nA pesquisa aponta na direção oposta.
\nLost in the Middle mostrou que modelos frequentemente usam long contexts de forma desigual, desempenhando melhor 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 long-context RAG da Databricks descobriu que, embora adicionar mais retrieved documents possa ajudar, apenas um pequeno número de modelos state-of-the-art manteve performance forte acima de 64k tokens.[6] O relatório Context Rot da Chroma foi ainda mais longe: até tarefas simples se tornam menos confiáveis à medida que o input length cresce, especialmente quando ambiguity e distractors são introduzidos.[7]
\nEssa é a parte que muitos times aprendem da maneira mais difícil.
\nJanelas 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.
\nUm prompt longo pode falhar de pelo menos quatro formas diferentes:
\nÉ por isso que context engineering não é sobre maximizar tokens. É sobre maximizar signal density dentro da context window.
\nÉ aqui que uma das melhores ideias recentes entra em cena.
\nJason Liu argumentou que o próximo passo após o RAG clássico baseado em chunks é parar de pensar apenas sobre \"as passagens mais similares\" e começar a pensar sobre a shape of the search space.[10] Sua moldura é especialmente útil porque mapeia uma progressão pela qual muitos times já estão passando:
\nOs três primeiros são melhorias no que é retrieved.
\nO quarto é mais interessante. Melhora o que o agent aprende sobre o corpus em si.
\nFacets dão ao modelo algo como visão periférica. Em vez de retornar apenas os poucos chunks do topo, o sistema também pode retornar aggregated metadata:
\nIsso importa porque similarity search é tendenciosa em relação ao que é mais fácil de combinar, não necessariamente ao que é mais importante inspecionar.[10] Um retrieval system pode expor demais incidentes resolvidos bem documentados e expor de menos incidentes esparsos ainda abertos. Uma busca legal pode expor demais contratos assinados e esconder os não assinados que realmente precisam de atenção. Facets ajudam o agent a ver não apenas \"o que combinou\", mas \"o que mais existe por perto\".
\nEssa é uma mudança conceitual importante.
\nRAG era principalmente sobre retrieval.
\nContext engineering é cada vez mais sobre navigation.
\nA maneira mais fácil de tornar o context engineering concreto é dividi-lo nos trabalhos reais que ele executa.
\nO primeiro trabalho é decidir o que merece entrar na window em primeiro lugar.
\nIsso inclui retrieval, ranking, filtering, source choice e freshness checks. Parece óbvio, mas ainda é onde uma enorme quantidade de qualidade é ganha ou perdida. Benchmarks como BRIGHT mostram que retrieval realista é muito mais difícil do que surface-level semantic matching sugere.[11] Se a sua retrieval quality é fraca, nenhuma quantidade de polimento downstream do prompt vai salvar totalmente o resultado.
\nSelection não é apenas \"encontrar chunks relevantes\". É:
\nBons sistemas frequentemente retrievam menos do que sistemas ingênuos, mas retrievam de forma mais intencional.
\nO segundo trabalho é decidir como o context escolhido é representado.
\nA mesma informação pode ser útil ou inútil dependendo da formatação. A orientação de tool-use da Anthropic é explícita sobre isso: tool descriptions e interfaces moldam fortemente o comportamento do modelo.[9] A orientação de long-context prompting faz recomendações semelhantes para XML tagging, source labeling e seções de documentos claramente separadas.[12]
\nNa prática, structure significa:
\nUm resultado curto e bem rotulado frequentemente supera um grande blob JSON.
\nO terceiro trabalho é reduzir o context sem destruir o que importa.
\nÉ aqui que muitos sistemas de agent ou ficam muito melhores ou muito piores.
\nCompression pode significar:
\nA documentação de prompt caching da OpenAI mostra que a ordem do prompt importa economicamente tanto quanto cognitivamente: static shared prefixes são mais baratos e rápidos quando colocados na frente porque cache hits dependem de reutilização exata do prefixo.[13] O trabalho mais recente da OpenAI na Responses API sobre compaction leva a mesma ideia mais longe ao tratar o histórico de agent de longa duração como algo que deve ser comprimido em uma representação mais eficiente em tokens antes que a window encha.[14]
\nCompression não é opcional. A única questão é se você faz isso deliberadamente ou deixa a context window degradar por conta própria.
\nO quarto trabalho é decidir o que deve persistir além do turn atual.
\nÉ aqui que muitos times cometem o mesmo erro: confundem memory com transcript retention.
\nMas uma boa memory não é \"guardar tudo para sempre\". O LongMemEval enquadra a long-term memory como um problema de três estágios: indexing, retrieval e reading.[4] Essa é a maneira certa de pensar sobre isso. Um memory system deve ajudar o modelo a recuperar o fato anterior certo no momento certo, não afogá-lo no passado completo.
\nIsso leva a uma distinção útil:
\nSe tudo ficar em working memory, o modelo se distrai.
\nSe tudo for expulso, o modelo perde continuidade.
\nO context engineering decide o que pertence a cada camada.
\nO quinto trabalho é tornar as tools legíveis para o modelo.
\nEssa é uma parte subestimada da disciplina. Uma tool surface não é apenas software API design. Também é context design.
\nO modelo precisa entender:
\nÉ por isso que tool descriptions importam tanto.[9] Também é por isso que a ênfase de Jason Liu em tool results é importante.[10] O output de uma tool não responde apenas à query atual. Ensina ao agent como pensar sobre a próxima query.
\nQuando a tool surface se torna padronizada por meio de um protocolo como MCP, isso se torna ainda mais importante. O MCP facilita conectar tools, resources e prompts a aplicações LLM, mas não decide qual informação deve ser surfaced, como deve ser filtrada ou quanto dela deve ser injetado na próxima model call.[15] O protocolo é o plumbing. O context engineering ainda é o craft.
\nO sexto trabalho é decidir quando não compartilhar context.
\nEssa é uma das maiores diferenças entre toy demos e agents de produção.
\nÀs vezes a resposta certa não é um prompt compartilhado maior. São múltiplos prompts menores com escopos isolados.
\nO sistema de pesquisa multi-agent da Anthropic é um exemplo forte.[16] Seus subagents executam em paralelo com context windows separadas, o que ajuda a explorar diferentes branches de um problema sem contaminar uns aos outros com cada detalhe intermediário. A LangChain descreve um padrão similar sob \"isolate\": às vezes a melhor maneira de melhorar a confiabilidade do agent é dividir contexts em vez de acumulá-los.[17]
\nIsso importa porque context compartilhado tem um custo oculto. Cria path dependence. Um único branch ruim pode influenciar a próxima etapa, e a seguinte, e a seguinte.
\nIsolation é uma forma de limitar o blast radius.
\nEm 2025, context engineering era principalmente um nome útil para um problema que as pessoas já sentiam. Em 2026, está começando a se cristalizar em uma arquitetura.
\nA primeira grande mudança é que os builders estão movendo durable state para fora da context window bruta. A ferramenta de context editing e memory da Anthropic separa explicitamente o que fica live na working window do que deve persistir entre sessions.[18] O cookbook de janeiro de 2026 da OpenAI sobre personalization faz o mesmo movimento de uma forma diferente: structured state objects que persistem entre runs e são deliberadamente injetados de volta na working memory no início de cada run.[19] A Responses API da OpenAI então leva isso um passo adiante com compaction nativo, para que loops de agent de longa duração não exijam que cada time construa um subsistema de summarization customizado do zero.[14]
\nO Managed Agents da Anthropic torna o padrão subjacente incomumente explícito: a session não é a context window do modelo.[20] Essa é uma ideia crítica de 2026. A window é working memory transitória. O session log é o durable object. O harness decide como fatiar, compactar e reidratar aquele context durável de volta na próxima model call.
\nA segunda mudança é que o retrieval está se tornando mais just in time e mais interface-native. Em vez de front-loading todo token possivelmente relevante, os times estão dando aos agents retrieval surfaces que eles já sabem operar. O ChromaFs da Mintlify é um bom exemplo: em vez de inicializar um sandbox completo para retrieval de documentação, ele apresenta docs como um virtual filesystem navegável com ls, cat e grep, reduzindo a criação de session p90 de cerca de 46 segundos para cerca de 100 milissegundos.[21] O AgentFS da Turso leva a mesma intuição para a execução geral de agent: uma abstração de filesystem copy-on-write com armazenamento single-file portátil e auditing embutido.[22]
A terceira mudança é que context graphs 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 agents ficam no execution path, eles podem capturar decision traces como artifacts duráveis, não apenas emitir outputs finais.[26][27] Sistemas open-source como Graphiti e plataformas comerciais como Zep operacionalizam isso como context graphs temporais com validity windows, provenance episodes e hybrid retrieval entre semantics, keywords e graph structure.[23] O TrustGraph adota uma abordagem relacionada ao tratar o context como um artifact versionado: graph, embeddings, evidence e policies agrupados em \"context cores\" portáteis que podem ser promovidos ou revertidos como build outputs.[24][25]
\nA quarta mudança é que o context engineering agora é visível na prática real de software, não apenas em blogs de plataforma. O artigo de 2026 da MSR sobre context engineering em open-source software estudou 466 repositórios e descobriu que arquivos de context de IA como AGENTS.md estão se espalhando, mas ainda sem uma estrutura de conteúdo estável.[28] Isso importa porque marca uma mudança da teoria para artifacts operacionais. O context não é mais apenas algo inferido em runtime. Está sendo autorado, versionado, revisado e minerado como parte do ciclo de vida do software.
Se você quer o modelo mental de 2026 em uma imagem, ele se parece com isso:
\nflowchart LR\n E[\"Session log / events\"] --> A[\"Context assembler\"]\n F[\"Files, docs, and tools\"] --> A\n G[\"Context graph / memory\"] --> A\n P[\"Policies and AGENTS.md\"] --> A\n\n A --> W[\"Working context window\"]\n W --> X[\"Agent action\"]\n\n X --> E\n X --> G\nEssa é uma arquitetura muito diferente de \"prompt + vector search\".
\nUma razão pela qual essa conversa fica confusa é que as pessoas usam context engineering e context graph como se significassem a mesma coisa. Não significam.
\nContext engineering é a disciplina mais ampla. É o trabalho de decidir o que entra na próxima context window, o que fica de fora, o que é comprimido e o que é retrieved sob demanda.
\nUm context graph é um possível substrato de long-term memory dentro desse sistema maior.
\nEssa distinção importa porque nem todo agent útil precisa de um context graph. Um assistente de documentação sobre conteúdo principalmente estático pode precisar de bom retrieval, tool design e compaction, mas não de um graph. Um agent de coding pode ir surpreendentemente longe com repository instructions, um session log durável e uma abstração de filesystem.[20][21][22][28]
\nContext graphs se tornam convincentes quando o problema tem quatro características:
\nÉ por isso que a melhor definição de um context graph, na minha opinião, não é \"um banco de dados em graph para IA\". É uma representação durável de precedent.
\nÉ por isso também que decision traces importam tanto. O framing da Foundation Capital é útil aqui: rules dizem ao agent o que deve acontecer em geral; decision traces dizem o que aconteceu em um caso específico, sob constraints reais, com exceções reais.[26] Uma vez que esses traces são vinculados entre entities e tempo, você obtém algo muito mais valioso do que memory genérica. Você obtém searchable judgment.
\nSe eu estivesse construindo uma stack séria de context engineering hoje, eu não começaria com o graph. Começaria com as interfaces e as promotion rules.
\nCada action, tool result, observation e artifact intermediário importante devem aterrissar em um session log ou event store append-only. Esse é seu recoverable context object.[14][20]
\nNão confunda a context window ativa com a source of truth.
\nA window é para reasoning.
\nA session é para recovery, replay, debugging e reidratação seletiva.
\nO assembler deve gerenciar explicitamente:
\nEssa é a camada que decide o que o modelo vê agora. Ela deve ser observável, testável e barata de mudar.[18][19][14]
\nDê ao modelo lightweight handles primeiro: file paths, object IDs, URLs, query templates, ticket IDs, incident IDs. Depois deixe-o puxar detalhes apenas quando necessário.[9][18][21]
\nÉ aqui que filesystems, MCP tools, search APIs e structured queries se tornam mais valiosos do que grandes dumps top-K.
\nNem tudo deve se tornar memory.
\nEu promoveria quatro classes de artifacts:
\nTodo o resto deve ficar no session log até provar que merece promotion.
\nEssa é a parte que muitos times invertem.
\nO graph não deve ser seu transcript bruto em forma de graph. Deve ser a camada curada que fica acima de sessions e abaixo da assembly em tempo real:
\nSe você pular o passo de promotion, o graph se torna um dumping ground.
\nSe você acertar o promotion, o graph se torna a memória de como a organização realmente raciocina.[23][26]
\nAté 2026, uma das ideias mais promissoras é tratar o context como um artifact versionado. Em projetos de software isso aparece como AGENTS.md e outros arquivos de context específicos de repositório.[28] Em sistemas graph-native isso aparece como context cores: pacotes portáteis de ontology, graph structure, embeddings, provenance e retrieval policy.[24][25]
Isso importa porque mudanças de context precisam da mesma disciplina operacional que mudanças de code:
\nUma vez que o context se torna um artifact, ele se torna governável.
\nVocê precisa de ambos:
\nEssas não são a mesma coisa.
\nEu quero saber:
\nSe você não conseguir responder essas perguntas, ainda está debugando prompts no escuro.
\nSe você está tentando avaliar onde seu próprio sistema está, esse modelo de maturidade é mais útil do que definições abstratas.
\nVocê tem um system prompt, uma user message e talvez alguns exemplos.
\nIsso pode funcionar surpreendentemente bem para tarefas de escopo restrito. Quebra rapidamente quando a tarefa requer fresh knowledge, persistence ou tools.
\nVocê adiciona documents em runtime.
\nÉ aqui que muitos times param. Também é onde muitos times começam a ver as limitações de chunking, ranking e context bloat ingênuos.
\nVocê agora gerencia history, tool results, memory e formatting intencionalmente.
\nEsse é o primeiro nível onde \"context engineering\" se torna um termo útil, porque o sistema não é mais apenas prompt mais retrieval. Ele está montando múltiplas formas de context dinamicamente.
\nO sistema muda como ele constrói o context com base na tarefa.
\nEle pode:
\nNesse ponto, a construção de context é parte da lógica central da aplicação.
\nO sistema trata o context como uma engineering surface de primeira classe.
\nEle tem:
\nÉ para onde os sistemas de produção mais fortes estão indo.
\nSe eu tivesse que reduzir toda a disciplina a um checklist, ele se pareceria com isso:
\nNada disso é glamouroso. É exatamente por isso que importa.
\nPrompt engineering se tornou popular porque soava como um atalho.
\nContext engineering importa porque descreve o trabalho real.
\nO centro de gravidade na IA está se movendo.
\nA pergunta de fronteira costumava ser: Quão inteligente é o modelo?
\nA pergunta aplicada é cada vez mais: O que o modelo consegue ver antes de ter que agir?
\nEsse é um problema de engenharia diferente. É menos sobre prompts únicos e mais sobre systems design. Menos sobre phrasing e mais sobre information flow. Menos sobre a qualidade de output one-shot e mais sobre se um agent pode permanecer confiável ao longo do tempo.
\nÉ por isso que context engineering vai continuar crescendo como uma disciplina. Quanto melhores os modelos ficam, mais as falhas restantes parecem context failures. Missing state. Wrong tool. Bad retrieval. Bloated history. Poor formatting. Conflicting evidence. Weak memory. Unbounded loops.
\nA ironia é que isso faz os sistemas de IA parecerem mais com software clássico, não menos. Estamos de volta a construir pipelines, interfaces, state machines, memory hierarchies, caches e observability layers. A novidade é que todas essas peças agora existem a serviço de um probabilistic reasoning engine.
\nO nome pode ser novo. A direção não.
\nSistemas de IA confiáveis serão construídos por times que tratam o context como uma product surface de primeira classe.
\nTodos os outros vão continuar chamando o modelo de flaky.
\nReferências:
\n[1] Simon Willison. (2025, June 27). Context engineering.
\n[2] Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.
\n[3] Yao, S. et al. (2023). ReAct: Synergizing Reasoning and Acting in Language Models.
\n[4] Wu, D. et al. (2025). LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory.
\n[5] Liu, N. F. et al. (2023). Lost in the Middle: How Language Models Use Long Contexts.
\n[6] Leng, Q. et al. (2024). Long Context RAG Performance of Large Language Models.
\n\n[8] LangChain. (2025, June 23). The rise of \"context engineering\".
\n[9] Anthropic. How to implement tool use.
\n[10] Jason Liu. (2025, August 27). Beyond Chunks: Why Context Engineering is the Future of RAG.
\n\n[12] Anthropic. Long context prompting tips.
\n\n\n[15] Model Context Protocol. What is the Model Context Protocol (MCP)?
\n[16] Anthropic. (2025, June 13). How we built our multi-agent research system.
\n[17] LangChain. (2025, July 2). Context Engineering.
\n[18] Anthropic. (2025, September 29). Managing context on the Claude Developer Platform.
\n\n[20] Anthropic. Scaling Managed Agents: Decoupling the brain from the hands.
\n[21] Mintlify. (2026, March 24). How we built a virtual filesystem for our Assistant.
\n[22] Turso. AgentFS.
\n[23] Zep. Graphiti: Build Real-Time Knowledge Graphs for AI Agents.
\n[24] TrustGraph. The context development platform.
\n[25] TrustGraph. Working with Context Cores.
\n[26] Gupta, J., and Garg, A. (2025, December 22). AI's trillion-dollar opportunity: Context graphs.
\n[27] Garg, A. (2026, January 16). Why context graphs are the missing layer for AI.
\n", "source_hash": "sha256:3f3faa38dd809a893509e9f3c2de70a7ec3778cc6cef2fa58967b63bd169d7d9", "model": "moonshotai/kimi-k2.6", "generated_at": "2026-08-07T07:25:53.852075+00:00" }