Manual del operador de agentes: supervisar lo que no puedes ver

Operar agentes autónomos de IA es una disciplina nueva: no es ingeniería, no es gestión, no es operaciones, sino un híbrido que requiere las tres. El rol de operador surge cuando los agentes se ejecutan el tiempo suficiente para que la supervisión se convierta en el cuello de botella, no la generación de código. Cinco responsabilidades definen el rol. Una pila de supervisión las implementa. Un marco de intervención decide cuándo actuar.

Nadie se formó para este trabajo. Ningún departamento universitario lo enseña. Ninguna oferta de empleo lo describe con precisión. Un mes escribes Python. Al mes siguiente gestionas un sistema autónomo que escribe Python, llama a APIs, modifica tu sistema de archivos y toma decisiones arquitectónicas mientras duermes. El bucle Ralph creó el rol en mi infraestructura: un script de shell que reinicia Claude Code con contexto fresco, lee el estado del sistema de archivos y continúa el trabajo a lo largo de sesiones nocturnas. Cada equipo que ejecuta agentes de forma autónoma ha descubierto el mismo rol de manera independiente, porque los mismos problemas aparecen cuando un agente opera más allá de una sola sesión interactiva.

El rol no tiene un nombre establecido. Algunos equipos lo llaman “AI ops.” Otros lo integran en ingeniería de plataforma. Unos pocos lo asignan a engineering managers que nunca han escrito un hook. La ambigüedad importa porque identificar mal el rol lleva a asignar mal el trabajo. Un engineering manager sin conocimiento de sistemas no puede depurar un estado de agente corrupto. Un ingeniero de plataforma sin criterio de producto no puede evaluar si el resultado de un agente cumple con la intención de la especificación. El rol de operador requiere ambos: decisiones de especificación (qué debe construir el agente, qué restricciones imponer) y ejecución operativa (monitorear sesiones, recuperarse de fallos, mantener la infraestructura).

Cinco responsabilidades del operador

1. Delegación

Delegar significa escribir especificaciones que restrinjan el comportamiento del agente antes de que comience la ejecución. La calidad de la delegación determina la calidad del resultado autónomo más que cualquier otro factor.

Un archivo CLAUDE.md es un artefacto de delegación. Codifica convenciones del proyecto, patrones prohibidos, comportamientos requeridos y estándares de calidad en un documento que el agente lee al inicio de la sesión.¹ Un PRD es un artefacto de delegación. Especifica criterios de aceptación que el agente verifica antes de reportar la finalización. Una descripción de tarea es un artefacto de delegación. La especificidad de la descripción delimita el espacio de decisión del agente.

Una delegación deficiente produce la Espiral de atajos: el agente se salta pasos porque la especificación no los enumeró como obligatorios. Una buena delegación hace explícitos los pasos requeridos. Mis PRDs incluyen criterios de aceptación numerados, y cada criterio se vincula a un artefacto observable (una ruta de archivo, un resultado de prueba, un comportamiento específico). El agente no puede marcar un criterio como completo sin producir el artefacto. La delegación que especifica resultados observables elimina toda una clase de completaciones fantasma.

La habilidad está en saber qué especificar y qué dejar abierto. La sobre-especificación produce agentes frágiles que no pueden adaptarse cuando encuentran código inesperado. La sub-especificación produce agentes que toman decisiones arquitectónicas que no autorizaste. El límite se mueve con la confianza: un agente bien probado con hooks sólidos se gana mayor libertad que una configuración nueva ejecutando su primera sesión nocturna.

2. Supervisión

Supervisar significa monitorear sesiones activas, revisar diffs y detectar la deriva antes de que se acumule.

La deriva es el riesgo central. Un agente comienza alineado con la especificación, toma una micro-decisión razonable que se desvía ligeramente, y luego toma decisiones subsiguientes que se construyen sobre la desviación. Para la iteración ocho, el agente está resolviendo un problema diferente al que delegaste. Cada decisión individual parecía razonable de forma aislada. La trayectoria acumulada erró el objetivo.

Detecto la deriva mediante dos mecanismos. Primero, los hooks imponen límites duros: comandos bloqueados, patrones requeridos, modificaciones de archivos prohibidas. Los hooks capturan violaciones en tiempo real, antes de que el agente continúe. Segundo, la revisión periódica de logs detecta la deriva suave que ningún hook puede captar: el agente eligiendo un enfoque innecesariamente complejo, o construyendo una función que la especificación no solicitó, u optimizando una ruta de código que no era el cuello de botella. La deriva suave requiere juicio humano porque ninguna verificación automatizada puede determinar si la trayectoria del agente coincide con la intención del operador.

La supervisión escala mal con la cantidad de agentes. Un agente que produce una sesión por noche se puede revisar con el café de la mañana. Cinco agentes que producen ocho iteraciones cada uno generan cuarenta ventanas de contexto de trabajo. La priorización se vuelve obligatoria: revisar los fallos primero, luego las sesiones que tocaron rutas críticas, y por último las completaciones limpias en tareas de bajo riesgo.

3. Intervención

Intervenir significa saber cuándo detener, redirigir o reiniciar un agente a mitad de tarea.

Cuatro patrones exigen intervención:

El agente está atrapado en un bucle. El mismo error aparece en iteraciones consecutivas. El agente intenta la misma solución con variaciones menores. Cada iteración consume una ventana de contexto completa sin producir progreso. Intervención: detener la sesión, diagnosticar la causa raíz manualmente, actualizar el documento de traspaso con el diagnóstico, reiniciar.

El agente produjo un resultado incorrecto que pasa las pruebas. El código compila, las pruebas están en verde, pero el comportamiento no coincide con la intención de la especificación. La puerta de evidencia detecta algunos casos, pero un agente puede producir una justificación plausible para un comportamiento incorrecto. Intervención: escribir una prueba que falle y capture el comportamiento correcto, luego reiniciar.

El agente está a punto de tocar producción o sistemas externos. Cualquier operación con consecuencias irreversibles (desplegar a producción, enviar correos, modificar una base de datos, llamar a un API de pago) requiere una puerta. Mis hooks bloquean comandos destructivos de bash y llamadas de red externas. El operador decide qué puertas abrir y cuándo.²

El agente avanza pero en la dirección equivocada. El trabajo es competente pero está desalineado. Intervención: detener, clarificar la especificación en el documento de traspaso, reiniciar. No intentes redirigir a mitad de sesión mediante conversación. El agente ya construyó modelos mentales en torno a la interpretación equivocada, y la corrección de rumbo dentro de la misma ventana de contexto produce resultados inconsistentes.

El patrón en el que no intervienes: el agente avanzando lentamente hacia el objetivo correcto. Déjalo correr.

4. Recuperación

Recuperar significa manejar los fallos después de que ocurren: estado corrupto, ramas equivocadas, builds rotos y pérdida de datos.

Los fallos de agentes dejan artefactos. Una sesión que se interrumpió pudo haber escrito archivos parciales, hecho commit en la rama equivocada, dejado archivos temporales en el directorio de trabajo o modificado configuración que sesiones posteriores heredan. La recuperación requiere revertir estos artefactos antes de reiniciar.

Mi protocolo de recuperación: inventariar el daño (git status, git log, git diff), preservar el log de sesión como datos diagnósticos, revertir al último commit verificado como bueno, actualizar el documento de traspaso con lo que falló y por qué, y luego reiniciar con restricciones corregidas. No intentes rescatar trabajo parcial de una sesión fallida a menos que el trabajo parcial sea claramente correcto y aislable. El traspaso lleva el contexto del fallo a través de los límites de sesión para que el siguiente agente no repita los mismos errores.

El escenario de recuperación más peligroso es un fallo que parece un éxito. El agente reporta completación, las pruebas pasan, el build está en verde, pero la implementación es sutilmente incorrecta. El modo de fallo Espejismo de confianza produce exactamente esta situación. La recuperación requiere leer el código, no solo el reporte de completación.

5. Gobernanza

Gobernar significa establecer políticas, presupuestos, permisos y requisitos de auditoría que aplican a todas las sesiones de agentes.

Las políticas definen lo que los agentes pueden y no pueden hacer. Mi capa de gobernanza incluye: un presupuesto de instancias (máximo de iteraciones por ejecución nocturna), un techo de costos (gasto máximo de API por sesión), una lista de comandos bash permitidos, una lista de patrones de archivos prohibidos y un conjunto de criterios de completación requeridos.³ Cada política tiene su origen en un fallo específico. El presupuesto de instancias existe porque una sesión temprana ejecutó 47 iteraciones sin converger. El techo de costos existe porque una sesión de depuración quemó $200 en llamadas a API persiguiendo una pista falsa. Cada política es una cicatriz de una lección aprendida de la manera costosa.

Los permisos siguen el principio de mínimo privilegio. Un agente que genera contenido de blog no necesita acceso de escritura al sistema de archivos fuera del directorio de contenido. Un agente que ejecuta pruebas no necesita acceso a la red. Mis hooks imponen estos límites a nivel de llamada de herramienta, bloqueando operaciones que exceden el alcance de permisos de la sesión.²

Los requisitos de auditoría completan la capa de gobernanza. Cada sesión produce un log estructurado: comandos ejecutados, archivos modificados, pruebas ejecutadas, criterios de completación evaluados. La taxonomía de siete modos de fallo surgió de revisar seis meses de estos logs y categorizar cada fallo que requirió intervención humana.

La pila de supervisión

Cinco componentes de infraestructura implementan las cinco responsabilidades.

Los hooks implementan la supervisión automatizada. Los eventos del ciclo de vida de Claude Code (PreToolUse, PostToolUse, Notification) activan scripts de shell que imponen políticas en tiempo real.² Un hook que bloquea rm -rf es una política de gobernanza codificada como verificación PreToolUse. Un hook que requiere la ejecución de pruebas antes de la completación es una restricción de delegación codificada como verificación PostToolUse. Los 95 hooks en mi sistema codifican 95 decisiones sobre lo que los agentes pueden y no pueden hacer, cada uno vinculado a un fallo específico que el hook ahora previene.

La puerta de evidencia implementa la verificación estructurada. Seis criterios (sigue patrones, solución más simple, casos límite manejados, pruebas pasan, sin regresiones, resuelve el problema) deben producir artefactos específicos antes de que el agente marque el trabajo como completo.⁴ La puerta transforma la supervisión de “¿hizo el agente un buen trabajo?” (subjetivo, no verificable) a “¿produjo el agente evidencia para los seis criterios?” (objetivo, auditable). Cada palabra evasiva en un reporte de completación activa una re-verificación.

El bucle de calidad implementa el refinamiento iterativo. Siete pasos (implementar, revisar, evaluar, refinar, ampliar la perspectiva, repetir, reportar) obligan al agente a realizar múltiples pasadas sobre su propio trabajo.⁵ El bucle compensa una limitación estructural de la generación en una sola pasada: los modelos producen primeros borradores plausibles que contienen errores visibles solo al releer. El bucle de calidad exige esa relectura.

Los logs de sesión implementan la auditoría posterior. El sistema captura cada llamada de herramienta, modificación de archivo y reporte de completación en formato estructurado. Seis meses de logs de sesión produjeron la taxonomía de fallos. Sin los logs, cada fallo habría permanecido como una anécdota aislada.

Las puertas de costo implementan el control presupuestario. Los presupuestos de instancias limitan el conteo de iteraciones. Los techos de costo de API limitan el gasto en tokens. Un agente que no ha convergido dentro del presupuesto de instancias probablemente está atascado, y más iteraciones no van a ayudar. El presupuesto obliga al operador a diagnosticar e intervenir en lugar de esperar que la siguiente iteración resuelva el problema.

Cuándo intervenir vs. cuándo dejarlo correr

La decisión de intervenir es la llamada de juicio más trascendental del operador. Intervenir demasiado pronto desperdicia el trabajo del agente. Intervenir demasiado tarde permite que la deriva se acumule. Un marco ayuda.

El meta-principio: intervenir ante la asimetría de información, no ante la velocidad. Cuando sabes algo que el agente no sabe (la ruta de código correcta, el requisito real, el modo de fallo de una sesión anterior), la intervención transfiere ese conocimiento. Cuando el agente sabe todo lo que tú sabes y simplemente está trabajando en el problema, déjalo trabajar.

Lista de verificación del operador

Antes de comenzar

• [ ] Especificación revisada: los criterios de aceptación son específicos, observables y completos
• [ ] Hooks activos: los hooks de políticas están habilitados y probados para el tipo de tarea
• [ ] Presupuesto definido: el límite de instancias y el techo de costos están configurados
• [ ] Sandbox confirmado: el agente no puede alcanzar producción, enviar solicitudes externas ni modificar archivos fuera del alcance
• [ ] Traspaso actualizado: si se continúa trabajo previo, el documento de traspaso refleja las últimas correcciones
• [ ] Rama limpia: el directorio de trabajo está en la rama correcta sin cambios sin confirmar

Durante

• [ ] Verificar logs en intervalos definidos (cada 2-3 iteraciones para ejecuciones nocturnas)
• [ ] Verificar que la trayectoria coincide con la intención de la especificación, no solo con su letra
• [ ] Monitorear el uso de recursos: gasto de tokens, conteo de iteraciones, cambios en el sistema de archivos
• [ ] Vigilar la escalación de permisos: solicitudes de acceso que la tarea no debería requerir
• [ ] Anotar cualquier deriva suave para la revisión post-sesión

Después

• [ ] Revisar todos los cambios en archivos, no solo el reporte de completación
• [ ] Ejecutar la suite de pruebas completa de forma independiente (no confiar en los resultados de pruebas reportados por el agente)
• [ ] Verificar regresiones en código adyacente que el agente no modificó explícitamente
• [ ] Verificar la puerta de evidencia: cada criterio tiene un artefacto específico, no una garantía general
• [ ] Actualizar el documento de traspaso con los resultados de la sesión y cualquier corrección
• [ ] Registrar la sesión: modos de fallo encontrados, hooks que se activaron, decisiones de intervención tomadas
• [ ] Actualizar la gobernanza: si surgió un nuevo patrón de fallo, escribir un hook o política para prevenir la recurrencia

El operador como artesano

El rol de operador de agentes existe en la intersección entre habilidad de ingeniería y criterio de producto. Escribir hooks requiere conocimiento de sistemas. Escribir especificaciones requiere comprensión de producto. Revisar el resultado de un agente requiere ambos: la capacidad de evaluar si el código es correcto y si el código correcto resuelve el problema adecuado.

El chat es la interfaz equivocada para la mitad operativa del rol. Desplazarse por transcripciones de conversación para supervisar trabajo autónomo no escala más allá de un solo agente ejecutando una sola sesión. La pila de supervisión descrita arriba (hooks, puertas de evidencia, bucles de calidad, logs de sesión, puertas de costo) compensa la brecha de interfaz al codificar la supervisión en infraestructura. La infraestructura no reemplaza al operador. La infraestructura multiplica el alcance del operador.

El gusto es un sistema técnico describe la mitad de juicio. Saber qué delegar, qué verificar y qué rechazar requiere reconocimiento de patrones construido a partir de la experiencia. Cada sesión le enseña algo al operador sobre el comportamiento de los agentes. La habilidad del operador se acumula mediante la práctica deliberada, la reflexión y la infraestructura que codifica las lecciones de forma permanente.

La fábrica oscura representa el punto final teórico, el Nivel 5, donde ningún humano lee el código. La práctica actual se sitúa en el Nivel 3 o 4 para la mayoría de los equipos: el agente hace el trabajo, el operador supervisa e interviene. La brecha entre el Nivel 4 y el Nivel 5 es la capa de verificación. La brecha entre el Nivel 2 y el Nivel 4 es el operador.

Cada equipo que ejecuta agentes autónomos desarrollará operadores. La pregunta es si desarrollan el rol de manera deliberada (con responsabilidades definidas, soporte de infraestructura y capacitación explícita) o de manera accidental, asignando el trabajo a quien resulte estar despierto cuando la sesión nocturna falla. El oficio se desarrolla a partir de ahí.