Últimamente mucha gente habla de los “agentes long-running”. La idea más obvia es que, si un agente tiene que durar mucho tiempo, entonces basta con alojarlo como un proceso de larga vida y mantenerlo encendido. A primera vista suena razonable: el contexto queda en memoria, el directorio de trabajo permanece en su sitio y, cuando el usuario vuelve, el proceso simplemente continúa. El problema es que este enfoque convierte silenciosamente el tiempo de espera en tiempo de cómputo pagado, y ahí es donde las cosas empiezan a torcerse.
Muchas sesiones de agentes pueden durar ocho horas, un día entero o incluso más, pero solo una pequeña fracción de ese tiempo es computación real. El usuario se va un rato, una aprobación queda pendiente, un evento externo todavía no llega o una tarea programada no se dispara hasta mucho más tarde. En otras palabras, la sesión es larga en tiempo de reloj, no en tiempo de CPU activa. Si no separas esas dos ideas desde el principio, la arquitectura termina optimizando lo equivocado.
0x00 > El problema
Si los agentes se modelan como procesos alojados de forma permanente, lo primero que se pierde no es elegancia arquitectónica sino eficiencia de costes. Mientras el proceso siga vivo, hay que reservar cómputo para él, esté haciendo algo útil o no. En periodos tranquilos, las máquinas quedan ocupadas sosteniendo agentes inactivos; en periodos de pico, la capacidad se vuelve escasa porque demasiado recurso ya está comprometido por agentes que técnicamente están en línea pero en la práctica solo están esperando.
Eso es exactamente lo contrario de lo que la nube hace bien. El valor real de la infraestructura cloud no está en alojar más procesos siempre encendidos, sino en darte recursos cuando el trabajo aparece de verdad y en hacer scale to zero cuando no está ocurriendo nada. Si un agente tiene que permanecer caliente todo el tiempo, renuncias a una de las propiedades más valiosas de la nube: la elasticidad. Un sistema que desperdicia recursos en los periodos tranquilos y aun así tiene problemas para expandirse bajo carga lo tendrá muy difícil para ofrecer, al mismo tiempo, una gran experiencia y una gran eficiencia de costes.
0x01 > Lo que el usuario quiere de verdad
Pero el punto más importante es que al usuario realmente no le importa si un proceso concreto siguió vivo. Lo que le importa es si puede volver y continuar el trabajo desde donde lo dejó. ¿Sigue ahí el repositorio? ¿El navegador sigue en la misma página? ¿Los archivos descargados, las notas a medio hacer y el entorno en progreso permanecen donde estaban?
Lo que el usuario quiere, en otras palabras, no es un proceso siempre encendido sino un espacio de trabajo que no desaparezca. Esos dos objetivos suenan parecidos, pero llevan a sistemas muy distintos. Uno consiste en mantener viva una unidad de ejecución para siempre; el otro consiste en preservar la parte del entorno que realmente tiene valor para el usuario. En cuanto el objetivo pasa de “mantener vivo el proceso” a “mantener intacto el espacio de trabajo”, el diseño se aclara mucho.
0x02 > Runtime, agent y sandbox
Por eso Brazosd trata el runtime, el agent y el sandbox como capas separadas. El agent es la identidad de larga vida: lleva la configuración, las instrucciones, herramientas, skills, permisos, credenciales y su relación con usuarios, equipos y sesiones. La sesión es el registro duradero: guarda lo que dijo el usuario, lo que hizo el agent y en qué punto se encuentra el proceso general. El runtime es la capa de ejecución: cuando llega trabajo, lo toma, lo ejecuta y escribe los resultados. Cuando no hay trabajo, no necesita seguir ocupando cómputo.
El sandbox es el espacio de trabajo, y no es solo una capa abstracta sino un entorno aislado que corre dentro de una máquina virtual. Ahí viven el sistema de archivos, el directorio de trabajo, el estado del navegador, los artefactos descargados y el contexto local que se va acumulando mientras una tarea está en curso. Esto no sirve únicamente para conservar el espacio de trabajo; también mejora la seguridad. Cuando un agent navega por la web, descarga archivos, ejecuta scripts o procesa entradas no confiables, la parte más sensible del sistema es precisamente el entorno de ejecución. Si todo eso ocurriera directamente dentro de un proceso alojado de larga vida, el límite sería mucho más difuso. En cambio, al ejecutarse dentro de un sandbox en una VM, la separación entre el entorno de ejecución y la capa de control de la plataforma queda mucho más clara.
Separar el sistema de este modo permite que las partes que deben durar realmente duren, que las partes que deben escalar de forma elástica no tengan que permanecer en línea para siempre, y que las partes que interactúan con el mundo exterior queden dentro de un límite de aislamiento más fuerte. El agent deja de ser “un proceso”, la sesión deja de quedar atada a una máquina concreta y el sistema por fin puede conservar continuidad, mejorar la seguridad y mantener la elasticidad de la nube.
0x03 > Suspensión del sandbox
El paso clave a partir de ahí es hacer que el sandbox pueda dormir. En cuanto el espacio de trabajo puede entrar en suspensión, ya no hace falta elegir de manera brutal entre experiencia y coste. Cuando una sesión queda inactiva, el sandbox no necesita seguir quemando cómputo activo, pero tampoco hace falta destruir el espacio de trabajo que contiene. El directorio puede seguir ahí. Los archivos pueden seguir ahí. El estado del navegador y los artefactos intermedios también.
Después, cuando llega el siguiente mensaje del usuario, se dispara una tarea programada o por fin aparece un evento externo, el sandbox se despierta y el trabajo continúa desde el mismo punto. Esto se parece mucho más a cerrar la tapa de un portátil que a desmontar una oficina entera y reconstruirla más tarde. Desde el punto de vista del usuario, la experiencia sigue siendo continua. Desde el punto de vista de la plataforma, el tiempo ocioso ya no sigue consumiendo cómputo. Eso es exactamente lo que necesita un agente long-running de verdad: no calor permanente, sino la capacidad de volver.
0x04 > Por qué importa
En la práctica, este diseño nos da dos cosas. La primera es experiencia. El usuario no necesita entender qué ocurrió por debajo ni si los recursos se reasignaron en medio; solo percibe que, cuando vuelve, el agente sigue sintiéndose como el mismo espacio de trabajo. La segunda es coste. El cómputo se gasta cuando el trabajo realmente ocurre, las sesiones inactivas pueden dormir, los periodos vacíos pueden hacer scale to zero y los periodos de alta actividad pueden escalar hacia fuera.
Así que cuando Brazosd dice que el runtime es sin estado, no es porque persigamos una idea abstracta de arquitectura elegante. La motivación es mucho más simple: dar a los usuarios la experiencia más continua posible y, al mismo tiempo, empujar el coste del tiempo de espera tan abajo como se pueda. Lo mejor de la nube es que los recursos se usan bajo demanda, y la mejor experiencia de agentes no debería depender de mantener un proceso caliente para siempre. Lo que merece preservarse no es el proceso en sí, sino el espacio de trabajo que al usuario realmente le importa.