Bienvenidos a otra píldora de conocimiento. Imaginen que dirigen una empresa y contratan a un equipo de especialistas brillantes, un planificador de viajes de clase mundial, un experto en integración mundial, un experto en integración de empleados y un técnico de soporte informático. Pero ninguno de ellos se habla entre sí. Cada vez que una tarea requiere a dos de ellos, tienen que ir de un escritorio a otro y llevar la información a ustedes mismos. Así es exactamente como funcionan la mayoría de los agentes de área. Operan de forma aislada, incluso cuando el problema claramente requiere trabajo en equipo. Así que hoy hablaremos sobre cómo los agentes pueden comunicarse, delegar trabajo y actuar como verdaderos equipos. Hoy Mirko Pitta. Esto no es un concepto futurista. La orquestación multiagente ya está ocurriendo y funciona mediante un protocolo llamado ADOSA. Empezaremos con el problema.

Analizaremos ese protocolo paso a paso y veremos cómo Microsoft lo utiliza dentro de Copilot Studio y Azure AI. Tomen su café y comencemos. ¿Cuál es el problema real? Sus agentes de área actuales son exactamente como sus especialistas aislados. Cada uno tiene su propio conocimiento, herramientas y objetivos. Un agente meteorológico conoce el problema. Un agente de hoteles conoce la disponibilidad de habitaciones, pero no comparten nada. Ahora imaginen a un usuario pidiendo un viaje a Seattle la próxima semana con un hotel cerca de la oficina. Un solo agente tendría que ser experto en clima, en viajes y en negocios locales al mismo tiempo. Eso significa prompts gigantes y saturados que comprimen cada capacidad posible en un sistema y esos prompts se rompen constantemente. La vieja solución es el código personalizado. Escribirías un puente entre el agente del clima y el del hotel, luego otro entre el del hotel y el de vuelos y otro para el calendario.

Funciona al principio, pero cada vez que agregas un nuevo agente construyes otra integración. Muy pronto tienes una pesadilla de espagueti de conexiones punto a punto donde un solo cambio lo rompe todo. Las ganancias de productividad que tu día a entregar son consumidas por el trabajo de mantenimiento. Analiza un empresario. Tu organización ya tiene proceso con traspaso de tareas. Se crea un ticket, alguien lo clasifica, alguien lo resuelve, alguien lo registra y cada paso es un traspaso. En el viejo mundo automatizas cada paso con un agente separado y luego pasas semanas conectándolos. ¿Pero qué pasaría si hubiera un protocolo que permitiera a los agentes descubrirse y cooperar sin puentes personalizados? Eso es exactamente lo que hace ADOSA. En palabras sencillas, ADOSA es una forma estándar para que los agentes hablen entre sí, se pasen de trabajo y logren resultados en equipo. ¿Qué es ADOSA?

La definición simple. ADOSA significa agente, agent to agent. Es un protocolo abierto que permite a los agentes de A comunicarse directamente entre sí, sin importar quién los haya creado. Puedes pensar en él como el HTTP para los agentes. HTTP es el lenguaje que usan los navegadores y servidores web para comunicarse, hace lo mismo para los agentes. Un agente creado por tu equipo de TI en Microsoft Copilot Studio puede hablar con un agente de otra empresa en Google Cloud siempre que ambos hablen ADOSA. Tampoco es un proyecto pequeño. ADOSA está patrocinado por ocho grandes empresas, incluyendo Google, Microsoft, Cisco, Salesforce, SAP y otras, y está alojado por la Linux Foundation. La versión 1.0 es estable y está lista para su uso real, lo que significa que ningún proveedor controla el protocolo. No es algo de Google ni de Microsoft, es algo de la industria. Diseño es deliberadamente sencillo.

ADOSA se basa en estándares web existentes como HTTP y JSON de RPC, cosas que todo desarrollador ya conoce. No hay nada exótico ni propietario. Eso facilita que las empresas lo adopten sin tener que reemplazar su infraestructura actual. Quizás hayas oído hablar de otro protocolo llamado MSP, o protocolo de contexto de modelo. Esta es la diferencia. MSP es de agente herramienta, lo que significa que conecta un agente a fuentes de datos externas y APIs. A2A es de agente a agente conectando a los agentes directamente entre sí. No son competidores, son complementarios. Piensa en MSP como la conexión vertical desde un agente hacia sus herramientas. Y en A2A como la conexión horizontal entre agentes. Una elección de diseño más. A2A trata a los agentes como pan. Por lo tanto, cuando un agente habla con otro, no ve razonamiento interno, las herramientas ni los datos privados del otro agente. Solo ve la tarea que envió y el resultado que recibe.

Eso perciera la privacidad intelectual. Un agente meteorológico no necesita saber cómo el agente de un hotel reserva habitaciones. Solo necesita entregar el pronóstico. Ahora veamos la primera pieza del rompecabezas. La tarjeta de la agente. La tarjeta de la agente del currículo. Cada agente compatible con A2A publica algo llamado tarjeta de agente. Esa tarjeta es un documento elegible por máquina que reside una URL estándar en el dominio del agente, específicamente en la ruta Well-Know Agent Card, JSON. Si sabes dónde vive un agente, puedes obtener su tarjeta y aprender todo lo necesario para trabajar con él. Piensa en la tarjeta de la agente como un currículo o una tarjeta de presentación. Le dice a otros agentes quién eres y qué puedes hacer. La tarjeta contiene nombre del agente, una descripción en texto simple de sus capacidades y etiquetas de habilidades que ayudan con el descubrimiento.

También enumera la URL del punto de enlace donde acepta solicitudes, sus requisitos de autenticación y los formatos de entrada y salida que acepta. Aquí hay un ejemplo concreto. Digamos que tienes un agente especialista en clima. Su tarjeta de agente dice puede proporcionar el clima actual y un pronóstico de 5 días para cualquier ciudad. Enumera sus puntos de enlace de API ya que acepta el nombre de una ciudad y devuelve la temperatura y las condiciones en formato JSON. Eso es todo. Es solo una declaración clara de lo que puede hacer sin secretos ni lógica interna expuesta. Descubrimiento funciona así. Un agente orquestador tiene una lista de URLs de agentes conocidos o puedes configurarlo con ellas. Cuando llega una tarea, el orquestador obtiene las tarjetas de los agentes, lee las descripciones y decide qué agente es la mejor opción. La tarjeta del clima dice clima, así que las tareas de clima van allí.

La tarjeta de hoteles dice hoteles, así que las tareas de hoteles van allí. Nótese que no se requiere un registro central. Sus agentes no necesitan registrarse en un directorio global. Simplemente publican su tarjeta en una ubicación conocida y cualquier otro agente que conozca la URL puede encontrarlos. Esa es una decisión de diseño deliberada que mantiene el sistema descentralizado y flexible. Puedes añadir un nuevo especialista a tu red dándole al orquestador su URL y el descubrimiento ocurre automáticamente. Entonces el orquestador sabe quién está disponible. ¿Pero cómo se transfiere en el trabajo realmente? ¿Cómo funciona la comunicación a dos? Entonces el orquestador sabe que agentes están disponibles a través de la tarjeta de agente. ¿Pero cómo se transfieren en el trabajo estos agentes realmente entre sí? La respuesta es en sí. Toda la comunicación ocurre mediante HTTP usando mensajes JSON-RPC, el mismo protocolo que impulsa la mayoría de los servicios web actuales.

Nada personalizado ni complicado, solo tráfico web estándar fluyendo entre dos agentes. Aquí está el punto. No todas las tareas son iguales. Admite a tres patrones de interacción diferentes dependiendo de lo que necesites. La respuesta instantánea maneja búsquedas rápidas donde el agente remoto puede responder de inmediato. Envías una solicitud, responde de inmediato y listo. Preguntarle a un agente climático por el pronóstico de hoy funciona exactamente así. Respuesta síncrona, entra y sale, y sale. El streaming maneja es más larga. Tal vez el agente especialista necesite buscar en múltiples bases de datos o ejecutar un análisis complejo. En lugar de hacerte esperar por una sola respuesta, el agente envía actualizaciones de estado mientras trabaja usando eventos enviados por el servidor. Obtienes informes de progreso a lo largo del camino y luego el resultado final llega al final. Rastrear la entrega de un paquete funciona de manera.

Ves cada paso a medida que sucede. La notificación asíncrona maneja las tareas de larga duración donde el agente remoto puede tardar minutos, horas o incluso días. La incorporación de empleados es un buen ejemplo. Un especialista provisiona cuentas de IT, mientras otro gestiona la inscripción a beneficio durante varios días. El agente cliente envía una solicitud, recibe un ID de tarea y continúa con su trabajo. Más tarde, el agente remoto envía el resultado a través de un webhook. El cliente también puede verificar el progreso en cualquier momento consultando ese ID de tarea. Toda interacción sigue la misma estructura, organizada como una tarea. Cuando el cliente envía una solicitud, el agente remoto crea una tarea y devuelve un ID de tarea. Ese ID se convierte en un identificador de seguimiento para todo lo que sigue. Los mensajes dentro de esa tarea tienen un rol que indica quién lo envió.

Y partes que pueden ser texto simple, datos binarios como imágenes o documentos, cargas útiles, JSON o URLs que apuntan archivos almacenados en otros lugares. La autenticación sigue las convenciones web estándar, OAO, claves de API, tokens de portador. Los sospechosos habituales nada nuevo que aprender. La tarjeta de la agente le indica al cliente qué método de autenticación usar. Y el cliente lo maneja igual que lo haría para cualquier otra llamada API. Si es como se ve esto en la práctica, digamos que el orquestador necesita datos meteorológicos para un viaje. Envía una tarea al especialista en clima. El especialista en clima reconoce la solicitud, comienza a procesar y transmite actualizaciones de progreso, obteniendo datos, analizando el resultado. Luego envía el pronóstico final. El orquestador nunca ve las herramientas internas del agente meteorológico, sus claves API o su proceso de razonamiento.

Solo ve el resultado. Ese es el principio de diseño clave. Límites limpios entre agentes y sin fugas de estado interno, interno. Pero la comunicación a dos a por sí siente. Necesitas un jefe inteligente para coordinar a todos los especialistas. Eso nos lleva al patrón de orquestador especialista. El patrón de orquestador especialista. Aquí es donde todo se conecta. El patrón de orquestador especialista es la arquitectura más común en los sistemas multiagente en producción hoy en día. Piénsalo como una empresa con departamentos, ITR, LHH, finanzas, cada uno manejando su propia área. Tienes un tomador de decisiones central que dirige el trabajo a equipos especializados y cada equipo se enfoca en lo que mejor hace. El orquestador tiene la visión general. Recibe la solicitud del usuario, determina qué debe suceder y decide qué especialista puede manejar cada pieza. Si un usuario pide, planea un viaje a Sierra la próxima semana.

El orquestador no reserva vuelos ni busca hoteles por sí mismo. Sabe que hay un especialista en vuelos, un especialista en hoteles y un especialista en clima. Divide la solicitud en esas piezas y delega cada una. Cada especialista tiene un enfoque limitado. Un agente maneja la reserva de vuelos, otro la búsqueda de hoteles y un tercero la clasificación de incidentes. No necesitan saber nada sobre los dominios de los otros. El especialista en vuelos conoce aerolíneas, rutas y precio. No necesita saber nada sobre tipos de habitaciones de hotel o políticas de cancelación. Ese enfoque limitado mantiene a cada agente simple, fácil de mantener y fácil de probar. Aquí está la parte importante. El orquestador no ejecuta las tareas. Enruta el trabajo y combina los resultados. Ese es su único trabajo. El rol del orquestador es ser un despachador inteligente, no un superagente que intenta hacerlo todo.

Cuando dejas que el orquestador empiece a hacer el trabajo de un especialista, pierdes todo el beneficio del patrón. Te convierte de nuevo en un desastre monoid. Cuidado con un error común. Algunos equipos crean dominios de especialistas que se superponen. Dos agentes afirman que pueden manejar soporte al cliente o búsqueda de datos, lo que crea confusión en el enrutamiento. El orquestador no sabe cuál elegir y los usuarios obtienen resultados inconsistentes. La solución es sencilla. Cada especialista posee un dominio claramente delimitado sin superposición. Si dos agentes pueden hacer lo mismo, fusionarlos o dividir el dominio de forma más limpia. Copilot Studio de Microsoft utiliza este patrón de forma nativa. Tu copilot principal actúa como orquestador, mientras que los agentes secundarios y conectados actúan como especialistas. Cuando un usuario pide algo que abarca varios dominios, el copilot principal delega a los especialistas correctos mediante AD2A.

Está integrado en la plataforma, por lo que no tienes que programar la lógica de orquestación desde cero. El gran beneficio aquí es la modularidad. Necesitas cambiar tu proveedor de reservas de datos. Reemplaza al especialista en hoteles sin tocar al orquestador ni a ningún otro agente. ¿Quieres añadir una nueva capacidad? Crea un nuevo especialista, registralo en el orquestador y listo. Cada agente permanece pequeño, manejable e independiente para desplegar. Ese es el objetivo principal de pasar de agentes monolíticos a un sistema multiagente. Entonces tenemos el protocolo de las tarjetas de agente. Veámoslo en acción con escenarios reales. Ejemplos reales de AD2A en acción. Entonces, ¿cómo se ve AD2A realmente en el mundo real? Comencemos con un ejemplo simple. Le dices a tu asistente de IA. Planifica un viaje a Ciudad la próxima semana. En la forma antigua de hacer las cosas, ese único asistente tendría que saberlo todo.

Clima, vuelos, hoteles, restaurantes, todo a la vez. Todo a la vez. Eso es mucho pedir para un surpro. Con AD2A el orquestador lo desglosa. Envía una tarea a un especialista en clima pidiendo el pronóstico para esos días específicos. Al mismo tiempo, le pide a un especialista en vuelos que busque vuelos que lleguen el martes por la mañana y regresen el jueves por la noche. Y a un especialista en hoteles que busque lugares cerca del centro deseado para tres noches. Cada especialista trabaja de forma independiente y no necesita hablar con los otros agentes porque cada uno tiene sus propias fuentes de datos, herramientas y experiencia. El orquestador recopila todos los resultados y los combina en una sola respuesta. El usuario ve una respuesta única. Aquí está el pronóstico. Estas son sus opciones de vuelo. Aquí tiene tres hoteles cerca de la oficina. Detrás de escena, tres agentes separados trabajaron juntos sin código de integración personalizado.

Ahora, un escenario empresarial. Supongamos que hay un ticket, mi computadora portada y no se conecte a la VPN. El orquestador determina que es un problema de red. Le entrega el ticket a un especialista en manuales de procedimientos que conoce los pasos. Comprobar el estado del cliente VPN, verificar las credenciales de red, reiniciar el servicio. Especialista de vuelos pasos. Luego, el orquestador pasa el resultado a un especialista en redacción de tickets que registra la solución en el sistema. Todo esto sucede en segundos sin intervención humana. Y el equipo de TI solo se involucra si los pasos automatizados no resuelven el problema. La incorporación de empleados es otro ejemplo, pero este toma días, no segundo. Un nuevo empleado se une en la empresa. El orquestador activa a un especialista de TI para crear cuentas y asignar hardware, lo que podría tomar algunas horas. Al mismo tiempo, activa un especialista en beneficios de red.

H. Para los formularios de inscripción. Y más tarde, a un especialista en instalaciones para el escritorio y el acceso con tarjeta. Cada especialista ejecuta su propia tarea de larga duración de forma independiente. Y el orquestador rastrea el progreso usando esos ideas de tarea de los que hablamos antes. Entonces, si el especialista de TI termina, el orquestador lo sabe. Y si el especialista en instalaciones se retrasa, puede realizar un seguimiento. El usuario ve un flujo de incorporación fluido. Pero detrás de escena, es un equipo coordinado trabajando durante varios días. Y esto no es solo teoría. Coca-Cola Beverages Africa ya está usando agentes de Copilot Studio con Dynamics 365 para automatizar los ciclos de planificación. Sus planificadores solían pasar hasta una hora y media cada día en tareas repetitivas. Con la orquestación de múltiples agentes, esos ciclos se ejecutan por sí solos.

El orquestador delea en especialistas que manejan diferentes partes del proceso de planificación de la cadena de suministro. El resultado es más de una hora ahorrada por persona al día, simplemente dejando que los agentes hablen entre sí en lugar de hacer que los humanos trasladen información entre sistemas. Tú, si el patrón es el mismo, todos tus ejemplos. Cada agente es un experto autónomo que conoce su propio dominio y tiene sus propias herramientas y no necesita saber nada sobre los otros agentes. A2A proporciona una capa de comunicación sencilla para que puedan cooperar sin código personalizado. Obtienes un protocolo estándar y un orquestador inteligente sin puentes, sin integraciones, punto a punto y sin dolores de cabeza de mantenimiento. Microsoft totalmente por esto. Veamos dónde encajan Copilot Studio y Azure AI. El ecosistema de Microsoft, Copilot Studio y Azure AI. ¿En dónde se sitúa Microsoft en todo esto?

Pues teniendo. Copilot Studio ahora admite A2A de forma nativa y ha estado disponible de manera general desde abril de 2026. No se trata de una versión preliminar. Está listo para producción y cualquier cliente elegible puede usarlo el mismo. Y está lo importante. Puedes conectar agentes externos a tu orquestador de Copilot Studio. Cuando digo externo, me refiero a verdaderamente externo. Agentes creados en Google Cloud, AWS o cualquier otra plataforma que admita el protocolo A2A. Al orquestador, no le importa dónde reside el agente o con qué marco de trabajo se haya construido. Mientras hable A2A, puede unirse al equipo. La configuración es simple. En Copilot Studio creas algo llamado agente conectado. Pegas la URL del punto de conexión del agente. Copilot Studio obtiene automáticamente la tarjeta del agente desde esa URL que es el conocido archivo JSON de tarjeta del agente del que hablamos.

Lee las capacidades del agente, los requisitos de autenticación y los formatos de entrada y salida. Luego, crea un conector personalizado en segundo plano y tu orquestador puede comenzar a delegar tareas de inmediato. No necesitas trabajo de integración manual ni código personalizado. Solo pega la URL y habrás terminado. En el lado de Azure, Azure AI Foundry Agent Service también admite A2A. Tiene un punto de conexión de API A2A dedicado que permite a orquestadores de código abierto como Autohen, LandChain y Semantic Kernel invocar agentes de Foundry. Entonces, si has creado agentes usando esos marcos, puedes conectarlos al ecosistema de Microsoft sin reescribir nada. Es una vía de dobles. Microsoft sigue el mismo patrón de orquestador especialista que hemos estado describiendo. El agente principal en Copilot Studio actúa como el orquestador, mientras que los agentes secundarios y conectados son los especialistas.

Cada uno maneja su propio dominio y el orquestador dirige y combina. Es la misma arquitectura, solo que ejecutándose en la plataforma de Microsoft. Pero aquí está el detalle. Hay algunas limitaciones que debes conocer. Primero, cada salto de orquestación adicional añade la tex. Si tu agente principal llama a un agente conectado, y ese agente conectado llama a otro especialista que haga salto, añade tiempo de red. Para conversaciones en tiempo real, demasiados saltos pueden hacer que la experiencia se entame. Segundo, la delegación excesiva crea un caos de enrutamiento. Si tienes demasiados especialistas con dominios superpuestos, el orquestador comienza a tomar malas decisiones de enrutamiento. Así que mantén tu número de especialistas bajo control y tus dominios claramente separados. Tercero, existe una limitación específica con los agentes de datos de Fabio. No funcionan cuando el agente principal se implementa en Microsoft 365 Copilot.

Si tu implementación apunta en B35, planifica en consecuencia. Estas limitaciones son reales, pero son manejables. La plataforma es lo suficientemente madura para uso en producción y Microsoft trabaja activamente en cerrar estas brechas. Ahora, unamos los puntos y veamos el panorama general. Sección de conexión. ¿Cómo encaja todo? Demos un paso atrás y veamos cómo se conectan estas piezas. A2A es el sistema telefónico que los agentes usan para llamarse entre sí. Las tarjetas de agentes son tu directorio de teléfono. Te muestran a quién llamar y de qué se encarga cada agente. El orquestador es el recepcionista que dirige cada llamada al departamento correcto. Ninguna de estas piezas funciona sola. Necesitas las tres. Sin una guía telefónica no sabes a quién llamar. Sin un recepcionista, nadie dirige el tráfico. Y sin un sistema telefónico, un recepcionista no puede conectar a nadie. Solo funcionan como un equipo.

Ahí es donde entra la modularidad. Cuando tus especialistas son modulares, puedes añadir nuevas capacidades sin romper lo que ya funciona. Digamos que quieres añadir un especialista en alquiler de coches a tu asistente de viaje, lo construyes, publicas su tarjeta de agente y le das al orquestador su aire. El especialista en vuelos y el especialista en hoteles permanecen exactamente igual. ¿El orquestador tampoco cambia? Simplemente conectas una nueva pieza y el sistema se adapta. Debido a que el protocolo es abierto, nunca te quedarás atado a un solo proveedor. Tu orquestador puede ejecutarse en Copilot Studio. Tu agente meteorológico puede estar en Google Cloud. Tu agente de hoteles en AWS y tus sistemas internos pueden permanecer en Azure. Todos hablan en el mismo idioma. Esa es la belleza de un estándar abierto. Evita la dependencia de proveedores y te permite elegir la mejor herramienta para cada trabajo.

A dosa no se trata de construir un agente súper inteligente que lo sepa todo. Se trata de construir una fuerza laboral flexible de especialistas que puedes reorganizar en mis armas y de que cambien de tus. No reemplazas a tus agentes, los reanizas. Añades otros, ¿no? Sustituye los antiguos. El sistema crece contigo en lugar de convertirse en un cuello de botella. Entonces, ¿qué puedes hacer conocimiento? Inclusiones prácticas. Pisa poco más. Elige un proceso repetitivo en tu organización que involucre múltiples sistemas. Resolución de tickets. Integración de empleados o informes de gastos, por ejemplo. Algo con transferencias claras entre pasos. Luego, construye un prototipo con un orquestador y dos especialistas. No necesitas una gran arquitectura. Solo necesitas un ejemplo funcional del cual aprender. Usa las herramientas que ya admiten esto. Copilot Studio tiene soporte a dosa integrado.

Azure AI Foundry también lo tiene. No necesitas crear el protocolo desde cero ni escribir código de integración personalizado. Pega una URL, configura tus agentes y comienza a delegar. Cuidado con los errores comunes. Evita que los dominios de tus especialistas se superpongan. Si dos agentes pueden hacer lo mismo, combínalos o divide el dominio de forma más clara. Deja que el orquestador maneje el enrutamiento o no la ejecución. Vigila la latencia causada por nuestra orquestación. Si el tiempo de respuesta empieza a aumentar, puede que tengas demasiadas capas de delegación. El mejor primer paso es sencillo. Identifica las transferencias en tu flujo de trabajo actual. ¿Dónde se transfiere información entre personas o entre sistemas? Esos son los puntos donde los agentes pueden tomar el control. Cada transferencia es una oportunidad. Así que eso es el sistema A2A en pocas palabras. Tres piezas simples trabajando juntas.

Los agentes dejan de estar aislados y empiezan a actuar como un verdadero equipo. Elige un flujo de trabajo con transferencias claras y control y apartir. Suscríbete para más explicaciones sencillas y deja un comentario si algo te resultó útil.