Cómo trabajan juntos los agentes de IA independientes: un puente A2A para Hermes Agent

Lo que esto significa para su negocio

• Sus agentes cooperan sin una reescritura. El Agent2Agent Protocol (A2A) es un estándar abierto para que los agentes de IA se descubran, se deleguen trabajo y transmitan resultados entre sí. Un fino puente permite que un agente existente hable ese estándar sin cambiar su interior: usted conserva la inversión que ya hizo.
• Sin dependencia de proveedor. Como el puente se sitúa entre el estándar y el agente, más adelante puede cambiar el framework de agente subyacente sin romper las integraciones construidas encima. Los demás equipos siguen llamando al mismo endpoint estándar.
• Un solo sistema atiende a muchos clientes o unidades de negocio, con separación de datos estricta. El aislamiento entre inquilinos se aplica a nivel de base de datos, no solo en el código de la aplicación, de modo que un error de programación no puede filtrar los datos de un cliente a otro. Esa es la diferencia que supera una auditoría de seguridad.
• Las personas mantienen el control de las acciones sensibles. Cuando un agente necesita una aprobación —una compra, una decisión de acceso a datos, la aprobación de una cotización— la solicitud aparece como un estado estándar de «esperando aprobación» que regresa hasta la persona o el agente que inició la cadena, incluso a través de las fronteras entre frameworks.
• Es real y está probado, no es una diapositiva. Todo está empaquetado como un despliegue de código abierto (docker-a2a-hermes-agent-gateway) con un conjunto de pruebas automatizadas que demuestra cada capacidad antes de que usted dependa de ella.

El problema: agentes que no pueden hablar entre sí

La mayoría de las organizaciones no adoptan «un agente de IA». Acumulan varios. Un agente de cotización aquí, un agente de consulta de catálogo allá, un agente de inventario que pertenece a otro equipo, a menudo construidos sobre frameworks distintos, a veces de proveedores distintos, en momentos distintos. Por separado funcionan. El cuello de botella es lograr que cooperen: entregar trabajo a otro, esperar un resultado y devolver el control.

Resolver eso cableando a mano cada agente con todos los demás es lento, frágil y empeora con cada nuevo agente. Además, lo encierra en silencio: en cuanto las integraciones quedan codificadas contra la interfaz de un proveedor, reemplazar a ese proveedor obliga a rehacerlas todas.

El Agent2Agent Protocol (A2A) es el estándar abierto que elimina ese cuello de botella. Define un lenguaje común para que los agentes se descubran, se deleguen tareas, transmitan el progreso y notifiquen la finalización, sin importar sobre qué esté construido cada uno. Adopte el estándar una vez y cada agente nuevo hablará el mismo lenguaje que el resto.

La trampa: sus agentes existentes no hablan A2A de forma nativa. Hermes Agent de Nous Research, por ejemplo, expone su propia interfaz. Reescribir un agente que funciona para añadir un nuevo protocolo es exactamente el tipo de proyecto costoso y arriesgado que los equipos quieren evitar.

La respuesta es un puente: una pequeña capa de traducción que habla A2A por fuera y se comunica con el agente en su propio lenguaje por dentro. El agente nunca cambia. El proyecto docker-a2a-hermes-agent-gateway es un ejemplo funcional y de código abierto de ese puente, empaquetado para ejecutarse como una única unidad desplegable.

Cómo encajan las piezas

Hay tres piezas en movimiento, y solo una de ellas queda expuesta al mundo exterior:

1. La puerta de entrada (la pasarela). Todo entra por un único punto de acceso controlado. Decide quién puede entrar, a qué cliente pertenece una solicitud, a qué velocidad pueden ir las personas que llaman y cómo se transmite el progreso en vivo. Nada más es accesible directamente.
2. El traductor (el puente). Recibe solicitudes en el estándar abierto A2A y las convierte en lo que su agente realmente entiende, y luego convierte de vuelta la respuesta. Esta es la única pieza que sabe algo del agente concreto, que es exactamente la razón por la que el agente puede cambiarse más adelante.
3. El agente y su registro de trabajo. Su agente existente hace el razonamiento real. Todo lo que hace queda anotado —cada tarea y cada mensaje— manteniéndolo estrictamente separado por cliente.

Como la puerta de entrada y el registro son independientes del agente en sí, puede mantener la pasarela dentro de su propia nube y apuntarla a un agente que se ejecute en otro lugar, o a una base de datos gestionada de su elección. Nada obliga a que las tres piezas estén en el mismo sitio.

Adopte el estándar sin reescribir sus agentes

La propiedad más valiosa aquí es que su agente nunca cambia. El traductor hace todo el trabajo de hablar el estándar en su nombre.

Eso tiene dos consecuencias de negocio directas:

• Protege la inversión que ya hizo. El equipo que construyó el agente de cotización no se detiene a rediseñarlo para un nuevo protocolo. Añade un puente y sigue adelante.
• Evita la dependencia en ambos sentidos. Quienes llaman dependen solo del estándar abierto, no de su proveedor de agentes. Si más adelante reemplaza el agente —un modelo mejor, un proveedor más barato, un desarrollo propio— cambia el traductor y todas las integraciones construidas encima siguen funcionando sin tocarse. A la inversa, una sola pasarela puede dar frente a varios agentes distintos a la vez: el trabajo de razonamiento intensivo enrutado a uno, los pasos de flujo rutinarios a otro, todos con el mismo aspecto para quien llama. La elección del motor pasa a ser un detalle de implementación que usted controla, no un compromiso al que queda atado.

Atienda a muchos clientes o unidades de negocio, con una separación de datos que supera una auditoría

El mismo despliegue puede atender a muchos inquilinos —clientes distintos, o unidades de negocio internas distintas— desde un solo sistema en ejecución. Cada uno obtiene sus propios agentes, su propio historial de tareas y su propio registro de mensajes.

Lo que hace que esto sea seguro y no solo cómodo es dónde se aplica la separación. Cada solicitud se etiqueta con el cliente al que pertenece, y la propia base de datos se niega a devolver las filas de un cliente a otro, un control aplicado en la capa de datos, por debajo del código de la aplicación. En la práctica, esto significa que un fallo o un filtro olvidado en el software no puede filtrar datos entre clientes, porque la base de datos es la red de seguridad, no la aplicación. Esa es la distinción que busca un revisor de seguridad o de cumplimiento, y la que le permite poner a varios clientes en infraestructura compartida sin poner en riesgo sus datos.

Mantenga a las personas al mando de las acciones sensibles

La autonomía solo es aceptable cuando una persona puede intervenir en los momentos que importan. Cuando un agente llega a un paso que necesita aprobación —autorizar una compra, aprobar una cotización, liberar datos sensibles— no se limita a continuar. Se detiene y plantea un estado estándar de «esperando aprobación».

Lo importante es que ese estado viaja. Una solicitud que empezó varios agentes atrás —posiblemente en un framework completamente distinto, propiedad de otro equipo— recibe esa misma señal de «se requiere entrada», sin cambios. Una persona aprueba (o rechaza) y el trabajo se reanuda. La gobernanza no se detiene en la frontera de un agente; el estándar abierto transporta la puerta de aprobación por toda la cadena. Para cualquier flujo de trabajo que toque dinero, contratos o datos regulados, ese control de extremo a extremo es lo que hace que la delegación entre agentes sea defendible en lugar de temeraria.

Ejecútelo donde deben residir sus datos

El despliegue es un paquete único y autónomo que puede ejecutarse combinado —agente, base de datos y pasarela juntos— para un arranque rápido, o separado para producción. Puede mantener la puerta de entrada controlada dentro de su propia red y apuntarla a una base de datos gestionada (de modo que las copias de seguridad, el cifrado y el cumplimiento los gestione su proveedor de nube) y a un agente que se ejecute en hardware aparte.

Para las empresas con requisitos de residencia o soberanía de datos, esto importa: el registro de cada interacción de agente puede mantenerse dentro del límite que exijan sus políticas, en lugar de en la nube de un tercero que usted no controla.

Probado antes de que dependa de ello

Una capacidad que no puede verificar es un riesgo. Este despliegue viene con un conjunto de pruebas automatizadas que ejercita el sistema real en ejecución de extremo a extremo, confirmando que los agentes pueden descubrirse, que las solicitudes se completan, que el progreso en vivo se transmite correctamente, que un cliente que se pierde una actualización en vivo todavía puede recuperar el resultado completo, y que los fallos y las cancelaciones se comportan como se espera. Las pruebas informan un resultado claro de aprobado o fallido en cada comprobación y están diseñadas para ejecutarse como una barrera automatizada, de modo que un cambio defectuoso se detecta antes de llegar a producción, no después.

El valor práctico es la reducción de riesgo: no está tomando la palabra de nadie de que la integración funciona. Se demuestra, de forma repetible, en cada cambio.

Lo que realmente exige ejecutarlo en producción

Ser honesto sobre el coste operativo es parte del caso de negocio. Algunas realidades que conviene planificar:

• Está diseñado para ejecutarse de forma ligera y luego escalar de forma deliberada. Lo predeterminado es un despliegue único y simple. Atender un volumen muy alto en varias copias es compatible, pero es un paso deliberado, no un accidente: necesita infraestructura compartida para que las copias se mantengan coherentes. Planifique la ampliación; no dé por hecho que es gratis.
• Mantenerse al día es una rutina, no una reescritura. Los componentes se obtienen de sus fuentes de código abierto, así que estar al día es una operación de actualización estándar que su equipo ejecuta según un calendario.
• La postura de seguridad es suya para configurar. El paquete viene con contraseñas de marcador de posición y valores permisivos por defecto para que arranque con facilidad de fábrica; están pensados para reemplazarse antes de exponerlo a internet. El agente opcional incluido es potente y solo debería ejecutarse en infraestructura de su confianza. Nada de esto es exótico; es el endurecimiento normal que necesita cualquier sistema en producción, y debería estar en la lista de verificación de puesta en marcha.

Ninguno de estos es un impedimento. Son las responsabilidades ordinarias de ejecutar un sistema real, y nombrarlas por adelantado es como se evitan las sorpresas tras el lanzamiento.

Lo que esto permite

En conjunto, el patrón de puente ofrece tres cosas genuinamente difíciles de armar por cuenta propia:

1. Cooperación basada en estándares sin una reescritura. Cualquier agente que hable A2A puede trabajar con su agente existente de inmediato —descubriéndolo, delegándole trabajo y siguiendo su progreso— sin que ese agente sea modificado. Adopta un estándar abierto mientras conserva lo que ya funciona.

2. Servicio multiinquilino con aislamiento real. Un solo despliegue atiende a muchos clientes o unidades de negocio, con la separación de datos aplicada a nivel de base de datos. Eso es lo que le permite consolidar en infraestructura compartida sin debilitar la seguridad.

3. Autonomía gobernada a través de fronteras. Las puertas de aprobación humana viajan con el trabajo, de modo que las acciones sensibles reciben a una persona en el circuito sin importar por cuántos agentes —o cuántos frameworks— haya pasado la solicitud.

La implementación funcional es de código abierto y está totalmente documentada: el puente y su guía de integración viven en el repositorio a2a_daemon_engine (véase la guía de integración de Hermes), y la puerta de entrada controlada está documentada en el repositorio de SilvaEngine Gateway. El despliegue completo está empaquetado en docker-a2a-hermes-agent-gateway.

Lecturas relacionadas

• MCP + A2A: los dos protocolos detrás de todo sistema de IA agéntica en producción — cómo los dos estándares abiertos dividen el trabajo: MCP conecta a los agentes con las herramientas, A2A conecta a los agentes entre sí
• Integrar A2A con frameworks de agentes existentes: una demostración con Hermes Agent — el patrón de puente general y cómo se aplica más allá de Hermes
• Estándar de código para módulos MCP — la disciplina que mantiene las integraciones de agentes listas para producción a medida que se multiplican

---

Un distribuidor de mercado medio necesita agentes de cotización que hablen con agentes de catálogo que hablen con agentes de inventario, cada uno construido por un equipo distinto, cada uno posiblemente sobre un framework distinto. Un estándar abierto da a esos agentes un lenguaje compartido. Un puente permite que los agentes que ya ejecuta se sumen sin ser reconstruidos. El resultado es un sistema donde los agentes cooperan, los datos de cada cliente permanecen separados y una persona mantiene el control de las decisiones que importan.

Solicite un desarrollo con alcance definido

Una semana de descubrimiento. Obtiene un inventario del sistema, un mapa de flujo de trabajo y un alcance fijo, tanto si construye con nosotros como si no.