Dejé de aprobar las decisiones del agente. Ahora las observo.

Cuando construí mi primer agente de verdad, hice que pidiera permiso para todo. Cada acción que quería ejecutar lanzaba un aviso: a punto de llamar a esta herramienta — ¿aprobar? a punto de escribir este archivo — ¿aprobar? a punto de enviar esto — ¿aprobar? Sentía que era lo responsable. Yo era el humano en el bucle. Nada pasaba sin mi sí.

Me tomó vergonzosamente poco tiempo descubrir que esto era puro teatro.

"¿Aprobar?" "Sí." "¿Aprobar?" "Sí."

Para el trigésimo aviso de aprobación en una sesión, ya no los leía. Hacía clic en "sí" igual que haces clic en un banner de cookies — reconociendo el patrón de "se ve bien" y siguiendo adelante. Las aprobaciones se habían vuelto un reflejo, y un reflejo no es supervisión. Había construido un punto de control y luego me había automatizado hasta aprobarlo de forma automática.

Y un punto de control sellado de goma es peor que no tener ningún punto de control. Sin punto de control, todos saben que el agente actúa por su cuenta y tratan su salida con la sospecha que corresponde. Con un punto de control que en realidad no leía, los errores del agente quedaban blanqueados como decisiones mías — yo las aprobé, así que ahora son mías, solo que nunca las miré de verdad. Como lo dice sin rodeos una guía de supervisión de 2026, un revisor poco comprometido que aprueba salidas defectuosas es peor que no tener punto de control. Yo me había convertido en ese revisor.

Dos tipos de supervisión

Existe un vocabulario útil para esto, y me aclaró las ideas en cuanto lo tuve. La industria distingue entre human-in-the-loop (humano en el bucle) y human-on-the-loop (humano sobre el bucle):

• In the loop: el agente se detiene antes de cada acción definida, pregunta y espera un sí explícito antes de continuar. Nada pasa sin una decisión humana en cada paso.
• On the loop: el agente actúa por su cuenta dentro de límites fijados, mientras un humano observa el flujo de lo que está haciendo y puede intervenir — durante o después. Supervisas los resultados, no cada pulsación de tecla.

Había caído por defecto en in-the-loop para todo, bajo la teoría de que más compuertas significaban más seguridad. Lo que en realidad tenía era una sola compuerta que había dejado de atender.

El giro: de hacer clic en "sí" a observar resultados

Así que moví la mayor parte del trabajo a on-the-loop. El agente corre; yo observo lo que hace a través de un log que sí leo, de resultados agregados y de excepciones que se me marcan — no de un aviso de sí/no en cada paso.

El modelo mental que lo destrabó: así es como manejas a un ingeniero competente, no a un sospechoso. No apruebas cada línea que escribe. Acuerdas el plan, lo dejas trabajar y revisas el resultado y cualquier cosa rara que haya surgido. La aprobación línea por línea lo insultaría y te agotaría, y ni siquiera produciría mejor código — produciría un cuello de botella y un jefe que lee por encima. La supervisión de un trabajador capaz siempre ha sido on-the-loop. Los agentes no son distintos.

Qué hace que soltar sea seguro (este es el trabajo de verdad)

Aquí está la parte que importa, y es pura arquitectura, no confianza. Pasar a on-the-loop solo es responsable si el sistema está construido de modo que observar sea suficiente. Tres cosas lo logran:

• Umbrales en términos de negocio, no de modelo. No toda acción es igual, así que no reciben el mismo trato. La regla recomendada es definir las compuertas por consecuencia: un paso reversible y de bajo riesgo (redacta esto, resume aquello, reformatea) corre libre; gastar por encima de un umbral, tocar sistemas privilegiados o cualquier cosa irreversible sigue deteniéndose y preguntando. Gastas tu atención escasa solo donde un error es caro — lo que significa que cuando un aviso sí aparece, realmente lo lees, porque es raro y porque importa.
• Observable, interrumpible, acotado. No puedes observar lo que no puedes ver. El agente tiene que emitir una traza que puedas leer, poder detenerse a mitad de ejecución y operar dentro de límites duros que no pueda exceder. Es la misma idea de la restricción en la arquitectura apuntada a la autonomía: la seguridad no es el buen comportamiento del agente, es la cerca a su alrededor.
• Te ganas el ascenso con evidencia. In-the-loop versus on-the-loop no es una elección de personalidad; es una calibración que mueves por tipo de tarea a medida que se demuestra la confiabilidad. La versión cuidadosa de esto es mantener al agente recomendando-pero-no-ejecutando hasta que su criterio se haya validado a lo largo de muchas decisiones reales — medido, igual que un eval set te dice que algo está listo antes que los usuarios. La confianza se otorga con datos, no con vibras, y solo para las categorías que se la ganaron.

Fíjate que nada de eso es "aprobar cada acción". Es trabajo de diseño que haces una vez, por adelantado, para que correr el agente no requiera un reflejo humano en cada paso.

El trabajo cambió, no desapareció

Lo que quiero dejar claro: pasar a on-the-loop no es abdicar. La supervisión no desapareció — subió un nivel, de mano de obra a diseño. En vez de gastar atención por decisión (lo que no escala y se degrada hasta convertirse en aprobación automática), la gasto en la política: qué acciones son reversibles, cuáles necesitan una compuerta, qué debe registrar el agente, cómo se ve una excepción y qué evidencia asciende una tarea a más autonomía. Es el mismo movimiento que revisar el spec en lugar de cada diff — razonar sobre el sistema, no sobre cada instancia.

El objetivo de la supervisión nunca fue tener mis huellas en cada decisión. Era ser genuinamente responsable de los resultados. Aprobar todo sentía como control y entregaba un reflejo. Observar, con límites reales por debajo, se siente como soltar — y fue la primera vez que de verdad tuve el control de lo que el agente podía hacer.