Si ha intentado implementar un agente en producción, el modelo y la herramienta utilizados no son el obstáculo. El principal cuello de botella es todo lo que los rodea: cuántos equipos pueden construir dentro de un entorno seguro, qué equipo es el propietario de cada modelo y herramienta, cómo AgentOps y el manejo de errores se mantienen dentro de un límite predefinido, y cómo los equipos de plataforma, Workstream y finanzas ven el costo y la salud en todas las cuentas. Para un equipo de plataforma que desee admitir muchos casos de uso de agentes, eso es un producto de plataforma que diseñar y operar. En esta publicación, nos referimos al equipo que administra la plataforma como el equipo de plataforma, y a los equipos que construyen sobre ella como equipos de Workstream. Los equipos de Workstream son los equipos de dominio o producto que construyen y poseen agentes en la plataforma.

Cada equipo de Workstream necesita un camino pavimentado con modelos y herramientas aprobados, identidad de carga de trabajo de corta duración, tiempo de ejecución y memoria aislados, evaluación automatizada, reversión, telemetría y atribución de costos. Estos controles deben permanecer consistentes mientras los equipos de Workstream personalizan las solicitudes, herramientas, acceso a datos y comportamiento de la aplicación. Cuando cada equipo los ensambla, los controles se desvían, los servicios compartidos se convierten en un cuello de botella y la propiedad es difícil de auditar.

En esta publicación, pasamos por la arquitectura y la implementación de referencia de una plataforma de Agentic AI empresarial en Amazon Bedrock y Amazon Bedrock AgentCore. Cubrimos el modelo de operación de cuentas múltiples, el plano de control de la plataforma, un patrón de implementación repetible por Workstream, pasarelas de inferencia y herramientas separadas, y una tubería de evaluación que controla cada agente antes de promoverlo a producción. Al final, debería poder implementar un Workstream gobernado desde la plantilla companion, validar sus contratos de seguridad y ciclo de vida, y usarlo como base para su propia plataforma de Agentic AI en la organización.

Amazon Bedrock AgentCore proporciona servicios modulares para construir, implementar y operar agentes a escala, incluyendo tiempo de ejecución, pasarela, identidad, memoria, política, registro y evaluaciones. La Plantilla de plataforma de Agentic AI empresarial, construida sobre AgentCore, agrega los contratos empresariales circundantes como infraestructura de código implementable: propiedad, límites de cuenta, entrega de software, observabilidad, gobernanza de costos y jubilación.

Principios arquitectónicos

Antes de sumergirse en los detalles de la solución, ayuda entender las necesidades organizativas que impulsan la arquitectura de la plataforma. Los desafíos comunes que hemos escuchado de los clientes que establecen una plataforma de agentes se dividen en estas cinco categorías:

1. Acceso al modelo gobernado: Cada solicitud de inferencia no confiable debe pasar por una puerta de enlace de inferencia aprobada. La puerta de enlace aplica los guardrails de la organización (por ejemplo, Amazon Bedrock Guardrails o un proveedor de terceros), restringe qué modelos y regiones de AWS de inferencia cada Workstream puede utilizar, y aplica límites de velocidad, cuotas de token y presupuestos por Workstream para que ningún equipo pueda agotar la capacidad compartida. También lleva la identidad de la carga de trabajo y emite datos de atribución.
2. Acceso a herramientas gobernadas: Los agentes deben descubrir e invocar solo herramientas aprobadas a través de una puerta de enlace de protocolo de contexto de modelo (MCP) autenticada, con objetivos exactos, roles de ejecución con privilegios mínimos, decisiones de política y un propietario auditable.
3. Entrega delegada: Los equipos de Workstream (por ejemplo, equipos de productos) necesitan enviar y revertir de forma independiente dentro de límites preaprobados, sin esperar a que el equipo de plataforma implemente cada aplicación o otorgue a los desarrolladores una ruta de escritura directa en la infraestructura.
4. Operaciones de flota y costo: Varias personas necesitan visibilidad en varias cuentas sin obtener acceso de escritura a las cargas de trabajo del equipo. Los ingenieros de operaciones de agentes necesitan registros, métricas, trazas y cuotas. Los propietarios de Workstream necesitan el costo por agente en relación con sus presupuestos. Los equipos de FinOps y finanzas necesitan cargo por equipo o unidad comercial a través de AWS Cost Explorer y el Informe de costo y uso de AWS (CUR). Los líderes de seguridad y gobernanza necesitan pruebas de qué carga de trabajo llamó a qué modelo y herramienta.
5. Evidencia limitada y ciclo de vida: Cada lanzamiento de agente necesita pruebas en cada límite que toca:
   1. Acceso al modelo: Una llamada a un modelo aprobado tiene éxito, y una llamada a un modelo no aprobado o región es denegada.
   2. Acceso a herramientas: Una llamada a una herramienta suscrita tiene éxito, y una llamada a una herramienta fuera de la suscripción del agente es denegada con el error esperado.
   3. Identidad: Una solicitud de otra cuenta o identidad de Workstream es rechazada.
   4. Lanzamiento: La versión de tiempo de ejecución del agente anterior se puede restaurar.
   5. Jubilación: El desmantelamiento elimina el tiempo de ejecución del agente, la memoria, la puerta de enlace de herramientas y las concesiones de herramientas en orden de dependencia, y confirma que no queda nada atrás.

La plantilla aborda estas necesidades a través de cuatro planos conectados: experiencia del desarrollador, control de plataforma, ejecución de Workstream y garantía y operaciones. La unidad de escala es la célula de Workstream, no un agente configurado manualmente ni una cuenta de carga de trabajo compartida. La plantilla README documenta los responsabilidades de cada plano en detalle. Y leerás los planos principales: control de la plataforma Agentic AI y célula de Workstream repetible en los párrafos siguientes.

Modelos de operación y componentes de la plataforma

Las empresas suelen adoptar uno de tres modelos de operación para la inteligencia artificial agentic:

• Centralizado: Un solo equipo de inteligencia artificial y aprendizaje automático (AI/ML) crea y ejecuta cada agente. La gobernanza es consistente, pero ese equipo se convierte rápidamente en un cuello de botella a medida que crece el número de casos de uso.
• Descentralizado: Cada unidad de negocio crea y opera sus propios agentes. Los equipos pueden moverse rápidamente, pero sin estándares compartidos, los controles tienden a derivar, el esfuerzo se duplica y la visibilidad del costo se resiente.
• Federado: Un equipo de plataforma centralizado proporciona servicios compartidos y gobernados, mientras que los equipos de dominio retienen la propiedad de sus agentes, herramientas y datos. Este modelo equilibra la autonomía del equipo con guardrails consistentes y es donde la mayoría de las empresas se establecen.
• Para obtener ayuda para elegir, consulta la página de orientación prescriptiva de AWS sobre modelos de gobernanza.

Siguiendo patrones que hemos observado en compromisos con clientes, la plantilla implementa el modelo federado. El equipo de plataforma es el centro, típicamente un gerente de producto de plataforma, arquitecto, ingenieros de plataforma, ingenieros de operaciones de agentes y un líder de seguridad y gobernanza. Los equipos de Workstream son las radios, compuestas por desarrolladores de agentes, un líder técnico de dominio y ingenieros de AI/ML. Un patrocinador ejecutivo y el CISO se sientan por encima de ambos.

En esta plantilla, el equipo de plataforma posee la definición de cada componente: plantillas, versiones, políticas y admisión. Cada cuenta de Workstream ejecuta su propia instancia de los componentes por equipo (Runtime, Memoria, Puerta de herramientas), por lo que un fallo o reversión se mantiene dentro de los límites de un equipo.

Visión general de la solución

En una escala empresarial, el plano de experiencia del desarrollador es un catálogo de plantillas de agentes aprobadas por la organización y versionadas. La plantilla de referencia incluye plantillas para Strands, LangGraph y CrewAI, pero puede utilizar el framework de su elección cuando la plantilla preserve los mismos contratos de puerta de inferencia, puerta de herramientas, identidad, política, evaluación y entrega. Los equipos de aplicaciones poseen los mensajes de inicio, la lógica del agente, las herramientas y los casos de evaluación. El equipo de la Plataforma posee los controles comunes y los requisitos de lanzamiento.

De los cuatro planos, dos llevan la mayor parte de la arquitectura:

1. Plano de control de la Plataforma de Agentic AI: La cuenta de la Plataforma publica plantillas y interfaces versionadas, opera registros de gobernanza del Registro de Agentes de AWS y Puertas de Inferencia compartidas, admite modelos y Guardrails, orquesta lanzamientos revisados y agrega señales de la flota. Los equipos consumen estas capacidades a través del código, los descriptores y las pipelines en lugar de sesiones de administrador o tickets de implementación.
2. Celda de flujo de trabajo repetible: Cada producto o dominio recibe un límite aislado con un repositorio de código fuente propiedad del equipo, una pipeline de carga de trabajo y tres capacidades de AgentCore de Amazon Bedrock: AgentCore Runtime, memoria de AgentCore con ámbito de actor y una Puerta de AgentCore que utiliza autorización de AWS_IAM y expone solo los objetivos de herramientas aprobados. La celda también contiene claves de AWS KMS administradas por el cliente, etiquetas, alarmas, presupuestos y un enlace de origen de Access Manager de Observabilidad de CloudWatch (OAM). Una celda puede implementar, fallar, revertir o retirar sin coordinar con el lanzamiento de otro equipo.

Componentes clave

El siguiente diagrama ilustra el modelo de operación y el flujo gobernado de la solución.

Figura 1: Modelo de operación de la Plataforma de Agentic AI empresarial, que muestra la base de gobernanza, el plano de control de la Plataforma, las celdas de flujo de trabajo repetibles propiedad del equipo y los flujos de entrega de software, inferencia, herramientas, telemetría y propiedad entre ellos.

La arquitectura consiste en las siguientes capas de cuenta:

1. Fundamento de gestión y gobernanza. AWS Organizations, AWS IAM Identity Center, política preventiva, auditoría, retención y política de costos establecen el límite de la empresa. Estas son responsabilidades lógicas que pueden asignarse a una zona de aterrizaje de AWS Control Tower existente en lugar de requerir una estructura de cuenta duplicada.
2. Capa de seguridad, auditoría y observabilidad. AWS CloudTrail, AWS Config, AWS Security Hub, Amazon GuardDuty, archivo de registros y un sumidero de Amazon CloudWatch OAM proporcionan evidencia de control independiente y visibilidad de la flota. Los operadores centrales pueden consultar señales compartidas sin obtener acceso de escritura a los recursos de Workstream.
3. Capa de plataforma de Agentic AI Platform. Los entornos de plataforma separados poseen caminos dorados, el catálogo de gobernanza, Guardrails, puertas de inferencia compartidas, alias de herramientas exactas, pipelines, compatibilidad, cuotas y interfaces operativas comunes. Los cambios de plataforma se prueban contra celdas representativas antes de una implementación más amplia.
4. Capa de flota de Workstream. Cada producto, dominio o límite regulado recibe una o más celdas de no producción y producción. Los equipos poseen Runtime, Memoria, Puerta de herramientas, herramientas, datos, prompts, casos de evaluación, incidentes de aplicación y objetivos de nivel de servicio (SLO). La misma línea base puede repetirse en muchas celdas mientras se mantiene el aislamiento a nivel de cuenta.

Recorrido de la solución

Las siguientes secciones trazan las decisiones de diseño clave: topología de cuenta, controles preventivos y detectivos, el camino de ejecución de AgentCore y el pipeline de entrega.

Topología de cuenta y unidades organizativas

El plan define roles de cuenta lógicos que separan la gobernanza empresarial, los servicios de plataforma compartidos y la ejecución propiedad de los equipos:

Esta topología se integra en una zona de aterrizaje existente, un entorno de AWS multi-cuenta preconfigurado, seguro y escalable, donde las etiquetas de Administración, Plataforma y Flujo de trabajo describen responsabilidades en lugar de una finca de tres cuentas fija. Una organización puede operar múltiples entornos de Plataforma validados y muchos pares de cuentas de Flujo de trabajo. Comience con una celda representativa y pruebe la incorporación, promoción de producción, reversión, observabilidad centralizada y jubilación sin residuos antes de repetir la línea de base.

Políticas de control de servicio

Las políticas de control de servicio limitan los permisos máximos disponibles para las cuentas de Plataforma y Flujo de trabajo. Complementan, en lugar de reemplazar, IAM, autorización de puerta de enlace, Guardrails, políticas de recursos, controles de red y evidencia de pipeline. La plantilla renderiza y revisa las políticas efectivas para la cuenta y la Región exactas en lugar de confiar solo en la intención del código fuente.

1. Admisión de modelo y región: La política de organización y los roles de ejecución de Gateway restringen la inferencia a modelos aprobados y a la región compatible. Agregar un modelo o región requiere disponibilidad del servicio, residencia, IAM, calidad, costo, reversión, observabilidad y validación de denegación.
2. Aplicación de guardrail y cumplimiento de inferencia: Los agentes no llaman a los proveedores de modelos directamente. La inferencia cruza el gateway gobernado, donde se aplican la etapa Guardrail y la lista de modelos permitidos.
3. Mutación de Workstream solo a través de la canalización: Los equipos de Workstream abren solicitudes de extracción y utilizan la canalización de Workload. La implementación directa de desarrolladores en cuentas de Workstream está fuera del modelo de operación compatible, que mantiene la ruta de lanzamiento revisada y la evidencia no eludible.
4. Gobernanza de Registro y Gateway: La síntesis de Gateway de Workstream falla cuando un registro de Registro suscrito está ausente, ha cambiado o no está aprobado.
5. Roles de implementación con ámbito: Las políticas de arranque se generan por cuenta y región, se validan con AWS Identity and Access Management Access (IAM) Analyzer y se verifican a través de la simulación de política efectiva. El acceso de administrador se reserva para la configuración inicial en lugar de la ejecución rutinaria de la canalización.
6. Separación de deberes y prueba adversaria: Los controles de plataforma controlan el modelo, Guardrail, Registro y admisión de servicios compartidos. Los equipos de Workstream controlan el comportamiento de la aplicación. Cada ruta denegada se empareja con una llamada positiva autorizada y una mutación que prueba que el control pretendido causó la denegación.

Un administrador dentro de una cuenta de Workstream no puede crear un camino rápido compatible que evite estos controles. Las nuevas políticas de organización o las cambiadas necesitan un entorno de sandbox o una prueba de representative-cell, pruebas exactas de permitir y denegar, y un plan de reversión antes de la conexión generalizada.

Canalización CI/CD con puertas de evaluación

La plantilla utiliza canalizaciones de plataforma y Workload revisadas para aplicar la siguiente secuencia de promoción:

1. Fuente y revisión: Una solicitud de extracción establece la revisión de fuente inmutable. La pipeline fija la rama destinada para que un cambio no fusionado no pueda compilar silenciosamente la rama predeterminada del repositorio.
2. Compilación y síntesis: La pipeline compila el código, ejecuta pruebas y linting, crea el manifiesto del agente, escanea la imagen vinculada al resumen, valida las políticas, resuelve los descriptores de Registro aprobados e inspecciona la salida sintetizada de AWS CloudFormation y cdk-nag.
3. Roles estables y entrega de permisos: La pipeline de Workload crea roles de Workstream estables y pausas. La pipeline de Platform otorga alias de herramientas exactas al rol de Gateway exacto, se verifican las políticas en vivo y solo entonces continúa la pipeline de Workload.
4. Implementación en no producción: La pipeline implementa Runtime, Memoria, Gateway de herramientas, observabilidad, alarmas, presupuestos, etiquetas y recursos de aplicación en el límite de no producción de la celda.
5. Evaluación del agente implementado: La puerta invoca el Runtime real y mide la regresión, la calidad, el éxito de la herramienta, el comportamiento de rechazo, la latencia del primer token y el costo. Cada llamada autorizada se empareja con un gemelo adversario: la puerta llama a un modelo aprobado y confirma el éxito, luego llama a un modelo no aprobado y confirma el rechazo. El mismo patrón se aplica a herramientas, identidad entre cuentas y limitación. Si falta un rechazo esperado, la puerta falla la compilación.
6. Aprobación humana: Un revisor examina la evidencia implementada, las limitaciones conocidas y el riesgo residual. Una compilación verde genérica no es suficiente cuando falta una sonda, un recurso o un rechazo esperado requerido.
7. Promoción, observación y reversión: La promoción a producción utiliza la revisión revisada y las comprobaciones de continuidad. Las sesiones de Runtime se muestran mediante actualización, cancelación, reversión, restauración y nueva ejecución para que la pipeline pruebe tanto el camino hacia adelante como el camino de recuperación.

Ningún paso de implementación de Workstream tiene una vía rápida manual. El equipo de Platform es el propietario del contrato de lanzamiento, pero los equipos de Workstream operan sus propias instancias de pipeline y cadencia de implementación. El retiro sigue un orden de dependencia estricto: primero se revocan las concesiones de alias de Platform, luego los roles de Gateway y herramientas de Workstream, luego Runtime, Memoria y recursos de aplicación. Cada paso se verifica antes de proceder y un inventario final confirma que no quedan recursos residuales.

Seguridad y gobernanza

El modelo de diseño implementa la defensa en profundidad a través del refuerzo de los controles de identidad, política, entrega, datos y evidencia:

1. Identidad y límites de confianza: AgentCore Identity, una capacidad de Amazon Bedrock AgentCore, y Amazon Cognito proporcionan credenciales de inferencia de vida corta. AWS_IAM y SigV4 autenticán el tráfico de herramientas. Los roles de Exact Runtime y Gateway, las comprobaciones de emisor y audiencia, el contexto de cuenta y región, y la confianza de arranque limitada limitan a cada principal a su ruta prevista.
2. Seguridad y admisión del modelo: El flujo de inferencia pasa por la puerta de enlace gobernada descrita en la visión general de la solución, aplicando Guardrails y listas de permitidos de modelos antes de cada llamada.
3. Autorización de herramientas: La puerta de enlace de herramientas invoca solo alias aprobados por el Registro, como se detalla en la visión general de la solución. Las políticas de Cedar proporcionan autorización, con un wrapper de AWS Lambda retenido para defensa en profundidad.
4. Protección de datos de inquilino: Las cuentas de Workstream aíslan el estado de la aplicación. La memoria de AgentCore utiliza espacios de nombres con ámbito de actor y claves de KMS administradas por el cliente. Las herramientas y los datos de la aplicación siguen siendo propiedad del equipo, y las políticas de retención, eliminación y acceso son explícitas en lugar de heredadas de una cuenta de carga de trabajo mutable compartida.
5. Cadena de suministro de software y lanzamiento: El código fuente revisado, el hash de manifiesto, las compilaciones reproducibles, el análisis de imágenes con digestión, la validación de políticas, las comprobaciones de cdk-nag, la evaluación de tiempo de ejecución implementado, la aprobación humana, el despliegue y el desmontaje ordenado por dependencias forman un contrato de lanzamiento. Una comprobación que falta cierra el lanzamiento.
6. Auditoría, observabilidad y gobernanza de costos: CloudTrail y los datos del plano de control retenidos corroboran la evidencia de la canalización. OAM comparte registros, métricas y trazas con los operadores centrales. Las etiquetas de asignación estándar, los presupuestos, las cuotas y la reconciliación del informe de costos y uso de AWS asignan la propiedad sin dar al agente permiso para reescribir su propia atribución.

El repositorio es una implementación de referencia. Los desarrolladores pueden ajustarlo para satisfacer sus necesidades. La implementación y las características disponibles se basan en la región eu-west-1 (Irlanda). Un componente sustituido, otra región o una implementación organizacional más amplia requiere su propia evidencia de disponibilidad, seguridad, carga, despliegue, observabilidad y desmontaje.

Conclusión

En este artículo, analizamos una plataforma de Agentic AI empresarial construida sobre Amazon Bedrock AgentCore. La arquitectura separa un plano de control de plataforma centralmente gobernado de células de Workstream propiedad de equipos, con puertas de enlace de inferencia y herramientas distintas, y la promoción de producción limitada por la evaluación de tiempo de ejecución implementado.

El repositorio companion incluye una plantilla que valida estos controles de extremo a extremo, desde las puertas de la canalización y las pruebas de límites adversarios hasta el desmontaje residual cero. La reclamación de soporte se detiene en ese límite probado.

Para comenzar, implemente una célula representativa de Workstream del repositorio companion, pruebe su ciclo de vida completo y luego automatice células adicionales desde la misma línea de base versionada.

Recursos relacionados:

1. Enterprise Agentic AI Platform Blueprint en GitHub
2. Arquitectura de cuentas múltiples de empresa para ejecutar agentic AI en producción en AWS (Prescriptive Guidance)
3. Construyendo una plataforma de Agentic AI de empresa en Amazon Bedrock AgentCore Workshop
4. Documentación de Amazon Bedrock AgentCore

Acerca de los autores