AWS propone una arquitectura de siete capas para agentes: del prototipo a producción

El prototipo de un agente casi siempre resulta convincente. Responde preguntas, llama a herramientas y luce muy bien en la demo. Luego llegan el tráfico real, la factura de tokens y la revisión del equipo de seguridad, y el proyecto se atasca. Según AWS, rara vez la culpa es del modelo. La culpa es de la infraestructura circundante que cada equipo escribe desde cero y, por lo general, después del lanzamiento y no antes.

El blog de AWS Machine Learning ha publicado un análisis del Pluggable Agentic AI Framework. Se trata de una arquitectura de referencia para aplicaciones multiagente compuesta por siete capas. Cada capa tiene su propia área de responsabilidad y un contrato estable con las vecinas. Los servicios concretos del esquema son solo un ejemplo de implementación, no una elección obligatoria.

Siete capas sin magia

La primera capa es la de datos y conocimiento. Recibe una consulta y devuelve el contexto relevante para el agente. En el ejemplo se trata de Bedrock Knowledge Base, OpenSearch Serverless, S3 Vectors y DynamoDB.

La segunda capa es la de modelos e inferencia. La elección del modelo debe residir en la configuración, no en el código del agente. Las tareas sencillas van a un modelo pequeño y rápido; el razonamiento complejo, a uno grande. Entre los agentes y los proveedores se sitúa un proxy como LiteLLM con una interfaz única. Tras cada nueva evaluación se puede cambiar de modelo sin tocar la lógica de la aplicación.

La tercera capa es la orquestación. Para una tarea sencilla basta con un agente. Los escenarios complejos entre dominios requieren un supervisor y especialistas acotados, cada uno con su propio conjunto de herramientas. Un único agente universal acaba acumulando instrucciones y herramientas, el contexto se infla, la latencia crece y la precisión cae. Los especialistas se registran en un registro único, y el supervisor los encuentra y los invoca mediante los protocolos estándar MCP y A2A. Un registro con la descripción de las herramientas, las habilidades y el responsable de cada agente es necesario también para la gobernanza y para no escribir lo mismo dos veces.

La cuarta capa es la de seguridad y barreras de protección. Todo el contenido externo se considera no confiable. Cada solicitud se autentica, provenga de un usuario, de otro agente o de un proceso automático. Los permisos de cada llamada a una herramienta se comprueban antes de ejecutarla, y en lugar de secretos permanentes el agente recibe credenciales temporales y limitadas. Los datos personales y médicos se enmascaran en las solicitudes y las respuestas. Las decisiones clave se registran en un log de auditoría, las acciones de riesgo requieren confirmación humana y los interruptores de emergencia detienen el comportamiento anómalo.

La quinta capa es la aplicación. Se recomienda mantenerla delgada: un chat, una API o un widget pasan la solicitud al orquestador y nada más. Aquí no tiene cabida la lógica de negocio. En el límite se puede colocar un modelo clasificador barato y rápido. En una sola llamada evalúa si la solicitud encaja en la temática, si hace falta una persona y con qué urgencia. El modelo devuelve probabilidades, no texto, y un código ordinario decide mediante umbrales si se lanza el ciclo completo del agente.

La sexta capa es la observabilidad. Las trazas de extremo a extremo, el coste y los tokens por solicitud, el tiempo hasta el primer token y los paneles de latencia y errores se necesitan antes del lanzamiento, no después del primer incidente. La séptima capa son las operaciones: evaluación continua de cada sesión de producción en cuanto a fundamentación, precisión y seguridad. Además, una puerta de regresión que impide que llegue a los clientes una versión con la calidad deteriorada.

Cómo se ve en un ejemplo

La implementación de referencia es la atención al cliente en retail: estado del pedido y posibilidad de devolución. El supervisor recibe una solicitud de devolución y la pasa a dos especialistas. El agente de pedidos extrae de DynamoDB los datos de entrega y compra. El agente de devoluciones toma de la base de conocimiento las reglas por niveles de fidelidad y calcula la elegibilidad según la fecha de entrega, la fecha actual y el nivel del cliente. Cada llamada pasa por AgentCore Gateway, que comprueba los permisos. Cada llamada se traza, y si el cálculo falló, la traza muestra en qué capa y en qué decisión.

Qué sacar de todo esto

La idea principal: primero la arquitectura, luego las tecnologías. Si los límites de las capas están definidos por contratos, cambiar el modelo, las barreras de protección o el sistema de monitorización no se convierte en una reescritura de toda la pila. Para las empresas es además la posibilidad de conservar las herramientas que ya funcionan y añadir las nuevas de forma gradual.

También conviene ver las limitaciones. El artículo está escrito por un proveedor y está orientado a la pila de AWS: AgentCore, Bedrock, CloudWatch. La sustituibilidad de los componentes se declara, pero tendrá que comprobarla usted mismo en su propia infraestructura. Los propios autores advierten de que el ejemplo no sustituye el hardening de seguridad, las pruebas ni la revisión.

La conclusión práctica es sencilla. Incluso si no usa AWS, la lista de siete capas funciona como una lista de verificación para planificar. ¿Tiene un registro de agentes? ¿Los permisos se comprueban antes de llamar a la herramienta o después? ¿Sabe demostrar que el agente funciona tan bien como el día del lanzamiento? Si la respuesta a al menos una de estas preguntas es «no», ha encontrado el punto donde su proyecto corre el riesgo de quedarse atascado entre el prototipo y producción.