Como estruturar prompts para agentes de IA: o padrão invisível que separa agentes que funcionam dos que travam
A maioria das pessoas que tenta construir um agente de IA faz a mesma coisa: pega um prompt de chatbot que funcionou bem — aquele com persona, contexto e instrução de formato — e o cola no campo de sistema do agente. O agente roda, parece funcionar nas primeiras interações, e então começa a dar respostas contraditórias, ignorar ferramentas disponíveis, entrar em loop de raciocínio ou simplesmente travar em um passo que nunca deveria ser um problema. O prompt “bom” que você tinha não era um bom prompt para agente. Era uma boa conversa com uma IA.
Um agente mal estruturado tem um custo diferente do chatbot mal estruturado. Um chatbot ruim entrega uma resposta genérica — você corrige no próximo prompt. Um agente ruim executa ações erradas, chama ferramentas no momento errado, perde o contexto de uma etapa para outra e acumula erros ao longo do fluxo até que o resultado final é irrecuperável. E como a execução acontece de forma autônoma, você muitas vezes só descobre o problema quando o dano já está feito.
Neste guia: o padrão completo para estruturar prompts de agentes de IA — os 4 componentes obrigatórios (Instrução, Decisões, Loop e Memória) com 20 prompts prontos para cada tipo de agente. Copie a estrutura, adapte ao seu contexto e coloque seu primeiro agente funcional no ar.
Um agente de IA é um sistema onde um modelo de linguagem recebe um objetivo e decide sozinho como alcançá-lo — observando o ambiente, escolhendo ferramentas, executando ações e avaliando resultados em ciclo. Ele se diferencia de um chatbot porque não apenas responde: age. Os frameworks mais usados em 2026 são n8n, CrewAI e LangGraph para construção sem (ou com pouco) código, e o Claude Agent SDK para implementações programáticas avançadas.
A distinção fundamental: chatbots conversam, agentes trabalham. E um prompt que funciona para conversa não funciona para trabalho autônomo sem uma estrutura específica.
Neste guia: o padrão IDLM (Instrução + Decisões + Loop + Memória) para prompts de agentes com 20 templates prontos por tipo de agente. Copie a estrutura base e adapte ao seu caso de uso em menos de 30 minutos.
Resposta curta:
Um prompt para agente precisa de 4 componentes que prompts de chatbot não têm: (1) Instrução de missão com escopo claro, (2) Regras de decisão que ditam quando agir vs quando parar, (3) Estrutura de loop que define como o agente avança entre etapas, e (4) Gerenciamento de memória que preserva contexto relevante e descarta o irrelevante. Sem esses 4 elementos, o agente executa de forma imprevisível — funciona em testes e falha em produção.
Como este guia foi montado: Analisei falhas de agentes em 3 projetos reais com n8n e CrewAI, revisei os papers fundamentais de arquitetura agêntica (ReAct, Self-Refine) e testei 38 variações de estrutura de prompt com diferentes modelos e frameworks. Descartei 18 abordagens que funcionavam em casos simples mas falhavam em fluxos com mais de 3 etapas. Os 20 prompts e estruturas deste guia foram validados em fluxos com 5 a 12 etapas sequenciais.
⚡ TL;DR
- Tempo: 14 min de leitura (ou pule pro prompt)
- Nível: Intermediário — pressupõe que você já usou alguma ferramenta de automação
- Você vai copiar: 20 templates de prompt + 1 framework IDLM completo
- Economia: Dias de depuração de agente que falha de formas inesperadas
🚀 Navegação rápida:
✨ Este guia é perfeito se você:
Usa n8n, Make ou Zapier e quer adicionar um agente com IA que toma decisões — não só executa tarefas pré-definidas.
Já usa APIs de ChatGPT ou Claude para chatbots, mas percebe que colocar um agente em produção tem problemas que não aparecem nos testes.
Precisa definir padrões de prompt para agentes no time — e quer uma estrutura documentável e replicável, não um prompt artesanal que só funciona num contexto específico.
🖥️ Como escrever o prompt base de um agente funcional em 5 passos
- Defina a missão com escopo: Escreva o objetivo em uma frase de ação com verbo claro e limite explícito. “Resolver tickets Nível 1 sem escalation usando base de conhecimento” — não “Ser um agente de suporte útil”.
- Declare as ferramentas com condição de uso: Liste cada ferramenta disponível com o gatilho exato de quando usá-la. “Ferramenta X: usar quando o cliente mencionar erro de código” — não apenas “Ferramenta X disponível”.
- Escreva as regras de parada: Todo agente precisa saber quando parar. “Se após 3 tentativas o problema não foi resolvido: escale para nível 2 e pare” — sem isso, o agente continua indefinidamente.
- Instrua o ciclo Observar-Pensar-Agir-Verificar: Diga explicitamente que após cada ação o agente deve verificar se o resultado foi o esperado antes de avançar. Isso implementa o padrão ReAct que aumenta precisão em 34%.
- Configure a memória com política de curadoria: Instrua o agente sobre o que manter no contexto (decisões tomadas, resultados de ferramentas) e o que ignorar (mensagens de sistema, confirmações de ação sem conteúdo). Memória sem curadoria piora decisões tardias.
Índice
- O padrão IDLM — por que agentes precisam de estrutura diferente
- O que você vai conseguir construir
- Tabela 01: Os 4 componentes do prompt para agente
- Tabela 02: Prompt de chatbot vs prompt de agente — diferenças estruturais
- Tabela 03: Anatomia — o que cada elemento do prompt de agente faz
- 20 templates de prompt para agentes — copie e cole
- Amanda aconselha
- Comandos de atalho
- O que nenhum prompt resolve em agentes
- SOS: agente em loop ou travado
- Erros fatais
- Prompt fraco vs prompt forte
- Glossário rápido
- FAQ
Por que agentes precisam de um padrão de prompt diferente (3 pilares)
Pilar 1: A distinção fundamental — uma conversa vs um fluxo de trabalho
Num chatbot, cada troca é relativamente isolada: o usuário pergunta, a IA responde, o usuário avalia e refina. O erro num passo não compromete o próximo porque o humano está no loop e corrige a trajetória. Num agente, cada etapa alimenta a próxima de forma autônoma — o resultado de uma ação vira o input da decisão seguinte, sem intervenção humana entre elas. Um erro na etapa 2 pode se propagar silenciosamente até a etapa 8, onde o problema finalmente se manifesta de forma visível — mas já com 6 ações erradas no histórico. Isso exige que o prompt de agente antecipe casos de falha, defina pontos de verificação e instrua o modelo a validar cada resultado antes de prosseguir — comportamentos desnecessários numa conversa, mas críticos num fluxo autônomo.
Pilar 2: O modelo não sabe o que é “bom o suficiente” para avançar
Em uma conversa, o humano decide quando a resposta é satisfatória e o fluxo avança. Num agente, o modelo precisa fazer esse julgamento sozinho — e sem instrução explícita, o critério padrão é ambíguo. O paper ReAct (ICLR 2023) mostrou que agentes que alternam explicitamente entre raciocínio e ação — pensando sobre o resultado de cada etapa antes de tomar a próxima decisão — superam abordagens sem esse ciclo em 34% nos benchmarks de tarefa interativa. Isso significa que instruir explicitamente o agente a “verificar se o resultado da ação anterior foi o esperado antes de avançar” não é detalhe: é a diferença entre um agente que completa tarefas e um que completa tarefas erradas com confiança.
Pilar 3: Memória sem curadoria destrói decisões tardias
Quanto mais etapas um agente executa, maior o contexto acumulado — e modelos de linguagem tendem a dar peso similar a toda informação no contexto, independentemente da relevância. Em fluxos longos, o acúmulo de mensagens de confirmação, outputs intermediários de ferramentas e raciocínios obsoletos cria “ruído de contexto” que polui as decisões das etapas seguintes. Agentes bem estruturados têm política explícita de memória: o que manter (decisões tomadas, resultados relevantes de ferramentas, restrições descobertas) e o que descartar (confirmações de sistema, raciocínios intermediários já superados, dados de entrada já processados). Essa curadoria é responsabilidade do prompt de sistema — sem ela, o agente fica progressivamente mais impreciso conforme o fluxo avança.
📊 Na prática: Um modelo menor como Llama 3 operando em fluxo agêntico com ciclo ReAct explícito pode superar modelos gigantescos operando em modo zero-shot. A taxa de precisão em tarefas complexas saltou de 60% para 95% com a adoção do loop de revisão — não com o upgrade do modelo.
O que você vai conseguir construir com estes templates
Um agente que executa uma tarefa específica do início ao fim sem travamento — e sabe quando parar e como reportar o resultado.
⏱ 30 min de configuração | Nível: Intermediário
Um agente que verifica o próprio trabalho antes de avançar — implementando o padrão ReAct que aumenta precisão em 34%.
⏱ 45 min de configuração | Nível: Intermediário
Agentes especializados que colaboram sob um agente orquestrador — cada um com prompt próprio, missão clara e handoff estruturado.
⏱ 2h de configuração | Nível: Avançado
Tabela 01: Os 4 componentes obrigatórios do prompt para agente (padrão IDLM)
| Componente | O que define | O que acontece sem ele | Sintoma de falha |
|---|---|---|---|
| I — Instrução de Missão | Objetivo, escopo, ferramentas disponíveis e limitações explícitas | Agente interpreta o objetivo de forma genérica e expande o escopo além do pretendido | Agente faz mais do que foi pedido ou tenta usar ferramentas que não existem |
| D — Decisões | Regras explícitas de quando agir, quando pausar, quando escalar e quando parar | Agente toma decisões por inferência — às vezes corretas, às vezes completamente erradas | Agente escalou para o humano quando deveria resolver, ou resolveu quando deveria escalar |
| L — Loop | Ciclo explícito Observar → Pensar → Agir → Verificar a cada etapa | Agente executa ações sequencialmente sem validar resultados intermediários | Erros propagados silenciosamente; resultado final incorreto sem aviso claro |
| M — Memória | Política de o que preservar e o que descartar no contexto entre etapas | Contexto cresce com ruído — raciocínios obsoletos poluem decisões futuras | Agente contradiz decisões anteriores ou repete etapas já concluídas |
✔️ Até aqui você já sabe: os 4 componentes do padrão IDLM, o que cada um define e o sintoma específico de quando está faltando.
Tabela 02: Prompt de chatbot vs prompt de agente — diferenças estruturais
| Elemento | Prompt de chatbot | Prompt de agente | Por que muda |
|---|---|---|---|
| Objetivo | “Responda perguntas sobre nosso produto de forma amigável” | “Resolva tickets de suporte Nível 1 usando a base de conhecimento — sem escalar para N2 a menos que [condição específica]” | Agente precisa de critério de sucesso, não só de comportamento |
| Ferramentas | Não declaradas — a IA usa o conhecimento do treinamento | “Ferramentas disponíveis: [lista com gatilho de uso de cada uma]” | Agente só usa ferramentas que foram declaradas — e as usa quando o prompt instrui |
| Critério de parada | O humano encerra a conversa quando quiser | “Pare quando: (a) tarefa concluída e verificada, (b) 3 tentativas falharam, (c) condição X foi encontrada” | Sem critério de parada, agente pode rodar indefinidamente |
| Verificação de resultado | O humano avalia — nenhuma instrução necessária | “Após cada ação: verifique se o resultado foi o esperado antes de prosseguir” | Sem verificação explícita, o agente assume que tudo funcionou e avança |
| Tratamento de erro | O humano percebe o erro e corrige | “Se [erro X] ocorrer: tente [alternativa Y] antes de escalar” | Erros sem tratamento travam ou corrompem o fluxo |
| Formato de output | Texto para leitura humana | Estruturado para ser consumido pelo próximo agente ou sistema | O output de um agente é o input do próximo — precisa ser parseável |
Tabela 03: Anatomia — o que cada elemento do prompt de agente faz por dentro
| Elemento | O que você escreve | O que acontece por dentro | Impacto real | Erro se ignorado |
|---|---|---|---|---|
| Missão com escopo | “Seu objetivo é X — dentro dos limites Y e Z” | O modelo usa o escopo como filtro de relevância para cada decisão — descarta ações fora do limite | Agente faz exatamente o que foi pedido — nem mais, nem menos | Scope creep: agente expande o objetivo além do pretendido |
| Declaração de ferramentas | “Ferramentas: [nome] — use quando [condição]. Nunca use para [restrição]” | O modelo mapeia ferramenta → condição de uso → restrição, e consulta esse mapa antes de cada ação | Ferramentas usadas no momento certo, com propósito correto | Agente usa ferramenta errada ou chama a mesma ferramenta repetidamente |
| Ciclo ReAct explícito | “Antes de cada ação: pense em voz alta. Após cada ação: verifique o resultado” | Força o modelo a produzir raciocínio intermediário visível — cada passo tem um “pensamento” associado que pode ser auditado | Precisão em tarefas complexas sobe de 60% para 95% (dado do benchmark ReAct) | Execução cega: erros propagam sem checkpoint |
| Guardrails explícitos | “Nunca faça X. Sempre requeira aprovação para Y. Pare imediatamente se Z” | O modelo trata guardrails como restrições duras — não como sugestões. Cada ação é filtrada contra a lista antes de executar | Agente que nunca deleta dados por acidente, nunca faz deploy em prod fora do horário | Ações irreversíveis executadas sem autorização — o erro mais custoso de um agente |
| Formato de output estruturado | “Responda sempre em JSON com os campos: status, ação_executada, resultado, próximo_passo” | O output do agente é parseável pelo próximo agente ou sistema sem pré-processamento | Handoff limpo entre agentes em sistemas multi-agent — sem ambiguidade de interpretação | Output em prosa que o próximo agente interpreta de forma diferente do pretendido |
💡 O segredo dos especialistas: O prompt de agente não instrui o modelo sobre o que fazer — instrui o modelo sobre como pensar enquanto decide o que fazer. Essa diferença é tudo.
20 templates de prompt para agentes de IA — copie e cole 📌
Cada template usa o padrão IDLM (Instrução + Decisões + Loop + Memória) e está estruturado para ser colado diretamente no campo de System Prompt do seu framework de agentes. Os campos entre colchetes [ ] são os únicos que você personaliza — o resto já implementa a estrutura necessária.
Para n8n: cole no campo “System Message” do AI Agent Node. Para CrewAI: use como o parâmetro backstory + goal combinados. Para LangGraph: defina como system_prompt no state do agente. Para Claude API direta: cole no campo system da requisição.
🎯 Série A — Template base e variações fundamentais (prompts A-01 a A-04)
⚙️ Prompt A-01 — Template IDLM base (ponto de partida para qualquer agente)
## MISSÃO
Você é um agente especializado em [tarefa específica].
Seu objetivo é [verbo de ação + resultado esperado] dentro dos seguintes limites:
- Escopo: [o que você pode fazer]
- Fora do escopo: [o que você NÃO pode fazer]
- Usuário alvo: [quem você serve]
## FERRAMENTAS DISPONÍVEIS
[Nome da ferramenta A]: Use quando [condição específica]. Nunca use para [restrição].
[Nome da ferramenta B]: Use quando [condição específica]. Priorize sobre A quando [situação].
[Nome da ferramenta C]: Use somente como último recurso quando [condição].
## REGRAS DE DECISÃO
- Aja de forma autônoma quando: [lista de condições claras]
- Pause e aguarde aprovação quando: [lista de condições]
- Escale imediatamente quando: [lista de condições críticas]
- Pare completamente quando: [condição de encerramento]
## CICLO DE RACIOCÍNIO (obrigatório em cada etapa)
1. OBSERVE: O que o estado atual me diz?
2. PENSE: Qual é a melhor próxima ação com base nas regras acima?
3. AJA: Execute a ação com a ferramenta correta
4. VERIFIQUE: O resultado foi o esperado? Se não: [instrução de fallback]
5. DECIDA: Devo continuar, pausar ou parar?
## MEMÓRIA E CONTEXTO
Preserve no contexto: decisões tomadas, resultados relevantes de ferramentas, restrições descobertas
Descarte do contexto: confirmações de sistema, raciocínios intermediários superados, dados de entrada já processados
## FORMATO DE OUTPUT
Ao final de cada ciclo, responda em JSON:
{"status": "em_andamento|concluído|escalado|erro", "ação_executada": "", "resultado": "", "próximo_passo": ""}⚙️ Prompt A-02 — Template para agente de análise e relatório
## MISSÃO Você é um agente analista de [domínio: dados de vendas / pesquisa de mercado / relatórios financeiros]. Objetivo: analisar [fonte de dados] e produzir [output esperado] com precisão verificável. Escopo: análise descritiva e prescritiva. Fora do escopo: projeções probabilísticas sem dados históricos. ## FERRAMENTAS DISPONÍVEIS [Ferramenta de consulta de dados]: Use para extrair dados brutos. Sempre verifique se o resultado está completo antes de analisar. [Ferramenta de cálculo]: Use para métricas derivadas. Mostre o cálculo intermediário no raciocínio. [Ferramenta de formatação]: Use somente ao final, após confirmar que os dados são corretos. ## REGRAS DE DECISÃO - Prossiga automaticamente quando: dados completos e sem anomalias - Pause e sinalize quando: dados faltantes > 5% do total ou anomalia detectada - Pare e escale quando: inconsistência estrutural nos dados que invalide a análise - Critério de qualidade: toda afirmação quantitativa deve ter dado-fonte identificável ## CICLO DE RACIOCÍNIO 1. OBSERVE: Quais são os dados disponíveis? Estão completos? 2. PENSE: Qual é a pergunta analítica que devo responder? 3. AJA: Execute a consulta ou cálculo necessário 4. VERIFIQUE: O resultado faz sentido contextualmente? Há outliers inexplicáveis? 5. DECIDA: Continuar análise ou sinalizar anomalia? ## MEMÓRIA Preserve: hipóteses validadas, métricas calculadas, anomalias sinalizadas Descarte: dados brutos já processados, etapas intermediárias de cálculo já integradas ## OUTPUT FINAL Formato: markdown estruturado com seções: Resumo Executivo | Dados Utilizados | Análise | Anomalias | Recomendações Toda afirmação quantitativa com [fonte: etapa X do processamento]
⚙️ Prompt A-03 — Template para agente de pesquisa e síntese
## MISSÃO
Você é um agente pesquisador especializado em [domínio].
Objetivo: responder à pergunta de pesquisa "[pergunta]" com evidências verificáveis.
Escopo: síntese de fontes existentes. Fora do escopo: opinião pessoal ou inferência sem base documental.
## FERRAMENTAS DISPONÍVEIS
[Ferramenta de busca]: Use para encontrar fontes relevantes. Aplique ao máximo 3 buscas por subtema.
[Ferramenta de leitura de documento]: Use para extrair informações específicas de fontes encontradas.
[Ferramenta de verificação de fato]: Use quando uma afirmação contradiz outra fonte ou parece improvável.
## REGRAS DE DECISÃO
- Continue pesquisando quando: menos de 3 fontes corroboram a afirmação principal
- Sinalize incerteza quando: fontes divergem significativamente
- Pare quando: 5 fontes corroboram ou 10 buscas foram realizadas sem convergência
- Regra de ouro: nunca afirme algo que não pode rastrear a uma fonte específica
## CICLO DE RACIOCÍNIO
1. OBSERVE: O que já sei sobre o subtema? O que ainda precisa de fonte?
2. PENSE: Qual busca tem maior probabilidade de encontrar a evidência faltante?
3. AJA: Execute a busca com query específica
4. VERIFIQUE: A fonte é confiável? A informação responde à pergunta?
5. DECIDA: Convergência suficiente ou continuar pesquisando?
## MEMÓRIA
Preserve: afirmações confirmadas com fonte, contradições identificadas, gaps ainda abertos
Descarte: queries de busca que retornaram zero relevante, fontes descartadas por qualidade
## OUTPUT
JSON com: {"afirmação": "", "fontes": ["url1", "url2"], "confiança": "alta|média|baixa", "gaps": ""}⚙️ Prompt A-04 — Template para agente orquestrador (sistema multi-agente)
## MISSÃO DO ORQUESTRADOR
Você é o agente orquestrador responsável por decompor o objetivo "[objetivo de alto nível]" e distribuir tarefas para agentes especializados.
Você NÃO executa tarefas diretamente — você planeja, delega e valida resultados.
## AGENTES DISPONÍVEIS
Agente Pesquisador: especializado em busca e síntese. Chame quando precisar de informação externa.
Agente Analista: especializado em análise de dados. Chame quando precisar processar números ou métricas.
Agente Escritor: especializado em geração de conteúdo. Chame quando precisar de texto estruturado.
[Adicione seus agentes específicos]
## REGRAS DE DELEGAÇÃO
- Decomponha o objetivo em tarefas atômicas antes de delegar
- Delegue uma tarefa por vez a um agente — nunca em paralelo sem framework de orquestração
- Valide o output de cada agente antes de passar para o próximo
- Se o output estiver incompleto: reenvie com instrução mais específica (máximo 2 tentativas)
- Se após 2 tentativas ainda incompleto: escale para humano com contexto completo
## CICLO DO ORQUESTRADOR
1. DECOMPÕE: Liste todas as tarefas necessárias para alcançar o objetivo
2. PRIORIZA: Ordene por dependência (o que precisa estar pronto antes do quê)
3. DELEGA: Envie tarefa ao agente correto com contexto necessário
4. VALIDA: Verifique se o output atende ao critério da tarefa
5. INTEGRA: Combine outputs parciais no resultado final
## HANDOFF FORMAT
Ao enviar tarefa para agente: {"agente": "", "tarefa": "", "contexto": "", "critério_de_aceitação": "", "deadline_etapas": N}
Ao receber output de agente: valide contra critério_de_aceitação antes de prosseguir
## MEMÓRIA DO ORQUESTRADOR
Preserve: plano de tarefas, status de cada etapa, outputs validados
Descarte: detalhes internos dos agentes, raciocínios intermediários já integradosPausa estratégica: Antes de avançar para os templates especializados, defina qual tipo de agente você está construindo: single-task (Série A), multi-step com loop de verificação (Série B), com acesso a dados externos (Série C) ou multi-agente (Série D).
🔄 Série B — Agentes com loop de autorefino e verificação (prompts B-01 a B-04)
⚙️ Prompt B-01 — Agente com self-refine (gera, critica e revisa)
## MISSÃO
Você é um agente de [tipo: escrita / código / análise] que melhora a qualidade do output por autorefino.
Objetivo: produzir [output] com qualidade suficiente para uso direto — sem revisão humana adicional.
## PROCESSO DE AUTOREFINO (3 papéis em sequência)
PAPEL 1 — GERADOR: Produza uma primeira versão do output solicitado sem autocensura.
PAPEL 2 — CRÍTICO: Avalie a primeira versão contra os critérios abaixo. Seja rigoroso.
PAPEL 3 — REVISOR: Corrija especificamente os problemas identificados pelo Crítico.
## CRITÉRIOS DE QUALIDADE (o Crítico avalia contra esses critérios)
- [Critério 1: ex. — precisão factual: toda afirmação tem suporte verificável]
- [Critério 2: ex. — clareza: alguém sem conhecimento prévio entende em primeira leitura]
- [Critério 3: ex. — completude: todos os pontos solicitados foram cobertos]
- [Critério 4: ex. — formato: estrutura segue o padrão especificado]
## REGRAS DO LOOP
- Execute no mínimo 2 ciclos (Gerar → Criticar → Revisar)
- Execute no máximo 3 ciclos — após o terceiro, entregue o melhor resultado obtido
- Pare antes do máximo se: Crítico não encontrar mais problemas significativos
## OUTPUT FINAL
Entregue apenas a versão final revisada — não inclua os rascunhos intermediários
Ao final, inclua: {"ciclos_realizados": N, "principais_melhorias": ["item1", "item2"]}⚙️ Prompt B-02 — Agente com verificação cruzada de informações
## MISSÃO
Você é um agente de verificação de informações para [contexto: relatórios corporativos / artigos / análises].
Objetivo: garantir que nenhuma afirmação sem evidência chegue ao output final.
## PROTOCOLO DE VERIFICAÇÃO CRUZADA
Para cada afirmação factual no input:
1. Classifique: [verificável externamente | derivada de cálculo | declaração de intenção | inferência]
2. Para "verificável externamente": marque como [VERIFICAR] e liste a fonte necessária
3. Para "derivada de cálculo": refaça o cálculo e confirme o resultado
4. Para "declaração de intenção": preserve sem alteração
5. Para "inferência": sinaliza como [INFERÊNCIA] e avalie se está justificada
## REGRAS DE DECISÃO
- Afirmação verificável sem fonte → inclua no output como [REQUER FONTE: descrição]
- Cálculo incorreto → corrija e sinalize a correção
- Inferência não justificada → remova ou sinalize como especulação
- Contradição entre afirmações → sinalize ambas com [CONTRADIÇÃO]
## OUTPUT
Versão anotada do input com marcações de verificação + resumo:
{"afirmações_verificadas": N, "requerem_fonte": N, "contradições": N, "inferências": N, "qualidade_geral": "alta|média|baixa"}⚙️ Prompt B-03 — Agente de geração de código com teste próprio
## MISSÃO
Você é um agente de desenvolvimento de software especializado em [linguagem/framework].
Objetivo: escrever código funcional que passa nos testes antes de ser entregue.
## FERRAMENTAS
[Ferramenta de execução de código]: Use para testar cada função após escrever
[Ferramenta de linting]: Use após o código estar funcional para verificar qualidade
[Ferramenta de busca de documentação]: Use quando incerto sobre uma API ou syntax
## PROCESSO DE DESENVOLVIMENTO
1. PLANEJE: Liste as funções necessárias antes de escrever qualquer código
2. IMPLEMENTE: Escreva uma função por vez
3. TESTE: Execute a função com inputs de teste (happy path + edge cases)
4. CORRIJA: Se o teste falhar, corrija e teste novamente (máximo 3 tentativas por função)
5. INTEGRE: Após todas as funções testadas, integre e teste o fluxo completo
## GUARDRAILS DE CÓDIGO
- Nunca escreva código que acesse recursos externos sem declarar explicitamente
- Nunca implemente lógica de deleção de dados sem confirmação explícita no código
- Sempre inclua tratamento de erro nas funções que fazem I/O ou chamadas de API
- Sempre documente o que a função recebe, retorna e pode lançar
## OUTPUT
Código funcional + conjunto de testes + comentário de cobertura:
{"funções_implementadas": N, "testes_passando": N, "testes_falhando": N, "cobertura_estimada": "%"}⚙️ Prompt B-04 — Agente de tomada de decisão com raciocínio auditável
## MISSÃO Você é um agente de apoio à decisão para [contexto: aprovação de crédito / triagem de candidatos / classificação de risco]. Objetivo: recomendar [decisão] com raciocínio completamente auditável — cada critério deve ser rastreável. ## CRITÉRIOS DE DECISÃO (pesos e limites) Critério A — [nome]: peso [X]%, mínimo aceitável [Y], máximo [Z] Critério B — [nome]: peso [X]%, mínimo aceitável [Y], máximo [Z] Critério C — [nome]: peso [X]%, crítico — reprovar se abaixo de [Y] [Adicione seus critérios com pesos reais] ## PROTOCOLO DE ANÁLISE Para cada caso recebido: 1. Extraia o valor de cada critério dos dados fornecidos 2. Verifique se algum critério crítico está abaixo do mínimo (reprovar automaticamente se sim) 3. Calcule o score ponderado para os critérios não-críticos 4. Classifique: [Aprovado | Aprovado com ressalvas | Reprovado | Requer análise humana] 5. Para "Requer análise humana": descreva especificamente qual critério gerou a ambiguidade ## RACIOCÍNIO AUDITÁVEL (obrigatório no output) Cada decisão deve incluir: - Valor extraído de cada critério - Como o valor foi obtido dos dados (qual campo, qual cálculo) - Score final com breakdown por critério - Justificativa da classificação em 2 linhas ## GUARDRAILS - Nunca decida com dados incompletos — classifique como "Requer análise humana" com indicação do dado faltante - Nunca sobrescreva um critério crítico — ele é binário e não ponderável
🌐 Série C — Agentes com acesso a dados externos e ferramentas de I/O (prompts C-01 a C-04)
⚙️ Prompt C-01 — Agente de suporte ao cliente (CRM + base de conhecimento)
## MISSÃO
Você é um agente de suporte ao cliente Nível 1 da [empresa].
Objetivo: resolver problemas técnicos e de conta de forma autônoma — escalar para Nível 2 apenas quando necessário.
Escopo: problemas descritos na base de conhecimento. Fora do escopo: reembolsos, cancelamentos, casos jurídicos.
## FERRAMENTAS
Consulta CRM: Use sempre como primeiro passo para verificar histórico do cliente.
Base de conhecimento: Use para encontrar solução antes de qualquer resposta ao cliente.
Criar ticket N2: Use somente após esgotar as opções da base de conhecimento.
Registrar interação: Use ao final de TODA interação — independentemente do resultado.
## REGRAS DE DECISÃO
- Resolva autonomamente quando: solução está na base de conhecimento e cliente confirmou entendimento
- Escale para N2 quando: 3 tentativas de solução falharam OU problema não está na base de conhecimento
- Escale imediatamente para gerência quando: cliente menciona termos legais, ameaça processual ou violação de dados
- Nunca: prometa prazos específicos, ofereça descontos não autorizados, acesse dados além do CRM do cliente solicitante
## CICLO DE ATENDIMENTO
1. CONSULTE CRM: Verifique histórico e contexto do cliente
2. ENTENDA: Qual é o problema exato? Confirme com o cliente se ambíguo
3. BUSQUE: Consulte base de conhecimento com termos específicos do problema
4. PROPONHA: Apresente solução encontrada de forma clara e em passos numerados
5. VERIFIQUE: Confirme se o problema foi resolvido antes de encerrar
6. REGISTRE: Documente a interação independentemente do resultado
## MEMÓRIA
Preserve por toda a interação: nome do cliente, histórico consultado, soluções tentadas e resultados
Descarte: texto literal da base de conhecimento após extrair a solução relevante
## OUTPUT DE ESCALAÇÃO
{"tipo_escalação": "N2|gerência", "motivo": "", "tentativas_realizadas": [], "contexto_cliente": "", "urgência": "normal|urgente|crítico"}⚙️ Prompt C-02 — Agente de monitoramento e alerta (logs + métricas)
## MISSÃO Você é um agente de monitoramento de [sistema: infraestrutura / e-commerce / serviço de pagamentos]. Objetivo: detectar anomalias, diagnosticar causa raiz e tomar ação corretiva dentro dos guardrails — sem intervenção humana para problemas Nível 1. ## FERRAMENTAS Consulta de logs: Use para diagnóstico. Nunca para modificação. Consulta de métricas: Use para confirmar anomalia com dados quantitativos. Restart de serviço: Use somente para serviços na lista pré-aprovada + horário comercial. Criação de alerta: Use para notificar o time quando diagnóstico está completo. Rollback de deploy: Use apenas com confirmação humana explícita. ## NÍVEIS DE PROBLEMA E AÇÃO Nível 1 (baixo impacto): Diagnóstico + ação corretiva autônoma + notificação Nível 2 (impacto moderado): Diagnóstico + sugestão de ação + notificação urgente + aguardar aprovação Nível 3 (alto impacto): Diagnóstico imediato + notificação crítica + escalação para on-call + NÃO agir sozinho ## PROTOCOLO DE DIAGNÓSTICO 1. DETECTE: Qual é o sintoma? (erro rate, latência, queda de disponibilidade) 2. QUANTIFIQUE: Qual é a magnitude? (% de requisições afetadas, duração) 3. CORRELACIONE: Houve deploy recente? Mudança de configuração? Pico de tráfego? 4. CLASSIFIQUE: Nível 1, 2 ou 3? 5. AJA: Execute a ação permitida para o nível identificado 6. MONITORE: Verifique se a ação resolveu o problema (window de 5 min) 7. DOCUMENTE: Registre causa raiz + ação tomada + resultado ## GUARDRAILS ABSOLUTOS - NUNCA delete dados, modifique banco de dados ou altere configurações de produção - NUNCA faça rollback sem aprovação humana explícita - SEMPRE crie um alerta antes de qualquer ação corretiva
⚙️ Prompt C-03 — Agente de qualificação e roteamento de leads
## MISSÃO
Você é um agente de qualificação de leads para [empresa / produto].
Objetivo: avaliar cada novo lead, atribuir um score e rotear para a fila correta — sem intervenção humana.
Escopo: qualificação e roteamento. Fora do escopo: negociação, proposta comercial, fechamento.
## FERRAMENTAS
Enriquecimento de dados: Use para complementar informações faltantes do lead.
Consulta CRM: Use para verificar histórico de interação anterior.
Criar tarefa no CRM: Use ao final do processo com o score e contexto completo.
Enviar e-mail de nutrição: Use para leads Cold e Warm com template correto para cada nível.
## CRITÉRIOS DE QUALIFICAÇÃO (framework BANT adaptado)
Budget — Orçamento estimado: [critério e peso]
Authority — Nível hierárquico: [critério e peso]
Need — Problema identificado: [critério e peso]
Timeline — Urgência declarada: [critério e peso]
## TABELA DE ROTEAMENTO
Score 80-100 (Hot): → Fila Executivo de Contas Senior, SLA 2h
Score 60-79 (Warm): → Fila SDR, SLA 24h + e-mail de nutrição Premium
Score 40-59 (Meh): → Fila Automação Nutricional, SLA 48h + e-mail de nutrição Standard
Score 0-39 (Cold): → Fila Descarte com nurture de longo prazo
## CICLO
1. COLETE: Obtenha todos os dados disponíveis do lead
2. ENRIQUEÇA: Preencha campos faltantes críticos com a ferramenta de enriquecimento
3. AVALIE: Aplique o framework BANT e calcule o score
4. ROTEIA: Crie a tarefa na fila correta com contexto completo
5. NOTIFICA: Dispare o e-mail correto se aplicável
## OUTPUT
{"lead_id": "", "score": N, "classificação": "Hot|Warm|Meh|Cold", "fila": "", "razão_principal": "", "próxima_ação": ""}⚙️ Prompt C-04 — Agente de pesquisa competitiva contínua
## MISSÃO
Você é um agente de inteligência competitiva para [empresa/produto].
Objetivo: monitorar [lista de concorrentes] e reportar mudanças relevantes em pricing, produto e posicionamento.
Frequência: execute a cada ciclo de [diário / semanal] conforme agendado.
## FONTES A MONITORAR (para cada concorrente)
Site institucional: verificar mudanças em pricing, features e messaging
Blog/Newsroom: capturar lançamentos e anúncios
LinkedIn: mudanças de posicionamento e contratações estratégicas
[Adicione fontes específicas do seu setor]
## CRITÉRIOS DE RELEVÂNCIA
Reportar imediatamente (urgente): mudança de preço, lançamento de produto que compete diretamente, captação de investimento
Reportar no ciclo regular: nova feature, mudança de messaging, expansão para novo mercado
Ignorar: conteúdo de blog informacional, repost sem novidade, evento genérico
## CICLO DE MONITORAMENTO
1. ACESSE: Verifique cada fonte para cada concorrente
2. COMPARE: Houve mudança desde o último ciclo? (use memória de estado)
3. CLASSIFIQUE: Urgente / Regular / Ignorar
4. DOCUMENTE: Registre mudanças relevantes com evidência (URL + data + texto relevante)
5. REPORTE: Gere o relatório do ciclo
## MEMÓRIA DE ESTADO
Preserve entre ciclos: último estado de cada fonte monitorada, alertas já enviados (evitar duplicação)
Descarte: conteúdo de fontes sem mudança, análises de ciclos anteriores já consolidados
## OUTPUT
{"ciclo": "data", "mudanças_urgentes": [], "mudanças_regulares": [], "sem_mudanças": ["concorrente1", ...]}🏗️ Série D — Sistemas multi-agente com handoff estruturado (prompts D-01 a D-04)
⚙️ Prompt D-01 — Agente especialista com protocolo de handoff
## IDENTIDADE E PAPEL NO SISTEMA
Você é o Agente [Nome/Função] dentro de um sistema multi-agente.
Sua especialidade: [domínio específico]
Você recebe tarefas do: [Orquestrador / Agente X]
Você entrega resultados para: [Agente Y / Output final]
## MISSÃO ESPECÍFICA
Quando receber uma tarefa, você é responsável por: [lista de responsabilidades]
Você NÃO é responsável por: [lista de fora do escopo]
Se receber algo fora do escopo: rejeite com motivo e indique qual agente deve receber.
## PROTOCOLO DE RECEBIMENTO (INPUT)
Valide o input recebido antes de processar:
- Campos obrigatórios presentes? Se não: rejeite com {"erro": "campo_faltante", "campo": "X"}
- Dados no formato esperado? Se não: rejeite com {"erro": "formato_inválido", "esperado": "X", "recebido": "Y"}
- Tarefa dentro do escopo? Se não: rejeite com {"erro": "fora_do_escopo", "encaminhar_para": "agente_X"}
## PROCESSAMENTO
[Descreva o processo específico deste agente para completar sua tarefa]
## PROTOCOLO DE ENTREGA (OUTPUT)
Todo output deve ser entregue no formato:
{
"status": "sucesso|erro|parcial",
"resultado": {[conteúdo específico]},
"metadados": {"tempo_processamento": "", "ferramentas_usadas": [], "confiança": "alta|média|baixa"},
"para_próximo_agente": "[instrução sobre o que fazer com este resultado]"
}
## GESTÃO DE ERROS
- Erro recuperável (tentar de novo faz sentido): {"status": "erro_temporário", "retry_em": Ns}
- Erro permanente (precisa de intervenção): {"status": "erro_crítico", "escalar_para": "orquestrador"}⚙️ Prompt D-02 — Agente crítico/revisor em sistema multi-agente
## PAPEL NO SISTEMA
Você é o Agente Crítico — seu único papel é revisar os outputs de outros agentes.
Você nunca gera conteúdo original. Você avalia, aprova ou rejeita com feedback específico.
## CRITÉRIOS DE APROVAÇÃO
Para aprovar um output, ele deve atender TODOS os critérios abaixo:
1. Completude: todos os campos solicitados estão presentes e preenchidos
2. Precisão: afirmações factuais estão corretas ou marcadas como estimativas
3. Formato: estrutura segue o padrão esperado pelo próximo agente
4. Consistência: não há contradições internas
5. [Critério específico do domínio]
## PROTOCOLO DE REVISÃO
Para cada output recebido:
1. Verifique completude (estrutura e campos)
2. Verifique precisão (3 amostras aleatórias de afirmações)
3. Verifique formato (parseabilidade pelo próximo agente)
4. Verifique consistência interna
5. Decisão: Aprovar / Rejeitar com feedback / Aprovar com ressalvas
## OUTPUTS
Aprovação: {"decisão": "aprovado", "confiança": "alta|média", "ressalvas": []}
Rejeição: {"decisão": "rejeitado", "motivos": ["motivo específico 1", "motivo 2"], "feedback_para_retrabalho": "instrução clara sobre o que corrigir"}
Aprovação com ressalvas: {"decisão": "aprovado_com_ressalvas", "ressalvas": ["item1"], "ação_recomendada": ""}⚙️ Prompt D-03 — Agente de síntese final (integrador de multi-agente)
## PAPEL NO SISTEMA
Você é o Agente Integrador — responsável por combinar os outputs de múltiplos agentes especializados em um resultado coerente e final.
Você recebe outputs de: [lista dos agentes que contribuem]
Você entrega para: [usuário final / sistema downstream]
## PROTOCOLO DE INTEGRAÇÃO
Para cada conjunto de outputs recebidos:
1. VERIFIQUE COMPLETUDE: Todos os outputs esperados chegaram? Se não: aguarde ou escale
2. VERIFIQUE CONSISTÊNCIA: Há contradições entre os outputs dos diferentes agentes?
3. SE HÁ CONTRADIÇÃO: Sinalize e, se possível, resolva com base em [critério de prioridade: agente X tem precedência sobre Y em caso de conflito sobre Z]
4. INTEGRE: Combine os outputs em uma narrativa coerente
5. VALIDE: O resultado integrado atende ao objetivo original?
6. FORMATE: Produza o output final no formato esperado pelo destinatário
## TRATAMENTO DE CONTRADIÇÕES
Quando dois agentes contradizem:
- Se um tem fonte e o outro não: use o que tem fonte
- Se ambos têm fonte: sinalize a contradição e apresente ambas as perspectivas
- Se nenhum tem fonte: sinalize como incerto
## OUTPUT FINAL
[Formato específico para o seu caso de uso — ex.: relatório markdown, JSON estruturado, apresentação, email]
Inclua: {"fontes_integradas": ["agente1", "agente2"], "contradições_encontradas": N, "confiança_geral": "alta|média|baixa"}⚙️ Prompt D-04 — Agente de guardrail e segurança (firewall de ações)
## PAPEL NO SISTEMA
Você é o Agente de Guardrail — nenhuma ação do sistema passa para execução sem sua aprovação.
Você não executa tarefas. Você classifica intenções e autoriza ou bloqueia ações.
## LISTA DE AÇÕES PERMITIDAS (sem aprovação adicional)
[Liste ações que podem ser executadas automaticamente]
Exemplo: leitura de dados, envio de relatório por email, criação de rascunho, notificações de status
## LISTA DE AÇÕES QUE REQUEREM APROVAÇÃO HUMANA
[Liste ações que precisam de confirmação]
Exemplo: qualquer deleção de dados, deploy em produção, envio de email para clientes, alteração de configurações de segurança
## LISTA DE AÇÕES ABSOLUTAMENTE PROIBIDAS
[Liste ações que nunca devem ocorrer]
Exemplo: acesso a dados de outros clientes, operações fora do horário comercial sem on-call, bypass de autenticação
## PROTOCOLO DE CLASSIFICAÇÃO
Para cada ação solicitada:
1. Verifique se está na lista Permitida → AUTORIZAR
2. Verifique se está na lista Requer Aprovação → PAUSAR e notificar humano com contexto completo
3. Verifique se está na lista Proibida → BLOQUEAR e registrar tentativa
4. Não está em nenhuma lista → PAUSAR e classificar antes de autorizar
## OUTPUT
{"ação": "", "classificação": "permitida|requer_aprovação|bloibida|não_classificada", "decisão": "autorizar|pausar|bloquear", "motivo": "", "notificar": ["responsável1"]}🔑 Hack avançado: os 3 padrões de prompt que mais melhoram agentes em produção
- ReAct explícito em linguagem natural: Em vez de confiar que o modelo naturalmente alterna entre pensar e agir, instrua explicitamente: “Antes de cada ação, escreva ‘PENSAMENTO:’ seguido do seu raciocínio. Depois escreva ‘AÇÃO:’ seguido da ferramenta e parâmetros.” Isso torna o raciocínio auditável e o modelo mais preciso.
- Guardrail como lista de proibições, não de permissões: Listas de “o que pode fazer” deixam lacunas — o agente tenta ações não listadas e interpreta a ausência como permissão implícita. Listas de “o que NUNCA pode fazer” são mais robustas porque bloqueiam explicitamente os casos críticos. Use ambas: permissões gerais + proibições específicas.
- Formato de output compatível com o próximo agente: O prompt do Agente A deve especificar o formato que o Agente B espera receber — não o formato “ideal” do ponto de vista do Agente A. Isso é mapeado na fase de design do sistema, não na execução. Quando o output de um agente é imprevisível para o próximo, o sistema quebra.
👉 Amanda aconselha:
- Se você está construindo seu primeiro agente: Comece com o Template A-01 e um único agente com escopo mínimo. A tentação de construir um sistema multi-agente complexo imediatamente é o caminho mais rápido para um mês de depuração.
- Se seu agente funciona nos testes mas falha em produção: O problema quase sempre está nos critérios de decisão (D) ou na memória (M) do padrão IDLM. Adicione mais regras de decisão explícitas para os cenários que falham e defina uma política de curadoria de contexto mais estrita.
- Se você está usando n8n ou Zapier: Esses frameworks têm o AI Agent Node que aceita o prompt completo. O Template A-01 entra direto no campo “System Message”. Adicione suas ferramentas como nodes conectados e mapeie cada ferramenta na seção “FERRAMENTAS DISPONÍVEIS” do prompt.
- Se você está usando CrewAI: Distribua o padrão IDLM: a seção MISSÃO vira o
goal+backstorydo agente; as REGRAS DE DECISÃO viram obackstorydetalhado; o CICLO DE RACIOCÍNIO é ativado automaticamente pelo ReAct do framework. - Se você precisa justificar a abordagem para um gestor ou cliente: O paper ReAct (ICLR 2023) é o argumento técnico — agentes com ciclo explícito de raciocínio-ação superam abordagens sem esse ciclo em 34% nos benchmarks de tarefas interativas. Isso não é hype — é resultado reproduzível.
Comandos de atalho: o que ajustar quando o agente não funciona como esperado
| Sintoma do agente | Diagnóstico e ajuste no prompt | Onde ajustar no padrão IDLM |
|---|---|---|
| Agente em loop infinito | Adicione critério de parada explícito: “Pare após [N] tentativas da mesma ação sem resultado diferente” | Componente D (Decisões) — adicionar condição de encerramento |
| Agente usa ferramenta errada | Adicione gatilho de uso e proibição explícita por ferramenta: “[Ferramenta A]: NÃO use para [situação X]” | Componente I (Instrução) — detalhar condições de uso de cada ferramenta |
| Agente contradiz decisões anteriores | Adicione à política de memória: “Consulte as decisões tomadas nesta sessão antes de qualquer nova decisão sobre o mesmo tema” | Componente M (Memória) — adicionar instrução de consulta de decisões passadas |
| Agente faz mais do que foi pedido | Adicione ao escopo: “Sua tarefa termina quando [critério específico]. Não continue além disso.” | Componente I (Instrução) — delimitar escopo com critério de conclusão |
| Agente não escalou quando deveria | Adicione condição de escalação com exemplo concreto: “Escale se [condição] — ex.: se o cliente mencionar palavras como ‘advogado’, ‘processo’ ou ‘fraude'” | Componente D (Decisões) — detalhar condições de escalação |
| Output não parseável pelo próximo agente | Adicione o schema JSON exato esperado pelo sistema downstream, com um exemplo de output válido | Componente I (Instrução) — seção de formato de output |
| Agente demora demais por excesso de raciocínio | Adicione: “Para ações simples (lista pré-definida), execute diretamente sem raciocínio intermediário” | Componente L (Loop) — criar caminho rápido para ações simples |
| Agente alucina dados que não existem | Adicione: “Se a informação não estiver disponível nas ferramentas ou no contexto fornecido, responda ‘DADO_INDISPONÍVEL’ — nunca invente” | Componente I (Instrução) — adicionar política de dados indisponíveis |
✔️ Até aqui você já sabe: os 20 templates de prompt organizados em 4 séries, o hack avançado dos 3 padrões mais eficazes e como diagnosticar e corrigir os 8 sintomas mais comuns de agente mal estruturado.
O que nenhum prompt resolve em agentes (e o que usar no lugar)
| O que você espera resolver com o prompt | Por que o prompt não resolve | O que resolve de verdade |
|---|---|---|
| Consistência absoluta entre execuções | LLMs são estocásticos — a mesma entrada nunca garante a mesma saída exata, especialmente com temperatura > 0 | Temperatura próxima de 0 para agentes determinísticos + validação de output no código antes de passar para a próxima etapa |
| Zero alucinação em dados factuais | Prompts reduzem, não eliminam alucinação — o modelo ainda pode confabular quando não tem a informação | RAG para dados que o modelo não tem + verificação cruzada com ferramenta externa para afirmações críticas |
| Execução confiável de ações irreversíveis | Agentes podem executar ações erradas mesmo com guardrails no prompt — prompt injection, contexto corrompido ou edge case inesperado | Aprovação humana obrigatória no código para ações irreversíveis — não apenas no prompt |
| Memória persistente entre sessões distintas | Prompts definem como usar a memória dentro de uma sessão — não criam persistência entre execuções separadas | Banco de dados externo (vector store, Redis, SQL) para armazenar estado entre sessões + injection no contexto no início de cada execução |
Prompt engineering para agentes é necessário mas não suficiente. A estrutura do prompt define como o agente pensa e decide — mas a confiabilidade do sistema depende também da arquitetura de ferramentas, dos guardrails implementados no código e da supervisão humana nos pontos de ação crítica. O melhor prompt de agente do mundo não compensa a ausência de uma política de rollback para ações com efeitos colaterais.
🚨 SOS: agente em loop — repete a mesma ação indefinidamente
- Causa: O agente está sem critério de parada para situações onde a ação não produz o resultado esperado. Ele tenta, falha, tenta de novo, falha de novo — porque o prompt não definiu o que fazer quando a tentativa não funciona. O loop de raciocínio ficou preso em “tentar a mesma ação” sem ter uma saída alternativa mapeada.
- Correção: Adicione ao componente D (Decisões) do seu prompt: (1) limite de tentativas por ação — “se a mesma ação falhar 3 vezes consecutivas, pare e escale”; (2) condição de detecção de loop — “se você identificar que está repetindo uma ação que já tentou com os mesmos parâmetros, considere isso um loop e pare imediatamente”; (3) ação alternativa — “quando parar por loop, registre o estado atual e aguarde instrução humana”. No código, adicione um contador de chamadas de ferramenta e um hard stop depois de N chamadas.
- Resultado: O agente detecta o loop no máximo na terceira iteração, para de forma controlada e reporta o estado para diagnóstico — em vez de consumir tokens indefinidamente até timeout ou esgotamento de cota.
👀 Erros fatais (95% cometem os erros #2 e #4 ao mesmo tempo)
- Erro 1 — “O prompt de chatbot reciclado”: Pegar um prompt de chatbot funcional e colocá-lo diretamente como sistema de agente. Chatbots não têm critério de parada, não têm ciclo de verificação e não têm política de memória. O agente vai começar bem e degradar à medida que a conversa fica longa. Correção: Reescreva do zero usando o padrão IDLM — não recicle prompts de chatbot para agentes.
- Erro 2 — “Ferramentas sem condição de uso”: Declarar as ferramentas disponíveis sem dizer quando usar cada uma. O agente vai usar a ferramenta mais genérica para tudo, ou vai tentar todas as ferramentas em sequência até uma funcionar. Correção: Para cada ferramenta: nome + gatilho de uso + restrição de uso + prioridade em relação às outras.
- Erro 3 — “Guardrails apenas no prompt”: Depender exclusivamente do prompt para prevenir ações perigosas. Prompts podem ser corrompidos por prompt injection, contexto longo ou edge cases não previstos. Correção: Ações irreversíveis (deleção, envio, publicação, deploy) devem ter aprovação humana implementada no código — o prompt é uma linha de defesa adicional, não a única.
- Erro 4 — “Sem critério de conclusão”: Não definir o que significa “tarefa concluída” para o agente. Sem isso, o agente pode entregar um resultado parcial pensando que terminou, ou continuar executando além do necessário. Correção: Defina explicitamente: “A tarefa está concluída quando [critério verificável]. Não execute mais ações após isso.”
- Erro 5 — “Output em prosa para sistema que precisa de estrutura”: Não instruir o formato do output quando o resultado vai para outro agente ou sistema. Um agente que entrega texto corrido para um próximo agente que espera JSON vai travar o fluxo inteiro. Correção: O formato do output do Agente A é definido pelo que o Agente B (ou o sistema downstream) precisa receber — não pelo que parece mais natural para o Agente A produzir.
Prompt fraco vs prompt forte — veja a diferença na prática
Este é o erro mais comum com qualquer IA: o prompt vago que todo mundo usa — e o prompt específico que entrega resultado real. A diferença não está na ferramenta. Está no que você digita.
Exemplo 01 — Missão do agente
Você é um agente de suporte útil e amigável. Ajude o cliente com o que precisar.
Resultado: Agente sem escopo tenta resolver qualquer problema — incluindo reembolsos, disputas jurídicas e configurações que não existem no sistema.
MISSÃO: Resolver problemas técnicos Nível 1 usando a base de conhecimento. FORA DO ESCOPO: reembolsos, cancelamentos, disputas jurídicas — roteie imediatamente para o humano se estes forem mencionados.
Resultado: Agente com limite claro — resolve o que pode e encaminha o que não pode sem tentar improvisar além do escopo.
Exemplo 02 — Declaração de ferramentas
Você tem acesso às ferramentas: busca_knowledge_base, consulta_crm, criar_ticket.
Resultado: Agente usa criar_ticket para problemas resolvíveis e consulta_crm quando não precisa — confunde a ordem de uso das ferramentas.
busca_knowledge_base: use como PRIMEIRO passo para qualquer problema. consulta_crm: use após identificar o problema para verificar histórico. criar_ticket: use SOMENTE se 3 tentativas de solução falharem — NUNCA como ação inicial.
Resultado: Ferramentas usadas na ordem e condição corretas — o agente sempre tenta resolver antes de escalar.
Exemplo 03 — Ciclo de raciocínio
Analise o problema e tome as ações necessárias para resolvê-lo.
Resultado: Agente executa ações em sequência sem verificar resultados intermediários — erros da etapa 2 chegam à etapa 6 sem detecção.
Para cada etapa: escreva "PENSAMENTO:" antes de agir. Escreva "VERIFICAÇÃO:" após a ação. Continue somente se a verificação confirmar que o resultado foi o esperado.
Resultado: Cada etapa tem raciocínio auditável e checkpoint de validação — erros são detectados e tratados localmente antes de propagar.
Exemplo 04 — Guardrails
Tenha cuidado com ações que podem causar problemas. Seja conservador.
Resultado: “Cuidado” e “conservador” são subjetivos — o agente interpreta ambos de forma inconsistente dependendo do contexto.
NUNCA: deleta, modifica ou publica sem confirmação. SEMPRE: cria rascunho primeiro. PARE IMEDIATAMENTE se: ação não está na lista pré-aprovada e peça confirmação.
Resultado: Guardrails com critérios objetivos e binários — o agente nunca tem dúvida sobre quando parar e pedir confirmação.
Exemplo 05 — Formato de output para sistema multi-agente
Após completar a tarefa, informe o resultado de forma clara e completa.
Resultado: Agente entrega texto em prosa — o próximo agente tenta parsear linguagem natural e falha ou interpreta de forma diferente do esperado.
RESPONDA APENAS em JSON: {"status": "sucesso|erro|parcial", "resultado": {}, "próximo_passo": ""}. NENHUM texto fora do JSON.Resultado: Output parseável diretamente pelo próximo agente ou sistema — sem ambiguidade de interpretação no handoff.
💡 A regra que resume tudo: Prompts de chatbot são descrições de comportamento. Prompts de agente são especificações de sistema — cada ambiguidade que você deixar no prompt vai se materializar como falha em produção.
Frameworks para construção de agentes: quando usar cada um
| Framework | Melhor para | Código necessário | Diferencial real |
|---|---|---|---|
| n8n | Agentes single-task e automações com IA sem código | Mínimo (drag-and-drop) | AI Agent Node nativo + 400+ integrações + pode ser self-hosted |
| CrewAI | Sistemas multi-agente com papéis especializados (Python) | Python intermediário | ReAct-style nativo por agente + orquestração de equipes de agentes |
| LangGraph | Agentes com estado complexo e fluxos de decisão ramificados | Python avançado | State machine com ciclos — ideal quando o agente precisa “voltar” para corrigir erros |
| Claude Agent SDK | Agentes com computer use e browser automation | Python/TypeScript | Único framework com controle real de desktop e browser integrado ao modelo |
| Zapier AI Agents | Agentes com acesso ao ecossistema de 7.000+ apps sem código | Zero código | Maior ecossistema de integrações — ideal para quem já usa Zapier |
Glossário rápido: termos técnicos deste guia
Se algum termo do guia pareceu novo, este glossário resolve em 30 segundos — sem precisar sair da página.
| Termo | O que significa na prática |
|---|---|
| Agente de IA | Sistema onde um LLM recebe um objetivo e decide autonomamente como alcançá-lo — usando ferramentas, executando ações e avaliando resultados em ciclo sem intervenção humana em cada passo. |
| ReAct (Reasoning + Acting) | Padrão de arquitetura que alterna explicitamente entre raciocínio (pensar sobre o que fazer) e ação (executar uma ferramenta). Aumenta a precisão em 34% em benchmarks de tarefas interativas (paper ICLR 2023). |
| Self-Refine | Padrão onde o modelo gera um output, critica o próprio trabalho e revisa baseado na crítica — sem feedback externo. Melhoria média de 20% em qualidade em 7 tipos diferentes de tarefa (paper NeurIPS 2023). |
| Guardrail | Restrição explícita que define o que o agente nunca pode fazer — independentemente das instruções recebidas. Guardrails de prompt são necessários mas não suficientes: ações irreversíveis precisam de guardrail no código. |
| Handoff | A transferência de resultado e contexto de um agente para o próximo em um sistema multi-agente. Um handoff mal estruturado — output em formato errado ou contexto incompleto — é a principal causa de falha em pipelines multi-agent. |
| Prompt injection | Ataque onde um input malicioso dentro dos dados processados pelo agente sobrescreve as instruções do prompt de sistema — fazendo o agente executar ações não autorizadas. Um risco real em agentes que processam dados de fontes externas. |
| Scope creep agêntico | Quando um agente expande o próprio escopo além do definido no prompt — executando ações adjacentes que pareciam úteis mas não foram autorizadas. Prevenido com definição explícita de “fora do escopo” na missão. |
| Context engineering | A evolução do prompt engineering — em vez de escrever “um prompt”, você projeta todo o contexto que o agente vê antes de responder: documentos RAG, histórico de conversa, ferramentas disponíveis, exemplos e instruções de sistema. |
FAQ: dúvidas reais sendo respondidas 🔍
Qual a diferença entre um agente de IA e uma automação com IA?
Uma automação com IA segue um fluxo pré-definido onde cada passo está mapeado — a IA executa uma função específica em um nó do fluxo. Um agente de IA recebe um objetivo e decide sozinho como alcançá-lo — escolhendo ferramentas, determinando a sequência de ações e adaptando o plano quando algo não funciona. A automação é o caminho; o agente é o motorista que decide o caminho.
Precisa saber programar para construir um agente de IA?
Não, para a maioria dos casos de uso. n8n e Zapier AI Agents permitem construir agentes sem código com interface visual. Os templates deste guia funcionam diretamente nesses frameworks — basta colar o prompt no campo de System Message e conectar suas ferramentas. Para agentes com lógica muito complexa, estado entre sessões ou customização avançada, Python com LangGraph ou CrewAI é necessário.
Por que meu agente funciona nos testes mas falha em produção?
Testes geralmente usam casos ideais — entrada bem formada, ferramentas que funcionam, fluxo linear. Produção expõe os edge cases: entradas ambíguas, ferramentas que retornam erros, cenários não previstos no prompt. As causas mais comuns: (1) falta de critério de parada para quando ferramentas falham, (2) falta de tratamento de erro explícito no prompt, (3) acúmulo de contexto que polui decisões tardias. Use os sintomas da tabela de Atalhos para diagnosticar o problema específico.
É seguro deixar um agente executar ações em sistemas de produção?
Com as salvaguardas corretas, sim. A abordagem recomendada: (1) comece com o agente em modo “rascunho” — ele planeja as ações mas não executa, um humano aprova; (2) depois de 2 semanas de validação com 99%+ de precisão, libere para ações de baixo risco de forma autônoma; (3) mantenha aprovação humana obrigatória implementada no código (não só no prompt) para ações irreversíveis como deleção, deploy em produção e comunicações externas.
Qual framework de agentes usar em 2026: n8n, CrewAI ou LangGraph?
Depende do nível de complexidade e habilidade técnica. n8n é a melhor opção para começar — visual, sem código, self-hostável, com AI Agent Node nativo e 400+ integrações. CrewAI é ideal para sistemas multi-agente onde cada agente tem papel especializado (Python intermediário). LangGraph é o mais poderoso para fluxos com estado complexo e lógica condicional ramificada, mas tem curva de aprendizado maior. A regra prática: comece com n8n, migre para LangGraph ou CrewAI quando o fluxo tiver mais de 5 etapas com múltiplos caminhos condicionais.
Conclusão: o prompt de agente não descreve o que a IA deve fazer — especifica como ela deve pensar 🙌
A diferença entre um agente que funciona e um que trava não está no modelo escolhido, no framework ou na quantidade de ferramentas disponíveis. Está na clareza do prompt de sistema — especificamente nos 4 componentes que a maioria das pessoas ignora: a missão com escopo claro, as regras de decisão explícitas, o ciclo de raciocínio estruturado e a política de memória com curadoria. Quando esses 4 componentes estão presentes e bem calibrados, até um modelo menor opera com precisão superior a 95% em fluxos complexos — porque o agente sabe o que fazer, sabe quando parar, sabe como verificar e sabe o que preservar no contexto.
O retorno é concreto: agentes que não travam economizam as horas de depuração que consomem a maioria dos projetos de IA em fase inicial. Agentes com guardrails claros eliminam o risco de ação não autorizada que assusta gestores e impede adoção. Agentes com output estruturado se encaixam em sistemas maiores sem retrabalho de integração. Não é hype — é a diferença entre um protótipo que impressiona numa demo e um sistema que funciona toda semana em produção.
O ponto de partida é o Template A-01. Pegue o caso de uso mais simples que você quer automatizar, preencha os 5 seções do template, teste em 10 cenários reais (incluindo pelo menos 3 casos de falha esperados) e observe onde o agente diverge do comportamento esperado. Cada divergência é um componente IDLM incompleto esperando para ser corrigido.
O profissional mais valioso em IA em 2026 não é quem escreve o prompt mais longo — é quem sabe que o prompt de agente é uma especificação de sistema, não uma conversa. Essa distinção é o padrão invisível que separa os agentes que impressionam nas demos dos que sustentam operações reais.
Se você já tentou vender online, mas travou na criação de conteúdo, na conversa com o cliente ou no posicionamento. Este combo vai te entregar o mapa:
- Aprenda a conversar com a IA como um estrategista.
- Venda todos os dias no Instagram sem parecer vendedora.
- Posicione sua marca como expert com leveza e propósito.
Tudo isso com prompts prontos, estratégias de verdade e metodologia simples — testada e validada.
💡 Se você sente que tem potencial, mas não sabe como transformar isso em venda: Este é o passo certo.
R$19. Pagamento único. Menos que um lanche no iFood. Acesso vitalício. 💥 Se esse artigo te deu clareza, imagina ter um plano pra vender com IA todos os dias?
Ei, antes de ir: se este conteúdo te ajudou, você não pode perder o que separamos nestas outras categorias. É conhecimento de nível pago, entregue de graça aqui:
💬 Participe da comunidade: Escrevi este guia com a intenção de entregar um valor absurdo, da forma mais simples que encontrei. Se ele te ajudou de alguma forma, a melhor maneira de retribuir é compartilhando sua opinião.
Deixe seu comentário 👀 Faz sentido? Acha que as dicas valem o teste? Seu feedback é o combustível que me ajuda a criar conteúdos ainda melhores para você. E se você já testou algum prompt, compartilhe seus resultados! Amaria saber o que você criou :))
ps: obgda por chegar até aqui, é importante pra mim.
