Cómo automatizo mi propio trabajo con bucles de agentes

Por qué automatizo con bucles

La mayor parte de mi trabajo es juicio: decisiones de arquitectura, compromisos, saber qué problema vale realmente la pena resolver esta semana. Pero una parte sorprendente no lo es. Es la misma coordinación, las mismas comprobaciones, los mismos pequeños informes, repetidos con una periodicidad. Ese trabajo no me necesita. Necesita un bucle fiable que nunca olvide un paso y nunca se aburra en la cuarta repetición.

Un bucle, en el sentido que uso aquí, es un agente que ejecuta la misma tarea una y otra vez: con un temporizador, a su propio criterio de ritmo, o con una programación fija en la nube. Me apoyo en tres de ellos cada día. El resto de este artículo es cómo los configuro y, igual de importante, dónde los detengo.

Los tres bucles que realmente uso

El primero es un bucle de intervalo fijo: una tarea que se ejecuta cada N minutos dentro de una sesión activa. El segundo es un bucle autorregulado: la misma idea, pero el modelo decide cuánto esperar antes de la siguiente ejecución según lo que esté esperando. El tercero es un agente programado en la nube: una tarea acotada que se ejecuta de forma desatendida con una programación cron, sin ninguna terminal abierta.

Cada uno cambia inmediatez por autonomía. Un bucle de intervalo fijo está ahí delante de mí y es fácil de interrumpir. Un agente programado se ejecuta mientras duermo, pero hay que confiar en que termine solo. Elegir el adecuado depende sobre todo de lo de cerca que necesito vigilar el trabajo mientras ocurre.

Ejecutar un bucle en una sesión activa

Los bucles más simples viven en una sesión que tengo abierta. Cuando necesito vigilar algo que cambia por sí solo, un despliegue que termina, una ejecución de CI que se pone en verde, una cola que se vacía, lo pongo en un intervalo fijo. En Claude Code el comando es /loop con un intervalo y un comando o prompt:

/loop 5m /babysit-prs

Eso ejecuta la tarea cada cinco minutos hasta que la detengo. La única regla que importa aquí es ajustar el intervalo a lo rápido que cambia de verdad el estado. Sondear un despliegue cada treinta segundos cuando tarda ocho minutos solo gasta trabajo sin información nueva. Si lo que vigilo se actualiza cada pocos minutos, lo compruebo cada pocos minutos, no cada pocos segundos.

A veces no conozco el intervalo correcto de antemano, o cambia a medida que avanza la tarea. Para eso quito el intervalo por completo y dejo que el modelo marque su propio ritmo, programando su propio despertar según lo que esté esperando:

/loop vigila el despliegue de staging y avísame en cuanto termine

El instinto útil aquí es pensar en ventanas de caché, no en números redondos. Una espera de menos de cinco minutos mantiene el contexto de trabajo caliente, así que es barato volver a comprobar a menudo mientras algo se mueve activamente. Una espera más larga paga por recargar el contexto, así que solo compensa cuando de verdad no hay nada que hacer hasta entonces. El error es el punto medio: esperar exactamente cinco minutos paga el coste de recarga sin comprar mucho tiempo inactivo. Así que o vuelvo a comprobar rápido o me comprometo a una pausa real, y dejo que el bucle decida cuál.

Programar agentes en la nube

Los bucles anteriores viven en una sesión que tengo abierta. El trabajo que se ejecuta mientras duermo es distinto: va a un agente programado en la nube, una rutina con una programación cron que se ejecuta de forma desatendida. Una clasificación matutina de pull requests, un resumen nocturno de nuevos errores, una revisión semanal de dependencias. No tengo que estar ahí, y no hay terminal que mantener abierta.

Un agente programado solo funciona si la tarea es clara y acotada, y si tiene un sitio claro donde dejar su resultado. Instrucciones vagas más ninguna audiencia producen trabajo que nadie lee. Así que cada rutina responde a dos preguntas antes de programarla: qué exactamente queda hecho cuando esto termina, y dónde aterriza el resultado, un mensaje de Slack, un borrador de correo, un archivo que veré por la mañana. Si no puedo responder a ambas, todavía no está lista para ser un bucle.

Los principios que mantienen seguro un bucle

La automatización que se ejecuta sin que yo vigile es tan buena como las protecciones que la rodean. Cinco reglas cargan con casi todo el peso.

Idempotente: cada ejecución debe ser segura de repetir. Diseño la tarea para que una doble ejecución no cobre dos veces, ni publique dos veces, ni duplique nada. El bucle debería poder ejecutarse dos veces por accidente y dejar el mundo en el mismo estado.

Acotado: cada bucle necesita una condición de parada o una reserva razonable, o gira para siempre. Un bucle que espera un evento también recibe un máximo de espera, para que una dependencia atascada no se convierta en un sondeo infinito.

Escalar excepciones: el bucle gestiona lo rutinario y avisa a una persona ante lo realmente inusual. Es el mismo patrón que usan mis agentes de Plain Freight para llevar los envíos, la máquina gestiona el noventa por ciento predecible y una persona recibe el diez por ciento que no lo es.

Observable: un bucle que no puedes ver es un bucle en el que no puedes confiar. Cada ejecución deja un rastro, un mensaje, una línea de log, un estado, para poder reconstruir lo que hizo sin volver a ejecutarlo.

Manual primero: ejecuto una tarea a mano hasta entender sus casos límite, y luego la envuelvo en un bucle. Automatizar un proceso que aún no entiendo solo automatiza los errores más rápido.

Dónde termina el bucle y empiezo yo

La línea que trazo es simple. Los bucles gestionan lo repetible, yo gestiono el juicio. Un bucle puede perseguir un despliegue, resumir errores nocturnos y dar un toque a un pull request atascado sin mí. No puede decidir si un compromiso vale la pena, si un riesgo es aceptable, o cuál de tres problemas merece mi semana. Eso es criterio, y el criterio no entra en bucle.

Bien hecho, esto es apalancamiento, no pereza. Cada paso repetitivo que entrego a un bucle fiable es una hora que recupero para el trabajo que de verdad necesita a una persona. El objetivo nunca fue quitarme del trabajo. Fue quitarme de las partes que nunca me necesitaron para empezar.