System prompt de produção: a espinha dorsal do comportamento do agente

Todo mundo que monta um agente acaba escrevendo um system prompt. Poucos param pra pensar no que aquele texto realmente é.

A maioria trata o system prompt como o lugar onde você "manda o modelo ser legal": "Você é um assistente prestativo e amigável". Pronto. Acha que terminou. Aí o agente chama uma ferramenta que não devia, vaza o tom errado pro cliente, ou trava na terceira mensagem porque ninguém disse o que ele pode e o que nunca pode fazer.

O system prompt não é firula de abertura. É a constituição do agente. É onde você define quem ele é, o que pode tocar, o que jamais deve fazer e em que formato responde. Neste post vou mostrar como estruturar um system prompt de produção — papel, políticas, ferramentas, formato — e por que ele joga num campeonato diferente de um prompt de chat qualquer.

TL;DR

• O que é: o system prompt é o contrato de comportamento que precede toda interação do agente — papel, escopo, políticas, uso de ferramentas e formato de saída.
• Stack/Modelos: vale pra qualquer LLM com system / developer role (Claude, GPT, Gemini) e pra qualquer harness de agente.
• Custo/Acesso: zero — é texto. O custo é de engenharia: escrever, testar e versionar direito.
• Link útil: Effective context engineering for AI agents (Anthropic) e o Model Spec da OpenAI.

O contexto: por que system prompt não é prompt de chat

Prompt de chat é uma pergunta. Vai, volta, acabou. Se a resposta não presta, você reescreve e tenta de novo. O ciclo de feedback é você, na hora, olhando a tela.

System prompt de agente é outra coisa. Ele é injetado antes de cada turno, em toda execução, muitas vezes sem ninguém olhando. O agente vai rodar em loop — percebe, decide, age, observa — e o system prompt é a única peça de contexto que está presente em 100% das iterações. Se ele estiver vago, o erro não aparece na primeira mensagem. Aparece na vigésima, quando o agente já chamou três ferramentas e tomou uma decisão que você não consegue reverter. (Se "loop percebe-decide-age-observa" soou novo, leia antes o que é um agente de IA — aqui parto do princípio que você já sabe o que separa um agente de um wrapper de prompt.)

Tem mais uma diferença que quase ninguém leva a sério: autoridade. No chat existe só você falando. Num agente existe uma hierarquia. O Model Spec da OpenAI descreve essa cadeia de comando de forma explícita: instruções de plataforma mandam mais que as de desenvolvedor, que mandam mais que as de usuário, que mandam mais que comportamentos-padrão. O system prompt (a parte do desenvolvedor) é onde você crava o que nenhum usuário consegue derrubar com um "ignore as instruções anteriores".

É isso que faz o system prompt ser a espinha dorsal. Ele não pede educadamente. Ele estabelece o que é inegociável antes de qualquer input entrar.

A anatomia de um system prompt de produção

Um system prompt sério tem quatro blocos. Não é decoração — cada um responde uma pergunta que o agente vai fazer em runtime.

1. Papel e contexto — quem é o agente?

Quem ele é, pra quem trabalha, qual o domínio. Não é biografia. É o enquadramento que faz o modelo escolher o vocabulário, o nível de detalhe e as suposições certas. "Você é um agente de suporte técnico de um SaaS de logística B2B" já corta metade das alucinações de contexto.

2. Políticas — o que ele pode e o que nunca deve fazer?

A parte que mais gente esquece e que mais dói em produção. Aqui entram os limites duros: o que está fora de escopo, que dados ele nunca expõe, quando ele tem que parar e pedir confirmação. O Model Spec é direto sobre ações de efeito irreversível em contexto agêntico — o agente deve favorecer caminhos "minimamente disruptivos e, quando possível, facilmente reversíveis", e definir um escopo de autonomia acordado: quais sub-objetivos ele pode perseguir, que efeitos colaterais (tempo, dinheiro, acesso a dados) são aceitáveis e quando ele precisa pedir aval antes de agir.

3. Ferramentas — como e quando usar cada uma?

A definição técnica da ferramenta (nome, schema) vive na API. O julgamento de quando usar vive no system prompt. "Use a busca no banco antes de responder sobre pedido; nunca invente número de rastreio" é a diferença entre um agente que consulta e um que chuta.

4. Formato de saída — como ele responde?

Tom, estrutura, idioma, tamanho. Se o output alimenta outro sistema, isso vira contrato: JSON, esse campo, esse enum. Se fala com humano, é o tom da marca. Em ambos os casos, vago aqui significa retrabalho lá na frente.

Mão na massa: estruturando o prompt

A recomendação da Anthropic em context engineering é organizar o prompt em seções distintas, com headers Markdown ou tags XML — o modelo distingue melhor blocos rotulados do que um muro de texto. Um esqueleto que funciona:

## Papel
Você é o agente de atendimento da Acme Logística. Responde dúvidas de
clientes B2B sobre status de pedido, prazo e faturamento.

## Políticas
- NUNCA exponha dados de outro cliente que não o autenticado na sessão.
- NUNCA invente número de rastreio, prazo ou valor. Se não está na ferramenta, diga que não tem.
- Cancelamento e reembolso são ações irreversíveis: confirme com o cliente
  e só execute após "sim" explícito.
- Fora de escopo (jurídico, RH, parcerias): encaminhe pro humano, não improvise.

## Ferramentas
- `buscar_pedido(id)`: use SEMPRE antes de afirmar qualquer dado de pedido.
- `abrir_chamado(motivo)`: só após confirmar que não resolveu na conversa.

## Formato
- Português do Brasil, tom direto e cordial, sem emoji.
- Máximo 4 frases por resposta, salvo quando listar itens de um pedido.

Repare em três decisões de engenharia ali dentro.

Primeiro: o "right altitude". A Anthropic chama assim o ponto certo de especificidade. Os dois extremos quebram. Hardcodar lógica frágil ("se o cliente disser X, responda exatamente Y") deixa o prompt impossível de manter. Mas dar só orientação vaga ("seja prestativo") não dá sinal nenhum pro modelo. O alvo é ser "específico o bastante pra guiar o comportamento, mas flexível o bastante pra dar ao modelo boas heurísticas". Você não escreve um fluxograma. Você contrata um sênior, dá os limites e sai da frente.

Segundo: políticas em negativo e em CAIXA ALTA pra o que é inegociável. "NUNCA exponha dados de outro cliente" pesa mais que "tente manter a privacidade". O modelo trata proibição explícita como restrição dura.

Terceiro: reforço por posição. Os engenheiros do Claude Code repetem a declaração de segurança no começo e no fim do system prompt de propósito — por causa da curva de atenção em U, onde o modelo presta mais atenção ao início e ao fim do contexto do que ao miolo. Se uma regra é crítica de verdade, ancore ela nas duas pontas.

E um conselho que economiza meses: comece pequeno. A própria Anthropic recomenda testar com um modelo capaz e um prompt mínimo, e só então adicionar instrução com base em falha observada — não encher o prompt de edge case que você imaginou no café. "Mínimo não quer dizer curto", mas quer dizer que cada linha está ali porque um teste mostrou que precisava estar.

Limitações e pontos de atenção

System prompt não é blindagem. É a primeira linha, não a única.

Ele não impede prompt injection sozinho. Um usuário mal-intencionado vai tentar sobrescrever suas instruções. A hierarquia de autoridade ajuda — o modelo sabe que o system prompt manda mais que o input do usuário — mas conteúdo que chega via ferramenta (uma página web, um e-mail, um documento) entra como dado e pode carregar instrução envenenada. É exatamente o vetor de prompt injection quando o site raspado vira o novo system prompt. Política no prompt reduz risco; não substitui validação de output e sandbox de ferramenta.

Ele compete por contexto. Cada token de system prompt é um token que se repete em toda chamada e some do orçamento disponível pro trabalho real. Prompt inchado não é prompt seguro — é prompt caro e mais difícil pro modelo seguir. Por isso o "mínimo set de tokens de alto sinal", e por isso vale ler o que entra e o que não entra na engenharia de contexto do agente.

Ele não se testa sozinho. Mudou uma linha de política? Isso é uma mudança de comportamento que precisa de eval, igual a deploy de código. Decidir o que o agente pode fazer sem confirmação é uma escolha de arquitetura — é o mesmo eixo dos 4 níveis de autonomia em agentic code: quem aprova, quem reverte, quem audita.

FAQ rápido

System prompt e developer message são a mesma coisa? Na prática, o papel é o mesmo: instrução de quem constrói, acima do usuário e abaixo da plataforma. A OpenAI separa system (regras da própria OpenAI) de developer (suas regras) no Model Spec; a maioria das APIs ainda chama tudo de system. Importa menos o nome e mais a posição na cadeia de comando.

Qual o tamanho ideal? O menor que cobre o comportamento esperado. Sem número mágico. Se você não consegue justificar por que uma linha está ali (qual falha ela previne), ela provavelmente não devia estar.

Posso colocar a data e o estado do projeto no system prompt? Contexto de runtime (data, status do git, regras do projeto) é melhor injetar via mensagem com tag XML do que cravar no system prompt estático — assim o modelo distingue o que é injeção do sistema do que é fala do usuário, e você preserva o cache do prefixo estático.

Como sei que meu system prompt funciona? Eval. Casos de teste que batem nas políticas: tentou vazar dado de outro cliente? recusou ação irreversível sem confirmação? Se você só testa "na mão" olhando a tela, está testando chat, não agente.

Conclusão

O system prompt é a espinha dorsal porque é a única peça presente em toda iteração do agente: define o papel, crava as políticas inegociáveis, governa as ferramentas e fixa o formato. Não é onde você manda o modelo ser legal — é onde você escreve o contrato que o usuário não consegue derrubar.

A maioria está mal escrita pela mesma razão: foi tratada como prompt de chat, não como engenharia. E essa é exatamente a diferença entre quem usa IA e quem constrói produto com IA — pensar system prompt como arquitetura, com escopo, autoridade, teste e versionamento. É esse tipo de decisão que a gente coloca na mesa, com código rodando, no Workshop Arquitetando Soluções de IA, onde o foco é arquitetar soluções de software com agents de verdade.

O próximo passo é parar de escrever system prompt no improviso e começar a versionar ele junto com o código — porque, no fim, comportamento de agente é decisão de engenharia. E decisão de engenharia se escreve, se testa e se revisa.