O que é engenharia de contexto
Engenharia de contexto é a prática de decidir, montar e entregar tudo o que um modelo de IA precisa para executar bem uma tarefa, antes de o modelo rodar. Ela abrange o system prompt, os documentos que você anexa, o que o modelo lembra sobre você, quais ferramentas ele pode chamar e o que já está na conversa. A engenharia de prompt ajusta uma frase. A engenharia de contexto ajusta toda a pilha de entrada.
A definição da Anthropic é a mais apertada em circulação: "the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference" (o conjunto de estratégias para curar e manter o conjunto ótimo de tokens, isto é, de informação, durante a inferência do LLM). O princípio que eles oferecem vale ser memorizado, porque funciona também como teste de que você está fazendo a coisa certa: encontre "the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome" (o menor conjunto possível de tokens de alto sinal que maximize a probabilidade de um resultado desejado). (Anthropic, 2025)
Pense nisso como fazer o briefing de um consultor novo. Um briefing ruim é um e-mail de uma linha. Um bom briefing inclui o histórico da empresa, os antecedentes relevantes, os arquivos de que a pessoa vai precisar, quem são os envolvidos, como é o sucesso e o que está fora do escopo. Se você contrata um consultor brilhante e entrega um briefing ruim, recebe um trabalho medíocre. Com a IA é igual.
Repare no que não está na definição: esperteza. Não há formulação mágica, não há palavra secreta que te dê um modelo melhor. O trabalho está mais próximo da edição do que do encantamento. Você está decidindo o que entra na sala antes de a conversa começar e, com a mesma importância, o que fica de fora.
O tweet que deu nome à coisa
Em 19 de junho de 2025, Tobi Lütke, CEO da Shopify, postou no X que preferia o termo "context engineering" a "prompt engineering". Ele descreveu a prática como "the art of providing all the context for the task to be plausibly solvable by the LLM" (a arte de fornecer todo o contexto para que a tarefa seja plausivelmente solucionável pelo LLM). Seis dias depois, Andrej Karpathy, uma das vozes mais respeitadas em IA, amplificou o termo. A definição dele era mais afiada: "context engineering is the delicate art and science of filling the context window with just the right information for the next step" (a arte delicada e a ciência de preencher a janela de contexto com exatamente a informação certa para o próximo passo). (Karpathy, 2025)
A expressão em si não era nova. Walden Yan, da Cognition, equipe por trás do agente autônomo de programação Devin, havia publicado "Don't Build Multi-Agents" uma semana antes, em 12 de junho, chamando a engenharia de contexto de "effectively the #1 job of engineers building AI agents" (na prática, a tarefa número 1 dos engenheiros que constroem agentes de IA). Mas foram os posts de Lütke e Karpathy que levaram o rótulo ao mainstream. No mês seguinte, a Gartner publicou um relatório intitulado "Lead the Shift to Context Engineering as Prompt Engineering Fades", com uma síntese direta: "Context engineering is in, and prompt engineering is out" (a engenharia de contexto entrou, a engenharia de prompt saiu). A previsão que acompanha o relatório: até 2028, recursos de engenharia de contexto estarão embutidos em 80 por cento das ferramentas de software usadas para construir aplicações de IA, melhorando a acurácia da IA agêntica em pelo menos 30 por cento. (Gartner, 2025)
O que aconteceu não foi um rebranding. Foi uma correção. A comunidade de IA admitiu em silêncio que a habilidade chamada "engenharia de prompt" sempre foi um subconjunto de algo maior e que o subconjunto já não era a parte interessante. Um prompt é um componente. O contexto é a sala inteira.
Isso importa porque profissionais do conhecimento passaram dois anos aprendendo a coisa errada. Memorizaram templates de prompt. Colecionaram threads de Twitter com o "prompt definitivo". Trataram o prompt como um feitiço. Esse esforço não é inútil, mas já não basta. A pergunta não é como você formula seu pedido. A pergunta é o que você coloca ao lado do seu pedido.
A engenharia de prompt morreu mesmo?
Resposta curta: o cargo morreu, as técnicas não.
É tentador tratar isso como uma virada geracional em que tudo o que é antigo está errado. Esse enquadramento é preguiçoso. Chain-of-thought, exemplos few-shot, atribuição de papel e formatos de saída explícitos continuam movendo o ponteiro, e continuam aparecendo dentro de contextos bem construídos.
O que mudou foi o teto. Em 2023, um prompt bem formulado podia dobrar a qualidade de uma resposta porque os modelos da época se confundiam facilmente com ambiguidade. Você conseguia transformar o GPT-3.5 de estagiário atrapalhado em analista coerente com a estrutura de frase certa. Essa diferença era real, e a engenharia de prompt a explorou.
Os modelos de fronteira de 2026 não precisam desse cuidado. Claude Opus 5, GPT-5.6 e Gemini 3.1 Pro lidam razoavelmente bem com pedidos ambíguos. O retorno marginal da formulação caiu. Mas o retorno marginal de fornecer material de origem relevante, memória bem delimitada e exemplos curados subiu bastante. A alavanca mudou de lugar.
Aqui está a comparação, lado a lado.
| Dimensão | Engenharia de prompt | Engenharia de contexto |
|---|---|---|
| O que você ajusta | A redação do seu pedido | Toda a pilha de entrada fornecida ao modelo |
| Unidade principal | Uma frase | Um pacote: system prompt, documentos, memória, ferramentas, histórico |
| Para quem serve | Qualquer pessoa que use uma caixa de chat | Qualquer pessoa cuja qualidade do trabalho dependa de IA |
| Habilidade exigida | Boa escrita, reconhecimento de padrões | Curadoria, arquitetura da informação, julgamento |
| Quando falha | O modelo entende mal a instrução | O modelo entende bem, mas faltam os fatos, os exemplos ou o histórico para responder bem |
| Correção quando trava | Reformular, dar exemplos, especificar o formato de saída | Acrescentar a fonte certa, cortar as fontes erradas, ajustar a memória, delimitar a recuperação |
| Auge | 2022 a 2024 | De 2025 em diante |
Repare na última linha. A engenharia de prompt não morreu por estar errada. Morreu porque o gargalo mudou de lugar.
A engenharia de contexto também morreu?
Resposta curta: o rótulo está desbotando, a prática não.
A reação contrária já é forte o bastante para ter gênero próprio. Joe Reis publicou "Gartner Declares 2026 The Year of Context™" em março de 2026, satirizando o "context engineer" como uma mistura de "data engineer, ontologist, librarian, corporate anthropologist, and therapist" (engenheiro de dados, ontologista, bibliotecário, antropólogo corporativo e terapeuta) cujo trabalho real é "updating a YAML file" (atualizar um arquivo YAML). Tirando as piadas, sobram três objeções de pé, e duas delas contêm algo verdadeiro.
"Os modelos vão absorver isso." A tese é que os arcabouços de agentes hoje cuidam sozinhos de compactação, recuperação e memória, então a pessoa não precisaria mais pensar em contexto. Há substância real aqui. A compactação automática e a recuperação just-in-time de fato eliminaram uma categoria de trabalho manual. Mas a automação deslocou o trabalho em vez de apagá-lo. Alguém continua decidindo o que vai para o arquivo de memória, quais fontes o recuperador pode tocar e o que o agente deve ignorar. O encanamento foi automatizado. O julgamento, não.
"Sempre foi só um jargão para 'boas entradas'." Em parte justo. Curar entradas não é ideia nova, e o termo acabou esticado para cobrir quase tudo por fornecedores que vendem produtos de contexto. Mas dar nome a uma coisa muda o quanto as pessoas a levam a sério. Ninguém auditava sistematicamente as entradas de IA em 2023. Muitas equipes fazem isso hoje, e fazem porque o nome deu forma à prática.
"Context rot significa que não dá para resolver com engenharia." Essa está de trás para frente. O fato de os modelos degradarem conforme a entrada cresce é o argumento a favor do trabalho deliberado de contexto, não contra ele. Se mais contexto fosse sempre melhor, a curadoria seria inútil e você poderia despejar tudo lá dentro.
A leitura honesta em meados de 2026: a expressão já passou do pico de hype, e o cargo isolado de "context engineer" é emergente, não padrão. A Adobe publica vagas com exatamente esse nome, mas na maioria das empresas o trabalho está dentro de posições já existentes de engenharia de IA, de dados ou de plataforma. A prática por baixo dele está mais consolidada do que nunca. Espere que o rótulo vire pano de fundo como aconteceu com "responsive design", absorvido pela definição padrão de trabalho competente.
As seis camadas de contexto
Para fazer engenharia de contexto de forma deliberada, você precisa saber o que está construindo. Toda interação moderna com IA puxa de seis camadas, quer você pense nelas ou não. A habilidade está em saber quais ajustar.
| Camada | Função | Exemplo |
|---|---|---|
| System prompt | Define quem é o modelo, que regras ele segue, que tom adota | Um arquivo claude.md no seu repositório, o .cursorrules do Cursor ou uma instrução de GPT customizado como "Você é um editor sênior. Prefira a voz ativa. Nunca use travessões." |
| Memória persistente | Coisas que o modelo lembra sobre você entre conversas | O recurso de memória do ChatGPT guardando sua profissão, seu estilo de escrita e seus projetos em andamento |
| Recuperação (RAG) | Puxa trechos relevantes de uma base de conhecimento maior sob demanda | Perguntar à sua IA "o que eu destaquei sobre efeitos de rede no mês passado?" e ela buscar exatamente aquelas passagens |
| Uso de ferramentas | Permite que o modelo execute ações ou busque dados ao vivo | O modelo chama uma calculadora, roda código, pesquisa na web ou consulta sua agenda |
| Anexos | Arquivos, imagens ou URLs carregados nesta sessão específica | Um contrato em PDF que você solta ali para revisão, ou uma captura de tela que você cola para depurar |
| Histórico da conversa | O que já foi dito nesta conversa | O vai e vem acima da sua mensagem atual, incluindo correções e preferências anteriores |
Um contexto bem construído usa as seis de forma deliberada. Um contexto mal construído despeja tudo em uma única camada (em geral os anexos, muitas vezes o histórico da conversa) e torce para o modelo se virar.
O erro que a maioria dos profissionais do conhecimento comete é tratar a IA como uma interface de chat quando ela é, na verdade, um montador de contexto. Quase tudo o que determina a resposta já aconteceu quando você começa a digitar.
Para um ângulo relacionado sobre como a arquitetura da informação pessoal molda a utilidade da IA, veja gestão de contexto pessoal.
Por que janelas de contexto maiores pioraram tudo, e não melhoraram
Em 2023, uma janela de contexto de 100 mil tokens era exótica. Em 2026, um milhão de tokens é a linha de base comum: cerca de 1.050.000 no GPT-5.6, 1.048.576 no Gemini 3.6 Flash e 1.000.000 no Claude Opus 5. O Llama 4 Scout anuncia 10 milhões. Você pode jogar o texto completo de Guerra e Paz em um único prompt várias vezes seguidas. A suposição natural, então, é que a engenharia de contexto está ficando mais fácil. Mais espaço, menos triagem, certo?
Errado. Ficou mais difícil.
O artigo fundacional aqui é Liu et al. (2024), "Lost in the Middle: How Language Models Use Long Contexts", publicado na TACL. Os pesquisadores testaram se os modelos conseguiam encontrar e usar uma informação específica dependendo de onde ela era colocada em um contexto longo. O achado foi desconfortável: o desempenho tem forma de U. Os modelos prestam mais atenção à informação bem no começo e bem no fim do contexto. A informação do meio é sistematicamente subvalorizada, às vezes ignorada por completo. (Liu et al., 2024)
Coloque uma instrução crítica no meio de um documento de 50 páginas e o modelo pode agir como se nunca a tivesse visto. Esse não é um defeito que você resolve com prompt.
Depois, em julho de 2025, a Chroma publicou "Context Rot: How Increasing Input Tokens Impacts LLM Performance", de Kelly Hong, Anton Troynikov e Jeff Huber. Eles testaram 18 modelos de fronteira, incluindo GPT-4.1, Claude 4, Gemini 2.5 e Qwen3. O resultado foi consistente em todos: o desempenho degradou conforme a entrada crescia, bem antes de a janela de contexto chegar perto de cheia. Os modelos não usam seu contexto de forma uniforme. A acurácia caiu dezenas de pontos percentuais entre cerca de 10.000 e 100.000 tokens, o que, em um modelo de um milhão de tokens, é o primeiro décimo da janela.
O detalhe crucial é que o limiar acompanha uma contagem absoluta de tokens, não uma fração da janela. A Databricks mediu a corretude despencando por volta de 32.000 tokens no Llama 3.1 405B, e em contagens ainda menores nos modelos menores. Comprar uma janela maior não move esse número. Uma janela de um milhão de tokens não te dá um milhão de tokens úteis, dá apenas mais espaço para piorar o problema. A Meta publica recuperação quase perfeita do tipo agulha no palheiro em todos os 10 milhões de tokens do Llama 4 Scout, mas encontrar um fato plantado não é o mesmo que raciocinar sobre o corpus, e nenhum benchmark publicado mostra a qualidade do raciocínio se mantendo nesse comprimento.
A Anthropic descreve a causa de fundo de um jeito que torna a solução óbvia. O contexto é "a finite resource with diminishing marginal returns" (um recurso finito com retornos marginais decrescentes), e os modelos operam com um "attention budget" (orçamento de atenção) no qual "every new token introduced depletes this budget by some amount" (cada novo token introduzido consome uma parte desse orçamento). A arquitetura explica o porquê: um transformer precisa calcular n² relações entre pares para n tokens, então a atenção fica mais rala conforme a entrada cresce. (Anthropic, 2025)
Esse é o custo oculto da era do milhão de tokens. A janela cresceu mais rápido do que a capacidade dos modelos de usá-la, e isso transformou "o que eu devo deixar de fora?" na pergunta mais valiosa da pilha. Para a versão arquitetural desse problema, incluindo quando recorrer à recuperação em vez do contexto longo, veja Context Rot, RAG e contexto longo.
As quatro formas de falha do contexto
Poluição de contexto é o termo guarda-chuva para um contexto degradado por material que não deveria estar ali. É uma expressão útil e um diagnóstico inútil, porque saber que seu contexto está poluído não diz o que remover. A decomposição mais proveitosa veio de Drew Breunig, que publicou "How Long Contexts Fail" em 22 de junho de 2025. Ele dividiu a poluição de contexto em quatro modos de falha distintos, e a razão de a taxonomia ter pegado é que cada um deles tem uma correção diferente.
| Modo de falha | O que é | Sinal revelador | Correção |
|---|---|---|---|
| Envenenamento de contexto | Uma alucinação ou um erro entra no contexto e passa a ser citado repetidamente | O modelo repete com segurança um fato que você nunca forneceu | Comece uma conversa nova. Valide o que entra na memória |
| Distração de contexto | O contexto fica tão longo que o modelo se fixa nele e negligencia o que aprendeu no treinamento | As respostas ficam repetitivas, o modelo reaproveita ações passadas em vez de raciocinar | Compacte ou resuma e então recomece |
| Confusão de contexto | Conteúdo supérfluo acaba sendo usado para gerar uma resposta de qualidade inferior | Ferramentas irrelevantes são chamadas, detalhes fora do tema aparecem na saída | Corte a lista de ferramentas e a lista de fontes |
| Conflito de contexto | Informações ou ferramentas novas entram em choque com o que já está no contexto | O modelo hesita, se contradiz ou escolhe a instrução errada | Remova a contradição. Reafirme a regra uma única vez |
Os exemplos por trás disso são concretos. Para o envenenamento, Breunig aponta um agente Gemini 2.5 jogando Pokémon que alucinou estados de jogo, escreveu-os na própria seção de objetivos e depois passou longos trechos perseguindo metas impossíveis. Para a distração, ele cita o mesmo resultado da Databricks que ancora a seção anterior: a corretude começa a escorregar perto dos 32.000 tokens em um modelo cuja janela é muitas vezes maior.
A confusão tem a evidência mais acionável. No Berkeley Function-Calling Leaderboard, no resumo de Breunig, "every model performs worse when provided with more than one tool" (todo modelo tem desempenho pior quando recebe mais de uma ferramenta), e os modelos vez ou outra chamam ferramentas que nada têm a ver com o pedido. Em um teste do benchmark GeoEngine, um Llama 3.1 8B quantizado falhou na tarefa quando recebeu 46 ferramentas e teve sucesso quando recebeu 19. Mesmo modelo, mesma tarefa, menos opções.
Para o conflito, Breunig cita pesquisas da Microsoft e da Salesforce sobre prompts "fatiados", em que a mesma informação é espalhada por várias mensagens em vez de entregue de uma vez. O desempenho caiu 39 por cento em média, e o o3 despencou de 98,1 para 64,1 nas tarefas afetadas.
Eis o padrão que vale internalizar: três dessas quatro falhas pioram quando você acrescenta contexto. Só uma delas, a de um fato genuinamente ausente, melhora. Essa assimetria é o argumento inteiro a favor da curadoria.
O que a pesquisa diz: os artigos que importam
Quatro documentos carregam quase todo o peso aqui e, se você ler só esses, vai estar à frente de quase todo mundo que discute o assunto na internet. A âncora é "A Survey of Context Engineering for Large Language Models" (arXiv:2507.13334), submetido em 17 de julho de 2025. São 166 páginas percorrendo 1.411 artigos citados, o que faz dele a coisa mais parecida com um mapa que a área tem.
O enquadramento do survey é que a engenharia de contexto "transcends simple prompt design to encompass the systematic optimization of information payloads for LLMs" (transcende o simples desenho de prompts para abarcar a otimização sistemática das cargas de informação entregues aos LLMs). Ele divide a área em componentes fundacionais (recuperação e geração de contexto, processamento de contexto, gestão de contexto) e depois nas implementações de sistema construídas sobre eles: RAG, sistemas de memória, raciocínio integrado a ferramentas e arquiteturas multiagente. Se você já se perguntou onde o RAG se encaixa em relação à engenharia de contexto, a resposta é essa: a recuperação é uma máquina dentro de uma disciplina maior.
O achado mais interessante é uma lacuna que os autores sinalizam como "a defining priority for future research" (uma prioridade definidora para a pesquisa futura). Modelos reforçados por boa engenharia de contexto "demonstrate remarkable proficiency in understanding complex contexts" (demonstram proficiência notável em compreender contextos complexos), mas "exhibit pronounced limitations in generating equally sophisticated, long-form outputs" (exibem limitações pronunciadas em gerar saídas longas igualmente sofisticadas). Em bom português: ficamos muito melhores em alimentar os modelos com informação do que em receber de volta trabalho longo e de alta qualidade. Quem já viu uma IA produzir um resumo brilhante e, na sequência, um rascunho medíocre de 3.000 palavras sentiu isso na pele.
O outro documento que vale ler na íntegra é "Effective context engineering for AI agents", da Anthropic, publicado em 29 de setembro de 2025. É ele que deu aos praticantes o vocabulário de trabalho que a maioria das ferramentas usa hoje:
- Recuperação just-in-time: manter identificadores leves no contexto (caminhos de arquivo, consultas, links) e carregar os dados de verdade em tempo de execução, em vez de pré-carregar tudo.
- Compactação: quando a conversa se aproxima do limite da janela, resumi-la e reinicializar uma janela nova. A Anthropic observa que a dificuldade está inteiramente na seleção, já que uma "overly aggressive compaction" (compactação agressiva demais) perde contexto sutil cuja importância só aparece mais tarde.
- Anotação estruturada: fazer o agente escrever notas em uma memória persistente fora da janela de contexto e reler essas notas quando precisar.
- Arquiteturas de subagentes: entregar tarefas focadas a agentes especializados com janelas de contexto limpas e deixar um agente principal sintetizar os resultados.
Essas quatro técnicas foram desenhadas para agentes autônomos. Todas as quatro têm um equivalente manual que uma pessoa pode executar em uma janela de chat, que é o assunto das duas próximas seções. Para ver como essas ideias aparecem no ferramental de agentes do dia a dia, veja Skills, subagentes e hooks.
A habilidade que ninguém nomeou: curadoria
Se o context rot é o problema, a curadoria é a solução. E a curadoria, por acaso, é uma habilidade que a maioria dos profissionais do conhecimento já pratica, sem chamar assim.
Toda vez que você destaca uma passagem em um artigo, você está fazendo curadoria. Está dizendo: isto importa. O resto é pano de fundo. Quando você anota um PDF, salva um paper ou guarda uma citação, está fazendo a mesma coisa. Está construindo um filtro de sinal e ruído sobre um mundo cheio de texto.
O problema, até pouco tempo atrás, era que essa curadoria ficava presa. Seus destaques viviam em um aplicativo. Suas notas do Kindle, em outro. Sua pesquisa na web, no histórico do navegador. Quando você sentava para dar o briefing a uma IA, não conseguia puxar nada disso para a janela de contexto de forma eficiente. Acabava relendo tudo ou, pior, colando as fontes cruas e torcendo pelo melhor.
A engenharia de contexto como disciplina tem uma lacuna enorme exatamente aqui. As empresas resolveram construindo bases de conhecimento internas e pipelines de RAG. Mas profissionais do conhecimento individuais não têm uma equipe de engenharia. Eles têm o mesmo problema (material de origem demais, sinal de menos) e nada dessa infraestrutura.
É por isso que ferramentas de leitura que capturam destaques de forma durável viraram, discretamente, infraestrutura de IA. O marca-texto web do Glasp existe para resolver exatamente isso: ele transforma sua leitura em contexto estruturado e recuperável. Quando você destaca um parágrafo em um post de blog, aquele destaque vira uma peça de contexto que você pode entregar a qualquer IA depois, filtrada por tema, por fonte, por data.
O mesmo princípio vale para a leitura longa. Seus destaques do Kindle são, provavelmente, o sinal de mais alta qualidade que você já gerou sobre o que importa para você. Você prestou atenção o suficiente para destacá-los. Esse é um filtro caro, e ele é desperdiçado se os destaques ficam presos em um sistema fechado.
Engenharia de contexto para indivíduos (não só engenheiros)
A maior parte do que se escreve sobre engenharia de contexto mira desenvolvedores. Fala de construir sistemas de IA em produção: como moldar um system prompt para um agente de programação, como fatiar documentos para recuperação, como conectar chamadas de ferramentas. Isso é útil se você entrega software. É menos útil se você é consultor, pesquisador, escritor, analista ou estudante tentando obter melhores respostas de IA.
Mas a mesma disciplina se aplica. Você só a executa na mão.
Você desenha system prompts, informalmente. Todo GPT customizado, todo Projeto do Claude, todo arquivo de instruções no estilo claude.md que você configura é um system prompt. Quando você escreve "você é meu assistente de pesquisa, trabalho com política de energia renovável, prefiro resumos céticos", está fazendo desenho de system prompt. Faça isso de propósito.
Você gerencia memória. O recurso de memória do ChatGPT e os Projetos do Claude permitem fixar fatos que persistem entre conversas. A maioria das pessoas ou ignora isso (e perde continuidade) ou despeja tudo lá (e cria ruído). O movimento certo é curar a memória como você curaria um currículo: só o que você quer que o modelo use sempre.
Você faz recuperação, manualmente. Colar o artigo certo em um chat é RAG manual. A questão é de onde vem "o artigo certo". Se vem de rolar freneticamente o histórico do navegador, você não tem sistema de recuperação. Se vem de uma biblioteca de passagens que você já marcou como interessantes, você tem.
Você carrega anexos com intenção. A tentação é subir o livro inteiro. O melhor movimento é subir as 40 páginas que você realmente destacou. Você está driblando o context rot ao fazer a filtragem a montante.
Depois vêm as quatro técnicas de agente do manual da Anthropic, cada uma com sua versão manual:
| Técnica de agente | A versão manual que você pode rodar hoje |
|---|---|
| Recuperação just-in-time | Mantenha uma lista de links das fontes na conversa e cole o texto completo só quando o modelo realmente precisar |
| Compactação | Quando a conversa ficar longa e as respostas repetitivas, peça um resumo das decisões até ali e comece um chat novo com esse resumo no topo |
| Anotação estruturada | Mantenha o estado corrente do projeto em um documento fora do chat e recole a versão atual em vez de depender da rolagem |
| Subagentes | Rode chats separados para subtarefas separadas em vez de uma conversa gigante, e traga de volta só as conclusões |
A compactação é a que a maioria das pessoas esquece. Conversas longas pioram com o tempo porque as mensagens antigas dominam o contexto sem ajudar, e isso é exatamente o modo de falha por distração da tabela anterior. Começar uma conversa nova para uma subtarefa nova, com um briefing limpo, costuma ser melhor do que continuar a conversa gigante.
Nada disso exige habilidade de engenharia. Exige a mesma habilidade que bons pesquisadores e bons jornalistas já têm: saber o que incluir, o que cortar e de onde puxar cada coisa.
Seus destaques são seu contexto competitivo
Aqui está a parte subestimada.
A maioria das pessoas trata suas notas e seus destaques como auxiliares de memória. Coisas para revisitar um dia. Esse enquadramento fazia sentido em 2010, quando revisitar era a única forma de usá-los. Em 2026, está obsoleto.
Seus destaques agora são um insumo que pode ser entregue à IA. Cada passagem que você marcou, cada citação que salvou, cada anotação que fez é uma peça de contexto. E, como você a gerou prestando atenção, ela tem sinal mais alto do que qualquer coisa raspada aleatoriamente da web.
Pense no que isso significa em termos competitivos. Dois profissionais do conhecimento usam o mesmo modelo de IA. Um tem três anos de leitura estruturada e de destaques. O outro tem três anos de abas de navegador que nunca revisitou. Quando fazem a mesma pergunta à IA, o primeiro pode alimentá-la com o próprio acervo curado. O segundo fica preso aos dados genéricos de treinamento do modelo e ao que conseguir lembrar de colar. A diferença não é de prompt. É de contexto.
É por isso que o Glasp vem mudando a forma como se posiciona. A proposta original era um marca-texto web social: destacar coisas, ver o que os outros destacaram, construir uma identidade de leitor. Tudo isso continua valendo. Mas o valor mais profundo agora é que cada destaque é um token de contexto esperando para ser usado. Seu histórico de leitura se acumula em um corpus de RAG pessoal, um parágrafo por vez.
Quando você combina isso com o chat com IA do Glasp, o fluxo fica parecido com o que engenheiros constroem para as próprias empresas. Você destaca enquanto lê. Depois, faz perguntas e a IA puxa daquilo com que você de fato se importou, não de um índice genérico da web. Isso é engenharia de contexto, só que o contexto é a sua própria biblioteca.
Para mais sobre como isso inverte a relação entre leitura e IA, veja assistentes de leitura com IA.
Um framework simples para montar contexto em qualquer tarefa de IA
Chega de teoria. Aqui está um fluxo concreto que você pode rodar da próxima vez que abrir um chat.
Passo 1: defina a tarefa antes de digitar. Uma frase. Como é o resultado pronto? "Escreva um memorando de 500 palavras resumindo os três principais argumentos contra a semana de quatro dias, endereçado a um COO cético." Isso é uma tarefa. "Me ajuda com este artigo" não é.
Passo 2: reúna suas fontes e depois corte. Puxe os materiais que de fato incidem sobre a tarefa. Se você tem destaques sobre o tema, comece por eles, não pelos artigos inteiros. Se você tem memória configurada, verifique se ela já traz um pano de fundo útil. Deixe de fora tudo o que for só tangencialmente relacionado. O context rot é real.
Passo 3: defina o papel e as regras. Antes da tarefa, diga ao modelo quem ele é e que regras valem. "Você está editando para um COO cético. Sem jargão. Sem meias palavras. Números antes de adjetivos." Essa é a camada do system prompt. Leva dez segundos e muda o tom de tudo o que vem depois.
Passo 4: entregue a tarefa e o pacote, nessa ordem. Coloque o contexto mais importante no começo e a tarefa no fim. Por causa do efeito Lost in the Middle, você quer a instrução e o material mais afiado no início e no final. O meio é um pântano.
Passo 5: diagnostique antes de iterar. Se a resposta veio ruim, resista ao impulso de reescrever seu prompt de doze maneiras. Em vez disso, rode os quatro modos de falha como um checklist. Há um fato errado ali que insiste em voltar (envenenamento)? A conversa está longa e repetitiva (distração)? Você anexou três fontes quando só uma era relevante (confusão)? Você deu duas instruções que se contradizem (conflito)? Cada uma tem uma correção diferente, e nenhuma delas é reformular.
Faça isso algumas dezenas de vezes e vira reflexo. Você vai parar de perguntar "como eu escrevo o prompt disso?" e começar a perguntar "o que o modelo precisa ver antes de responder?". Essa virada é a disciplina inteira.
Perguntas frequentes
O que é engenharia de contexto em termos simples?
É decidir o que um modelo de IA vê antes de responder. Isso inclui as instruções que você dá, os documentos que anexa, o que ele lembra sobre você, as ferramentas que pode usar e a conversa até ali. A engenharia de prompt cobre apenas a redação do seu pedido, que é uma entrada entre muitas.
A engenharia de prompt morreu mesmo?
A expressão está se aposentando. As técnicas por trás dela continuam funcionando. Chain-of-thought, exemplos few-shot e formatos de saída claros seguem úteis. O que morreu é a ideia de que só uma boa formulação te dá um ótimo resultado. Em 2026, a formulação é uma alavanca menor. A montagem do contexto é a maior. Quando as pessoas dizem "a engenharia de prompt morreu", é isso que elas querem dizer.
A engenharia de contexto morreu ou é só um jargão?
O termo já passou do pico de hype, e o cargo isolado de "context engineer" é emergente, não padrão: a Adobe publica vagas exatamente com esse nome, mas na maioria das empresas o trabalho está dentro de posições já existentes de engenharia de IA, de dados ou de plataforma. A prática está mais consolidada do que nunca, e vem sendo absorvida pelo trabalho normal com IA em vez de desaparecer. A compactação e a recuperação automáticas das ferramentas de agente modernas eliminaram alguns passos manuais, mas alguém continua decidindo o que entra na memória e quais fontes o modelo pode ver. Essa decisão é o trabalho.
O que é poluição de contexto?
É o termo geral para um contexto degradado por material que não deveria estar ali. A taxonomia de Drew Breunig divide a poluição de contexto em quatro modos: envenenamento (um erro entra e passa a ser repetido), distração (o contexto fica tão longo que o modelo se apoia demais nele), confusão (conteúdo irrelevante puxa a resposta para baixo) e conflito (duas peças de contexto se contradizem). Diagnosticar qual deles você tem faz diferença, porque as correções são diferentes.
Quais são os melhores artigos sobre engenharia de contexto?
Comece por "A Survey of Context Engineering for Large Language Models" (arXiv:2507.13334), uma revisão de 166 páginas sobre 1.411 artigos. Para a evidência das falhas em contexto longo, leia Liu et al. (2024), "Lost in the Middle", na TACL, e o relatório técnico "Context Rot" da Chroma, de 2025. Para a prática aplicada, "Effective context engineering for AI agents" da Anthropic (setembro de 2025) é o documento não acadêmico mais útil.
Qual a diferença entre engenharia de contexto e RAG?
RAG (retrieval-augmented generation) é uma camada da engenharia de contexto, especificamente a camada de recuperação. É a maquinaria que puxa trechos relevantes de uma base de conhecimento quando necessário. A engenharia de contexto é a disciplina mais ampla, que inclui o RAG mais os system prompts, a memória, o uso de ferramentas, os anexos e o histórico da conversa.
Janelas de contexto maiores não vão acabar resolvendo isso?
Não resolveram até agora, e as evidências sugerem que não vão. Liu et al. (2024) mostraram que os modelos ignoram o meio de contextos longos. O estudo da Chroma de 2025 mostrou que todos os 18 modelos de fronteira testados degradam bem antes de a janela encher. Janelas anunciadas com 10 milhões de tokens têm resultados de recuperação do tipo agulha no palheiro, mas nenhum benchmark publicado mostra a qualidade do raciocínio se mantendo nesse comprimento. O gargalo não é o tamanho da janela. É a alocação de atenção dentro dela.
Preciso ser técnico para fazer engenharia de contexto?
Não. A metáfora da engenharia confunde algumas pessoas, mas ela só quer dizer fazer o trabalho de propósito em vez de por acaso. Um consultor preparando um briefing, um jornalista pesquisando uma matéria, um estudante organizando material de origem para uma redação, tudo isso é engenharia de contexto disfarçada. A habilidade central é curadoria e julgamento.
Como isso se relaciona com os recursos de "memória" da IA?
A memória (como a memória persistente do ChatGPT ou os Projetos do Claude) é uma camada do contexto. É o que o modelo sabe sobre você entre sessões. A engenharia de contexto inclui a memória, mas é mais ampla. A memória é a camada sempre ligada. Recuperação, anexos e system prompts são as camadas por tarefa. Um bom engenheiro de contexto usa todas juntas.
Isso não é só anotação sofisticada?
Em parte. A diferença é que a anotação tradicional é otimizada para você reler suas notas. A engenharia de contexto é otimizada para um modelo consumir suas notas. Os requisitos de formato mudam (estrutura, atomicidade e recuperabilidade importam mais), mas a prática de fundo, capturar o que vale a pena lembrar, é a mesma. Quem já anota bem larga na frente.
Conclusão: a nova alfabetização
Toda era da computação teve uma alfabetização que separou amadores de usuários sérios. Nos anos 2000, era aprender a pesquisar bem no Google. Nos anos 2010, era aprender a estruturar informação em apps como Notion ou Airtable. Em 2026, é aprender a construir contexto para a IA.
Quem entender isso vai abrir uma vantagem enorme sobre quem não entender. Não por ter acesso melhor aos modelos (os modelos são os mesmos para todo mundo), mas por chegar em cada tarefa com material melhor. Essas pessoas sabem o que colocar dentro. Sabem o que deixar de fora. Sabem onde está sua melhor fonte sobre um tema, porque se deram ao trabalho de capturá-la meses atrás.
É por isso que a curadoria vem se tornando, discretamente, a meta-habilidade mais valiosa da era da IA. Cada destaque que você salva, cada passagem que anota, cada leitura que você de fato processa é um depósito em um motor de contexto pessoal. O futuro da produtividade com IA não são pessoas com prompts secretos. São pessoas com bibliotecas bem pensadas.
Você já faz a leitura. Você já tem opinião sobre o que importa. A única questão é se algo disso permanece por tempo suficiente para ser útil ao seu eu futuro e à IA que trabalha ao seu lado. As ferramentas existem. O hábito é a parte difícil.
Escolha hoje algo que valha a leitura. Destaque as partes que importam. Isso é engenharia de contexto. Todo o resto é técnica.
