O guia do arquiteto para interoperabilidade do Agentforce

Criado por: A equipe de produtos do Agentforce (Pragya Anand , Moe Basi , Shiv Ramanna , Kyle Bransky )

Continue lendo para saber mais sobre como definir sua abordagem de interoperabilidade.
Em seguida, baixe a Parte 2 para usar como guia de referência durante a criação.

Antes de projetar sistemas multiagentes, é importante entender como um único agente funciona. Um agente do Agentforce é composto por subagentes (anteriormente chamados de tópicos), blocos de construção modulares com escopo para domínios específicos, cada um com ações definidas (por exemplo, Flow, Apex, prompts).

Cada agente do Agentforce executa seu próprio ciclo de raciocínio com LLM, orquestrando como as tarefas são delegadas entre os subagentes e como as respostas são formuladas até que a meta seja alcançada. O mecanismo de raciocínio do Agentforce estende esse ciclo com determinismo baseado em Agent Script, adicionando transições explícitas e sequenciamento entre subagentes, garantindo um comportamento previsível e controlável em vez de depender apenas das decisões de LLM. Essa combinação de raciocínio com LLM e scripts determinísticos é o que possibilita fluxos de trabalho de negócios. Um único agente pode lidar com muita coisa, mas, à medida que a complexidade cresce, ele encontra estas limitações:

• Limites de acesso a dados: Não é possível acessar dados, fluxos de trabalho e permissões que estão em diferentes organizações ou sistemas Salesforce. Essa é uma limitação arquitetônica que um design de agente único não pode superar.
• Sobrecarga de contexto: O contexto do mecanismo de raciocínio com LLM é preenchido com instruções, resultados de ações e histórico de conversas até que ele comece a ignorar as regras principais ou a confundir tópicos.
• Colapso da especialização por domínio: Um agente que tenta ser especialista em tudo aplica a lógica errada para invocar subagentes específicos. Quanto maior o bloco de instruções, pior a precisão.

Estrutura de decisão: Use agentes únicos quando seu processo de negócios for relativamente simples, operar em um único domínio e exigir um conjunto unificado de acesso a dados entre seus subagentes.

A orquestração SOMA (organização única, vários agentes) permite que vários agentes especializados do Agentforce trabalhem juntos de forma integrada em uma única organização Salesforce. Em vez de exigir que os usuários gerenciem conversas com diferentes agentes individualmente, a SOMA fornece um agente conversacional unificado como porta de entrada. Nos bastidores, um agente "Superagente" ou "orquestrador" coordena e delega tarefas de forma inteligente a agentes especializados, garantindo que cada tarefa seja tratada pelo agente mais bem preparado para isso.

Estrutura de decisão: Use o SOMA quando seus clientes quiserem uma experiência unificada de "porta de entrada" para agentes especializados que operam em um único ambiente da Salesforce (organização).

• Prós: Simplifica a experiência do usuário ao fornecer um ponto de entrada conversacional para vários agentes especializados.
• Contras: Limitado aos dados e fluxos de trabalho disponíveis em uma única organização da Salesforce.

A orquestração MOMA (Multi-Org Multi-Agent), como evolução lógica do modelo de organização única (SOMA), permite que várias organizações Salesforce forneçam uma experiência unificada de agente sem a necessidade de uma consolidação complexa de dados. Essa arquitetura é construída com base em uma filosofia de delegação intencional em vez de uma rede aberta e impõe uma restrição intencional de um nível de profundidade (Agente A>Agente B, não Agente A->B->C) para evitar encadeamentos imprevisíveis. A segurança é mantida por meio da execução com reconhecimento da identidade do usuário e da operação dentro de um limite de confiança do Data 360 One (DC1).

Estrutura de decisão: Use o MOMA quando sua rede nativa do Agentforce precisar delegar tarefas com segurança entre diferentes organizações da Salesforce sem consolidar modelos de dados.

• Prós: Oferece uma experiência unificada de agente em cenários corporativos complexos, mantendo a residência rigorosa dos dados.
• Contras: O mapeamento da identidade do usuário em várias organizações e o compartilhamento do contexto entre organizações podem ser desafiadores.

O cliente do Model Context Protocol (MCP) permite que os administradores do Agentforce registrem servidores MCP externos para que os criadores possam integrar ferramentas, recursos e ações remotas no Agentforce de forma padronizada. Isso permite que o Agentforce consuma recursos externos por meio de um contrato de ferramenta, em vez de integrações personalizadas ponto a ponto.

Estrutura de decisão: Use o Cliente MCP quando o Agentforce deve permanecer o orquestrador principal e simplesmente precisar de acesso a recursos externos como ferramentas. Por exemplo, extrair dados de um sistema externo, invocar um fluxo de trabalho, pesquisar uma fonte de conhecimento ou agir por meio de uma plataforma de terceiros.

Use o Cliente MCP quando o Agentforce deve consumir um recurso externo como uma ferramenta.

• Prós: Transforma serviços externos em ferramentas seguras e governáveis para o Agentforce sem código personalizado; inclui recursos de segurança, como verificações de integridade semântica (anti-rug pull) e pontuação de risco para evitar o envenenamento da ferramenta. Ele mantém o ciclo de raciocínio centrado no Agentforce enquanto expande o que o Agentforce pode fazer.
• Contras: A abstração é intencionalmente centrada na ferramenta. Se o recurso remoto for melhor modelado como um agente especializado que deve possuir parte do raciocínio ou do fluxo de trabalho, forçá-lo para o MCP pode não ser natural. Além disso, como o esquema é definido pelo servidor externo, as alterações no contrato podem fazer com que a integração falhe até que seja atualizado ou registrado novamente.

Agentforce A2A Outbound é a maneira nativa de os agentes do Agentforce colaborarem diretamente com um agente de terceiros. Para permitir isso, os administradores devem primeiro registrar o agente externo detalhando suas habilidades, recursos e protocolos de transporte específicos. Uma vez registrado e conectado a um agente do Agentforce, ele fica disponível em tempo de execução para delegação segura de tarefas entre plataformas.

Estrutura de decisão: Use o A2A do Agentforce quando sua rede nativa do Agentforce precisar interagir com segurança com agentes de fornecedores externos, como o Google ou o Box. Observação: Aqui, um agente precisa delegar o trabalho a outro agente responsável por parte do raciocínio, planejamento ou execução.

• Prós: Como ele está integrado diretamente ao Agentforce, você não precisa adquirir ferramentas de orquestração externas para gerenciar esses fluxos de trabalho multiagentes. Ele permite um ecossistema de IA de "marca unificada" para os usuários e usa conhecimento pré-criado de plataformas externas.
• Contras: Confiar em agentes de terceiros e garantir a privacidade dos dados entre sistemas pode ser um desafio. Isso requer o registro manual dos recursos do agente de terceiros e padrões de autenticação correspondentes.

Use esta regra simples: A principal distinção não é se há IA em ambos os lados. A principal distinção é como o recurso remoto é modelado:

• Se ele for modelado como uma ferramenta, use MCP
• Se ele for modelado como um agente colaborador, use A2A

O A2A de entrada permite que agentes externos de terceiros acessem nativamente as habilidades e os dados especializados de um agente do Agentforce. Essa configuração trata o Agentforce como um "especialista" de alto valor que pode ser convocado por sistemas externos para executar ações específicas da Salesforce. Ao expor recursos do Agentforce por meio de um endpoint de API seguro, as plataformas externas podem delegar tarefas à Salesforce sem que o usuário saia do aplicativo de terceiros.

Estrutura de decisão: Use o A2A de entrada quando sua interface de IA principal estiver em um sistema de terceiros (como um portal personalizado ou bot externo), mas precisar executar fluxos de trabalho complexos dentro da Salesforce.

• Prós: Capacita aplicativos externos com dados e automação da Salesforce em tempo real, sem duplicar a lógica.
• Contras: Exige que o sistema externo lide com a orquestração e a lógica de "transferência" para garantir uma experiência fluida do usuário.

O servidor MCP hospedado da Salesforce permite expor recursos do Agentforce a hosts externos, como agentes de terceiros, copilotos e plataformas de LLM, por meio de uma interface MCP padronizada. Isso permite que as plataformas externas invoquem o Agentforce como um provedor de ferramentas, enquanto o Agentforce continua encapsulando ações corporativas, lógica de negócios e orquestração nos bastidores para tarefas complexas e especializadas.

Estrutura de decisão: Use agentes do Agentforce como um servidor MCP quando uma plataforma externa precisar consumir o Agentforce como um provedor de ferramentas. Isso é especialmente útil em dois cenários:

• Interoperabilidade de agentes corporativos: Quando um agente corporativo de terceiros, como o Microsoft Copilot, precisa invocar um agente do Agentforce porque o Agentforce contém as ações corporativas necessárias para concluir a tarefa.
• LLM externo/distribuição de canais: Quando você deseja que os recursos de marca do Agentforce estejam acessíveis em superfícies conversacionais externas, como ChatGPT, Gemini ou hosts semelhantes.

Nesse modelo, a plataforma externa continua sendo a experiência principal do host, enquanto o Agentforce é intencionalmente exposta por meio do MCP como um endpoint de ferramenta. Mesmo que o Agentforce seja agêntico internamente, o padrão de interoperabilidade ainda é MCP porque o relacionamento externo é uma invocação de ferramenta, e não uma delegação entre agentes.

• Prós: Facilita o uso de agentes poderosos e especializados do Agentforce, criados para sua empresa com base em dados da Salesforce (faturamento, suporte etc.), fora da Salesforce por meio de um protocolo padronizado; permite que assistentes externos e agentes corporativos usem a orquestração e as ações de negócios do Agentforce sem precisar recriá-las; oferece suporte à interoperabilidade corporativa e à distribuição de canais externos.
• Contras: O host externo controla a experiência principal do usuário e o ciclo de raciocínio, portanto, o Agentforce tem menos controle sobre como e quando é invocado. Os cenários corporativos também exigem um tratamento robusto de autenticação, autorização, propagação de identidade e passagem de contexto.

A visão geral acima é apenas o começo, ajudando você a identificar qual padrão de orquestração se adapta ao seu caso de uso. Continue lendo para ver como projetar e disponibilizar.

Veja o que você aprenderá ao baixar a Parte 2: O guia de referência sobre orquestração multiagente para arquitetos:

• Decomponha processos complexos em agentes que mantêm a responsabilidade. Três estratégias — por experiência de domínio, por estágio do fluxo de trabalho ou por capacidade — transformam um agente inchado em um conjunto de especialistas, cada um responsável por uma tarefa específica.
• Associe sua arquitetura a um dos cinco padrões de orquestração. O Modo supervisionado e o Modo de encaminhamento já estão disponíveis. A execução paralela, os agentes em segundo plano orientados por eventos e Planejar e apresentar estão previstos para lançamento.
• Escolha entre roteamento orientado por LLM e roteamento determinístico. O mecanismo de raciocínio se adapta a solicitações abertas. O Agent Script oferece controle determinístico quando um fluxo de trabalho exige uma sequência predefinida. A maioria dos projetos multiagentes usa os dois.
• Evite os sete antipadrões mais comuns. A orquestração em malha, a sobreposição de subagentes e o excesso de camadas de delegação são as maneiras mais rápidas de comprometer a governança e a observabilidade em grande escala.
• Projete de acordo com o que é compatível hoje. As restrições atuais do Agent Script (transferência fixa, delegação aninhada, limite de sete subagentes conectados) determinam quais padrões você pode implementar agora e quais deve planejar para o próximo trimestre.