O contexto que você manda para o agente é o produto. Não o prompt.

Tem um momento específico em que você percebe que o problema não está no modelo.

Você testou localmente. Funcionou. O agente tomava decisões razoáveis, seguia o fluxo, gerava outputs coerentes. Você subiu para produção. Duas semanas depois, o sistema começa a tomar decisões que não fazem sentido. Não sempre. Não de forma previsível. Mas o suficiente para começar a acumular erros silenciosos que ninguém percebe de imediato.

Você começa a depurar o prompt. Ajusta o tom. Reescreve as instruções. Adiciona exemplos. O comportamento melhora um pouco. Mas o problema volta.

Eu passei por isso. E o diagnóstico demorou mais do que deveria porque eu estava olhando para o lugar errado.

O problema não estava no prompt. Estava no contexto que eu estava injetando junto com ele.

O que context engineering realmente significa em produção

Context engineering virou jargão. Mas antes de ser jargão, é um problema de engenharia concreto: o que você manda para o modelo determina o que o modelo vai fazer.

Isso parece óbvio. E é. Mas tem uma consequência que a maioria dos times ignora: se o contexto for ruim, ambíguo, desatualizado ou excessivo, o modelo vai produzir outputs ruins de forma determinística. Não porque o modelo é fraco. Porque você deu a ele informação ruim para trabalhar.

Um agente de produção não está "pensando" no vácuo. Ele está respondendo ao que está na janela de contexto. Cada decisão que ele toma é uma função do que você colocou lá.

Quando o agente tomava decisões erradas no sistema que mencionei, o que eu encontrei foi o seguinte: o contexto que chegava para o modelo incluía eventos de estado que já estavam obsoletos. A arquitetura de ingestão de contexto não tinha nenhum mecanismo de expiração. Eventos de horas atrás conviviam com eventos recentes, sem distinção de relevância temporal.

O modelo tentava conciliar tudo. E às vezes ele conciliava de formas que faziam sentido internamente mas eram completamente erradas para o estado real do sistema.

O problema que ninguém chama pelo nome certo

Eu chamo isso de Envenenamento por Contexto Acumulado.

Não é sobre o contexto ser errado desde o início. É sobre ele se tornar errado com o tempo, sem que nenhum mecanismo no sistema perceba ou corrija isso.

É um problema especialmente traiçoeiro porque:

Nos testes, o contexto é sempre limpo e atual.
Em produção, o contexto acumula histórico, estados transitórios, informações parciais e eventos que já perderam relevância.
O modelo não sabe distinguir o que é atual do que é ruído. Ele trata tudo com o mesmo peso, a menos que você instrua explicitamente o contrário.

A maioria dos times resolve isso adicionando mais instruções no prompt. "Priorize os eventos mais recentes." "Ignore informações contraditórias." Isso atenua. Não resolve.

A solução real fica na camada de ingestão, não na camada de instrução.

O que funciona melhor na prática

O contexto precisa ser tratado como um recurso gerenciado, não como uma string montada na hora.

Três princípios que mudaram como eu construo isso:

Contexto tem validade. Todo dado injetado deveria ter um TTL implícito ou explícito. Se um evento de estado tem mais de X minutos, ele precisa ser descartado ou marcado como histórico antes de entrar na janela de contexto. O modelo pode usar histórico. Mas ele precisa saber que é histórico.

Contexto tem hierarquia. Nem tudo que é relevante tem o mesmo peso. Informação de estado atual tem prioridade sobre log de eventos passados. Intenção explícita do usuário tem prioridade sobre inferência de comportamento anterior. Se você não estruturar essa hierarquia na montagem do contexto, o modelo vai tentar inferir ela. E vai errar em casos que você não testou.

Contexto tem custo de ambiguidade. Cada contradição dentro da janela de contexto é um ponto de falha potencial. Antes de injetar qualquer dado, a pergunta não é "isso é relevante?" mas "isso cria ambiguidade com alguma outra coisa que já está aqui?"

A decisão arquitetural que a maioria atrasa demais

Montar contexto inline, dentro da mesma função que chama o modelo, funciona nos primeiros ciclos. É rápido de implementar e fácil de rastrear.

Mas quando o sistema começa a ter múltiplos agentes, múltiplas fontes de dados e estados que mudam com frequência, esse padrão cria um problema que vai aparecer gradualmente: a lógica de seleção e filtragem de contexto fica espalhada. Cada chamada ao modelo tem sua própria versão de "o que é relevante agora". Nenhuma delas é testada isoladamente. Nenhuma delas é observável como unidade.

A mudança que fez diferença foi tratar context building como um módulo separado com responsabilidade única: receber o estado atual do sistema e produzir uma representação limpa, hierarquizada e com validade explícita para ser injetada no modelo.

Isso tem um custo. É mais código. É mais uma camada para manter. Mas é a camada que você vai precisar testar quando o agente começar a tomar decisões erradas em produção, e você vai agradecer ela existir separada.

O trade-off que ninguém menciona

Contexto mais rico não é sempre contexto melhor.

Existe uma tendência natural de injetar mais informação porque mais informação parece mais seguro. O modelo vai ter tudo que precisa. Não vai faltar nada.

Na prática, contexto excessivo degrada a qualidade das respostas de formas que são difíceis de rastrear. O modelo começa a dar atenção para partes do contexto que você não considerou relevantes. O sinal se dilui no ruído. E o output vira algo que é coerente com o contexto injetado mas errado para a situação real.

O paradoxo é que reduzir o contexto, ser mais cirúrgico no que você injeta, frequentemente melhora a qualidade das decisões do agente. Não porque o modelo ficou mais inteligente. Porque você removeu ambiguidade.

Isso vai contra o instinto de engenharia. A gente foi treinada a pensar que mais dados é sempre melhor. Em LLMs, mais dados é melhor só quando os dados certos estão no lugar certo.

O que eu faria diferente

Teria tratado o módulo de construção de contexto como sistema de primeira classe desde o início. Com testes unitários próprios. Com observabilidade própria. Com logs que mostram exatamente o que entrou na janela de contexto em cada chamada.

Sem isso, quando o agente falha, você está no escuro. Você tem o output errado e o prompt. Mas não tem visibilidade do que estava no contexto naquele momento específico. E depurar sem isso é adivinhar.

Observabilidade de contexto não é opcional em sistemas de produção. É a diferença entre um bug que você consegue reproduzir e um comportamento que você vai tentar explicar por semanas.

O modelo não é o produto. O prompt não é o produto. O produto é o sistema inteiro: como você coleta estado, como você filtra, como você hierarquiza, como você injeta, e o que você descarta antes de o modelo ver qualquer coisa.

Quando o agente erra, comece pelo contexto. Quase sempre é lá que o problema está.