La superficie de reversibilidad ayuda a decidir qué acciones puede automatizar un agente primero

No todas las acciones de un agente merecen el mismo nivel de autonomía porque no todas cuestan lo mismo cuando salen mal. Buscar un archivo, crear un borrador y enviar un pago pueden compartir el mismo lenguaje de “tool call”, pero su reversibilidad es radicalmente distinta. La superficie de reversibilidad clasifica acciones según qué tan fácil es deshacerlas, cuánto tiempo existe para corregirlas y qué efectos secundarios dejan. Esa clasificación permite decidir qué capacidades pueden automatizarse primero y cuáles necesitan aprobación, límites o simulación antes de recibir autoridad real.

Una acción puede evaluarse en varias dimensiones en lugar de etiquetarse simplemente como reversible o irreversible. Considera si existe una operación compensatoria, si conserva historial, cuánto tiempo tarda en propagarse, si afecta a terceros, si mueve dinero, si cambia permisos y si su corrección depende de otra persona. Editar un borrador puede ser casi totalmente reversible; publicar un post puede borrarse pero ya haber sido visto; transferir fondos puede requerir un proceso externo. El resultado es un mapa de consecuencias más útil que una etiqueta binaria.

Ese mapa puede convertirse en una política de autonomía por niveles. Acciones con alta reversibilidad pueden ejecutarse automáticamente y registrarse. Las intermedias pueden requerir una ventana de revisión o un límite cuantitativo. Las de baja reversibilidad pueden quedarse en modo prepare-only: el agente reúne datos, valida y prepara la mutación, pero una persona o política adicional autoriza el commit. Así el mismo agente puede ser muy autónomo en tareas de bajo impacto y deliberadamente conservador cuando la consecuencia excede la capacidad de recuperación.

La reversibilidad también cambia cómo deben diseñarse logs y backups. Si una acción puede deshacerse, el sistema necesita conservar suficiente estado previo para reconstruir o compensar. Para archivos, eso puede ser versión o hash anterior; para registros, snapshot de campos; para campañas, configuración previa; para permisos, membership original. Una promesa de “podemos revertir” sin evidencia de qué existía antes es frágil. El costo de capturar estado previo debería formar parte del diseño de la tool y no quedar como una tarea manual después del incidente.

Las pruebas de autonomía deberían empezar por acciones reversibles y avanzar hacia consecuencias mayores solo cuando la evidencia lo justifique. En un shadow mode, el agente puede proponer acciones sin ejecutarlas; luego se habilitan mutaciones fáciles de revertir; después se amplía el alcance con límites. Cada etapa mide tasa de corrección, necesidad de intervención y recuperación. Este orden permite aprender con errores baratos. Hacer lo contrario —dar autoridad irreversible desde el primer día— convierte cada bug de routing o comprensión en un incidente real antes de saber cómo se comporta el sistema.

La superficie de reversibilidad crea una manera práctica de alinear autonomía con riesgo. En lugar de discutir en abstracto si “el agente debería actuar”, la organización pregunta qué acción, con qué capacidad de deshacer, bajo qué límite y con qué evidencia previa. Esa conversación produce decisiones más precisas. La autonomía deja de ser un porcentaje global y se convierte en una matriz por consecuencia. Cuanto más difícil es volver al estado anterior, más fuerte debe ser la verificación antes de cruzar la frontera de ejecución.

Cierre operativo. La autonomía no debe asignarse al agente completo; debe asignarse acción por acción según cuánto cuesta volver atrás si la decisión fue incorrecta. En la práctica, conviene evalúa reversibilidad en varias dimensiones y usa niveles de autonomía según consecuencia antes de ampliar el workflow.