97% das organizações acreditam que context engineering é importante para seus objetivos de IA. Apenas 4% construíram a infraestrutura para suportá-lo em produção. O relatório "State of Context Engineering 2026", publicado pela Redis em agosto deste ano, registra esse gap com uma clareza que incomoda.
O que torna o número relevante não é o gap em si. É o que ele revela sobre uma confusão que a maioria dos times de engenharia ainda não resolveu. 73% dos líderes de TI entrevistados no mesmo levantamento concordam que agentes falham mais por contexto quebrado do que por modelos inadequados. O problema não é a inteligência do modelo. É o que chegou até ele antes de começar a trabalhar.
A distinção que ainda não virou prática
Birgitta Böckeler, distinguished engineer na ThoughtWorks, publicou em fevereiro de 2026 no martinfowler.com a definição que me parece mais precisa para o tema: context engineering é "curating what the model sees so that you get a better result". Não é o que você pede. É o que está disponível quando o modelo responde.
Prompt engineering atua na redação da instrução. Context engineering atua na arquitetura de informação que envolve essa instrução. O primeiro resolve a formulação. O segundo resolve o pipeline.
Matt Tanner, escrevendo para o Sourcegraph em maio de 2026, expande: context engineering é "the practice of deliberately designing what a large language model sees on every inference call". A palavra que importa é "every". Em tarefas longas e com múltiplos passos, o contexto que o agente recebe muda a cada iteração. Projetar esse fluxo é trabalho de engenharia, não de configuração inicial.
O que os números mostram sobre o estado atual
81% das organizações ainda operam nos dois primeiros estágios de maturidade que o relatório identifica: ad hoc ou exploratório. O contexto que chega ao agente é montado na mão, sem infraestrutura compartilhada, sem garantia de frescor e sem rastreabilidade.
21% admitem tomar decisões críticas com dados desatualizados. O agente processa bem o que recebe. O que chegou até ele estava incorreto antes da tarefa começar.
83% acreditam que contexto fresco importa mais do que adicionar parâmetros ao modelo. A intuição está correta. O gap é entre acreditar e construir.
Esses 96% que ainda não construíram não estão parados. Estão improvizando. Cada projeto monta o contexto de um jeito diferente, sem padrão, sem reutilização, sem visibilidade sobre o que chegou e o que não chegou ao agente. Funciona até o ponto em que a escala não permite mais improvisar.
Por que o agente chuta quando o contexto quebra
Quando o contexto é insuficiente, o agente não para para pedir mais informação. Ele escolhe o caminho mais plausível com o que recebeu.
Se o arquivo de configuração relevante não estava na janela, ele trabalha sem ele. Se a documentação de arquitetura não foi incluída, ele infere padrões de contextos parecidos. Se o estado atual do sistema não chegou até ele, ele age sobre o estado que conhecia.
Não é um defeito de raciocínio. É o comportamento esperado de um sistema que recebeu informação incompleta. O bug não está no modelo. Está no pipeline que antecede a inferência.
A confusão persiste porque o comportamento parece um erro de inteligência quando é, na prática, um erro de infraestrutura de dados. Debugar o prompt não resolve. Monitorar o modelo não resolve. O que resolve é projetar e monitorar o que entra na janela de contexto a cada passo da execução.
O mise en place antes da geração
Andrew Zigler, em paper publicado em maio de 2026 no arXiv, usa uma analogia que ajuda a entender o que preparação de contexto exige na prática. Mise en place é o princípio da culinária profissional para a preparação que precede o cozimento. Ingredientes separados, medidos e prontos para o momento em que forem necessários. O cozinheiro que não entra em pânico durante o serviço é o que preparou antes de o serviço começar.
Zigler propõe três fases para o desenvolvimento agentic. Primeiro, contextual grounding: reunir os documentos, padrões e referências que o agente vai precisar antes de gerar qualquer coisa. Segundo, collaborative specification: construir a especificação junto com o modelo enquanto o contexto ainda está completo, não depois que a tarefa já começou. Terceiro, task decomposition: quebrar o trabalho em unidades com contexto independente, evitando janelas que crescem até colapsar.
O que Zigler chama de "context fluency" é a habilidade de navegar esse processo com intencionalidade. Não é uma habilidade de escrita de prompt. É uma habilidade de projeto de sistemas.
O próximo passo depois da spec
Spec-driven development resolve o problema de comunicar ao agente o que precisa ser feito. Context engineering resolve o problema de garantir que o agente tem o que precisa saber para fazer.
São camadas complementares. A spec sem infraestrutura de contexto produz um agente que entende a tarefa mas não tem as informações para executá-la com precisão. A infraestrutura de contexto sem spec produz um agente bem informado sem critério de aceitação definido.
Na minha leitura, o que o relatório da Redis mapeia é uma fase específica da maturidade do mercado com IA. Spec-driven development ganhou tração. Context engineering é a camada que falta construir. Não como abstração adicional, mas como infraestrutura operacional: fontes de dados com garantia de frescor, grafos de contexto que permitem ao agente navegar entre sistemas relacionados, observabilidade sobre o que entrou na janela e o que ficou de fora.
Os 96% que ainda improvisam vão chegar nesse ponto pela força dos incidentes. Ou chegam antes, por design.
Referências
- Redis – The State of Context Engineering 2026 (Agosto 2026)
- Birgitta Böckeler (ThoughtWorks) – Context Engineering for Coding Agents (martinfowler.com, 5 fev 2026)
- Matt Tanner (Sourcegraph) – Context Engineering: A Practical Guide for AI Agents (28 mai 2026)
- Andrew Zigler – Mise en Place for Agentic Coding: Deliberate Preparation as Context Engineering Methodology (arXiv:2605.05400, 6 mai 2026)