Infinity: un runtime para agentes de IA que esperan

Un runtime para agentes de IA que no se quedan esperando

Casi todos los agentes que hemos montado pasan la mayor parte de su vida esperando: un build de veinte minutos, la aprobación de alguien que contesta mañana, la siguiente PR de un repositorio. AWS y UC Berkeley publicaron hace unos días Infinity, un runtime para agentes de IA que, según AWS, está pensado para ese problema. Lo han soltado con licencia Apache 2.0, dentro del proyecto Hydro, y ellos mismos lo llaman una versión de investigación temprana. Me parece interesante sobre todo por la idea, más que por el producto.

El problema: el agente que espera ocupa sitio

Según el anuncio de AWS, en muchos arneses el bucle del agente es una secuencia de pasos bloqueantes: llamas al modelo, lanzas la herramienta, esperas a que vuelva y repites. Mientras esperas, el agente ocupa un proceso y su memoria, y además no puede reaccionar a nada que ocurra entretanto. Si tienes unos pocos agentes, da igual. Si tienes muchos esperando horas o días, empieza a doler.

La idea: tratar cada herramienta como un await

Los lenguajes como Rust, JavaScript o Python resolvieron algo parecido hace tiempo con async y await: cuando una función espera, se suspende y el hilo se dedica a otra cosa. Infinity aplica lo mismo a un agente. Cuando el agente llama a una herramienta, el runtime lanza la llamada, guarda la conversación y lo suspende. Cuando llega el resultado, lo reanuda desde lo guardado.

Cada ejecución es una “porción” acotada: carga el historial, hace una respuesta del modelo, la guarda, lanza como mucho una herramienta y termina. Todo lo que puede despertar al agente (el texto del usuario, un resultado, un evento) llega como un mensaje a una cola. Así, un agente suspendido ocupa lo que ocupa su historial y poco más.

Esto tiene una consecuencia práctica en serverless. Como ninguna porción se queda esperando, la función puede terminar. En su despliegue de referencia en AWS usan una cola SQS FIFO, funciones Lambda, Aurora DSQL y DynamoDB, y dicen que un agente que espera tres días a un pipeline de CI no consume cómputo mientras tanto. El repositorio incluye los constructs de CDK para montarlo.

Lo que más me gusta: los eventos como “llamadas sintéticas”

Un agente que espera también tiene que enterarse de lo que pasa mientras tanto: la salida de un comando largo, una PR nueva. Las APIs de los modelos no tienen una forma de representar un evento asíncrono: cada llamada a una herramienta debe tener exactamente un resultado.

La solución de Infinity es ingeniosa. Cuando llega un evento, el runtime añade una llamada a herramienta que el modelo no hizo (receive_event__injected), con una referencia a la llamada original, seguida de un resultado con el evento. Así el modelo lo interpreta como interpreta cualquier resultado de herramienta, y no confunde un evento con algo que dijo el usuario. Por defecto, cada evento lo procesa un hilo hijo temporal, para no llenar el contexto del agente principal; el hijo decide si merece avisar al padre. Lo mismo sirve para que padres e hijos se comuniquen entre ellos, sin un sistema de mensajería aparte.

Si has leído mi post sobre el harness de los agentes, esto encaja: mucho de lo que importa en un agente no está en el modelo, sino en la capa que lo rodea.

Con el dato de los 75.000 agentes, ojo

Según AWS, caben 75.000 agentes concurrentes en los 8 GB de una Raspberry Pi 5. Ese número se ha repetido bastante, pero no se probó en una Raspberry Pi. Lo que midieron fue lo siguiente:

• 80.000 agentes en un solo hilo de un AMD EPYC 9R14.
• Un modelo simulado y almacenamiento en memoria.
• Unos 100 KB de memoria por agente inactivo, con respuestas de unos 1,2 KB.

Los 75.000 no son una medición: son una extrapolación de AWS, que lleva ese ritmo de unos 100 KB por agente a los 8 GB de la Raspberry. Y lo que mide es algo estrecho: lo que cuesta recordar una conversación pequeña. Los historiales reales pueden pesar mucho más que esos 100 KB (esto ya es lectura mía, AWS no lo dice): un agente real acumula salidas de herramientas, ficheros y logs. Un análisis crítico de alfw.ai lo resume bien: quédate con los 100 KB por agente inactivo en esas condiciones, no con el titular. Tampoco es lo mismo tener 80.000 agentes residentes que 80.000 inferencias simultáneas.

Y una cosa más que ese análisis señala y me parece justa: suspender al agente reduce el coste de esperar, pero no el de pensar. Reanudarlo sigue implicando cargar el historial, una entrega de cola, una función y otra llamada al modelo.

Lo que ellos mismos dejan abierto

Lo mejor del anuncio es que acaba con sus propias dudas:

• Los modelos se entrenan sobre todo con trazas donde las herramientas responden de forma síncrona. No se sabe cuánto afecta recibir eventos intercalados a las decisiones del agente.
• El planificador atiende los hilos por orden de llegada, sin prioridades.
• No han estudiado cómo compactar el historial en árboles grandes de agentes.
• La autenticidad de los eventos: si el agente está expuesto a internet, ¿cómo sabe de dónde viene cada mensaje? Es el mismo tema que tocaba en permisos, sandboxes y secretos.

Qué me llevo

Yo lo leo como un diseño que merece la pena copiar antes que como algo para adoptar mañana. Guardar la conversación en cada llamada a una herramienta, tratar resultados y eventos como mensajes de una cola y dejar que el proceso muera entre medias es una idea que sirve en cualquier stack, también fuera de AWS. Y si tus agentes sobre todo esperan (triage, vigilancia de CI, aprobaciones), tiene sentido probar el código sabiendo que es una versión de investigación. Si necesitas algo probado en producción, yo esperaría a ver un benchmark con un modelo real y con historiales realistas.

Para cerrar

Si en tu equipo tenéis agentes que pasan más tiempo esperando que trabajando y queréis diseñarlos bien desde el principio, en onext te echamos una mano. Escríbeme desde onext.es y lo hablamos.