En la mayoría de las conversaciones sobre ingeniería de agentes, la acción ha pasado de dar instrucciones (prompting) a operar. Esto es una frontera mirando hacia la niebla: fábricas de software, objetivos (goals), bucles (loops), sesiones en segundo plano (background sessions), subagentes, hooks, sandboxes, agentes que aprueban agentes. Para muchos creadores del futuro, este comportamiento estará integrado en los productos desde el primer día: Claude Code y Codex exponen directamente este cambio.
Desde la perspectiva del ingeniero, usarás baja autonomía para limitar el riesgo y aumentar la reversibilidad, pero usarás mayor autonomía para actividades explícitas, y flotas de agentes paralelos refactorizando de forma segura bases de código masivas. La pregunta central sobre una acción siempre es: ¿qué nivel merece esta tarea, y qué verificación hace que ese nivel sea defendible?
El borde de la frontera es el agente administrador que se activa con su desencadenante, delegando en sus ayudantes mientras verifica continuamente su resultado, y regresando solo con las decisiones que un humano debe tomar. Las personas que utilizan este tipo de configuración ya pueden estar ejecutando cientos o miles de agentes, principalmente en bases de código siempre actualizadas (evergreen). Como ocurre con casi todo el pensamiento sobre la autonomía, cómo percibes la escala sigue siendo diferente para cada uno.
La escala más mencionada es la escala de un solo eje de Steve Yegge, mencionada en «Welcome to Gas Town» y en The Pragmatic Engineer. Es una buena referencia si quieres un número que te indique qué tan nativo de la IA eres: la escala te da un solo número para medir si conoces tu confianza en un solo agente. Aquí tienes una versión:
A principios de 2026, incluso cuando el trabajo comenzaba a pasar de la delegación a la orquestación, esto era un indicador bastante bueno para medir el riesgo. Hoy, sin embargo, muchos conjuntos de habilidades pueden tener mayor relevancia y apalancamiento cuando puedes ejecutar muchos agentes a la vez. Un solo peldaño no puede ayudarte a situar la habilidad multiagente.
En cambio, casi todos los debates sobre autonomía que he visto combinan dos preguntas que deberían separarse: ¿qué tan lejos de nosotros mismos estamos dejando ir a este único agente, y cuál es nuestra habilidad para coordinar a muchos agentes?
Para capturar estas dos dimensiones por separado, usaremos dos ejes: agencia y orquestación.
En el eje de agencia, el nivel bajo incluye sugerir acciones candidatas y esperar una decisión.
El nivel medio significa que el agente está trabajando en una tarea particular, pero acota lo que hace, e informa constantemente lo que hace junto con evidencia, para que puedas seguir dirigiéndolo.
En el extremo de alta agencia, el agente trabaja hacia un objetivo, experimenta, aprende, prueba, encuentra formas de resolver un problema, se bloquea, hace preguntas, prueba diferentes enfoques, y devuelve todo este trabajo como evidencia.
En el eje de orquestación, el nivel bajo significa un agente, un hilo. En el nivel medio, tienes varios agentes, cada uno trabajando en su propio worktree, posiblemente trabajando hacia diferentes objetivos, pero aislados. En el extremo alto, tienes un orquestador que puede tomar un backlog, un issue tracker, un cronograma u otra cola, y convertirlo en trabajo continuo, y solo necesitas intervenir cuando las cosas fallan: «gestión por excepción». Los productos y funcionalidades que incorporan estas ideas incluyen:
- Los modos /plan, /goal, /loop, /background, /batch, /code-review, /security-review de Claude Code, subagentes, hooks, checkpointing, prácticas de delegación y gestión de agentes, sesiones en segundo plano, patrones de equipos de agentes, argumentos /schedule
- Los hilos locales/en la nube de Codex, el modo Goal, worktrees, Automations, subagentes, paneles de revisión, revisión de código en GitHub, hooks, sandboxing, Auto-review y rerun
Estas capacidades no encajan en una sola escala.
El ascenso: tres eras y una sola pila
Si lees la escala de abajo arriba, estás imaginando escalar tanto la agencia como la orquestación al mismo tiempo. En efecto, los seis niveles representan tres eras separadas por las que todos pasamos:
Primero, estás al volante, y un agente mayormente solo ayuda, esperando que lo dirijas.
Segundo, el agente se encarga de una tarea u objetivo acotado, pero todavía estás presente para dirigirlo y verificar lo que hace.
Y tercero, en la era de la orquestación, el sistema es capaz de dirigir el espectáculo, distribuyendo el trabajo entre muchos agentes, y tú principalmente necesitas intervenir cuando las cosas van mal: «gestión por excepción».
Esto simplifica las cosas, porque la posición vertical en la escala captura de manera ordenada los dos ejes (la orquestación solo aparece cerca de la cima), dejándolo como un ascenso constante a través de los peldaños. Y sin embargo, el ascenso sigue siendo parte de un cambio que todos estamos experimentando.
Un buen día de ingeniería incluye tocar varios peldaños, a veces más: es normal cambiar entre las eras varias veces en el transcurso de una tarea.
Los seis niveles en detalle
Nivel 0: Asistir
El agente hace sugerencias que son mayormente buenas y a menudo perfectas, pero siempre decidirás si son lo suficientemente buenas para actuar. Piensa en autocompletado, sugerencias de edición en línea, o estar en una sesión de chat discutiendo un cambio del que nadie se ha hecho cargo todavía. Úsalo para errores costosos, cambios pequeños, o cuando estás formando tu propio juicio. La verificación ocurre principalmente de forma local.
Nivel 1: Acción supervisada
El agente edita o ejecuta comandos en tu nombre, pidiéndote permiso antes de ejecutar cualquier cosa relevante. Esta es la postura predeterminada para la mayoría de las personas. Puede hacerse en un sandbox local con aprobaciones antes de aplicar cambios –donde cada aprobación es una verificación independiente de que el cambio es aceptable– o en una sesión interactiva. El modo de fallo es la fatiga de aprobación; todas las aprobaciones se sienten igual independientemente de lo que se esté aprobando. Puedes solucionarlo examinando el diff, siguiendo algunas heurísticas, consultando con otra persona antes de aprobar, o simplemente aceptando que el agente sea responsable. Codex Auto-review resuelve este problema delegando la aprobación final de las condiciones límite a un agente revisor independiente.
Nivel 2: Delegación de tareas acotadas
Delega una tarea acotada al agente. Esa tarea tendrá un objetivo claro, restricciones y una definición funcional de cómo se ve «terminado». Te mantendrás cerca, capaz de interrumpir, pero mayormente no involucrado. Este es el centro de gravedad en el mundo de la ingeniería de software. La verificación se está alejando de ti (puede que necesites descansar y dormir) hacia la evidencia que el agente puede producir: pruebas automatizadas que pasan, tipos adecuados, sugerencias de lint, capturas de pantalla, pasos de reproducción, procedencia mediante ejemplos, etc.
Nivel 3: Autonomía orientada a objetivos
El agente hace lo que sea necesario para lograr un objetivo, deteniéndose solo cuando se cumple alguna condición. En el modo prompt, esto significa que el propio prompt se convierte en el objetivo (por ejemplo, «¿Puedes reducir el tiempo de interacción de esta página por debajo de 1 segundo?»). En Codex, esto es el modo Goal: el agente cicla a través de los pasos planificar->actuar->probar->revisar hasta que deja de cumplir los criterios de éxito. En Claude Code, son los comandos /goal, /loop y /schedule. Para que este nivel sea útil, la condición de parada debe ser medible de forma automatizada.
No le pidas a tu agente que ayude con objetivos vagos y difusos como «mejorar la experiencia de usuario en general» o «hacer la base de código más testeable». Elige algo específico, medible y automatizado: encontrar errores en producción que eludan el análisis estático, reducir el tiempo de carga, asegurar que tenemos una compilación estricta de TypeScript sin ningún «any» explícito, triar todas las dependencias para quedarse solo con las que entendemos y que pasan nuestras pruebas, etc. Y, finalmente, para encontrar errores en producción, el agente necesitará estar en un entorno similar al de producción.
Nivel 4: Delegación en paralelo
Trabaja con muchos agentes en paralelo. Cada agente trabaja en una porción aislada de la tarea. El mayor cuello de botella en este nivel es la descomposición: definir las porciones adecuadas para delegar. Los soportes incluyen: subagentes, sesiones en segundo plano, /batch, worktrees, equipos de agentes, etc. El modo de fallo es el falso paralelismo: ejecutar muchos agentes contra porciones superpuestas a la vez, de modo que en lugar de más trabajo obtienes conflictos de fusión y decisiones duplicadas. Para hacerlo bien, los agentes deben estar aislados entre sí, cada uno con sus propios archivos y estado. Cada uno también necesita tener su propia cola de revisión. Y, finalmente, cada agente incurre en un costo –en términos de tokens consumidos– proporcional al número de agentes ejecutándose al mismo tiempo. En el lado humano, el impuesto de orquestación hace que el costo marginal de añadir un agente aumente después de unos pocos.
Nivel 5: Orquestación gestionada por excepción
Define cómo es el éxito, y qué políticas deben aplicarse. Un agente administrador se activará en función de desencadenantes (por ejemplo, nuevo issue, nueva tarea, reloj), asignará agentes trabajadores, monitoreará su progreso, verificará los resultados, reintentará en caso de fallo, escalará a agentes más competentes o a humanos cuando se cumplan las condiciones, agregará resultados y, en última instancia, devolverá productos de trabajo (por ejemplo, PRs) y evidencia a los sistemas externos. Piensa en una fábrica: el issue tracker o backlog es la entrada, y el producto de la fábrica es la salida (es decir, muchos issues y errores corregidos). Los agentes trabajan en un entorno adecuadamente aislado con muchos muros (y, si es necesario, escotillas de escape), y solo un sistema operativo –definido por el agente administrador– define lo que se espera que haga la fábrica.
El diseño de este sistema operativo queda en manos del humano; OpenAI ha propuesto una especificación para Symphony que tiene un tablero de Linear en el centro: cada issue tiene su propio espacio de trabajo de agente, y el agente se asegura continuamente de que está progresando hacia su objetivo según lo definido en un archivo de especificación en su propio espacio de trabajo. La revisión humana puede realizarse al nivel donde se genera la evidencia, pero la frontera (es decir, lo más potente en el mundo de la orquestación) es construir fábricas de agentes continuas con cientos o incluso miles de agentes. En este punto del ascenso, se vuelve cada vez más importante tener verificación independiente: implementadores y revisores separados, ejecutores de pruebas y QA separados, controles de seguridad separados, puertas de proceso separadas para la aceptación.
El riesgo y la reversibilidad marcan el techo.
Recuerdo haber leído un estudio anterior de Anthropic sobre algunas de las tareas más difíciles con Claude Code, donde pedía aclaraciones más del doble de veces de las que los usuarios interrumpían. Los usuarios experimentados (~750 sesiones frente a menos de 50) eran más propensos a aprobar automáticamente e interrumpir vigilando el progreso.
También hicieron un análisis más amplio de cómo la gente usa Claude Code. Analizaron ~400K sesiones de ~235K personas entre octubre de 2025 y abril de 2026. De cada sesión podían deducir las decisiones que alguien toma, como cuántas acciones solicitan en cada prompt, cuáles de ellas eligen aprobar automáticamente, con qué frecuencia interrumpen, etc. Las personas toman aproximadamente el 70% de las decisiones de planificación, pero Claude realiza aproximadamente el 80% de la ejecución. La alta autonomía no consiste en dejar a las personas fuera del circuito, sino en pasar de que hagan cada paso a que decidan en qué dirección ir a continuación.
Si queremos determinar si un sistema de IA grande está operando con alta autonomía, las tres preguntas que deberíamos hacernos son:
- ¿Qué tan rápido sabremos que estamos equivocados sobre lo que está haciendo?
- ¿Con qué limpieza podemos deshacer lo que está haciendo?
- ¿Qué probaría que tenemos razón sobre lo que está haciendo?
Si la respuesta a las tres es: no rápidamente, con gran dificultad, y confiando en el resumen, no es alta autonomía.
Cada ejecución de un agente debería ir precedida de un contrato que defina lo que intenta hacer.
El objetivo: lo que estamos tratando de lograr (no una actividad, no la técnica, sino un resultado).
El alcance: en qué dominio estamos operando, y qué técnicas están permitidas.
No objetivos: lo que no es parte del objetivo.
Herramientas y permisos: cómo el agente puede interoperar con el mundo. Condición de parada: cuándo detenerse; idealmente, una variable medible.
Evidencia: pruebas específicas, capturas de pantalla, registros, registros de bases de datos u otros indicadores que puedan usarse para confirmar que algo se ha hecho (independientemente del agente).
Escalada: quién se involucra y en qué circunstancias (incluyendo quién ejecuta el agente).
Y presupuesto: un límite en cuánto tiempo, esfuerzo y tokens se dedicarán a la tarea (los tokens son el presupuesto de los grandes modelos de IA; también puedes incluir un límite en el número de veces que puede intentar la tarea y un límite en el grado de paralelismo).
Las métricas hacen que la autonomía sea un poco más fiable
Decidir la métrica después del hecho probablemente no sea suficiente. Se pueden establecer métricas de antemano, en un documento conciso. Y eso hace que la autonomía se sienta más fiable y da un poco más de confianza para dar el salto de fe.
Aunque hay muchas formas de medir el éxito, considera hacer un seguimiento de alguna versión de estas métricas para cada nivel de autonomía:
- Tiempo medio entre intervenciones
- Ejecución no supervisada exitosa más larga con trabajo aceptado
- Proporción de acciones ejecutadas en el sandbox frente a escaladas
- Porcentaje de acciones aprobadas automáticamente frente a rechazadas
- Número medio de acciones del agente por instrucción humana
- Tasa de solicitudes de aclaración / Tasa de solicitudes de interrupción
- Tiempo de revisión por cambio aceptado
- Tasa de retrabajo en cada nivel de confianza
- Tasa de fugas de defectos en cada nivel de confianza
- Costo de tokens por cambio aceptado
Estas métricas pueden contar una historia: un solo agente mantenido ocupado por transferencias humanas es el Nivel 4 con un panel de control. Un agente conservador, que no está dispuesto a continuar sin una admisión automatizada, reintentos y evidencia decente, es el Nivel 5 con una puerta de control real.
Piensa en la preparación
Clasifica el trabajo por riesgo y por lo fácil que es deshacerlo. Aplica la autonomía de forma conservadora, aumentando solo a medida que se acumula evidencia que respalde el nivel superior. Una refactorización de un motor de pagos protegida por pruebas sólidas y agentes revisores con una ruta de rollback limpia puede soportar una autonomía mucho mayor que una tarea de automatización de documentación que carece de una verdad canónica. El nivel de autonomía debe seguir el proceso de verificación, no el nombre de la tarea.
Cuatro antipatrones
Cualquier sistema puede caer fácilmente presa de estos cuatro antipatrones de autonomía a menos que se eviten vigilantes.
Autonomía como estatus – el nivel de autonomía de un agente se convierte en una insignia de estatus sin significado. La mayor autonomía se trata como una prueba de capacidad, no de seguridad, y los agentes se ejecutan a un nivel más alto del que la verificación respalda. Solución: elogia y recompensa a quienes se establecen en el nivel correcto de autonomía y evitan implacablemente sobrepasarse.
Blanqueo de permisos – la tiranía de la fatiga de aprobación nos lleva a conceder a los agentes y herramientas de IA un acceso mucho más amplio de lo necesario. Solución: mejores límites siempre son una solución, como perfiles de sandbox, raíces de escritura acotadas, comandos permitidos, hooks y Auto-review.
Sustitución por resumen – el resumen del trabajo del agente sustituye a la revisión, asumiendo que el resumen es suficiente. Solución: incluye el mismo paquete de evidencia que en las revisiones totalmente manuales (un diff, pruebas, registros, capturas de pantalla, hallazgos del revisor, riesgos, brechas, etc.) evitando la rendición cognitiva.
Cosplay de flota – docenas de agentes se ejecutan en paralelo, pero un humano persiste en orquestar cada dependencia manualmente. Solución: el estado compartido, las reglas de propiedad y un mejor seguimiento de dependencias reducen gradualmente la necesidad de coordinar manualmente. Límites de trabajo en curso (WIP) más pequeños fuerzan un enfoque en codificar y documentar los pasos coordinados hasta que la orquestación se automatice.
Un ejercicio de calibración
Revisa las últimas diez tareas que realizaste con la ayuda de un agente. Para cada tarea, registra el nivel de autonomía ejercido, el riesgo involucrado, con qué facilidad se podría deshacer el trabajo, la evidencia producida para cumplir con los requisitos de verificación, el tiempo de revisión, si fue necesario algún retrabajo, y si el nivel de autonomía elegido seguiría siendo adecuado la próxima vez.
Cómo escalar de forma segura
Sube de nivel en un eje a la vez. Comienza con un solo agente supervisado para realizar una única tarea acotada que produzca evidencia defendible de éxito (un nivel de autonomía 1, si es lo suficientemente ordenado). Luego expande gradualmente en las tres direcciones ortogonales. Paraleliza tareas de exploración intensivas en lectura (nivel de autonomía 4). Añade agentes de escritura que actúen en worktrees separados con reglas de propiedad de archivos restringidas (nivel de autonomía 4). Añade automatizaciones recurrentes, luego orquestación liderada por agentes basada en issues, voz, etc. Cada paso hacia arriba en la palanca requiere un nuevo conjunto de mecanismos de seguridad (como nuevos modos de fallo).
Nómbralos: Las ejecuciones más largas de un solo agente pueden llevar a desviación, podredumbre del contexto, comunicación perdida u objetivos desviados. El trabajo en segundo plano puede llevar a suposiciones obsoletas y transferencias débiles. Demasiado trabajo en paralelo puede llevar a conflictos de fusión o decisiones duplicadas. Demasiado trabajo recurrente puede llevar a un gasto silencioso de tokens o prompts desactualizados. La gestión por excepción puede llevar a colas de revisión largas y fatiga de alertas. La solución no es confiar más a ciegas; en su lugar, reduce el alcance, asegura mejor evidencia, habilita rutas de rollback más baratas, endurece las puertas de control y define reglas de propiedad más claras.
Usa el nivel de autonomía:
- El Nivel 0 es mejor para trabajos delicados y cuando el juicio aún se está formando.
- El Nivel 1 es mejor para la mayoría de la exploración, si el trabajo se realiza cerca de los límites de lo bien entendido.
- El Nivel 2 es mejor para la mayoría de las tareas acotadas, sabiendo que puede haber dependencias desconocidas y problemas imprevistos.
- El Nivel 3 es mejor donde las condiciones de éxito pueden establecerse con suficiente claridad.
- El Nivel 4 es mejor cuando el trabajo puede dividirse limpiamente entre estas condiciones de éxito.
- El Nivel 5 es mejor una vez que la coordinación y comunicación necesarias entre las diversas condiciones de éxito están completamente codificadas.
La verificación siempre será el cuello de botella.
A pesar de la bravuconería actual y las herramientas actuales, la postura madura de un equipo de ingeniería que trabaja con agentes de IA es la autonomía calibrada.
Los cuellos de botella son la coordinación, la verificación, el mantenimiento, el juicio de producto y el aprendizaje de incidentes.
En el futuro cercano, querrremos diseñar bucles que sepan cuándo trabajar, cuándo verificar y cuándo preguntar – pero la habilidad del ingeniero seguirá estando en elegir el nivel correcto de autonomía y en construir patrones y evidencia defendible que protejan contra sus rincones más oscuros.
Nota: Pangram etiqueta este artículo como 100% escrito por humanos: https://www.pangram.com/history/87531e13-cd12-4cb0-9e02-9579719ddc26
