OpenComputer presenta agentes sin servidor que se reanudan con el estado intacto

Why it matters

Long-running agents need durable files, state and execution environments. OpenComputer is betting that managed, hibernating VMs become the deployment layer beneath them.

Mohamed Habib (@motatoeshq), co-founder y CTO de Digger, abrió una vista previa temprana de OpenComputer's serverless agents el 4 de agosto, ofreciendo a los desarrolladores un camino administrado desde el código de agente local hasta un despliegue persistente en la nube. Habib anunció la vista previa en una publicación en X, mostrando el flujo de construcción, prueba local y despliegue del producto.

https://x.com/motatoeshq/status/2084502004618133724

Habib llegó a la infraestructura por una ruta menos convencional. Obtuvo un doctorado estudiando análisis de imágenes retinianas antes de trabajar en enrutamiento de tráfico, autenticación, seguridad y limitación para la puerta de enlace de Prime Video de Amazon, según su perfil profesional. Más tarde cofundó Digger con Igor Zalutski (@IgorZIJ) y Utpal Nadiger (@utpalnadiger), inicialmente construyendo herramientas de código abierto para Terraform y otros flujos de trabajo de infraestructura como código.

Una computadora completa detrás de la etiqueta "serverless"

La etiqueta "serverless" describe cómo OpenComputer gestiona el ciclo de vida de un agente. Cada despliegue se ejecuta en una máquina virtual Linux completa en lugar de en una función de corta duración. OpenComputer dice que la máquina hiberna entre invocaciones, conservando su memoria, sistema de archivos y contexto de trabajo, y luego se reanuda cuando llega otro desencadenante. Los agentes inactivos no generan cargos de cómputo, según la página del producto.

Esa arquitectura aborda un problema recurrente de despliegue para los desarrolladores de agentes. Los agentes pueden instalar paquetes, editar archivos, ejecutar código arbitrario y continuar una tarea a lo largo de múltiples interacciones. Las funciones sin estado convencionales están diseñadas alrededor de solicitudes aisladas con tiempos de ejecución predecibles. OpenComputer, en cambio, le da a cada agente un espacio de trabajo persistente y una máquina que puede sobrevivir a un fallo de proceso, una desconexión o un redepliegue.

La documentación del sandbox de OpenComputer indica que cada entorno tiene su propio kernel, sistema de archivos, red y espacio de procesos, con aislamiento a nivel de hardware mediante KVM. La plataforma también soporta puntos de control, forks de VM y cambios en CPU o memoria mientras una máquina está en ejecución.

Los agentes se convierten en proyectos controlados por código fuente

OpenComputer empaqueta un agente como un directorio que contiene su identidad, instrucciones, herramientas, conexiones de servicio, configuración de runtime, espacio de trabajo y archivos de evaluación. Los desarrolladores pueden confirmar esos componentes en un repositorio y revisar los cambios mediante el mismo proceso que usan para el código de las aplicaciones.

El quickstart de la vista previa temprana guía a través de un resumidor de Gmail. Un desarrollador instala la CLI de OpenComputer, inicializa un agente a partir de una plantilla, define sus instrucciones y límites de aprobación, conecta una cuenta de Google y prueba el comportamiento de forma local. Ejecutar opencomputer deploy --alias production publica un despliegue inmutable manteniendo una identidad estable del agente. Un despliegue posterior mueve el alias production a una nueva versión.

Ese modelo de versionado importa para agentes conectados a correo electrónico, código fuente o sistemas empresariales. Las instrucciones y los permisos de las herramientas pueden cambiar el comportamiento de manera tan significativa como una actualización de código de aplicación. Mantener esos archivos en control de código le da a los equipos de ingeniería un registro de lo que se le permitió hacer a un agente en cada despliegue.

OpenComputer también asigna a los agentes desplegados endpoints permanentes, permitiéndoles recibir solicitudes desde webhooks, programaciones y servicios externos. El producto está diseñado para trabajos como la clasificación de bandeja de entrada, revisión de código e investigación en segundo plano que pueden necesitar pausar, conservar estado y continuar más tarde.

Digger extiende su apuesta por la infraestructura

OpenComputer es el último paso en el movimiento de Digger desde gestionar cambios de infraestructura escritos por humanos hasta suministrar infraestructura para software autónomo. En un ensayo del 15 de marzo, Zalutski argumentó que el código de los agentes combina el comportamiento de petición-respuesta de una aplicación con los requisitos de aislamiento y ejecución arbitraria de un trabajo de integración continua. Su conclusión fue que los agentes necesitan una capa de despliegue distinta construida alrededor de gateways, colas y entornos de ejecución dedicados.

La vista previa de serverless-agents convierte ese argumento en un producto gestionado. Digger apuesta a que los desarrolladores querrán la conveniencia asociada con el despliegue serverless a la vez que conservan una máquina duradera que un agente pueda tratar como su propia computadora.

Digger anunció una ronda semilla de $3.6 millones liderada por Initialized Capital el 16 de junio de 2025. Zalutski dijo que la ronda también incluyó a Olivier Pomel, David Cramer, Michael Grinich, Zeno Rocha, Ben Porterfield, Peter Zaitsev, Eran Sandler, Oana Olteanu y Palumni VC. Initialized dijo que los fundadores se apoyaron en trabajo de infraestructura en Palantir, Amazon y Fitbit, mientras que Nadiger había ayudado a lanzar OpenTofu, el fork de Terraform respaldado por la Linux Foundation.

La vista previa entra en su verdadera prueba después del despliegue: si las máquinas persistentes proporcionan suficiente confiabilidad y simplicidad operativa como para justificar otra capa en la pila de agentes. La respuesta de OpenComputer es ocultar el ciclo de vida de la máquina sin quitar la máquina.