Cuando lanzamos los agentes en la nube por primera vez, hace un año, parecían una extensión sencilla de los agentes locales. Desde entonces, las capacidades de los agentes en la nube se han ampliado considerablemente.

Ahora, los agentes en la nube se ejecutan en sus propias máquinas virtuales dedicadas, con sus propios entornos, dependencias y acceso a la red. Pueden trabajar en paralelo, ejecutarse sin supervisión y encargarse de tareas más largas que un agente local en tu portátil.

Estas capacidades plantean retos de configuración del entorno, fiabilidad y orquestación que son menos evidentes cuando un agente se ejecuta en tu portátil.

En esta publicación, queremos compartir las lecciones más importantes que hemos aprendido al crear agentes en la nube, y por qué este trabajo se parece cada vez menos a portar un agente local a un servidor y más a crear una capa operativa a su alrededor.

#El entorno de desarrollo es el producto

Durante el último año, hemos aprendido que el factor que más influye, con diferencia, en la calidad de los resultados de un agente en la nube es garantizar que disponga de un entorno de desarrollo completo, igual que un desarrollador.

Esto no es algo en lo que tengas que pensar tanto en local, porque los agentes locales heredan sin esfuerzo tu entorno de desarrollo de trabajo desde tu portátil. En la nube, tienes que reconstruir todo eso desde cero, y es sorprendentemente difícil saber cuándo no lo has hecho a la perfección.

En vez de un fallo o un mensaje de error, a menudo la única señal es una sutil degradación en la calidad de los resultados. Puede que al principio no lo notes o, si lo haces, puede que se lo atribuyas al modelo.

Pero una y otra vez hemos llegado al mismo diagnóstico: el agente en la nube no tiene el entorno que necesita para ejecutar o verificar su trabajo. Hace un año esto importaba menos, porque los modelos tampoco podían aprovechar mucho su entorno. Pero, a medida que se han vuelto más inteligentes, la configuración del entorno se ha convertido en el factor decisivo para que rindan a todo su potencial.

Hoy, llegar a ese "entorno completo" requiere reconstruir una cantidad sorprendente de infraestructura:

• Mejores herramientas para que el usuario cree el entorno del agente
• Métodos para hibernar y reanudar de forma eficiente las VM de los agentes entre mensajes
• Pipelines para crear rápidamente checkpoints duraderos, restaurar y bifurcar imágenes de VM
• Integraciones estrechas de harness y cliente para que tanto los agentes como las personas puedan interpretar e interactuar con el entorno

Y, a medida que los agentes en la nube asumen más trabajo, necesitan acceso controlado a la red para crear PR, descargar dependencias e investigar. Con el tiempo, hemos acabado creando lo que es, en esencia, un departamento de TI empresarial para agentes, con ocultación de secretos, políticas de red y gestión de credenciales.

#Los agentes de larga duración necesitan una ejecución duradera

Los agentes en la nube plantean un tipo de reto de fiabilidad distinto al de los agentes locales. En lugar de competir por los recursos locales de tu laptop, los agentes en la nube se ejecutan en sus propias VMs aisladas. Esto facilita que los desarrolladores ejecuten muchos agentes en paralelo y deleguen tareas de larga duración que a menudo tardan horas en vez de minutos.

Pero ejecutarse en una VM los expone a interrupciones como caídas de los proveedores de inferencia, pods que deben reemplazarse y nodos de EC2 que dejan de estar disponibles.

Empezamos a crear agentes en la nube con una arquitectura de work stealing, en la que los nodos worker podían recoger agentes y hacerlos iterar hasta completarlos. Trasplantaba a un servidor lo que funciona en local, y era una configuración frágil: nuestra beta inicial de agentes en la nube a menudo operaba con un solo nueve de fiabilidad.

A medida que los agentes en la nube maduraban, vimos que estábamos a punto de tener que volver a crear muchas de las primitivas de ejecución duradera que Temporal ya resuelve (p. ej., mecanismos de reintento, programación del trabajo entre máquinas y durabilidad ante fallos de nodos), así que en su lugar migramos a Temporal.

Nuestro bucle de agente actual en Temporal puede sobrevivir a fallos puntuales en la fiabilidad de la inferencia, a la hibernación y reanudación de pods, y a ejecuciones que se prolongan durante días o incluso semanas. Solo esa migración nos llevó a superar los dos nueves de fiabilidad y, hoy, Temporal gestiona más de 50 millones de acciones al día en más de 7 millones de flujos de trabajo únicos. Internamente, más del 40% de nuestras PR provienen de agentes en la nube, y la cifra sigue creciendo.

Con el tiempo, hemos aprendido a diseñar mejor la arquitectura de nuestros flujos de trabajo en Temporal. Hemos pasado de flujos de trabajo de agentes "eternos" a varios más cortos que finalizan tras completar una sola tarea, lo que facilita las actualizaciones de versión. También hemos separado actividades para capturar mejor los timeouts y los reintentos, a medida que las llamadas a herramientas asíncronas, los subagentes y las caídas de los proveedores de inferencia han ido cambiando nuestras suposiciones de base.

#Desacoplar agentes y máquinas del estado de la conversación

Un agente en la nube ya no es solo un bucle que se ejecuta en una sola máquina. Ahora, un agente puede ejecutarse en una máquina, generar subagentes asíncronos en varias, o iniciarse localmente y luego delegar trabajo a la Cloud. Un subagente incluso puede sobrevivir a su padre, o ejecutarse en un tipo de pod completamente distinto.

Para que eso funcione, hemos visto que es útil mantener el bucle del agente, el estado de la máquina y el estado de la conversación como componentes desacoplados. Como el bucle del agente se ejecuta en Temporal en lugar de en la propia VM, podemos gestionar los ciclos de vida de los pods de forma independiente y ejecutar agentes en distintos tipos de pods, incluidas optimizaciones como VMs de solo lectura o VMs precalentadas.

En cuanto a la conversación, separamos la capa de almacenamiento y streaming del flujo de trabajo principal del agente. Creamos un mecanismo eficiente de almacenamiento de solo anexado que transmite las actualizaciones de la conversación a clientes web y de escritorio. Esta capa tiene en cuenta los reintentos, de modo que, si un paso del bucle del agente falla después de transmitir un resultado parcial y luego se vuelve a intentar, el cliente puede detectarlo, retroceder la transmisión y mostrar los datos nuevos en lugar de los anteriores.

#Saber cuándo apartarse

Crear un harness de agente en la nube implica reevaluar constantemente qué parte del comportamiento es determinista y qué parte se deja en manos del agente.

Al principio, no confiábamos demasiado en el agente, así que el harness volvía a comprobar su trabajo después de cada tarea, forzaba un commit y hacía push. A medida que los modelos se fueron volviendo más inteligentes, empezamos a sacar lógica del harness y a llevarla a herramientas controladas por el agente. Hace un año, las configuraciones multirrepo requerían comportamiento codificado de forma rígida en el harness. Ahora, podemos darle al agente el diseño del repo, exponer herramientas para ramas y PRs, y dejar que decida cómo hacer el trabajo.

Lo mismo ocurrió con CI Autofix, donde las versiones anteriores de nuestro harness de agente en la nube contenían lógica para capturar logs de fallos de trabajos y escribirlos en la VM. Ahora, simplemente le damos al agente acceso a GitHub CLI y escribimos automáticamente los resultados de gran tamaño en archivos en los que puede buscar. La notificación al agente se simplificó mucho, y esperamos que esa tendencia continúe.

El harness no está desapareciendo; más bien, está cambiando lo que contiene. El uso del ordenador es un buen ejemplo en este momento. Nuestro harness de agente en la nube tiene un tipo de subagente dedicado al uso del ordenador, con su propio enrutamiento de modelos, prompt personalizado y grabación de pantalla. VNC y Chrome pertenecen al entorno, que se comparte entre el agente principal y el subagente. Esto permite que el agente principal los use directamente, por ejemplo, al ejecutar un script de Playwright. Usamos esta base porque los modelos todavía no están del todo listos para encargarse por sí solos del uso del ordenador, pero el agente sigue controlando cuándo invocarla.

Los agentes en la nube también necesitan distintos tipos de prompts en el harness, a diferencia de los agentes locales. Los animamos a ser más autónomos, porque el coste de quedarse bloqueados es mucho mayor. En local, sabes cuándo un agente se ha detenido y está esperando permiso, pero en la nube podría quedarse así durante horas antes de que vuelvas a comprobarlo.

#Entornos de agentes autorreparables

De cara al futuro, nos centramos en superar la disyuntiva entre guiar al agente paso a paso y dejarlo actuar por su cuenta. Un enfoque mejor es darle herramientas para entender el sistema que lo rodea.

Queremos que los agentes en la nube puedan informar cuando faltan secretos, cuando el acceso a la red está bloqueado o cuando su entorno les impide avanzar de cualquier otra forma, y que luego puedan actuar de manera autorreparable. En un blog de investigación reciente hablamos de una forma de lograrlo a la que llamamos “autoinstall”.

Los agentes en la nube han mejorado muchísimo en solo los últimos meses, y esperamos que el ritmo de cambio no haga más que acelerarse a partir de aquí. Los agentes en la nube de Cursor permiten que los equipos aprovechen todo este potencial sin tener que crear ni mantener la infraestructura subyacente.