Context engineering: o que merece entrar, sair e sobreviver à sessão

Dar “todo o contexto” a um agente parece seguro. Na prática, excesso pode esconder instruções, misturar estado antigo, aumentar custo e fazer informação irrelevante competir com o que decide a tarefa.

Context engineering é a disciplina de montar o menor conjunto de sinais capaz de orientar uma execução e preservar fora da janela aquilo que precisa sobreviver.

Resumo executivo

Contexto não é memória total. É uma seleção temporária.

O chat ajuda a trabalhar. O sistema de registro ajuda a continuar.

Prompt é apenas uma parte do contexto

O comportamento de um agente pode depender de:

• instruções de sistema;
• objetivo e critérios da tarefa;
• arquivos e documentos selecionados;
• histórico de mensagens;
• ferramentas e descrições;
• resultados intermediários;
• estado do ambiente;
• memória recuperada;
• políticas e capabilities;
• feedback de verificadores.

Mudar qualquer uma dessas peças pode alterar a saída, mesmo com o mesmo modelo e a mesma frase inicial.

O orçamento de atenção

Janelas maiores não transformam todo token em sinal. Três problemas permanecem:

Poluição

Instrução obsoleta ou exemplo irrelevante ganha peso por estar presente.

Competição

Fatos críticos ficam distantes ou diluídos em material semelhante.

Ambiguidade de autoridade

O agente não distingue regra canônica, hipótese, comentário e histórico.

O objetivo não é minimizar tokens por estética. É maximizar sinal útil e deixar autoridade explícita.

Um pacote de contexto em camadas

Monte a tarefa na seguinte ordem:

1. intenção: problema, destinatário e resultado;
2. autoridade: quem decide e quais ações são permitidas;
3. contratos: requisitos, interfaces, riscos e não objetivos;
4. estado atual: branch, versão, pendências e evidências;
5. fontes: arquivos ou referências necessárias;
6. critério: como verificar e quando parar;
7. saída: formato de entrega e handoff.

Essa estrutura reduz a chance de contexto histórico se passar por instrução atual.

Recuperar no momento certo

Nem toda fonte precisa entrar antes da primeira ação. Em tarefas longas, mantenha identificadores leves e recupere conteúdo quando a etapa exigir.

Exemplo:

índice de ADRs -> selecionar ADR relevante -> ler integralmente -> executar -> registrar decisão

Isso é melhor do que despejar cem ADRs na janela. A recuperação, porém, precisa de:

• fonte confiável;
• busca reproduzível;
• versão ou data;
• registro do que foi usado;
• fallback quando a fonte não está disponível.

Sistemas públicos de agentes diferenciam histórico, sessão, workspace e tools; essas implementações reforçam que contexto e ambiente são camadas, não um único prompt. [HARNESS31-C2]

O que deve sobreviver à sessão

Se uma informação é necessária para retomar, auditar ou corrigir, ela não deveria depender apenas do chat.

Externalize:

• decisão e motivação;
• estado do trabalho;
• artefatos criados;
• comandos ou testes relevantes;
• falhas ainda abertas;
• evidência coletada;
• próximos passos e condições;
• limites da conclusão.

Use arquivos versionados, issue, ADR, manifest, checkpoint ou outro registro apropriado. O formato depende do produto; o princípio é que consequência durável merece endereço durável.

Compactar sem reescrever a história

Um bom resumo de handoff separa:

Evite “tudo certo” ou “quase pronto”. Esses rótulos apagam o caminho de verificação.

Contexto também expira

Preço, disponibilidade de modelo, benchmark, lei e status operacional envelhecem. Registre:

• observado em;
• válido para;
• revisar depois de;
• fonte;
• decisão que depende do fato.

Quando a validade vence, o sistema deve buscar novamente ou bloquear a claim. Não permita que um texto antigo continue comandando uma decisão atual por inércia.

Subagentes como isolamento de contexto

Subagentes podem manter pesquisas ou especialidades separadas. Isso reduz competição de detalhes no agente principal, mas cria um novo contrato:

• tarefa delimitada;
• fontes permitidas;
• saída estruturada;
• incertezas preservadas;
• nenhum efeito fora do escopo;
• síntese final com atribuição.

Paralelismo não corrige pergunta ruim. Ele apenas produz respostas concorrentes mais rápido.

Um teste de qualidade do contexto

Antes de executar, pergunte:

1. o objetivo cabe em uma frase?
2. regras e exemplos estão distinguidos?
3. há fonte da verdade para cada fato material?
4. alguma informação sensível entrou sem necessidade?
5. o agente sabe o que não fazer?
6. o critério de pronto é verificável?
7. o estado poderá ser retomado sem esta conversa?

Depois, faça ablação: remova um bloco e observe se qualidade, custo ou risco mudam. Pesquisa pública de harness mostra que camadas adicionais podem elevar capacidade e também custo ou latência conforme a tarefa; o resultado não é universal. [HARNESS31-C3]

O que este artigo prova — e o que não prova

Fontes de fornecedores descrevem técnicas de seleção, recuperação, compactação e isolamento de contexto. Elas são orientação empírica, não padrão independente nem garantia de desempenho para toda aplicação.

Este artigo propõe um contrato de contexto para a FORGE. O conjunto ideal precisa ser testado por tarefa, modelo, risco e horizonte.

Conclusão

Context engineering não é empilhar conhecimento. É decidir o que o agente precisa perceber agora, o que pode buscar depois e o que a organização precisa preservar fora da sessão.

O melhor contexto não é o maior. É o que torna intenção, autoridade, estado e verificação difíceis de confundir.

Leitura anterior: Agentes de longa duração. Próxima leitura sugerida: A fila certa para IA.