Guía gratuita

Agentes que trabajan mientras duermes: goals, loops y rutinas

Cómo llevo a los equipos del ping-pong de prompts a agentes que funcionan solos, con una meta clara, un horario y una revisión humana. Sirve para Claude Code y Codex.

Qué contiene

1. 1. Define qué es terminado antes de empezar

   • Escribe la meta como algo que el agente pueda demostrar: 'npm test termina con 0', no 'mejóralo'.
   • Delimita el alcance: qué carpetas, qué tickets y qué está prohibido.
   • Mete un límite en el propio objetivo, por ejemplo 'o para tras 20 turnos e informa de lo que falta'.

2. 2. Pon las reglas

   • Un archivo de instrucciones por repositorio con las reglas que el agente debe cumplir.
   • Solo ramas: el agente abre pull requests, nunca hace merge ni despliega en producción.
   • Ninguna credencial de producción, solo cuentas de prueba, y un presupuesto de tokens por ejecución.

3. 3. Elige el modo adecuado

   • Meta clara: un goal (/goal en Claude Code, goal mode en Codex).
   • Comprobación periódica mientras trabajas: un loop con intervalo, por ejemplo /loop 15m.
   • Tiene que funcionar con el portátil cerrado: una rutina en la nube, lanzada por horario, por una llamada a la API o por un evento de GitHub.

4. 4. Prueba con una persona mirando

   • Ejecútalo una vez de forma interactiva y lee cada paso.
   • Corrige las instrucciones donde el agente se equivocó, no solo el resultado.
   • Solo funciona sin supervisión cuando una prueba sale limpia.

5. 5. Déjalo funcionar solo

   • Empieza en pequeño: un repositorio, un tipo de tarea, como actualizar dependencias, arreglar tests fallidos o un informe nocturno.
   • Cada ejecución escribe un resumen corto: qué hizo, qué dejó y qué necesita a una persona.
   • Una alerta llega al chat del equipo cuando una ejecución falla o tarda mucho más de lo normal.

6. 6. Revisión antes de publicar nada

   • Una persona revisa y hace el merge, igual que con los pull requests de personas.
   • Reglas fijas: login, pagos, borrado de datos y permisos siempre necesitan a una persona.
   • Primero staging, luego producción, con smoke tests después de cada despliegue.

7. 7. Aprende y amplía

   • Cada error se convierte en una regla del archivo de instrucciones, para que la siguiente ejecución lo evite.
   • Mide las horas ahorradas, el coste por ejecución y el porcentaje de ejecuciones que necesitaron ayuda.
   • Añade el siguiente tipo de tarea solo cuando el actual lleve dos semanas funcionando sin sobresaltos.

8. Cómo implantarlo según el tamaño de la empresa

   • Startup: una rutina para el trabajo pesado, como actualizar dependencias, tests fallidos y el informe semanal. Suele estar en marcha en una semana.
   • Empresa mediana: un equipo piloto con archivos de instrucciones compartidos y un presupuesto de tokens, luego el resto de equipos.
   • Gran empresa: ajustes gestionados que los usuarios no pueden cambiar, una lista aprobada de modelos y herramientas, registros de auditoría y modelos locales para el código sensible.