// NOTE · destination-and-boundaries-es

Si el destino y los límites se conocen, el sistema debería poder conducir

La autonomía no consiste en darle a un agente libertad ilimitada, sino en darle el contexto, la autoridad y los límites suficientes para que no necesite preguntar en cada paso.

Piensa en la persona más autónoma con la que hayas trabajado — no la que hace lo que le da la gana, sino aquella a la que de verdad llamarías autónoma en el buen sentido. No pregunta qué hacer a cada paso, y tampoco actúa por libre. Lo que tiene es muy concreto: entiende el objetivo, sabe hasta dónde llega su autoridad, sabe qué decisiones son suyas y de nadie más, y sabe cuándo levantarse e ir a preguntar. Quítale cualquiera de esas tres cosas y todo se rompe. Sin el objetivo, optimiza lo que no toca. Sin los límites, “autónomo” pasa a significar “sin supervisión”. Sin el criterio para saber cuándo escalar, te queda alguien que o te interrumpe constantemente o se salta un límite que debería haber señalado.

Esa combinación — ni libertad total ni obediencia ciega, sino un entendimiento operativo del destino, los límites y el momento de preguntar — es lo que entiendo por autonomía en el trabajo. Y es también la única definición de autonomía que he encontrado que se traslada limpiamente a un agente de software.

La autonomía no es la ausencia de estructura

Existe una versión de “autonomía” que en realidad significa “sin reglas” — la del “déjalo que se las apañe solo”. Esa versión nunca ha descrito de verdad cómo trabaja la gente autónoma. La investigación organizacional estudia la autonomía laboral como margen de decisión dentro de un puesto — sobre horarios, decisiones, método — no como la ausencia de puesto [S1]. La teoría de la autodeterminación de Deci y Ryan sitúa la autonomía junto a la competencia y la vinculación como una necesidad psicológica básica [S2]: lo que importa es que la gente la necesita, no que quitar la estructura sea lo que la satisface. Un empleado autónomo sigue teniendo jefe, ámbito y consecuencias — la autonomía está en el margen de decisión, no en la ausencia de marco.

Ahí va la tesis, tal como la uso yo:

La autonomía no consiste en darle a un agente libertad ilimitada. Consiste en darle suficiente contexto, autoridad y límites para que no necesite preguntarte qué hacer en cada paso. “If the destination and boundaries are known, the system should be able to drive.”

Eso no es un permiso para relajar la supervisión. Se parece más a una descripción del puesto — y, como toda descripción de puesto, la mayor parte del trabajo está en lo que presupone.

“Conocido” es una afirmación que hay que ganarse

Fíjate en el condicional: si el destino y los límites se conocen. Esa palabra hace más trabajo del que parece. Un destino no se conoce solo porque alguien haya escrito una frase describiéndolo — se conoce cuando puedes comprobar si has llegado. Un límite no se conoce solo porque alguien crea que existe — se conoce cuando está por escrito, se verifica, y de verdad puede frenar al sistema cuando se acerca a él.

Esto no es un problema que haya inventado el software. El trabajo de Herbert Simon sobre la racionalidad limitada planteó lo mismo sobre las personas décadas antes de que los agentes fueran una cuestión de diseño: quien toma decisiones opera con información y capacidad cognitiva limitadas, y busca una respuesta que funcione, no una demostrablemente óptima [S10]. La persona que fija los límites también está limitada — no puede enumerar todas las excepciones, todas las reglas no escritas que solo viven en su cabeza. Así que “el destino y los límites se conocen” es una afirmación que se verifica, no una premisa que se da por hecha. Sáltate ese paso y la tesis deja de argumentar a favor de delegar para pasar a justificar un trabajo de especificación que nunca se hizo.

Tener permiso no es lo mismo que tener capacidad

Darle a alguien un título no significa que pueda sacar adelante el trabajo. Aghion y Tirole formalizaron esta distinción en las organizaciones hace treinta años: la autoridad formal es el derecho a decidir; la autoridad real es el control efectivo sobre la decisión — y ambas divergen con frecuencia [S3]. Puedes darle a alguien un rol y aun así no darle lo que necesita para ejercerlo: la información, la posición, las herramientas.

La misma brecha aparece en el momento en que le das a un agente un permiso que no puede usar. Tiene el derecho — a nivel de fichero de configuración — de actuar, y ninguno de los medios para terminar: el dato, la credencial, el contexto. Y el resultado no es autonomía, es un cuello de botella con etiqueta de autorización [S3, S4]. A una persona a la que se delega pero se le niega información tampoco se le puede llamar autónoma; se queda atascada, y acaba parándose o improvisando mal. La solución en ambos casos es la misma: no basta con conceder el derecho a decidir — hay que asegurarse de que la capacidad de decidir esté realmente ahí.

Saber cuándo preguntar es la habilidad entera

La parte más fácil de hacer mal es el instinto de escalar. Una persona autónoma en un equipo no pregunta por todo, pero tampoco se queda callada por todo — ha desarrollado un criterio operativo sobre qué decisiones son suyas y cuáles necesitan el juicio de otra persona. La investigación sobre seguridad psicológica encontró que los equipos donde la gente se siente capaz de señalar un problema o admitir incertidumbre reportan y sacan a la luz más de lo que realmente está pasando [S9]. El mecanismo tiene que ver específicamente con el coste de hablar — que es justo donde el paralelismo con un agente de software se rompe.

A un agente no le preocupa cómo va a quedar un error. No necesita sentirse seguro para admitir incertidumbre — necesita estar construido de forma que señalar la incertidumbre sea simplemente lo que ocurre, estructuralmente, cuando la situación lo exige, sin ningún coste por acertar al pedir ayuda. Eso es un problema de diseño, no de cultura. Pero la forma — saber qué decisiones son tuyas, cuáles no lo son, y construir un camino para entregar las segundas sin penalización — es la misma tanto si el “quién” es una persona como si es un sistema.

Donde la filosofía se encuentra con el flujo de trabajo

No quería abrir esta cuenta hablando de herramientas, así que he mantenido este post centrado en la tesis. Pero la razón por la que la tesis me importa no es abstracta — es lo que de verdad estoy intentando construir.

En la práctica, eso significa tratar las barreras humanas como gestión de excepciones, no como un sello de goma en cada paso. Una barrera justifica su coste allí donde el criterio de una persona cambiaría el resultado — un conflicto real, una restricción no escrita, una consecuencia irreversible — no en el trabajo rutinario que el sistema ya ha demostrado que sabe hacer. Significa que cada unidad de trabajo se asigna a un único ejecutor responsable, de modo que siempre quede claro quién — o qué — estaba al mando cuando se tomó una decisión. Significa que la autoridad se amplía igual que la confianza entre personas: a partir de evidencia, dominio por dominio, no por una buena semana. Y significa que todo lo que no se pueda deshacer — borrados, acciones externas, consecuencias fuera del sistema — tiene un listón más alto que el resto, sin importar lo bien que haya estado funcionando el sistema hasta entonces.

Nada de esto es exótico. Es simplemente coger las mismas condiciones que hacen que confiemos autonomía a una persona — un destino conocido, límites reales y un criterio operativo sobre cuándo preguntar — y negarse a saltárselas solo porque quien conduce ahora es software en vez de una persona.

El destino y los límites se conocen. El sistema debería poder conducir. Poder decir eso con honestidad es la mayor parte del trabajo.

Fuentes

Read in English — Versión original en inglés.