Orquestación multiagente multiproveedor: coordinar agentes entre frameworks

La orquestación multiproveedor de agentes es la coordinación de agentes de IA de distintos frameworks y proveedores mediante un protocolo común y abierto. Con Agent-to-Agent (A2A), por ejemplo, un orquestador LangGraph dirige agentes de CrewAI y AutoGen sin exponer sus prompts, modelos ni memoria internos. El objetivo es la interoperabilidad sin vendor lock-in: agentes que viven en entornos separados colaboran en una tarea común.

• ¿Quién coordina a quién? Un agente orquestador llama a agentes pares a través de A2A. La lógica interna de los agentes llamados permanece opaca de forma deliberada.
• ¿Qué protocolo para qué? MCP para agente a herramienta, A2A para agente a agente. En 2026, este es el stack convergente de la industria.
• ¿Qué aporta? Ningún lock-in con un único proveedor, ya que los agentes se vuelven intercambiables gracias a AgentCards portables y ningún entorno tiene que exponer a los demás.

Por qué coordinar varios frameworks en lugar de un monolito

En la realidad de las empresas europeas nadie parte de cero. El agente de CRM vive en Salesforce, el agente de ERP en SAP, el agente de productividad en Microsoft y un paso de razonamiento especializado quizá directamente en el Anthropic Claude Agent SDK. Nadie reconstruye todo eso en un único framework. La orquestación multiproveedor acepta esta heterogeneidad como lo normal y coloca encima un lenguaje común.

La clave conceptual de A2A: el protocolo define cómo hablan los agentes, no cómo piensan. Un agente de Salesforce puede llamar a un agente de SAP sin que ninguno de los dos revele sus prompts, su memoria o su modelo. Este encapsulamiento es justo la condición para que un orquestador LangGraph pueda dirigir un agente de CrewAI o de AutoGen sin conocer su funcionamiento interno.

Arquitectura: el stack de protocolos convergente en 2026

Tras doce meses de reorganización pública, el stack está claro. Anthropic aportó MCP el 9 de diciembre de 2025 a la Agentic AI Foundation, dentro de la Linux Foundation; Google donó A2A a la Linux Foundation el 23 de junio de 2025, con AWS, Cisco, Google, Microsoft, Salesforce, SAP y ServiceNow como miembros fundadores. El ACP de IBM se integró en A2A en agosto de 2025.

La valoración honesta: MCP más A2A es el stack convergente. AGNTCY es el complemento racional cuando de verdad se necesitan identidad y observabilidad entre proveedores. NANDA va a la lista de seguimiento, no a la ruta crítica de un programa de 2026.

Los componentes técnicos clave de A2A

• Transporte: JSON-RPC 2.0 sobre HTTPS, streaming mediante Server-Sent Events y notificaciones push opcionales para tareas largas.
• AgentCard: un documento JSON por agente con endpoint, capacidades, skills compatibles, modalidades y esquemas de autenticación. Es el contrato entre sistemas por excelencia.
• Ciclo de vida de las tareas: submitted -> working -> input-required -> completed | failed | canceled. El resultado de una tarea son uno o varios artefactos.
• Tres modos de interacción: síncrono, polling asíncrono y streaming/push para tareas de larga duración.

Ventajas de la interoperabilidad y sus límites

La principal ventaja no es una promesa de marketing, sino estructural: quien conecta agentes mediante AgentCards portables puede sustituir un agente especializado flojo por uno mejor sin rehacer el orquestador. Para una agencia, eso significa que los agentes construidos una vez se pueden llamar desde cualquier entorno de cliente.

Los límites son igual de reales y deben formar parte de toda decisión de arquitectura:

• Límites de confianza: cada par A2A es opaco para los demás. Eso es bueno para la confidencialidad, pero malo para la auditoría de caja blanca. Las trazas entre proveedores son difíciles.
• Amplificación de la inyección de prompts: cada nueva ventana de contexto de un subagente es una nueva superficie de ataque. La clase EchoLeak (CVE-2025-32711, Aim Labs, Microsoft 365 Copilot, junio de 2025) escala linealmente con el número de agentes que ingieren contenido no fiable.
• Vendor lock-in por la puerta de atrás: las extensiones propietarias de A2A en la AgentCard o en la semántica de las tareas socavan justo la portabilidad que da sentido al protocolo. La señal que hay que vigilar en 2026: ¿seguirá siendo la AgentCard un documento JSON portable?
• Madurez: en 2026, el hub-and-spoke con A2A todavía está en fase de productización y no es un estándar maduro. AGNTCY y NANDA aún no son apuestas para producción.

Escenario práctico: LangGraph orquesta cuatro agentes más allá de las fronteras entre proveedores

Un flujo transversal concreto de un gran grupo empresarial que conecta ventas, servicio y finanzas. El orquestador es LangGraph (v1.0, disponibilidad general el 22 de octubre de 2025, licencia MIT); los agentes especializados internos usan cada uno su propio framework y se llaman a través de A2A. Para que un orquestador externo como LangGraph pueda llamar a un agente de Joule por A2A, SAP está ampliando Joule con A2A bidireccional. Según SAP, estará disponible de forma general en el Q4 2026 (situación: octubre de 2026, SAP Sapphire 2026 Innovation News Guide).

```text
Orquestador LangGraph (durable state, checkpointing)
|
|-- tarea A2A --> agente Agentforce 360 (datos CRM, Atlas Reasoning, sin A2A interno)
|-- tarea A2A --> agente CrewAI Enrichment (enriquecimiento de leads, proceso propio)
|-- tarea A2A --> agente AutoGen Review (critic-generator, control de calidad)
|-- tarea A2A --> agente SAP Joule (contabilización financiera tras aprobación, A2A bidireccional anunciado para Q4 2026)
|
|-- MCP --> ABAP / S4HANA / Integration Suite (herramientas)

Ruta de escritura: single-threaded. Solo el nodo LangGraph autoriza las escrituras; la contabilización se hace a través de la tarea de Joule.
Cada salto A2A lleva el mismo trace ID (auditoría + RGPD).
```

Lo importante es la disciplina de escritura. En abril de 2026, Cognition concretó la forma eficaz: varios agentes aportan inteligencia, pero las escrituras siguen siendo single-threaded. El fan-out con predominio de lectura (enriquecimiento, recuperación, revisión) es robusto; la escritura en paralelo sobre un estado compartido es frágil. En el escenario, tres agentes recopilan y revisan, y solo se escribe en un punto: a través de la tarea de Joule que autoriza el orquestador. Para situar los costes: el patrón orquestador-trabajador en el que se basa Claude Research obtuvo en la evaluación interna de investigación un resultado un 90,2 % mejor que un único agente Claude Opus 4, pero consumió unas 15 veces más tokens que una interacción de chat normal (Anthropic, 13 de junio de 2025). Este consumo adicional solo compensa en tareas de alto valor y paralelizables, no de forma generalizada.

Obligaciones del RGPD y reglas prácticas en flujos multiproveedor

En cuanto los agentes se ejecutan en distintos proveedores de computación, el flujo de datos cruza en cada tarea varias fronteras de residencia de datos y de encargados del tratamiento.

• Cadena de contratos de encargo (art. 28 RGPD): cada proveedor de agentes es potencialmente un encargado del tratamiento. El enfoque multiagente alarga la cadena; cada salto A2A es potencialmente una relación de encargo propia.
• Transferencias internacionales (arts. 44-49): para cada salto de agente hacia un tercer país que se base en cláusulas contractuales tipo (art. 46), necesitas una evaluación de impacto de la transferencia (TIA) propia. En ella compruebas si la legislación o la práctica de las autoridades del país de destino menoscaban la eficacia de las cláusulas (Recomendaciones 01/2020 del CEPD). Si el salto va a un proveedor estadounidense certificado en el marco del EU-US Data Privacy Framework, la transferencia se ampara en la decisión de adecuación de la Comisión según el art. 45 RGPD (Decisión de Ejecución (UE) 2023/1795). Mientras esa decisión esté vigente, no hace falta la TIA.
• Registro de auditoría: traza de extremo a extremo de cada llamada a un agente, versiones de los modelos fijadas, registro de todos los prompts de los subagentes y de las AgentCards utilizadas, y correlación mediante un único trace ID. La ley no exige el trace ID. Pero muestra qué agente trató qué datos y cuándo, y así facilita acreditar el cumplimiento según el art. 5, apartado 2, del RGPD. El patrón de Allianz Project Nemo, con un agente de auditoría dedicado, es aquí el modelo de referencia relevante en Europa.
• Coherencia lingüística: un agente que tutea con Du y llama a otro que usa el tratamiento formal Sie parece roto a ojos del cliente. El tono de voz debe imponerse en la AgentCard y en las plantillas de prompts.

Para agencias y B2B

Para las agencias europeas, la mayor palanca de estrategia de producto en 2026 es publicar una AgentCard para cada agente productizado. Así, los entornos de los clientes llaman a tus agentes directamente desde Agentforce, Joule o Copilot Studio, sin integración a medida. Sin AgentCard, tu agente queda permanentemente detrás de una interfaz personalizada. Para los responsables de decisiones B2B, la pregunta de compras es concreta: ¿garantiza el contrato de Agentforce, Joule o Copilot Studio la interoperabilidad A2A y el cumplimiento del estándar MCP, y qué pasa en caso de salida? La arquitectura por defecto racional para pymes es n8n o LangGraph para la orquestación, MCP para las herramientas y A2A para cada handshake entre plataformas. Blck Alpaca acompaña estas decisiones de forma práctica: desde la revisión de la selección de patrones hasta una arquitectura de auditoría apta para entornos soberanos, pasando por estrategias de AgentCard gobernadas.