Agente de IA autónomo: cómo dejarlo trabajar horas sin producir basura

Qué es un agente de IA autónomo y en qué se diferencia de una petición normal

El trabajo habitual con un agente es paso a paso: escribe un prompt, el agente da un paso, usted revisa el resultado y decide qué sigue. Un agente de IA autónomo trabaja en un bucle: usted describe una vez cómo es el estado final y, a partir de ahí, el agente repite «hacer, comprobar, corregir» hasta alcanzar el objetivo o agotar el presupuesto. Desde el momento del lanzamiento puede irse.

Suena sencillo, pero la primera experiencia suele ser esta: el agente recibe la tarea por la mañana y por la tarde se descubre que ha pasado horas corrigiendo un error que ya estaba arreglado, porque olvidó lo que hizo una hora antes. Nadie le dijo cuándo parar y cuándo llamar a una persona. A continuación, cómo diseñar un ciclo que evite eso.

Una advertencia importante: el ciclo no sustituye al harness. El harness hace fiable una sola ejecución; el ciclo hace que las ejecuciones sean continuas. Un ciclo sobre un harness malo solo produce basura más deprisa.

Si una tarea sirve para un agente autónomo

La primera pregunta es si el trabajo tiene una meta final que una máquina pueda comprobar. «Todas las pruebas de tests/payments pasan», «todas las funciones de la lista están en estado passing», «la métrica subió respecto a la línea base»: sirve. «Mejora el código» o «sigue mejorando los pagos»: no sirve. Esa meta no tiene fin, y el ciclo girará hasta agotar el presupuesto.

Conviene distinguir cuatro tipos de ciclo:

• Paso a paso: usted escribe cada prompt; es el trabajo interactivo habitual.
• Por objetivo: usted fija la meta y la detienen una comprobación independiente o un presupuesto. Es el agente autónomo de varias horas.
• Por tiempo: se lanza según un horario (por ejemplo, una revisión matinal de los builds de CI que fallaron) y usted lo detiene a mano.
• Por evento: un disparador externo (una issue nueva, un despliegue fallido) lo arranca, y lo detienen el fin del procesamiento del evento o un límite de reintentos.

Un error frecuente es confundir el ciclo por tiempo con el ciclo por objetivo: «cada 10 minutos sigue haciendo los pagos». Un ciclo programado empieza la instrucción desde cero en cada ejecución y no sabe qué ya se hizo. Si la tarea tiene un final, necesita un ciclo por objetivo con memoria del progreso.

Paso 1. Sandbox: dónde el agente puede equivocarse

Un agente que trabaja sin supervisión tarde o temprano hará algo mal: borrará un archivo, reescribirá una migración, lanzará un comando pesado. Por eso la pregunta no es «cómo hacer que no se equivoque», sino «cómo hacer que el error no cueste nada».

• Copia de trabajo aparte. git worktree le da al agente su propio directorio y su propia rama sobre el mismo repositorio. La rama principal no se toca, varios agentes no se estorban y una ejecución fallida se elimina con un solo comando.
• Contenedor o máquina virtual. Si el agente necesita acceso completo a comandos, ejecútelo en un contenedor sin acceso a su directorio personal, sus claves ni las bases de datos de producción.
• Datos de prueba. Base de datos local, sandboxes de los proveedores de pago, claves ficticias. Ni un solo secreto de producción en el entorno del agente.

# rama y directorio propios para una ejecución autónoma
git worktree add ../shop-agent -b agent/f03-refunds

# después de la ejecución: revisar el resultado o descartarlo
git -C ../shop-agent log --oneline main..
git worktree remove ../shop-agent

Paso 2. Permisos: el mínimo que necesita la tarea

Cuanto más tiempo trabaja el agente solo, más estrechos deben ser sus permisos. En Claude Code los permisos se configuran en settings.json (listas allow y deny para herramientas y comandos): autorice explícitamente lo que la tarea necesita, como ejecutar pruebas, el linter o editar archivos en la copia de trabajo, y prohíba lo peligroso: el push a la rama principal, el acceso a secretos y los comandos de red si no hacen falta.

El modo en que el agente ejecuta todo sin pedir confirmación solo es admisible dentro de un sandbox aislado, donde el peor resultado es un contenedor desechado. En una máquina de trabajo con acceso a sus claves y repositorios, eso no se debe hacer.

Las prohibiciones que no pueden romperse se refuerzan con mecanismos, no con texto. La frase «no toques migrations/» en una instrucción es un deseo; un hook que bloquea la edición de ese directorio o los permisos del sistema de archivos son una garantía.

Paso 3. Objetivo, verificación, parada: tres líneas antes de lanzar

Un ciclo de trabajo sencillo se sostiene en tres cosas, y conviene escribirlas antes de arrancar, no sobre la marcha:

1. Objetivo: cómo es el estado final.
2. Verificación: una forma comprobable por máquina de saber que el objetivo se ha cumplido, es decir, un comando que devuelve éxito o error.
3. Condición de parada: un límite de intentos, de tiempo o de dinero a partir del cual el ciclo se detiene aunque el objetivo no se haya cumplido.

Es útil guardar esto en un archivo de metodología que solo modifica una persona. Ejemplo para un backend de pagos:

# program.md — metodología de la ejecución autónoma

## Objetivo
Todas las funciones de .agent/feature_list.json en estado passing.

## Métrica
Número de funciones en passing. Crece de forma monótona. Regresión = revertir de inmediato.

## Restricciones
- Una sola función en curso a la vez.
- No modificar migrations/ ni infra/.
- No tocar dependencias sin registrarlo en el diario.

## Orden de trabajo
1. Tomar la primera función que no esté en passing.
2. Implementarla, ejecutar pytest y el linter.
3. Si está en verde: commit y registro en .agent/progress.md. Si está en rojo: corregir.

## Parada y escalado
- 3 intentos fallidos con una misma función: marcarla como blocked y pasar a la siguiente.
- Si todas las restantes están blocked: detenerse y escribir un informe.
- Cualquier tarea sobre dinero de clientes, permisos de acceso o borrado de datos: no hacerla, escalarla.

Paso 4. Bucle comprobar y corregir con memoria en disco

La ventana de contexto no sobrevive a un trabajo largo: se llena, se comprime, la sesión se reinicia. Por eso el progreso debe vivir en archivos, no en la «cabeza» del agente: una lista de tareas con estados, un diario de lo que se hizo y de lo que no funcionó, y el historial de git.

Un buen modelo es el de «trinquete que solo avanza», como en el proyecto autoresearch de Andrej Karpathy, donde el agente pasa la noche haciendo cientos de experimentos de ML. Cada iteración: leer la metodología, proponer una hipótesis, introducir un cambio, ejecutar el experimento con un presupuesto de tiempo fijo y comparar con la línea base. Si mejora, commit; si no, revertir. El resultado se anota en el diario y luego viene la siguiente hipótesis.

De ese esquema conviene tomar dos decisiones:

• Presupuesto fijo por intento. Así los intentos son comparables y una hipótesis fallida no se come toda la noche.
• En la rama principal, solo mejoras. Todo lo que no funcionó se revierte, no se deja al lado. El git log se convierte en un diario verificado que se lee bien por la mañana.

Ese mismo ejemplo muestra el reparto de roles por archivos: la infraestructura y la evaluación no las modifica nadie, el código del experimento lo modifica solo el agente y la metodología solo una persona. Así el agente no puede «mejorar» el resultado cambiando la forma de medirlo.

Paso 5. Quién decide que está listo: un evaluador aparte

Cuando no hay una persona en el bucle, la autoevaluación del agente se convierte en el único freno, y ese freno no funciona. Un agente que acaba de escribir código tiende a considerarlo correcto: ve sus propios razonamientos y «sabe» lo que quería hacer.

Reglas para separar al generador del evaluador:

• No evalúa la misma sesión que hizo el trabajo. En Claude Code los subagentes son útiles para esto, porque cada uno tiene su propio contexto.
• El evaluador recibe un contexto limpio: el requisito, el diff y los resultados de las ejecuciones, y nada de los razonamientos del ejecutor.
• Si es posible, el evaluador es otro modelo o, como mínimo, otro prompt con otro rol.
• El veredicto se emite según una rúbrica, y cada punto remite a una prueba: una línea de test, la salida de un comando, un lugar del diff.

Las comprobaciones de máquina siguen siendo primarias. El evaluador hace falta para lo que las pruebas no detectan: que el requisito se entendió mal, que el test se ajustó al código, que el cambio se salió del alcance de la tarea.

Criterios de parada: cuándo el agente debe rendirse

Un ciclo sin condiciones de parada se queda en bucle; es cuestión de tiempo. El conjunto mínimo:

Compruebe el progreso por su contenido, no por el número de intentos: «se hicieron 40 iteraciones» no significa nada, «el número de funciones en verde pasó de 5 a 9» sí. Si la tarea se atasca, eso es motivo para pasarla a una persona, no para volver a lanzar el ciclo.

Riesgos del agente autónomo que no se ven de inmediato

Los riesgos evidentes, como archivos borrados o un build roto, se cubren con el sandbox y los permisos. Son más peligrosos los costes ocultos que se acumulan durante semanas:

• Deuda de verificación. «Tiene buena pinta» en lugar de «confirmado por máquina». El antídoto son solo condiciones de parada comprobables por máquina, sin excepciones.
• Pérdida de comprensión. Usted conoce cada vez peor su propio código. El antídoto es leer los diffs de forma obligatoria: la velocidad del ciclo no debe superar la velocidad de lectura de usted.
• Capitulación cognitiva. Deja de tener opinión sobre el resultado y lo acepta todo. Conviene contar con honestidad los casos de «lo miro más tarde» que nunca se miraron.
• Inflado del contexto. Una ejecución larga acumula historial, y cada paso siguiente es más caro y peor. La compresión del contexto y la memoria externa hacen falta desde el primer ciclo, no cuando todo ya se ha descontrolado.

Cómo lanzar el primer ciclo autónomo en una tarde

No empiece con «el agente encontrará y hará las tareas por sí solo». La autonomía crece por escalones: primero, una tarea con objetivo y condición de parada; después, una automatización programada; luego, un ejecutor y un verificador separados en una copia de trabajo aislada, y solo entonces ciclos que encuentran el trabajo por su cuenta y funcionan en paralelo.

1. Busque una tarea que haga a mano al menos dos veces por semana y que tenga un final comprobable.
2. Escriba el objetivo, la verificación y la condición de parada: tres líneas.
3. Cree un worktree aparte y configure los permisos: las pruebas y la edición de archivos están permitidas; el push y los secretos, no.
4. Cree un archivo de progreso y pídale al agente que lo actualice después de cada iteración.
5. Separe los roles: el ejecutor escribe y un verificador, en un contexto aparte, evalúa el diff.
6. Ponga un límite global y revise el primer resultado a la hora, no por la mañana.

Resumen

Un agente de IA autónomo es tan fiable como lo sean sus límites: un sandbox donde un error no cuesta nada, permisos mínimos, un objetivo comprobable por máquina, memoria en disco, un evaluador independiente y condiciones de parada estrictas con escalado a una persona. Sin eso, una ejecución larga no ahorra tiempo: aplaza una limpieza muy grande. Cómo montar un ciclo así en un proyecto de principio a fin, desde el program.md hasta el evaluador independiente, se trabaja en la práctica dentro del curso de harness engineering.