Resumen de la publicación
En una sola semana AWS anunció instancias persistentes para agentes con sesiones de hasta 14 días y búsqueda vectorial nativa en DynamoDB, Cloudflare presentó un navegador hecho para agentes y no para personas, Docker empujó sus sandboxes en microVM y Anthropic confirmó que arma un equipo de silicio propio.
Leídos juntos, esos anuncios describen algo más interesante que cinco lanzamientos: la capa de infraestructura para correr agentes en producción se está estandarizando en público, y el aislamiento pasó de ser una buena práctica a ser un producto que se compra.
Vengo viendo hace meses una brecha rara entre dos conversaciones que deberían ser la misma.
Por un lado, todo el mundo habla de agentes: qué modelo, qué framework, qué prompt, cuántos pasos. Por el otro, cuando preguntás dónde corre eso en producción, la respuesta suele ser un contenedor cualquiera en el mismo cluster donde corre el resto, con las mismas credenciales de siempre.
La primera semana de agosto me llamó la atención porque parece el momento en que la segunda conversación empezó a tener respuestas de proveedor.
AWS: sesiones de 14 días y el fin del cold start
El 6 de agosto AWS anunció runtime instances en Bedrock AgentCore, que en criollo es infraestructura EC2 gestionada donde desplegás varios agentes dentro de un mismo runtime.
Lo relevante no es el anuncio en sí sino el problema que reconoce. Hasta ahora, si necesitabas un agente corriendo durante días, con acceso a GPU o coordinando con otros agentes, tenías que armarte la infraestructura vos: aprovisionar instancias, configurar red, resolver el manejo de sesiones.
Las características que definen la categoría son tres:
- Sesiones que persisten hasta 14 días, con posibilidad de hibernar y retomar sin perder estado.
- Tipos de instancia con GPU para las tareas que lo justifiquen.
- Agentes que se llaman entre sí como herramientas dentro de una sesión compartida y colaboran por filesystem, sin llamadas de API entre ellos.
El precio es EC2 estándar más un cargo de gestión por la orquestación. Está en Ohio, Virginia, Oregón, Bombay, Singapur, Sídney, Tokio, Fráncfort e Irlanda, o sea todavía nada en Sudamérica.
Un día antes, el 5, AWS había puesto en disponibilidad general la búsqueda vectorial nativa en DynamoDB: embeddings guardados junto a los datos operacionales, latencia de milisegundos de un dígito con más de 99% de recall, hasta 4096 dimensiones, sin límite de almacenamiento del índice.
Esos dos anuncios juntos dicen algo bastante claro sobre hacia dónde va el stack: menos piezas separadas, más capacidades absorbidas por la base de datos y el runtime que ya tenías.
Un navegador que no es para que lo mires
El anuncio que más me hizo pensar es Kitesurf, de Cloudflare: un navegador alojado en la nube diseñado para agentes de IA, no para humanos.
Ignora todo lo que existe para que una persona use un navegador (temas, pestañas, el chrome de la interfaz) y se concentra en lo que le importa a un agente: manejo de la ventana de contexto, rendimiento, costo en tokens y escalabilidad. También aborda específicamente la inyección de prompts.
Corre sobre Workers y está en beta gratuita dentro de Browser Run. Usa componentes open source como el motor Blitz, el parser CSS Stylo de Firefox y el motor de JavaScript Boa.
Lo que me parece significativo es el reconocimiento implícito: durante años los agentes automatizaron un Chromium headless, es decir, una herramienta hecha para personas con la interfaz apagada. Que aparezca un navegador diseñado desde cero para el otro caso de uso indica que ese caso de uso dejó de ser marginal.
El aislamiento como producto
Acá está, para mí, el punto central de todo esto.
Docker Sandboxes le da a cada agente de código su propia microVM desechable, con filesystem privado, su propio daemon de Docker y un stack de red aislado, accesible desde un CLI nuevo (sbx). Desde Docker Desktop 4.60 corren dentro de microVMs dedicadas, que es un límite de seguridad más duro que el de un contenedor.
El agente puede instalar paquetes, cambiar configuraciones, borrar archivos y levantar sus propios contenedores sin tocar tu máquina.
Ahora bien, esto no salió de la nada. Salió de una semana en la que los agentes demostraron que se escapan de donde los ponés, y en la que se publicó que un issue de GitHub alcanzaba para ejecutar código en los runners de CI de tres de los principales proveedores de agentes de código.
Es la secuencia clásica de la industria: primero adoptamos la capacidad, después descubrimos el modo de falla, después aparece el producto que lo contiene. Lo llamativo es la velocidad con que se completó el ciclo esta vez.
Anthropic diseñando chips y la aritmética que hay detrás
El 5 de agosto Anthropic confirmó que está armando un equipo interno de silicio para diseñar chips propios. Está contratando ingenieros que hayan llevado diseños de semiconductores hasta producción, con salarios publicados de entre 320.000 y 485.000 dólares.
El objetivo declarado es co-diseñar el silicio junto con los modelos, apuntando a recortar cerca de la mitad del costo de inferencia por token. La compañía aclaró que mantiene un enfoque multi-chip con AWS, Google, Nvidia y AMD, y viene de expandir en abril su acuerdo con Google y Broadcom por unos 3,5 gigawatts de capacidad de TPU para 2027.
Cuando servís miles de millones de tokens por día, el costo por token deja de ser un detalle de la factura y pasa a ser la estrategia.
Y esto no es solo un problema de los que fabrican modelos. Es exactamente el mismo problema que tenés vos cuando pasás un agente de un piloto a producción, solo que tres órdenes de magnitud más grande.
Por eso me parece que la pieza más práctica de toda la semana es la más aburrida: OpenCost 1.121.0 agregó seguimiento de costos de inferencia por token en clusters de Kubernetes. Nada glamoroso, pero es lo que te permite contestar cuánto cuesta cada agente que pusiste a correr.
Qué me llevo de todo esto
Si tuviera que resumir la semana en una idea, sería esta: los agentes dejaron de ser un problema de modelo y pasaron a ser un problema de plataforma.
Y eso, para los que hacemos infraestructura, es una buena noticia disfrazada de trabajo nuevo. Porque son problemas conocidos: aislamiento, cuotas, persistencia de estado, observabilidad, costo por unidad. Nada de eso es magia; es lo que venimos haciendo hace veinte años, aplicado a una carga de trabajo distinta.
Las tres preguntas que armaría para cualquier agente que hoy tengas en producción o a punto de entrar:
- Si este agente hace lo peor que puede hacer, ¿qué se rompe y hasta dónde llega? Si la respuesta incluye «producción», el aislamiento es la tarea número uno.
- ¿Cuánto cuesta por ejecución? Si no lo sabés, no lo tenés en producción, lo tenés en piloto pagado.
- ¿Dónde vive el estado entre corridas, y quién puede escribirlo? Es la pregunta que el caso de
AGENTS.mddejó incómodamente abierta.
La parte aburrida es la que decide
Me da la impresión de que estamos entrando en la fase donde la ventaja competitiva deja de estar en elegir bien el modelo y pasa a estar en cómo lo operás.
Es lo mismo que pasó con los contenedores. Durante un tiempo la conversación fue sobre Docker contra rkt, y al final lo que separó a los equipos que lo lograron de los que no fue quién tenía resuelto el registry, los límites de recursos, los logs y el costo.
Con los agentes va a pasar igual, y la buena noticia es que esa parte ya no hay que inventarla: esta semana quedó claro que se puede comprar.
