Context engineering é a disciplina de curar o que um agente de IA sabe, vê e lembra no momento de agir, e é onde a maioria das falhas de agente realmente nasce.
Um prompt bem escrito diz o que fazer. Não diz, sozinho, quais ferramentas o agente pode usar, qual histórico da conversa importa, ou quais dados externos precisam entrar antes da resposta. Isso é contexto, e é aí que a maioria dos agentes de IA erra, mesmo quando a instrução em si está correta. O Gartner formalizou essa virada em julho de 2025, declarando que “context engineering is in, prompt engineering is out” e recomendando que líderes de IA priorizem arquiteturas orientadas a contexto (Gartner, Lead the Shift to Context Engineering as Prompt Engineering Fades, 2025).
Por que o prompt certo não é garantia de agente certo
A Redis perguntou diretamente a times técnicos onde os agentes de IA realmente falham, e 73% concordaram que agentes falham mais por contexto quebrado do que por modelo quebrado (Redis, The State of Context Engineering 2026). Isso inverte o instinto mais comum quando um agente erra, que é trocar de modelo ou reescrever o prompt. Na maioria dos casos, o modelo já é capaz o suficiente. O que falta é a informação certa, no formato certo, no momento certo.
O que realmente compõe o contexto de um agente
A Anthropic descreve o contexto de um agente como o conjunto de tokens disponíveis no momento da inferência, além do prompt em si. Na prática, isso inclui instruções de sistema, as ferramentas que o agente pode chamar (incluindo integrações via MCP), dados externos recuperados de sistemas do negócio, o histórico da conversa até aquele ponto, e referências de armazenamento como caminhos de arquivo ou consultas salvas (Anthropic, Effective context engineering for AI agents). Cada um desses componentes muda o que o agente decide fazer a seguir, e nenhum deles aparece no prompt escrito pelo usuário.l
Um agente que já lê dados de CRM, ERP e documentos internos, por exemplo, depende inteiramente de como esses dados chegam até ele. Se a integração devolve informação desatualizada ou fora de escopo, o agente decide em cima disso com a mesma confiança que decidiria em cima de um dado correto.
O mesmo prompt, “responda ao cliente sobre o status do pedido”, ilustra bem isso. Com acesso ao sistema de pedidos atualizado, o agente responde com o status real. Com um dado desatualizado no meio do histórico, ou sem acesso a esse sistema, o agente responde com a mesma confiança e o mesmo tom, só que errado. A instrução ficou igual; o que mudou foi o contexto disponível, e foi ele que decidiu o resultado.
A lacuna entre acreditar e construir
A mesma pesquisa da Redis encontrou uma contradição que vale mais do que qualquer número de crescimento: 97% das organizações acreditam que contexto importa, mas apenas 4% já construíram sistemas de contexto que realmente acumulam e refinam essa informação ao longo do tempo. A crença chegou antes da infraestrutura. Isso explica por que tantas empresas já têm agentes acessando sistemas internos via MCP sem ter, por trás disso, uma camada que decide o que desses sistemas realmente deveria chegar ao agente.
Onde a maioria erra: contexto de menos, ou contexto de mais
Um agente com contexto insuficiente improvisa: preenche a lacuna com uma suposição plausível, que pode estar certa ou completamente errada. Um agente afogado em contexto tem o problema oposto, decide pior porque a informação relevante se perde no meio de dado irrelevante. A recomendação da própria Anthropic é otimizar pelo menor conjunto de tokens de alto sinal que o agente precisa, não pelo maior volume de informação disponível. Contexto em excesso vira mais texto para o agente peneirar, sem necessariamente melhorar a decisão. Um teste prático para decidir o que entra: se aquela informação não mudaria a decisão do agente para a tarefa específica em questão, ela provavelmente não deveria estar no contexto.
Perguntas frequentes
Context engineering substitui prompt engineering?
Redimensiona o papel dele, sem eliminá-lo. Escrever bem uma instrução continua importando, mas deixa de ser o fator decisivo sozinho. Context engineering trata o prompt como uma peça dentro de um sistema maior de informação que o agente recebe.
Preciso de RAG para fazer context engineering?
RAG é uma das formas de trazer dado externo para o contexto, mas context engineering é mais amplo: inclui também ferramentas disponíveis, histórico de conversa e instruções de sistema. RAG cobre uma fatia específica desse problema maior.
Como sei se meu agente tem um problema de contexto, não de modelo?
Um sinal forte é o agente errar de forma inconsistente na mesma tarefa, dependendo de quando ou em que ordem a informação chegou até ele. Erro de modelo tende a se repetir do mesmo jeito. Erro de contexto muda conforme o que estava disponível naquela execução específica.
O que muda quando contexto vira disciplina, não acidente
Tratar contexto como parte do design do agente, e não como o que sobra depois de escrever o prompt, é a diferença entre um agente que funciona na demonstração e um que funciona em produção. Isso significa decidir, antes da primeira execução, quais ferramentas o agente pode acessar, que dados externos entram e em que formato, e o que do histórico da conversa realmente precisa ser carregado adiante.
A Maitha estrutura essa disciplina dentro da AI Unit, na oferta de AI Foundation e AI Agents, com um playbook de context engineering que ajuda a decidir o que entra, o que fica de fora, e como manter isso atualizado à medida que o sistema evolui.
