O que é context engineering

Por que o prompt não basta

Num chat, a instrução é quase tudo o que o modelo lê. Num sistema com agentes, ela é uma parte pequena. O resto é contexto: arquivos carregados, histórico da sessão, descrições de ferramentas, regras do projeto e o que outros agentes produziram antes.

Mais contexto não significa resultado melhor. O CL-Bench, citado no experimento #007, indica que 76% do contexto carregado em LLMs é ignorado. O problema raramente é falta de instrução. Quase sempre é excesso de material.

Os quatro jeitos de o contexto falhar

1. Envenenamento. Uma informação errada entra no contexto e passa a ser tratada como verdade nas respostas seguintes.
2. Distração. O volume de contexto é tão grande que o modelo perde de vista a tarefa atual.
3. Confusão. Material irrelevante muda a resposta, mesmo sem ter relação com o pedido.
4. Conflito. Duas partes do contexto dizem coisas diferentes, e o modelo escolhe uma sem avisar.

As quatro foram validadas no mesmo experimento, a partir de um estudo com o Gemini 2.5. Cada uma pede uma correção diferente, por isso vale saber qual está acontecendo antes de mexer.

O que um contexto bem desenhado tem

1. Só o que a etapa precisa. Se a resposta não muda sem um item, ele sai.
2. Contexto separado por agente. Cada agente trabalha com o próprio contexto, e um erro não contamina o resto do sistema.
3. Regras como limites. Dizer o que nunca fazer costuma segurar mais do que listar o que sempre fazer.
4. Verificação fora do modelo. O que precisa estar certo é conferido por um teste, não pela opinião do próprio modelo.

Como isso aparece nos meus sistemas

No ATHENA OS, cada agente executor roda com contexto próprio. No squad de context engineering do experimento #007, a regra de arquitetura foi "agentes pensam, skills executam": menos agentes, cada um com seus frameworks completos e sem referências externas. No experimento #009, um único arquivo de voz com limites explícitos manteve 10 agentes escrevendo com a mesma voz em 9 páginas.