Un agente que necesita levantar una aplicación y su base de datos puede necesitar algo más que ejecutar un script aislado. Las VM Sandboxes de Modal ofrecen una máquina virtual con su propio núcleo de Linux para ese tipo de trabajo. La decisión práctica es comprobar qué exige el entorno del agente antes de cambiar de sistema de ejecución.
La fecha importa: Modal anunció su disponibilidad general el 1 de octubre de 2026. El comunicado empresarial del 14 de octubre vuelve a mencionarla; no constituye un lanzamiento nuevo el día 19. Revisamos su utilidad y sus límites con la documentación consultada hoy.
Qué aporta la máquina virtual
El anuncio de producto describe un entorno compatible con las APIs e imágenes de Modal Sandboxes, pensado para necesidades como Docker y sistemas de archivos FUSE. Son capacidades útiles cuando las dependencias de una aplicación necesitan comportarse como en una máquina Linux completa. No implican que todos los agentes necesiten una VM.
El selector es el parámetro runtime: la documentación admite "vm" y "gvisor". Aunque el anuncio del 1 de octubre señalaba gVisor como opción predeterminada, la guía actual dice que omitir el parámetro permite a Modal elegir. Para una evaluación reproducible conviene registrar explícitamente cuál se utiliza, junto con las dependencias de la aplicación.
Dos límites que evitan una migración equivocada
La documentación actual solo admite GPU en Sandboxes con gVisor. Por tanto, disponer de una VM no equivale a disponer de una VM con GPU. Si una carga depende de aceleración, ese requisito debe resolverse antes de adoptar el entorno.
También hay que separar Docker dentro de una VM de la virtualización anidada, que permite ejecutar otro nivel de máquinas virtuales. La segunda aparece condicionada a los planes Team y Enterprise y a solicitar acceso. Ejecutar Docker no exige, por ese mero hecho, solicitar esa capacidad distinta.
El anuncio no justifica migrar cualquier script. Como criterio propio: si el agente transforma un JSON en un informe y su entorno actual funciona, añadir una VM necesita una razón concreta, como una dependencia incompatible. No basta con que sea una opción nueva.
Un ejemplo: comprobar un cambio con una base de datos
Imaginemos un agente que modifica una aplicación web con PostgreSQL y debe comprobar una prueba de integración sobre servicios Docker. Es un ejemplo hipotético, no ejecutado por Puntoes.
El equipo podría preparar una imagen con dependencias conocidas, cargar datos ficticios y pedir al agente que reproduzca el error antes de aplicar el cambio. Después conservaría el resultado de las pruebas, los registros y el parche para revisarlos. Registrar también un fallo es útil: permite distinguir una dependencia ausente de un cambio incorrecto.
Nuestro criterio sería separar tres comprobaciones: que el entorno arranca, que reproduce el problema y que la modificación supera las pruebas pertinentes. Arrancar Docker solo responde a la primera. Esa separación conecta con nuestro artículo sobre arquitectura de aplicaciones de IA y control de efectos.
Aislamiento, permisos y consumo se revisan por separado
Los Sandboxes permiten conexiones salientes a direcciones públicas de forma predeterminada. La documentación ofrece bloqueo completo mediante block_network=True y restricciones por destinos. Antes de cargar datos, conviene decidir qué comunicaciones son necesarias. Una máquina aislada no decide qué credenciales debe recibir el agente; para el ejemplo anterior bastarían datos y permisos de prueba.
El coste tampoco queda fijado por elegir VM. Modal documenta facturación por segundo sobre el mayor valor entre los recursos solicitados y el uso real; CPU y memoria pueden crecer si existe capacidad disponible. Hay límites superiores configurables. Nuestra recomendación es observar el consumo de una tarea representativa y fijar un presupuesto antes de ampliar concurrencia.
Es un servicio gestionado que requiere cuenta y puede generar consumo facturable. Aquí no se ha utilizado ni se han medido rendimiento, ahorro o seguridad. El criterio de adopción es resolver una necesidad de ejecución comprobada y revisar sus límites, no asumir que el nuevo entorno mejora la calidad del agente.