Siete agentes de IA se encargan de nuestras noches: agentes programados más allá del código, con los prompts

El 23 de septiembre, un usuario llamado Rob escribió en nuestro backlog público: «would love to get examples of how you guys are doing stuff beyond coding». Buena pregunta. Todo este sitio habla de agentes de código, y lo que de verdad hacemos funcionar cada tarde, en su mayor parte, no es código.

Desde el 28 de agosto, siete agentes arrancan en un Mac mini a las 20:00. Leen los commits del día, la Search Console, los paneles de administración, el backlog, el feedback que envió la gente, los informes de la noche anterior. Corrigen bugs, corrigen el sitio web, escriben y traducen un artículo de blog cada tres días, publican en tres redes sociales, actualizan una base de conocimiento del producto, y a las 22:00 el séptimo lee lo que dejaron los otros seis y envía un e-mail de 25 líneas. Nadie mira. El fundador lee el e-mail en su móvil a la mañana siguiente.

Este artículo es la respuesta a Rob. Qué funciona, cómo está conectado, cómo los agentes se pasan el trabajo sin hablarse nunca, qué modelo hace qué oficio y por qué, las cuatro reglas que sus prompts tuvieron que aprender por las malas, y los prompts mismos, condensados en bloques que puedes copiar. Cada cifra de abajo sale del repositorio: los informes están ahí con commit, noche tras noche.

Lo que han producido 33 noches

La carpeta de informes del repositorio tiene 33 directorios fechados, del 28 de agosto al 30 de septiembre. Leerlos da esto:

• 31 e-mails de la mañana enviados por el relator.
• 51 bugs corregidos por el corrector, cada uno con el enlace del commit en su línea del informe. Varios los habían reportado usuarios en el backlog público y recibieron una respuesta con la siguiente versión.
• 7 artículos de blog escritos por el equipo SEO desde el 10 de septiembre, uno cada tres días, cada uno primero en inglés y en francés, y luego en otros 18 idiomas la misma noche.
• 29 días de diario de redes sociales: tres redes y cinco grupos de Facebook por tarde, más un comentario de agradecimiento bajo cada publicación en la que un usuario compartió AgentsRoom.
• Una base de conocimiento del producto de un centenar de fichas, sincronizada con los commits del día, que lee el asistente integrado en la app y que el sitio sirve como llms-full.txt.

Nada de esto necesitó a un humano después de las 20:00. Una parte sí necesitó a un humano a las 08:00, y ese es todo el sentido del último agente.

La plantilla: quién arranca a las 20:00

Cada agente es una Tarea programada en AgentsRoom: un prompt, un agente (rol, CLI, modelo), una máquina y una hora. Los siete funcionan con Claude Code. Dos de ellos no son agentes sueltos sino equipos de dos pasos, y volveremos a por qué.

Los archivos .md de la última columna viven todos en reports/night/<date>/, con commit y push. Esa carpeta es todo el sistema de coordinación, y la sección siguiente explica por qué.

Cómo está conectado

Cada uno de los siete es una Tarea programada con la misma forma:

• Salta cada día a las 20:00 (22:00 para el relator). Sin expresión cron; la frecuencia se elige en el editor.
• Fijada a una sola máquina. El proyecto está abierto en varios ordenadores, y un disparador salta en cada máquina que lo tiene salvo que lo restrinjas. Los nuestros están restringidos al Mac mini, así que un portátil abierto a las 20:05 no arranca un segundo CEO.
• Despierta la máquina. El Mac mini duerme. La tarea tiene una opción «despertar la máquina», que programa un despertar con la herramienta propia del sistema operativo (pmset en macOS, el Programador de tareas con despertar para ejecutar en Windows, rtcwake en Linux) unos segundos antes de la ejecución. Sin ella, una máquina dormida simplemente se salta la ejecución.
• Recuperación activada o no, por tarea. Si la máquina estaba apagada a las 20:00, una tarea con recuperación activada salta en el siguiente arranque. El CEO, el PM y el relator la tienen activada. Las tareas SEO, corrector, social y documentación la tienen desactivada: una ejecución que empezara a las 11:00 de la mañana siguiente chocaría con el trabajo del día en el mismo checkout.
• El modo de permisos se ajusta en la tarea, no en el proveedor. Una ejecución desatendida no puede pararse en una petición de aprobación a las 3 de la madrugada, así que la tarea funciona sin ellas, mientras que los agentes que el fundador maneja a mano con el mismo CLI siguen preguntando primero.
• La consola se cierra tras 60 minutos de inactividad. Un agente que ha terminado no se queda en la barra lateral hasta que alguien lo cierre.
• El prompt es el primer mensaje. El texto de cada prompt está guardado en la Biblioteca de prompts y es el mismo texto que el campo prompt del disparador, así que editar uno es editar los dos. Los prompts están en francés, porque el fundador lee los informes en francés. Todo lo demás, de los mensajes de commit a la base de conocimiento, está en inglés.

Una última pieza la comparten los siete: una skill llamada «agentes nocturnos, reglas comunes». Cada prompt empieza con «carga esta skill y aplícala», y la skill contiene todo lo que vale para todos: quién se encarga de qué, la guarda «una noche, una ejecución», los derechos git, el formato del informe, las reglas del backlog y el formato del e-mail para el relator. Cuando una regla cambia, cambia en un solo sitio.

Cómo se pasan el trabajo sin hablarse

Los siete agentes nunca se envían mensajes. Podrían, AgentsRoom tiene una mensajería entre agentes, pero un mensaje es invisible a la mañana siguiente y no se le puede hacer grep. Todo pasa por tres cosas que sobreviven a la noche:

El repositorio. Cada agente escribe reports/night/<date>/<agent>.md, lo abre en el primer minuto de su ejecución, lo reescribe tras cada trabajo terminado, le hace commit y push. El informe tiene cuatro secciones fijas: «En dos palabras» (una lista de viñetas, una viñeta por cosa hecha), «A decidir» (solo lo que el prompt reserva al humano), «A verificar» (una URL local o una pantalla que abrir), «Detalles» (tan largo como haga falta). Termina con un marcador de ejecución: el último commit que vio el agente.

El backlog. Un agente que encuentra trabajo para otro no hace ese trabajo. Abre un ticket con una etiqueta: ceo-fix para un bug verificado y pequeño que tomará el corrector; ceo-seo para un trabajo de contenido con su consulta objetivo; ceo-decision para todo lo que necesita al humano (base de datos, facturación, auth, cifrado, precios, una URL indexada, un comportamiento por defecto). El documentalista, leyendo los commits, encuentra una feature sin página en el sitio: abre un ticket ceo-seo, y el SEO lo toma la noche siguiente. El CEO, leyendo los logs de errores, encuentra un bug con su causa en el código: ceo-fix, y el corrector lo toma la noche siguiente.

El informe de ayer. Antes de abrir cualquier trabajo, cada agente lee su propio informe de la noche anterior, más la lista de tickets cerrados durante el día. Lo que señaló ayer muchas veces se ha corregido durante el día. Un tema ya tratado no se vuelve a plantear; un ticket ya abierto no se vuelve a crear.

El ciclo se cierra con el humano. El e-mail del relator termina con una línea: para responder al product manager, añade una sección «## Decisiones» al final de rapport.md (P1 OK / P2 NO: motivo / P3 MÁS TARDE), commit, push. El PM lee la versión subida la tarde siguiente y ejecuta lo aprobado: crea el ticket, fusiona los duplicados, aparca el resto con el motivo. Una decisión que no recibe respuesta en tres noches es una decisión: la propuesta sale del e-mail y se queda como ticket.

Qué modelo hace qué oficio, y por qué

La tabla de arriba muestra dos modelos. Es la configuración actual, no un benchmark, y va cambiando. Pero el reparto es deliberado.

Fable donde el oficio es el criterio. El CEO decide si un pulgar abajo sobre un oráculo es un error real o una preferencia. El corrector decide si un reporte de bug es un bug o una configuración propia de una máquina, y luego encuentra la causa en el código. El paso 1 del SEO decide qué frase del sitio se ha vuelto falsa con el commit de hoy, qué artículo escribir y qué página dejar en paz. El paso 1 del Social elige el tema de la tarde y escribe para un público que detecta un texto generado en tres líneas. Estos prompts son largos (el del SEO tiene unas 4.000 palabras) y están llenos de reglas «tú decides, no preguntas» con listas cortas de excepciones. Ahí es donde el modelo más fuerte se gana su coste.

Opus con un contexto de 1M donde el oficio es el volumen. Traducir un artículo a 18 idiomas con subagentes, tres locales cada uno, y luego comprobar la fusión contra la referencia francesa, es leer y escribir, mucho, con las mismas reglas aplicadas 18 veces. El documentalista lee un día de diffs contra un centenar de fichas. El PM lee una exportación de 8 MB de conversaciones de salida. El relator lee cinco informes y copia, no piensa. Ahí, un contexto grande y un coste por token más bajo importan más que el criterio.

Dos de los siete son, por tanto, equipos de dos pasos, cada paso un agente con su propio modelo. El paso 1 con Fable termina escribiendo una sección «Traspaso» en el informe compartido: la lista exacta de archivos y claves que el traductor debe entregar, o las publicaciones exactas que el publicador debe publicar. El paso 2 con Opus lee esa sección y solo hace lo que enumera. El grafo del equipo es lineal, un solo ciclo, y el informe conserva su línea «ejecución en curso» hasta que el paso 2 la quita. Desde fuera, a las 22:00, un informe todavía marcado «en curso» significa o una ejecución cortada o un equipo entre sus dos pasos, y el relator dice cuál.

Las cuatro reglas que los prompts tuvieron que aprender

Los primeros prompts eran descripciones de puesto. Los actuales son sobre todo reglas, y cada regla tiene una fecha, porque cada una se escribió después de una noche que salió mal.

1. Un marcador de ejecución, leído en el informe de ayer. La primera versión del agente SEO leía «los commits de las últimas 24 horas». Dos problemas: una ejecución a las 20:00 y una a las 20:10 al día siguiente no ven las mismas 24 horas, y una noche en la que el agente no funcionó es un día de commits que nadie mira. Ahora cada informe termina con Último commit visto: <sha>, y la ejecución siguiente parte de ese commit, diga lo que diga el reloj. Sin marcador (primera noche, informe ausente): dos días atrás, y el informe lo dice.

2. El historial está en el disco, así que hazle grep antes de plantear nada. La queja que más volvió las dos primeras semanas: «ya me lo dijiste, lo corregí ayer». La solución es una regla con un comando dentro: antes de señalar un tema o abrir un trabajo, grep -ril "<el tema>" reports/night/ y git log --since="30 days ago" -- <el archivo>. Una coincidencia significa leer ese informe primero. Tres casos, y solo tres, permiten volver a hablar de un tema tratado: la corrección no funcionó y acabas de verificarlo; la corrección es parcial y nombras lo que queda; el tema cambió de naturaleza. Llegaron dos corolarios con ella. Una noche, una ejecución: si el informe de esta noche existe, contiene «En dos palabras» y ya no dice «ejecución en curso», el agente se detiene. Y una propuesta sin respuesta en tres noches sale del informe; el ticket se queda.

3. El informe se abre antes de empezar el trabajo. Una ejecución cortada a las 21:30 no dejaba nada. Ahora lo primero que hace un agente tras cargar la skill es mkdir -p reports/night/$(date +%F) y escribir el esqueleto del informe con sus cuatro títulos de sección y una línea ejecución en curso, iniciada a las 20:01. Reescribe el archivo entero tras cada trabajo terminado. Una ejecución cortada deja un informe parcial que el relator puede copiar, lo que es mucho mejor que un agente que «no se ejecutó».

4. Commit sobre la marcha, nunca al final. Medido el 9 de septiembre: dos agentes se detuvieron en el mismo minuto. El que hacía commit tras cada trabajo no perdió nada. El otro dejó 45 archivos modificados, sin push e imposibles de atribuir, que el fundador recogió a mano a la mañana siguiente, y su informe no existía. Desde entonces la regla es un commit por trabajo terminado, archivos nombrados uno a uno, un último commit para el informe, y al menos un push durante la ejecución. Un commit es también una huella fechada, y es lo que la regla 2 busca con grep.

Una quinta regla no trata de memoria sino de valentía, y es la que más cambió los resultados. El prompt del SEO dice: «No eres un auditor que reporta hallazgos: de noche, el sitio es tuyo. Una ejecución que termina con seis pistas por validar es una ejecución fallida». Luego enumera los seis casos, y solo seis, en los que el agente debe preguntar en lugar de actuar: borrar o renombrar una URL, cambiar el título de una página que posiciona, un texto legal, un precio o una cuota, una afirmación sobre privacidad o cifrado, un cambio que toque más de cinco páginas. Todo lo demás, lo hace, y el fundador quita lo que no le gusta a la mañana siguiente. El corrector tiene la misma regla con tres casos. Antes de esa regla, los informes eran listas de sugerencias. Después, son listas de commits.

Los prompts

Los originales están en francés y son largos. Lo que sigue es la parte que se puede trasladar, sin nuestras rutas ni nuestros nombres propios del proyecto. Tres bloques: las reglas comunes que carga cada agente, el relator, y las dos secciones «tú decides, no preguntas».

Bloque 1: las reglas comunes (cargadas por los siete como una skill)

# Agentes nocturnos: reglas comunes
Prevalecen sobre tu propio prompt si los dos se contradicen.

## Una noche, una ejecución
DAY=$(date +%F); F=reports/night/$DAY/<tú>.md
Si F existe, contiene «En dos palabras» y ya no contiene «ejecución en curso»:
detente. No escribas nada, no envíes nada, termina con un mensaje de una línea.
Si todavía dice «ejecución en curso»: es tu propia ejecución, cortada hace unos minutos.
Retómala donde se detuvo, no empieces de cero.

## Lo que puedes hacer
- Git: add <archivos nombrados>, commit, push de TU trabajo, sobre la marcha.
  Nunca: add -A, commit -a, push --force, stash, reset, checkout, clean, rama nueva.
- Build: typecheck, lint, scripts de control, un build local para verificar.
  Nunca: un script que despliegue o publique.
- Backlog: crear un ticket, añadir a un ticket, cerrar un ticket que hayas corregido.
  Nunca: responder a un usuario (eso envía un e-mail), borrar un ticket, sobrescribir una descripción.
- Nunca una cifra inventada. Fuente no disponible: dilo y sigue.
- Antes de cualquier escritura git: git status --short. El árbol se comparte con otros agentes.

## Ponerse al día, y saber lo que YA se hizo
git fetch && git status -sb
Atrasado y limpio: git pull --ff-only. Atrasado y sucio: no hagas pull, dilo al principio de tu informe.
Tu marcador de ejecución: la línea «Último commit visto: <sha>» al final del informe de ayer.
Sin marcador: --since="2 days ago", y dilo.
Tres lecturas obligatorias antes de cualquier análisis:
1. git log --no-merges --format='%h %s' <sha>..HEAD y git diff --stat <sha>..HEAD
2. los tickets cerrados desde ayer, y los tickets que un humano puso en espera
3. tu propio informe de ayer: «En dos palabras» y «A decidir»

## La carpeta de informes ES tu historial
Antes de plantear un hallazgo o abrir un trabajo:
grep -ril "<tema>" reports/night/ | sort | tail -5
git log --since="30 days ago" --oneline -- <el archivo>
Una coincidencia: lee ese informe antes de decidir nada.
Dos noches seguidas sobre el mismo tema: la segunda se pierde.
Una página o un texto que tocaste no se vuelve a tocar en tres semanas,
salvo para corregir algo que se ha vuelto falso.

## Nunca plantees dos veces lo mismo
Un hallazgo ya tratado que vuelve al día siguiente es una falta.
Solo tres casos lo permiten:
1. la corrección no funcionó, y acabas de verificarlo: «corregido el <fecha> por <commit>, sigue roto: <prueba>»
2. la corrección es parcial: nombra exactamente lo que queda
3. el tema cambió de naturaleza: nueva causa, nueva medida, nuevo alcance
No vuelvas a contar un stock. Informa de la variación, nunca del stock.

## Una propuesta sin respuesta muere a las tres noches
Noches 1 a 3: la línea lleva su contador y su primera fecha («2.ª noche, planteada el 07/09»).
Desde la 4.ª: sale de «A decidir». El ticket se queda; como mucho una línea en «Detalles».
Si la decisión te corresponde, decide la 3.ª noche y dilo.

## Commit y push sobre la marcha
Primer commit en cuanto el primer trabajo esté terminado y verificado. Luego uno por trabajo.
Último commit para tu informe. Haz push al menos una vez durante la ejecución y una vez al final.
Push rechazado (el remoto ha avanzado): git pull --ff-only, luego push. Sigue rechazado: no fuerces,
no hagas rebase, escríbelo en el informe.

## Tu informe: abierto al principio, nunca escrito solo al final
reports/night/<YYYY-MM-DD>/<tú>.md, creado ANTES del trabajo, con:
  # <Agente> - <fecha>
  _ejecución en curso - iniciada a las <HH:MM>_   (se quita al final)
  ## En dos palabras   (3 a 5 líneas, o una lista de viñetas: una viñeta por cosa hecha)
  ## A decidir         (solo lo que tu prompt reserva al humano; si no, «Nada»)
  ## A verificar       (- [ ] qué : dónde : qué se debe ver; si no, «Nada»)
  ## Detalles          (tan largo como haga falta: pruebas, archivos, comandos)
  ## Marcador de ejecución
  Último commit visto: <git rev-parse HEAD tras tu último commit>
Reescribe el archivo entero tras cada trabajo terminado.
El lector está en un móvil, durante dos minutos: frases cortas, sin rutas de archivo,
sin SHA, sin nombres de función en la primera sección. Una cifra solo si cambia una decisión.

Bloque 2: el relator (22:00)

Eres el relator. Te ejecutas dos horas después de los demás.
Tu único trabajo: leer lo que dejaron y enviar UN e-mail que el fundador lee
en un minuto en un móvil, y que entiende sin abrir nada más.
No analizas nada, no corriges nada, no propones nada. Reúnes y aclaras.

La noche de la que informas se lee en el disco, no en el reloj:
DAY=$(ls -1 reports/night | sort | tail -1)

1. git fetch; git pull --ff-only si el árbol está limpio: los informes tienen commit.
2. ls reports/night/$DAY: espera los cinco archivos (ceo, seo, pm, fixer, social).
   Falta alguno: sleep 9 minutos y vuelve a contar, 6 rondas como máximo. Luego envía de todos modos, nombrando quién falta.
3. Un informe que todavía dice «ejecución en curso» es una ejecución cortada, no una ausente.
   Copia lo que contiene y escribe en «Lo que no funcionó» que ese agente fue cortado.
4. De cada informe toma solo tres secciones: «En dos palabras», «A decidir», «A verificar».
   Nunca cites «Detalles».
5. Los bugs corregidos del corrector son viñetas en tres partes separadas por « > »:
   lo que sufría el usuario > la causa en una frase > la URL del commit.
   Cópialas carácter por carácter, enlace incluido, en «Bugs corregidos».
6. git status -sb y git log --oneline --since="4 hours ago": un informe que declara
   trabajo sin commit, archivos modificados que nadie reclama, o commits sin push: primera línea del e-mail.

Escribe reports/night/$DAY/rapport.md. 25 líneas de texto como máximo
(los títulos de sección y las líneas de «Bugs corregidos» no cuentan).
Seis reglas, aplicadas línea por línea:
1. Una viñeta = una frase completa que se entiende sola. Nunca «como se dijo ayer».
2. Un tema aparece en UNA sola sección.
3. Cero jerga: sin rutas, sin SHA, sin nombres de clave, sin abreviaturas internas.
   Una excepción: la URL completa de GitHub de un commit, obligatoria en cada línea de «Bugs corregidos».
4. Una cifra solo si cambia una decisión, y es una variación, nunca un stock.
5. Dos líneas como máximo por viñeta. El detalle está en el informe del agente.
6. Las malas noticias antes que las buenas, y la primera línea dice si algo está roto.

Secciones, en orden: A decidir / A verificar / Bugs corregidos / Lo que se hizo /
Redes sociales (3 líneas máx., enlaces incluidos) / CLI y modelos (1 línea) /
Lo que no funcionó. Una sección vacía es una palabra: «Nada».
Nunca recortes: «A decidir», «Bugs corregidos» con enlaces, los enlaces de las publicaciones, el artículo SEO.
Envía. Comprueba el código HTTP. Añade «Enviado a ... - HTTP <code>» al final.
Commit y push de rapport.md. Nunca envíes dos veces: si el rapport.md de hoy ya tiene
una línea «Enviado a», detente.

Bloque 3: las secciones «tú decides, no preguntas»

El agente SEO, sección 0 de su prompt:

# 0. Tú decides, no preguntas
Es la regla más importante de este prompt y prevalece sobre tu reflejo de prudencia.
No eres un auditor que reporta hallazgos: de noche, el sitio es tuyo.
Una ejecución que termina con «aquí tienes 6 pistas, por validar» es una ejecución fallida.
Cuando dudes, ponte en el lugar del fundador y decide con cuatro referencias:
- lo que el producto hace de verdad, leído en el repositorio y en la versión publicada, nunca en el copy existente;
- lo que el sitio ya dice: su ángulo, su tono, sus promesas. Prolongas, no reinventas;
- lo que dice la Search Console: qué páginas viven, qué intenciones existen de verdad;
- el público: desarrolladores que buscan en Google, y los asistentes de IA que recomiendan herramientas.
  Lo que cuenta para ellos: una afirmación verificable y fechable; una página que responde a una pregunta precisa;
  un llms.txt al día y coherente con las páginas; comparaciones honestas.
El fundador lee tu informe a la mañana siguiente y te dirá que quites lo que no le guste.
Una corrección de más cuesta cinco minutos; una noche sin resultados se pierde para siempre.

Solo pides su opinión en estos seis casos:
1. borrar o renombrar una URL existente;
2. cambiar el título o la meta description de una página que posiciona, cuando no es falso;
3. un texto legal (condiciones, privacidad, licencia);
4. un precio, una cuota comercial, una oferta;
5. una afirmación sobre privacidad, cifrado o dónde se procesan los datos;
6. un cambio que tocaría más de cinco páginas a la vez.
En esos seis casos: un ticket etiquetado para decisión, una línea en «A decidir», y sigues.
Todo lo demás, lo haces esta noche. Si «A decidir» contiene otra cosa,
has delegado una decisión que era tuya.

El corrector, sección 0 de su prompt:

# 0. Tú corriges, no clasificas
Un bug reportado por un usuario es una promesa. Alguien se tomó el tiempo de escribir, está esperando,
y nadie más se va a ocupar de él esta noche. Una ejecución que devuelve «5 bugs analizados, 1 corregido,
4 documentados» es una ejecución fallida. Tu objetivo es la cola vacía: primero los bugs de los usuarios,
del más antiguo al más reciente, luego el resto, hasta que no quede ninguno.
Cuando dudes sobre una corrección, decide con tres referencias:
- lo que hace el código hoy, leído, no supuesto;
- lo que el usuario esperaba claramente al escribir el reporte;
- el menor riesgo: la corrección más acotada que resuelve la causa, no la más elegante.
Una corrección discutible cuesta cinco minutos deshacerla; un bug que se queda un mes más cuesta un usuario.

Solo puedes dejar un bug reportado sin corregir en tres casos, demostrados en el ticket:
1. no encontraste la causa tras una investigación real: escribe lo que descartaste,
   no solo «no reproducible»;
2. no es un bug, es una decisión: base de datos, facturación, auth, cifrado, privacidad,
   una URL indexada, un comportamiento por defecto. Ticket para decisión, con tu recomendación;
3. un control rechaza tu corrección y no sabes repararlo.
«Es grande», «toca varios archivos», «prefiero preguntar» no son motivos.
Un bug = un commit. Luego el ticket pasa a terminado, y si lo reportó un usuario,
se deja en cola un mensaje de dos frases para la siguiente versión. Nunca «en espera»: esa columna
es de los humanos.
Tu línea de informe para cada bug corregido, copiada tal cual en el e-mail de la mañana:
- <lo que sufría el usuario> > <la causa, en una frase sencilla> > <URL del commit>

Los otros cuatro prompts (CEO, PM, documentalista, paso 2 del SEO) siguen el mismo esqueleto: carga la skill, nombra los archivos que puedes escribir, enumera las lecturas en orden, di qué va en el ticket y qué va en el informe, termina con el marcador de ejecución.

Lo que no funcionó, y sigue sin funcionar

Algunas noches aparecen en la sección «Lo que no funcionó» del e-mail, y vale la pena enumerarlas porque es con lo que te vas a encontrar.

• Cinco agentes haciendo push a la misma rama en el mismo minuto. Un push se rechaza porque el remoto ha avanzado. La regla es git pull --ff-only y luego push, nunca forzar, y si falla dos veces el informe lo dice y el humano hace push por la mañana. Pasa más o menos una vez por semana.
• Un commit que arrastró un archivo en staging de otro agente. El 29 de septiembre, el primer commit del SEO se llevó un borrado que el documentalista había dejado en staging en el checkout compartido. No se perdió nada (el borrado era intencionado), pero el commit se atribuye al agente equivocado. Desde entonces cada commit usa rutas explícitas, y la regla «archivos nombrados uno a uno» no es una preferencia de estilo.
• Un disco que llegó a cero bytes libres a las 20:10, dos tardes seguidas. Ajeno a los agentes, se recuperó solo a las 20:25, ningún archivo perdido. Pero los informes lo dicen, porque una noche con el disco lleno se parece exactamente a una noche en la que un agente no hizo nada.
• El relator esperando 54 minutos un informe que no va a llegar. Seis rondas de nueve minutos es el tope. Un equipo entre sus dos pasos a las 22:00 parece una ejecución cortada, y el e-mail dice «no había terminado», lo que es honesto y un poco alarmante de leer.
• Las primeras semanas de hallazgos repetidos. La regla 2 de arriba no existió hasta que el fundador escribió «me dijiste esto hace tres días» por cuarta vez.

Cómo montarlo tú mismo

No necesitas siete agentes. Necesitas uno que escriba un informe que vayas a leer, y un relator solo es útil a partir del tercer agente. En AgentsRoom:

1. Escribe el prompt en la Biblioteca de prompts. Empieza por el bloque 1 de arriba como skill, y un prompt corto que diga de qué se encarga este agente y qué archivos puede escribir.
2. Crea una Tarea programada en el proyecto: diaria a la hora que quieras, el rol, el CLI y el modelo del agente, el prompt, y en el bloque avanzado el modo de permisos para una ejecución desatendida. Fíjala a la máquina que la va a ejecutar, y activa «despertar la máquina» si esa máquina duerme.
3. Crea la carpeta reports/night/ en el repositorio y hazle commit. Esa es toda la capa de coordinación.
4. Añade un segundo agente el día en que el primero empiece a producir tickets para otro: una etiqueta ceo-fix solo significa algo cuando un corrector la lee la noche siguiente.
5. Cuando un oficio se divide en criterio y volumen, conviértelo en un equipo de dos pasos con dos modelos, y haz que el paso 1 escriba una sección de traspaso que lea el paso 2.

La página de Tareas programadas describe los campos, y el artículo sobre poner agentes de código en el turno de noche es el razonamiento que vino antes de la plantilla. Si tus agentes comparten una máquina, lee primero qué pasa cuando diez de ellos lanzan el mismo comando: pasó aquí, de noche, y la solución es un pequeño bloqueo compartido.

Rob, esto es lo que hacemos más allá del código. Los prompts son el producto.

Preguntas frecuentes

¿Hace falta AgentsRoom para lanzar agentes a una hora fija así?

No. Una línea de cron y claude -p arrancan una sesión de Claude Code a las 20:00 en cualquier máquina. Lo que escribes tú después es el resto: despertar un ordenador dormido, recuperar una ejecución que la máquina se saltó, mantener una sola ejecución por noche cuando el proyecto está abierto en dos ordenadores, pasar un informe de un agente a un segundo agente con otro modelo, y ver en tu móvil que la ejecución está bloqueada en una pregunta. Las Tareas programadas de AgentsRoom cubren esas piezas, y los siete agentes de este artículo las usan todas. Los prompts y las reglas se trasladan tal cual, sea lo que sea lo que arranque la sesión.

¿Cuánto cuesta una noche de siete agentes?

Funcionan como sesiones de Claude Code con una suscripción de Claude, como cualquier agente que lances en AgentsRoom, así que no hay factura por token para ellos, y no hemos publicado un coste por noche. La regla que lo acota es la guarda «una noche, una ejecución»: un disparador que salta dos veces, o una ejecución cortada y relanzada, no repite el trabajo, porque lo primero que hace cada agente es comprobar si el informe de esta noche ya existe y está cerrado.

¿Es seguro dejar que los agentes hagan commit y push sin nadie delante?

Es seguro por lo que no tienen permitido hacer, no por lo que se les pide que quieran. Las reglas comunes prohíben git add -A, commit -a, el push forzado, stash, reset, checkout, clean, crear una rama y cualquier script que despliegue. Cada commit nombra sus archivos uno a uno, el árbol se inspecciona con git status antes de cualquier escritura, y un push rechazado porque el remoto ha avanzado se resuelve con un pull en fast-forward o se deja al humano. La revisión de la mañana es la lista de commits de la noche, y lo que esté mal es un revert de cinco minutos.

¿Por qué los agentes escriben informes Markdown en el repositorio en lugar de un panel?

Porque el informe también es la memoria. Cada agente empieza leyendo su propio informe de la noche anterior, encuentra ahí su marcador de ejecución (el último commit que vio), y hace grep en toda la carpeta de informes antes de plantear nada, así que un tema tratado la semana pasada no se vuelve a plantear. Un panel mostraría las mismas cifras y no recordaría nada. Hacer commit del informe también lo fecha, y eso es lo que permite a la noche siguiente saber exactamente qué tocó la anterior.

¿Por qué dos de los siete agentes son equipos de dos pasos con dos modelos distintos?

Porque las dos mitades del trabajo no son el mismo trabajo. El paso SEO que lee la Search Console, decide qué es falso en el sitio y escribe el artículo en inglés y en francés necesita criterio, y funciona con Fable. Traducir ese artículo a otros 18 idiomas, pasar los controles i18n y el build es volumen, y funciona con Opus con un contexto de 1M. El primer paso escribe una sección de traspaso explícita en el informe compartido, el segundo solo hace lo que esa sección enumera. El mismo reparto para el equipo Social: redacción y visual con Fable, publicación en Chrome y agradecimientos con Opus.

¿Qué pasa cuando una ejecución se corta a mitad?

El informe existe desde el primer minuto de la ejecución, con una línea que dice «ejecución en curso», y cada trabajo terminado se sube con commit al momento. Así que una ejecución cortada a las 21:40 deja un informe parcial, sus commits y ningún archivo sin seguimiento. El relator copia el informe parcial y escribe que el agente fue cortado. Lo aprendimos por las malas el 9 de septiembre: dos agentes se detuvieron en el mismo minuto, el que hacía commit sobre la marcha no perdió nada, el otro dejó 45 archivos modificados que nadie podía atribuir.