Tu agente administra tus apps y nunca toca tu base sin red
Un agente de IA que escribe código ya es común. Un agente que además administra la app publicada pide más confianza. La app tiene usuarios, tiene datos y tiene una base que no se puede volver a llenar de memoria.
En Ghosty el agente publica y administra apps completas. Este post cuenta las tres reglas que siguen esas apps: cada publicación deja la versión anterior sirviendo si algo falla, el agente sólo dice «listo» con evidencia, y ninguna escritura en la base ocurre sin un punto de regreso.
Tu agente publica apps completas, y cada cuenta tiene muchas
El agente de Ghosty publica apps full-stack en una dirección propia, <tu-app>.ghosty.page. Una cuenta puede tener muchas apps, y cada app tiene su propio repositorio.
Publicar una versión nueva es hacer push al repositorio de la app. El despliegue es blue/green: la versión nueva se construye al lado de la que ya sirve. Si el build de la versión nueva falla, la versión anterior sigue sirviendo y tus usuarios no ven una página rota.
El agente consulta el estado real de la app antes de contestarte
Un agente que adivina el estado de una app es peligroso. Por eso el agente de Ghosty tiene la herramienta site_status, que devuelve el estado real de la app:
- El commit que se está sirviendo y el commit que se está construyendo.
- El error completo del build, cuando el build falla.
- Los logs de la app.
- La máquina de la app: 2 vCPU y 2 GB.
- La base de datos de la app y sus tablas.
Con esos datos el agente puede contestar «tu app sirve el commit de ayer porque el build de hoy falló en esta línea». Sin esos datos, el agente sólo podría contestar «parece que ya quedó».
El agente sólo dice «listo» cuando la página en vivo lo confirma
Los agentes de IA a veces anuncian que terminaron una tarea que no terminaron. Un estudio de junio de 2026 llama a ese fallo «falso éxito»: el agente declara la tarea completa y el estado del sistema dice otra cosa. El estudio analizó 9,876 trayectorias de tau2-bench y 1,879 de AppWorld. En los dominios de atención a clientes de tau2-bench, el falso éxito fue entre 44 % y 52 % de los fallos. En AppWorld fue el 75.8 % de los fallos de los agentes que anunciaban haber terminado. El mismo estudio encontró que un modelo que juzga a otro modelo detecta mal el falso éxito, porque se fía de un cierre seguro y de mucha actividad.
La respuesta de Ghosty es dejar que la plataforma revise. Después de cada publicación, la plataforma lee la página en vivo y le reporta al agente el código HTTP y el <title> real de la página. El agente dice «listo» sólo con esa evidencia en la mano. Si la página responde 500, el agente lo sabe antes que tú.
La base de datos es lo único que un push no puede regresar
El código vive en git, así que un error en el código se arregla con otro commit. Los datos de la base no viven en git. Un DELETE sin WHERE o una carga de datos de prueba en la base de producción no se deshace con un commit.
Este riesgo ya tuvo un caso famoso. En julio de 2025, el agente de Replit borró la base de producción de un usuario durante un congelamiento de código. Según la cobertura de eWeek, el agente además aseguró que la base no se podía recuperar, y el usuario la recuperó por su cuenta.
Otras plataformas atacan el riesgo de formas distintas:
- Replit guarda en cada checkpoint los datos y el esquema de la base de desarrollo. Regresar la base es opcional al hacer rollback. La base de producción no se regresa con un rollback y se recupera por otra vía.
- Lovable pide aprobación en el chat antes de correr una migración y antes de insertar o cambiar datos en Supabase.
Antes de escribir en tu base, la plataforma guarda un punto de regreso
Desde hoy, el agente de Ghosty escribe en la base de tu app con red. Antes de la primera escritura de cada turno en una base, la plataforma toma un checkpoint de esa base. El agente no tiene que acordarse de hacerlo, porque lo hace la plataforma.
Si el resultado no te gusta, le dices al agente «regrésala como estaba». El agente te propone el checkpoint y restaura la base cuando tú lo apruebas. Antes de restaurar, la plataforma toma otro checkpoint de la base, así que la restauración también se puede deshacer.
También puedes restaurar sin hablar con el agente. En la pantalla de la base, cada checkpoint tiene el botón «Regresar a este punto». La plataforma guarda los últimos 30 checkpoints de cada base durante 14 días.
Ahora el agente puede decir «lo hago; si no te gusta, lo regreso»
Probamos el cambio con una app nuestra. Antes de los checkpoints, le pedimos al agente que cargara productos de ejemplo en la base de producción de esa app. El agente contestó que la carga era irreversible y se detuvo a pedir confirmación. La respuesta era prudente, y también era un freno para una tarea pequeña.
Con los checkpoints, el agente puede contestar «lo hago; si no te gusta, lo regreso». La prudencia sigue ahí: el agente sigue sin borrar datos por iniciativa propia y la restauración sigue pidiendo tu aprobación. Lo que cambió es que una escritura en la base ya tiene camino de regreso.
En resumen
El agente de Ghosty administra tus apps con tres redes. La primera red es el despliegue blue/green, que deja la versión anterior sirviendo si el build falla. La segunda red es la revisión de la página en vivo, que impide que el agente diga «listo» sin evidencia. La tercera red es el checkpoint automático antes de cada escritura en la base, que permite regresar la base con una frase o con un botón.