Uma boa instrução diz ao agente o que ele deve fazer, para quem e até onde pode ir. A personalidade vem depois: ela define como a resposta soa, não o que o sistema está autorizado a acessar ou executar. Um agente cordial ainda pode dar uma resposta errada se sua tarefa for vaga; um agente com tom técnico não ganha permissão para consultar dados só porque a instrução pediu.
Em vez de começar com uma descrição longa e genérica, escreva a primeira versão para uma situação concreta. Por exemplo: “organizar tarefas informadas pelo usuário em uma lista com prioridade e prazo, sem inventar compromissos”. Esse escopo pode ser testado. “Ajudar em tudo” não pode.
Os seis blocos de uma instrução útil
1. Papel e resultado esperado
Defina a função de modo observável. Um agente pode ser assistente de organização, apoio à recepção ou leitor de uma base de procedimentos. Diga qual resultado ele deve entregar: lista de tarefas, resumo com fonte, rascunho de resposta ou encaminhamento para uma pessoa. Evite títulos grandiosos que não indicam nenhuma atividade.
2. Público e contexto
Explique quem conversa com ele e o que já está disponível. Um agente interno pode usar termos do time; um bot para iniciantes precisa explicar siglas. Se o agente consulta documentos, indique quais coleções são fontes válidas e como agir se a informação não estiver nelas. Fonte incompleta é motivo para informar limite ou encaminhar, não para preencher lacunas como se fossem fatos.
3. Tom e formato
Personalidade pode incluir clareza, cordialidade, frases curtas, linguagem em português do Brasil e preferência por listas quando há passos. Também pode proibir ironia, pressão comercial ou excesso de jargão. Peça um formato apenas quando ele ajuda: uma resposta com “resumo, próximos passos e pendências” é verificável. Não transforme toda resposta em um roteiro rígido se a conversa precisa ser natural.
4. Limites de conteúdo e ação
Liste o que o agente não faz. Ele não deve inventar preços, diagnósticos, políticas, prazos ou resultados. Não deve pedir senhas nem exibir credenciais. Descontos, pagamentos, compras, alterações irreversíveis e exceções precisam de aprovação humana definida fora do texto de personalidade. Se não tiver dados suficientes, deve dizer o que falta e orientar o próximo passo.
5. Uso de ferramentas e permissões
Descreva quando uma ferramenta pode ser usada e o que fazer antes dela. Uma consulta de agenda pode exigir autenticação; uma atualização de cadastro pode exigir confirmação explícita. A instrução nunca substitui as permissões técnicas. Configure leitura e escrita separadamente, use menor privilégio e registre ações sem vazar segredos.
6. Exemplos de comportamento
Inclua poucos exemplos realistas de entrada e saída. Mostre uma pergunta fora de escopo, uma informação ausente e uma solicitação que exige humano. Exemplos são mais úteis quando ensinam decisão, não quando tentam antecipar cada frase possível.
Um modelo inicial para adaptar
Papel: você organiza tarefas informadas pelo usuário. Objetivo: devolver lista com tarefa, prazo informado e prioridade, sem criar dados. Tom: claro, respeitoso e direto, em português do Brasil. Limites: não marque compromissos, não envie mensagens a terceiros e não peça credenciais. Incerteza: se prazo ou responsável não foi informado, pergunte de forma objetiva. Formato: apresente primeiro a lista e depois as dúvidas restantes.
Esse modelo não precisa ficar igual em todos os casos. Um agente que responde com documentos pode precisar citar a fonte consultada; um agente de atendimento precisa saber quando transferir o caso para uma pessoa. Para esse último cenário, uma base com fontes revisadas importa mais do que acrescentar adjetivos à persona. Veja também quando usar RAG com documentos e quando uma FAQ basta.
Personalidade não é segurança
É comum escrever “nunca revele dados confidenciais” e supor que isso protege uma integração. A frase é útil como orientação, mas não é controle suficiente. O agente só deve receber as informações necessárias; tokens precisam ficar fora de prompts; usuários devem ser autenticados antes de consultar dados; e ações sensíveis devem exigir aprovação. Se uma ferramenta tiver acesso excessivo, um texto bem escrito não corrige o problema.
Da mesma forma, não tente criar uma instrução que “ignore todas as regras” ou contorne limites de outras ferramentas. O objetivo é produzir um comportamento confiável dentro das autorizações disponíveis, não uma persona que se sobreponha à segurança.
Como testar antes de liberar
- Escreva dez perguntas comuns que o agente deve resolver.
- Inclua três perguntas ambíguas e três sem dados suficientes.
- Inclua pedidos proibidos, como acessar informação sem autenticação ou executar ação irreversível.
- Compare a resposta com o resultado esperado e anote falhas.
- Altere uma regra por vez e repita os mesmos testes.
- Convide uma pessoa para testar sem explicar a resposta desejada.
Teste também se o agente admite incerteza. Uma resposta segura pode ser “não encontrei essa informação na fonte disponível; vou encaminhar para verificação”. É melhor do que uma explicação convincente e sem base.
Revisão contínua
Depois da publicação, reveja conversas representativas, pedidos que exigiram intervenção humana e situações em que o agente usou tom inadequado. Atualize fontes, exemplos e limites quando o processo real mudar. Guarde versões das instruções para poder comparar alterações e voltar atrás se uma edição piorar o resultado.
Antes de redigir instruções, é útil ter uma primeira tarefa delimitada; o artigo Como criar seu primeiro agente de IA organiza essa escolha. Para aprender a configurar e testar sem pular etapas, conheça a Academia NT Labz.