La mayoría de los frameworks de agentes hoy en día asumen un escritorio. Un usuario, una máquina, un proceso. El agente se ejecuta mientras la laptop está abierta, escribe en un sistema de archivos local, guarda las claves API en variables de entorno y muere cuando la terminal se cierra. Cuando algo falla, el usuario lo reintenta. Cuando el agente necesita un paquete, pip install lo instala en el Python del usuario. El estado, los secretos y el ciclo de vida están todos dentro de un único límite de confianza.
La infraestructura de agentes en la nube no tiene ninguno de esos lujos.
El agente se ejecuta en un sandbox que arranca desde cero, en hardware compartido con extraños, activado por quienes llaman a los que el usuario nunca conoce: un cronograma, una solicitud HTTP, otro agente. El usuario suele estar dormido cuando ocurre la ejecución. El código dentro del sandbox puede ser adversarial. El sistema de archivos tiene que sobrevivir a los despliegues. Las credenciales no pueden vivir donde vive el agente. Cada garantía que el escritorio te da gratis — persistencia, identidad, confianza en la red, reintento — tiene que ser reconstruida como un sistema explícito.
Pasamos los últimos meses ajustando esa capa en CREAO. Dos lecciones surgieron de ello. Si alguna vez has distribuido un agente de escritorio y te has preguntado qué cambia cuando se mueve a la nube, esto es lo que cambia.
Lección 1: Separa lo que cambia lentamente de lo que cambia rápido
En un escritorio, el entorno del usuario y el runtime del agente son la misma cosa, actualizados al mismo ritmo, por la misma persona. En la nube, no lo son.
Una aplicación de agente acumula estado en el lado de la plataforma. Un analista de acciones instala matplotlib, descarga datos de mercado, escribe scripts de gráficos. Ese entorno es la memoria muscular del agente. Lo congelamos en una instantánea del sandbox en el momento en que el usuario está satisfecho con él, y mantenemos esa instantánea congelada hasta que el usuario edite el entorno nuevamente. Cada ejecución arranca desde la misma imagen. Los mismos paquetes, los mismos archivos, las mismas versiones. La ejecución del lunes se comporta como la del viernes, porque nada de lo subyacente se ha movido.
Esta es la propiedad que los frameworks de escritorio no pueden darte gratis. Un pip install de hace seis meses se resuelve a versiones diferentes hoy. Una instantánea en la nube se resuelve a los mismos bytes para siempre. La reproducibilidad es algo que la plataforma le debe al usuario, y una instantánea congelada es la forma más barata de ofrecerla.
Luego aparece el problema del acoplamiento.
La misma imagen que congela el entorno del usuario también contiene el código del runner — la pequeña librería de arnés desarrollada por nosotros que gestiona el agente en cada ejecución. El usuario quiere que su entorno se quede quieto. Nosotros queremos que nuestro runner se despliegue muchas veces al día. Un artefacto, dos requisitos opuestos.
Nuestra primera solución fue contundente. Al arrancar, verificar si el runner dentro de la instantánea coincide con la versión que acabamos de desplegar. Si no es así, desechar la instantánea y arrancar desde una plantilla limpia. Funcionó y nadie se quejó. El daño solo afectó a la primera ejecución después de un despliegue.
Las ejecuciones no supervisadas acabaron con esa cobertura. Un trabajo cron a las 9 a.m. del lunes no debería perder su entorno porque desplegamos a las 8:55 a.m. El contrato que estábamos violando silenciosamente — «tu entorno está congelado hasta que lo cambies» — se rompió.
La solución nos llevó más tiempo del que debería para verla. El entorno del usuario y el código del runner cambian a ritmos completamente diferentes. El usuario edita su agente cuando quiere. Nosotros desplegamos la plataforma muchas veces al día. Tratarlos como un solo artefacto forzaba una decisión en cada despliegue: mantener código de runner obsoleto, o destruir el entorno congelado que el usuario nos pidió explícitamente que preserváramos.
El modelo en el que aterrizamos toma prestado de cómo los sistemas operativos manejan las actualizaciones. El kernel cambia. Tu directorio personal no cambia. No borras el disco para instalar un parche de seguridad.
Dibujamos el mismo límite. El sandbox arranca desde la instantánea congelada del usuario, intacta. Luego intercambiamos en caliente solo el runner. La secuencia:
- Colocar el nuevo runner en un directorio temporal dentro del sandbox.
- Validarlo con node --check para que cualquier error de sintaxis sea detectado antes de tocar algo en vivo.
- Intercambiarlo atómicamente: desbloquear el flag inmutable del runner antiguo, copiar el nuevo, bloquear de nuevo con chattr +i, luego ocultar el binario chattr para que el código del sandbox no pueda revertir el bloqueo.
- Purgar la caché de compilación de V8 (/home/user/.cache/v8-compile-cache/*) para que el archivo nuevo se cargue realmente en lugar de ejecutar bytecode obsoleto.
- Si algún paso falla, matar el sandbox y reintentar con uno nuevo. Nunca se ejecuta un agente en un estado medio actualizado.
Todo el intercambio toma unos 300 milisegundos. Volvemos a tomar una instantánea después de una ejecución exitosa solo cuando el código del runner fue intercambiado, horneando el código actualizado en la imagen del usuario para que la próxima ejecución se salte el intercambio por completo. Los despliegues de la plataforma nunca descartan el estado del usuario; integran el nuevo runner en él. Los paquetes, archivos y personalizaciones del usuario se transfieren sin cambios.
Si algo puedes sacar de esta lección, es la pregunta de diagnóstico. Para cualquier cosa que persistas en una plataforma en la nube, pregúntate: ¿quién controla el ritmo de cambio de este artefacto? Si tanto el usuario como la plataforma lo poseen, eventualmente pagarás por el acoplamiento. Divide el artefacto a lo largo del límite de propiedad y deja que cada lado se actualice en su propio reloj.
Lección 2: Mantén los secretos fuera del límite de ejecución
Esta es la lección que separa la infraestructura de agentes en la nube de todo lo demás.
Un agente de escritorio se ejecuta como el usuario. Usa las claves del usuario, en la máquina del usuario, contra la red del usuario. Un agente en la nube se ejecuta como nadie, en hardware compartido, contra internet abierto, ejecutando código que un LLM escribió a partir de un prompt que puede haber sido adversarial. El modelo de seguridad tiene que asumir que el código dentro del sandbox ya está comprometido, no esperar que no lo esté.
La regla que mantenemos es simple. Ninguna credencial de larga duración vive jamás dentro del sandbox.
Cuando un agente necesita llamar a un servicio autenticado — Slack, GitHub, la propia API del usuario — no guarda el token. Envía una solicitud HTTP local a un puente de API que se ejecuta fuera del sandbox. El puente adjunta el token OAuth en el lado del host y reenvía la llamada. La respuesta regresa sin que el token entre nunca en la memoria o el entorno del sandbox.
La parte interesante es cómo el puente sabe que el sandbox está autorizado a preguntar. Dos verificaciones, superpuestas a propósito.
Primero, lista blanca de IPs. El puente solo acepta conexiones del rango de red interna en el que viven nuestros hosts de sandbox. Una llamada desde cualquier otro lugar — una laptop de desarrollador, una URL filtrada, internet público — es descartada en la capa de red antes de que se ejecute cualquier código de aplicación. Esto fija el puente a una pieza de infraestructura física y lo vuelve inútil para cualquiera fuera de ella.
Segundo, un JWT de corta duración emitido por ejecución. Cuando un sandbox arranca, la plataforma firma un token limitado a esa ejecución específica: qué usuario, qué aplicación, qué sesión, con una caducidad que cubre la ventana de ejecución y nada más. El sandbox lo presenta en cada llamada al puente. El puente verifica la firma, comprueba la caducidad, y solo entonces resuelve las credenciales almacenadas del usuario y las adjunta del lado del servidor. Si un sandbox es secuestrado, el atacante hereda un token que muere con la ejecución y solo autoriza llamadas limitadas a esa sesión. No hay una credencial maestra que robar.
El mismo puente transporta las deducciones de facturación, los registros y las métricas hacia afuera, por lo que es la única interfaz que cruza el límite del sandbox en cualquier dirección. Todo lo demás dentro del sandbox se trata como comprometido por defecto.
Si una inyección de prompt convence a un agente de volcar process.env a un webhook mañana, el atacante obtiene un JWT de corta duración que solo funciona desde dentro de nuestra red y caduca con la ejecución. Esa propiedad es lo que nos permite ejecutar código de usuario no confiable en infraestructura compartida sin perder el sueño.
El patrón subyacente
La infraestructura de agentes en la nube confiable y segura no es un sistema novedoso. Son unas pocas propiedades mantenidas sin excepción:
- El estado vive en el sandbox, congelado hasta que el usuario lo cambie.
- El código es intercambiable en caliente, independiente del estado.
- Las credenciales viven del lado del host, nunca dentro del agente.
- Un único pipeline de ejecución sirve a todos los que llaman, ya sea que el desencadenante sea un humano, un programador o otro software.
Esa última propiedad es la conclusión de todo el diseño. Una única función executeAgent maneja clics de interfaz, ejecuciones programadas y llamadas API. El sistema de facturación, los registros de deducción de créditos, las señales de observabilidad — todos idénticos independientemente de si un humano hizo clic en Ejecutar, un cron se disparó o un script llamó a la API. Agregar una nueva superficie de activación es un cambio de enrutamiento, no un cambio de arquitectura. El agente mismo no sabe ni le importa quién apretó el gatillo.
Eso es lo que los frameworks de escritorio no pueden darte, y lo que hace que valga la pena construir la versión en la nube. Un agente en una laptop está ligado a la laptop. Un agente en la nube es una función que el resto de tu stack puede llamar. El usuario lo escribe una vez. La plataforma lo hace sobrevivir a los despliegues, ejecutarse de forma segura en hardware compartido y aceptar a quienes llaman que el usuario nunca anticipó.
Un agente es una función con una interfaz de lenguaje natural. Su implementación pertenece al usuario. Su superficie de activación, su runtime, su límite de seguridad pertenecen a la plataforma. La disciplina es construir las capas para que cada una evolucione en su propio reloj, y dedicar tiempo a encontrar las grietas entre los sistemas antes de que alguien más lo haga.
Eso es lo que hace que la próxima superficie sea barata de distribuir, y segura de distribuir.
