Vários agentes: roteamento, transferência e consulta

Como dividir o atendimento entre agentes especialistas sem perder o contexto da conversa.

Por que dividir em vários agentes

Um agente que tenta responder tudo fica com diretrizes enormes, base de conhecimento misturada e ferramentas demais — e erra mais. A alternativa é ter especialistas (vendas, suporte, cobrança) e combinar quatro mecanismos:

Mecanismo	O que faz	Quando usar
Roteamento inicial	Escolhe quem responde a primeira mensagem, sem IA	O canal ou a origem já diz de que assunto se trata
Transferência (swap)	Passa a conversa inteira para outro agente	Durante a conversa, o assunto muda de dono
Consulta (ask)	Pergunta a outro agente e usa a resposta, sem transferir	Só falta uma informação de outro domínio
Políticas de escalação	Regras determinísticas que chamam humano ou trocam de agente	Casos críticos que não podem depender da decisão da IA

ℹ️

Esses recursos são liberados por ambiente. Se alguma opção não aparecer no formulário do agente, ou não surtir efeito, fale com o suporte para habilitá-la no seu workspace.

Roteamento inicial

Em Agentes → [agente] → Regras de roteamento inicial, você cria regras que escolhem o agente que responde à primeira mensagem. Não há IA envolvida: a primeira regra que casar vence; se nenhuma casar, responde o próprio agente.

Cada regra combina condições:

Campo	Operadores	Exemplo
Canal	é igual a, está na lista	canal = `whatsapp`
Palavra-chave	contém	mensagem contém "segunda via"
Variável do contato	é igual a, contém, está na lista	`plano` = `enterprise`

A comparação ignora maiúsculas e acentos.

⚠️

Para criar regras é preciso ter ao menos um agente de destino marcado na seção de transferência. O destino da regra sai dessa lista.

Transferência entre agentes (swap)

Ligue Permitir transferir para outros agentes e marque os agentes de destino. O agente ganha a ação de passar a conversa quando o assunto for melhor atendido por um especialista — levando resumo e contexto, para o visitante não repetir tudo.

Allowlist obrigatória — Só os agentes marcados podem receber a conversa, e isso é validado no servidor
Limite por conversa — Defina quantas transferências uma conversa pode ter (evita ping-pong entre agentes)

⚠️

A troca de agente vale nos canais de texto. Em voz, o pipeline em tempo real não executa esse tipo de ação — planeje a operação de voz com um agente por número. Entre canais de texto, a troca com reflexo no atendimento humano é mais completa no Freshchat; nos demais, prefira "chamar humano".

Consulta entre agentes (ask)

Nem toda dúvida justifica transferir a conversa. Com a consulta, o agente pergunta a um especialista e usa a resposta para continuar falando com o visitante.

Marque em Agentes que este agente pode consultar (nenhum marcado = consulta desativada)
O agente consultado recebe apenas a pergunta e um resumo — nunca o histórico da conversa
Há limite de consultas por conversa e timeout, para não travar a resposta

💡

Consulta é a escolha certa quando o visitante quer uma informação de outro domínio ("qual o prazo de entrega?") no meio de um atendimento comercial. Transferir nesse caso só cria atrito.

O custo das consultas aparece separado em Analytics → Consumo e custos → Custo do provedor (USD) → Por finalidade (só ADMIN), como "Consulta entre agentes".

Políticas de escalação

Em Agentes → [agente] → Políticas de escalação, você define regras que não dependem da IA: quando as condições casarem, a plataforma chama um humano ou troca de agente. A primeira política que casar vence.

Ação — Chamar humano ou trocar de agente
Motivo do handoff (opcional) — Um intent_slug (ex.: enterprise), útil para rotear ao grupo certo no Freshchat
Condições — Comparações numéricas e de texto sobre variáveis do contato

⚠️

Variáveis que não estão no schema de extração do agente só têm valor vindo de conversas anteriores — elas não são detectadas na conversa em curso. Se a política depende de um dado coletado agora, inclua esse campo na extração.

Prompts por estágio (dentro de um agente)

Quando a conversa tem fases claras (qualificação → proposta → fechamento), em vez de mais agentes use Prompts por estágio: cada estágio tem seu próprio system prompt, e a transição acontece por regra (padrão de texto) ou por decisão do LLM, se você permitir.

Estágio default — Onde a conversa começa
Allowlist de transições — Só os estágios marcados podem ser alvo
Regras de transição — Padrões validados contra regex inseguro (proteção contra ReDoS)

💡

Um agente com estágios é mais simples de operar do que três agentes com transferência entre eles. Use vários agentes quando mudam também as ferramentas e a base de conhecimento; use estágios quando muda só o roteiro.

Acompanhando

Inbox — Mostra o agente ativo, o motivo da transferência e a origem (decisão da IA, regra do fluxo, roteamento automático ou política)
Conversas → Logs — Cada passo, incluindo consultas a outros agentes
Analytics → Consumo e custos → Custo do provedor (USD) — Custo por agente e por finalidade (só ADMIN)

Erros comuns

Allowlist vazia — Sem agentes de destino marcados, a transferência simplesmente não existe para a IA
Sem limite de transferências — Conversa pulando entre agentes cansa o visitante; comece com um limite baixo
Especialistas sem base própria — Se todos os agentes leem as mesmas bases, dividir não melhora nada
Regra de roteamento genérica demais — Uma palavra-chave muito comum captura conversas que não eram para ela; a primeira regra que casa vence
Contar com swap em voz — Em ligação, resolva com transferência para um número (destinos de transferência) em vez de troca de agente