AWS renueva AgentCore Runtime con memoria elástica y cold starts cercanos a dos segundos para agentes de producción

El runtime empieza a optimizar el ciclo completo, no solo el arranque. AWS anunció una nueva generación de AgentCore Runtime, la capa de cómputo administrado de Amazon Bedrock AgentCore. La actualización asigna memoria a medida que una sesión la necesita y puede recuperar memoria que ya no está activa, en lugar de mantener el pico hasta el final. También prepara el entorno una vez y lo restaura desde un snapshot para nuevas instancias. Según las pruebas publicadas por AWS, el P75 de cold start se mantuvo alrededor de dos segundos en imágenes desde 200 MB hasta 2 GB, frente a tiempos crecientes en la versión anterior.

La memoria elástica cambia la forma de pensar el costo de una sesión larga. Muchos agentes tienen perfiles irregulares: cargan una librería pesada para una fase, procesan un archivo grande y luego pasan varios minutos esperando una herramienta o al usuario. Si la infraestructura factura o reserva el pico durante toda la vida de la sesión, esa forma de trabajo penaliza la intermitencia. Recuperar memoria permite que el costo se acerque más al recurso activo en cada momento. Para arquitectura, esto invita a medir curvas de uso y no únicamente el máximo, porque dos agentes con el mismo pico pueden tener economías muy distintas.

El snapshot desacopla el tamaño de imagen de la espera inicial. En un arranque tradicional, una imagen más grande suele significar más trabajo de preparación. AWS afirma que su enfoque restaura una imagen ya preparada, haciendo más consistente la latencia a través de tamaños y niveles de concurrencia. Ese patrón tiene valor especialmente en experiencias interactivas, donde el usuario interpreta cualquier segundo previo al primer output como lentitud del agente. Sin embargo, cold start no es tiempo total de tarea. El loop del agente, el modelo y las herramientas siguen dominando muchas ejecuciones, así que el benchmark debe mantener ambas métricas separadas.

Una mejora de plataforma también necesita una prueba propia del cliente. Los números del proveedor son una referencia, no una garantía sobre cada workload. Dependencias, inicialización, red, herramientas y región pueden cambiar la experiencia. Antes de migrar tráfico, conviene correr una matriz con sesiones cortas y largas, concurrencia realista, distintos tamaños de imagen y patrones de memoria. La comparación debe incluir latencia al primer trabajo útil, costo por run, tasa de éxito y estabilidad durante picos. Así la decisión de runtime se apoya en outcomes del negocio y no únicamente en una cifra de infraestructura.

La infraestructura agentic empieza a parecer una política de ejecución. Una misma habilidad puede necesitar un perfil rápido para interacción humana y otro más barato para trabajo asíncrono. También puede tener requisitos de aislamiento o memoria que cambian según la herramienta. Esto sugiere separar la definición de la habilidad de su runtimeprofile: plataforma, recursos, límites, región y objetivos de latencia. El orquestador puede escoger un perfil aprobado sin alterar el objetivo de negocio. Esa separación facilita adoptar mejoras de infraestructura sin reescribir prompts ni lógica funcional.

Lectura Goatify. En Goatify, el runtime debería convertirse en una decisión observable. Cada habilidad puede declarar un presupuesto de arranque, memoria y duración, y cada ejecución registrar cuánto utilizó realmente. Cuando aparezca una plataforma nueva, la probamos contra un corpus de runs y no por entusiasmo. Si reduce costo o latencia sin empeorar resultados, se promueve. El cliente recibe una ventaja práctica: la infraestructura puede evolucionar debajo de sus agentes mientras el contrato de la habilidad permanece estable. El producto defendible no es el contenedor; es la política que sabe dónde ejecutarlo y cómo demostrar que la elección funcionó.