Guía del arquitecto sobre la interoperabilidad de Agentforce

Escrita por: El equipo de productos de Agentforce (Pragya Anand , Moe Basi , Shiv Ramanna y Kyle Bransky ).

Siga leyendo para obtener más información sobre cómo definir su enfoque de interoperabilidad.
Después, descargue la parte 2 como guía de referencia para crear.

Antes de diseñar sistemas multiagente, es importante entender cómo funciona un solo agente. Un agente de Agentforce se compone de subagentes (anteriormente conocidos como "temas"), elementos modulares orientados a dominios específicos, cada uno con acciones determinadas (por ejemplo, Flow, Apex, solicitudes, etc.).

Cada agente de Agentforce ejecuta su propio bucle de razonamiento de LLM, orquestando cómo se delegan las tareas en los subagentes y cómo se generan las respuestas hasta que se logre el objetivo. El motor de razonamiento de Agentforce amplía este bucle con el determinismo basado en el guionado de agente, añadiendo transiciones y secuencias explícitas entre subagentes, lo que garantiza un comportamiento predecible y controlable en lugar de depender únicamente de las decisiones de LLM. Esta combinación de razonamiento de LLM y guionado determinista es lo que permite ejecutar los flujos de trabajo empresariales. Un solo agente puede encargarse de numerosas tareas, pero a medida que aumenta la complejidad, se topa con los siguientes obstáculos:

• Límites de los datos: No se puede acceder a los datos, flujos de trabajo y permisos que se alojan en diferentes organizaciones o sistemas de Salesforce. Se trata de un muro arquitectónico que no se puede cruzar con el diseño de un solo agente.
• Sobrecarga de contexto: El contexto del motor de razonamiento LLM está repleto de instrucciones, resultados de acciones e historial de conversaciones, por lo que empieza a ignorar las reglas básicas o a mezclar temas.
• Colapso de la especialización de dominios: Un agente que intenta ser un experto en todo aplica la lógica incorrecta para invocar subagentes específicos. Cuanto más grande sea el bloque de instrucciones, peor será la precisión.

Marco de decisiones: Utilice agentes individuales cuando su proceso empresarial sea relativamente sencillo, opere dentro de un único dominio y requiera un conjunto unificado de acceso a los datos en todos sus subagentes.

La orquestación SOMA (multiagente en una única organización) permite que varios agentes especializados de Agentforce trabajen conjuntamente de forma fluida dentro de una única organización de Salesforce. En lugar de obligar a los usuarios a gestionar conversaciones con distintos agentes por separado, SOMA ofrece un único agente conversacional como punto de entrada. Entre bastidores, un agente "supervisor" u "orquestador" coordina y delega las tareas de forma inteligente a los agentes especializados, lo que garantiza que cada tarea sea atendida por el agente más adecuado para realizarla.

Marco de decisión: Utilice SOMA cuando sus clientes necesiten una experiencia unificada de punto de entrada para agentes especializados que operan dentro de un único entorno de Salesforce (organización).

• Ventajas: Simplifica la experiencia del usuario al proporcionar un único punto de entrada conversacional para varios agentes especializados.
• Inconvenientes: Está limitado a los datos y procesos disponibles dentro de una única organización de Salesforce.

La orquestación MOMA (multiagente entre varias organizaciones), como evolución natural del modelo de organización única (SOMA), permite que varias organizaciones de Salesforce ofrezcan una experiencia unificada de agentes sin necesidad de una consolidación compleja de datos. Esta arquitectura se basa en una filosofía de delegación intencionada en lugar de una red abierta, y aplica una restricción deliberada de un único nivel de profundidad (Agente A > Agente B, no Agente A > B > C) para evitar encadenamientos impredecibles. La seguridad se garantiza mediante una ejecución basada en la identidad del usuario y el funcionamiento dentro del límite de confianza de Data 360 One (DC1).

Marco de decisión: Utilice MOMA cuando su red nativa de Agentforce necesite delegar tareas de forma segura entre diferentes organizaciones de Salesforce sin consolidar los modelos de datos.

• Ventajas: Ofrece una experiencia unificada de los agentes en entornos empresariales complejos, al tiempo que mantiene estrictos requisitos de residencia de datos.
• Inconvenientes: La asignación de identidades de usuario entre varias organizaciones y el intercambio de contexto entre ellas pueden resultar complejos.

El cliente de protocolo de contexto del modelo (MCP) permite a los administradores de Agentforce registrar servidores MCP externos para que los desarrolladores puedan integrar herramientas, recursos y acciones remotos en Agentforce de forma estandarizada. Esto permite que Agentforce consuma capacidades externas mediante un contrato de herramientas, en lugar de depender de integraciones personalizadas punto a punto.

Marco de decisión: Utilice el Cliente MCP cuando Agentforce deba seguir siendo el principal orquestador y simplemente necesite acceso a capacidades externas como herramientas. Por ejemplo, para obtener datos de un sistema externo, invocar un flujo de trabajo, buscar información en una fuente de conocimiento o ejecutar acciones a través de una plataforma de terceros.

Utilice el cliente MCP cuándo Agentforce deba consumir una capacidad externa como una herramienta.

• Ventajas: Convierte los servicios externos en herramientas seguras y gobernables para Agentforce sin necesidad de código personalizado. Además, incorpora funciones de seguridad como comprobaciones de integridad semántica (protección contra cambios maliciosos en herramientas) y evaluación de riesgos para evitar la manipulación de herramientas. De este modo, el proceso de razonamiento permanece centrado en Agentforce, al tiempo que se amplían sus capacidades (Agentforce).
• Inconvenientes: La abstracción está diseñada deliberadamente en torno al concepto de herramienta. Si la capacidad remota se modela mejor como un agente especializado que deba asumir parte del razonamiento o del flujo de trabajo, forzar su integración mediante MCP puede resultar poco natural. Además, dado que el esquema lo define el servidor externo, los cambios en el contrato pueden provocar fallos en la integración hasta que esta se actualice o se registre de nuevo.

Agentforce A2A de salida es la forma nativa en que los agentes de Agentforce colaboran directamente con un agente externo. Para habilitar esta funcionalidad, los administradores deben registrar primero el agente externo, especificando sus habilidades, capacidades y protocolos de transporte. Una vez registrado y conectado a un agente de Agentforce, estará disponible en tiempo de ejecución para permitir una delegación de tareas segura entre plataformas.

Marco de decisión: Utilice Agentforce A2A cuando su red nativa de Agentforce necesite interactuar de forma segura con agentes externos de proveedores, como Google o Box. Nota: En este escenario, un agente debe delegar trabajo a otro agente que se encarga de parte del razonamiento, la planificación o la ejecución.

• Ventajas: Al estar integrado directamente en Agentforce, no es necesario adquirir herramientas externas de orquestación para gestionar estos flujos de trabajo multiagente. Permite ofrecer a los usuarios un ecosistema de IA con una experiencia de marca unificada y aprovechar la experiencia especializada de plataformas externas.
• Inconvenientes: Confiar en agentes de terceros y garantizar la privacidad de los datos entre distintos sistemas puede resultar complejo. Además, requiere el registro manual de las capacidades del agente externo y la compatibilidad de los estándares de autenticación entre las plataformas.

Utilice esta regla sencilla: La diferencia clave no radica en si existe IA en ambos extremos. Lo importante es cómo se modela la capacidad remota:

• Si se modela como una herramienta, utilice MCP.
• Si se modela como un agente colaborador, utilice A2A.

A2A para la delegación de tareas permite que agentes externos de terceros utilicen de forma nativa las capacidades especializadas y los datos de un agente de Agentforce. En esta configuración, Agentforce actúa como un "experto" de gran valor al que los sistemas externos pueden recurrir para ejecutar acciones específicas de Salesforce. Al exponer las capacidades de Agentforce a través de un punto final de API seguro, las plataformas externas pueden delegar tareas en Salesforce sin que el usuario tenga que abandonar su aplicación de terceros.

Marco de decisión: Utilice A2A para la delegación de tareas a Agentforce cuando su interfaz principal de IA se encuentre en un sistema de terceros (como un portal personalizado o un bot externo), pero necesite ejecutar flujos de trabajo complejos dentro de Salesforce.

• Ventajas: Permite que las aplicaciones externas aprovechen datos y capacidades de automatización de Salesforce en tiempo real sin necesidad de duplicar la lógica de negocio.
• Inconvenientes: Requiere que el sistema externo gestione la orquestación y la lógica de transferencia entre sistemas para garantizar una experiencia de usuario fluida.

El servidor MCP alojado de Salesforce permite exponer las capacidades de Agentforcea hosts externos, como agentes de terceros, copilotos y plataformas de LLM, mediante una interfaz MCP estandarizada. Esto permite que las plataformas externas utilicen Agentforce como proveedor de herramientas, mientras Agentforce sigue ejecutando en segundo plano las acciones empresariales, la lógica de negocio y la orquestación necesarias para tareas complejas y especializadas.

Marco de decisión: Utilice los agentes de Agentforce como servidor MCP cuando una plataforma externa deba usar Agentforce como proveedor de herramientas. Esto resulta especialmente útil en dos escenarios:

• Interoperabilidad entre agentes empresariales: Cuando un agente empresarial de terceros, como Microsoft Copilot, necesita recurrir a un agente de Agentforce porque Agentforce contiene las acciones empresariales necesarias para completar una tarea.
• Distribución a LLM y canales externos: Cuando desea que las capacidades de Agentforce de su marca estén disponibles en entornos conversacionales externos, como ChatGPT, Gemini u otros hosts similares.

En este modelo, la plataforma externa sigue siendo el entorno principal de interacción para el usuario, mientras que Agentforce se expone deliberadamente mediante MCP como punto final de acceso a la herramienta. Aunque Agentforce utilice capacidades agénticas internamente, el patrón de interoperabilidad sigue siendo MCP, ya que la relación externa se basa en la utilización de herramientas y no en la delegación entre agentes equivalentes.

• Ventajas: Facilita la reutilización fuera de Salesforce, mediante un protocolo estandarizado, de agentes de Agentforce potentes y especializados basados en datos de Salesforce para distintos ámbitos empresariales, como facturación o soporte. Además, permite que asistentes externos y agentes empresariales aprovechen la orquestación y las acciones de negocio de Agentforce sin necesidad de volver a desarrollarlas, y admite tanto la interoperabilidad empresarial como la distribución a canales externos.
• Inconvenientes: El host externo controla la experiencia principal de usuario y el ciclo de razonamiento, por lo que Agentforce tiene menos capacidad de decisión sobre cómo y cuándo se utiliza. Además, los escenarios empresariales requieren una gestión sólida de la autenticación, la autorización, la propagación de identidades y el intercambio de contexto.

La descripción anterior es solo el punto de partida y le ayudará a identificar qué patrón de orquestación se ajusta mejor a sus circunstancias. Continúe leyendo para descubrir cómo diseñar e implementar su caso de uso.

Esto es lo que aprenderá al descargar la Parte 2: Guía de referencia de orquestación multiagente para arquitectos:

• Descomponer procesos complejos en agentes con responsabilidades claramente definidas. Tres estrategias, basadas en la especialización por dominio, la etapa del flujo de trabajo o la capacidad, permiten transformar un único agente sobredimensionado en un conjunto de especialistas que desempeñan eficazmente funciones concretas.
• Adaptar su arquitectura a uno de los cinco patrones de orquestación. Los modos de supervisión y transferencia ya están disponibles de forma general. La ejecución paralela, los agentes secundarios basados en eventos, la planificación y el presente están en la hoja de ruta.
• Elegir entre enrutamiento basado en LLM y determinista. El motor de razonamiento se adapta a las solicitudes abiertas. El guionado de agente ofrece un control determinista cuando un flujo de trabajo requiere una secuencia de pasos garantizada. La mayoría de las arquitecturas multiagente combinan ambos enfoques.
• Evitar los siete antipatrones más habituales. La orquestación en malla, los subagentes con responsabilidades superpuestas y un número excesivo de niveles de delegación son algunas de las formas más rápidas de comprometer la gobernanza y la observabilidad a gran escala.
• Diseñar teniendo en cuenta las capacidades disponibles actualmente. Las restricciones actuales del guionado de agente (transferencia persistente, delegación anidada y límite de siete subagentes conectados) condicionan qué patrones puede implementar ahora y cuáles conviene planificar para próximas fases.