Nos três posts anteriores descrevi a inflação de contexto, as técnicas de compactação e a disciplina de poda e priorização que mantém a janela útil dentro do budget. Todos esses mecanismos operam sobre conteúdo variável: histórico, retrieval, tool results, turnos recentes. O system prompt é diferente porque é invariante por chamada e, ao mesmo tempo, é o elemento que mais se repete ao longo da vida operacional de um agente. Pra mim, essa combinação faz dele o vetor de custo mais subestimado em IA na produção, até porque cada token que sobra é multiplicado pelo número total de invocações do agente, que num cenário de SaaS tende a ordens de grandeza que ninguém estima na fase de design.
A aritmética é direta e desconfortável. Um system prompt de 4.000 tokens num agente que processa 100 mil chamadas por dia consome 400 milhões de tokens de entrada diariamente, antes de qualquer histórico ou retrieval. Num modelo como o Claude Sonnet 4.5, a US$ 3 por milhão de tokens de input, isso equivale a US$ 1.200 por dia, acumulando US$ 36.000 por mês pagos exclusivamente pra reenviar as mesmas instruções. Reduzir esse prompt pra 1.200 tokens, o que em quase todos os casos é viável sem perda funcional, derruba o custo fixo em 70% e libera budget de contexto pra retrieval e histórico, que são os elementos que de fato carregam informação útil pra resposta. O ganho é estrutural, e compõe ao longo do ciclo de vida do produto.
Na minha análise, a inflação de system prompts tem causas identificáveis, e todas elas convergem pro mesmo padrão de acúmulo sem remoção. Cada vez que o agente falha num caso específico, o time adiciona uma instrução pra cobrir aquele caso, sem remover instruções anteriores que se tornaram redundantes ou obsoletas. Depois de alguns trimestres, o prompt vira um sedimento de decisões locais, onde regras conflitantes convivem e o modelo precisa arbitrar entre elas a cada turno. Somam-se a isso os few-shot examples incluídos de forma defensiva, com variações redundantes que o modelo já generaliza a partir de dois ou três casos, além da duplicação entre system prompt e tool definitions, onde o comportamento esperado de uma ferramenta é descrito tanto no schema da tool quanto no prompt principal, quando o modelo já consome o schema diretamente.
O enxugamento começa pela separação entre o que é instrução estrutural e o que é conteúdo variável que nunca deveria estar no system prompt. Definições de persona, restrições de segurança e políticas de decisão de formato são estruturais e permanecem. Exemplos contextuais, instruções condicionais aplicáveis só a certos tipos de requisição e informações de estado do usuário são variáveis e devem migrar pro contexto dinâmico, injetadas apenas quando a query atual justifica sua presença. Essa separação reduz o prompt fixo e simultaneamente aumenta a precisão, porque o modelo deixa de processar instruções irrelevantes pra chamada em curso.
Depois da separação vem a consolidação. Instruções redundantes ou sobrepostas são reescritas em formulações únicas que capturam a intenção sem repetição. Listas de regras que começaram como bullets separados frequentemente podem ser compactadas em princípios mais gerais, sem perda de cobertura. Um prompt que enumera vetos por tópico ("não responda sobre política", e variações pra religião e pra outros temas controversos) pode ser substituído por uma regra única de escopo, que o modelo aplica com a mesma confiabilidade ocupando uma fração dos tokens. A métrica aqui é densidade informacional por token, e a revisão crítica do prompt frequentemente revela que 30% a 50% do conteúdo atual é redundância acumulada.
Resta então a modularização. Em sistemas com múltiplos fluxos, o system prompt único e genérico tende a acumular instruções específicas de cada fluxo, obrigando o modelo a carregar contexto irrelevante em toda chamada. A alternativa é manter um núcleo estrutural mínimo, compartilhado entre fluxos, e compor prompts específicos por rota de entrada, ativados apenas quando aquele fluxo é acionado. Na minha avaliação, essa decomposição exige infraestrutura de roteamento prévia à chamada do modelo, mas reduz drasticamente o custo fixo médio e melhora a previsibilidade do comportamento, até porque cada fluxo opera com um prompt focado em suas próprias regras.
A medição do impacto precisa ser contínua. O system prompt é o componente mais estável do sistema, o que cria a ilusão de que não precisa ser monitorado. Na prática, ele muda a cada ajuste de comportamento do agente, e essas mudanças se acumulam silenciosamente até que alguém revise o arquivo e descubra que ele cresceu 40% em seis meses. Tratar o prompt como código versionado, com revisão em pull request e contagem de tokens no pipeline de CI cobrindo casos críticos de regressão, converte um ativo invisível em ativo gerenciado. Sem essa disciplina, o prompt degrada pela mesma dinâmica que degrada o código: entropia por adição, sem remoção proporcional.
Há ainda um ganho que aparece só depois: system prompts enxutos reduzem custo e, ao mesmo tempo, melhoram a qualidade das respostas. Quando o modelo recebe menos instruções, aplica as que sobraram com mais consistência, porque há menos arbitragem entre regras e menos diluição de atenção. A correlação entre tamanho do prompt e confiabilidade do agente não é linear nem crescente; nos casos que acompanhei, prompts menores produzem comportamento mais previsível, com menor taxa de desvio do esperado. Pra mim, o prompt deixa de ser acumulador de correções e passa a ser um contrato estável, auditável e operacionalmente barato.