El agente de IA que ejecuta solo necesita «poner manos a la obra»
Ya explicamos la separación de poderes (aquí: la distribución de ejecución / auditoría / aprobación entre agentes distintos) en la entrega anterior y en la siguiente.
A partir de aquí vamos a descomponer cada uno de los tres roles. Empezamos por el rol de ejecución.
¿Qué es el rol de ejecución?
El rol de ejecución corresponde al agente de IA que realiza el trabajo concreto.
Escribir código, redactar borradores, ejecutar comandos, dar formato a datos. Ese tipo de «trabajo en sí» es lo que asume este rol.
Su función se reduce a recibir lo que se le pide y entregar un resultado.
En la estructura que estamos construyendo en esta serie, el rol de ejecución está diseñado como un subagent (agente de IA que recibe una tarea y actúa). Cada rol tiene su propio responsable, y cada uno se concentra en «su trabajo». El agente de ejecución es uno de ellos: está especializado en completar las tareas que se le asignan.
Lo que el agente de ejecución «hace»
El agente de ejecución se encarga de llevar a cabo tareas concretas.
Por ejemplo, le asignamos trabajos como estos:
- Redactar el borrador de un artículo
- Procesar datos indicados y exportarlos a un archivo
- Registrar entradas en la base de datos
- Operar el sistema siguiendo un procedimiento definido de antemano
En todos los casos, «qué hacer» está diseñado de antemano, y el agente actúa dentro de ese margen.
Lo importante es que el agente de ejecución «actúa dentro del alcance de las instrucciones». «Hasta dónde llegar» y «con qué criterio» lo determinan el diseño previo o un rol distinto. El agente de ejecución completa la tarea dentro de ese marco.
Hay una razón para esta estructura. Si al agente de ejecución también se le asigna «tomar decisiones», la acción y la toma de decisiones ocurren en el mismo lugar. Al revisar después, resulta difícil ver «en qué se basó para actuar así». Ese era el problema.
Separar la acción de la decisión facilita el seguimiento del registro. «Qué se hizo» y «por qué se autorizó» quedan en capas distintas. Esto tiene un impacto real en la operación.
Lo que el agente de ejecución «no hace»
Aquí está el núcleo de esta estructura.
El agente de ejecución no juzga por sí mismo si su propio trabajo está «bien».
No verifica por sí solo si el borrador que escribió es correcto. No decide por sí mismo si el resultado de ejecutar un comando es aceptable. No se da a sí mismo la aprobación (aquí: la confirmación final de que algo puede avanzar) con un «esto está bien».
Evitamos de forma deliberada la estructura en la que «quien hizo el trabajo evalúa su propio trabajo».
¿Por qué?
Porque auditar el propio trabajo es estructuralmente difícil. Estar concentrado en una tarea y al mismo tiempo realizar una evaluación objetiva es difícil incluso para las personas. Con la IA ocurre lo mismo: optimizar la ejecución y optimizar la detección de problemas son dos modos que no conviven fácilmente de forma simultánea.
Por eso, la auditoría la asume un rol distinto. La decisión final de «seguir adelante» o «detener» la gestiona otro mecanismo.
Esta es una de las razones para separar los tres poderes. Cuanto más potente es el agente de ejecución, más importante se vuelve la restricción de «no poder darse el visto bueno a sí mismo».
Lo que aprendimos al diseñar el agente de ejecución
Al ponerlo en marcha, comprendimos que la claridad del «alcance» del agente de ejecución incide directamente en la calidad del conjunto.
Cuanto más claros son los límites de «hasta aquí puede actuar, a partir de aquí lo retoma otro rol», más fácil resulta rastrear el registro de la tarea. Si surge algún problema, es más sencillo revisar qué ocurrió en cada paso.
Al contrario, si al agente de ejecución se le dice «aprovecha y revisa también» o «decide según tu criterio si hace falta», el registro se vuelve ambiguo. Todo se cierra con «lo hizo la IA». Deja de verse dónde recae la responsabilidad de quienes diseñaron el sistema.
El diseño de «solo poner manos a la obra» parece una restricción a primera vista. En la práctica, sin embargo, esa restricción es lo que mejora la visibilidad del conjunto. Por ahora, así es como lo vivimos en la operación real.