Arquitetura de Filas no Agentforce: Como escalar integrações de IA contornando limites de LLM

O Problema Real Antes da Solução

A chegada de agentes autônomos ao ecossistema Salesforce não trouxe apenas possibilidades — trouxe uma nova categoria de problema arquitetural que boa parte das implementações ainda vai descobrir da pior forma: em produção. Quando analisamos o funcionamento do Agentforce Sales Engagement, especificamente no papel de Lead Nurturing, o volume de interações simultâneas que ele precisa suportar é impressionante. Clientes chegam a atribuir mais de 10.000 leads em um único dia. O gargalo não está no banco de dados relacional. Está no limite rígido de requisições por minuto — o famoso RPM — imposto pelos provedores de LLM, que tipicamente gira em torno de 300 chamadas por minuto.

Sem uma arquitetura de enfileiramento robusta, esse número é atingido em segundos. O que vem depois são falhas em cascata, bloqueio de fluxos humanos e, inevitavelmente, um incidente de P1 no pior momento possível.

O Desafio Central: Concorrência Entre Agentes e Humanos

Agentes de IA têm capacidade de processamento muito superior à humana — e é exatamente isso que os torna perigosos para a infraestrutura compartilhada da org. Vendedores humanos e bots autônomos dividem os mesmos limites de RPM e as mesmas restrições de envio de e-mail. Sem orquestração, o agente monopoliza os recursos disponíveis em minutos, deixando os fluxos desenhados para humanos em espera ou disparando erros de throttling no gateway do LLM.

Para resolver esse problema de concorrência, a plataforma aplica um mecanismo de alocação por distribuição justa. O funcionamento é o seguinte:

• O trabalho é agrupado por contexto de execução: agentes de IA são agrupados por usuário de bot; fluxos humanos, por proprietário do registro.
• Um despachante central itera sobre esses grupos usando uma estratégia round-robin, puxando uma ação de cada contexto até preencher a capacidade de disparo do ciclo corrente.
• O resultado é equilíbrio garantido — nenhum contexto monopoliza o throughput disponível.

Dois Padrões de Design que Valem Atenção

1. Gestão Dinâmica de Prioridade

Nem todo e-mail tem o mesmo valor de negócio, e tratar todos igualmente é um erro de arquitetura. Uma resposta de um lead engajado tem prioridade crítica sobre um e-mail de introdução ou um lembrete automatizado. A engenharia do produto implementa uma fila de três níveis com a seguinte lógica de despacho:

1. O sistema sempre tenta esgotar primeiro a fila de respostas (maior valor de negócio).
2. Se sobrar capacidade, realiza preenchimento adaptativo com e-mails de introdução.
3. Somente então processa o restante da fila.

Isso garante 100% de utilização do throughput disponível sem penalizar as oportunidades mais quentes — que são exatamente aquelas que nenhum time de vendas pode se dar ao luxo de deixar esfriar.

2. Isolamento de Fluxo para Revisão Humana

Em indústrias reguladas, comunicações geradas por IA exigem aprovação humana antes do envio. Esse requisito cria um problema grave de inanição de recursos: se mensagens aguardando aprovação ficassem presas na mesma fila de geração autônoma, o sistema travaria progressivamente.

A solução adotada é uma bifurcação de fluxo:

• Para mensagens que exigem revisão, a IA gera o rascunho de forma totalmente assíncrona na fase inicial, consumindo RPM nesse momento.
• Quando o usuário aprova o conteúdo, o envio entra em uma esteira separada de agendamento — que avalia apenas limites diários de e-mail e horário comercial, sem consumir novamente capacidade de requisição do LLM.

Simples na descrição. Crítico na prática.

O RPM é o Novo Governor Limit

Esse modelo revela o grau de maturidade arquitetural necessário para escalar inteligência artificial em ambiente corporativo. O limite de requisições de LLM é, na prática, o novo Governor Limit do ecossistema Salesforce. E precisa ser tratado com o mesmo respeito que sempre dedicamos a limites de DML, SOQL e heap size.

No passado, quando enfrentávamos concorrência e limites de transação síncrona, a resposta imediata era recorrer ao processamento assíncrono: Batch Apex, Queueable, plataform events. Com IA generativa, a abordagem reativa de tentar, falhar e reprocessar não se sustenta. Retentativas competem diretamente com novos trabalhos e causam falhas progressivas no gateway do LLM — um efeito de bola de neve difícil de controlar.

A modulação de taxa adaptativa — onde o sistema verifica o consumo da org em tempo real e reduz proativamente o volume de envios ao se aproximar do limite — não é otimização. É requisito de arquitetura.

O que Isso Significa para Quem Constrói na Plataforma

Usar ferramentas prontas como o Lead Nurturing do Agentforce não exige que você construa essas filas do zero. Mas exige que arquitetos e consultores entendam profundamente como a plataforma processa a carga — porque as mesmas decisões de design que a Salesforce Engineering tomou aqui precisarão ser replicadas em qualquer solução customizada que envolva agentes autônomos em volume.

Ao projetar workloads na era do Agentforce, as seguintes premissas são inegociáveis:

• Isole fluxos paralelos. Agentes autônomos e fluxos humanos não devem competir por recursos no mesmo nível sem mediação.
• Modele prioridade explicitamente. A fila plana é conveniente e errada para a maioria dos casos de uso de IA em vendas.
• Desenhe para o limite, não contra ele. Modulação proativa de taxa é mais barata do que recovery de falhas em produção.
• Elimine chamadas síncronas pesadas. Escalabilidade não perdoa integrações síncronas em workflows de alto volume.

Refinar o prompt é importante. Mas sem uma arquitetura de orquestração sólida por baixo, o melhor prompt do mundo não vai chegar ao destinatário.