O modelo não esqueceu. Você nunca explicou direito.

Num app financeiro com milhões de usuários, integramos um agente pra responder dúvidas sobre movimentações da conta. O modelo era bom. Os testes eram promissores. Em produção, o agente começou a dar respostas vagas, às vezes contraditórias, às vezes corretas mas inúteis.

A hipótese inicial foi "o modelo precisa de fine-tuning". Gastamos duas semanas nessa direção.

O problema real era outro: o agente não sabia quem era o usuário, em qual estado da jornada ele estava, nem o que havia acontecido nas últimas interações. O modelo recebia uma pergunta sem nenhum contexto operacional e tentava ser útil com o que tinha. Às vezes acertava por sorte.

Fine-tuning não resolve isso. Nenhum modelo resolve isso.

O erro que a maioria comete sem perceber

Existe uma crença implícita de que um LLM bom o suficiente vai compensar a falta de contexto. Que o modelo vai "inferir" o que está faltando, "deduzir" a intenção, "completar" os buracos.

Não vai.

Um LLM é uma máquina de completar sequências com base no que recebeu. Se o que ele recebeu é ambíguo, incompleto ou desconectado da realidade do sistema, a saída vai refletir exatamente isso.

O problema não está no modelo. Está no que chega antes do modelo.

Eu chamo isso de Ilusão da Inteligência Implícita: a suposição de que o modelo sabe coisas que ninguém nunca disse a ele.

Contexto não é o system prompt

Quando a maioria fala em "contexto", pensa no system prompt. Define o papel do agente, coloca algumas instruções, talvez um ou dois exemplos.

Isso é o mínimo. E o mínimo raramente é suficiente em produção.

Contexto real é um conjunto de camadas:

Contexto operacional: quem é o usuário agora, o que ele está tentando fazer, em qual etapa do fluxo ele está, o que aconteceu antes nesta sessão.

Contexto histórico: o que esse usuário fez nas últimas interações, quais problemas ele reportou, qual é o padrão de comportamento dele no sistema.

Contexto de estado: o estado atual do sistema, as entidades relevantes, os dados que o agente precisa pra tomar uma decisão informada.

Contexto de restrições: o que o agente pode e não pode fazer, quais ações têm consequências irreversíveis, onde ele deve parar e escalar pra um humano.

Quando qualquer uma dessas camadas está ausente, o agente começa a improvisar. E agente improvisando em produção é exatamente o que parece.

O problema do contexto que cresce e envelhece

Tem um segundo problema que aparece depois que você resolve o primeiro.

Você monta um contexto rico. O agente passa a funcionar bem. Então o histórico de interações cresce, os dados do usuário se acumulam, o sistema de estado fica mais complexo. O contexto que antes cabia confortavelmente na janela do modelo agora compete com tudo mais.

E você começa a cortar partes pra caber no limite de tokens.

Aqui está a decisão que mais vi ser tomada errado: cortar o contexto de forma linear, removendo as interações mais antigas. Parece razoável. Na prática, você às vezes remove exatamente a informação que explica o estado atual.

O usuário mencionou na terceira mensagem que estava com problema num pagamento específico. A décima mensagem faz sentido só com esse histórico. Você cortou a terceira pra economizar tokens. O agente perdeu o fio.

Contexto não é só volume. É relevância. E relevância é difícil de calcular de forma genérica.

O que funcionou melhor pra mim foi parar de pensar em "janela de contexto" e começar a pensar em "memória de trabalho com intenção". Quais são as informações sem as quais este agente não consegue resolver este problema agora? Essas ficam. O resto é negociável.

Tool calling não é atalho para contexto

Outro padrão que vi falhar algumas vezes: usar ferramentas (function calling / tool use) como substituto para contexto.

A lógica é: o agente vai buscar o que precisar quando precisar. Você não precisa colocar tudo no contexto inicial.

Isso funciona pra dados que genuinamente não fazem sentido carregar de antemão. Mas pra informações que definem quem é o usuário, o que ele quer e o que já aconteceu nessa conversa, não funciona.

Cada chamada de ferramenta é uma latência. É uma possibilidade de falha. É um ponto de acoplamento com um sistema externo.

E mais: quando o agente precisa chamar uma ferramenta pra entender o contexto básico da conversa, isso é sinal de que o sistema foi desenhado de fora pra dentro. Pensa no agente como o centro e constrói a infraestrutura ao redor. Na prática, o agente foi jogado por cima de um sistema existente e agora tenta reconstruir contexto que o sistema nunca surfaceou pra ele.

O agente deveria chegar na primeira mensagem já sabendo quem é o usuário, em qual estado ele está e o que é relevante agora. Não descobrir isso no meio da conversa.

O que mudou na minha abordagem

Eu comecei a tratar engenharia de contexto como uma disciplina separada da engenharia do agente.

São dois problemas distintos.

Engenharia do agente: quais ferramentas ele tem, como ele toma decisão, como ele lida com falhas, como ele escala pra humanos quando precisa.

Engenharia de contexto: o que chega pra ele antes de qualquer decisão ser tomada, como esse conteúdo é estruturado, como ele se mantém relevante ao longo da conversa, como ele envelhece de forma controlada.

Quando as duas estão misturadas, o sistema fica difícil de debugar. Você não sabe se o agente tomou uma decisão ruim porque a lógica dele é falha ou porque ele não tinha a informação certa.

Separar as duas camadas muda a forma como você diagnostica. E muda a forma como você evolui o sistema.

Trade-off honesto

Contexto rico custa. Custa tokens, custa latência, custa complexidade no sistema que prepara esse contexto.

Existe um ponto onde o custo de montar o contexto perfeito supera o custo de deixar o agente errar às vezes e tratar o erro de outra forma.

Isso é real. E vai depender do domínio. Num agente que toma decisão financeira, o custo de um erro é alto o suficiente pra justificar contexto mais caro. Num agente que sugere conteúdo, talvez não.

O que eu não recomendo é tomar essa decisão por default. A maioria dos times corta contexto porque é mais simples de implementar, não porque analisou o trade-off.

O que fica

Modelo ruim com contexto bom bate modelo bom com contexto ruim. Sempre.

Isso contraria o instinto de quem entra no problema querendo escolher o melhor modelo disponível. O modelo importa. Mas ele é o último fator na cadeia.

O sistema que você constrói ao redor do modelo é o que determina se aquele modelo vai se comportar como esperado em produção.

E esse sistema começa muito antes do prompt.