Desde 15 de junho de 2026, o Multi-Agent Orchestration do Agentforce saiu do beta e chegou à disponibilidade geral. Isso significa que, pela primeira vez, empresas podem colocar múltiplos agentes de IA trabalhando juntos como uma equipe coordenada — cada um especializado em um domínio diferente — sem que o cliente precise repetir informação ou navegar entre bots desconectados.
A mudança parece simples no slide de keynote, mas a execução é outra história. Quando você distribui trabalho entre agentes especializados, cada um executa fielmente a lógica que já existe no seu org. Se a lógica está quebrada, o erro se multiplica. E se a descrição de um agente é vaga, o roteamento falha silenciosamente.
Neste artigo, vou explicar como funciona a arquitetura por trás dessa orquestração, como o Atlas Reasoning Engine 3.0 decide quem recebe cada tarefa, e o que você precisa fazer antes de ativar isso em produção.
Do bot isolado ao time de agentes
Até o Spring ’26, a maioria das implementações de Agentforce seguia o mesmo padrão: um agente por domínio. Um bot respondia dúvidas de produto, outro qualificava leads, outro resolvia tickets de suporte. Cada um funcionava de forma independente, com suas próprias instruções e contexto. Quando o cliente precisava de algo que cruzava domínios, a experiência quebrava — ele precisava repetir a história para cada bot ou, pior, desistia e pedia para falar com um humano.
O Multi-Agent Orchestration muda esse cenário. Agora existe um agente primário que serve como ponto de contato único. Ele recebe a solicitação, interpreta o que o cliente precisa, e roteia para o especialista mais adequado. Se a conversa envolve mais de um domínio — digamos, uma dúvida sobre faturamento que depende de informações do contrato — o orquestrador coordena a transição mantendo o contexto compartilhado entre os agentes envolvidos.
Para o cliente, a experiência é contínua. Ele conversa com “um agente” que, por dentro, é uma equipe.
Como o Atlas Reasoning Engine 3.0 decide quem recebe a tarefa
A camada de coordenação por trás da orquestração é o Atlas Reasoning Engine 3.0, que acompanha o Summer ’26. O mecanismo de roteamento funciona de uma forma que vale a pena entender em detalhe, porque tem consequências diretas na forma como você descreve seus agentes.
Diferente de sistemas baseados em árvores de decisão fixas, o Atlas não segue regras rígidas de roteamento. Ele lê a descrição, as instruções e as ações disponíveis de cada subagente registrado e usa essa informação para decidir qual especialista é o mais adequado para cada tarefa. Em seguida, decomõe a solicitação em sub-tarefas, distribui para os especialistas relevantes, coleta os resultados e remonta uma resposta final para o usuário.
Isso significa que a descrição de cada agente não é documentação para humanos — é um insumo de roteamento que afeta diretamente a qualidade das respostas. Uma descrição vaga como “agente de suporte” faz o orquestrador rotear incorretamente. Uma descrição precisa como “responde dúvidas sobre faturas, prazos de pagamento e status de cobrança — não resolve disputas nem concede descontos” reduz drasticamente os erros de roteamento.
Na prática, escrever descrições de agentes se tornou uma atividade de arquitetura, não de configuração.
O problema das costuras: quando o orquestrador amplifica seus erros
Essa é a parte que os materiais de lançamento não destacam, mas que qualquer arquiteto precisa entender antes de colocar multi-agent em produção.
Em um sistema multi-agente, nenhum agente tem visão global do fluxo. Cada especialista opera dentro do seu domínio, executando a lógica existente de forma fiel. Se a sua regra de atribuição de leads foi escrita para uma equipe de vendas que não existe mais, o agente de roteamento vai seguir essa regra. Se uma política de atendimento foi descontinuada mas continua ativa na configuração, o agente de suporte vai honrar essa política. Se um campo customizado foi reutilizado três vezes com significados diferentes, o agente de previsão vai usar o valor errado.
Nenhum desses é um defeito do Agentforce. São defeitos na fundação que o Agentforce agora executa de forma fiel, centenas de vezes por hora, com logs de auditoria documentando cada execução.
Antes de ativar a orquestração multi-agente, faça um levantamento completo dos seus dados e processos. Verifique regras de atribuição, políticas de atendimento, campos customizados e automações ativas. Esse audit é o seguro mais barato que você pode ter — e a maioria das empresas pula essa etapa porque o contrato de licença já foi assinado.
Interoperabilidade: MCP e A2A conectando agentes além do Salesforce
O Summer ’26 também trouxe o Tableau MCP, que permite aos agentes do Agentforce consultar diretamente o motor de analytics do Tableau. As respostas passam a ser fundamentadas em dados reais do negócio, protegidas pela Trust Layer do Agentforce.
O MCP (Model Context Protocol) é um padrão aberto introduzido pela Anthropic em novembro de 2024 para padronizar como sistemas de IA se conectam a ferramentas e dados externos. No contexto do Agentforce, a conexão funciona nos dois sentidos: agentes podem chamar ferramentas MCP externas como fontes de ação, e workflows do Salesforce podem ser expostos como ferramentas MCP para outros sistemas.
Para agentes que vivem fora do ecossistema Salesforce, existe o protocolo A2A (Agent2Agent), que permite ao agente primário delegar trabalho de forma segura a agentes de terceiros em outras plataformas. O A2A foi lançado pelo Google em abril de 2025 com mais de 50 parceiros, incluindo o Salesforce, e agora é administrado pela Linux Foundation.
Juntos, MCP e A2A formam a camada de interoperabilidade que permite times de agentes cruzarem fronteiras de vendor, em vez de ficarem presos no silo de uma única empresa.
Tableau MCP: transformando agentes em analistas de dados
O Tableau MCP merece uma seção própria porque muda a forma como agentes de IA interagem com dados analíticos. Até agora, quando um agente precisava de insights baseados em dados, ele dependia de informações estáticas ou de integrações customizadas. Com o Tableau MCP, o agente consulta diretamente o motor de analytics do Tableau, obtendo respostas fundamentadas em dados reais e atualizados.
Imagine um agente de vendas que, ao qualificar um lead, pode consultar automaticamente o histórico de compras do segmento, as tendências de conversão por região e o pipeline atual — tudo via Tableau MCP, sem precisar de uma integração dedicada para cada consulta.
A implementação usa o padrão MCP hospedado pelo Salesforce, o que significa que a configuração é relativamente simples para quem já tem Tableau no ambiente. O agente se conecta ao servidor MCP do Tableau, recebe as capabilities disponíveis (schemas, métricas, dimensões) e pode fazer consultas estruturadas diretamente.
Guia prático: o que fazer antes de ativar Multi-Agent Orchestration
Se você está considerando implementar a orquestração multi-agente, aqui está uma sequência que funciona:
Semanas 1 a 3 — Avaliação de dados e permissões. Audite suas regras de atribuição, políticas de atendimento, campos customizados e automações ativas. Identifique o que está desatualizado e corrija antes de conectar agentes. Verifique se o Data Cloud está configurado corretamente para fornecer contexto unificado entre os agentes.
Semanas 4 a 8 — Piloto contido. Comece com um único fluxo de orquestração bem delimitado. O cenário de handoff de qualificação de lead — do Customer Engagement Agent para um vendedor humano — é um bom ponto de partida. Defina métricas de sucesso claras: taxa de resolução, tempo médio de atendimento, satisfação do cliente.
Semanas 9 a 12 — Medição e decisão. Analise os resultados do piloto e decida se expande para outros domínios ou ajusta a configuração. Não tente cobrir todos os canais e domínios de uma vez — isso é receita para agent sprawl.
O papel do Agent Script na orquestração
O Agent Script, parte do Agentforce 360, é uma linguagem de script que permite definir fluxos explícitos de if/then onde a sequência e os resultados precisam ser consistentes. Em um contexto multi-agente, isso se torna particularmente útil para garantir que certas etapas aconteçam sempre na ordem correta.
Por exemplo, antes de um agente de cobrança iniciar uma ação, o Agent Script pode garantir que a verificação de identidade do cliente aconteceu primeiro. Ou que um agente de vendas só ofereça desconto após consultar a política de preços vigente via Tableau MCP. Essas garantias determinísticas são o que separa um sistema multi-agente confiável de um que funciona bem 80% do tempo e falha catastroficamente nos outros 20%.
Observabilidade: monitorando um time de agentes
Quando você tem múltiplos agentes trabalhando juntos, o monitoramento tradicional de aplicação não é suficiente. Um agente pode retornar uma resposta plausível, bem formatada e completamente errada para a situação — sem gerar erro, sem alerta, sem nada nos logs que indique um problema.
O Agentforce Observability foi construído especificamente para esse cenário. Ele oferece rastreamento de sessão a nível de conversa, capturando o caminho completo de raciocínio; categorização de intenções que identifica quando os usuários estão pedindo coisas para as quais o agente não foi projetado; e alertas de anomalia que disparam com base em desvio comportamental, não em erros de sistema.
Em um ambiente multi-agente, essa observabilidade se torna essencial. Você precisa saber qual agente tratou cada parte da conversa, como o contexto foi passado entre eles, e onde a cadeia de raciocínio pode ter se desviado.
Impacto para arquitetos e desenvolvedores
A chegada do Multi-Agent Orchestration à GA muda o jogo de várias formas. Para arquitetos, a prioridade agora é definir a taxonomia de agentes: quais domínios merecem um agente dedicado, como as descrições devem ser escritas, e onde as fronteiras entre agentes devem ficar. A tentação de criar um agente para cada micro-domínio é grande, mas cada agente a mais é uma costura a mais no sistema.
Para desenvolvedores, o foco muda de “como construir um bot” para “como garantir que os bots trabalhem bem juntos”. Isso envolve testes de integração entre agentes, validação de roteamento e, principalmente, garantir que as descrições dos agentes sejam precisas e atualizadas.
A mensagem central é simples: a capacidade técnica de colocar agentes para trabalhar juntos já existe e está em GA. O que determina se a implementação funciona ou falha não é o modelo de IA por trás — é a qualidade dos dados, a precisão das descrições dos agentes e a disciplina de governança que você aplica antes de ativar a orquestração.
O Summer ’26 deu às empresas a ferramenta. Agora o trabalho de verdade começa.