Agentes de IA con Bedrock AgentCore: arquitectura y uso

Para poner agentes de IA en producción, vale la pena probar Amazon Bedrock AgentCore cuando el agente ya funciona, pero la infraestructura que lo rodea empieza a convertirse en un segundo producto. El catálogo actual de AWS reúne 13 servicios y capacidades modulares. Adopta los que resuelvan una carga operativa concreta y conserva la responsabilidad sobre lo que hace tu agente en el negocio.

Información verificada en la página del producto y la documentación de AWS el 30 de octubre de 2026. El inventario de componentes que sigue procede de la descripción general para desarrolladores, enlazada desde la página de AgentCore. El análisis de qué trabajo puede sustituir cada componente es propio de este artículo.

¿Qué aporta Amazon Bedrock AgentCore a los agentes de IA?

AgentCore permite delegar en AWS determinadas tareas necesarias para operar agentes en producción. Un agente es un programa que usa un modelo para elegir acciones, llamar a herramientas y avanzar hacia la resolución de una tarea. Conseguir que ese ciclo responda en un entorno local todavía deja mucho trabajo por hacer: identidad, ejecución, estado, control de acceso y depuración.

Imagina una sala de conciertos. El comportamiento de tu agente es la actuación. Runtime aporta el escenario y la infraestructura de apoyo; los controles de acceso regulan las entradas; la memoria conserva el contexto útil, y la observabilidad registra lo ocurrido. Tú sigues decidiendo qué debe conseguir la actuación y si lo ha logrado.

AWS presenta AgentCore con una promesa explícita: «Cualquier framework. Cualquier modelo». Su página de producto menciona LangChain, OpenAI Agents SDK, Claude Agent SDK, Strands SDK y los frameworks propios. Ese es el alcance que AWS declara para la plataforma; no garantiza que todas las capacidades opcionales tengan las mismas integraciones ni que migrar no requiera trabajo. Descripción del producto de AWS.

También hay distintas opciones según quién se encargue del ciclo del agente. Con Runtime, despliegas tu propio código. Con Harness, defines el agente mediante configuración y utilizas el ciclo gestionado de AWS, basado en Strands Agents, su framework de código abierto para agentes. La documentación de Harness deja clara esta diferencia. Si un responsable de ingeniería ya cuenta con código de orquestación que funciona, conviene que evalúe primero la vía de Runtime.

Bedrock Agents y AgentCore: ¿cuál conviene usar?

Tener un despliegue de Amazon Bedrock Agents no obliga a migrar por el simple hecho de que exista AgentCore. AWS indica que los usuarios actuales de Bedrock Agents pueden seguir utilizándolo. Tiene sentido evaluar AgentCore cuando necesitas alguna de sus capacidades concretas de ejecución, integración u operación. Preguntas frecuentes de AWS.

La distinción útil ya no se limita a «ciclo gestionado frente a infraestructura»: AgentCore también ofrece un ciclo gestionado a través de Harness. Decide primero si quieres mantener el control del código de orquestación y elige la vía que corresponda. Apóyate en el mapa de arquitectura de agentes de IA para que una decisión de alojamiento no termine rediseñando toda la aplicación sin haberlo previsto.

Componentes de Bedrock AgentCore: qué trabajo sustituye cada uno

Elige los componentes según el trabajo que, de otro modo, tendrías que desarrollar y operar. AWS los documenta como capacidades modulares que pueden funcionar juntas o por separado. La última columna recoge las responsabilidades que debe conservar la aplicación, aunque AWS proporcione el servicio de apoyo.

Un asistente de soporte podría necesitar Runtime, Gateway e Identity desde el principio, y añadir Memory cuando resulte útil conservar el contexto de los usuarios que regresan. Payments no aporta nada si el asistente nunca compra acceso a recursos externos. Registry cobra sentido cuando encontrar recursos aprobados dentro de la organización se convierte en un problema. Adoptar más componentes no es un objetivo en sí mismo.

Code Interpreter y Runtime resuelven necesidades distintas. Runtime aloja el agente; Code Interpreter proporciona un entorno aislado para el código que este ejecuta. Si solo te falta aislar la ejecución de código, compara las opciones con la guía de entornos aislados para código de agentes de IA antes de trasladar la orquestación.

Las decisiones de arquitectura que siguen a tu cargo

Hay que delimitar qué infraestructura se delega y qué autoridad conserva la aplicación. En un flujo de soporte ilustrativo, el agente podría consultar un pedido, explicar su estado y proponer una acción. AWS puede aportar la infraestructura de ejecución y acceso, pero tu aplicación debe determinar a quién pertenece el pedido y si esa acción está permitida.

Bedrock AgentCore Runtime: el aislamiento no determina a quién pertenece una sesión

Runtime puede aislar la ejecución sin saber a qué cliente pertenece una sesión. AWS documenta entornos microVM dedicados para las sesiones, con recursos de cómputo, memoria y sistema de archivos separados. Esa misma documentación aclara que AgentCore no impone la correspondencia entre sesiones y usuarios: el backend de tu aplicación cliente debe mantener esa relación. Sesiones de Runtime.

En el asistente de soporte, un identificador de sesión enviado por el navegador no basta para demostrar que la sesión pertenece al cliente. Autentica la solicitud, determina en el backend qué sesión puede utilizar y limita los accesos posteriores a los datos de ese cliente. El aislamiento de la infraestructura y la decisión de autorización de la aplicación son responsabilidades distintas.

Bedrock AgentCore Memory: decide qué contexto merece conservarse

Memory sustituye la infraestructura de gestión del contexto, pero tú decides qué guardar. AWS admite tanto contexto de conversación a corto plazo como información a largo plazo que se conserva entre sesiones. Documentación de Memory.

Recordar que un cliente prefiere respuestas breves no equivale a guardar el saldo oficial de un pedido. Los registros de negocio de tu aplicación deben seguir siendo la fuente de referencia. Decide cómo obtiene el agente los datos actualizados, qué información de las conversaciones puede conservar y qué ocurre cuando una preferencia recordada deja de ser correcta. Un servicio de memoria no toma esas decisiones de diseño de datos por ti.

Bedrock AgentCore y MCP: Gateway conecta las herramientas

Gateway resulta útil cuando conectar herramientas se ha convertido en un trabajo repetitivo de ingeniería. Model Context Protocol, o MCP, es una interfaz común para ofrecer herramientas a los agentes. Gateway puede convertir API y funciones de AWS Lambda en herramientas compatibles con MCP y conectarse a servidores MCP existentes. Su documentación actual también contempla el enrutamiento hacia otros agentes y modelos. Documentación de Gateway.

Para un asistente de pedidos, empieza por ofrecer una operación acotada, como consultar el estado de una entrega, antes de habilitar una herramienta de consultas generales a la base de datos. Gateway puede transmitir la llamada; tu API sigue definiendo qué significa la operación, a qué registros puede acceder y si un reintento podría repetir un efecto secundario.

Bedrock AgentCore Identity: las credenciales necesitan reglas de negocio

Identity gestiona quién actúa y qué credenciales utiliza; Policy controla las acciones permitidas en Gateway. Identity proporciona identidad para las cargas de trabajo y gestión de credenciales para acceder a recursos de AWS y servicios de terceros, incluso en nombre de un usuario. Documentación de Identity.

Policy evalúa el tráfico que pasa por un AgentCore Gateway asociado antes de permitir el acceso a las herramientas. Ese límite importa: no des por hecho que una política de Gateway controla una llamada de red directa que el agente pueda realizar por otra vía. Haz pasar las operaciones sensibles por el punto de control previsto y restringe las rutas que permitan evitarlo. Documentación de Policy.

Una identidad de soporte al cliente puede tener permiso para consultar un pedido y, al mismo tiempo, tener prohibido emitir un reembolso. Las instrucciones del modelo deben describir ese flujo; las capas de herramientas y autorización deben hacer cumplir los permisos.

Bedrock AgentCore Observability: una traza muestra qué pasó, no si estuvo bien

Observability ayuda a reconstruir el comportamiento; Evaluations ayuda a valorarlo. AgentCore ofrece vistas de ejecución y telemetría compatible con OpenTelemetry, un formato estándar para trazas y métricas, con paneles basados en Amazon CloudWatch. AWS distingue entre las métricas integradas y las trazas y metadatos de negocio adicionales que debes instrumentar en tu aplicación. Documentación de Observability.

En el asistente de soporte, registra si se completó la consulta del pedido solicitado y si se autorizó una acción. Una llamada a una herramienta puede ejecutarse correctamente desde el punto de vista técnico y aun así responder a la pregunta de negocio equivocada.

Evaluations ofrece evaluaciones integradas y personalizadas, incluidas las realizadas por modelos que actúan como evaluadores. Define tus propios casos representativos y revisa los fallos con consecuencias relevantes. La documentación de evaluación especifica los frameworks y las opciones de instrumentación compatibles. Comprueba la vía que hayas elegido, sin extender la compatibilidad general de la plataforma a todas sus funciones.

Los límites que condicionan el diseño

Separa la duración de los recursos de cómputo del tiempo que necesitas conservar el estado útil. La documentación actual de AWS sobre el ciclo de vida establece un tiempo de espera por inactividad predeterminado de 15 minutos y una duración máxima del cómputo de la microVM de 8 horas. Instances, la alternativa que ejecuta capacidad gestionada de Amazon Elastic Compute Cloud en tu cuenta, permite configurar una duración de hasta 14 días, según los ajustes de su proveedor de capacidad. Ajustes del ciclo de vida, Instances.

Una sesión lógica puede reanudarse sobre recursos de cómputo recién aprovisionados. Por defecto, el estado en memoria y en el sistema de archivos local depende del ciclo de vida de esos recursos. Si configuras el almacenamiento de sesión, los datos del sistema de archivos pueden conservarse entre paradas y reanudaciones. Define expresamente qué debe sobrevivir a una interrupción. Ciclo de vida y almacenamiento de las sesiones.

Antes de decidir qué capacidades adoptar, consulta la matriz de funciones por región de AWS. Que algo esté «disponible en AWS» no basta si tu aplicación depende de una región concreta.

¿Cuándo vale la pena usar AgentCore?

Da el paso cuando una carencia operativa concreta esté frenando la entrega y el componente gestionado correspondiente cumpla tus requisitos. Valora el aislamiento de la ejecución, el acceso autorizado a herramientas, la conservación del estado, la capacidad de diagnosticar problemas y la carga de operar todo ello por tu cuenta.

Para quienes desarrollan, conviene iniciar un piloto cuando la lógica del agente ya funciona, pero faltan el alojamiento o la integración de herramientas. Mantener el ciclo existente en Runtime permite acotar más la prueba que cambiar a la vez el framework y la plataforma de despliegue.

Para quienes operan los sistemas, el argumento gana peso cuando todos los agentes necesitan la misma gestión de credenciales, los mismos controles de acceso y la misma investigación de incidentes. Elige un flujo que permita demostrar esas responsabilidades, incluido un fallo que necesites diagnosticar.

Para quienes deciden las compras tecnológicas, la pregunta es qué trabajo recurrente desaparece y qué nuevas tareas de integración quedan pendientes. La configuración de AWS, el diseño de permisos, el comportamiento de la aplicación y la respuesta de guardia siguen necesitando responsables concretos.

Espera si tu infraestructura ya ofrece los controles necesarios y no hay un problema concreto que resolver. La migración necesitaría otro motivo, como una capacidad que tu infraestructura no pueda proporcionar. Sigue como estás si el flujo consiste en una secuencia fija de operaciones conocidas y no necesita que un agente elija la siguiente acción.

Si el gasto determina la decisión, consulta los precios de AgentCore en AWS junto con la guía de precios de Amazon Bedrock de este sitio.

Un primer piloto con la CLI de AWS

Empieza con la plantilla de AWS basada en código y añade después una operación representativa del negocio. Este recorrido sigue la guía de inicio rápido de Runtime y la guía completa de la CLI actuales. El procedimiento procede de la documentación; no se ha probado un despliegue para este artículo.

La guía completa exige Node.js 20.12 o posterior, npm, Python 3.10 o posterior, el gestor de dependencias de Python uv, credenciales de AWS configuradas, permisos de despliegue y acceso al modelo. Esta plantilla utiliza CodeZip, por lo que no hace falta Docker.

1. 1

   Instala y crea el proyecto

   Utiliza una cuenta o un entorno de desarrollo de AWS.

   npm install -g @aws/agentcore
   agentcore --version
   agentcore create --name MyProject --template agent-python-strands

   La plantilla incluye un Runtime llamado agent y un recurso de AgentCore Memory. Revisa ambos en la configuración generada.

2. 2

   Prueba en local

   cd MyProject
   agentcore dev --mode browser

   Prueba el agente en el inspector local y detén el servidor antes de continuar en la misma terminal.

3. 3

   Compila, despliega e invoca

   agentcore build
   agentcore deploy
   agentcore status
   agentcore invoke --runtime agent --payload '{"prompt":"Hello, what can you do?"}'

   El despliegue aprovisiona los recursos de AWS mediante AWS Cloud Development Kit, o CDK.

4. 4

   Inspecciona y elimina los recursos

   agentcore logs runtime
   agentcore traces runtime list

   Desde el directorio de este proyecto piloto, estos comandos eliminan sus recursos y desmantelan la pila desplegada:

   agentcore remove all --yes
   agentcore deploy --yes

Antes de incorporar tráfico de producción, sustituye el saludo por una tarea acotada, como consultar un pedido de prueba. Los criterios de aceptación recomendados dependen de la aplicación: recibir los datos correctos, rechazar accesos no autorizados, poder ver en la traza una llamada fallida a una herramienta y entender cómo se recupera el sistema tras una interrupción. Son criterios para decidir sobre tu piloto, no afirmaciones de AWS sobre rendimiento.

Las promesas que conviene poner en perspectiva

La ejecución gestionada no demuestra que un agente tome decisiones de negocio correctas. El alojamiento, las trazas, la evaluación y la aplicación de políticas resuelven problemas distintos. Ninguno te exime de elegir una tarea útil, definir las acciones aceptables y examinar los fallos.

«Cualquier framework» tampoco significa «sin trabajo de integración». La flexibilidad de la plataforma deja en tus manos la validación de dependencias, autenticación, instrumentación y contratos de cada servicio que adoptes.

Por último, adoptar todos los componentes no demuestra que el sistema esté listo para producción. Un asistente de soporte de solo lectura no mejora por obtener autorización para pagar o un navegador que no necesita. Añade capacidades cuando una tarea concreta las requiera e incluye la ampliación de permisos en la revisión.

Por dónde empezar el lunes

Elige una tarea que ya realice un agente y anota qué responsabilidad operativa está retrasando su avance. Prueba únicamente las capacidades de AgentCore necesarias para resolver ese retraso. Compara el despliegue resultante, la gestión de fallos y la carga de responsabilidades con tu infraestructura actual. Amplía la adopción cuando los resultados justifiquen el cambio.

Recibe en la newsletter guías prácticas para crear y operar sistemas de IA.