AI agents en producción: patrones de orquestación y fallo

El problema no es construir agentes. Es que sobrevivan.

Construir un agente de IA que funcione en un entorno controlado lleva una tarde. Construir uno que sobreviva en producción lleva meses. La diferencia no está en el modelo ni en el prompt: está en todo lo que rodea al agente cuando las cosas se tuercen.

Y se tuercen. Se tuercen a las tres de la mañana un viernes, cuando un proveedor cambia el formato de su API sin avisar. Se tuercen cuando un usuario envía un PDF escaneado a 72 DPI con texto en diagonal. Se tuercen cuando el modelo decide que la mejor forma de clasificar una factura es releerla catorce veces porque no tiene suficiente confianza en la respuesta.

Este whitepaper documenta los tres patrones de orquestación que hemos validado en producción con clientes reales: supervisor, jerárquico y consenso. También documenta los modos de fallo que descubrimos por las malas y las estrategias que los mitigan. No es un documento teórico. Cada patrón incluye las condiciones en las que funciona, las condiciones en las que falla, y los números que usamos para decidir entre ellos.

Tres patrones de orquestación

El patrón supervisor

El patrón supervisor es el punto de partida para la mayoría de despliegues y por buenas razones. Un componente central (el supervisor) recibe las peticiones, decide qué sub-agentes necesitan actuar, orquesta la ejecución y consolida los resultados.

La implementación concreta que usamos tiene tres capas:

1. Router. Clasifica la petición entrante y determina el flujo. Puede ser un modelo pequeño (Haiku, GPT-4o-mini) o lógica basada en reglas. El coste por clasificación está en el rango de $0.0003-$0.001.
2. Sub-agentes especializados. Cada uno tiene un scope definido: extracción de documentos, consulta de APIs, generación de respuestas estructuradas. Usan el modelo adecuado a su complejidad.
3. Consolidador. Recibe las salidas de los sub-agentes, valida contra esquemas JSON, resuelve conflictos y produce el resultado final.

La ventaja principal del patrón supervisor es la contención de fallos. Si el sub-agente de extracción de documentos falla, el supervisor puede reintentar, usar un fallback o escalar a revisión humana sin perder el estado de los otros sub-agentes que ya completaron su trabajo.

Los números de producción: en un flujo de procesamiento de pedidos con cuatro sub-agentes, el patrón supervisor maneja un 96.3% de peticiones sin intervención humana, con un coste medio de $0.08 por petición y una latencia p95 de 12 segundos.

La limitación es la centralización. El supervisor es un punto único de fallo. Si cae, todo cae. La mitigación es obvia (redundancia, health checks, circuit breakers), pero añade complejidad operativa.

El patrón jerárquico

El patrón jerárquico extiende el supervisor con múltiples niveles de delegación. Un supervisor de nivel superior delega en supervisores intermedios, que a su vez orquestan sus propios sub-agentes. Piensa en ello como un organigrama de software.

Usamos este patrón cuando el flujo de trabajo tiene suficiente complejidad para que un único supervisor se convierta en un cuello de botella cognitivo. Un ejemplo concreto: procesamiento de reclamaciones de seguros. El supervisor de nivel superior decide el tipo de reclamación. Los supervisores intermedios gestionan flujos específicos (daños materiales, responsabilidad civil, salud). Cada flujo tiene sus propios sub-agentes especializados.

La jerarquía introduce dos beneficios que el patrón plano no ofrece:

Aislamiento de contexto. Cada supervisor intermedio solo conoce su dominio. El supervisor de daños materiales no necesita saber nada sobre reclamaciones de salud. Esto reduce el tamaño de los prompts, mejora la precisión y baja los costes de tokens.

Escalabilidad organizativa. Diferentes equipos pueden poseer diferentes ramas de la jerarquía. El equipo de daños materiales evoluciona sus agentes sin afectar al equipo de salud. Las interfaces entre niveles están definidas por contratos (JSON schemas) que actúan como contratos de API.

El coste es latencia. Cada nivel de la jerarquía añade un salto de comunicación. En nuestras mediciones, cada nivel añade entre 2 y 4 segundos de latencia. Con tres niveles, la latencia total puede superar los 20 segundos. Para flujos donde el usuario está esperando una respuesta interactiva, esto es demasiado. Para procesamiento asíncrono, es aceptable.

La regla práctica que usamos: si el flujo tiene menos de 6 sub-agentes, el patrón supervisor plano es suficiente. A partir de 6, empieza a tener sentido la jerarquía. A partir de 15, es casi obligatoria.

El patrón de consenso

El patrón de consenso ejecuta múltiples agentes en paralelo sobre la misma tarea y combina sus resultados. Es el equivalente a pedir una segunda (y tercera) opinión.

Lo usamos exclusivamente para tareas donde la precisión es crítica y el coste del error es alto. Clasificación de documentos legales. Validación de datos financieros. Extracción de importes de facturas cuando el OCR es ambiguo.

La implementación típica ejecuta tres instancias del mismo agente (a veces con diferentes prompts o diferentes modelos) y aplica una función de agregación:

• Voto por mayoría para tareas de clasificación. Si dos de tres agentes dicen que el documento es una factura, es una factura.
• Mediana para tareas de extracción numérica. Si los tres agentes extraen importes de 1.250, 1.250 y 12.500 euros, la mediana descarta el outlier.
• Unión con verificación para tareas de extracción de campos múltiples. Se unen todos los campos extraidos y se verifican las discrepancias.

El coste es lineal con el número de instancias. Tres agentes cuestan tres veces más. Pero en contextos donde un error de clasificación tiene un coste de negocio de cientos o miles de euros, el multiplicador de 3x en coste de inference (céntimos) es irrelevante.

Los números: en extracción de facturas, pasar de un agente a tres con voto por mayoría redujo la tasa de error del 4.2% al 0.7%. El coste pasó de $0.03 a $0.09 por factura. Para un cliente que procesa 8.000 facturas al mes, la reducción de 280 errores mensuales justifica el incremento de $480 en costes de inference.

Modos de fallo y cómo sobrevivir a ellos

El loop infinito

El modo de fallo más peligroso es el agente que entra en un bucle. Relee el mismo documento, reinvoca la misma herramienta, intenta la misma estrategia una y otra vez. Cada iteración consume tokens. Sin un mecanismo de interrupción, un loop puede quemar cientos de dólares en minutos.

La causa raíz suele ser una de dos: el agente no puede resolver la ambigüedad con la información disponible, o la herramienta que está invocando devuelve siempre el mismo resultado insatisfactorio.

Tres mecanismos de protección son obligatorios:

1. Límite de iteraciones. Cada agente tiene un máximo de iteraciones configurable. Para la mayoría de nuestros agentes es 5. Si un agente no ha completado su tarea en 5 iteraciones, se detiene y escala.
2. Presupuesto de tokens. Cada invocación tiene un límite de tokens total. Lo configuramos a 3x el consumo medio histórico. Si la invocación actual cuesta más de $0.25 cuando la media es $0.08, algo va mal.
3. Detección de repetición. Comparamos los argumentos de cada tool call con los anteriores. Si un agente invoca la misma herramienta con los mismos argumentos dos veces consecutivas, se interrumpe. Esto captura el 80% de los loops antes de que consuman recursos significativos.

El fallo en cascada

En una arquitectura de múltiples agentes, el fallo de un componente puede propagarse. El sub-agente A falla, el supervisor reintenta, el reintento satura el rate limit de la API del modelo, los sub-agentes B y C empiezan a fallar también porque comparten el mismo pool de conexiones.

La mitigación es separar los circuit breakers por sub-agente. Cada sub-agente tiene su propio circuit breaker con su propio umbral. Si el agente de extracción falla tres veces consecutivas, su circuit breaker se abre y el supervisor deja de enviarle peticiones durante un periodo de enfriamiento. Los otros sub-agentes siguen operando normalmente.

También separamos los pools de rate limiting. Cada sub-agente tiene su propia cuota de tokens por minuto. Un sub-agente que entra en un loop no puede consumir la cuota de los demás.

La degradación silenciosa

Este es el modo de fallo que más daño causa porque es invisible. El agente sigue funcionando. Produce resultados. Los resultados parecen razonables. Pero la calidad ha bajado.

Lo hemos visto cuando un proveedor de modelos cambia el comportamiento del modelo sin cambiar la versión del API (ocurre más de lo que la industria admite). Lo hemos visto cuando los datos de entrada cambian gradualmente: facturas que antes tenían un formato consistente empiezan a llegar con variaciones porque el proveedor cambió su sistema.

La única defensa es monitoreo continuo de calidad. Muestreamos un porcentaje de las salidas del agente (entre el 5% y el 10%) y las evaluamos contra ground truth. Para extracción de documentos, comparamos campos extraidos con valores verificados por humanos. Para clasificación, medimos precisión y recall sobre el muestreo.

Tenemos alertas configuradas en tres umbrales:

• Warning: la precisión cae por debajo del 95%. Investigar en horario laboral.
• Error: la precisión cae por debajo del 90%. Investigar inmediatamente.
• Critical: la precisión cae por debajo del 85%. Desactivar el agente y procesar manualmente.

Los umbrales varían por caso de uso. Para un agente de triage de emails, un 90% puede ser aceptable. Para un agente que clasifica documentos fiscales, necesitamos 98%+.

La alucinación operativa

Los modelos de lenguaje alucinan. Esto es un hecho conocido. Lo que es menos conocido es cómo las alucinaciones se manifiestan en agentes con acceso a herramientas.

El caso más problemático que hemos visto: un agente que necesita consultar una API para obtener un dato, pero el modelo “decide” que ya sabe la respuesta y genera un valor inventado en lugar de invocar la herramienta. No falla. No lanza un error. Simplemente inventa un número de pedido, una fecha, un importe.

La defensa es doble. Primero, validación de esquema estricta en todas las salidas. Si el agente dice que el número de pedido es X, verificamos que X existe en la base de datos. Si no existe, la salida se rechaza. Segundo, análisis de trazas. Si una traza muestra que el agente produjo un resultado que incluye un campo que debería haber venido de una tool call, pero no hay tool call en la traza, tenemos una alucinación operativa.

Human-in-the-loop: dónde dibujar la línea

El debate “autónomo vs. supervisado” es un falso dilema. La pregunta real es: para cada tipo de decisión, cuál es el nivel correcto de supervisión humana?

Usamos un framework de cuatro niveles:

Nivel 0: Completamente autónomo. El agente decide y ejecuta sin intervención. Reservado para decisiones de bajo impacto y alta confianza. Ejemplo: clasificar un email como spam, actualizar el estado de un envío, enviar una notificación de confirmación.

Nivel 1: Autónomo con auditoría. El agente decide y ejecuta, pero todas las decisiones se registran para revisión posterior. Un humano revisa una muestra periódicamente. Ejemplo: clasificar facturas por categoría contable, asignar tickets de soporte a colas.

Nivel 2: Propuesta con aprobación. El agente propone una acción pero no la ejecuta hasta que un humano la aprueba. Ejemplo: redactar una respuesta a un cliente, proponer un ajuste de inventario, generar un borrador de informe.

Nivel 3: Solo asistencia. El agente proporciona información y análisis, pero la decisión y ejecución son completamente humanas. Ejemplo: análisis de riesgos legales, recomendaciones de inversión, diagnósticos médicos.

La asignación de niveles no es estática. Un agente puede empezar en Nivel 2, y a medida que acumula un historial de precisión alta, migrar a Nivel 1 y eventualmente a Nivel 0 para ciertos tipos de decisiones. El camino inverso también ocurre: si la precisión baja, el agente sube de nivel (más supervisión).

La implementación práctica requiere una cola de revisión. Las decisiones que necesitan aprobación humana van a una cola priorizada por urgencia y monto. Los revisores humanos ven la propuesta del agente, la evidencia que usó para llegar a esa propuesta, y el nivel de confianza. Pueden aprobar, rechazar o modificar. Las decisiones de los revisores alimentan el pipeline de evaluación y mejoran los umbrales de confianza.

Control de costes: más allá del presupuesto de tokens

El control de costes en agentes de IA tiene cuatro dimensiones que los equipos suelen descubrir secuencialmente (y dolorosamente).

Coste de inference

El más obvio. Cada llamada a un modelo LLM tiene un precio por token. El error común es usar el modelo más potente para todas las tareas. Nuestra regla: el 70% de las tareas de un flujo típico pueden resolverse con modelos rápidos y baratos (Haiku, GPT-4o-mini, Gemini Flash). El 25% necesita modelos medios (Sonnet, GPT-4o). Solo el 5% justifica modelos premium (Opus, o1).

Esa distribución de modelos reduce el coste medio por petición entre un 60% y un 75% comparado con usar el modelo premium para todo. En un cliente que procesa 50.000 peticiones mensuales, la diferencia es de $3.200 al mes.

Coste de reintentos

Un agente que reintenta tres veces antes de escalar cuesta cuatro veces más que uno que acierta a la primera. Los reintentos son necesarios, pero deben ser medidos y optimizados. Si un sub-agente tiene una tasa de reintentos superior al 15%, no necesita más reintentos: necesita un mejor prompt, mejores datos de entrada, o un rediseño.

Monitorizamos la tasa de reintentos por sub-agente como métrica primaria. Es el indicador más fiable de que algo está degradando silenciosamente.

Coste de human-in-the-loop

Cada escalación a un humano tiene un coste: el salario del revisor, el tiempo de espera del proceso, la posible degradación de la experiencia del usuario. En un cliente del sector logístico, calculamos que cada escalación cuesta 4.70 euros en tiempo de personal. Con 200 escalaciones diarias, son 940 euros al día. Reducir las escalaciones de 200 a 80 (mejorando la precisión del agente del 88% al 95%) ahorro 564 euros diarios, o 12.400 euros al mes.

Coste de errores no detectados

El más difícil de cuantificar y el más caro. Un error de clasificación fiscal puede resultar en una sanción. Un error en un importe de factura puede resultar en un pago incorrecto. Un error en la asignación de un ticket puede resultar en un SLA incumplido. Estos costes no aparecen en la factura del proveedor de LLM, pero son reales y a veces órdenes de magnitud mayores que el coste de inference.

La contabilidad completa del coste de un agente incluye las cuatro dimensiones. Los equipos que solo optimizan el coste de inference ignoran el 80% de la ecuación.

Observabilidad específica para orquestación

La observabilidad de microservicios es un requisito previo, pero los sistemas de agentes necesitan capas adicionales.

Trazas de razonamiento

Cada invocación de un agente genera una traza que incluye: el prompt enviado al modelo, los tool calls con sus argumentos y respuestas, las decisiones de routing del supervisor, los resultados de validación, y el output final. Almacenamos estas trazas en un formato estructurado que permite queries como “muéstrame todas las invocaciones donde el agente usó más de 3 reintentos en la última hora” o “muéstrame las invocaciones donde la confianza fue baja pero el resultado fue correcto”.

Usamos OpenTelemetry como base, con spans personalizados para cada componente del agente. Un span por el supervisor, un span por cada sub-agente, un span por cada tool call. Los atributos incluyen tokens consumidos, modelo usado, nivel de confianza, y resultado de validación.

Dashboards operativos

Mantenemos dos dashboards principales. El dashboard de salud muestra métricas en tiempo real: peticiones por minuto, latencia p50/p95/p99, tasa de éxito, tasa de escalación, coste acumulado. El dashboard de calidad muestra métricas de precisión calculadas sobre el muestreo: accuracy por tipo de tarea, drift de confianza, y la correlación entre confianza reportada y precisión real.

El segundo dashboard es crítico porque detecta el problema de calibración: un agente que reporta alta confianza pero produce resultados incorrectos. Si la correlación entre confianza y precisión diverge, los umbrales de human-in-the-loop necesitan recalibrarse.

Alertas específicas de agentes

Además de las alertas estándar de infraestructura, configuramos alertas específicas:

• Tasa de loops detectados > 2% de invocaciones.
• Coste medio por invocación > 2x la media histórica.
• Tasa de escalación humana > umbral configurado por caso de uso.
• Tiempo medio en cola de revisión humana > SLA definido.
• Drift de precisión > 3 puntos porcentuales en ventana de 24 horas.

Eligiendo el patrón correcto

No existe un patrón universalmente mejor. La decisión depende de cuatro factores.

Complejidad del flujo. Flujos simples (menos de 5 pasos, sin ramificación significativa) funcionan bien con el patrón supervisor. Flujos complejos (múltiples ramas, múltiples dominios) necesitan jerarquía.

Requisitos de precisión. Si un error tiene coste alto, el patrón de consenso en las tareas críticas del flujo reduce la tasa de error significativamente. No necesitas consenso en todo el flujo, solo en los puntos de decisión de alto impacto.

Presupuesto y latencia. El patrón de consenso multiplica costes e introduce latencia por las ejecuciones paralelas. La jerarquía añade latencia por los saltos entre niveles. Si el presupuesto es ajustado o la latencia es crítica, el supervisor plano con buenos fallbacks es la opción más pragmática.

Madurez del equipo. La jerarquía y el consenso requieren más infraestructura de observabilidad y más disciplina operativa. Si el equipo está empezando con agentes, el patrón supervisor es suficiente complejidad para la primera iteración. Los otros patrones se introducen cuando los datos muestran que son necesarios, no antes.

Patrones combinados: lo que usamos en producción

En la práctica, nuestros despliegues combinan patrones. Un ejemplo real: procesamiento de documentos de importación.

El supervisor de nivel superior clasifica el documento (factura, packing list, BL, DUA). Cada tipo de documento tiene su propio sub-supervisor con agentes especializados de extracción. La extracción de importes usa patrón de consenso con tres instancias. La extracción de campos textuales (nombre del proveedor, descripción de mercancías) usa un agente único.

El flujo completo tarda entre 8 y 15 segundos. Procesa documentos con una precisión del 97.2% sin intervención humana. El 2.8% restante va a cola de revisión. El coste medio es $0.14 por documento. Para un cliente que procesa 3.000 documentos mensuales, el coste total es $420 frente a un estimado de 2.5 FTEs ($7.500/mes) para procesamiento manual.

Esos números no incluyen la ventaja de velocidad (15 segundos vs. 8-12 minutos por documento) ni la disponibilidad 24/7. Pero son los números de coste directo los que convencen a los CFOs.

El estado del arte y hacia dónde va

El ecosistema de orquestación de agentes está madurando rápidamente. Frameworks como LangGraph, CrewAI y AutoGen proporcionan abstracciones útiles pero todavía requieren trabajo significativo de personalización para producción. El standard de facto para interoperabilidad entre agentes empieza a ser el Model Context Protocol (MCP) de Anthropic, que estandariza cómo los agentes consumen herramientas y datos.

Lo que falta es tooling maduro para testing y evaluación. Testear un agente determinista es trivial. Testear un agente que toma decisiones probabilísticas sobre datos no estructurados requiere infraestructura de evaluación que la mayoría de frameworks no proporcionan. Los equipos que invierten en evaluación antes que en features son los que mantienen sus agentes en producción. Los que no, acaban con un demo que nunca escala.

La orquestación no es el problema más difícil de los agentes en producción. Pero es el que determina si tu sistema se degrada elegantemente o colapsa espectacularmente cuando algo falla. Y algo siempre falla. Si quieres profundizar en los patrones de arquitectura o entender los costes reales de operar LLMs en producción, los cubrimos en detalle.