Prácticas recomendadas de orquestación de agentes de IA: cómo manejar fallas, aprobaciones y reintentos

Tener varios agentes trabajando en el mismo proyecto suena sumamente eficiente. Uno planifica el trabajo, otro se encarga del diseño y un tercero escribe el código. Funciona hasta que deja de funcionar. Y las fallas ocurren con más frecuencia de lo que quisieras.

Evitar estas fallas requiere una ingeniería cuidadosa de los flujos de trabajo. Así que analicemos qué hace que los flujos de trabajo orquestados sean poco confiables y exploremos las mejores prácticas de orquestación para lograr confiabilidad en producción.

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

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

En términos simples, una capa de orquestación divide un objetivo en tareas más pequeñas, rastrea las dependencias, delega la ejecución a los agentes adecuados, administra el contexto compartido y consolida los resultados.

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

Ampliar

Veamos qué sucede después de asignarle una tarea a un orquestador.

Considera un ejemplo del taller de Computer de Perplexity: crear un panel de inteligencia de cuentas con información de Salesforce, Snowflake, correo electrónico, 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 determina 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 ya se cumplieron y delega el trabajo a agentes o modelos especializados. Las tareas dependientes esperan a que se completen sus requisitos previos. Perplexity Computer usa múltiples 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 en la cadena necesita el resultado relevante 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. Lo importante es que los agentes no tienen que cargar 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 fallan en sus 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 que el orquestador haga seguimiento del progreso y se reanude después de 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é sigue. Cuando una tarea devuelve un resultado, la capa de orquestación verifica si este cumple el contrato esperado y si se cumplen las dependencias de la siguiente tarea. Si se detecta un problema, el flujo de trabajo puede regresar a un paso anterior para corregirlo o pausarse. De lo contrario, avanza hacia su finalización.

Detrás de lo que parece una orquestación sencilla de agentes de IA hay muchas piezas en movimiento. La forma en que organizas la coordinación de los agentes determina cuánto control tienes sobre la ejecución. Y, por supuesto, toda esa coordinación agrega sobrecarga. Por eso, no siempre vale la pena.

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

Considera 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 lo tanto, la orquestación es útil en tres escenarios:

• Las tareas requieren distintas especializaciones. Un proyecto de programación, por ejemplo, podría beneficiarse de agentes separados de planificación, diseño, desarrollo y revisión.
• Las tareas independientes pueden ejecutarse en paralelo. En lugar de que un solo agente 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 eso, la orquestación es solo una tendencia costosa. Más agentes también implican más coordinación y, potencialmente, mayores costos de tokens.

“Normalmente empiezo con la opción más sencilla y construyo a partir de ahí. Si conocemos los pasos y son repetibles, probablemente se trate de un flujo de trabajo. Solo veo motivo para introducir varios agentes cuando tienen responsabilidades, permisos o usuarios diferentes”, dice Josh Spilker, director de marketing de búsqueda en AirOps.

Aun así, sopesa los beneficios frente a las llamadas adicionales al modelo, los traspasos, la latencia y los puntos de falla.

Arquitecturas de orquestación de agentes de IA y sus ventajas y desventajas

Hay tres formas comunes de estructurar la coordinación de agentes: orquestación centralizada, descentralizada y 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 solo orquestador gestiona el proceso. Divide la tarea, delega el trabajo a agentes especializados, hace seguimiento de su progreso y consolida sus resultados.

Ampliar

Ventajas y desventajas: La coordinación centralizada facilita el seguimiento de la ejecución y la aplicación de reglas comunes desde un único punto de control. Sin embargo, el orquestador puede convertirse en un cuello de botella y su falla 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 administrador que tome todas las decisiones. Pueden intercambiar mensajes, leer el estado compartido y determinar sus siguientes pasos de forma independiente.

Ampliar

Ventajas y desventajas: 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 no están de acuerdo, actualizan información compartida o necesitan llegar a un resultado coherente.

Orquestación jerárquica

La orquestación jerárquica extiende el enfoque del administrador 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 legal. Un orquestador de nivel superior podría delegar cada línea de trabajo a un coordinador específico del dominio. Luego, esos coordinadores gestionarían sus propios agentes especializados e informarían resultados consolidados.

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

Ampliar

Ventajas y desventajas: Las jerarquías permiten a los equipos dividir las responsabilidades de coordinación y, potencialmente, manejar las fallas 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.

Cómo se comparan 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 de forma simultánea.
• 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 encargarse del siguiente paso, aunque cada traspaso debe conservar la información necesaria para continuar.

Estos 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, los requisitos de coordinación y la carga operativa aceptable de tu flujo de trabajo.

Fallas comunes en la orquestación de agentes de IA

Con la orquestación, cualquier cosa puede salir mal, desde simples descuidos hasta obstáculos 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, reunimos algunos de los errores comunes detrás de los flujos de trabajo orquestados poco confiables — 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.
• Agregación (fan-in) prematura. 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 el framework gestione 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 exitosa no queda registrada de forma duradera antes de que falle el worker. Durante la recuperación, el orquestador ve una tarea sin terminar y la vuelve a ejecutar.
• 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 superponen, 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 ciertos 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 de ingeniería de seguridad de Perplexity destaca por qué los agentes pueden traspasar límites de seguridad mientras persiguen objetivos legítimos, incluso sin instrucciones maliciosas

Observa lo distintas que son estas fallas. Una transición prematura del programador de tareas o una escritura externa ambigua pueden producir un resultado incorrecto, pero se originan en partes diferentes del ciclo de vida de la ejecución. Por eso, una orquestación confiable requiere algo más que mejorar los prompts o agregar reintentos.

7 prácticas recomendadas de orquestación de agentes de IA para lograr confiabilidad en producción

1. Define contratos de tarea explícitos, criterios de aceptación y condiciones de detención

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 (un alcance de trabajo para un agente): acuerda el objetivo, las restricciones, el formato de salida y las condiciones de falla antes de que comience la ejecución.

Por ejemplo, así 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 la prueba, registros de fallas de CI, commits recientes y código relevante de la aplicación.
• Restricciones: no desactivar pruebas, no relajar aserciones ni modificar comportamientos no relacionados de la aplicación.
• 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 la suite de regresión correspondiente también se supera.
• Condiciones de falla: 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 ha producido un resultado satisfactorio. Define qué constituye una finalización exitosa, 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 iteración o presupuestos de ejecución para que las tareas sin resolver no se conviertan en bucles interminables.

Volvamos a nuestro ejemplo de CI. Podrías definir las siguientes condiciones de detención:

• Éxito: la corrección supera 10 ejecuciones consecutivas de la prueba y la suite de regresión correspondiente.
• Límite de iteraciones: el agente puede intentar como máximo dos correcciones candidatas.
• Presupuesto de ejecución: el agente debe detenerse después de 60 minutos, aunque el problema siga sin resolverse.
• Límite de delegación: el agente puede delegar trabajo a un agente especializado, sin más delegación a subagentes.
• Finalización parcial: si ambos intentos fallan o se agota el tiempo límite, el agente devuelve sus hallazgos, los cambios que intentó y los resultados de las pruebas.
• Ejecución bloqueada: si el entorno de pruebas no está disponible, el agente se detiene y reporta el bloqueo en lugar de afirmar que tuvo éxito.

2. Mantén los orquestadores ligeros y exige traspasos estructurados

A veces, los desarrolladores le asignan demasiadas responsabilidades a un orquestador y, en lugar de coordinar a los agentes especializados, este empieza a escribir código, depurar o hacer 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 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 confiable del progreso del flujo de trabajo. Cuando se llena su ventana de contexto, la compactación automática puede descartar detalles importantes. Y si un worker falla, el siguiente agente necesita saber qué pasos se completaron realmente.

Por ejemplo, si el agente de programación genera un parche y luego falla, 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

Por eso, 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. Mientras tanto, 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 que tengan en cuenta las fallas y una ejecución de herramientas recuperable

Supongamos que tu agente de CI activa una ejecución de pruebas, pero la solicitud a la API agota el tiempo de espera. ¿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 necesitas distinguir entre los errores antes de decidir qué pasa después:

• Errores transitorios (429, 503): reintenta con un retroceso exponencial acotado y jitter, respetando Retry-After cuando se proporcione.
• Errores de validación o de permisos (400, 403): detente o corrige el problema de fondo en lugar de repetir la misma solicitud.
• Resultados ambiguos (tiempo de espera agotado tras una posible escritura): comprueba si la operación tuvo éxito 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 de reintento y el tiempo total de reintentos, y aplica un plazo general al flujo de trabajo para que los agentes anidados no puedan seguir reiniciando la misma operación. Si una dependencia falla repetidamente, usa un circuit breaker para detener temporalmente las solicitudes.

Para 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 deduplicación del lado del 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 autorizada.

Cuando no puedas determinar qué pasó, detente y escala el problema.

Un ejemplo de la lógica de reintentos para nuestro agente de CI, expresado 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 limitarse 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 de compensación cuando fallen pasos posteriores. Solo recuerda que la compensación no siempre equivale a una reversión completa. Puedes revertir una actualización de 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 dos cosas que equilibrar: cuánta capacidad de modelo necesita cada tarea y cuántas tareas puedes ejecutar de forma simultánea. Si te equivocas en cualquiera de las dos, corres el riesgo de que los agentes compitan por cuotas de API compartidas o de depender solo 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 suele pasarse por alto. Ten en cuenta que puedes configurar reglas de enrutamiento y evaluar modelos por tu cuenta, o usar una plataforma de orquestación que se encargue de la selección de modelos por ti.

Por ejemplo, el Modo de esfuerzo 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. Después, ese orquestador delega subtareas a agentes de apoyo, que pueden usar modelos de distintos proveedores.

Perplexity evalúa las configuraciones de modelos en cuanto a calidad y costo, y favorece las opciones más económicas que ofrecen resultados comparables. También puedes usar los controles personalizados si prefieres elegir tú mismo el modelo y el nivel de razonamiento.

En cuanto al paralelismo, el límite debe depender de tu infraestructura y de tus dependencias externas. Verifica los límites de frecuencia de solicitudes y de tokens de las API compartidas y, luego, haz pruebas de carga de tu flujo de trabajo con una concurrencia creciente. Observa si el rendimiento mejora 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 costos: 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 requeridas estén disponibles, en lugar de lanzar todos los agentes al mismo tiempo.

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, otorga 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 el daño si el agente comete un error o ejecuta código inseguro.

“Desconfío de los sistemas multiagente demasiado complicados, sobre todo cuando los agentes revisan y aprueban el trabajo de los demás. Puedes terminar con varios agentes que se pasan con total confianza el mismo error, sin que nadie lo detecte realmente”, 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 de estado
• la decisión del revisor

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

Así que, si la aprobación se rechaza o vence, 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 los agentes totalmente autónomos de extremo a extremo sean el objetivo. “Para mí, el mejor enfoque es crear unos cuantos agentes enfocados, con responsabilidades claras, permisos definidos y revisión humana en los puntos adecuados. Así sigues obteniendo 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 reportado Success cuando en realidad falló? Es molesto, por no decir exasperante, y la solución no es rápida, porque el mensaje final del agente no necesariamente te dirá dónde salieron mal las cosas.

Para investigar, 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é salió mal

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 ofrecen una forma estandarizada de describir estas operaciones. Por ejemplo, invoke_workflow identifica la ejecución de un flujo de trabajo; invoke_agent, la invocación de un 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 da una traza de la ruta de ejecución para que puedas identificar dónde tuvo un tropiezo 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 requeridos y consulta los sistemas externos para confirmar que las acciones realmente se completaron con éxito.

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

Aun así, debes validar los hallazgos del revisor cuando sea posible y, si usas evaluadores basados en LLM para evaluaciones repetidas, calibra sus juicios con ejemplos revisados por personas.

Inyecta fallas para probar la recuperación

Hasta ahora, rastreaste lo que ejecutaron los agentes y verificaste si sus resultados eran correctos. Pero ¿qué pasa 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 podría comportarse perfectamente bien en condiciones normales, pero fallar durante la recuperación.

Para probarlo, inyecta fallas deliberadamente en un entorno de prueba:

• Simula tiempos de espera agotados de la API
• Provoca fallas en los workers entre las escrituras externas y los puntos de control
• Devuelve resultados 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ó. Luego, revisa los resultados reales.

Supongamos que tu agente de CI envía una solicitud para iniciar una ejecución de pruebas, pero se agota el tiempo de espera de la respuesta de la API. El agente reintenta, recibe una respuesta exitosa y reporta Éxito. Todo parece estar bien hasta que revisas el servicio de CI y descubres que se crearon 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 aprobarse cuando el flujo de trabajo alcanza el estado esperado sin efectos secundarios no deseados.

Agrega las fallas que descubras a tus pruebas de regresión para que los cambios futuros no las vuelvan a introducir.

En última instancia, el éxito significa que el flujo de trabajo superó sus verificaciones obligatorias y que se verificaron sus resultados externos.

Preguntas frecuentes sobre la orquestación de agentes de IA

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

Los agentes aislados pueden completar correctamente sus tareas individuales, pero producir resultados inconsistentes en conjunto. Imagina que un agente de ventas recupera las condiciones de un cliente a las 10:00, un agente de precios calcula una cotización con precios actualizados a las 10:05 y un agente legal 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, operan con permisos distintos y no necesariamente comparten el contexto ni el estado de ejecución.

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

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

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

¿Cómo reanudar un flujo de trabajo de agentes de IA después de una falla?

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 que la ejecución continúe desde el 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 implementar mientras los flujos de trabajo aún se están ejecutando, es posible que el estado guardado y los historiales de ejecución ya no sean compatibles. Temporal resuelve esto mediante Worker Versioning y el parcheo de 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 implementar cambios incompatibles.

¿Cómo probar la confiabilidad 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 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 sola tasa de éxito agregada. Haz seguimiento del éxito en el primer intento, la consistencia entre ejecuciones repetidas, la latencia p95, el costo por tarea completada y la proporción que requiere intervención humana. Reporta los tamaños de muestra y los intervalos de incertidumbre de las tasas de éxito.