AI agents en produccion: patrones de orquestacion 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 produccion lleva meses. La diferencia no esta en el modelo ni en el prompt: esta en todo lo que rodea al agente cuando las cosas se tuercen.

Y se tuercen. Se tuercen a las tres de la manana un viernes, cuando un proveedor cambia el formato de su API sin avisar. Se tuercen cuando un usuario envia 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 orquestacion que hemos validado en produccion con clientes reales: supervisor, jerarquico y consenso. Tambien documenta los modos de fallo que descubrimos por las malas y las estrategias que los mitigan. No es un documento teorico. Cada patron incluye las condiciones en las que funciona, las condiciones en las que falla, y los numeros que usamos para decidir entre ellos.

Tres patrones de orquestacion

El patron supervisor

El patron supervisor es el punto de partida para la mayoria de despliegues y por buenas razones. Un componente central (el supervisor) recibe las peticiones, decide que sub-agentes necesitan actuar, orquesta la ejecucion y consolida los resultados.

La implementacion concreta que usamos tiene tres capas:

1. Router. Clasifica la peticion entrante y determina el flujo. Puede ser un modelo pequeno (Haiku, GPT-4o-mini) o logica basada en reglas. El coste por clasificacion esta en el rango de $0.0003-$0.001.
2. Sub-agentes especializados. Cada uno tiene un scope definido: extraccion de documentos, consulta de APIs, generacion 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 patron supervisor es la contencion de fallos. Si el sub-agente de extraccion de documentos falla, el supervisor puede reintentar, usar un fallback o escalar a revision humana sin perder el estado de los otros sub-agentes que ya completaron su trabajo.

Los numeros de produccion: en un flujo de procesamiento de pedidos con cuatro sub-agentes, el patron supervisor maneja un 96.3% de peticiones sin intervencion humana, con un coste medio de $0.08 por peticion y una latencia p95 de 12 segundos.

La limitacion es la centralizacion. El supervisor es un punto unico de fallo. Si cae, todo cae. La mitigacion es obvia (redundancia, health checks, circuit breakers), pero anade complejidad operativa.

El patron jerarquico

El patron jerarquico extiende el supervisor con multiples niveles de delegacion. 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 patron cuando el flujo de trabajo tiene suficiente complejidad para que un unico 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 reclamacion. Los supervisores intermedios gestionan flujos especificos (danos materiales, responsabilidad civil, salud). Cada flujo tiene sus propios sub-agentes especializados.

La jerarquia introduce dos beneficios que el patron plano no ofrece:

Aislamiento de contexto. Cada supervisor intermedio solo conoce su dominio. El supervisor de danos materiales no necesita saber nada sobre reclamaciones de salud. Esto reduce el tamano de los prompts, mejora la precision y baja los costes de tokens.

Escalabilidad organizativa. Diferentes equipos pueden poseer diferentes ramas de la jerarquia. El equipo de danos materiales evoluciona sus agentes sin afectar al equipo de salud. Las interfaces entre niveles estan definidas por contratos (JSON schemas) que actuan como contratos de API.

El coste es latencia. Cada nivel de la jerarquia anade un salto de comunicacion. En nuestras mediciones, cada nivel anade entre 2 y 4 segundos de latencia. Con tres niveles, la latencia total puede superar los 20 segundos. Para flujos donde el usuario esta esperando una respuesta interactiva, esto es demasiado. Para procesamiento asicrono, es aceptable.

La regla practica que usamos: si el flujo tiene menos de 6 sub-agentes, el patron supervisor plano es suficiente. A partir de 6, empieza a tener sentido la jerarquia. A partir de 15, es casi obligatoria.

El patron de consenso

El patron de consenso ejecuta multiples agentes en paralelo sobre la misma tarea y combina sus resultados. Es el equivalente a pedir una segunda (y tercera) opinion.

Lo usamos exclusivamente para tareas donde la precision es critica y el coste del error es alto. Clasificacion de documentos legales. Validacion de datos financieros. Extraccion de importes de facturas cuando el OCR es ambiguo.

La implementacion tipica ejecuta tres instancias del mismo agente (a veces con diferentes prompts o diferentes modelos) y aplica una funcion de agregacion:

• Voto por mayoria para tareas de clasificacion. Si dos de tres agentes dicen que el documento es una factura, es una factura.
• Mediana para tareas de extraccion numerica. Si los tres agentes extraen importes de 1.250, 1.250 y 12.500 euros, la mediana descarta el outlier.
• Union con verificacion para tareas de extraccion de campos multiples. Se unen todos los campos extraidos y se verifican las discrepancias.

El coste es lineal con el numero de instancias. Tres agentes cuestan tres veces mas. Pero en contextos donde un error de clasificacion tiene un coste de negocio de cientos o miles de euros, el multiplicador de 3x en coste de inference (centimos) es irrelevante.

Los numeros: en extraccion de facturas, pasar de un agente a tres con voto por mayoria redujo la tasa de error del 4.2% al 0.7%. El coste paso de $0.03 a $0.09 por factura. Para un cliente que procesa 8.000 facturas al mes, la reduccion de 280 errores mensuales justifica el incremento de $480 en costes de inference.

Modos de fallo y como sobrevivir a ellos

El loop infinito

El modo de fallo mas 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 iteracion consume tokens. Sin un mecanismo de interrupcion, un loop puede quemar cientos de dolares en minutos.

La causa raiz suele ser una de dos: el agente no puede resolver la ambiguedad con la informacion disponible, o la herramienta que esta invocando devuelve siempre el mismo resultado insatisfactorio.

Tres mecanismos de proteccion son obligatorios:

1. Limite de iteraciones. Cada agente tiene un maximo de iteraciones configurable. Para la mayoria 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 invocacion tiene un limite de tokens total. Lo configuramos a 3x el consumo medio historico. Si la invocacion actual cuesta mas de $0.25 cuando la media es $0.08, algo va mal.
3. Deteccion de repeticion. 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 multiples 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 tambien porque comparten el mismo pool de conexiones.

La mitigacion es separar los circuit breakers por sub-agente. Cada sub-agente tiene su propio circuit breaker con su propio umbral. Si el agente de extraccion 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.

Tambien 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 demas.

La degradacion silenciosa

Este es el modo de fallo que mas dano 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 version del API (ocurre mas de lo que la industria admite). Lo hemos visto cuando los datos de entrada cambian gradualmente: facturas que antes tenian un formato consistente empiezan a llegar con variaciones porque el proveedor cambio su sistema.

La unica 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 extraccion de documentos, comparamos campos extraidos con valores verificados por humanos. Para clasificacion, medimos precision y recall sobre el muestreo.

Tenemos alertas configuradas en tres umbrales:

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

Los umbrales varian 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 alucinacion operativa

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

El caso mas problematico 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 numero de pedido, una fecha, un importe.

La defensa es doble. Primero, validacion de esquema estricta en todas las salidas. Si el agente dice que el numero de pedido es X, verificamos que X existe en la base de datos. Si no existe, la salida se rechaza. Segundo, analisis de trazas. Si una traza muestra que el agente produjo un resultado que incluye un campo que deberia haber venido de una tool call, pero no hay tool call en la traza, tenemos una alucinacion operativa.

Human-in-the-loop: donde dibujar la linea

El debate “autonomo vs. supervisado” es un falso dilema. La pregunta real es: para cada tipo de decision, cual es el nivel correcto de supervision humana?

Usamos un framework de cuatro niveles:

Nivel 0: Completamente autonomo. El agente decide y ejecuta sin intervencion. Reservado para decisiones de bajo impacto y alta confianza. Ejemplo: clasificar un email como spam, actualizar el estado de un envio, enviar una notificacion de confirmacion.

Nivel 1: Autonomo con auditoria. El agente decide y ejecuta, pero todas las decisiones se registran para revision posterior. Un humano revisa una muestra periodicamente. Ejemplo: clasificar facturas por categoria contable, asignar tickets de soporte a colas.

Nivel 2: Propuesta con aprobacion. El agente propone una accion 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 informacion y analisis, pero la decision y ejecucion son completamente humanas. Ejemplo: analisis de riesgos legales, recomendaciones de inversion, diagnosticos medicos.

La asignacion de niveles no es estatica. Un agente puede empezar en Nivel 2, y a medida que acumula un historial de precision alta, migrar a Nivel 1 y eventualmente a Nivel 0 para ciertos tipos de decisiones. El camino inverso tambien ocurre: si la precision baja, el agente sube de nivel (mas supervision).

La implementacion practica requiere una cola de revision. Las decisiones que necesitan aprobacion humana van a una cola priorizada por urgencia y monto. Los revisores humanos ven la propuesta del agente, la evidencia que uso para llegar a esa propuesta, y el nivel de confianza. Pueden aprobar, rechazar o modificar. Las decisiones de los revisores alimentan el pipeline de evaluacion y mejoran los umbrales de confianza.

Control de costes: mas alla 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 mas obvio. Cada llamada a un modelo LLM tiene un precio por token. El error comun es usar el modelo mas potente para todas las tareas. Nuestra regla: el 70% de las tareas de un flujo tipico pueden resolverse con modelos rapidos 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 distribucion de modelos reduce el coste medio por peticion 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 mas 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 mas reintentos: necesita un mejor prompt, mejores datos de entrada, o un rediseno.

Monitorizamos la tasa de reintentos por sub-agente como metrica primaria. Es el indicador mas fiable de que algo esta degradando silenciosamente.

Coste de human-in-the-loop

Cada escalacion a un humano tiene un coste: el salario del revisor, el tiempo de espera del proceso, la posible degradacion de la experiencia del usuario. En un cliente del sector logistico, calculamos que cada escalacion cuesta 4.70 euros en tiempo de personal. Con 200 escalaciones diarias, son 940 euros al dia. Reducir las escalaciones de 200 a 80 (mejorando la precision del agente del 88% al 95%) ahorro 564 euros diarios, o 12.400 euros al mes.

Coste de errores no detectados

El mas dificil de cuantificar y el mas caro. Un error de clasificacion fiscal puede resultar en una sancion. Un error en un importe de factura puede resultar en un pago incorrecto. Un error en la asignacion 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 ordenes 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 ecuacion.

Observabilidad especifica para orquestacion

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

Trazas de razonamiento

Cada invocacion 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 validacion, y el output final. Almacenamos estas trazas en un formato estructurado que permite queries como “muestrame todas las invocaciones donde el agente uso mas de 3 reintentos en la ultima hora” o “muestrame 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 validacion.

Dashboards operativos

Mantenemos dos dashboards principales. El dashboard de salud muestra metricas en tiempo real: peticiones por minuto, latencia p50/p95/p99, tasa de exito, tasa de escalacion, coste acumulado. El dashboard de calidad muestra metricas de precision calculadas sobre el muestreo: accuracy por tipo de tarea, drift de confianza, y la correlacion entre confianza reportada y precision real.

El segundo dashboard es critico porque detecta el problema de calibracion: un agente que reporta alta confianza pero produce resultados incorrectos. Si la correlacion entre confianza y precision diverge, los umbrales de human-in-the-loop necesitan recalibrarse.

Alertas especificas de agentes

Ademas de las alertas estandar de infraestructura, configuramos alertas especificas:

• Tasa de loops detectados > 2% de invocaciones.
• Coste medio por invocacion > 2x la media historica.
• Tasa de escalacion humana > umbral configurado por caso de uso.
• Tiempo medio en cola de revision humana > SLA definido.
• Drift de precision > 3 puntos porcentuales en ventana de 24 horas.

Eligiendo el patron correcto

No existe un patron universalmente mejor. La decision depende de cuatro factores.

Complejidad del flujo. Flujos simples (menos de 5 pasos, sin ramificacion significativa) funcionan bien con el patron supervisor. Flujos complejos (multiples ramas, multiples dominios) necesitan jerarquia.

Requisitos de precision. Si un error tiene coste alto, el patron de consenso en las tareas criticas del flujo reduce la tasa de error significativamente. No necesitas consenso en todo el flujo, solo en los puntos de decision de alto impacto.

Presupuesto y latencia. El patron de consenso multiplica costes e introduce latencia por las ejecuciones paralelas. La jerarquia anade latencia por los saltos entre niveles. Si el presupuesto es ajustado o la latencia es critica, el supervisor plano con buenos fallbacks es la opcion mas pragmatica.

Madurez del equipo. La jerarquia y el consenso requieren mas infraestructura de observabilidad y mas disciplina operativa. Si el equipo esta empezando con agentes, el patron supervisor es suficiente complejidad para la primera iteracion. Los otros patrones se introducen cuando los datos muestran que son necesarios, no antes.

Patrones combinados: lo que usamos en produccion

En la practica, nuestros despliegues combinan patrones. Un ejemplo real: procesamiento de documentos de importacion.

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 extraccion. La extraccion de importes usa patron de consenso con tres instancias. La extraccion de campos textuales (nombre del proveedor, descripcion de mercancias) usa un agente unico.

El flujo completo tarda entre 8 y 15 segundos. Procesa documentos con una precision del 97.2% sin intervencion humana. El 2.8% restante va a cola de revision. 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 numeros no incluyen la ventaja de velocidad (15 segundos vs. 8-12 minutos por documento) ni la disponibilidad 24/7. Pero son los numeros de coste directo los que convencen a los CFOs.

El estado del arte y hacia donde va

El ecosistema de orquestacion de agentes esta madurando rapidamente. Frameworks como LangGraph, CrewAI y AutoGen proporcionan abstracciones utiles pero todavia requieren trabajo significativo de personalizacion para produccion. El standard de facto para interoperabilidad entre agentes empieza a ser el Model Context Protocol (MCP) de Anthropic, que estandariza como los agentes consumen herramientas y datos.

Lo que falta es tooling maduro para testing y evaluacion. Testear un agente determinista es trivial. Testear un agente que toma decisiones probabilisticas sobre datos no estructurados requiere infraestructura de evaluacion que la mayoria de frameworks no proporcionan. Los equipos que invierten en evaluacion antes que en features son los que mantienen sus agentes en produccion. Los que no, acaban con un demo que nunca escala.

La orquestacion no es el problema mas dificil de los agentes en produccion. 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 produccion, los cubrimos en detalle.