O instinto de controlar tudo, e por que ele cobra um preço
Quando uma equipe implanta um SDR de IA, o primeiro reflexo é natural: adicionar regras. Cada situação nova que o agente trata de forma errada vira uma nova instrução no prompt.
O lead mencionou concorrente? Adiciona regra. O agente foi direto demais com um CFO? Adiciona regra. Alguém perguntou sobre preço cedo demais? Adiciona regra.
Esse ciclo parece responsável. É, na verdade, o caminho mais curto para um agente quebrado.
O problema não é ter regras. É acreditar que mais regras equivalem a mais controle. Não equivalem.
O que acontece quando o prompt satura
Modelos de linguagem processam instruções em contexto. Quando o contexto fica denso demais, algumas coisas acontecem de forma previsível:
Conflito entre regras Duas instruções que parecem compatíveis para um humano podem ser mutuamente exclusivas para o modelo. Exemplo clássico: "seja consultivo, não empurre produto" junto com "sempre mencione o plano Enterprise quando o lead tiver mais de 50 funcionários". Em metade dos casos, o modelo vai escolher uma das duas, de forma inconsistente.
Atenção distribuída de forma desigual O modelo não lê o prompt como uma lista ordenada de prioridades. Ele pondera. Regras no início e no fim do prompt tendem a ter mais peso. Regras no meio ficam subrepresentadas, e são exatamente as que costumam acumular com o tempo.
Respostas travadas Um agente com 40 condicionais no prompt começa a soar como um roteiro de call center dos anos 2000. A fluidez desaparece. O lead percebe, mesmo sem saber nomear o que percebeu.
Falsos positivos de segurança A equipe acredita que o agente está mais protegido. O agente está, na verdade, mais imprevisível.
Como identificar que você já passou do ponto
Não existe um número mágico de regras. O sinal não está na contagem, está no comportamento.
Alguns indicadores concretos de saturação:
- O agente começa a ignorar instruções que funcionavam antes
- Respostas ficam longas e mecânicas sem motivo aparente
- Você precisa testar o mesmo cenário várias vezes para ter resultado consistente
- Adicionar uma nova regra corrige um problema e quebra outro
- O prompt virou um documento que ninguém na equipe consegue explicar inteiro
Se três ou mais desses pontos descrevem o seu SDR agora, o problema não é o modelo. É a arquitetura do prompt.
A diferença entre regras e estrutura
A saída não é ter menos intenção sobre o comportamento do agente. É expressar essa intenção de forma diferente.
Regras brutas tentam cobrir situações. Estrutura define como o agente raciocina.
Comparação direta:
| Regra bruta | Abordagem estrutural | |---|---| | "Não fale sobre preço antes da qualificação" | Definir uma fase de qualificação com critérios claros e instruir o agente a seguir a fase atual | | "Se o lead for agressivo, mantenha o tom neutro" | Descrever a persona do agente com traços de temperamento estável, não uma lista de ifs | | "Sempre pergunte sobre o prazo do projeto" | Incluir prazo como campo obrigatório no objeto de qualificação, não como lembrete avulso |
A lógica muda de "preveja cada situação" para "construa um agente que sabe como pensar".
Quando adicionar uma regra ainda faz sentido
Regras continuam tendo lugar. A questão é quando e como.
Faz sentido adicionar uma regra quando:
- Existe um requisito de compliance que não pode depender de interpretação do modelo
- Um comportamento específico precisa ser bloqueado de forma absoluta, sem nuance
- O agente está em fase inicial e ainda não tem histórico de comportamento consolidado
Não faz sentido adicionar uma regra quando:
- O problema é de tom ou de qualidade de raciocínio, não de comportamento específico
- Você está tentando corrigir um sintoma sem entender a causa
- A regra nova contradiz algo já existente no prompt
- A solução correta seria retreinar ou ajustar a persona do agente
A pergunta certa antes de qualquer nova instrução: isso é um caso que precisa de regra, ou é um sinal de que a estrutura base está fraca?
O processo de poda: como recuperar um prompt saturado
Se o seu SDR já está nesse estado, a recuperação é possível. Não é rápida, mas é direta.
Passo 1: Auditoria de regras Liste todas as instruções do prompt em linguagem natural. Sem jargão técnico. Se você não consegue explicar o que uma instrução faz em uma frase simples, ela provavelmente está mal escrita.
Passo 2: Classificação por tipo Separe o que é persona, o que é processo, o que é restrição e o que é conhecimento de produto. Misturar esses quatro tipos no mesmo bloco é uma das causas mais comuns de conflito.
Passo 3: Eliminação de redundâncias Regras que cobrem variações do mesmo cenário podem virar uma só instrução mais abrangente. Menos texto, mesma cobertura.
Passo 4: Teste isolado por bloco Avalie cada seção separadamente antes de reintegrar. Isso revela quais blocos estão causando conflito quando combinados.
Passo 5: Versionamento Trate o prompt como código. Cada mudança documentada, com data e motivo. Sem isso, o ciclo de saturação volta em semanas.
O objetivo final não é um prompt enxuto por princípio estético. É um agente que performa de forma consistente e que sua equipe consegue manter sem depender de um especialista para cada ajuste.
Perguntas frequentes
Existe um número máximo recomendado de regras em um prompt de SDR de IA? Não existe um limite universal. O sinal de saturação está no comportamento do agente, não na contagem de instruções. Um prompt com 10 regras conflitantes é mais problemático do que um com 25 bem estruturadas. Monitore consistência de resposta, não volume de texto.
Como saber se o problema de desempenho é no prompt ou no modelo escolhido? Isole o prompt em uma versão mínima, com apenas persona e processo base, sem regras específicas de situação. Se o comportamento melhorar, o problema está na camada de regras. Se persistir, o modelo ou os dados de contexto merecem revisão.
Regras de compliance também causam saturação? Podem causar, especialmente quando estão misturadas com instruções de tom e processo no mesmo bloco. O recomendado é manter regras de compliance em uma seção separada, com linguagem diretiva e sem sobreposição com outros blocos.
Vale usar few-shot examples no lugar de regras descritivas? Em muitos casos, sim. Exemplos de conversa bem conduzida ensinam o modelo a raciocinar por analogia, o que costuma ser mais robusto do que uma lista de condicionais. A combinação de estrutura de persona com exemplos representativos tende a superar prompts baseados apenas em regras.
Com que frequência o prompt de um SDR de IA deve ser revisado? Uma revisão estruturada a cada quatro a seis semanas é uma referência razoável para equipes em operação ativa. Fora do ciclo regular, qualquer mudança reativa, feita para corrigir um comportamento pontual, deve ser documentada e avaliada na revisão seguinte para verificar impacto sistêmico.
