Autonomía no es lo mismo que autoridad: el principio que falta en la mayoría de arquitecturas de IA agéntica

Un agente de IA puede razonar sobre un problema, evaluar tres alternativas y llegar a la conclusión correcta. Y aun así no debería tener permiso para ejecutar esa conclusión.

Esa distinción — entre lo que un agente puede decidir y lo que un agente tiene autoridad para ejecutar — es la que separa un piloto que impresiona en una demo de un sistema que sobrevive seis meses conectado a datos y sistemas reales. Y es, sospecho, la razón por la que tantos proyectos de IA agéntica se quedan atascados entre el hackathon y la producción.

¿Qué es la autonomía de un agente de IA, exactamente?

La autonomía es la capacidad de un agente para percibir información, razonar sobre un objetivo y decidir una acción sin intervención humana en cada paso. Microsoft, en la documentación de su Semantic Kernel Agent Framework, describe un agente de IA como una entidad de software capaz de recibir información, procesarla y ejecutar acciones para alcanzar objetivos concretos, de forma autónoma o semiautónoma.

Esa definición es correcta, pero incompleta si se usa para diseñar un sistema real. Habla de capacidad, no de permiso. Y en cualquier arquitectura conectada a un sistema de producción, esas dos cosas se gobiernan por separado.

Un modelo de lenguaje más potente no debería recibir automáticamente más autoridad. Puede mejorar su capacidad de análisis — pero la autoridad para ejecutar una acción tiene que seguir determinada por políticas y controles externos al modelo, no por lo bien que razone.

¿Qué es el "agent loop" y por qué todo el mundo habla de eso ahora?

El agent loop es el ciclo de percepción-razonamiento-acción que repite un agente hasta completar una tarea: observa el estado actual, decide el siguiente paso, ejecuta una herramienta, observa el resultado, y vuelve a decidir. Es el mecanismo detrás de patrones como ReAct y de la mayoría de los frameworks agénticos actuales.

Es también, ahora mismo, uno de los temas que más fricción genera en la conversación técnica sobre IA agéntica — y por buenas razones prácticas, no solo teóricas:

• Bucles que no terminan. Un agente sin condición de salida clara puede seguir llamando herramientas indefinidamente, acumulando coste de tokens sin acercarse a una solución.
• Errores que se amplifican. Si un paso del loop interpreta mal un resultado, ese error se propaga a las siguientes iteraciones en lugar de corregirse.
• Acciones irreversibles dentro de un ciclo automático. Un loop que puede llamar herramientas libremente puede ejecutar una acción con efectos secundarios reales — como una compra o un envío — sin que nadie la revise antes de que ocurra.

El error habitual es tratar el loop como si fuera solo un problema de ingeniería de prompts: "si el agente se atasca, hay que mejorar las instrucciones". En la práctica, el loop necesita límites estructurales — número máximo de iteraciones, puntos de control obligatorios, y acciones que quedan completamente fuera de lo que el loop puede ejecutar sin aprobación. Eso no se resuelve con un mejor prompt. Se resuelve con arquitectura.

¿Por qué la mayoría de los pilotos de IA agéntica no llegan a producción?

No suele ser por la calidad del modelo. Suele ser porque nadie definió, antes de construir el agente, qué puede ejecutar sin supervisión, qué necesita un visto bueno humano, y qué debe quedar completamente fuera de su alcance.

Sin esa definición previa, ocurre uno de dos escenarios: el equipo restringe tanto al agente que deja de aportar valor real, o lo deja actuar con demasiada libertad y la primera acción problemática — una orden duplicada, un dato mal escrito, una respuesta enviada a la persona equivocada — mata la confianza del negocio en el proyecto completo.

La solución no es un mejor modelo. Es una arquitectura de gobernanza definida antes de escribir la primera línea de código del agente.

¿Cómo se diseña la autonomía por niveles de riesgo?

Una forma práctica de resolver esto es clasificar cada acción posible del agente según el riesgo real de ejecutarla mal, no según su complejidad técnica:

La ventaja de este modelo es que convierte la autonomía en una propiedad del sistema, no del modelo. Un mismo agente, con el mismo LLM debajo, puede operar con autonomía completa en L0–L2 y estar completamente bloqueado en L5 — no porque el modelo "no sepa" hacerlo, sino porque la arquitectura no se lo permite.

¿Cuándo debería un agente pedir aprobación humana antes de actuar?

La guía de patrones de orquestación de agentes de Microsoft para Azure Architecture Center es clara en un punto: los puntos de control humano no tienen que aplicarse a todo lo que hace el agente, sino que pueden limitarse a invocaciones de herramientas específicas, de forma que el resto del flujo siga siendo autónomo mientras solo las operaciones sensibles esperan revisión.

Esto es exactamente el diseño que evita el problema más común del human-in-the-loop mal implementado: convertirlo en un cuello de botella que obliga a una persona a revisar cada paso, lo cual anula buena parte del valor de automatizar. El punto de intervención correcto es la acción de riesgo, no la conversación completa.

A nivel técnico, frameworks como LangGraph ya resuelven esto con un mecanismo de interrupción: la ejecución del agente se detiene justo antes de una herramienta marcada como sensible, el estado queda guardado, y el flujo se reanuda solo cuando una persona aprueba, edita o rechaza la acción propuesta. El agente nunca "olvida" dónde estaba — simplemente espera.

¿Siempre hace falta una arquitectura multi-agente?

No. Y esta pregunta debería hacerse antes de diseñar cualquier sistema agéntico, no después.

Microsoft documenta varios patrones de orquestación multi-agente — secuencial, concurrente, handoff, group chat y magentic — cada uno pensado para un tipo distinto de coordinación entre agentes especializados. Ninguno de ellos es el patrón "por defecto"; la elección depende de si el problema realmente requiere que distintos agentes colaboren, o si es, en el fondo, una secuencia de pasos determinista.

Si tu proceso es "consultar datos → aplicar una regla → generar una propuesta", probablemente no necesitas varios agentes conversando entre sí. Un workflow determinista con un único agente — o sin agente en absoluto — suele ser más barato, más fácil de probar y muchísimo más fácil de auditar.

La arquitectura multi-agente empieza a justificarse cuando hay responsabilidades genuinamente especializadas, contexto distinto por dominio, o decisiones que requieren coordinar información de varias fuentes antes de actuar. La complejidad nunca debería ser el objetivo — es un costo que solo vale la pena pagar cuando el problema lo exige.

Preguntas frecuentes

¿Qué diferencia hay entre un agente de IA y un chatbot?

Un chatbot genera respuestas conversacionales. Un agente de IA, además de responder, puede usar herramientas y ejecutar acciones sobre sistemas reales para alcanzar un objetivo, con distintos niveles de supervisión humana.

¿Qué es human-in-the-loop en el contexto de agentes de IA?

Es un punto de control donde el flujo del agente se detiene antes de ejecutar una acción de riesgo y espera una decisión humana — aprobar, editar o rechazar — antes de continuar. No implica supervisar cada paso del agente, solo los pasos sensibles.

¿Por qué mi agente entra en un bucle sin terminar?

Casi siempre porque no hay un límite explícito de iteraciones ni una condición de salida clara ante resultados ambiguos. La solución no es un mejor prompt, es un límite estructural: número máximo de pasos, timeout, y una vía de escalamiento a revisión humana cuando el agente no converge.

¿Un modelo más potente necesita más permisos?

No debería. La capacidad de razonamiento de un modelo y la autoridad para ejecutar acciones son cosas distintas que se gobiernan por separado. Un modelo mejor puede analizar mejor un problema sin que eso implique automáticamente más autonomía para actuar sobre él.

¿Cuándo NO conviene usar una arquitectura multi-agente?

Cuando el proceso es, en el fondo, una secuencia determinista de pasos sin necesidad real de coordinación entre dominios especializados. En esos casos, un único agente — o incluso un workflow sin agentes — suele ser más barato, más rápido de construir y mucho más fácil de auditar.

Este artículo es la primera parte de una serie sobre arquitectura de sistemas agénticos. La segunda parte cubre la capa de implementación — tool calling, idempotencia, separación de estado y observabilidad — para llevar estos principios de gobernanza a un sistema conectado a datos reales.

Continúa la línea de nuestra guía anterior sobre desarrollo agéntico en equipos de software, donde exploramos estos mismos principios de orquestación aplicados al ciclo de vida del desarrollo.

Fuentes técnicas

• Semantic Kernel Agent Framework — Microsoft Learn: learn.microsoft.com
• Semantic Kernel Agent Orchestration — Microsoft Learn: learn.microsoft.com
• AI Agent Orchestration Patterns — Azure Architecture Center: learn.microsoft.com
• Human-in-the-Loop — LangGraph Docs by LangChain: docs.langchain.com