La autonomía gradual funciona cuando cada nivel tiene autoridad, evidencia y una forma clara de devolver el control

La autonomía no es binaria. Muchas discusiones plantean dos opciones: el agente aconseja o el agente hace todo. En realidad existe un espectro útil. Puede observar y recomendar, preparar una acción, ejecutarla con aprobación, actuar automáticamente dentro de límites o coordinar varias acciones reversibles. Cada nivel representa una combinación distinta de autoridad y riesgo. Tratarlo como una escalera permite desplegar valor antes de confiar tareas sensibles y hace posible ampliar permisos a partir de datos, en lugar de decidir por entusiasmo si una automatización “ya está lista”.

Cada nivel necesita un perímetro de autoridad. Decir “puede publicar” es insuficiente. ¿En qué cuentas, formatos, horarios y presupuestos? ¿Puede crear un borrador pero no lanzarlo? ¿Puede cambiar una campaña existente? El perímetro debería expresarse en reglas que el sistema pueda comprobar. Cuanto más concreta sea la frontera, menos depende de que el modelo interprete una política en lenguaje ambiguo. La autonomía útil no nace de un prompt que diga “sé prudente”; nace de capacidades y límites que la infraestructura hace difíciles de cruzar accidentalmente.

La evidencia de entrada define cuándo avanzar. Para pasar de recomendación a ejecución, el agente necesita condiciones: contenido aprobado, recurso no modificado, identidad correcta y datos completos. En niveles altos puede exigir más señales porque el costo de una acción errónea aumenta. Estas precondiciones funcionan como gates. Si falta una, el agente permanece en el nivel anterior y conserva el trabajo. La progresión se vuelve determinista y auditable. No hace falta adivinar por qué se detuvo: el estado puede decir exactamente qué condición no se cumplió.

La verificación posterior cierra el ciclo. Autoridad para actuar no equivale a autoridad para declarar éxito. Después de publicar, enviar o actualizar, el sistema debe comprobar el resultado en la fuente de verdad adecuada. Una acción de API que respondió OK puede producir un estado incompleto. La verificación debe corresponder al impacto: leer el archivo final, confirmar el correo en Sent o recuperar la configuración publicada. Esta segunda lectura permite medir desempeño real de cada nivel y detectar si un agente aparentemente autónomo todavía requiere demasiadas correcciones.

Devolver el control también debe diseñarse. Un sistema puede empezar en modo automático y encontrar una situación que excede su política: un destinatario nuevo, un conflicto o una dependencia no disponible. El handback debería ser un estado normal, no una excepción vergonzosa. El agente presenta qué hizo, qué detectó y qué decisión necesita. Si la persona resuelve el punto, la automatización revalida y continúa. Así se evita que la única respuesta ante incertidumbre sea fallar por completo o seguir sin autoridad.

La promoción de nivel necesita datos longitudinales. Una demo exitosa no justifica ampliar permisos. Conviene observar una cohorte de tareas: tasa de resultado, correcciones, abstenciones correctas, incidentes y tiempo ahorrado. Después se puede permitir más autonomía en escenarios estrechos y mantener otros bajo aprobación. La evolución puede ser granular por usuario, cuenta o acción. Este enfoque se parece a un rollout progresivo: no “activamos autonomía”, sino que habilitamos capacidades concretas allí donde la evidencia muestra que el riesgo está controlado.

Aplicación Goatify. Podemos convertir esta escalera en una propiedad explícita de cada habilidad. Nivel 0 observa; nivel 1 recomienda; nivel 2 prepara; nivel 3 ejecuta con aprobación; nivel 4 actúa dentro de políticas; nivel 5 coordina un workflow completo con gates. El nombre exacto es secundario. Lo importante es que cada nivel tenga permisos, precondiciones y verificación. Esto nos permitiría vender autonomía como un camino controlado y adaptar el producto al apetito de riesgo del cliente sin mantener versiones completamente distintas de la misma habilidad.