Context Engineering para AI Agents: por que contexto importa mais que prompts em produção

Prompt Engineering foi a alavanca certa quando o produto era um chat. Você afinava instruções, few-shots, tom. Em agentes de produção a alavanca mudou de lugar. O modelo já é “bom o suficiente” na maior parte das tarefas enterprise. O que falta é o pacote certo de fatos, estado, memória, tools e limites no momento da inferência. Esse pacote tem nome: Context Engineering.

A pesquisa State of Context Engineering 2026 da Redis cravou o paradoxo que eu vejo em discovery com CTOs: quase todos concordam que contexto decide se a IA funciona (97% consideram importante). Quase ninguém construiu o sistema em que o contexto acumula valor com o uso (4%). Setenta e três por cento já dizem que sistemas de contexto navegável separam experimento de produção. A crença é universal. A infraestrutura é rara.

A escada que substitui o culto ao prompt

No artigo de Agent Harness deste blog já separamos State de Memory e dissemos que RAG é mecanismo de recuperação, não arquitetura de memória. Este artigo sobe um nível: mostra como essas peças viram um único objeto de engenharia — o contexto — e por que “jogar o PDF inteiro no prompt” é a antítese de Context Engineering.

Prompt Engineering: o que permanece

O prompt ainda importa. Ele declara papel, formato de saída, recusas, idioma, schema da intenção. Ele deve ser versionado como código (prompt version no trace). O que não escala é usar o prompt como banco, como IAM, como fila e como memória. Quando o time responde a cada falha de produção com “vamos reforçar o system prompt”, o contexto já estourou e ninguém mediu.

• Cabe no prompt: contrato de I/O, política narrativa (não a enforcement), few-shots estáveis.
• Não cabe no prompt: 400 páginas de wiki, o log da semana, 200 tools, o histórico cru de 40 sessões.
• Regra: se muda a cada request, não é prompt — é contexto montado pelo runtime.

Context: o objeto da inferência

Contexto é o pacote montado agora: system, intenção do usuário, recorte de estado, memórias recuperadas, snippets RAG, catálogo de tools autorizadas, resultados das últimas tools, avisos de política. Engineering, aqui, é budget. Tokens não são infindáveis e atenção do modelo não é uniforme. Lixo no meio da janela empurra o fato crítico para a borda — e agentes erram na borda.

Operações de um context engine

1. Select — o que esta tarefa tem direito de ver (tenant, papel, risco).
2. Retrieve — fatos e memórias com evidência de origem (provenance).
3. Compress — sumarizar estado, não copiar o transcript eterno.
4. Isolate — SYSTEM ≠ UNTRUSTED. Injection indireto vive da mistura.
5. Refresh — contexto velho é alucinação com carimbo da empresa (78% dos líderes na pesquisa Redis dizem que provar freshness é muito importante; 21% admitem decisão crítica em dado stale).
6. Bound — teto de tokens, teto de tools, teto de custo.

State: a execução atual não é memória

State é o que o harness precisa para retomar o run: step, plano, tool calls, aprovações, idempotency keys, budget restante. Pertence a uma máquina de estados (RECEIVED, PLANNING, WAITING_TOOL, WAITING_APPROVAL, …). Se você “lembra” isso num vector store, você não tem recovery — tem sorte semântica. State vive em store durável, checkpointável, com TTL da execução.

Memory: o que atravessa runs — com política de escrita

Memória de agente não é “guardar o chat”. É um conjunto de lojas com semântica diferente: episódica (o que aconteceu), semântica (fatos vigentes), operacional/procedural (como fazemos aqui). O LLM não deveria decidir sozinho o que merece persistir. Escrita de memória é tão perigosa quanto escrita no ERP: memory poisoning é só prompt injection com TTL infinito. O artigo seguinte deste cluster aprofunda os tipos e o porquê de vector database sozinho estar errado.

RAG: recuperação, não personalidade

RAG busca trechos no momento. Excelente para policy documents, catálogos, runbooks. Péssimo como substituto de estado transacional (“qual o status do pedido 8891 agora”) e como substituto de memória episódica (“o que o diretor aprovou ontem neste ticket”). A falha clássica de 2024–2025 foi one-shot RAG: embed tudo, top-k, rezar. Em 2026 o padrão maduro é retrieval híbrido + filtros de ACL + freshness + citação. Ainda assim, RAG não navega um grafo de conta → oportunidade → contrato sozinho. Para isso você precisa de modelo semântico de negócio — e 55% das organizações na pesquisa Redis admitem não ter esse modelo.

Tools: contexto de ação, não menu infinito

Cada tool na janela é contexto. Descrição longa é contexto. Cem tools é um prompt adversarial contra a própria atenção do modelo — e um paraíso para tool poisoning. Context Engineering de tools significa: capability discovery, subset por tarefa, descrições curtas e hasheadas, schemas estritos. MCP é o transporte (veja o mapa de protocolos). O catálogo visível é decisão de contexto.

Policies: o contexto que o modelo não pode editar

A política narrada no prompt (“nunca apague produção”) é dica. A política no Policy Engine é fato. Context Engineering inclui injetar no pacote o resumo do que foi permitido — “você pode observe em staging; mutate exige aprovação” — sem entregar ao modelo a caneta para reescrever o motor. O texto da política no contexto reduz erro honesto. O enforcement fora do contexto reduz incidente.

Agent Harness: onde o contexto vira sistema

Sem harness, Context Engineering vira um script que concatena strings. Com harness, cada step monta o pacote a partir de State Store, Memory Layer, retrievers, Tool Registry e Policy Engine, registra o que entrou (para eval e forense) e descarta o que não deveria ter entrado. EmerAgents é esse control plane na fábrica: intenção entra estruturada; contexto é montado; evidência fica.

type InferencePacket = {
  promptVersion: string;
  stateSlice: unknown;          // nunca o state inteiro
  memories: { id: string; text: string; provenance: string }[];
  rag: { id: string; text: string; asOf: string }[];
  tools: { name: string; schema: object }[]; // subset
  untrusted: { source: string; text: string }[];
  budget: { maxTokens: number; maxToolCalls: number };
};

function assemble(ctx: AgentContext): InferencePacket {
  return {
    promptVersion: prompts.current,
    stateSlice: state.project(ctx.runId),
    memories: memory.read(ctx, { limit: 8 }),
    rag: retriever.search(ctx.task, { acl: ctx.identity, fresh: true }),
    tools: registry.subset(ctx),
    untrusted: [],
    budget: ctx.budget,
  };
}

Falhas de contexto que imitam “o modelo é ruim”

• Fragmentação — a verdade da conta está em quatro sistemas; o agente vê um. (Pilar Redis: navigate.)
• Opacidade — ninguém sabe por que aquele snippet entrou no pacote. Sem provenance, sem eval.
• Velocidade — retrieval de 2s em loop de 20 steps mata a experiência e empurra cache podre.
• Não-acúmulo — cada sessão recomeça do zero; o sistema não fica mais inteligente. 81% concordam que a próxima maturidade é infraestrutura que ganha valor com o tempo. Quase ninguém tem.
• Stale — política de preço de ontem aplicada na cotação de agora.
• Oversharing — o agente de N1 vê o dossiê jurídico porque o RAG não tem ACL.

Como medir Context Engineering (não “qualidade do prompt”)

• Citation/provenance rate — fração de afirmações com fonte.
• Freshness SLA — % de fatos com as-of dentro da janela do domínio.
• Context hit rate — retrieval que de fato foi usado na decisão (não só retornado).
• Token waste — tokens enviados e ignorados.
• Policy packing errors — tentativas do modelo de agir fora do subset.
• Task success vs context size — curva; mais contexto não é monotonicamente melhor.

Playbook de adoção na fábrica

1. Versionar prompts e tratar como o menor arquivo do pacote.
2. Desenhar o modelo semântico mínimo (entidades de negócio que o agente precisa navegar).
3. Separar stores: state, episódica, semântica, operacional, índice RAG.
4. Ligar ACL e freshness no retriever antes de “melhorar o embedding”.
5. Cortar o catálogo de tools visíveis por tarefa.
6. Instrumentar o pacote no trace (o que entrou, de onde, com que hash).
7. Só então treinar o time em “escrever melhores prompts”.

Conclusão

Category ownership em 2026 não é “somos bons de prompt”. É ser o time que sabe montar contexto governado para AI Agents. Prompt Engineering continua no degrau de cima — necessário, insuficiente. Abaixo dele, state, memory, RAG, tools e policies. Abaixo de todos, o Agent Harness. É essa escada que a EmerSoftware sobe com EmerAgents: o modelo propõe; o contexto é engenharia; a política não se discute na janela de tokens.

O próximo artigo do cluster ataca o degrau que mais gera clique técnico e mais gera incidente silencioso: memória. “Guardar tudo no vector database” parece Context Engineering. Não é. É adiamento.