Engenharia de contexto: a disciplina que substituiu o 'prompt mágico'

Um agente que começou rápido e barato pode, meses depois, estar lento, caro e dando respostas piores. A primeira suspeita costuma cair sobre o modelo ou sobre o prompt, mas o problema mais comum é outro: a cada chamada, o agente carrega o histórico inteiro, todos os documentos, todas as decisões anteriores, empilhados na mesma janela. Trocar de modelo não resolve isso. O problema é de arquitetura de contexto, não de fraseado.

Engenharia de contexto é a disciplina que trata o que entra na janela do modelo como uma decisão de projeto, não como um detalhe de implementação. Ela substitui a ideia de um "prompt mágico" que resolve tudo por uma pergunta mais simples e mais útil: o que essa tarefa específica precisa saber agora, e o que pode ficar de fora?

A janela de contexto é orçamento, não depósito

Trate a janela de contexto como um orçamento, não como um depósito onde vale colocar tudo por precaução. Cada token que entra tem custo de tempo e de dinheiro, e tem também um custo de qualidade: uma janela maior não significa uma janela melhor. Quando a informação relevante está espalhada entre muito material irrelevante, a chance de o modelo usar exatamente o trecho certo no momento certo cai, não sobe.

Exemplo prático: um agente que responde perguntas sobre um produto carrega o manual inteiro, com dezenas de páginas, em toda chamada, mesmo quando a pergunta é sobre cobrança e o manual traz seções de instalação, garantia, resolução de problemas e especificações técnicas, nada disso relevante para a pergunta. Cada resposta fica mais lenta e mais cara sem ficar melhor, e o risco de o modelo misturar uma instrução de instalação com uma regra de cobrança aumenta, não diminui.

Carregamento pontual: dar só o que a tarefa pede

Em vez de antecipar tudo que o modelo pode vir a precisar e colar isso de uma vez no início, o carregamento pontual entrega a informação no momento em que ela é necessária para aquele passo específico, nem antes, nem a mais. Um pequeno núcleo de instruções fica sempre presente (identidade do agente, regras fixas, limites de segurança), e o resto é buscado sob demanda, conforme o que a tarefa atual exige.

Exemplo prático: um agente de suporte não precisa do catálogo inteiro de produtos em toda conversa. Ele precisa saber a que categoria o ticket atual pertence, o que é uma informação pequena, e então carregar apenas a seção de documentação daquela categoria. O catálogo completo fica fora da janela até virar de fato o assunto da conversa.

Roteadores de contexto: decidir o que entra antes de gastar tokens

Um roteador de contexto é um mecanismo, que pode ser tão simples quanto um arquivo de índice ou tão elaborado quanto um sistema de busca, que decide, a partir do tipo de tarefa, quais pedaços de contexto carregar, sem precisar carregar tudo só para tomar essa decisão. Funciona como um sumário que aponta para o capítulo certo em vez de entregar o livro inteiro a cada consulta.

Uma versão simples desse padrão é um índice curto do tipo "se a tarefa é X, carregue o documento A; se é Y, carregue o documento B", no lugar de um único documento gigante cobrindo tudo de uma vez. O custo de rotear é pequeno, algumas linhas de índice, comparado ao custo de não rotear, que é carregar material sem relação com a tarefa em cada chamada.

Esse índice também funciona como documentação viva da própria arquitetura de contexto. Quando alguém pergunta "por que esse agente carregou esse documento nessa chamada", a resposta está no roteador, não espalhada dentro de um prompt gigante que ninguém revisita. Isso facilita ajustar o sistema depois: adicionar uma nova categoria de tarefa vira uma linha nova no índice, não uma reescrita do prompt inteiro.

Memória em arquivo: parar de carregar tudo pelo histórico da conversa

Agentes de uso contínuo acumulam histórico. Se cada decisão passada, cada resposta anterior, fica dentro da conversa viva, a janela se enche de material antigo que volta a ser reprocessado a cada novo turno. Uma alternativa é registrar o que importa num arquivo de memória e carregar só o trecho relevante quando necessário, em vez de manter a conversa completa aberta para sempre.

Isso muda o que significa "lembrar" para um agente: o que conta é saber onde procurar, mais do que manter tudo dentro da conversa. Um arquivo de memória bem organizado, estruturado por assunto, deixa o agente recuperar exatamente o dado de que precisa para a tarefa atual sem arrastar junto tudo que veio antes.

Compactação: resumir para caber, com critério

Quando o histórico não pode ser evitado, mas cresce além do que é útil, a compactação resume a parte mais antiga numa versão menor, mantendo a essência e descartando o ruído. Isso é diferente de carregar de forma pontual: funciona como um recurso para quando o contexto completo já não cabe de jeito nenhum.

A troca envolvida importa: compactar economiza tokens, mas perde detalhe. Funciona bem para contexto que é mais pano de fundo do que operacional, quando um entendimento geral do que aconteceu basta e não é preciso reproduzir cada linha. Funciona mal quando uma decisão de várias etapas atrás precisa ser aplicada ao pé da letra agora, como um número exato ou um nome exato, porque o resumo pode ter suavizado exatamente o detalhe que importava.

O que isso muda em custo e qualidade

Combinar as quatro técnicas muda mais do que o custo por chamada, embora essa diferença já seja percebida ali. Muda o tipo de contexto com que o modelo trabalha: mais limpo, mais focado na decisão que precisa ser tomada. Um agente que precisa atravessar páginas de material irrelevante para encontrar o parágrafo que responde à pergunta desperdiça orçamento em três frentes ao mesmo tempo: dinheiro, tempo de resposta e precisão.

A ordem prática para aplicar isso: primeiro, mapear o que de fato é usado dentro do que hoje é carregado em cada chamada; cortar o que não é usado; separar o restante por tipo de tarefa para carregamento pontual; registrar em arquivo de memória as decisões que precisam persistir; e reservar a compactação para o histórico residual que genuinamente não cabe mais como documento separado.

Um exemplo juntando as quatro técnicas

Imagine um agente que analisa contratos recebidos por e-mail e prepara um resumo para o time jurídico interno. Sem engenharia de contexto, a versão mais simples desse agente carregaria, em toda execução, o histórico de todos os contratos já analisados, um glossário jurídico completo e as regras de todas as categorias de contrato possíveis, mesmo quando o contrato do dia é um simples aditivo de prazo.

Com as quatro técnicas combinadas, o desenho muda de forma direta. Um núcleo pequeno e fixo define o papel do agente e as regras gerais de como resumir um contrato. Um roteador identifica a categoria do contrato recebido (aditivo, prestação de serviço, confidencialidade) e carrega só o glossário e as regras daquela categoria, via carregamento pontual. Decisões recorrentes, como "aditivos de prazo abaixo de noventa dias não exigem alçada superior", ficam registradas num arquivo de memória, disponíveis quando um contrato daquele tipo aparece de novo, sem precisar repetir a explicação em toda execução. E o histórico de contratos já analisados, que não precisa ser revisitado linha a linha, fica disponível como um resumo compactado, útil para dar contexto geral sem pesar a janela.

O resultado é um agente que processa menos ruído a cada execução, sem depender de um modelo mais avançado para isso, o que se traduz em resposta mais rápida, custo menor por chamada e menos chance de o modelo misturar a regra de um tipo de contrato com outro.

Próximo passo

Se um agente do seu negócio ficou mais lento ou mais caro com o tempo, o primeiro diagnóstico costuma ser olhar o que está sendo carregado a cada chamada e por quê, antes mesmo de cogitar trocar de modelo. Esse mapeamento, o que entra na janela, quando e por que, costuma ser o ponto de partida de uma revisão de engenharia de contexto antes de qualquer ajuste de prompt.