Inicio / Artículos

Práctica con Bedrock AgentCore: Terraform, LangGraph y los problemas encontrados

Qué hacen Runtime, Gateway, Memory e Identity de AgentCore, además de seis problemas comunes en la implementación, un precio aproximado y una comparación con el alojamiento de agentes desarrollados manualmente en AWS.

Editor: REACTAPP.TOP9 min de lectura2141 palabras

Fuentes: Amazon Bedrock AgentCore, What It Is, How to Use It, and What Hosting Looks Like

Alojar un agente de IA en AWS de forma manual implica resolver por uno mismo problemas como el aislamiento de sesiones, el acceso a herramientas, la gestión de memoria y la autenticación. Amazon Bedrock AgentCore es la versión gestionada de ese mismo problema, disponible desde octubre de 2025. Una forma práctica de evaluar una plataforma como esta es dejar de leer sobre ella y crear algo real; un pequeño agente de triaje DevOps de solo lectura sirvió para ese propósito aquí. Fue desplegado con Terraform en lugar del asistente CLI de AWS, y escrito con LangGraph en vez del SDK Strands de AWS. Ambas elecciones fueron intencionadas, ya que el objetivo era averiguar qué funciona cuando no se sigue el camino trazado.

Qué es AgentCore

AgentCore es un conjunto de componentes gestionados que se encargan de las tareas tediosas y esenciales para ejecutar un agente en entornos de producción, permitiendo que cualquier framework de agentes existente siga funcionando sin cambios. La promesa principal es la compatibilidad con cualquier framework, y en su mayor parte se cumple: LangGraph, LangChain, CrewAI, Strands y llamadas API simples son todos aceptados.

Los componentes y su función respectiva:

  • Runtime alberga el código del agente y proporciona a cada sesión una microVM aislada propia. Escala a cero cuando no hay actividad y se cobra por segundo mientras está en uso.
  • Gateway convierte las funciones Lambda o APIs existentes en herramientas compatibles con MCP que puede utilizar un agente, por lo que no se necesita un servidor MCP escrito a mano.
  • Memory almacena el historial de conversaciones como eventos a corto plazo y, opcionalmente, puede extraer conocimiento semántico a largo plazo entre sesiones.
  • La identidad abarca dos direcciones de autenticación: quién puede llamar al agente y qué puede hacer el agente en nombre de un usuario, incluidos servicios de terceros como Slack o GitHub.
  • La observabilidad envía rastros de OpenTelemetry a CloudWatch para que quede un registro de lo que hizo el agente y por qué.
  • Una herramienta para navegadores y una herramienta para intérprete de código sirven a los agentes que deben actuar en la web abierta o ejecutar código arbitrario.
  • Un anuncio en la cumbre AWS de junio de 2026 incluyó una capa de Harness y una búsqueda web nativa. Ambas son aún lo suficientemente nuevas como para que la infraestructura crítica no deba depender de ellas por el momento.

    El proceso de incorporación ya ha sido reconstruido una vez. La CLI original de Starter Toolkit ahora es obsoleta y ha sido reemplazada por un paquete npm basado en CDK llamado @aws/agentcore. Un tutorial que muestra cómo configurar y ejecutar agentcore como pasos separados describe el flujo anterior. Este detalle es importante porque indica el ritmo de los cambios: nueve meses después de su disponibilidad general, el proceso de inicio ya ha sido modificado, por lo que todo lo escrito sobre el producto tiene una vida útil limitada.

    El proyecto de prueba

    El agente responde a preguntas como si hay alarmas de CloudWatch activas o cuál es el estado de una instancia EC2 específica. Cuenta con dos herramientas reales de solo lectura, por lo que nada de lo que puede utilizar permite modificar la infraestructura, solo observarla. Recuerda la conversación a lo largo de las interacciones, y cada transición entre componentes está autenticada.

    Se eligió LangGraph en lugar de Strands porque Strands es el propio framework de AWS y permite seguir el camino más sencillo a través de cada ejemplo oficial. Utilizar otro framework fue la verdadera prueba de la afirmación de que cualquier framework sirve, y resultó ser compatible con las herramientas ya disponibles. Por razones similares, se eligió Terraform en lugar de la CLI: el asistente está diseñado para ejecutar una demostración rápidamente, y el objetivo aquí era ver todas las relaciones de confianza IAM y todas las conexiones entre componentes, en lugar de que se generaran de forma invisible. Esa visibilidad resultó ser más importante de lo esperado.

    La arquitectura consiste en un contenedor de tiempo de ejecución que runea el agente LangGraph, el cual se comunica con una pasarela que expone dos herramientas basadas en Lambda a través de MCP. AgentCore Memory almacena la conversación, mientras que Cognito emite tokens máquina-a-máquina para cada paso del proceso.

    Haga clic antes de escribir scripts

    Antes de que se escribiera cualquier código Terraform, se probó una vez la versión en consola de la configuración, principalmente para ver qué se estaba automatizando. Es una costumbre que vale la pena mantener incluso cuando Terraform se encarga del despliegue real, ya que leer los archivos de infraestructura resulta mucho más sencillo después de haber visto los formularios que llenan.

    El registro de contenedores merece un proceso manual, independientemente de la herramienta que se utilice para el resto, ya que es ese paso el que Terraform no puede realizar. Crear el repositorio ocurre en una sola pantalla de la consola. Sin embargo, la imagen debe llegar por otro medio, ya que la consola no cuenta con un botón para generar un Dockerfile. Eso se hace en una terminal mediante el comando docker buildx build para la plataforma linux/arm64, seguido de un push. El nombre de la plataforma se establece a mano; si no se indica, la imagen se compila sin problemas, pero luego es rechazada silenciosamente cuando Runtime intenta iniciarla, porque Runtime solo funciona en Graviton.

    Una vez que la imagen está lista, la consola muestra su URI exacto. Esa cadena es el único dato de estado que debe transferirse desde el proceso manual a lo que Terraform conoce, ya sea mediante un archivo tfvars o al campo de la imagen del contenedor de Runtime para quienes trabajan desde la consola.

    Las pantallas de AgentCore para Memory, Gateway y Runtime se encuentran en su propia sección de la consola de Bedrock. Cada una es un formulario con los mismos campos que establece Terraform, lo cual tiene sentido ya que Terraform utiliza la misma API en el fondo.

    • Memory solicita un nombre y por cuánto tiempo se deben conservar los eventos a corto plazo.
    • Gateway pide un protocolo, un rol de ejecución y un método para autenticar a los solicitantes. El problema relacionado con Cognito entre audience y client-id, descrito más abajo, aparece aquí mismo en forma de menú desplegable que obliga a elegir una opción.
    • Runtime solicita la URI del registro, un rol y la misma configuración de autorización que Gateway.

    Nada de esto resulta difícil una vez que tienes los formularios frente a ti. Terraform sigue siendo la mejor opción para cualquier cosa que deba durar, porque tener que pasar por siete formularios en tres secciones de la consola no es un proceso de despliegue que nadie quiera repetir o delegar a un colega.

    Where it bit

    Images must be ARM64

    Runtime is Graviton-only, with no exceptions. A plain docker build on most laptops yields an amd64 image that is silently refused at deploy time. Every build needs the buildx command with the arm64 platform flag. A comment directly above the FROM line in the Dockerfile is a cheap safeguard, because it will be forgotten otherwise.

    The Gateway's Lambda contract

    Varios artículos de blog muestran un evento Lambda envuelto en un sobre que contiene un toolName y parámetros. El evento real son las propiedades de entrada de la herramienta en forma de un diccionario plano. El nombre real de la herramienta se obtiene a través de context.client_context.custom bajo la clave bedrockAgentCoreToolName, precedido por el nombre del destino de la pasarela y un delimitador de tres guiones bajos. La discrepancia solo se hizo evidente al leer directamente la documentación oficial de Lambda de AWS en lugar de confiar en resúmenes de terceros. Gran parte de lo que circula sobre este producto proviene del período de prueba o simplemente es incorrecto.

    Los tokens de Cognito carecen de la claim aud

    Este caso requirió tiempo real para ser resuelto. Al utilizar Cognito para la autenticación máquina a máquina, a través de un permiso client_credentials sin inicio de sesión humano, Cognito emite un token de acceso y no un token de identidad. Los tokens de acceso nunca contienen aud; solo lo hacen los tokens de identidad, y un flujo M2M no tiene token de identidad ya que no existe usuario al cual emitirlo. Es necesario configurar el autorizador JWT de AgentCore para verificar allowed_audience contra dicho token, lo que resulta en un error 403 sin motivo aparente. La solución es utilizar allowed_clients, que verifica el campo client_id que sí incluyen los tokens de acceso de Cognito.

    boto3 no puede invocar un Runtime protegido por JWT

    Esta fue la mayor sorpresa: no se trata de una solución temporal, sino de una instrucción presente en la propia referencia de API de AWS. Si el agente utiliza autenticación entrante al estilo OAuth, InvokeAgentRuntime no puede ser llamado en absoluto a través del AWS SDK. En su lugar, la solicitud se realiza mediante una petición HTTPS sin procesar, con un token de portador en el encabezado Authorization, enviada a una URL creada manualmente con el ARN del entorno de ejecución codificado en porcentajes dentro de la ruta. Todos los ejemplos de boto3 asumen la ruta IAM y SigV4 predeterminada. Una vez que se configura un custom_jwt_authorizer, como es necesario para cualquier sistema que no sea puramente interno, toda esa categoría de ejemplos deja de ser aplicable.

    Conflicto con un paquete de Python

    El paquete mcp para Python lanzó una versión principal 2.0.0 que cambia los nombres de los módulos internos, mientras que langchain-mcp-adapters aún no se ha actualizado. Este último declara compatibilidad con mcp a partir de la versión 1.24.0 sin establecer un límite superior, por lo que un simple pip install ahora genera una combinación infuncional. Al menos produce un error evidente al importar, en lugar de un bug sutil. El proyecto de pruebas fija la versión de mcp en 1.29.0. Verifique si esa fijación sigue siendo necesaria, ya que los parches discretos pueden convertir una solución en un elemento innecesario.

    El despliegue implica más que solo una aplicación

    El recurso Runtime necesita una imagen de contenedor ya presente en el registro, y Terraform no puede compilar ni publicar una imagen dentro de su propio proceso de aplicación. La secuencia correcta es crear primero solo el repositorio del registro, compilar y publicar la imagen fuera de Terraform, y luego aplicar todo lo demás. Los ingenieros que trabajan con stacks AgentCore mucho más grandes han integrado CodeBuild en el grafo de Terraform mediante null_resource para resolver este problema. Ese es un paso lógico a seguir, y indica que el problema es generalizado y no se debe a un error personal.

    El estado de la conversación debe estar en un solo lugar

    No se trata de un error, sino de una elección estructural: el agente deliberadamente no utiliza el propio checkpointer de LangGraph para el estado de la conversación, aunque la mayoría de los tutoriales de LangGraph lo establecen como predeterminado. Las sesiones en tiempo real se reducen a cero y pueden pasar a una microVM nueva entre llamadas, por lo que todo lo almacenado únicamente en la memoria del proceso desaparece. La Memoria de AgentCore representa el lado duradero de ese límite. Ejecutar un checkpointer local junto a la Memoria genera dos registros competidores de la misma conversación, y tarde o temprano llegarán a discrepar sobre lo que se dijo. Elija uno. La Memoria es la opción más sensata porque sobrevive a un inicio en frío.

    Costo

    La tarificación se basa en el consumo sin mínimo, lo cual es adecuado para algo que pasa la mayor parte del tiempo esperando una respuesta de un LLM. La consecuencia es que la factura es la suma de varios elementos pequeños medidos por separado, y no un único número. A fecha de redacción:

    • Los costos de ejecución ascienden a aproximadamente 9 centavos por cada vCPU-hora y unos 1 centavo por cada GB-hora, midiéndose segundo a segundo con un mínimo de un segundo; por lo tanto, una consulta de tres segundos cuesta tres segundos y no un minuto redondeado hacia arriba.
    • El costo del gateway es de aproximadamente medio centavo por cada mil llamadas MCP.
    • La memoria tiene un precio de 0,25 centavos por cada 1.000 eventos almacenados y 0,5 centavos por cada 1.000 eventos recuperados.
    • No se aplica ningún costo a la identidad cuando se utiliza a través de Runtime o Gateway en lugar de ser llamada directamente, lo cual aplica a casi toda la configuración.

    Nada de eso incluye las llamadas al modelo, que para cualquier cosa más allá de pruebas simples representarán la mayor cantidad en la factura, y que AgentCore no puede influir. Eso es simplemente lo que Bedrock cobra por el modelo elegido. Las cuentas nuevas reciben doscientos dólares en créditos de AgentCore, suficientes para desarrollar y desmantelar un proyecto como este varias veces. Se debe consultar la página oficial de precios antes de confiar en cualquier cifra, ya que los precios han cambiado más de una vez desde su disponibilidad general y probablemente lo harán nuevamente.

    Plataforma gestionada o alojamiento personalizado

    Una pila de hosting para agentes construida a mano permite una comparación útil, y la conclusión honesta tiene dos aspectos. AgentCore ofrece aislamiento de sesiones, una pasarela MCP gestionada, memoria duradera y un modelo de autenticación diseñados para funcionar en conjunto, lo que resulta más rápido que crear manualmente las políticas de confianza IAM; aquí se invirtieron horas precisamente en esas políticas. Eso representa una gran cantidad de trabajo de infraestructura sin diferenciar que se elimina del equipo. Para quienes su tarea es desarrollar el agente y no la plataforma de hosting subyacente, probablemente valga la pena hacer este intercambio.

    Lo que la plataforma no ofrece es una evaluación sobre qué acciones debería permitirse a un agente, cuánto debería costar a escala real, o si algún marco implica automáticamente que el enfoque con la documentación más completa sea el de AWS. También falta estabilidad: la CLI ya ha sido reconstruida una vez, y se han detectado al menos tres casos en los que la documentación de AWS no coincidía con la API real de maneras pequeñas pero significativas. Nada de esto hace que el producto sea deficiente; simplemente refleja un servicio gestionado en pleno desarrollo que evoluciona rápidamente, algo que es mejor conocer antes de comenzar a usarlo que descubrirlo a mitad de un despliegue.

    Todo esto fue construido realmente, no solo descrito. Cada recurso cuenta con Terraform, el agente está completo, existen las herramientas de Lambda, y el conjunto de pruebas no requiere credenciales de AWS; por lo tanto, todo lo que podía verificarse se verificó primero. En un proceso de construcción similar, los lugares más probables donde surgirían los mismos problemas son la marca de plataforma ARM64 para la imagen y el parámetro allowed_clients en la configuración del autorizador Cognito.