primeira coisa que aprendi quando comecei a manter agentes em produção é que o modelo é a parte fácil. O modelo está pronto, está testado em escala absurda, e tem comportamento previsível dentro de certos limites. O que falha — quase sempre — é o contexto que chega até ele.
Context engineering é o nome chique para uma disciplina simples: decidir, deliberadamente, o que o agente vê, em que ordem, e o que ele NÃO vê. Cada token tem um custo de atenção. Cada parágrafo enfiado no contexto "por garantia" rouba foco de outro parágrafo que realmente importa.
O que entra
O contexto que funciona é o mínimo necessário para que o agente tome uma boa decisão. Não é "tudo o que pode ser relevante" — é "o que muda a resposta se eu remover". O resto é ruído estruturado.
"O contexto que funciona é o mínimo necessário para uma boa decisão — não o máximo que cabe na janela."
Na prática, isso significa montar contextos do tipo "task brief" antes de cada chamada do agente: o que precisamos resolver, o que ele PODE assumir, o que ele NÃO pode assumir, e quais ferramentas estão disponíveis. Em vez de jogar logs inteiros, jogamos resumos. Em vez de jogar a base inteira, jogamos os 3-5 trechos que importam.
O que fica de fora
Resíduo de chamadas anteriores. Histórico de conversa que já não diz mais nada. Stack traces inteiros quando a primeira linha já basta. Documentação interna que está desatualizada. Cada um desses parece útil — e cada um deles degrada a decisão.
Se você não consegue explicar por que um pedaço do contexto está lá, ele provavelmente não deveria estar. Compaction não é otimização — é higiene.
O lado bom é que essa disciplina é barata. Não exige modelo novo, não exige infra nova. Exige só que alguém pare e desenhe — explicitamente — o contexto de cada chamada como se fosse uma API contract. Porque, no fundo, é.