Una publicación del AWS Machine Learning Blog publicada el 09.11.2026 presenta el Pluggable Agentic AI Framework, una arquitectura de referencia componible organizada en siete capas y diseñada para llevar aplicaciones de IA multiagente del prototipo a la escala de producción sobre Amazon Bedrock AgentCore.
El texto comienza con las preguntas que una prueba de concepto no puede responder: cómo atender miles de solicitudes simultáneas de usuarios de forma segura, cómo mantener a los agentes fiables bajo tráfico real en lugar de fallar silenciosamente, cómo saber si un agente sigue cumpliendo los estándares de calidad y seguridad que superó durante las pruebas, y qué comportamientos del agente deben ser deterministas o no deterministas. Los autores sostienen que la brecha entre un prototipo funcional y un sistema que opera de manera fiable, segura, frugal y responsable a escala es donde la mayoría de las iniciativas de IA agéntica se estancan, y que rara vez es culpa del modelo. Los equipos tienden a reconstruir una y otra vez la misma infraestructura auxiliar, como la lógica de enrutamiento, las barreras de protección y la observabilidad, aplicada a posteriori en lugar de diseñarse desde el inicio.
Las siete capas
Cada capa tiene una responsabilidad distinta y un contrato estable. Los servicios mencionados en cada capa reflejan la implementación de referencia y no son opciones obligatorias; las organizaciones pueden sustituirlos por alternativas acordes con su infraestructura y requisitos.
Datos y Conocimiento (Data and Knowledge). Esta capa de base gestiona la recuperación, los embeddings y el acceso a datos estructurados y no estructurados mediante un contrato que acepta una consulta y devuelve la información más relevante como contexto para el agente. Entre los componentes de ejemplo figuran Amazon Bedrock Knowledge Base, Vector Engine for Amazon OpenSearch Serverless, Amazon S3 Vectors y Amazon DynamoDB.
Modelo e Inferencia (Model and Inference). La elección del modelo debe depender de la configuración y no quedar fijada en la lógica del agente: modelos más pequeños y rápidos para tareas sencillas y modelos más grandes para solicitudes que requieren un razonamiento más matizado, seleccionados tras una evaluación con datos empresariales realistas y representativos. Una capa de enrutamiento de modelos mantiene a los agentes desacoplados del entorno de alojamiento y de las API específicas de cada proveedor; un proxy como LiteLLM ofrece una interfaz común entre proveedores, de modo que se puede cambiar de modelo sin reescribir la lógica de la aplicación.
Orquestación (Orchestration). Para tareas sencillas, los autores recomiendan un único agente de principio a fin; para flujos de trabajo complejos y multidominio, un supervisor que delegue en agentes especialistas, cada uno delimitado a una capacidad y a un conjunto de herramientas concretos. Advierten contra un único agente que lo haga todo: la acumulación de herramientas, instrucciones y contexto agranda la ventana de contexto, aumenta la latencia, puede reducir la precisión y genera una proliferación de herramientas que puede empujar a los agentes más allá de sus límites previstos, con acciones no deseadas y brechas de seguridad. Los especialistas deben operar con autonomía acotada, ejecutándose estrictamente dentro de las herramientas concedidas. El texto también recomienda desacoplar a los especialistas del supervisor mediante un registro centralizado de agentes que catalogue las herramientas, habilidades y responsable de cada agente, con invocación a través de protocolos estandarizados como MCP (Model Context Protocol) y A2A (Agent to Agent). Entre los componentes sugeridos se encuentran Strands Agents para los especialistas, el harness de Amazon Bedrock AgentCore para el orquestador, y AWS Agent Registry junto con Amazon Bedrock AgentCore Gateway para el descubrimiento y enrutamiento centralizados.
Seguridad y Barreras de Protección (Security and Guardrails). Los autores afirman que la IA agéntica expone a las organizaciones a riesgos para los que los marcos de seguridad convencionales no fueron diseñados, desde la inyección de prompts y el uso indebido de herramientas hasta el envenenamiento de memoria y datos. Entre las recomendaciones figuran tratar todo contenido externo como no confiable, autenticar cada solicitud ya provenga de un usuario, de otro agente o de un flujo de trabajo automatizado (por ejemplo mediante Amazon Bedrock AgentCore Identity), aplicar control de acceso detallado antes de cada llamada a herramienta, conceder credenciales temporales y de alcance limitado en lugar de secretos persistentes, y enmascarar datos sensibles como PHI y PII en solicitudes y respuestas. Para la rendición de cuentas, el texto pide un registro de auditoría a prueba de manipulaciones de las decisiones relevantes, una puerta de aprobación humana para las acciones de alto impacto y disyuntores que detengan comportamientos anómalos. Los servicios sugeridos incluyen Amazon Bedrock Guardrails para las entradas de usuario, AgentCore Identity y Policy en Amazon Bedrock AgentCore para la autenticación y el control de acceso, y los controles de seguridad y gobernanza de AWS para una defensa en profundidad.
Aplicación (Application). La capa de experiencia del usuario final, ya sea una interfaz de chat, una superficie de API o un widget integrado, debe mantenerse intencionadamente delgada: presenta la conversación y pasa las solicitudes a la capa de orquestación, sin lógica de negocio incorporada. Un modelo de decisión puede situarse en este límite como una comprobación rápida y económica que puntúa si una solicitud está dentro del ámbito, necesita una persona o es urgente, devolviendo probabilidades en lugar de texto libre, de modo que el bucle agéntico completo solo se ejecute cuando aporta valor. El texto también aconseja diseñar las interfaces externas para que otros agentes de IA, y no solo personas, puedan consumir e interactuar con el sistema.
Observabilidad (Observability). La monitorización debe cubrir todas las capas desde el primer día. Junto a los registros y las métricas, las trazas de extremo a extremo del agente son fundamentales para medir si realizó su tarea correctamente; el texto también enumera el coste y el uso de tokens por solicitud, el tiempo hasta el primer token, si cada llamada es segura y paneles de latencia, tasas de error y gasto antes del lanzamiento. Las herramientas sugeridas incluyen Amazon CloudWatch con OpenTelemetry y Amazon CloudWatch Omni para trazas y métricas.
Operaciones Agénticas (Agentic Operations). Esta capa cierra el ciclo con evaluación continua: puntuar cada sesión de producción en fundamentación, precisión y seguridad, con una puerta de regresión que detecte caídas de calidad antes de que lleguen a los clientes. Los componentes sugeridos son Amazon Bedrock AgentCore Evaluations para la puntuación y Amazon Bedrock AgentCore optimization para el ajuste continuo del rendimiento.
Implementación de referencia
El marco incluye una implementación de referencia lista para ejecutar basada en un escenario de atención al cliente minorista que cubre el estado de pedidos y la elegibilidad para reembolsos, elegido porque ejercita todas las capas y sigue siendo fácil de adaptar. Un agente supervisor recibe la solicitud de reembolso y delega en un agente de Pedidos y un agente de Reembolsos. El agente de Pedidos consulta los datos de entrega y compra en Amazon DynamoDB; el agente de Reembolsos recupera las reglas de política por niveles desde una base de conocimiento y calcula la elegibilidad usando la fecha de entrega, la fecha actual y el nivel de fidelidad del cliente. Cada llamada pasa por AgentCore Gateway, que aplica control de acceso detallado antes de que una herramienta se ejecute mediante Policy en AgentCore, y cada llamada se traza de extremo a extremo, de modo que un cálculo erróneo puede atribuirse a una capa y a un punto de decisión concretos. Los equipos que construyan un patrón similar de supervisor y especialistas pueden clonar la implementación y sustituir su propia lógica de dominio capa a capa.
Por qué importa la conectividad modular
Los autores sostienen que el valor del diseño por capas reside en la rapidez con que cada capa puede evolucionar: los contratos estables en los límites entre capas, desde las comprobaciones de identidad y las políticas de acceso hasta las interfaces de telemetría, permiten cambiar la tecnología subyacente sin rediseñar el resto del sistema. El marco lo demuestra mediante integraciones con proveedores externos en todas las capas, incluidos proveedores de modelos y alojamiento en la inferencia, capacidades de búsqueda en la orquestación, API de decisión en la capa de aplicación, barreras de protección en la capa de seguridad y soluciones de trazado y monitorización de agentes en la observabilidad, junto con el seguimiento del valor de negocio y los costes. Para las empresas, afirma el texto, esta flexibilidad protege las inversiones existentes y evita que todas las decisiones tecnológicas deban provenir del mismo proveedor.
La publicación concluye que un prototipo demuestra lo que un agente puede hacer, mientras que la arquitectura determina si una empresa puede depender de él, y recomienda comenzar con la experiencia de Workshop Studio y el repositorio de ejemplo público, con la advertencia de que la implementación no sustituye al endurecimiento de seguridad, las pruebas y la revisión propios de producción.