Prácticas recomendadas de orquestación de agentes de IA: gestión de fallos, aprobaciones y reintentos

Tener varios agentes trabajando en el mismo proyecto parece extremadamente eficiente. Uno planifica el trabajo, otro se encarga del diseño y un tercero escribe el código. Funciona hasta que deja de hacerlo. Y los fallos ocurren con más frecuencia de lo que te gustaría.

Evitar estos fallos requiere una ingeniería de flujos de trabajo cuidadosa. Así que analicemos qué hace que los flujos de trabajo orquestados sean poco fiables y exploremos las prácticas recomendadas de orquestación para lograr fiabilidad en producción.

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

La orquestación de agentes de IA coordina varios agentes, modelos y herramientas de IA para completar una tarea de varios pasos. Pero alguien —o algo— sigue teniendo que decidir qué agente se ejecuta primero, qué información recibe y qué ocurre cuando termina. Esta es la función del orquestador: un agente de IA que actúa como gestor o una capa de ejecución controlada por software.

En pocas palabras, una capa de orquestación divide un objetivo en tareas más pequeñas, hace un seguimiento de las dependencias, delega la ejecución en los agentes adecuados, gestiona el contexto compartido y reúne los resultados.

Cómo funciona la orquestación de agentes de IA: dentro del motor de ejecución

Ampliar

Veamos qué ocurre después de asignar una tarea a un orquestador.

Veamos un ejemplo del taller de Computer de Perplexity: crear un panel de inteligencia de cuentas con información de Salesforce, Snowflake, el correo electrónico, el calendario y noticias recientes.

1. Comprender el objetivo y planificar el trabajo. El orquestador parte del resultado solicitado y lo descompone en tareas con dependencias explícitas. En nuestro ejemplo del panel, esto implica recopilar información de distintas fuentes y convertirla en un entregable terminado. El planificador establece qué pasos dependen de otros y cuáles pueden ejecutarse de forma independiente.
2. Enrutar las tareas a los agentes adecuados. El orquestador identifica las tareas cuyas dependencias se han satisfecho y delega el trabajo en agentes o modelos especializados. Las tareas dependientes esperan a sus requisitos previos. Perplexity Computer utiliza varios modelos de frontera y enruta distintas partes del flujo de trabajo a los sistemas más adecuados para esas tareas. Esto también permite que el trabajo independiente se ejecute en paralelo.
3. Ejecutar llamadas a herramientas en entornos controlados. Los agentes interactúan con su entorno mediante herramientas, como la búsqueda web, las API, las aplicaciones conectadas, las operaciones con archivos o la ejecución de código. La capa de ejecución realiza estas acciones y devuelve los resultados a los agentes.
4. Pasar resultados y contexto entre agentes. Cuando un agente termina su tarea, el siguiente agente de la cadena necesita el resultado pertinente para continuar. Un registro de traspaso podría contener un ID de tarea, una referencia al resultado, una versión del esquema y metadatos de origen. El orquestador coordina estos traspasos y mantiene el contexto necesario para los pasos posteriores. Es importante destacar que los agentes no tienen que cargar con todo el historial del trabajo de los demás agentes en sus propias ventanas de contexto.
5. Registrar el estado de ejecución por separado del contexto de los agentes. A medida que los agentes inician, completan o no consiguen completar tareas, el motor de ejecución actualiza un registro persistente del flujo de trabajo con los estados de las tareas, los intentos de ejecución, las referencias a los resultados y el trabajo pendiente. Este registro permite al orquestador seguir el progreso y reanudar tras interrupciones sin depender de un LLM para reconstruir el flujo de trabajo a partir del historial de la conversación.
6. Validar los resultados y decidir qué ocurre a continuación. Cuando una tarea devuelve un resultado, la capa de orquestación comprueba si cumple el contrato esperado y si se cumplen las dependencias de la siguiente tarea. Si se detecta un problema, el flujo de trabajo puede volver a un paso anterior para corregirlo o pausarse. De lo contrario, avanza hacia su finalización.

Detrás de lo que parece una simple orquestación de agentes de IA hay muchas piezas en movimiento. La forma en que organices la coordinación de los agentes determina cuánto control tienes sobre la ejecución. Y, por supuesto, toda esa coordinación añade sobrecarga. Así que no siempre merece la pena.

¿Cuándo conviene usar la orquestación de agentes de IA?

Plantéate la orquestación multiagente cuando distintas partes de la tarea requieran conocimientos especializados diferentes, el trabajo independiente pueda ejecutarse en paralelo o no puedas determinar el siguiente paso de antemano.

Por tanto, la orquestación resulta útil en tres escenarios:

• Las tareas requieren distintas especializaciones. Un proyecto de programación, por ejemplo, podría beneficiarse de agentes independientes de planificación, diseño, desarrollo y revisión.
• Las tareas independientes pueden ejecutarse en paralelo. En lugar de que un solo agente lo complete todo de forma secuencial, varios agentes pueden trabajar simultáneamente y devolver sus resultados a un orquestador.
• El problema es abierto. Es posible que los agentes necesiten explorar distintos enfoques, tomar decisiones y colaborar en lugar de seguir una secuencia predefinida.

Fuera de estos casos, la orquestación no es más que una tendencia costosa. Más agentes también implican más coordinación y, potencialmente, mayores costes de tokens.

«Normalmente empiezo por la opción más sencilla y voy construyendo a partir de ahí. Si conocemos los pasos y son repetibles, probablemente se trate de un flujo de trabajo. Solo veo motivos para introducir varios agentes cuando tienen responsabilidades, permisos o usuarios distintos», afirma Josh Spilker, responsable de marketing de búsqueda en AirOps.

Incluso entonces, sopesa los beneficios frente a las llamadas adicionales a modelos, los traspasos, la latencia y los puntos de fallo.

Arquitecturas de orquestación de agentes de IA y sus ventajas e inconvenientes

Hay tres formas habituales de estructurar la coordinación de agentes: la orquestación centralizada, la descentralizada y la jerárquica. Elegir la arquitectura adecuada se reduce a una pregunta: ¿quién controla el trabajo y cómo se coordinan los agentes entre sí?

Orquestación centralizada

En la orquestación centralizada, un único orquestador gestiona el proceso. Divide la tarea, delega el trabajo en agentes especializados, hace un seguimiento de su progreso y reúne sus resultados.

Ampliar

La contrapartida: La coordinación centralizada facilita el seguimiento de la ejecución y la aplicación de reglas comunes en un único punto de control. Sin embargo, el orquestador puede convertirse en un cuello de botella y su fallo puede interrumpir todo el flujo de trabajo, a menos que el sistema admita la recuperación.

Orquestación descentralizada

En la orquestación descentralizada, los agentes se coordinan de forma más directa en lugar de depender de un único gestor que tome todas las decisiones. Pueden intercambiar mensajes, leer el estado compartido y determinar de forma independiente sus siguientes pasos.

Ampliar

La contrapartida: Los agentes pueden operar sin esperar a un planificador central, lo que hace que este enfoque sea útil para el trabajo exploratorio y las contribuciones independientes. Pero la coordinación se complica cuando los agentes discrepan, actualizan información compartida o necesitan llegar a un resultado coherente.

Orquestación jerárquica

La orquestación jerárquica extiende el enfoque del gestor a varios niveles. Un orquestador de nivel superior delega responsabilidades en orquestadores subordinados, que coordinan sus propios grupos de agentes especializados.

Piensa en un flujo de trabajo empresarial en el que participan los equipos de ventas, finanzas y asuntos legales. Un orquestador de nivel superior podría delegar cada línea de trabajo en un coordinador específico del área. Esos coordinadores gestionarían después sus propios agentes especializados e informarían de los resultados consolidados.

Esta estructura puede resultar útil cuando los flujos de trabajo son demasiado amplios para que un único orquestador los gestione de forma eficaz.

Ampliar

La contrapartida: Las jerarquías permiten a los equipos repartir las responsabilidades de coordinación y, potencialmente, gestionar los fallos dentro de ramas individuales. Sin embargo, introducen traspasos adicionales, una gestión del estado más compleja y una mayor sobrecarga operativa. La recuperación local también depende de cómo se implementen los puntos de control y el estado de ejecución.

Comparativa de estas arquitecturas:

Ejecución secuencial, en paralelo y basada en traspasos

Hay una distinción más que vale la pena entender. La arquitectura determina quién coordina a los agentes. El patrón de ejecución determina cómo avanzan sus tareas.

Estos son tres patrones de ejecución:

• Flujos de trabajo secuenciales: Los agentes trabajan en un orden predefinido, y el resultado de un agente se convierte en la entrada de otro.
• Ejecución en paralelo: Agentes independientes trabajan simultáneamente.
• Ejecución basada en traspasos: El control pasa de un agente especializado a otro a medida que avanza la tarea. Esto resulta útil cuando otro agente está mejor preparado para gestionar el siguiente paso, aunque cada traspaso debe conservar la información necesaria para continuar.

Los patrones no son mutuamente excluyentes ni se corresponden uno a uno con las arquitecturas de orquestación. El objetivo es elegir la estructura más sencilla que admita las dependencias de tu flujo de trabajo, sus requisitos de coordinación y una sobrecarga operativa aceptable.

Fallos comunes en la orquestación de agentes de IA

En la orquestación puede fallar cualquier cosa, desde simples descuidos hasta bloqueos complejos. A veces, un agente incluso puede parecer que hace bien su trabajo mientras el flujo de trabajo en su conjunto falla. A partir de la experiencia de profesionales del sector, hemos recopilado algunos de los errores más comunes que hay detrás de los flujos de trabajo orquestados poco fiables. Tenlos presentes:

• Traspasos entre agentes con pérdida de información. Un orquestador pasa un plan resumido a un agente especializado, pero el resumen omite restricciones, dependencias o detalles de implementación.
• Ejecución prematura de la convergencia (fan-in). Un agente posterior empieza a agregar resultados antes de que hayan terminado todas las tareas previas.
• Actualizaciones no deterministas del estado compartido. Varios agentes en paralelo escriben en las mismas claves de estado sin una semántica de fusión bien definida. Según cómo gestione el framework las actualizaciones, esto puede provocar escrituras perdidas, datos duplicados, resultados que dependen del orden o cambios en conflicto.
• Divergencia entre puntos de control y efectos secundarios. Una tarea realiza una operación externa, pero su ejecución correcta no se registra de forma duradera antes de que falle el worker. Durante la recuperación, el orquestador ve una tarea sin terminar y vuelve a ejecutarla.
• Condiciones de carrera al reanudar tras la aprobación humana. Pausar y reanudar la ejecución introduce sus propios problemas de sincronización.
• Bucles de delegación y amplificación de reintentos. Los agentes se pasan el trabajo repetidamente unos a otros porque sus responsabilidades se solapan, las dependencias son circulares o las condiciones de finalización son ambiguas.
• Controles a nivel de instrucciones confundidos con seguridad de ejecución. Un orquestador puede indicar a los agentes que no accedan a determinados recursos o que no realicen acciones sensibles, pero las instrucciones del modelo no imponen permisos del sistema operativo, restricciones de red ni límites de autorización. La investigación sobre ingeniería de seguridad de Perplexity pone de relieve por qué los agentes pueden traspasar límites de seguridad mientras persiguen objetivos legítimos, incluso sin instrucciones maliciosas

Fíjate en lo diferentes que son estos fallos. Tanto una transición prematura del planificador como una escritura externa ambigua pueden producir un resultado incorrecto, pero se originan en distintas partes del ciclo de vida de la ejecución. Por eso, una orquestación fiable requiere algo más que mejorar los prompts o añadir reintentos.

7 prácticas recomendadas de orquestación de agentes de IA para la fiabilidad en producción

1. Define contratos de tareas explícitos, criterios de aceptación y condiciones de parada

Los objetivos vagos y una definición de terminado poco clara suelen dar lugar a resultados decepcionantes generados por agentes. La solución es un contrato de prompt (el alcance del trabajo de un agente): acordar el objetivo, las restricciones, el formato de salida y las condiciones de fallo antes de que empiece la ejecución.

Por ejemplo, así es como podrías definir un contrato para un agente encargado de corregir una prueba de integración que falla de forma intermitente:

• Objetivo: Identificar y corregir la causa de una prueba de integración inestable de la API de pago.
• Entradas: Código fuente de las pruebas, registros de fallos de CI, commits recientes y código de la aplicación relevante.
• Restricciones: No desactivar pruebas, relajar aserciones ni modificar comportamientos de la aplicación no relacionados.
• Resultado esperado: Un parche de código, una explicación de la causa raíz y los resultados de la ejecución de las pruebas.
• Criterios de aceptación: La prueba que antes fallaba se supera en 10 ejecuciones consecutivas, y el conjunto de pruebas de regresión correspondiente también se supera.
• Condiciones de fallo: No se puede determinar la causa raíz, la corrección introduce regresiones o el entorno de pruebas necesario no está disponible.

Pero hay otra parte importante: ¿cuándo debe detenerse el agente?

Un agente no debería seguir iterando indefinidamente porque no haya producido un resultado satisfactorio. Define qué constituye una finalización correcta, cuándo devolver una tarea parcialmente completada y cuándo detenerse porque no se puede cumplir un requisito. Establece una profundidad máxima de delegación y límites de iteraciones o presupuestos de ejecución para que las tareas sin resolver no se conviertan en bucles infinitos.

Volvamos a nuestro ejemplo de CI. Podrías definir las siguientes condiciones de parada:

• Éxito: La corrección supera 10 ejecuciones consecutivas de las pruebas y el conjunto de pruebas de regresión correspondiente.
• Límite de iteraciones: El agente no puede intentar más de dos correcciones candidatas.
• Presupuesto de ejecución: El agente debe detenerse al cabo de 60 minutos, aunque el problema siga sin resolverse.
• Límite de delegación: El agente puede delegar trabajo en un agente especializado, sin más delegación en subagentes.
• Finalización parcial: Si ambos intentos fallan o se agota el tiempo límite, el agente devuelve sus conclusiones, los cambios que ha intentado y los resultados de las pruebas.
• Ejecución bloqueada: Si el entorno de pruebas no está disponible, el agente se detiene e informa del bloqueo en lugar de afirmar que ha tenido éxito.

2. Mantén orquestadores ligeros y exige traspasos estructurados

A veces, los desarrolladores asignan demasiadas responsabilidades a un orquestador y, en lugar de coordinar agentes especializados, este empieza a escribir código, depurar o realizar revisiones detalladas por sí mismo. Esto crea un cuello de botella: el orquestador gasta su presupuesto de contexto en detalles de implementación, retrasa la delegación y difumina la responsabilidad sobre los resultados.

Así que deja que los orquestadores hagan su trabajo y exige traspasos que hagan referencia a artefactos concretos: la tarea original, las entradas relevantes, los artefactos de salida, el estado de ejecución y cualquier problema sin resolver.

Considera este ejemplo: status: completed se refiere al trabajo asignado al agente, no a todo el flujo de trabajo. Como las pruebas siguen en estado pending, el orquestador no debería aprobar el resultado final.

3. Conserva el estado del flujo de trabajo y controla el crecimiento del contexto

El historial de conversación de un agente no es un registro fiable del progreso del flujo de trabajo. Cuando su ventana de contexto se llena, la compactación automática puede eliminar detalles importantes. Y si un worker se bloquea, el siguiente agente necesita saber qué pasos se completaron realmente.

Por ejemplo, si el agente de programación genera un parche y luego se bloquea, el siguiente worker debería recuperar el artefacto guardado y continuar desde el estado registrado del flujo de trabajo. Pero si el agente también activó una ejecución externa de CI, el orquestador debe conciliar esa ejecución por separado antes de repetir la acción

Así que mantén el estado de ejecución separado del contexto de trabajo del agente. Guarda los estados de las tareas, los intentos de ejecución, los pasos completados y las referencias a artefactos en un almacenamiento duradero. Además, carga solo las instrucciones, entradas y resultados relevantes para la tarea actual del agente, en lugar de meter todo el historial de ejecución en su ventana de contexto.

4. Diseña reintentos conscientes de los fallos y una ejecución de herramientas recuperable

Supón que tu agente de CI activa una ejecución de pruebas, pero se agota el tiempo de espera de la solicitud a la API. ¿La ejecución de pruebas no llegó a iniciarse, o el servicio de CI la puso en cola y se perdió la respuesta?

Que se agote el tiempo de espera no significa necesariamente que una operación haya fallado. Por eso tienes que distinguir entre errores antes de decidir qué ocurre a continuación:

• Errores transitorios (429, 503): Reintenta con un backoff exponencial acotado y jitter, respetando Retry-After cuando se proporcione.
• Errores de validación o de permisos (400, 403): Detente o corrige el problema subyacente en lugar de repetir la misma solicitud.
• Resultados ambiguos (tiempo de espera agotado tras una posible escritura): Comprueba si la operación se completó correctamente antes de volver a intentarla.

Nota: Incluso los errores reintentables necesitan límites. Establece un tiempo de espera para cada llamada a herramientas, limita los intentos y el tiempo total de reintento, y aplica un plazo general para el flujo de trabajo para que los agentes anidados no puedan seguir reiniciando la misma operación. Si una dependencia falla repetidamente, usa un disyuntor (circuit breaker) para detener temporalmente las solicitudes.

En las operaciones con efectos secundarios externos, asigna una clave de idempotencia estable a cada acción lógica y reutilízala en todos los reintentos. Si la API admite la deduplicación en el servidor, puede reconocer las solicitudes repetidas sin realizar la acción dos veces. Si no la admite, consulta el sistema externo mediante un ID de correlación u otra referencia fidedigna.

Cuando no puedas determinar qué ha pasado, detente y escala el problema.

Un ejemplo de la lógica de reintentos de nuestro agente de CI, expresada en pseudocódigo:

Nota sobre el código: El ejemplo supone que la API de CI permite buscar ejecuciones por ID de solicitud. El request_id solo evita duplicados si el proveedor garantiza explícitamente la idempotencia. bounded_retry() es pseudocódigo ilustrativo. En producción, los reintentos deben estar limitados tanto por un presupuesto de reintentos por operación (número máximo de intentos o tiempo transcurrido) como por el plazo general del flujo de trabajo.

Para flujos de trabajo más largos que abarcan varios servicios, considera el patrón Saga para coordinar acciones compensatorias cuando fallen pasos posteriores. Eso sí, recuerda que la compensación no siempre equivale a una reversión completa. Puedes revertir una actualización de una base de datos, pero no puedes deshacer el envío de un correo electrónico.

5. Enruta y paraleliza el trabajo con presupuestos de recursos explícitos

Aquí hay que equilibrar dos cosas: cuánta capacidad del modelo necesita cada tarea y cuántas tareas puedes ejecutar simultáneamente. Si te equivocas en cualquiera de las dos, corres el riesgo de que los agentes compitan por cuotas de API compartidas o de depender únicamente de costosos modelos de razonamiento.

En cuanto a la selección de modelos, ajusta la capacidad del modelo y el esfuerzo de razonamiento a la complejidad de la tarea: algo sencillo, pero que se pasa bastante por alto. Ten en cuenta que puedes configurar reglas de enrutamiento y evaluar los modelos tú mismo, o bien usar una plataforma de orquestación que se encargue de la selección de modelos por ti.

Por ejemplo, el modo de esfuerzo (Effort Mode) de Perplexity Computer te permite elegir cuánto esfuerzo merece una tarea sin tener que seleccionar un modelo manualmente. Elige Light, Standard, High o Ultra, y Perplexity selecciona automáticamente el modelo orquestador y su nivel de razonamiento. A continuación, ese orquestador delega subtareas en agentes de apoyo, que pueden usar modelos de distintos proveedores.

Perplexity evalúa las configuraciones de los modelos en función de la calidad y el coste, y da prioridad a las opciones menos costosas que ofrecen resultados comparables. También puedes usar los controles personalizados (Custom) si prefieres elegir tú mismo el modelo y el nivel de razonamiento.

En cuanto al paralelismo, el límite debe venir determinado por tu infraestructura y tus dependencias externas. Valida los límites de frecuencia de solicitudes y de tokens de las API compartidas y, después, somete tu flujo de trabajo a pruebas de carga con una concurrencia creciente. Observa si mejora el rendimiento o si las solicitudes empiezan a ponerse en cola, a ralentizarse o a devolver errores 429.

Para que el consumo de recursos sea predecible, aplica límites de recursos y controles de programación:

• Controla la concurrencia y la frecuencia de solicitudes: Limita las llamadas en curso por servicio y pon en cola el trabajo excedente. Recuerda que un límite de concurrencia por sí solo no impone límites de solicitudes por minuto ni de tokens por minuto.
• Haz un seguimiento de los presupuestos de tokens y costes: Contabiliza el uso en todo el flujo de trabajo, incluidos los subagentes, y deja de lanzar trabajo nuevo cuando el presupuesto restante sea insuficiente.
• Aplica plazos de ejecución: Establece límites de tiempo para las tareas y el flujo de trabajo, y propaga la cancelación a los agentes en ejecución cuando sea posible.
• Respeta las dependencias: Inicia las tareas posteriores solo cuando sus entradas necesarias estén disponibles, en lugar de lanzar todos los agentes a la vez.

6. Exige aprobaciones y aísla la ejecución de los agentes

Nunca le pidas al modelo que decida si sus propias acciones son seguras. En su lugar, concede a los agentes permisos de mínimo privilegio y aplica reglas de aprobación basadas en el riesgo en el código de la aplicación. Si los agentes ejecutan código, aísla esa ejecución de tu entorno host y restringe el acceso a archivos, redes y credenciales. Esto limita los daños si el agente comete un error o ejecuta código no seguro.

«Soy escéptico con los sistemas multiagente demasiado complicados, sobre todo cuando los agentes revisan y aprueban el trabajo de los demás. Puedes acabar con varios agentes que se pasan con total seguridad el mismo error sin que nadie llegue a detectarlo», advierte Spilker.

Ampliar

Para las acciones que requieren aprobación humana, pausa la ejecución y guarda la operación propuesta exacta:

• sus parámetros
• su recurso de destino
• su commit o versión del estado
• la decisión del revisor

Además, define qué ocurre si la aprobación se rechaza, caduca o necesita escalarse. Esto es esencial en los frameworks reanudables, ya que reanudar un nodo interrumpido vuelve a ejecutar el código desde el principio de ese nodo. Cualquier efecto secundario anterior a la interrupción puede volver a producirse.

Así que, si la aprobación se rechaza o caduca, la solicitud se cierra. Si el commit de destino, los parámetros o los permisos cambian antes de la ejecución, invalida la aprobación y solicita una nueva.

Spilker tampoco respalda la idea de que el objetivo sean agentes de extremo a extremo totalmente autónomos. «Para mí, el mejor enfoque es crear unos pocos agentes específicos con responsabilidades claras, permisos definidos y revisión humana en los puntos adecuados. Sigues ganando eficiencia sin renunciar al control total», concluye.

7. Verifica los resultados de forma independiente y prueba el comportamiento de recuperación

¿Alguna vez un agente te ha informado de un éxito cuando en realidad había fallado? Resulta molesto, por no decir exasperante, y la solución no es rápida, porque el mensaje final del agente no te dirá necesariamente dónde se torcieron las cosas.

Para investigarlo, rastrea lo que ocurrió durante la ejecución y verifica los resultados de forma independiente. Así que dediquemos algo de tiempo a aislar y resolver el problema.

Rastrea el flujo de trabajo para identificar qué falló

Antes de depurar los prompts de un agente, captura toda la ruta de ejecución. Necesitas una traza que conecte las invocaciones de agentes, las llamadas a herramientas, los errores y los reintentos dentro de la misma ejecución del flujo de trabajo.

Las convenciones semánticas de GenAI de OpenTelemetry proporcionan una forma estandarizada de describir estas operaciones. Por ejemplo, invoke_workflow identifica la ejecución de un flujo de trabajo, invoke_agent una invocación de agente y execute_tool una llamada a una herramienta. Cada operación puede registrarse como un span con su duración, su estado y los metadatos relevantes.

Este paso te proporciona una traza de la ruta de ejecución para que puedas identificar dónde se ha atascado un agente.

Una traza de ejecución ilustrativa.

Revisa el resultado de forma independiente

Usa comprobaciones programáticas siempre que sea posible. Valida los resultados con esquemas JSON, ejecuta pruebas unitarias y de integración, comprueba que existan los artefactos necesarios y consulta los sistemas externos para confirmar que las acciones se completaron realmente.

Para los resultados que requieren un juicio subjetivo —y que, por tanto, no pueden evaluarse mediante comprobaciones programáticas—, introduce un agente revisor independiente. Un enfoque posible es un bucle implementador–revisor–resolutor, en el que un agente produce un artefacto, un revisor con un contexto nuevo identifica problemas y un resolutor los soluciona antes de que vuelva a ejecutarse la validación.

Aun así, debes validar las conclusiones del revisor siempre que sea posible y, si utilizas evaluadores basados en LLM para evaluaciones repetidas, calibra sus juicios con ejemplos revisados por personas.

Inyecta fallos para probar la recuperación

Hasta ahora, has rastreado lo que ejecutaron los agentes y has comprobado si sus resultados eran correctos. Pero ¿qué ocurre cuando un worker falla a mitad de una tarea o una API agota el tiempo de espera después de aceptar una solicitud? Sorprendentemente, tu flujo de trabajo puede comportarse perfectamente en condiciones normales, pero fallar durante la recuperación.

Para comprobarlo, inyecta fallos deliberadamente en un entorno de pruebas:

• Simula tiempos de espera agotados de la API
• Provoca caídas de los workers entre las escrituras externas y los puntos de control
• Devuelve salidas de herramientas con formato incorrecto
• Haz que caduquen las aprobaciones

Después de cada prueba, inspecciona la traza de ejecución para ver qué pasos se ejecutaron, dónde se reanudó el flujo de trabajo y si alguna acción se repitió u omitió. A continuación, revisa los resultados reales.

Supón que tu agente de CI envía una solicitud para iniciar una ejecución de pruebas, pero la respuesta de la API agota el tiempo de espera. El agente lo reintenta, recibe una respuesta correcta e informa de Success. Todo parece correcto hasta que compruebas el servicio de CI y descubres que se han creado dos ejecuciones de pruebas en lugar de una.

Por eso debes verificar tanto el estado registrado del flujo de trabajo como los cambios reales en los sistemas externos. Una prueba de recuperación solo debe superarse cuando el flujo de trabajo alcanza el estado esperado sin efectos secundarios no deseados.

Añade los fallos que descubras a tus pruebas de regresión para que los cambios futuros no vuelvan a introducirlos.

En definitiva, el éxito significa que el flujo de trabajo ha superado las comprobaciones obligatorias y que se han verificado sus resultados externos.

Preguntas frecuentes sobre la orquestación de agentes de IA

¿Por qué fallan los agentes de IA aislados a escala empresarial?

Los agentes aislados pueden completar correctamente sus tareas individuales, pero producir resultados incoherentes en conjunto. Imagina un agente de ventas que recupera las condiciones de un cliente a las 10:00, un agente de precios que calcula un presupuesto con precios actualizados a las 10:05 y un agente jurídico que revisa un contrato que cambió a las 10:07. Cada agente trabaja con una instantánea distinta del negocio, por lo que sus resultados pueden contradecirse entre sí.

El problema se acentúa a escala empresarial porque los agentes interactúan con varios sistemas que se actualizan de forma independiente, funcionan con permisos diferentes y no comparten necesariamente el contexto ni el estado de ejecución.

¿Cómo se evitan los bucles de reintentos infinitos en los agentes de IA?

Establece límites en varios niveles: número máximo de reintentos de llamadas a herramientas, número máximo de iteraciones del agente, profundidad de delegación y un plazo límite global para el flujo de trabajo. Clasifica los fallos antes de reintentar. En las respuestas 429 transitorias, respeta Retry-After cuando se proporcione. De lo contrario, usa un retroceso exponencial acotado con jitter.

Deja de reintentar solicitudes sin cambios tras errores de validación o de permisos. Si un servicio descendente falla repetidamente, un disyuntor (circuit breaker) puede evitar que los agentes generen carga adicional.

¿Cómo se reanuda un flujo de trabajo de agentes de IA después de una caída?

El mecanismo de recuperación depende de tu entorno de ejecución. Con LangGraph, un checkpointer persistente como PostgresSaver almacena el estado del grafo bajo un thread_id, lo que permite continuar la ejecución a partir del estado persistido. Con Temporal, otro worker puede reconstruir un flujo de trabajo reproduciendo su historial de eventos. Durante la reproducción, reutiliza los resultados de actividades registrados previamente.

Si la aplicación se vuelve a desplegar mientras los flujos de trabajo siguen en ejecución, es posible que el estado guardado y los historiales de ejecución dejen de ser compatibles. Temporal resuelve este problema mediante Worker Versioning y la aplicación de parches a los flujos de trabajo. En los sistemas basados en puntos de control, planifica las migraciones de esquema y prueba la recuperación con los estados guardados existentes antes de implantar cambios incompatibles.

¿Cómo se prueba la fiabilidad de la orquestación de agentes de IA?

Ejecuta las mismas tareas representativas varias veces y distingue entre pass@k (si al menos uno de los k intentos tiene éxito) y pass^k (si todos los k intentos tienen éxito)

Mide los resultados por categoría de tarea y versión del flujo de trabajo en lugar de depender de una única tasa de éxito agregada. Haz un seguimiento del éxito en el primer intento, la coherencia entre ejecuciones repetidas, la latencia p95, el coste por tarea completada y la proporción de tareas que requieren intervención humana. Indica los tamaños de muestra y los intervalos de incertidumbre de las tasas de éxito.