Transpilação modular de prompts: tratando o control plane do agente como código

Quem já colocou um agente de IA em produção conhece o roteiro: começa com um único arquivo de system prompt, limpo e legível, e termina com um monólito onde convivem políticas de segurança, regras de domínio, formatação, protocolos de escalonamento e comportamento de ferramentas. Um artigo recente do Google Developers Blog, assinado pelo SRE Simerus Mahesh, defende uma tese direta: prompts em escala deixam de ser texto e viram artefato de build. A frase que resume o argumento é boa: "prompt maintainability becomes agent reliability".

Por que o prompt monolítico quebra

O texto identifica três modos de falha que aparecem quando o prompt cresce. O primeiro é o blast radius obscuro: em software normal, revisores raciocinam sobre o escopo de uma mudança via fronteiras de módulo e testes. Em um diff de system prompt, adicionar uma frase pode ter efeitos colaterais imprevisíveis em todo o agente. O segundo é o copy-paste drift: times duplicam lógica compartilhada (tratamento de PII, políticas de segurança, uso de serviços internos) e as cópias divergem. O terceiro são os erros diferidos para runtime: templates ad-hoc empurram a detecção de falha para o momento da execução, e você só descobre a variável faltando quando um workflow raro é acionado.

São problemas clássicos de engenharia de software, o que já entrega a solução proposta.

Prompt como artefato compilado

A ideia central é escrever arquivos de skill modulares em vez de um prompt único, e usar um transpilador para resolver imports e variáveis em um artefato final. O exemplo da fonte usa um agente de SRE com sintaxe de template estilo Jinja:

{% include "shared/safety.prompt.md" %}
{% include "shared/tool_usage.prompt.md" %}

You are an SRE triage agent operating in the {{ environment }} environment.

{% if allow_remediation %}
You may recommend remediation steps, but destructive actions require human approval.
{% endif %}

Com environment = production e allow_remediation = true, o transpilador gera um texto plano, sem condicionais nem includes, pronto para o modelo. O ganho é ter o melhor dos dois mundos: composição e reuso na autoria, e um artefato determinístico que dá para testar, auditar e comparar antes de chegar ao modelo. Cada include vira uma dependência e cada variável vira um requisito explícito.

Validação em build é o ponto que separa brinquedo de produção

Aqui está a parte que interessa a quem opera. Um transpilador digno de produção precisa rodar checagens em tempo de build, não em runtime: imports faltando, variáveis indefinidas e dependências circulares. A fonte sugere modelar cada fragmento como nó de um grafo dirigido, o que permite pegar imports recursivos que causariam falha silenciosa.

O detalhe mais interessante é o drift check via golden file. O CI regenera o prompt transpilado a partir da fonte e compara com o artefato commitado; se diferirem, o build falha. Isso elimina a lacuna entre o que está no repositório e o que roda em produção, um problema que qualquer um que já debugou "mas no meu prompt está diferente" reconhece.

Progressive disclosure e agentes que abrem PR

Dois padrões arquiteturais fecham o artigo. O primeiro é progressive disclosure: separar o control plane estável (identidade, limites de segurança, não-negociáveis) do contexto específico da tarefa. O prompt base compilado carrega o essencial; em runtime, o agente usa uma ferramenta para buscar só os módulos de skill necessários. Isso ataca o esgotamento de contexto e o custo em tokens, um problema real quando a biblioteca de skills cresce.

O segundo é mais ambicioso: o agente propor mudanças na própria camada de instruções. Resolveu um novo tipo de incidente? Pode redigir um módulo de skill, atualizar os imports e abrir um pull request. O ponto crucial, e bem colocado pela fonte, é que o agente não muta suas instruções em tempo real: ele propõe uma alteração de código, que passa pela mesma validação, evals e revisão humana de qualquer outro PR.

O que fica para quem constrói aqui

O artigo é conceitual e não entrega um transpilador pronto, o que é um limite a considerar antes de vender a ideia internamente. Mas a moldura é sólida e transferível: se você já tem CI/CD, o custo de adotar templates com validação e golden files é baixo, e o retorno em previsibilidade é alto. A escolha do engine importa (Jinja é o candidato óbvio em stacks Python), assim como definir cedo o que é control plane imutável versus skill carregável sob demanda. Para times brasileiros rodando agentes em suporte, triagem ou automação de processos, tratar prompt como artefato versionado e testável é menos hype e mais higiene de engenharia.

Fonte: Google Developers Blog