A orquestração multi-agentes virou GA no Summer '26. A documentação cobre a superfície da API bem o suficiente. O que ela não cobre é por que os padrões que parecem limpos num sandbox desmoronam sob carga real — e quais decisões arquiteturais você vai lamentar às 3h da manhã quando o alerta de plantão disparar.
Este post assume que você já subiu ao menos uma implementação de Agentforce. Se você ainda está perguntando "o que é um agente?", comece por lá primeiro.
Os Três Padrões de Orquestração
Toda arquitetura multi-agentes em produção se encaixa em um desses padrões, ou numa combinação explícita deles. A escolha define latência, custo e complexidade de falha.
Padrão Coordenador
Um agente recebe a requisição, decompõe em subtarefas, delega para agentes especializados e monta a resposta final. O coordenador conhece o contexto completo; os workers não precisam.
É a escolha certa quando as subtarefas têm dependências — quando o input do Agente B depende do output do Agente A. O coordenador impõe o sequenciamento.
O custo de latência é real: cada hop de agente adiciona 1 a 3 segundos de inferência de modelo mais overhead interno do Salesforce. Uma cadeia de cinco agentes sequenciais num fluxo orientado ao cliente vai perder a maioria dos SLAs aceitáveis. Projete a profundidade da cadeia deliberadamente.
Use quando: as tarefas se decompõem em etapas sequenciais com dependências rígidas, ou quando você precisa de um único ponto de responsabilidade pela qualidade da resposta final.
Executor Paralelo
O orquestrador distribui para múltiplos agentes simultaneamente e consolida os resultados. A latência total se aproxima do agente mais lento individualmente, não da soma de todos.
O argumento de performance é real. O risco arquitetural é igualmente real: agentes paralelos operam sem estado compartilhado. Se o Agente A e o Agente B ambos precisam ler o mesmo registro e um deles também escreve nele, você tem uma condição de corrida. A plataforma não previne isso. Você precisa projetar agentes idempotentes e usar bloqueio de registro quando operações de escrita estão no escopo.
Um segundo modo de falha é a perda de coerência de contexto. Cada branch paralela recebe uma cópia do contexto no momento do fan-out. Se a janela de contexto for grande — digamos, um histórico de 200 mensagens — você está passando esse contexto completo para cada branch. Custos de token escalam linearmente. Mais importante: se seu orquestrador for descuidado sobre o que cada agente realmente precisa, você vai bater no limite de 32K tokens nos agentes downstream e receber erros de truncamento difíceis de reproduzir.
Use quando: as subtarefas são verdadeiramente independentes, os agentes são predominantemente de leitura, e você definiu explicitamente qual contexto cada branch precisa.
Padrão Júri
Múltiplos agentes produzem um resultado independentemente; um agente "juiz" final avalia os candidatos e seleciona ou sintetiza o melhor output. Comum em geração de conteúdo, classificação e qualquer cenário onde a variância na qualidade do output é inaceitável.
O trade-off honesto: você está rodando N+1 chamadas de modelo para cada requisição. O custo escala linearmente. A latência adiciona o hop do juiz por cima do candidato mais lento — não chega a multiplicar se os candidatos rodam em paralelo, mas o overhead é real. A melhoria de qualidade também é real, mas nem sempre proporcional ao overhead — na minha experiência, para tarefas estruturadas (extração de dados, atualização de registros), um único agente com prompt bem escrito e exemplos few-shot iguala ou supera um ensemble a uma fração do custo.
Onde ensembles genuinamente justificam o overhead é em tarefas de raciocínio aberto onde o risco de alucinação de modelo único é alto. Um ensemble de três agentes com um juiz captura uma porcentagem significativa de outputs confiantes-mas-errados que um único agente passaria sem questionamento.
Use quando: a variância na qualidade do output é um risco de negócio, as tarefas são abertas o suficiente para que múltiplas abordagens válidas existam, e o orçamento de latência e custo suporta isso.
Quando Ensembles Não São Melhores
Isso merece uma afirmação direta porque o marketing em torno de sistemas multi-agentes implica que mais agentes sempre significa resultados melhores.
Para tarefas curtas e bem escoped (buscar uma conta, atualizar um campo, enviar uma notificação), adicionar agentes adiciona latência e superfície de falha sem benefício de qualidade. Cada hop adicional de modelo é um novo lugar onde o contexto pode ser mal interpretado, a chamada de ferramenta pode falhar, ou a resposta pode estar malformada.
Para tarefas com histórico longo de conversa, agentes paralelos recebendo o contexto completo produzirão outputs individuais coerentes, mas o orquestrador terá que reconciliar N perspectivas geradas sem consciência uma da outra. Na prática isso cria inconsistências sutis na resposta consolidada que são difíceis de detectar e difíceis de explicar para os usuários.
A pergunta certa não é "quantos agentes posso adicionar?" É "qual é o número mínimo de agentes que mantém as responsabilidades claramente separadas?"
O Que Quebra Silenciosamente em Produção
Estes são os modos de falha que encontrei em implementações em produção e que não apareceram nos testes em sandbox.
Condições de corrida em execução paralela. Dois agentes atualizam o mesmo registro relacionado na mesma janela de transação. A segunda escrita vence silenciosamente. Nenhum erro é lançado. O trabalho do primeiro agente é sobrescrito. Isso é particularmente perigoso em contextos financeiros ou de compliance onde cada alteração precisa ser intencional.
Dados desatualizados passados para agentes downstream. O coordenador busca o contexto do CRM no início da requisição. Um agente paralelo rodando 8 segundos depois recebe aquela snapshot de contexto. Se outro processo (um humano, um Flow, outro agente) modificou os registros subjacentes nessa janela, o agente downstream está tomando decisões com dados obsoletos. Com volume baixo isso é invisível. Em escala, aparece como inconsistências misteriosas.
Overflow de janela de contexto sem erro explícito. Agentes se aproximando do limite de tokens começam a truncar silenciosamente o contexto mais antigo. O modelo continua operando com uma visão incompleta. Isso não lança uma exceção. O primeiro sinal é tipicamente degradação da qualidade do output ou agentes "esquecendo" instruções anteriores, o que é genuinamente difícil de diagnosticar numa cadeia.
Exaustão silenciosa de AWU. Se uma cadeia de agentes atinge o limite de AWU da org ou do entitlement atual, ela nem sempre falha de forma barulhenta. Dependendo de onde na cadeia o limite é atingido, você pode ter execução parcial — alguns registros atualizados, outros não — sem superfície de erro clara. Veja o Post 2 desta série para governança de AWU em profundidade.
Arquitetura de Latência
Para fluxos orientados ao cliente, o teto prático fica em torno de 8 a 10 segundos totais antes de os usuários começarem a abandonar. Para automação de backend é mais tolerante, mas sistemas downstream têm seus próprios timeouts.
Algumas regras que se sustentaram na prática:
Mantenha o coordenador leve. Seu trabalho é decomposição e montagem, não raciocínio. Se seu agente coordenador está fazendo análise complexa, esse trabalho deve estar num agente especializado para o qual ele delega.
Paralelize agressivamente dentro de um estágio, minimize os estágios. Um estágio de orquestração com três agentes paralelos é quase sempre mais rápido do que três estágios sequenciais com um agente cada. Modele o grafo de dependências explicitamente.
Faça cache do contexto do CRM no nível do coordenador e passe referências, não dados completos. Agentes que precisam de dados de conta devem receber o ID da conta e buscar o que precisam, não receber um blob JSON de 50 campos que veio da consulta inicial do coordenador. Isso também reduz a pressão de tokens ao longo da cadeia.
Ao misturar dados do CRM com chamadas a APIs externas na mesma cadeia, projete os agentes de chamada externa com timeouts explícitos e comportamentos de fallback. Uma API externa com timeout de 29 segundos não vai respeitar seu SLA de 10 segundos. O limite de callout do Salesforce de 120 segundos se aplica por transação, não por agente — mas uma chamada externa travada bloqueia a cadeia inteira.
O Que Ainda Não Está Pronto
Algumas limitações honestas do release GA a partir do Summer '26.
Memória entre agentes ainda é por sessão. Não há mecanismo nativo para agentes compartilharem estado persistente entre sessões. Se você precisa que as descobertas do Agente A na segunda-feira estejam disponíveis para o Agente B na terça, você está construindo essa camada de persistência por conta própria — tipicamente através de registros do CRM ou Custom Metadata.
O modelo de confiança agente-a-agente é grosseiro. Quando um coordenador delega para um agente worker, o worker roda com as permissões do coordenador. Não há escopo fino de capacidades no nível da chamada agente-a-agente. Para operações sensíveis a privilégio, isso significa que você não pode facilmente criar um coordenador com acesso amplo de leitura mas acesso restrito de escrita para workers específicos.
A tooling de observabilidade ainda está evoluindo. Os logs de auditoria nativos do Agentforce dão request/response na fronteira do agente, mas rastrear uma decisão através de uma cadeia multi-agentes — entender por que um worker específico produziu um output específico — exige instrumentar seus próprios metadados. Essa é a lacuna de operabilidade que vai te morder primeiro em produção.
Nenhum desses é um bloqueador, mas são restrições para projetar em torno, não ignorar.
Próximo nesta série: governança de custo de AWU, design de audit trail e estratégias de rollback para cadeias de agentes que modificam registros em escala.
Perguntas ou histórias de guerra das suas próprias implementações? LinkedIn.
