Engenharia de prompt além do básico: o que muda quando você trabalha com agentes

Um prompt que funciona bem numa conversa pode falhar de formas silenciosas assim que ele vira parte de um agente. Você testa no chat, gosta da resposta, copia o texto para dentro de uma automação que roda sozinha, sem ninguém lendo cada saída, e alguns dias depois o processo trava, produz um formato errado ou executa uma ação que ninguém pediu. O prompt não mudou. O contexto de uso mudou por completo.

Essa é a diferença central entre escrever para conversa e escrever para agente. No chat, uma resposta ruim custa um reenvio. Num agente, uma resposta ruim vira uma etapa quebrada num fluxo que talvez ninguém esteja supervisionando em tempo real. As técnicas de base continuam as mesmas (clareza, contexto suficiente, exemplos bons), mas o padrão de qualidade exigido sobe, porque o prompt agora precisa se comportar bem em centenas de execuções, com entradas variadas, sem alguém corrigindo o rumo a cada rodada.

Chat pede resposta, agente pede comportamento

Numa conversa, o objetivo do prompt é obter uma boa resposta para uma pergunta específica. Num agente, o objetivo é definir um comportamento que se repete: como agir diante de uma entrada nova, quando parar, quando pedir mais informação, o que nunca fazer.

Essa mudança de objetivo pede um tipo diferente de instrução. Em vez de "resuma este texto", um agente de resumo precisa de regras sobre o que fazer se o texto vier vazio, se vier em outro idioma, se for grande demais para caber na janela de contexto, se contiver instruções embutidas que tentam mudar o comportamento do próprio agente. Nenhuma dessas situações aparece na primeira interação de teste no chat, mas todas aparecem eventualmente quando o volume de execuções cresce.

Exemplo prático: um agente de triagem de tickets de suporte recebe um prompt do tipo "classifique o ticket e sugira uma resposta". Funciona bem nos primeiros vinte testes. No teste vinte e um, chega um ticket em branco, porque o cliente só anexou um arquivo. O agente, sem instrução para esse caso, inventa uma classificação e uma resposta genérica, com a mesma confiança de sempre. Um prompt de chat deixaria essa dúvida para um humano decidir na hora. Um prompt de agente precisa responder essa pergunta sozinho, antes de o caso acontecer.

O papel do prompt de sistema quando há ação envolvida

Quando um agente só conversa, o prompt de sistema define tom e conhecimento. Quando um agente age (chama ferramentas, grava arquivos, envia mensagens, executa código), o prompt de sistema passa a ser também um contrato de escopo e de limites.

Isso muda o que precisa estar escrito ali:

• Papel e limite de autoridade: o que o agente tem permissão de decidir sozinho e o que exige confirmação de alguém.
• Ferramentas disponíveis e quando usar cada uma: não basta listar as ferramentas, é preciso dizer em que situação cada uma se aplica, para o agente não escolher a ferramenta errada por falta de critério.
• Condições de parada: em que ponto o agente deve considerar a tarefa concluída, e o que fazer se não conseguir concluir.
• O que está fora de escopo: tarefas parecidas que o agente não deve tentar resolver, mesmo que tecnicamente consiga.

Um prompt de sistema que só descreve personalidade ("você é um assistente prestativo e educado") não sustenta nada disso. Um prompt de sistema para agente se parece mais com uma descrição de função do que com uma instrução de estilo.

Contratos de saída: quando quem lê a resposta é outro sistema

No chat, quem lê a resposta é uma pessoa, que tolera variação de formato. Num agente, quem lê a resposta costuma ser outro sistema, um script, uma próxima etapa do fluxo, e essa etapa espera um formato específico para funcionar.

Isso exige tratar a saída como um contrato, não como um texto solto:

• Definir a estrutura esperada de forma explícita, com um schema, uma lista de campos obrigatórios ou um formato de dados como JSON.
• Especificar o que fazer quando um campo não tem valor disponível, em vez de deixar o modelo decidir se omite o campo ou preenche com algo inventado.
• Separar formato e conteúdo criativo em instruções distintas, porque a liberdade dada ao conteúdo tende a vazar para o formato quando as duas coisas se misturam.

Um contrato de saída bem definido reduz a superfície de erro do sistema inteiro. Se o formato é confiável, o código que consome a resposta pode validar antes de agir, e uma falha vira um erro claro em vez de um comportamento estranho três etapas depois.

Exemplo ensina forma, instrução ensina regra

Mostrar um ou dois exemplos do formato e do estilo esperado costuma ensinar melhor do que descrever esse formato em prosa. Um exemplo concreto transmite nuances de comprimento, tom e nível de detalhe que uma lista de regras não cobre bem.

Mas exemplos têm custo: cada exemplo ocupa espaço na janela de contexto, e em agentes de alto volume esse espaço é reprocessado a cada chamada. Por isso vale separar os dois casos de uso.

Use exemplos para transmitir formato, estilo e o padrão de uma boa resposta, sobretudo quando isso é difícil de descrever em palavras. Use instruções explícitas para regras de negócio, exceções e casos de borda, porque exemplo cobre mal condicionais como "se o cliente for pessoa jurídica, peça o CNPJ; se for pessoa física, não peça".

Misturar as duas coisas sem critério é o erro mais comum: prompts que acumulam exemplo atrás de exemplo tentando ensinar uma regra que caberia numa frase clara, inflando custo e tempo de resposta sem melhorar a consistência.

Avaliação: como saber se o prompt realmente funciona

No chat, a avaliação é implícita: se a resposta não serviu, a pessoa reformula a pergunta. Num agente que roda sozinho, ninguém está ali para reformular. Isso significa que a avaliação precisa acontecer antes de colocar o agente em produção, e continuar acontecendo depois.

Uma prática simples e eficaz é montar um pequeno conjunto de casos de teste, incluindo os casos difíceis (entrada vazia, entrada ambígua, entrada em formato inesperado), e rodar o prompt contra esse conjunto sempre que ele for alterado. Isso troca a pergunta "essa resposta parece boa?" pela pergunta certa: esse prompt se comporta bem de forma consistente, inclusive nos casos difíceis?

Vale observar também a variação entre execuções: o mesmo prompt, com a mesma entrada, pode gerar respostas diferentes em chamadas diferentes. Um prompt bem escrito para agente reduz essa variação nos pontos que importam (formato, decisão, ação), mesmo que mantenha alguma liberdade nos pontos que não importam, como fraseado ou ordem de explicação.

O que muda na prática

Escrever para um agente tem outro objetivo do que escrever para chat: em vez de uma boa resposta pontual, um comportamento confiável e repetível, com entrada e saída bem definidas, limites de autoridade claros e uma forma de verificar que continua funcionando conforme o agente e o negócio evoluem.

Se você já tem prompts em produção que nasceram de testes no chat, vale revisar cada um com estas perguntas: que ferramentas ele pode usar e sob qual critério, que formato de saída ele promete e quem consome isso, que casos de borda ele nunca viu. Essa revisão costuma expor onde um agente vai falhar antes que ele falhe em produção, e é um dos primeiros passos de um diagnóstico de IA aplicada ao negócio.