Niveles de autonomía de los agentes

• La ingeniería agentic se está acercando más al diseño operativo que a la redacción de prompts, y para cada tarea hay que decidir tanto la autonomía permitida como el método de verificación que la respalda
• Un modelo de escalera única es útil para expresar con un número la confianza en un agente, pero la capacidad para manejar varios agentes al mismo tiempo debe verse en dos ejes: agency y orchestration
• El modelo de niveles 0 a 5 va desde Assist, donde el agente solo propone, hasta Managed-by-exception orchestration, donde las personas intervienen solo ante excepciones; cuanto más alto el nivel, más claros deben estar el objetivo, el alcance, la evidencia, los permisos y el presupuesto
• En el análisis de Claude Code de Anthropic, con datos de unas 400 mil sesiones y unos 235 mil usuarios, se observa que las personas toman alrededor del 70% de las decisiones de planificación, mientras que Claude se encarga de cerca del 80% de la ejecución
• El uso maduro de agentes no consiste en presumir alta autonomía, sino en aplicar calibrated autonomy según el riesgo y la reversibilidad, y en gestionar los cuellos de botella de verificación

---

De escribir prompts a diseñar operaciones en la ingeniería agentic

• El centro de la ingeniería agentic se está desplazando de la redacción de prompts al diseño operativo
• Pasan al frente las fábricas de software, objetivos, loops, sesiones en segundo plano, subagentes, hooks, sandboxes y formas en que los agentes aprueban a otros agentes
• Claude Code y Codex se tratan como productos representativos de este cambio
• Los ingenieros pueden usar menor autonomía para reducir riesgos y facilitar la reversión, y mayor autonomía junto con flotas de agentes en paralelo para actividades claras o refactorizaciones de grandes codebases
• La pregunta clave es qué nivel de autonomía permitir para cada tarea y qué verificación puede defender ese nivel

Ver la autonomía en dos ejes en lugar de una sola escalera

• La escalera de un solo eje mencionada por Steve Yegge en “Welcome to Gas Town” es útil para expresar con un número la confianza en un agente
• A comienzos de 2026, incluso cuando el trabajo se desplazaba de la delegación a la orquestación, ese eje único funcionaba como un indicador aproximado del riesgo
• Cuando se vuelve posible ejecutar varios agentes al mismo tiempo, un solo nivel no alcanza para describir las capacidades multiagente
• Las discusiones sobre autonomía suelen mezclar dos preguntas distintas
  • Qué tan lejos se puede enviar a un solo agente de la persona
  • Qué tan bien se puede coordinar a varios agentes
• Para separarlas hacen falta dos ejes
  • agency: qué tan autónomamente un agente realiza propuestas, tareas acotadas o la consecución de objetivos
  • orchestration: qué tanto se coordina, desde un solo hilo hasta múltiples árboles de trabajo y trabajo continuo basado en backlog, issue tracker y calendario

Qué significan agency y orchestration

• En los niveles bajos del eje de agency, el agente propone acciones candidatas y espera la decisión de una persona
• En los niveles intermedios, el agente realiza una tarea específica pero con alcance limitado, y reporta continuamente lo que hizo con evidencia para que la persona pueda ajustar
• Con alta agency, el agente experimenta, aprende, prueba, maneja bloqueos, hace preguntas y prueba otros enfoques para alcanzar un objetivo, y devuelve todo esto como evidencia
• En los niveles bajos del eje de orchestration hay un agente y un hilo
• En los niveles intermedios, varios agentes trabajan en objetivos distintos, cada uno en su worktree separado
• En los niveles altos, un orquestador convierte backlogs, issue trackers, calendarios y colas en trabajo continuo, y las personas intervienen solo ante fallas, en una forma de management by exception
• Algunos ejemplos de funciones y productos relacionados son
  • Claude Code: /plan, /goal, /loop, /background, /batch, /code-review, /security-review, subagentes, hooks, checkpoints, delegación y gestión de agentes, sesiones en segundo plano, patrones de equipos de agentes, argumento /schedule
  • Codex: hilos locales y en la nube, Goal mode, worktree, Automations, subagentes, panel de revisión, revisión de código en GitHub, hooks, sandbox, Auto-review, rerun

Tres eras y seis niveles

• Si se lee la escalera de abajo hacia arriba, parece que agency y orchestration suben al mismo tiempo
• Los seis niveles se dividen en tres eras
  • La era en la que la persona está al volante y el agente asiste, esperando las acciones de la persona
  • La era en la que el agente asume tareas u objetivos acotados, pero la persona ajusta y verifica
  • La era de la orquestación, donde el sistema distribuye trabajo entre varios agentes y la persona interviene principalmente cuando hay problemas
• En la ingeniería real, es natural moverse entre varios niveles durante el día

Level 0: Assist

• El agente hace sugerencias generalmente buenas y a veces perfectas, pero la persona siempre decide si se ejecutan
• Algunos ejemplos son autocompletado, sugerencias de edición inline y situaciones en las que se discuten en el chat cambios que todavía no tienen dueño
• Es adecuado para errores de alto costo, cambios muy pequeños y trabajos donde todavía se está formando un criterio
• La verificación ocurre principalmente en local

Level 1: Supervised action

• El agente edita o ejecuta comandos en nombre de la persona, pero pide permiso antes de una ejecución importante
• Se parece a la postura predeterminada que usa la mayoría de la gente
• Puede hacerse en un sandbox local, con aprobación antes de aplicar cambios, o en una sesión interactiva
• Cada aprobación funciona como una verificación independiente de si está bien aplicar ese cambio
• El modo de falla principal es la fatiga de aprobación
  • Todas las aprobaciones pueden empezar a sentirse iguales, sin importar qué se esté aprobando
  • Se puede responder revisando el diff por arriba, siguiendo heurísticas, pidiendo confirmación a otra persona o permitiendo que el agente se haga responsable
• Codex Auto-review aborda este problema delegando la aprobación final de las condiciones de borde a un agente revisor separado

Level 2: Scoped task delegation

• Es el nivel en el que se entrega una tarea limitada al agente
• La tarea debe tener un objetivo claro, restricciones y una definición del trabajo completado
• La persona permanece cerca y puede interrumpir, pero por lo general no participa directamente
• Se trata como un nivel cercano al centro en la ingeniería de software
• La verificación se desplaza de la confirmación directa de la persona a la evidencia que el agente puede generar
  • Pruebas automatizadas que pasan
  • Tipos adecuados
  • Sugerencias de lint
  • Capturas de pantalla
  • Pasos para reproducir
  • Fuentes basadas en ejemplos

Level 3: Goal-driven autonomy

• El agente hace lo necesario para alcanzar un objetivo hasta que se cumplan ciertas condiciones
• En modo prompt, el propio prompt se convierte en el objetivo
  • Ej.: “¿Puedes reducir el time-to-interactive de esta página a menos de 1 segundo?”
• En Codex, esto corresponde a Goal mode, donde el agente repite plan -> act -> test -> review y se detiene cuando ya no puede satisfacer el criterio de éxito
• En Claude Code, corresponde a los comandos /goal, /loop y /schedule
• Para que este nivel sea útil, la condición de parada debe ser medible de una forma automatizable
• Objetivos ambiguos como “mejorar la experiencia de usuario en general” o “hacer que la codebase sea más testeable” no son adecuados
• Los objetivos más adecuados deben ser concretos, medibles y automatizables
  • Encontrar bugs de producción que evaden el análisis estático
  • Reducir el tiempo de carga
  • Garantizar una compilación TypeScript estricta sin any explícitos
  • Clasificar todas las dependencias para dejar solo las comprensibles y que pasan tests
• Para encontrar bugs de producción, el agente debe estar en un entorno similar a producción

Level 4: Parallel delegation

• Es el nivel en el que varios agentes trabajan en paralelo
• Cada agente toma una parte separada del trabajo
• El mayor cuello de botella es la descomposición, es decir, decidir qué partes delegar
• Las funciones de soporte incluyen subagentes, sesiones en segundo plano, /batch, worktree y equipos de agentes
• El modo de falla principal es el falso paralelismo
  • Si varios agentes trabajan al mismo tiempo sobre partes solapadas, producen merge conflicts y decisiones duplicadas en lugar de más trabajo
• Para operarlo bien, los agentes deben estar aislados entre sí
  • Cada uno debe tener sus propios archivos y estado
  • Cada uno también debe tener su propia cola de revisión
• Cada agente genera costo en tokens, proporcional al número de agentes que se ejecutan al mismo tiempo
• Del lado humano, después de cierta cantidad, el costo marginal de agregar agentes aumenta por el impuesto de orquestación

Level 5: Managed-by-exception orchestration

• La persona define la definición de éxito y las políticas aplicables, y un manager agent se despierta según disparadores para distribuir el trabajo
• Ejemplos de disparadores son nuevos issues, nuevas tareas o el reloj
• El manager agent despliega agentes trabajadores, monitorea el progreso, verifica los entregables y reintenta ante fallas
• Cuando se cumplen ciertas condiciones, escala a un agente más capaz o a una persona, agrega los resultados y devuelve a sistemas externos los entregables de trabajo, como PRs, junto con la evidencia
• Este nivel se compara con una fábrica
  • La entrada es un issue tracker o backlog
  • La salida son múltiples issues o bugs resueltos
• Los agentes trabajan en entornos aislados, con límites suficientes y salidas de emergencia cuando hacen falta
• Lo que debe hacer esta fábrica lo decide el sistema operativo definido por el manager agent
• OpenAI propuso una spec para Symphony, con un tablero de Linear en el centro
  • Cada issue tiene su propio workspace de agente
  • El agente verifica si sigue avanzando hacia los objetivos definidos en el archivo spec de su workspace
• La frontera de la orquestación es crear fábricas de agentes continuas donde operan cientos o miles de agentes
• En este nivel, la verificación independiente se vuelve más importante
  • Separar implementador y revisor
  • Separar ejecutor de pruebas y QA
  • Separar revisión de seguridad
  • Separar gates de proceso para la aceptación

El riesgo y la reversibilidad fijan el techo de la autonomía

• En una investigación de Anthropic sobre Claude Code, en algunas de las tareas más difíciles Claude Code hizo preguntas aclaratorias más del doble de veces que las interrupciones del usuario
• Los usuarios experimentados, definidos como quienes tenían unas 750 sesiones, tendían a usar con más frecuencia la aprobación automática y las interrupciones que los usuarios con menos de 50 sesiones, mientras supervisaban el progreso
• Un análisis más amplio de Anthropic cubre unas 400 mil sesiones de unos 235 mil usuarios entre octubre de 2025 y abril de 2026
• En cada sesión se podían identificar decisiones como cuántas acciones pidió el usuario por prompt, qué elementos aprobó automáticamente y con qué frecuencia interrumpió
• Las personas toman alrededor del 70% de las decisiones de planificación, y Claude realiza cerca del 80% de la ejecución
• La alta autonomía no significa sacar a la persona del loop, sino pasar de que la persona ejecute cada paso a que decida la siguiente dirección
• Para juzgar si un sistema de IA grande opera con alta autonomía hacen falta tres preguntas
  • Qué tan rápido puedo saber qué está haciendo mal
  • Qué tan limpiamente puedo revertir lo que está haciendo
  • Qué demuestra que lo que está haciendo es correcto
• Si la respuesta es “no puedo saberlo rápido, es difícil de revertir y tengo que confiar en un resumen”, entonces no es alta autonomía

Qué debe incluir el contrato antes de ejecutar un agente

• Antes de cada ejecución de un agente hace falta un contrato que defina qué se intenta hacer
• El contrato debe incluir lo siguiente
  • Objetivo: el resultado que se quiere lograr, no la actividad ni la técnica
  • Alcance: el dominio de trabajo y las técnicas permitidas
  • No objetivos: lo que no está incluido en el propósito
  • Herramientas y permisos: cómo interactúa el agente con el mundo externo
  • Condiciones de parada: cuándo detenerse y, si es posible, variables medibles
  • Evidencia: tests, capturas de pantalla, logs, registros de base de datos u otros elementos que permitan confirmar de forma independiente la finalización
  • Escalamiento: en qué situaciones interviene quién, y quién ejecuta al agente
  • Presupuesto: límites de tiempo, esfuerzo y tokens
• Los tokens son el presupuesto de los grandes modelos de IA, y también pueden incluir límites a la cantidad de intentos y al grado de paralelismo

Las métricas hacen que la autonomía sea un poco más confiable

• Definir métricas solo a posteriori puede no ser suficiente
• Las métricas pueden colocarse por adelantado en un documento conciso y hacer que la autonomía sea más confiable
• Algunos ejemplos de métricas que se pueden seguir por nivel de autonomía son
  • Tiempo promedio entre intervenciones
  • Mayor tiempo de ejecución sin supervisión para trabajos aceptados
  • Proporción entre acciones ejecutadas en sandbox y acciones escaladas
  • Proporción entre acciones aprobadas automáticamente y rechazadas
  • Número promedio 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 por nivel de confianza
  • Tasa de defectos escapados por nivel de confianza
  • Costo en tokens por cambio aceptado
• Un solo agente que se mantiene ocupado con tareas que le pasa una persona se parece más a Level 4 con dashboard, mientras que un agente conservador que no avanza sin recepción automatizada, reintentos y evidencia suficiente se parece más a Level 5 con gates reales

Preparación y elección del nivel de autonomía

• Las tareas deben clasificarse según el riesgo y la reversibilidad
• La autonomía debe aplicarse de forma conservadora y elevarse solo cuando se acumule evidencia que respalde un nivel más alto
• Una refactorización de un motor de pagos con tests sólidos, agente revisor y una ruta limpia de rollback puede soportar más autonomía que una tarea de automatización de documentación sin criterios de respuesta correcta
• El nivel de autonomía debe seguir el proceso de verificación, no el nombre de la tarea

Cuatro antipatrones de autonomía

• Autonomy as status

  • El nivel de autonomía del agente funciona como una insignia de estatus sin significado
  • La alta autonomía se trata como evidencia de capacidad, no de seguridad, y los agentes se ejecutan en niveles que la verificación no respalda
  • Hay que elogiar y recompensar a quienes eligen el nivel correcto de autonomía y no cruzan la línea

• Permission laundering

  • Por fatiga de aprobación, se otorgan a los agentes y herramientas de IA permisos de acceso más amplios de lo necesario
  • Hay que reforzar límites como perfiles de sandbox, raíces de escritura con alcance limitado, listas de comandos permitidos, hooks y Auto-review

• Summary substitution

  • El resumen del trabajo del agente reemplaza a la revisión
  • Hay que acompañarlo con el mismo paquete de evidencia que una revisión manual
  • Puede incluir diff, tests, logs, capturas de pantalla, hallazgos del revisor, riesgos y vacíos

• Fleet cosplay

  • Se ejecutan decenas de agentes en paralelo, pero la persona sigue coordinando manualmente todas las dependencias
  • El estado compartido, las reglas de propiedad y un mejor seguimiento de dependencias reducen la necesidad de coordinación manual
  • Límites de WIP más pequeños pueden obligar a enfocarse en codificar y documentar los pasos de coordinación, lo que puede llevar a automatizar la orquestación

Cómo subir de nivel de forma segura

• Se propone un ejercicio de calibración que revisa 10 trabajos recientes asistidos por agentes
  • Nivel de autonomía de cada trabajo
  • Riesgo
  • Facilidad de reversión
  • Evidencia generada para satisfacer los requisitos de verificación
  • Tiempo de revisión
  • Si hubo retrabajo
  • Si el mismo nivel de autonomía sería adecuado la próxima vez
• Hay que subir un eje a la vez
• El punto de partida es que un único supervised agent realice una tarea acotada que produzca evidencia defendible de éxito
• Luego se expande gradualmente en tres direcciones
  • Paralelizar tareas de exploración centradas en lectura
  • Agregar agentes de escritura en worktrees separados con reglas limitadas de propiedad de archivos
  • Agregar automatización iterativa y luego orquestación impulsada por agentes basada en issues, voz u otros disparadores
• Cada aumento de nivel exige nuevas salvaguardas frente a nuevos modos de falla
• Los modos de falla son los siguientes
  • Ejecuciones largas de un solo agente: deriva, corrupción de contexto, comunicación omitida, desvío del objetivo
  • Trabajo en segundo plano: supuestos obsoletos, traspasos débiles
  • Exceso de trabajo paralelo: merge conflicts, decisiones duplicadas
  • Exceso de trabajo iterativo: gasto silencioso de tokens, prompts obsoletos
  • managed-by-exception: colas de revisión largas, fatiga de notificaciones
• No se trata de confiar más fuerte, sino de reducir el alcance, obtener mejor evidencia, crear rutas de rollback más baratas, fortalecer gates y aclarar mejor las reglas de propiedad

Casos de uso adecuados por nivel

• Level 0 es más adecuado para trabajos delicados y situaciones donde se está formando criterio
• Level 1 es adecuado para la mayoría de las exploraciones cerca de límites bien entendidos
• Level 2 es adecuado para la mayoría de las tareas acotadas que pueden tener dependencias desconocidas y problemas inesperados
• Level 3 es adecuado cuando se pueden expresar con suficiente claridad las condiciones de éxito
• Level 4 es adecuado cuando el trabajo puede dividirse limpiamente según condiciones de éxito
• Level 5 es adecuado después de que la coordinación y la comunicación necesarias entre múltiples condiciones de éxito estén completamente codificadas

La verificación seguirá siendo el cuello de botella

• A pesar del nivel actual de confianza y herramientas, la postura de un equipo de ingeniería maduro que trabaja con agentes de IA es la calibrated autonomy
• En el futuro cercano habrá que diseñar loops que sepan cuándo trabajar, cuándo verificar y cuándo preguntar
• La capacidad del ingeniero seguirá estando en elegir el nivel adecuado de autonomía y en crear patrones y evidencia defendible que bloqueen su lado oscuro