La mayoría de las conversaciones sobre sistemas basados en agentes de IA todavía se desarrollan en términos de ingeniería: ventanas de contexto, llamadas a herramientas, evaluación, orquestación, memoria y mecanismos de protección. Aunque este vocabulario es necesario, también es incompleto.
Si le preguntamos a un líder de ingeniería experimentado qué debería incluir un entorno de ejecución bien diseñado para un sistema autónomo, probablemente mencionará objetivos claros, restricciones explícitas, un alcance delimitado, mecanismos de escalamiento, desempeño observable y ciclos de retroalimentación que permitan mejorar el comportamiento con el tiempo. Si le preguntamos a un gerente experimentado cómo dirige un equipo de alto rendimiento, es probable que su descripción sea sorprendentemente similar.
Esta convergencia no es casualidad: estamos comenzando a construir sistemas de software que hacen mucho más que ejecutar instrucciones predefinidas. Actualmente, los agentes pueden interpretar objetivos, seleccionar acciones y operar con autoridad delegada. Cuando el software comienza a comportarse de esta manera, diseñar el entorno en el que funciona empieza a parecerse al trabajo de gestión.
La industria todavía trata estos aspectos como disciplinas separadas. El diseño del entorno de ejecución de agentes pertenece a la ingeniería. La delegación, la confianza y la responsabilidad pertenecen a la gestión. Sin embargo, en la práctica, ambos campos se están convirtiendo en formas diferentes de describir un mismo problema.
Esto no comenzó con la inteligencia artificial. La transición hacia las plataformas en la nube, DevOps y las arquitecturas distribuidas ya había ampliado el alcance del desarrollo y la entrega de software. Las tareas que antes estaban separadas entre desarrollo de aplicaciones, infraestructura y operaciones comenzaron a diseñarse y gestionarse de manera conjunta, frecuentemente dentro de equipos más multidisciplinarios.
Las expectativas de contratación también aumentaron a medida que se ampliaba ese alcance. Las ofertas de empleo para puestos de nivel inicial comenzaron a exigir que los candidatos comprendieran no solo cómo escribir código, sino también cómo ese código se ejecutaba en infraestructuras en la nube y cómo se comportaba en producción. La experiencia en entornos de producción con AWS o GCP, contenedores, Kubernetes, observabilidad y pipelines de despliegue empezó a aparecer como requisito incluso en puestos que seguían clasificándose como junior.
Ahora, los sistemas basados en agentes de IA están añadiendo otra capa de complejidad. Se espera que los ingenieros y los equipos de desarrollo comprendan aspectos como la orquestación, los permisos de herramientas, la arquitectura de memoria, la evaluación y el comportamiento durante la ejecución, además de todas las capacidades que ya requería el desarrollo moderno de software. Pero esto no consiste simplemente en incorporar otra especialidad técnica al equipo. Cambia las responsabilidades que el propio sistema debe asumir desde su diseño.
Si se interpretan literalmente, muchas de estas descripciones de puestos son poco razonables. Reúnen expectativas que antes correspondían a diferentes etapas de una carrera en ingeniería y las concentran en un único puesto junior. Exigen experiencia en entornos de producción en la nube, conocimientos de infraestructura, orquestación de contenedores y, ahora, diseño de sistemas basados en agentes, sin eliminar ninguno de los requisitos anteriores. Sin embargo, si las interpretamos como señales organizacionales, revelan que las empresas esperan cada vez más que los ingenieros trabajen en un entorno técnico mucho más amplio.
La especialización sigue siendo importante. Todavía es necesario contar con profesionales que comprendan profundamente los sistemas distribuidos, la seguridad, los datos, el aprendizaje automático o la arquitectura de aplicaciones. Pero tener conocimientos profundos en una sola disciplina ya no es suficiente para el tipo de trabajo que están generando los sistemas basados en agentes de IA. El desafío más complejo consiste en comprender cómo interactúan estas disciplinas, cómo se distribuyen las responsabilidades entre ellas y cómo una decisión técnica aparentemente aislada puede generar consecuencias organizacionales en otras partes del sistema.
El software distribuido moderno ya había comenzado a dar lugar a un nuevo perfil: el especialista generalista, alguien con conocimientos profundos en un área específica que también comprende cómo interactúan el código de las aplicaciones, la infraestructura, los despliegues y las operaciones. Los sistemas basados en agentes amplían esta necesidad, pero también cambian su naturaleza.
Ya no basta con comprender diferentes disciplinas. Alguien debe decidir qué criterios y decisiones pueden delegarse, qué puede hacer un agente sin aprobación, qué acciones deben poder revertirse, cuándo es necesario escalar una decisión y quién mantiene la responsabilidad por los resultados. Posteriormente, esas decisiones deben traducirse en permisos, mecanismos de identidad, controles durante la ejecución, registros de auditoría y mecanismos que permitan ampliar o retirar la autonomía. El especialista generalista puede haber sido el precursor de este cambio. Sin embargo, el trabajo que está surgiendo ahora tiene características más específicas.
Un agente no puede diseñarse de manera aislada
Esto cobra especial importancia cuando analizamos la ingeniería de los entornos de ejecución de agentes, conocida como harness engineering. Un ingeniero que se concentre exclusivamente en el agente podría prestar atención al prompt, las herramientas disponibles, la selección del contexto, los criterios de evaluación, los mecanismos de protección y el consumo de tokens. Aunque cada una de estas decisiones es importante, ninguna determina por sí sola si el sistema puede operar de forma segura dentro de una empresa.
Las preguntas más complejas se encuentran un nivel por encima del agente:
- ¿En qué arquitectura se integrará?
- ¿Sobre qué sistemas puede actuar?
- ¿A qué información puede acceder?
- ¿Qué decisiones puede tomar de manera reversible y qué acciones generan obligaciones que no pueden deshacerse fácilmente? ¿Qué nivel de autoridad necesita?
- ¿Quién asume las consecuencias cuando el agente actúa correctamente según sus instrucciones, pero la organización sufre algún perjuicio?
Estas preguntas relacionadas con la gobernanza no deberían responderse después del despliegue. Por el contrario, deberían definir desde el principio cómo se construye el sistema.
Un agente autorizado para resumir las comunicaciones con los clientes no es el mismo tipo de sistema que uno autorizado para enviar respuestas. Del mismo modo, un agente que puede recomendar una compra no es equivalente a uno que tiene autoridad para negociarla o aprobarla. El modelo subyacente puede ser exactamente el mismo, pero la diferencia está en la autoridad que se le delega y en la arquitectura mediante la cual se controla esa autoridad.
Por eso, la capacidad es una unidad de análisis equivocada. Resulta más útil analizar la autonomía delimitada: qué puede decidir el sistema, qué puede hacer, bajo qué condiciones, con qué nivel de observabilidad y bajo la responsabilidad de quién.
Cuando el problema se plantea de esta manera, el diseño del entorno de ejecución deja de parecer un conjunto de controles técnicos. Se convierte en la arquitectura de la delegación.
Los mecanismos de protección son solo una parte del problema
La respuesta instintiva ante una mayor autonomía suele ser pedir mecanismos de protección más estrictos.
Es una reacción razonable, pero insuficiente. Los mecanismos de protección pueden impedir acciones conocidas, establecer límites de gasto, restringir el acceso a datos, bloquear comandos destructivos y exigir aprobación cuando se superan determinados umbrales. Son especialmente eficaces cuando los límites pueden expresarse mediante reglas deterministas.
Sin embargo, muchas decisiones con consecuencias importantes no pueden controlarse de esa manera. Por ejemplo, un agente de atención al cliente podría cumplir todas las políticas explícitas y aun así perjudicar una relación por una decisión poco acertada. Un agente de compras podría mantenerse dentro de su límite financiero y aceptar condiciones que generen riesgos a largo plazo. Un agente de programación podría superar todas las pruebas automatizadas y, aun así, introducir una arquitectura que resulte cada vez más difícil de modificar.
En ninguno de estos ejemplos vemos un sistema que haya escapado de sus restricciones. Lo que ocurre es que las restricciones no lograron representar aquello que realmente le importaba a la organización.
Los gerentes se enfrentan al mismo problema. Un equipo puede seguir todos los procesos documentados y aun así obtener un resultado equivocado, porque la gestión no puede reducirse al cumplimiento de reglas. Implica definir objetivos, distribuir autoridad, interpretar el contexto, ajustar los niveles de confianza, detectar excepciones y modificar el entorno cuando el comportamiento revela que las suposiciones iniciales estaban incompletas.
Los sistemas basados en agentes requieren el mismo enfoque. El entorno de ejecución no se limita a restringir el comportamiento. También comunica la intención, establece mecanismos de escalamiento y convierte los resultados observados en cambios en la forma de operar del sistema. Es un sistema de gestión, independientemente de que quienes lo construyan utilicen o no ese término.
El software está pasando de la ejecución a la delegación
El software tradicional también requería gestión, pero gran parte de ella se realizaba durante el diseño. Los ingenieros especificaban los estados y las transiciones permitidas. Después, la máquina ejecutaba esas decisiones de manera determinista. Cuando el software se comportaba incorrectamente, la explicación habitual era que la implementación no coincidía con las especificaciones o que estas no contemplaban determinada situación.
Los sistemas basados en agentes complican esta relación. El diseñador ya no determina todas las acciones de antemano. Define objetivos, permisos, contexto, criterios de evaluación y condiciones de escalamiento, y después permite que el sistema seleccione acciones dentro de ese entorno.
Esto cambia la naturaleza del trabajo de ingeniería. La pregunta central ya no es únicamente «¿Qué debería hacer el sistema?», sino también «¿Qué decisiones le estamos permitiendo tomar sobre cómo alcanzar ese resultado?».
Esta es una cuestión de delegación, y delegar requiere algo más que conceder permisos. Exige comprender las capacidades, los riesgos y las consecuencias. Un gerente no delega simplemente porque alguien sea capaz de realizar una tarea. Considera si la persona comprende el objetivo, si la decisión puede revertirse, si las consecuencias son visibles, cuándo se espera que escale una situación y cuánto margen de decisión permite el contexto.
Los sistemas basados en agentes obligan a los ingenieros a incorporar versiones de esos criterios en la arquitectura. Los permisos se convierten en límites de autoridad; el monitoreo se convierte en supervisión; la evaluación se convierte en gestión del desempeño; la lógica de escalamiento establece una relación operativa; y la memoria y la retroalimentación determinan qué aprende el sistema de la experiencia. La identidad determina en nombre de quién parece actuar.
La analogía no es perfecta. Los sistemas de IA no son empleados, y tratarlos como personas puede ocultar aspectos técnicos importantes. Sin embargo, el problema de diseño se parece cada vez más al de la gestión, porque ambos implican delegar decisiones de manera controlada en condiciones de incertidumbre.
Las consecuencias organizacionales
Esto genera una brecha de capacidades que las mejores herramientas no podrán cerrar por sí solas. Un ingeniero puede comprender los frameworks de orquestación sin entender cómo se distribuye la autoridad dentro de una organización. Un gerente puede comprender la delegación, pero saber poco sobre cómo se implementan los permisos, la identidad y los mecanismos de escalamiento en los sistemas de producción. Ambos pueden ser muy competentes en sus respectivas disciplinas y aun así pasar por alto los problemas que surgen entre ellas.
La respuesta inmediata probablemente será la formación interdisciplinaria. Se pedirá a los ingenieros que comprendan la autoridad, la reversibilidad y las consecuencias organizacionales. A su vez, se pedirá a los gerentes, equipos legales y responsables de gobernanza que comprendan los permisos, la identidad, los controles durante la ejecución y la observabilidad. Este intercambio de conocimientos es necesario, pero no explica completamente lo que está ocurriendo.
La formación interdisciplinaria parte de la idea de que la arquitectura técnica y la delegación organizacional siguen siendo disciplinas separadas cuyos profesionales necesitan comprender mejor el trabajo de los demás. Los sistemas basados en agentes cuestionan esa separación. La autoridad concedida a un agente se expresa mediante la arquitectura técnica, mientras que las decisiones técnicas sobre herramientas, permisos, memoria y escalamiento determinan la autoridad que puede ejercer en la práctica. Ambos aspectos ya no pueden diseñarse de manera independiente.
Esto está comenzando a dar forma a una disciplina propia: la arquitectura de delegación.
La arquitectura de delegación se ocupa de cómo las organizaciones transfieren formas delimitadas de ejecución y toma de decisiones a sistemas que actúan en su nombre. Determina qué puede delegarse, qué grado de autonomía es apropiado, qué decisiones deben poder revertirse, cuándo es necesario escalar una situación, cómo cambia la autoridad según la evidencia disponible y quién sigue siendo responsable del resultado.
Partes de este trabajo ya existen en la arquitectura de plataformas, la gestión de productos, la seguridad, la gobernanza, el diseño jurídico y el liderazgo organizacional. El problema es que ninguna función es responsable de garantizar la coherencia del conjunto. Cada una puede controlar ciertos límites, mientras que las relaciones entre ellos permanecen implícitas.
Cuando la delegación se convierte en arquitectura
La arquitectura tradicional de software definía en gran medida el flujo de control de antemano. Los ingenieros determinaban los estados, las transiciones y las acciones permitidas, incluso cuando los sistemas resultantes eran distribuidos, asíncronos o difíciles de reproducir desde el punto de vista operativo.
Los sistemas basados en agentes introducen un problema de diseño diferente. Interpretan objetivos, seleccionan acciones durante la ejecución y ejercen cierto grado de autonomía dentro de un entorno definido. El diseñador ya no especifica cada paso. En su lugar, establece las condiciones bajo las cuales el sistema puede decidir qué sucede después. Este cambio hace que las decisiones técnicas sean inseparables de las institucionales.
Un permiso ahora es una decisión sobre autoridad. Un mecanismo de escalamiento forma parte del modelo operativo. Un umbral de evaluación puede determinar si la autonomía se amplía o se reduce. La memoria influye no solo en la continuidad, sino también en la información sobre la que se basan las decisiones futuras. La identidad determina en nombre de quién parece actuar el sistema.
Por lo tanto, el desafío central no consiste simplemente en construir agentes capaces. Consiste en decidir qué decisiones deben delegarse, convertir esa decisión en algo ejecutable y mantener la responsabilidad sobre lo que ocurra después.
Este es el ámbito de la arquitectura de delegación. La disciplina todavía no se ha consolidado como una profesión reconocida, un conjunto estandarizado de métodos o una responsabilidad asignada a una única función organizacional. Pero el trabajo ya existe. Aparece cada vez que alguien debe conectar los permisos de un sistema con los derechos de decisión, los niveles de autonomía con la evidencia, la identidad del agente con la responsabilidad y el comportamiento durante la ejecución con la autoridad concedida originalmente.
Sabremos que la disciplina ha madurado cuando las organizaciones dejen de preguntarse únicamente qué puede hacer un agente y comiencen a diseñar explícitamente qué autoridad debería tener, cómo puede ejercerla y cómo puede retirarse.
La pregunta pendiente ya no es si los ingenieros y los gerentes trabajarán cada vez más cerca. Es quién asumirá la responsabilidad de diseñar la autoridad delegada a las máquinas como un sistema empresarial coherente.
Esta última modificación también elimina la distinción cuestionable entre lo determinista y lo probabilístico, y la sustituye por una diferencia más precisa entre el flujo de control definido de antemano y las acciones seleccionadas durante la ejecución a partir de objetivos interpretados.