AWS acelera el cómputo de sus agentes de IA con la nueva generación de AgentCore Runtime
Amazon Web Services publicó el 12 de noviembre de 2026 una actualización de la nueva generación de AgentCore Runtime, la capa de cómputo serverless de Amazon Bedrock AgentCore que se encarga de ejecutar agentes de inteligencia artificial en microVM. La compañía resume el cambio en tres cifras: sesiones que arrancan hasta 15 veces más rápido, hasta 4 veces más capacidad de cómputo y una eficiencia hasta un 68 % superior. Detrás de esos titulares hay decisiones de arquitectura que afectan directamente a los equipos que llevan agentes a producción: cada sesión vive en su propia máquina virtual aislada por hardware, los arranques se mantienen por debajo de los 2 segundos sin importar el tamaño de la imagen, la memoria se devuelve cuando el agente deja de usarla y aparece una segunda forma de pago pensada para agentes que nunca se apagan.
El anuncio no llega de la nada. La versión que AWS denomina V2 entró en disponibilidad general el 18 de septiembre de 2026, y lo publicado ahora amplía y consolida aquel lanzamiento con nuevas capacidades, testimonios de clientes y un modelo de facturación adicional. Para quien diseña plataformas de agentes, la pregunta ya no es si un agente puede ejecutarse en la nube, sino cuánto cuesta mantenerlo esperando, qué tan rápido responde la primera vez y qué garantías de aislamiento ofrece cuando atiende a miles de usuarios distintos. Este artículo repasa qué cambia, qué datos aporta AWS, qué aspectos quedan pendientes y cómo evaluar la migración.
De qué hablamos cuando hablamos de AgentCore Runtime
Amazon Bedrock AgentCore es el conjunto de servicios con el que AWS intenta resolver la parte menos vistosa de los agentes de IA: la infraestructura. Un agente no es solo un modelo de lenguaje; es un proceso que mantiene estado durante una conversación, llama a herramientas, ejecuta código, consulta datos y, a menudo, se queda esperando la respuesta de un usuario o de un servicio externo. Quien haya leído sobre cómo funcionan los agentes de IA más allá del modelo sabe que el bucle de razonamiento, la memoria y el uso de herramientas pesan tanto como la calidad del modelo en el resultado final.
Dentro de ese conjunto, AgentCore Runtime es el componente que proporciona el cómputo. El desarrollador empaqueta su agente en una imagen de contenedor, lo registra como runtime y la plataforma se encarga de levantar una sesión cada vez que hace falta, aislarla, escalarla y destruirla al terminar. No hay servidores que administrar ni clústeres que dimensionar, una propuesta que recuerda a la de AWS Lambda pero adaptada a cargas mucho más largas e impredecibles que una función que responde en milisegundos.
La primera versión del runtime, que AWS mantiene como valor por defecto, ya ejecutaba los agentes en microVM. La novedad de la segunda generación está en cómo se preparan esas máquinas, cuánto tardan en estar disponibles, cuántos recursos pueden usar y cómo se cobra por ellos.
Una microVM Firecracker para cada sesión
El pilar de seguridad del servicio es el aislamiento. En la nueva generación, cada sesión de un agente se ejecuta en su propia microVM Firecracker, aislada a nivel de hardware, con su propia identidad, su propia política de acceso y su propio registro de auditoría. Firecracker es la tecnología de virtualización ligera que AWS presentó y liberó como código abierto en noviembre de 2018 bajo licencia Apache 2.0. Está escrita en Rust, se apoya en KVM, el hipervisor integrado en el kernel de Linux, y es la misma pieza que AWS utiliza para ejecutar servicios como Lambda y Fargate.
La elección importa porque los agentes plantean un problema de seguridad distinto al de una aplicación web convencional. Un agente puede ejecutar código generado por un modelo, descargar archivos, navegar por sitios externos o manipular datos sensibles de un cliente concreto. Si dos sesiones de usuarios diferentes compartieran proceso, sistema de archivos o memoria, un error de programación o una inyección de instrucciones en una de ellas podría filtrar información a la otra. Al dar a cada sesión una máquina virtual propia, la frontera de aislamiento deja de depender de la disciplina del código del agente y pasa a estar garantizada por la virtualización.
El hecho de que cada sesión tenga identidad y política de acceso individuales también simplifica la gobernanza. Los equipos de seguridad pueden razonar sobre qué puede hacer una sesión concreta y revisar qué hizo en su registro de auditoría, algo que en arquitecturas multiinquilino compartidas suele requerir capas adicionales de etiquetado y correlación de logs. Para organizaciones reguladas, como las del sector financiero, sanitario o de servicios profesionales, este diseño de aislamiento por sesión con microVM es probablemente el argumento más relevante del anuncio, incluso por encima de la velocidad.
Cómo consigue arrancar en menos de 2 segundos
El tiempo de arranque en frío ha sido históricamente el talón de Aquiles de las plataformas serverless. Con contenedores pequeños el problema es manejable, pero los agentes modernos suelen cargar dependencias pesadas: SDK de varios proveedores, librerías de procesamiento de documentos, navegadores sin interfaz, intérpretes de código o modelos auxiliares. Las imágenes de varios gigabytes son habituales, y cada segundo de arranque se traduce en un usuario mirando una pantalla vacía.
AWS asegura que la nueva generación arranca sesiones en menos de 2 segundos con independencia del tamaño de la imagen y del nivel de concurrencia, y que lo hace sin recurrir a pools de instancias calientes ni a clústeres preaprovisionados. En las mediciones que la compañía publicó en septiembre, el percentil 75 del arranque en frío se situó entre 1,9 y 2,0 segundos para imágenes de contenedor de entre 200 MB y 2 GB, frente a un rango de 5,4 a 30 segundos con la primera versión. Esos datos ayudan a entender la cifra de hasta 15 veces más rápido: la mejora es modesta con imágenes pequeñas y mucho mayor con las grandes.
La técnica que lo hace posible es el uso de snapshots. Cuando se crea o actualiza un runtime V2, la plataforma prepara el entorno una sola vez: descarga la imagen, carga los artefactos, ejecuta la inicialización y deja el agente listo para recibir peticiones. En ese punto toma una instantánea del estado de la máquina. A partir de entonces, cada nueva sesión no repite ese proceso, sino que se restaura desde la instantánea, lo que elimina la carga de artefactos y la configuración que antes se pagaban en cada arranque.
El enfoque tiene un precio que se paga en otro momento. Crear o actualizar un runtime V2 tarda varios minutos, porque es entonces cuando se construye la instantánea. Además, el contenedor debe responder como sano en su endpoint de comprobación /ping en un máximo de 120 segundos; si la inicialización del agente es más lenta, la preparación no se completará. Es un intercambio razonable para producción, donde los despliegues son relativamente poco frecuentes y los arranques de sesión ocurren constantemente, pero conviene tenerlo presente en los flujos de integración continua y en los ciclos de prueba de los desarrolladores.
Más cómputo por sesión
La segunda gran cifra del anuncio es la capacidad. Cada sesión puede disponer ahora de hasta 8 vCPU y 32 GB de memoria, y las imágenes de contenedor pueden alcanzar los 10 GB. AWS lo presenta como cuatro veces el cómputo disponible en la versión anterior.
Este salto amplía el tipo de agentes que tiene sentido ejecutar en un runtime serverless. Un agente que solo orquesta llamadas a un modelo alojado en otro servicio apenas necesita recursos; uno que procesa documentos extensos, ejecuta análisis de datos con librerías científicas, compila código, transforma archivos multimedia o mantiene varias herramientas en memoria a la vez puede quedarse corto con límites modestos. Con 32 GB y 8 vCPU por sesión, muchos de esos casos dejan de requerir una flota de contenedores o máquinas virtuales gestionada a mano.
El límite de 10 GB por imagen, combinado con el arranque basado en snapshots, también elimina parte del incentivo a adelgazar artificialmente los contenedores. Antes, cada megabyte adicional se pagaba en latencia de arranque; ahora, según AWS, el tamaño de la imagen deja de influir en el tiempo que tarda una sesión en estar disponible. Eso no significa que la higiene de imágenes deje de importar, porque las imágenes grandes siguen alargando la preparación del runtime y ampliando la superficie de ataque, pero sí reduce la presión sobre la latencia percibida por el usuario.
Memoria elástica y escalado a cero
Uno de los rasgos que distinguen a los agentes de otras cargas es su patrón de consumo irregular. Un agente conversacional puede tener un pico de actividad mientras procesa una petición, llama a varias herramientas y genera una respuesta, y después quedarse inactivo durante minutos mientras el usuario lee, piensa o consulta a un colega. En los modelos tradicionales de facturación por recursos asignados, esos tiempos muertos se pagan como si el agente siguiera trabajando.
La nueva generación introduce memoria elástica. Cuando el agente libera memoria, la plataforma la recupera a los pocos minutos, de modo que el consumo facturable sigue más de cerca el uso real. AWS calcula que los agentes multiturno con pausas entre interacciones pueden consumir hasta un 68 % menos de memoria por sesión, cifra de la que procede el titular de eficiencia del anuncio. Y si el agente queda completamente inactivo, escala a cero.
Para un equipo que gestiona miles de conversaciones simultáneas, la diferencia puede ser notable, aunque dependerá del perfil de cada aplicación. Un agente que mantiene grandes estructuras en memoria durante toda la sesión verá menos beneficio que otro que carga datos, los procesa, los descarta y espera. Por eso tiene sentido revisar cómo gestiona la memoria el propio código del agente: liberar referencias a documentos ya procesados, evitar cachés innecesarias dentro de la sesión y delegar el estado persistente en servicios externos son prácticas que ahora repercuten directamente en la factura.
Dos maneras de pagar: consumo o línea base comprometida
El cambio comercial más significativo es la llegada de una segunda modalidad de facturación. AWS mantiene el precio por consumo, que encaja con cargas irregulares, picos impredecibles y agentes que pasan buena parte del tiempo sin actividad y pueden escalar a cero. A esa opción se suma ahora la llamada línea base comprometida, o committed baseline, diseñada para agentes que deben estar siempre activos.
En esta modalidad se factura un mínimo de memoria por sesión, y el agente puede crecer en ráfagas de hasta cuatro veces esa base bajo demanda. AWS sostiene que así las cargas estables obtienen una tarifa predecible, alineada con las tarifas de microVM de AWS Lambda. La compañía no ha detallado en su anuncio precios concretos en dólares para cada modalidad, por lo que cualquier comparación económica debe hacerse con la calculadora y la página de precios oficiales en el momento de la evaluación.
La elección entre ambos modelos no debería hacerse por intuición. Algunas pautas razonables para decidir son las siguientes:
- El precio por consumo suele ser la opción natural para asistentes internos con uso concentrado en horario laboral, prototipos, agentes que se activan por eventos esporádicos y servicios con tráfico muy variable.
- La línea base comprometida tiene más sentido para agentes que monitorizan sistemas de forma continua, asistentes que deben responder al instante en cualquier momento o procesos de larga duración con un consumo mínimo estable y picos ocasionales.
- Antes de comprometerse conviene medir durante unas semanas el consumo real de memoria por sesión, incluidos los picos, para fijar una base que no quede ni sobredimensionada ni demasiado ajustada.
- Si las ráfagas superan con frecuencia el margen de cuatro veces la base, es una señal de que la base elegida es demasiado baja o de que el agente tiene un patrón de uso que no encaja con este modelo.
Lo que dicen los clientes citados por AWS
Como es habitual en este tipo de lanzamientos, AWS acompaña el anuncio con resultados de clientes. Conviene leerlos como lo que son: datos aportados por empresas seleccionadas por el propio proveedor, no mediciones independientes ni necesariamente extrapolables a cualquier carga.
Mission Cloud informó de arranques en frío de inferencia un 35 % más rápidos, arranques de comprobación de salud un 77 % más rápidos y una reducción del 17 % en el coste de runtime por llamada. Zuora, por su parte, declaró una reducción de alrededor del 60 % en la memoria consumida por invocación en muchos de sus casos de uso. El anuncio incluye además valoraciones sin cifras de otras empresas, como Deloitte, Caylent, Okta y Cox Automotive.
Llama la atención que las mejoras declaradas por Mission Cloud en arranque de inferencia sean bastante más modestas que el titular de hasta 15 veces. La explicación más probable es que la cifra máxima corresponde a imágenes grandes, donde la primera versión era más lenta, mientras que las cargas reales combinan el arranque de la microVM con otros tiempos, como la primera llamada al modelo o la conexión con servicios externos, que el runtime no controla. Es un recordatorio útil: la latencia que percibe el usuario final depende de toda la cadena, no solo del cómputo.
Almacenamiento dentro del perímetro de confianza
Los agentes que trabajan con archivos necesitan un lugar donde dejar sus resultados intermedios y finales. La nueva generación permite montar dinámicamente un sistema de archivos dentro de la sesión, por ejemplo un bucket de Amazon S3 con soporte FUSE, para que el agente guarde su trabajo sin salir del perímetro de confianza definido por la organización.
La idea es que el agente pueda leer y escribir como si se tratara de un disco local, mientras los datos residen en almacenamiento gestionado, con sus propias políticas de acceso, cifrado y retención. Es una pieza clave para flujos como la generación de informes, la transformación de documentos o el análisis de conjuntos de datos que superan lo que razonablemente cabe en la memoria de una sesión.
AWS ha adelantado además que para re:Invent llegará el aislamiento de almacenamiento por sesión, de forma que cada sesión quede ligada a su propia carpeta mediante credenciales etiquetadas por sesión. Es importante subrayar que, a fecha del anuncio, se trata de trabajo futuro y no de una función disponible. Hasta que llegue, los equipos que monten almacenamiento compartido deberán diseñar ellos mismos la separación entre sesiones mediante prefijos, políticas de acceso y controles en el código del agente.
Ciclo de vida de una sesión y estado efímero
Otro aspecto que conviene entender antes de diseñar un agente sobre este runtime es el ciclo de vida de las sesiones. Una sesión puede durar hasta 8 horas. Termina cuando pasan 15 minutos sin actividad, cuando alcanza ese límite máximo o cuando deja de estar sana. El estado de la sesión es efímero: al finalizar, la microVM se destruye y la memoria se sanea.
Esta política tiene consecuencias de diseño claras. Un agente no debe dar por hecho que encontrará en memoria lo que dejó en una interacción de hace media hora, porque la sesión puede haber expirado por inactividad. Todo lo que deba sobrevivir a la sesión, como el historial de la conversación, los resultados parciales de una tarea larga o las preferencias del usuario, tiene que persistirse fuera, ya sea en un servicio de memoria, en una base de datos o en el almacenamiento montado. A cambio, la destrucción completa de la máquina al terminar ofrece una garantía de limpieza valiosa desde el punto de vista de la privacidad: no quedan restos de una sesión que puedan aparecer en la siguiente.
El límite de 8 horas también marca una frontera para tareas muy largas. Procesos que puedan prolongarse más allá de ese plazo deberían dividirse en etapas con puntos de control persistentes, de modo que una nueva sesión pueda retomar el trabajo donde lo dejó la anterior.
Cómo activar la nueva generación y qué revisar al migrar
La activación es sencilla desde el punto de vista de la configuración. Basta con establecer el parámetro platformVersion en V2 al crear o actualizar un runtime. La primera versión sigue siendo el valor por defecto, de modo que ningún runtime existente cambiará de comportamiento sin una acción explícita del equipo.
Que el cambio sea un parámetro no significa que la migración deba hacerse a ciegas. Antes de mover un agente en producción conviene repasar varios puntos:
- Medir el tiempo que tarda el contenedor en responder como sano en
/ping. Si la inicialización se acerca a los 120 segundos, habrá que optimizarla o trasladar parte del trabajo a la primera petición. - Revisar qué ocurre durante la inicialización que se capturará en la instantánea. Valores generados en el arranque, como identificadores aleatorios, tokens temporales o conexiones abiertas, podrían quedar congelados en el snapshot y repetirse en todas las sesiones restauradas. Es prudente generar esos elementos por sesión y no durante la preparación.
- Ajustar los pipelines de despliegue para asumir que crear o actualizar un runtime V2 tarda varios minutos, en lugar de esperar una actualización casi instantánea.
- Comprobar la disponibilidad en la región de trabajo. AWS habla de regiones en Norteamérica, Sudamérica, Europa y Asia-Pacífico, pero la lista concreta debe confirmarse en la documentación vigente.
- Ejecutar pruebas de carga comparando V1 y V2 con el tráfico real de la aplicación, midiendo arranques, latencia total y consumo de memoria, en lugar de confiar únicamente en las cifras del anuncio.
- Revisar el modelo de facturación tras unas semanas de uso para decidir si conviene seguir con el pago por consumo o pasar a una línea base comprometida.
Para quienes estén empezando con este tipo de arquitecturas, practicar antes con proyectos más sencillos ayuda a interiorizar conceptos como el escalado a cero, los arranques en frío o la facturación por uso. Una buena forma de hacerlo es aprender serverless con AWS a través de proyectos prácticos, ya que muchas de las ideas de Lambda se trasladan casi sin cambios al runtime de agentes.
El contexto: la carrera por la infraestructura de agentes
El anuncio se enmarca en una competencia cada vez más intensa por la capa de ejecución de los agentes. Los grandes proveedores de nube y los laboratorios de modelos han entendido que la ventaja no está solo en el modelo, sino en ofrecer un entorno donde los agentes puedan ejecutarse con seguridad, escalar y facturarse de forma predecible. Movimientos recientes como el de Anthropic, que decidió llevar Claude Managed Agents a la propia infraestructura del cliente, muestran que la discusión sobre dónde y cómo se ejecutan los agentes se ha vuelto central para las empresas.
En ese terreno, AWS juega con la carta de su experiencia acumulada en cómputo serverless. Firecracker lleva años en producción detrás de Lambda y Fargate, y la técnica de restaurar máquinas desde instantáneas para reducir arranques es una evolución lógica de ese trabajo. Que la línea base comprometida se vincule a las tarifas de microVM de Lambda refuerza la idea de que AgentCore Runtime se apoya en la misma maquinaria interna.
La apuesta por una microVM por sesión también marca una postura frente a alternativas más ligeras basadas en contenedores compartidos o en aislamiento a nivel de proceso. Esas opciones suelen ser más baratas y rápidas de arrancar, pero ofrecen garantías de separación más débiles. AWS intenta demostrar que no es necesario elegir: que se puede tener aislamiento por hardware con arranques de alrededor de 2 segundos.
Impacto para los equipos que despliegan agentes
Para los equipos de plataforma, la consecuencia más inmediata es que desaparecen algunas de las soluciones improvisadas que se habían vuelto habituales. Mantener pools de contenedores calientes para esquivar los arranques en frío, dividir agentes en varias imágenes para reducir su tamaño o sobredimensionar memoria por miedo a quedarse cortos en un pico son prácticas que, si las cifras de AWS se confirman en cada caso, pierden buena parte de su justificación.
Para los equipos de seguridad, el modelo de sesión aislada con identidad y auditoría propias facilita la conversación con las áreas de cumplimiento. Es más sencillo justificar que un agente procesa datos de clientes cuando cada cliente recibe su propia máquina virtual, que se destruye y sanea al terminar, que explicar los controles de una plataforma compartida.
Para los responsables financieros, la combinación de memoria elástica, escalado a cero y la nueva línea base comprometida abre un abanico más amplio para ajustar costes. Sin embargo, la ausencia de precios concretos en el anuncio obliga a hacer los números con cuidado. El coste de los agentes con pausas depende tanto de la tarifa como del comportamiento real del código, y solo la medición con tráfico propio permite saber qué modalidad resulta más conveniente.
Y para los desarrolladores, el cambio tiene un matiz práctico: los despliegues serán algo más lentos por la preparación de la instantánea, pero la experiencia de uso de sus agentes debería ser más ágil. Diseñar pensando en el estado efímero, persistir fuera lo importante y vigilar lo que se inicializa antes del snapshot pasan a ser hábitos imprescindibles.
Límites y preguntas abiertas
El anuncio deja algunos puntos que conviene seguir de cerca. El primero es el aislamiento de almacenamiento por sesión, prometido para re:Invent y todavía no disponible. Hasta entonces, la separación de datos en sistemas de archivos montados recae en el diseño de cada equipo.
El segundo es la transparencia de precios. Sin cifras concretas en el anuncio, la comparación entre pago por consumo y línea base comprometida exige consultar la documentación oficial y modelar escenarios propios, lo que añade fricción a la adopción.
El tercero tiene que ver con las cifras de rendimiento. Los datos de arranque, eficiencia y ahorro proceden de AWS y de clientes citados por la propia compañía, y las mejoras declaradas por estos últimos son más moderadas que los titulares. No es una contradicción, pero sí una invitación a medir antes de prometer mejoras a negocio.
El cuarto es la gestión del estado efímero. La expiración tras 15 minutos de inactividad y el máximo de 8 horas encajan con muchos casos de uso, pero obligan a diseñar con cuidado los agentes que acompañan procesos largos o conversaciones que se retoman tras pausas prolongadas.
Por último, la convivencia entre V1 y V2 plantea una cuestión de planificación. Mientras V1 siga siendo el valor por defecto, los equipos tendrán que decidir activamente cuándo migrar y verificar que sus agentes se comportan correctamente con el modelo de instantáneas.
Lecciones para quienes construyen agentes en producción
Más allá de AWS, el anuncio refleja tendencias que afectan a cualquier plataforma de agentes. La primera es que el aislamiento fuerte por sesión se está convirtiendo en una expectativa básica, no en un extra. A medida que los agentes ejecutan código y manejan datos sensibles, la frontera de seguridad tiene que estar en la infraestructura y no solo en la lógica de la aplicación.
La segunda es que el patrón de uso de los agentes, con ráfagas de trabajo y largas esperas, exige modelos de facturación distintos a los de las aplicaciones web clásicas. La memoria elástica y la combinación de consumo con líneas base comprometidas son respuestas a ese patrón, y es previsible que otros proveedores sigan caminos similares.
La tercera es que el diseño de agentes sin estado en la capa de cómputo, con persistencia delegada en servicios especializados, ya no es una recomendación teórica sino una condición para aprovechar bien plataformas que destruyen y recrean máquinas constantemente.
La cuarta es que la latencia de arranque sigue siendo determinante para la experiencia de usuario. Técnicas como la restauración desde instantáneas permiten ofrecer aislamiento fuerte sin sacrificar la respuesta inicial, pero introducen nuevas responsabilidades, como evitar que datos sensibles o valores únicos queden capturados en la imagen restaurada.
Conclusiones
La actualización de la nueva generación de AgentCore Runtime publicada por AWS el 12 de noviembre de 2026 consolida el lanzamiento de septiembre y lo convierte en una propuesta más completa para ejecutar agentes de IA en producción. Las microVM Firecracker por sesión, con identidad, política y auditoría propias, ofrecen un aislamiento difícil de igualar con contenedores compartidos. Los arranques por debajo de 2 segundos gracias a las instantáneas, el aumento hasta 8 vCPU y 32 GB por sesión y las imágenes de hasta 10 GB amplían el tipo de agentes que tiene sentido ejecutar en un entorno serverless.
En el plano económico, la memoria elástica, el escalado a cero y la nueva línea base comprometida dan más margen para ajustar costes a patrones de uso muy distintos, aunque la falta de precios concretos en el anuncio obliga a modelar cada caso. Los resultados de clientes como Mission Cloud y Zuora apuntan en la dirección correcta, pero son datos aportados por el proveedor y sus socios, no mediciones independientes.
Quedan piezas por llegar, como el aislamiento de almacenamiento por sesión anunciado para re:Invent, y decisiones que cada equipo debe tomar con datos propios: cuándo activar V2, qué revisar en la inicialización de sus contenedores y qué modelo de facturación encaja con su tráfico. Para quienes ya despliegan agentes, el mensaje es claro: la infraestructura empieza a adaptarse a la forma real en que trabajan los agentes, y aprovecharla exige diseñar el código pensando en sesiones aisladas, efímeras y elásticas.