Arquitetura Multi-Agent no Agentforce: Como Escalar Abordagens Contornando Limites de Infraestrutura

O problema real não era o Agentforce — eram os limites de infraestrutura

Uma rede comercial precisava reativar mais de 100 mil contatos e leads dormentes no CRM, com foco em vendas B2B. O volume era absolutamente inviável para o tamanho do time humano de vendas. A decisão foi usar o Agentforce como camada de prospecção automatizada. Mas o desafio técnico central não era a ferramenta em si — era a infraestrutura ao redor dela.

O provedor de e-mail corporativo impunha limites rígidos de envios diários por conta. Com o Einstein Activity Capture rodando em paralelo, o limite efetivo caía ainda mais. Na prática: um único agente trabalhando sozinho levaria meses apenas para zerar o backlog inicial. Essa conta não fecha para nenhum negócio com urgência real de pipeline.

Escalabilidade horizontal como decisão arquitetural

A resposta da equipe foi correta e direta: escalar horizontalmente. Foram implementados dez agentes paralelos atuando no mesmo escopo operacional, com divisão de responsabilidades clara:

• Sete agentes dedicados exclusivamente a contatos inativos
• Três agentes focados em leads com preenchimento de campos essenciais de negócio

Com dez processos autônomos rodando simultaneamente, a questão central virou controle e governança. Como garantir que esses agentes não entrem em conflito, não processem o mesmo registro duas vezes ou disparem comunicações cruzadas para a mesma pessoa?

Roteamento baseado em critérios: simples, explícito e mantível

A solução foi o roteamento nativo por critérios, configurado diretamente pela interface padrão da plataforma — sem Apex customizado e sem teia de automações em Flow para orquestrar filas.

• Para contatos: divisão em blocos alfabéticos pelo sobrenome. Cada agente assumiu uma fatia precisa e não-sobreponível da base.
• Para leads: a distribuição foi orientada pelo preenchimento de campos de negócio essenciais.

Registros sem e-mail válido ou com sinalização de opt-out eram bloqueados antes mesmo de chegar ao agente. Essa filtragem upstream é exatamente o tipo de decisão que separa um projeto funcional de um projeto que cria problema de compliance.

Evitar lógica complexa no Apex para orquestrar filas não é preguiça arquitetural — é disciplina. Quanto mais você empurra complexidade para dentro da plataforma padrão, menos você tem para manter fora dela.

Templates centralizados: o antídoto contra desvio de comportamento

Manter dez automações paralelas atualizadas com configurações isoladas é uma receita garantida para inconsistência. O risco concreto: cada agente começa a se comunicar com o mercado de forma ligeiramente diferente, degradando a percepção de marca e tornando qualquer ajuste de estratégia um trabalho manual multiplicado por dez.

A decisão correta aqui foi usar custom prompt templates completamente centralizados via Prompt Builder. Tom de voz, regras de resposta e critérios de abordagem ficam em um repositório único. Quando a equipe ajusta o prompt base para melhorar taxa de conversão ou adaptar o posicionamento, todos os agentes herdam a alteração imediatamente — sem exceção.

Isso elimina o risco de comunicação inconsistente entre filas e mantém a governança editorial centralizada, independente do volume de agentes ativos.

A experiência na ponta e o repasse humano inteligente

Para o cliente final, a interação opera visualmente como uma troca de e-mails comum — sem fricção de interface. O que muda é o que acontece no backend quando há resposta:

• Pedido de reunião → sistema gerencia o calendário diretamente
• Pedido de ligação → plataforma identifica a intenção e cria uma tarefa acionável para um vendedor no Sales Cloud
• Intenção técnica ou comercial validada → repasse humano ocorre de forma estruturada, não aleatória

O agente não tenta fechar o que não é dele fechar. O handoff acontece no momento certo, com contexto completo.

Gerenciamento de picos e proteção de governadores

O gerenciamento nativo de limites e o enfileiramento de mensagens absorvem picos de volume sem estourar governadores da org. Se uma fatia alfabética tem densidade maior de registros ativos em determinado período, eles entram em fila e são processados de forma gradativa. Isso protege a org de picos inesperados e mantém o fluxo operacional previsível.

Antes de plugar toda essa estrutura, o time fez análise prévia das automações existentes nos objetos principais — mapeando conflitos potenciais antes que eles virassem incidente em produção. Esse trabalho fundacional costuma ser ignorado em projetos com pressão de entrega. Aqui foi feito. Faz diferença.

O que esse projeto ensina sobre adoção real do Agentforce

Esse desenho é um caso prático de como pensar projetos complexos no ecossistema Salesforce com pragmatismo arquitetural. Alguns princípios que ficam evidentes:

1. Automação que ignora limites de integração é automação que vai falhar. Entender os tetos do provedor externo antes de desenhar o volume é pré-requisito, não detalhe.
2. Escalabilidade horizontal exige critérios de roteamento explícitos. Sem isso, paralelismo vira caos.
3. Centralização de templates não é detalhe de configuração — é decisão de governança. Qualquer projeto com múltiplos agentes que não resolva isso vai acumular dívida técnica editorial.
4. Higiene de dados upstream é inegociável. Registros sem e-mail ou com opt-out precisam ser tratados antes do agente, não dentro dele.

Ligar o Agentforce e esperar conversão não é estratégia. O trabalho real está em fatiar a base corretamente, entender os limites dos provedores externos e centralizar a lógica de comportamento em templates. Arquitetura e qualidade de dados ditam o resultado. A ferramenta executa o que você construiu — e só isso.