Orquestación de agentes de IA para líderes de soporte

La orquestación de agentes de IA es la coordinación de varios agentes de IA especializados, y de las personas que hay detrás, para que una solicitud del cliente llegue al agente adecuado en el momento adecuado y con el contexto adecuado. Un orquestador, ya sea un agente principal o el código que rodea a los agentes, decide quién actúa a continuación, qué se transmite y cuándo ha terminado el trabajo.

En resumen

La orquestación decide qué agente atiende cada paso de una conversación, qué contexto recibe y cuándo toma el relevo una persona.
La mayoría de los entornos de soporte combinan unos pocos patrones: un enrutador o supervisor al principio, pasos secuenciales para las acciones reguladas y traspasos entre agentes y hacia personas.
Las conversaciones con varios agentes fallan en las uniones: contexto perdido en un traspaso, bucles entre agentes, el agente equivocado actuando y conversaciones cerradas antes de terminar el trabajo.
Los paneles por agente ocultan esos fallos, porque cada agente puede parecer correcto mientras el recorrido del cliente fracasa.
Haga QA del recorrido, no del turno: una cada segmento de agente y de persona en un solo registro, evalúe las uniones y atribuya cada fallo al segmento que lo causó.

¿Qué es la orquestación de agentes de IA?

La orquestación de agentes de IA es la capa que coordina varios agentes de IA dentro de un mismo sistema. IBM la describe como la coordinación de agentes especializados hacia objetivos comunes, con un orquestador que puede ser un agente central o un framework. En atención al cliente, convierte un bot de triaje, un agente de facturación, un agente de devoluciones y su equipo humano en una sola experiencia.

Un agente de IA (en inglés) es un modelo con instrucciones y herramientas que trabaja hacia un objetivo. La orquestación es el control de tráfico entre varios de ellos y responde a cuatro preguntas en cada turno:

¿Quién actúa a continuación? Un agente de triaje, un especialista, una persona o nadie (la conversación ha terminado).
¿Qué recibe? La transcripción completa, un resumen o solo los campos que necesita.
¿Qué puede hacer? Leer datos, modificar un pedido, emitir un reembolso o solo responder.
¿Cuándo se detiene? Se alcanza el objetivo, se llega a un límite de turnos o una persona debe aprobar.

Anthropic llama workflows a los sistemas en los que “los LLM y las herramientas se orquestan mediante rutas de código predefinidas”, y agentes a los sistemas en los que los modelos “dirigen de forma dinámica sus propios procesos y el uso de herramientas”. La mayor parte de la orquestación en soporte mezcla ambos: rutas fijas para los reembolsos y las verificaciones de identidad, y criterio del agente para las preguntas abiertas. Nuestro artículo sobre qué es la IA agéntica (en inglés) trata la categoría en general.

¿Quién es un orquestador de IA? Técnicamente, el componente (un agente principal o un framework) que reparte el trabajo. Organizativamente, la persona o el equipo responsable de cómo se reparten el trabajo los agentes y las personas: las reglas de enrutamiento, los disparadores de escalamiento y el estándar de calidad de todo el recorrido.

¿Cuáles son los principales patrones de orquestación de agentes de IA?

Unos pocos patrones cubren casi cualquier entorno de soporte: un enrutador que envía cada solicitud a un especialista, un supervisor que mantiene el control y llama a especialistas como herramientas, una secuencia fija de pasos, agentes en paralelo sobre la misma entrada, una jerarquía de supervisores, traspasos entre agentes y hacia personas, y un bucle de redactor y revisor. Los despliegues reales los combinan.

Cada proveedor los llama de una forma. El Azure Architecture Center de Microsoft enumera la orquestación secuencial, concurrente, en chat de grupo, por traspaso y magentic (en inglés) y señala que el traspaso también se llama enrutamiento, triaje, transferencia, despacho o delegación. El OpenAI Agents SDK (en inglés) distingue entre “agentes como herramientas”, donde un gestor mantiene el control, y “traspasos”, donde el especialista toma el relevo. IBM añade los modelos centralizado, descentralizado, jerárquico y federado. Las palabras cambian; las preguntas de soporte, no. La tabla siguiente describe cada patrón en términos de soporte.

La distinción más importante para un responsable de soporte es quién es responsable del cliente después del cambio. En un esquema con supervisor, el agente principal sigue respondiendo de la respuesta final. En un traspaso, el agente que recibe asume toda la responsabilidad, como detalla la documentación de Microsoft sobre el traspaso (en inglés). Eso determina a quién pide cuentas cuando QA encuentra una mala respuesta.

Tabla de patrones de orquestación: fallos y comprobaciones para soporte

Cada patrón de orquestación falla a su manera, así que cada uno necesita su propia comprobación. La tabla relaciona cada patrón con un ejemplo de soporte, el fallo que cabe esperar y lo que hay que mirar en la revisión. Cópiela en su plan de QA y quédese con las filas que correspondan a cómo están conectados hoy sus agentes.

Patrón	Cómo funciona	Ejemplo de soporte	Fallo típico	Qué comprobar
Enrutador (triaje)	Un agente de triaje clasifica la solicitud y la pasa a un especialista	“¿Dónde está mi reembolso?” va al agente de Facturación	Enrutamiento erróneo: el agente de Pedidos responde con seguridad a una pregunta de facturación	¿Fue correcto el primer enrutamiento? ¿Se mantuvo el especialista dentro de su ámbito?
Supervisor (gestor)	Un agente principal mantiene la conversación y llama a especialistas como herramientas	El agente principal pregunta al agente de Políticas si se admite una devolución fuera de plazo	El principal ignora o reescribe la respuesta de un especialista; el cliente recibe una mezcla de ambas	¿Coincide la respuesta final con lo que devolvió el especialista?
Secuencial (pipeline)	Pasos fijos, cada uno usa el resultado del anterior	Verificar la identidad, comprobar los requisitos, emitir el reembolso, enviar el resumen	Un error al principio se arrastra por todos los pasos (un número de pedido equivocado lleva a un reembolso equivocado)	¿Se validó el resultado de cada paso antes de que lo usara el siguiente?
Concurrente (en paralelo)	Varios agentes trabajan a la vez sobre el mismo mensaje	La redacción de la respuesta y una comprobación de política se ejecutan en paralelo	Resultados contradictorios mal combinados; el cliente ve dos respuestas	Cuando los agentes discreparon, ¿cuál se impuso y era esa la regla correcta?
Jerárquico	Supervisores que gestionan equipos de agentes por ámbito	Un supervisor de logística reparte entre los agentes de seguimiento y de devoluciones	Una solicitud cae entre dos supervisores y nadie se hace cargo	¿Hay un responsable para cada recorrido, en cada nivel?
Traspaso entre agentes	Cada agente decide cuándo pasar la conversación	El agente de Pedidos pasa un caso de artículo dañado al agente de Devoluciones	Bucles (de A a B y de vuelta a A), contexto perdido, al cliente se le piden dos veces los mismos datos	¿Cuántos traspasos hubo? ¿Apareció algún agente dos veces? ¿Tuvo el cliente que repetir información?
Traspaso a una persona	Un agente escala a una persona con un resumen	El agente de Devoluciones escala un cargo en disputa a una persona	Escalamiento demasiado tardío, o sin resumen, de modo que la persona empieza de cero	¿Disparador correcto, momento correcto, y tenía la persona el contexto que necesitaba?
Redactor y revisor	Un agente redacta y otro aprueba o devuelve	Un agente redacta una oferta de compensación; un revisor la valida frente a la política	El revisor aprueba un borrador erróneo, o el bucle llega al límite y envía igualmente la última versión	¿Qué hace el revisor cuando alcanza el límite de iteraciones?

Los traspasos entre agentes son los que más riesgo tienen de bucles y de pérdida de contexto, y los traspasos a personas son donde los clientes notan primero el fallo. Nuestra guía sobre la derivación a agente humano profundiza en esa fila.

¿Dónde fallan las conversaciones de soporte con varios agentes?

Las conversaciones de soporte con varios agentes fallan en las uniones entre agentes, no dentro de ellos. Los cuatro fallos que más importan son el contexto perdido en un traspaso, los bucles entre agentes, el agente equivocado actuando sobre una solicitud y una conversación cerrada antes de resolver el problema. Cada uno puede producirse mientras cada agente, por separado, parece correcto.

Contexto perdido. Los traspasos transmiten menos de lo que la mayoría de los equipos supone. En la orquestación por traspaso de Microsoft Agent Framework, los mensajes del usuario y del agente se sincronizan entre agentes, pero el contenido relacionado con las herramientas no se difunde. El siguiente agente ve lo que se dijo, no necesariamente lo que el agente anterior consultó o hizo. Si el agente de Facturación no puede ver el pedido que consultó el agente de Pedidos, vuelve a preguntárselo al cliente o trabaja a partir de una suposición.

Bucles. Dos agentes pueden pasarse una solicitud de uno a otro, o un agente puede repetir el mismo paso. La guía de arquitectura de Microsoft cita los “bucles de traspaso infinitos” como un riesgo del patrón de traspaso y recomienda límites de iteraciones para los bucles. En modo autónomo, su framework de traspaso permite por defecto que cada agente ejecute hasta 50 turnos antes de necesitar una intervención del usuario, mucho más de lo que tolerará cualquier cliente.

El agente equivocado actuando. Una solicitud mal enrutada llega a un agente que responde con seguridad fuera de su ámbito. La respuesta es fluida, así que nadie lo nota a menos que alguien la contraste con la política correcta.

Cerrada demasiado pronto. Los agentes pueden detenerse antes de terminar el trabajo, o no saber siquiera cuándo han terminado.

La investigación lo respalda. Un artículo de 2025, Why Do Multi-Agent LLM Systems Fail? (en inglés), anotó 1.642 trazas de ejecución de siete frameworks y encontró 14 modos de fallo. La repetición de pasos apareció en el 15,7% de las trazas, el no reconocer que la tarea estaba terminada en el 12,4% y la pérdida de contexto en el 2,8%. Los autores también observaron que las ejecuciones con éxito no están libres de fallos. Las trazas procedían de tareas de programación, matemáticas y tareas generales, no de atención al cliente, así que tome los porcentajes como una advertencia, no como una referencia. La lección es trasladable: un resultado “resuelto” puede esconder fallos por el camino, como muestra nuestro artículo sobre fallos silenciosos de los agentes de IA.

¿Qué conviene supervisar en una operación de soporte orquestada?

Supervise el recorrido, no solo cada agente. Las notas por agente muestran si el agente de Facturación responde bien a las preguntas de facturación, no que los clientes rebotaron entre tres agentes antes de llegar a él. Siga en su lugar un conjunto reducido de señales del recorrido: traspasos, bucles, datos que el cliente repite, exactitud del primer enrutamiento, escalamientos con contexto y la diferencia entre la resolución por agente y la del recorrido.

Las reglas iniciales siguientes son nuestras, no un estándar del sector: mida su propia referencia durante cuatro semanas y después ajústelas.

Señal	Cómo medirla	Regla inicial
Traspasos por conversación	Cuente los cambios de agente en el registro de la conversación	Revise cada conversación con más de 3 traspasos
Agente repetido (bucle)	El mismo agente aparece dos veces en una conversación, con otro agente en medio	Revíselas todas; cualquier tendencia al alza es un error de enrutamiento
Tasa de repregunta	El cliente da dos veces el mismo identificador (número de pedido, correo electrónico)	Investigue si supera el 5% de las conversaciones con varios agentes
Exactitud del primer enrutamiento	Proporción de primeros enrutamientos que un revisor marca como correctos	Investigue el enrutador si baja del 90%
Escalamiento con contexto	Proporción de traspasos a personas en los que la persona no tuvo que volver a preguntar	Apunte al 95% o más
Diferencia de resolución	Tasa de “resuelto” por agente menos la tasa de resolución correcta del recorrido	Una diferencia de más de 5 puntos significa que hay fallos escondidos entre agentes
Límite de turnos o de iteraciones alcanzado	Conversaciones que terminaron porque se alcanzó un límite	Revíselas todas; son bucles atascados

Las indicaciones de Microsoft plantean lo mismo desde el lado de la ingeniería: instrumente todas las operaciones y traspasos de los agentes, y use rúbricas de evaluación o un modelo como juez en lugar de pruebas de coincidencia exacta, porque las respuestas de los agentes varían. Para paneles y alertas, consulte nuestra guía de monitorización de agentes de IA.

¿Cómo se hace el QA de un recorrido que pasa por varios agentes y personas?

Para hacer el QA de un recorrido con varios agentes, convierta la conversación completa en la unidad de revisión. Una cada segmento de agente y de persona en un solo registro, evalúe cada segmento según su función, evalúe las uniones con criterios del recorrido y atribuya cada fallo al segmento que lo causó. Después, corrija esa parte y vuelva a evaluar.

Paso 1: una el recorrido. Un mismo identificador de conversación sigue al cliente por cada agente y cada persona. Si sus agentes registran en lugares distintos, la primera tarea de QA es reunir la transcripción completa, con el nombre del agente en cada turno, en el helpdesk o en una única cola de revisión.

Paso 2: evalúe cada segmento según su función. La exactitud de facturación para el agente de Facturación, el enrutamiento para el agente de triaje, la resolución para la persona. Un núcleo común de criterios mantiene comparables los segmentos humanos y de IA; nuestra guía sobre una sola scorecard para agentes humanos y de IA explica cómo crearlo.

Paso 3: añada criterios del recorrido. Son las preguntas que ningún segmento por separado puede responder:

¿Fue correcto el primer enrutamiento?
¿Tuvo el cliente que repetir algún dato?
¿Apareció algún agente dos veces, o entró la conversación en bucle?
¿Transmitió cada traspaso los datos que necesitaba el siguiente agente?
Si una persona tomó el relevo, ¿se produjo el escalamiento con el disparador correcto y con un resumen útil?
¿Se resolvió al final el problema real del cliente, con independencia de quién lo resolviera?

Paso 4: atribuya el fallo. Cada recorrido fallido recibe un segmento causante: el enrutador, un especialista, el mecanismo de traspaso o la persona. Sin atribución, un fallo del recorrido es problema de todos y nadie lo corrige.

Paso 5: corrija y vuelva a evaluar. Envíe el hallazgo al responsable de esa parte (prompt, regla de enrutamiento, artículo de conocimiento, disparador de escalamiento) y vuelva a evaluar el mismo tipo de recorrido para confirmar que la corrección se mantiene. Pruebe los cambios antes de ponerlos en producción; consulte nuestra guía de pruebas de agentes de IA.

Un ejemplo práctico (ilustración, cifras inventadas para mostrar el cálculo)

Un equipo de soporte atiende 40.000 conversaciones al mes con un agente de triaje, tres agentes especialistas y un equipo humano:

26.000 conversaciones (65%) van del triaje a un especialista y terminan ahí.
10.000 (25%) pasan por dos o más agentes de IA.
4.000 (10%) terminan con una persona.

Los paneles por agente parecen sanos: cada especialista supera más del 90% de sus propios criterios. Entonces, el responsable de QA evalúa una muestra aleatoria de 200 recorridos con varios agentes según los criterios del recorrido anteriores. Fallan 34 (17%): 14 clientes repitieron su número de pedido, 9 conversaciones volvieron al triaje en bucle, 6 las respondió el especialista equivocado y 5 se cerraron antes de confirmar el reembolso.

A escala, el 17% de 10.000 son unos 1.700 recorridos fallidos al mes. Si los recorridos con un solo agente fallan en un 5%, son 1.300 fallos de 26.000. La cuarta parte de las conversaciones que pasa por varios agentes produce más fallos que los dos tercios que no lo hacen.

La muestra también muestra los límites del muestreo. Con 200 conversaciones y una tasa de fallo del 17%, el margen de error al 95% es de unos 5,2 puntos arriba o abajo (1,96 × √(0,17 × 0,83 / 200)). El intervalo al 95% va de unos 1.200 a 2.200 recorridos fallidos. Y las 14 repreguntas apuntan a una sola corrección: el resultado de la consulta del agente de Pedidos no llega al agente de Facturación en el traspaso.

Véalo con sus propias conversaciones. Kaizo evalúa el 100% de sus conversaciones de soporte, de agentes humanos y de IA, con su propia scorecard, y enlaza cada nota con las evidencias de la conversación. Reservar una demo.

¿Qué framework o plataforma de orquestación de agentes de IA conviene elegir?

El mejor framework de orquestación de agentes de IA es el que su proveedor de agentes o su equipo de ingeniería ya domina; los responsables de soporte rara vez lo eligen solos. Lo que sí debe fijar son los requisitos: enrutamiento visible por conversación, contexto transmitido en el traspaso, límites de turnos, escalamiento a una persona con resumen y transcripciones que lleguen a donde trabaja su equipo de QA.

Las opciones se dividen en tres grupos:

Integrada en su plataforma de agentes de IA. Las plataformas de agentes para atención al cliente enrutan entre sus propios agentes y hacia su equipo humano. Menos trabajo, menos control.
Frameworks para desarrolladores. Microsoft Agent Framework, el OpenAI Agents SDK, LangChain y CrewAI, entre otros. Control total, y sus ingenieros se hacen cargo de cada regla.
Capas de orquestación enterprise. Productos como IBM watsonx Orchestrate coordinan agentes, herramientas y flujos de trabajo desde una capa central para toda la empresa.

Esté en el grupo que esté, haga cinco preguntas antes de la puesta en marcha:

¿Podemos ver, por conversación, qué agente actuó en cada turno y por qué traspasó?
¿Qué se transmite exactamente en un traspaso: la transcripción, un resumen, los resultados de las herramientas, los datos del cliente?
¿Cuáles son los límites de turnos y de iteraciones, y qué ocurre cuando se alcanza uno?
¿Cómo toma el relevo una persona y qué ve primero?
¿Dónde acaba la transcripción completa y puede nuestro equipo de QA evaluarla allí?

Si la respuesta es “eso no se lo podemos mostrar”, tampoco podrá hacer el QA del recorrido.

¿Cuándo no le conviene la orquestación multiagente?

La orquestación multiagente no le conviene cuando un único agente de IA bien delimitado, con las herramientas adecuadas y una vía de escalamiento clara, puede atender su volumen. Las indicaciones de Microsoft recomiendan usar el menor nivel de complejidad que cumpla de forma fiable sus requisitos, y consideran que un solo agente con herramientas suele ser la opción por defecto adecuada en los casos de uso empresariales. Cada agente adicional añade traspasos, latencia, coste y modos de fallo.

Los profesionales de los foros de customer success plantean algo parecido: los buenos resultados suelen venir de un agente de IA que atiende bien un conjunto reducido de preguntas, no de uno que intenta abarcarlo todo. Si su agente de IA atiende unos cientos de conversaciones al mes en un solo ámbito, prescinda de la orquestación, lea las transcripciones cada semana y dedique el esfuerzo a la base de conocimiento y al disparador de escalamiento.

El enrutamiento en sí lo aporta su plataforma de agentes o uno de los frameworks anteriores. El papel de Kaizo empieza después de la conversación: evalúa las conversaciones resueltas de Zendesk o Salesforce con su scorecard.

Cómo empezar esta semana

Puede empezar a revisar recorridos orquestados esta semana sin herramientas nuevas: dibuje cómo están conectados sus agentes y evalúe un pequeño conjunto de recorridos con varios agentes según los criterios del recorrido. El objetivo de la primera semana no es un panel; es encontrar la unión que más falla.

Dibuje sus conexiones. Enumere cada agente de IA, quién puede traspasar a quién y dónde intervienen las personas, con el patrón de la tabla anterior.
Saque 30 recorridos con varios agentes, más 10 que terminaron con una persona.
Evalúelos con los seis criterios del recorrido, anotando el segmento causante de cada fallo.
Elija la peor unión. Normalmente es un traspaso que pierde contexto o una regla de enrutamiento que falla.
Nombre un responsable para cada agente y cada regla de traspaso.

Cuando la revisión manual confirme el patrón, automatícela. El QA de agentes de IA de Kaizo evalúa las conversaciones de los agentes de IA con la misma scorecard que las de su equipo, incluidos criterios de traspaso como si el agente escaló con el disparador correcto y transmitió el contexto, y AutoPilot evalúa cada conversación en cuanto se resuelve. Para la visión de conjunto, empiece por nuestra guía de atención al cliente agéntica; para las reglas que siguen esos agentes, consulte la gobernanza de agentes de IA.

Preguntas frecuentes

¿ChatGPT es un agente o un LLM?

ChatGPT es un producto construido sobre grandes modelos de lenguaje (LLM). Cuando responde a una sola pregunta, se comporta como una interfaz de chat para un LLM. Cuando usa herramientas, navega por internet o trabaja por su cuenta en una tarea de varios pasos, se comporta como un agente. La diferencia está en lo que puede hacer el sistema, no en el modelo.

¿Qué diferencia hay entre un sistema multiagente y la IA agéntica?

La IA agéntica describe una IA que actúa hacia un objetivo con cierta autonomía. Un sistema multiagente es una forma de construirla: varios agentes especializados, coordinados mediante orquestación, en lugar de un solo agente que lo hace todo. Un solo agente puede ser agéntico; un sistema multiagente añade los traspasos y, con ellos, las uniones que hay que comprobar.

¿Es Kubernetes una herramienta de orquestación?

Sí, pero de contenedores, no de agentes de IA. Kubernetes programa y escala el software que ejecuta sus servicios. La orquestación de agentes de IA decide qué agente atiende cada parte de una conversación y qué contexto recibe. Un sistema de agentes puede funcionar sobre Kubernetes, pero Kubernetes no enruta solicitudes entre agentes.

¿Qué es una capa de orquestación de agentes de IA?

La capa de orquestación está por encima de los agentes individuales y decide el enrutamiento, la transmisión del contexto, los permisos y las reglas de parada. Puede ser un agente principal, un framework en su propio código o un producto central. Para el QA, también debería aportar el registro de quién actuó y por qué.

¿Cómo se evalúa un sistema de atención al cliente con varios agentes?

Evalúelo en dos niveles: cada agente según su propia función y el recorrido completo según criterios como un primer enrutamiento correcto, ningún dato repetido, ningún bucle y un resultado final correcto. Nuestra guía de evaluación de agentes de IA trata los métodos, desde los conjuntos de pruebas hasta la evaluación de conversaciones reales.