Flujos de trabajo de agentes IA, enrutamiento de intención y colaboración multiagente

Las empresas pueden gestionar agentes de IA tratándolos como servicios operativos con inventario, versiones, estado, flujos de trabajo, estadísticas de invocación, reglas de enrutamiento y retroalimentación de resultados. El enrutamiento de intención debe decidir qué agente o flujo de trabajo gestiona cada solicitud, y la colaboración multiagente debe mantenerse visible como una secuencia planificada de pasos en lugar de convertirse en una cadena opaca.

El modelo de desarrollo de referencia combina cuatro capacidades: inventario de agentes, orquestación visual, planificación de intención y análisis de resultados. Juntas conforman una capa de gestión indispensable para pasar de agentes aislados a aplicaciones empresariales coordinadas.

¿Qué es un agente de IA empresarial en este modelo operativo?

En el modelo de referencia, un agente es un objeto gestionado que puede organizarse por dominio de negocio, versionarse, monitorizarse, orquestarse y publicarse como un servicio.

El inventario de agentes registra el dominio empresarial, la versión, el estado, el volumen de llamadas y la latencia. Esa es la primera diferencia sustancial respecto a tratar a un agente como un script puntual. En cuanto otras aplicaciones consumen un agente, este necesita un estado operativo: qué versión está activa, si responde correctamente, con qué frecuencia se invoca, cuánto tarda en responder y qué flujo de trabajo lo utiliza. Esas son cuestiones operativas clave.

¿Por qué importa el inventario de agentes?

El inventario de agentes evita que un entorno en crecimiento se convierta en una colección descontrolada de experimentos.

El modelo de referencia agrupa los agentes por dominio de negocio, lo que permite a las organizaciones ordenarlos según su propósito. Distintos dominios pueden contener agentes independientes para operaciones, finanzas, atención al cliente o conocimiento interno, por ejemplo. Los materiales de referencia no imponen una taxonomía universal; el requisito operativo es simplemente que cada agente cuente con una ubicación identificable, una versión y un estado claros.

Un inventario también respalda la gestión del ciclo de vida. Puedes identificar una versión obsoleta, publicar una actualización y recurrir a las estadísticas de invocación para comprobar si un agente se está utilizando realmente.

¿Qué es un flujo de trabajo de agente?

Un flujo de trabajo de agente es la secuencia orquestada de nodos de modelo, conocimiento, herramientas, bifurcaciones, respuestas y fin utilizada para completar una tarea.

El lienzo visual de referencia incluye nodos de inicio, modelo, base de conocimiento, llamada a herramientas, bifurcación, respuesta y fin. Eso hace que el flujo sea completamente auditable, ya que un usuario u operador puede comprobar qué componentes participan en cada fase. Ayuda tanto en el diseño como en la resolución de problemas: si una orquestación falla, el equipo puede examinar con precisión qué nodo o bifurcación generó el error.

Por tanto, un flujo de trabajo es mucho más que un prompt. Es la definición operativa exacta de cómo el agente lleva a cabo una tarea.

¿Por qué utilizar un lienzo de orquestación visual?

Un lienzo visual hace que el flujo de trabajo resulte lo bastante explícito como para poder gestionarse y publicarse.

El modelo de referencia utiliza una interfaz única para el inventario de agentes, la orquestación visual y las estadísticas de invocación, conectando el diseño y la operación para el equipo. El lienzo puede mostrar por dónde entra la solicitud, qué modelo se emplea, si se consulta la base de conocimiento, qué herramientas se activan, dónde se toman las decisiones de bifurcación y cómo se devuelve la respuesta.

Los materiales de referencia no pretenden que todo flujo de trabajo deba ser estrictamente visual. Describen el enfoque de orquestación visual de la solución. El principio operativo de fondo es que el flujo debe ser inspeccionable y estar versionado.

¿Qué es el enrutamiento de intención?

El enrutamiento de intención decide qué componente debe resolver la solicitud del usuario.

En el modelo de planificación de intención de referencia, la solicitud del usuario ingresa por un único punto de entrada. A continuación, el motor de intención decide si debe derivarla a un agente específico, planificar una tarea de varios pasos, responder directamente o recurrir a la recuperación de conocimiento.

Esto libera al usuario de tener que seleccionar el agente adecuado. A medida que el catálogo de agentes crece, los usuarios no deberían verse obligados a saber cuál elegir, y el modelo de referencia establece explícitamente que la planificación de intención debe asumir esa decisión por ellos.

¿Cómo funciona el reconocimiento de intención en el diseño de referencia?

El diseño de referencia clasifica una solicitud a partir de una frase, evalúa a varios agentes candidatos y recurre a una vía segura de contingencia cuando la confianza es baja.

Los materiales de referencia no especifican un algoritmo o modelo de clasificación concreto, por lo que este artículo no asume ninguno en particular. El resultado de la decisión es lo determinante. El sistema necesita una lista de candidatos, una señal de clasificación o confianza, y una regla clara para cuando el resultado resulte dudoso.

Esta última regla es fundamental, porque un nivel bajo de confianza nunca debería enviar al usuario a un agente aleatorio sin previo aviso.

¿Qué debe ocurrir cuando la confianza del enrutamiento es baja?

Utiliza la vía segura de contingencia. El diseño de referencia contempla tres opciones de respaldo: una respuesta directa para consultas sencillas, recuperación en la base de conocimiento como soporte y derivación a un operador humano cuando el sistema no pueda resolver la solicitud.

Esto evita que la capa de enrutamiento fuerce el paso de cada petición a través de un agente. Una pregunta simple no necesita un flujo multiagente, una duda documental puede resolverse directamente desde la base de conocimiento corporativa y una solicitud inabarcable debe abandonar el canal automatizado. Es un control empresarial indispensable porque hace visible la incertidumbre.

¿Qué es la colaboración multiagente?

La colaboración multiagente es un flujo de trabajo en el que más de un agente participa activamente en la resolución de la tarea del usuario.

La capa de planificación de referencia admite planificación autónoma en múltiples pasos, colaboración entre agentes y pasos revisables. El requisito operativo más determinante es que los pasos puedan auditarse, de modo que la colaboración no se transforme en una cadena opaca donde nadie sepa qué agente hizo qué. Un flujo de trabajo bien planificado puede mostrar el agente seleccionado, la tarea asignada, el resultado intermedio, el siguiente agente y la respuesta definitiva.

Los materiales de referencia no imponen cuántos agentes deben emplearse. Utilizar más agentes no garantiza mejores resultados, por lo que conviene recurrir a varios únicamente cuando la tarea exija capacidades claramente diferenciadas.

¿En qué se diferencia la planificación del enrutamiento?

El enrutamiento decide a dónde debe dirigirse la solicitud. La planificación determina la secuencia precisa de pasos necesarios para completarla.

Una solicitud puede enviarse a un único agente y concluir allí. Otra puede requerir consultar conocimiento, convocar a un agente especialista, ejecutar una herramienta, enviar el resultado a otro agente, combinar las salidas y devolver una respuesta consolidada.

El motor de intención de referencia admite planificación autónoma de varios pasos, lo que significa que el enrutamiento y la planificación deben modelarse por separado. El enrutamiento responde a: "¿Quién debe gestionar esto?". La planificación responde a: "¿Qué secuencia debe ejecutarse?". Mantener ambos conceptos diferenciados facilita enormemente la gestión del comportamiento multiagente.

¿Cómo deben utilizar el conocimiento empresarial los flujos de agentes?

El lienzo de orquestación de referencia incorpora nodos de base de conocimiento, y la capa de intención también puede utilizar la recuperación de información como soporte o vía de contingencia. De este modo, el conocimiento se convierte en un servicio reutilizable dentro de los flujos de trabajo de los agentes.

La base de conocimiento se mantiene desacoplada del modelo, por lo que un agente puede consultar una base de datos actualizada sin necesidad de reentrenar el modelo subyacente.

Para profundizar en la capa de recuperación, cómo funciona RAG con bases de conocimiento empresariales, particionado, vectorización y pruebas de recuperación explica cómo evaluar la calidad del conocimiento de forma independiente.

¿Cómo deben interactuar los flujos de agentes con las herramientas?

El modelo de orquestación de referencia incorpora nodos de llamada a herramientas, lo que permite que un flujo haga mucho más que limitarse a generar texto. Una herramienta puede otorgar acceso a una función comercial u operativa aprobada.

El diseño de partida no impone un protocolo universal ni una lista cerrada de herramientas. El requisito empresarial es que las llamadas a herramientas permanezcan visibles en el flujo y sujetas a la gobernanza habitual. En operaciones de infraestructura, los materiales de referencia sitúan la ejecución bajo permisos y aprobaciones de flujo de trabajo, y ese mismo principio debe regir cuando un agente acciona una tarea operativa. La orquestación de agentes no debe abrir atajos frente a los controles de acceso existentes.

¿Cómo deben monitorearse las estadísticas de invocación de los agentes?

La plataforma de referencia registra las llamadas por agente, la tasa de éxito, la latencia y los casos de muestra fallidos. Estas métricas son las que convierten al agente en un servicio operable: el volumen de llamadas refleja el uso, la tasa de éxito mide la fiabilidad, la latencia evalúa el rendimiento del servicio y las muestras fallidas aportan casos concretos sobre los que mejorar.

Los resultados deben poder consultarse por agente y por versión. Si una versión nueva incrementa la tasa de fallos, el equipo debe detectar ese cambio de inmediato. Las estadísticas de invocación también ayudan a decidir si un agente debe continuar publicado o retirarse.

¿Por qué son importantes las muestras fallidas?

Las muestras fallidas conectan la operación directa con la mejora continua. Un porcentaje de tasa de éxito advierte al equipo de que algo va mal, pero son las muestras individuales las que revelan exactamente qué falló.

El diseño de referencia mantiene visibles las muestras fallidas para las invocaciones de agentes y las muestras mal enrutadas para la planificación de intención. Esto respalda dos ciclos de optimización separados. Un fallo del agente exige mejorar el flujo de trabajo, el modelo, el uso de herramientas o la ruta de conocimiento. Un fallo de enrutamiento exige ajustar las reglas de intención o la lógica de asignación. Mantener ambos tipos de error separados evita que el equipo intente corregir la capa equivocada.

¿Cómo debe medirse la calidad del enrutamiento de intención?

El diseño de referencia realiza un seguimiento de la precisión de asignación y de las muestras mal enrutadas. No impone una fórmula matemática estricta para la precisión de asignación, por lo que cada empresa debe documentar qué criterio determina si una solicitud se enrutó correctamente.

El patrón operativo es transparente: mide los resultados del enrutamiento, inspecciona las solicitudes mal dirigidas y traslada esos hallazgos a las reglas de intención. Así obtienes un ciclo de mejora continua. El enrutamiento es una capacidad operativa que debe perfeccionarse a partir de los errores observados, por lo que conviene tratarlo como algo más que una configuración fija inicial.

¿Cómo puede publicarse una orquestación?

El modelo de referencia permite publicar una orquestación directamente como un servicio. Los agentes publicados utilizan la misma pasarela unificada que los servicios de modelos, de modo que la pasarela puede aplicar controles coherentes como límites de tasa (rate limiting), políticas de degradación y tarificación. La orquestación utiliza asimismo la misma definición de medición de consumo.

Esto resulta muy ventajoso porque los agentes pasan a formar parte del mismo modelo de entrega de servicios que el resto de las capacidades de IA, en lugar de circular por una vía aislada y sin control de consumo.

¿Cómo deben conectarse los servicios de agentes con la tarificación de tokens?

Los agentes publicados recurren a la pasarela de servicios unificada y a la misma definición de medición que los servicios de modelos. Esto permite vincular el consumo con el agente, el proyecto, el inquilino (tenant), el servicio de modelo y los tokens consumidos.

La plataforma de referencia también registra el volumen de llamadas de agentes y aplicaciones en la vista general de medición, lo que proporciona un modelo de consumo homogéneo. La empresa puede comprobar qué modelo generó tokens y también qué agente o ruta de aplicación originó esas peticiones.

¿Cómo deben gestionarse los permisos de los agentes?

El acceso a los agentes debe respetar los mismos límites de inquilinos y roles que el resto de la plataforma. La capa de gobernanza de referencia contempla organización, roles, matriz de permisos, inquilinos, proyectos, principio de mínimo privilegio y aprobaciones para operaciones delicadas.

Un agente no debería poder consultar una base de conocimiento ajena al inquilino autorizado del usuario. Una llamada a una herramienta no debe adquirir privilegios extraordinarios solo por haber sido iniciada por un agente. La orquestación debe heredar los permisos de su despliegue y del contexto del emisor de la llamada según el diseño corporativo.

Los materiales de referencia no establecen un protocolo de autorización exclusivo y detallado para agentes, por lo que la afirmación fundamentada correcta es que los servicios de agentes deben permanecer dentro del perímetro de gobernanza de accesos ya existente en la plataforma.

¿Cómo debe funcionar la derivación a un operador humano?

La estrategia de contingencia de referencia señala que las solicitudes no resueltas pueden derivarse a una persona. Esto establece un límite operativo esencial para el uso corporativo, ya que el sistema de agentes no necesita fingir que es capaz de resolver cualquier petición de forma automática.

El flujo de trabajo puede detectar una baja confianza en el enrutamiento, una intención no admitida, una planificación fallida, una restricción de políticas o la falta de datos, y trasladar la solicitud a un proceso humano. El flujo exacto de derivación dependerá de cada organización. El principio clave es que el fallo en la automatización sea visible y esté debidamente controlado.

¿Qué debe mostrar el panel de control de agentes empresariales?

El modelo de referencia proporciona una vista operativa práctica con:

• Inventario de agentes
• Dominio de negocio
• Versión
• Estado
• Volumen de llamadas
• Latencia
• Tasa de éxito
• Muestras fallidas
• Lienzo de orquestación
• Precisión de asignación de intención
• Muestras mal enrutadas
• Estado de publicación

Esto ofrece a los equipos de desarrollo y de operaciones una visión compartida. El usuario puede ver qué se espera que haga el flujo de trabajo y cómo se comporta realmente una vez publicado.

Para la cadena de desarrollo de modelos en torno a los agentes, cómo la evaluación de modelos, los conjuntos de datos, el ajuste fino y el despliegue encajan en un flujo operativo de modelos empresariales explica cómo conviven los agentes junto a las capacidades de modelos, conocimiento y despliegue.

Un ejemplo de plataforma que reúne inventario de agentes, orquestación visual, planificación de intención, colaboración multiagente y estadísticas de invocación es Sensaka.

Si tuviera que gestionar un entorno de agentes en expansión, aplicaría una regla estricta: cada agente publicado necesita una versión, un propietario o dominio de negocio, un flujo visible, estadísticas de uso, muestras de fallo y una ruta de enrutamiento con contingencia segura. Sin esos controles, añadir más agentes incrementa la complejidad mucho más rápido de lo que aumenta la capacidad útil real.