Las opiniones expresadas en esta publicación son las de los autores y no las de Cisco.
Las arquitecturas empresariales se han centrado durante mucho tiempo en las API REST y los microservicios. Estos sistemas son estables, están bien probados y están profundamente integrados en entornos de producción. No fueron diseñados para la comunicación de agente a agente (A2A), el estándar emergente para agentes autónomos que colaboran, razonan y coordinan a través de mensajes estructurados. Eso funcionó en ausencia de un protocolo de agente común, pero significa que muchos agentes existentes ahora se encuentran fuera del marco emergente A2A. El desafío hoy ya no es sólo agregar A2A a los servicios tradicionales. También es necesario incorporar estos agentes basados en REST a un mundo estandarizado de agente a agente.
En esta colaboración técnica entre AWS y los autores, presentamos una solución pragmática: superposiciones agentes. Las superposiciones agentes son capas delgadas que transforman los servicios tradicionales basados en REST en agentes capaces de participar en interacciones A2A. También exponen las API REST como herramientas compatibles con el Protocolo de contexto modelo (MCP). Juntos, permiten a las empresas agregar capacidades A2A a los servicios REST existentes sin reescribir la lógica empresarial, sin duplicar código y sin ejecutar infraestructuras paralelas. Esto reduce la dispersión de agentes en la infraestructura al reutilizar los servicios existentes como agentes. Proporcionamos arquitecturas de referencia y código de muestra que muestran cómo crear superposiciones agentes.
Antecedentes: REST frente a A2A
Las API REST están diseñadas para una integración determinista cliente-servidor. Un cliente llama a un punto final bien definido, pasa parámetros y recibe una respuesta predecible, generalmente en un flujo de solicitud-respuesta sin estado gobernado por la semántica HTTP. Esto hace que REST sea excelente para exponer capacidades comerciales (como crear, leer, actualizar y eliminar) con contratos claros, gran compatibilidad y simplicidad operativa.
A2A está diseñado para la interoperabilidad entre agentes autónomos. Los agentes se descubren entre sí a través de metadatos (como una tarjeta de agente), negocian capacidades e intercambian mensajes estructurados (a menudo a través de JSON-RPC) para coordinar tareas de varios pasos. Mientras que REST optimiza para interfaces de servicio estables y ejecución directa, A2A optimiza para coordinación basada en razonamiento, mensajería orientada a tareas y colaboración de agentes. El resultado son sistemas que pueden planificar, delegar y componer acciones en múltiples servicios en lugar de invocar puntos finales aislados.
Desafíos al avanzar hacia sistemas agentes
Las API REST y los sistemas de agencia se basan en paradigmas ortogonales, lo que dificulta que las empresas trasladen los servicios existentes a una comunicación de agencia estandarizada. Sin embargo, las empresas necesitan utilizar ambos sin una reforma importante. Aunque la comunicación de agentes más nueva a través de A2A introduce modelos de coordinación para los sistemas empresariales, la adopción se ha visto ralentizada por la necesidad de implementar y operar infraestructuras de agentes junto con los sistemas empresariales existentes. Esta operación paralela aumenta la complejidad operativa y el costo, creando barreras para la adopción efectiva de la IA.
Antes de que se estandarizara A2A, las empresas comúnmente implementaban agentes como servicios propietarios o basados en REST. Los trataron como API convencionales con lógica específica del agente integrada en puntos finales de solicitud-respuesta. Como resultado, muchos agentes existentes hoy en día no son nativos de A2A, lo que crea un nuevo desafío de migración: hacer que estos agentes interoperen utilizando protocolos A2A estandarizados sin reescribir su lógica central.
Fig 1: aplicación basada en REST
La figura anterior muestra una aplicación basada en REST. La pila de API REST puede ser un monolito o un conjunto de puntos finales distribuidos. El controlador de API REST no necesita ser un intermediario explícito que delega solicitudes fuera de la aplicación. Puede ser parte del marco mismo. Por ejemplo, en una aplicación Flask, el marco proporciona la abstracción del controlador lista para usar, como normalmente se ve cuando se usa @app.route () o las extensiones RESTful de Flask. La idea aquí es capturar la pila REST con un conjunto de puntos finales.
Enfoques de solución
En esta sección, analizamos los diferentes enfoques que podría adoptar para agregar una capacidad de agente a un sistema empresarial heredado. Los comparamos con el enfoque de utilizar superposiciones agentes.
Mantener pilas REST y A2A separadas: un enfoque es desarrollar y mantener dos formas paralelas de exponer las mismas capacidades. Esto podría significar:
Dos conjuntos de puntos finales: /api/v2/… y /a2a/…. Dos implementaciones de autenticación, validación y mapeo de errores (a menos que se reutilicen cuidadosamente). Dos canales de implementación (compilación, prueba, lanzamiento, reversión). Trabajo de doble observabilidad: logs, métricas y rastreo para ambos caminos. Mayor riesgo de inconsistencia. A2A puede devolver una salida diferente para la misma operación realizada por REST. Mayor costo y complejidad operativa en el tiempo.
Fig 2: Pilas REST y A2A separadas
Pilas separadas, pero lógica empresarial compartida: refactorizar los puntos finales existentes significa cambiar la estructura actual del código API REST (y a veces el comportamiento) para que pueda ser reutilizado por una nueva interfaz como A2A. En lugar de dejar los puntos finales REST como están, los reorganiza, generalmente extrayendo la lógica empresarial en servicios compartidos y actualizando controladores y manejadores para llamar a esos servicios. Incluso si las rutas REST externas siguen siendo las mismas, la refactorización puede introducir regresiones, cambios de comportamiento y una gran carga de pruebas.
Fig. 3: Pilas separadas, lógica empresarial compartida
La idea central: superposiciones agentes
Una superposición agente es una capa envolvente delgada que permite que los servicios basados en REST participen en la comunicación A2A. La superposición:
Transforma un mensaje agente en una carga útil REST y viceversa. Expone puntos finales REST como tareas o herramientas del agente.
Lo más importante es que A2A no es una API nueva. Es una nueva interfaz para una API existente. El servicio REST subyacente permanece sin cambios.
Agregar una superposición agente dentro de la aplicación
En este enfoque, tiene dos conjuntos de puntos finales, /api/v2/… y /a2a/… (REST frente a A2A), como se muestra en el siguiente diagrama, pero una única canalización de implementación para compilación, prueba, lanzamiento y reversión. Con este patrón, los puntos finales de API REST tradicionales se pueden transformar en puntos finales agentes sin reescribir la lógica empresarial central. El proceso de implementación no cambia para el servicio. Para el mismo host y el mismo puerto, agrega nuevas rutas, aunque es posible que sea necesario escalar los sistemas para manejar un mayor tráfico.
Puede aplicar las habilidades del agente para el enrutamiento. Se puede utilizar un servidor MCP para invocar servicios externos, pero las habilidades del agente pueden enrutar solicitudes dentro del alcance del agente directamente sin importar API a un servidor MCP como habilidades. Cualquier punto final que tenga puede exponerse como habilidades de agente sin necesidad de un servidor MCP independiente.
Fig 4: Superposición agente dentro de una aplicación
Este enfoque reduce la dispersión de agentes en la infraestructura al reutilizar los servicios existentes como agentes. Este patrón de diseño funciona bien para agentes supervisores que necesitan capacidades de agente y basadas en REST con un alcance funcional limitado, como clasificación de intenciones y enrutamiento.
Implementación de ejemplo de superposición agente
Como prueba de concepto, esta sección muestra cómo trasladar un servicio de calculadora heredado basado en REST de ejemplo que utiliza Flask a un sistema agente mediante una superposición. Para la superposición, agregamos los componentes (o rutas) estándar de A2A, como una tarjeta de agente conocida, un punto final de mensaje de agente, capacidades, habilidades y estado. También presentamos un patrón de diseño de transformación de mensajes que convierte mensajes de agente en mensajes de API REST y luego emite llamadas de invocación REST desde el agente. El flujo de trabajo de traducción de mensajes A2A es el siguiente:
Recibe solicitudes JSON-RPC 2.0. Asigna tareas A2A a puntos finales REST. Reenvía encabezados de autenticación. Llama a puntos finales REST internamente. Traduce respuestas REST al formato JSON-RPC.
Paso 0: formato de solicitud-respuesta
Esta sección compara el formato de solicitud-respuesta para los protocolos REST y A2A, utilizando el ejemplo de calculadora que se muestra en las siguientes secciones.
Solicitud de entrada REST frente a A2A:
REST A2A { “operación”: “agregar”, “operandos”: [5, 3] } { “jsonrpc”: “2.0”, “método”: “SendMessage”, “params”: { “mensaje”: { “rol”: “usuario”, “partes”: [ { “tipo”: “datos”, “datos”: { “operación”: “agregar”, “operandos”: [5, 3] } } ] } }, “identificación”: 1 }
Respuesta de salida REST vs. A2A:
REST A2A {“resultado”: 8} { “jsonrpc”: “2.0”, “resultado”: { “messageId”: “uuid”, “contextId”: “uuid”, “role”: “agente”, “partes”: [{“tipo”: “datos”, “datos”: {“resultado”: 8}}], “tipo”: “mensaje”, “metadatos”: {} }, “identificación”: 1 }
Paso 1: configurar el agente
En este paso, creará el ejemplo de agente de calculadora con una tarjeta de agente conocida y habilidades de agente cargadas. La función build_agent_card crea la tarjeta de agente dinámicamente.
Paso 2: implementar el llamador REST interno
Nota sobre eventos enviados por el servidor (SSE) para streaming:
La función extract_message_payload() anterior funciona de la misma manera tanto para SendMessage como para SendStreamingMessage.
Para operaciones instantáneas (como nuestra calculadora), ambos métodos devuelven un único resultado. Para operaciones de larga duración (por ejemplo, generación de informes o análisis de datos), la transmisión SSE permite que el servidor envíe actualizaciones incrementales.
Paso 4: implementar creadores de respuestas JSON-RPC
Paso 5: SendMessage: delegación de A2A a REST
Paso 6: configurar rutas A2A (especificación 0.3)
El SDK oficial de A2A proporciona bibliotecas A2A para aplicaciones FastAPI y Starlette que abstraen la complejidad de agregar rutas específicas de A2A. Aunque las bibliotecas A2A también están disponibles para aplicaciones Flask, no las usamos en nuestro código de muestra. Queremos que le resulte sencillo comprender lo que se necesita para alojar una superposición A2A en una aplicación Flask. El siguiente fragmento de código agrega las rutas necesarias para A2A.
Paso 7: Finalmente, inicialice su aplicación
Paso 8: ejecuta tu aplicación
Desde el directorio base del proyecto, ejecute los siguientes comandos.
Agregar una superposición agente mediante Amazon Bedrock AgentCore Gateway
Amazon Bedrock AgentCore es un servicio para crear, conectar y optimizar agentes a escala sin administrar infraestructura. Como se muestra en el siguiente diagrama, AgentCore Gateway puede desacoplar la superposición agente de la aplicación sirviendo como un único punto de acceso para puntos finales y servicios. Esta separación permite que una superposición agente sirva múltiples servicios o aplicaciones, no solo uno. AgentCore Gateway admite hasta 10 objetivos por puerta de enlace, con integración nativa en los servicios de AWS existentes y compatibilidad con puntos finales OpenAPI.
Fig 5: Desacoplamiento de la superposición agente mediante Amazon Bedrock AgentCore Gateway
Las aplicaciones a escala empresarial a menudo organizan múltiples servicios para manejar tareas complejas. Por ejemplo, una aplicación de calculadora que procesa “Calcular 2 * (3 + 4)”. Como se muestra en el siguiente diagrama, el sistema primero consulta un punto final de orden de operaciones (como /api/order-of-ops/…) para determinar el orden de evaluación. Luego realiza llamadas secuenciales a un punto final (como /api/arithmetic/…) para calcular "3 + 4" seguido de "2 * 7". Agregar una superposición de agente a cada servicio introduciría sus propios gastos generales. En su lugar, puede unir ambos servicios en una única superposición agente que organice las llamadas según sea necesario.
Puede separar la superposición de agente de su aplicación para organizar sus superposiciones de agente según la funcionalidad en lugar de solo por aplicación. Las superposiciones agentes actúan como una forma agente de interactuar con sus aplicaciones y sus sistemas, una forma agente de interactuar con la funcionalidad.
Más allá de AgentCore Gateway, las capacidades adicionales de AgentCore simplifican el monitoreo, la iteración y la implementación de su superposición agente. AgentCore Identity maneja la autenticación para los componentes del agente y de la puerta de enlace, y admite proveedores de OAuth 2.0 con integraciones administradas para Okta, GitHub y Slack. AgentCore Observability monitorea el desempeño de los agentes a través de métricas, registros y visualizaciones de intervalos. Puede ver datos de alto nivel, como llamadas a herramientas y latencia, o inspeccionar rutas de ejecución granulares entre componentes, con la integración nativa de Amazon CloudWatch. AgentCore Runtime implementa modelos a través de una imagen de contenedor, ya sea de código abierto, personalizado o LLM de Amazon Bedrock como Nova y Anthropic Claude, sin necesidad de administrar una infraestructura de modelos de lenguaje grandes (LLM).
Fig 6: Desacoplamiento de la superposición agente mediante las capacidades de Amazon Bedrock AgentCore: tiempo de ejecución, puerta de enlace, identidad y observabilidad
Al utilizar las diferentes capacidades de AgentCore, puede simplificar la implementación de su agente y su superposición agente, con una integración sencilla en su pila de AWS existente. Debido a que es un servicio administrado, también reduce el trabajo necesario para implementar su superposición agente.
Asociación para acelerar la adopción de la IA empresarial
Este patrón de superposición agente representa una colaboración más amplia entre los autores y AWS para ayudar a las empresas a cerrar la brecha entre la infraestructura existente y las capacidades emergentes de IA. La adopción exitosa de la IA requiere soluciones pragmáticas que respeten las inversiones existentes y respalden la transformación incremental. Juntos, AWS y los autores están desarrollando arquitecturas de referencia, patrones de implementación y herramientas que permiten a las empresas adoptar la comunicación A2A sin un reemplazo total de la infraestructura. El patrón de superposición agente ejemplifica esta filosofía: preservar lo que funciona, extenderlo donde sea necesario y proporcionar rutas de migración claras que minimicen el riesgo y maximicen el valor.
Conclusión
Las superposiciones agentes brindan a las empresas un camino pragmático para adoptar la comunicación de agente a agente sin abandonar sus inversiones en API REST. Al agregar una capa de traducción delgada que convierte mensajes A2A en cargas útiles REST, las organizaciones pueden participar en el panorama agente emergente y al mismo tiempo preservar una lógica empresarial estable y probada en producción. Los dos patrones de implementación ofrecen flexibilidad para satisfacer las necesidades de la organización: superposiciones dentro de la aplicación para casos de uso específicos y AgentCore Gateway para implementaciones a escala empresarial. Ya sea que esté habilitando un único agente supervisor u orquestando flujos de trabajo complejos de múltiples servicios, las superposiciones de agentes reducen la sobrecarga operativa de las infraestructuras paralelas y el riesgo de regresión de la refactorización total.
A medida que las empresas navegan por la transición de las API REST deterministas a los sistemas agentes basados en el razonamiento, la idea clave sigue siendo: A2A no es una API nueva. Es una nueva interfaz para su API existente. Esta perspectiva cambia el desafío de la adopción de reconstruir todo a modernizarlo gradualmente, para que las organizaciones puedan obtener el valor de la IA más rápido y al mismo tiempo gestionar el riesgo de manera efectiva. Para las organizaciones que están listas para explorar superposiciones agentes, el ejemplo de la calculadora proporciona un punto de partida concreto y AgentCore ofrece infraestructura para implementaciones de producción.
Próximos pasos
Evalúe su arquitectura: audite los servicios REST para candidatos a habilitación A2A. Las superposiciones dentro de la aplicación se adaptan a los agentes de servicio único. AgentCore Gateway se adapta a flujos de trabajo multiservicio. Revise la implementación de referencia: el ejemplo de la calculadora Flask demuestra el patrón de traducción con la configuración de la tarjeta del agente, la extracción de mensajes, la invocación REST y la creación de respuestas. Explore Amazon Bedrock AgentCore: AgentCore Gateway, Identity y Observability brindan infraestructura para superposiciones agentes de producción. Únase a la comunidad A2A: la especificación del protocolo A2A y la documentación del SDK están disponibles en a2a-protocol.org, con bibliotecas para aplicaciones Flask, FastAPI y Starlette.
El futuro de la IA empresarial no reside en reemplazar los sistemas existentes, sino en ampliarlos con capacidades de agencia. Las superposiciones agentes hacen que ese futuro sea accesible hoy.
Sobre los autores
Renuka Kumar
Renuka, Ph.D., es ingeniera principal de software en Cisco, donde diseñó y dirigió el desarrollo de las capacidades de IA/ML de la unidad de negocio de seguridad en la nube de Cisco en los últimos tres años, incluido el lanzamiento de innovaciones pioneras en el mercado en este espacio. Tiene más de 20 años de experiencia en varios dominios de vanguardia, con más de una década en seguridad y privacidad. Tiene un doctorado de la Universidad de Michigan en Ingeniería y Ciencias de la Computación.
Jessica Wu
Jessica es arquitecta de soluciones asociada en AWS. Trabaja con clientes estratégicos de AWS para crear arquitecturas de alto rendimiento, resilientes, tolerantes a fallas, optimizadas en costos y sostenibles. Jessica también se centra en ayudar a los clientes a superar el desafío de adoptar, integrar y expandir la IA y las cargas de trabajo compatibles con la IA.
Shweta Keshavanarayana
Shweta es gerente senior de soluciones para clientes en AWS. Trabaja con clientes estratégicos de AWS y los ayuda en su viaje de modernización y migración a la nube. A Shweta le apasiona resolver los complejos desafíos de los clientes mediante soluciones creativas. Tiene una licenciatura en Ciencias e Ingeniería de Computación. Más allá de su vida profesional, se ofrece como directora voluntaria del equipo de cricket U9 de sus hijos, al mismo tiempo que asesora a mujeres en tecnología y sirve a la comunidad local.
Abhishek Ghiya
Abhishek es ingeniero de software líder en Cisco, donde opera en la intersección de la ciberseguridad y la IA/ML. Se especializa en crear agentes con tecnología LLM y diseñar soluciones de inteligencia artificial escalables en AWS utilizando Docker y Kubernetes. Con una amplia experiencia en gestión de identidades y acceso, puertas de enlace API y motores de políticas, a Abhishek le apasiona resolver desafíos arquitectónicos complejos. Su experiencia técnica abarca el desarrollo completo y la construcción de sistemas basados en eventos en entornos nativos de la nube.