Lo que tu agente puede hacer cuando le das una máquina

Un agente sin máquina te entrega código y una promesa. Escribe la función, te la explica bien, y ninguno de los dos sabe si corre. Tú la pegas en tu proyecto, falla por una dependencia, copias el error, se lo pegas de vuelta. Eso no es un asistente: es un compilador con muy mala latencia, y tú eres el bus de datos.

Dale una máquina y cambia de oficio. En vez de proponer, comprueba.

1. Ve el error real, no el que imagina

Con una caja conectada, el agente deja de razonar sobre lo que debería pasar:

La segunda llamada le devuelve el stderr de verdad, con el número de línea de verdad. Corrige y vuelve a correr, sin pasar por ti. El ciclo que antes eran cuatro mensajes tuyos ahora es una tool call suya.

Y lo hace en una microVM de Firecracker, no en un contenedor de un host compartido: su propio kernel, su propio filesystem, su propia red. Cuando tu agente decida instalar un paquete que nadie auditó, el postinstall hostil se queda adentro. La caja nace sin credenciales a propósito.

2. Te entrega algo que se puede abrir, no un bloque de código

Un agente que armó un dashboard tiene que enseñártelo. Levanta el server y pide una URL pública:

Con HTTPS válido, emitido solo. El identificador es imposible de adivinar: quien tiene el link entra, y nadie más. Tú abres la URL y ves la cosa funcionando; no lees un diff imaginando el resultado.

Fíjate en el exec delante del comando. Sin él el shell se queda como padre del proceso, y al matarlo la señal le llega al shell mientras el server sigue escuchando con el puerto ocupado. Nosotros lo aprendimos por las malas: nuestro propio kill cometía el error simétrico —señalaba al shell y no al grupo— y respondía "listo" mientras el proceso seguía vivo. Ahora señala al grupo entero, primero SIGTERM para que alcance a cerrar.

3. Vigila lo que dejó corriendo

Un build o un test suite no caben en una llamada. El agente los manda al fondo y los consulta cuando quiere:

El stdout que devuelve es acumulado, así que seguir el log en vivo es restar lo que ya leyó. Sin websockets ni agregador de logs. Y si perdió el execId entre turnos —le pasa—, sandbox_exec_list le dice qué está corriendo en la caja: eso es la diferencia entre un proceso que puede bajar y un proceso zombi que se come la máquina hasta que vence el TTL.

4. Prueba cinco caminos en vez de elegir uno

Aquí es donde un agente hace algo que tú no harías a mano por pereza. Prepara el entorno una vez, lo congela y arranca N hijos copy-on-write, cada uno con su IP:

Tres variantes de la misma prueba, en paralelo, sin repetir el npm ci. Cuando probar es barato, se prueba en vez de opinar.

5. Y cuando ya no alcanza, te pasa el teclado

Hay un punto en el que quieres las manos adentro. El agente inyecta tu llave pública en la misma caja que estaba usando y te deja entrar:

El sshd es fail-closed: sin llave inyectada no existe ni siquiera cerrado. Y el acceso viaja por el 443, el mismo puerto que una página web, porque un puerto alto no atraviesa la red de una oficina ni una VPN corporativa — y ese fallo te llega como un "no me conecta" que no puedes reproducir. El túnel no autentica: mueve bytes, y tu sesión se autentica punta a punta contra el sshd de la caja.

No es un handoff a otro entorno "parecido". Es la caja donde tu agente estuvo trabajando, con su filesystem intacto.

Por qué se atreve: reconstruir es barato

Nada de lo anterior sirve si equivocarse es caro. Estos son los tiempos medidos de una app de React Router real, no estimaciones:

La última fila es la que casi nadie enseña. Borra la máquina y vuelve en 11.9 segundos: el release lleva el código, el backup diario lleva los datos. Perder el fierro dejó de ser una catástrofe y pasó a ser un redeploy.

Un agente que puede reconstruir su máquina en doce segundos no necesita pedirte permiso antes de intentar algo. Prueba, se equivoca, tira la caja y arranca otra vez — y tú te enteras del resultado, no de cada paso.

Para conectarlo: si tu agente habla MCP, apúntalo a @easybits.cloud/mcp y tiene estas tools sin que escribas código. Si prefieres orquestarlo tú, es el mismo comportamiento vía SDK:

Las dos superficies hacen lo mismo, porque en Easybits lo que puede hacer la interfaz lo puede hacer el agente.