Patrones de Orquestación Multi-Agente: Una Guía Práctica

Los sistemas de IA de agente único alcanzaron su punto máximo en 2025: le daba un prompt, algunas herramientas y un objetivo a un único LLM, y funcionaba razonablemente bien en tareas delimitadas.

En 2026, los sistemas multiagente han pasado de demostraciones de investigación a infraestructura de producción. Gartner informa un aumento del 1.445% en las consultas sobre sistemas multiagente desde el primer trimestre de 2024 hasta el segundo trimestre de 2025, mientras que el Informe de Referencia de Conectividad 2026 de Salesforce encontró que las organizaciones utilizan un promedio de 12 agentes, con un crecimiento proyectado del 67% en dos años. El clúster de Sistemas de IA cubre el stack completo en el que operan estos sistemas, desde la inferencia y la memoria hasta el enrutamiento y la observabilidad.

Pero aquí está lo que menos se discute: el 40% de los pilotos multiagente fracasa dentro de los seis meses posteriores al despliegue en producción. El fracaso no es que los sistemas multiagente no funcionen. El fracaso es que los equipos eligen el patrón de orquestación incorrecto para su problema, o eligen el correcto sin entender cómo se rompe.

Esta guía cubre los patrones de orquestación que resisten en producción, las formas específicas en que cada uno falla y un marco de decisión para elegir la arquitectura adecuada.

El Problema Central: La Coordinación es Difícil

Cuando se pasa de un único agente de IA a múltiples agentes trabajando juntos, la primera pregunta de ingeniería es: ¿cómo se coordinan?

El modelo de coordinación —el patrón de orquestación— determina la latencia del sistema, la tolerancia a fallos, el límite de escalabilidad y la complejidad de depuración. Es consistentemente la decisión arquitectónica de mayor impacto en el diseño multiagente, condicionando cada elección de implementación posterior.

Todo sistema multiagente de producción se mapea a uno de seis patrones canónicos, o a un híbrido de dos o más. Los patrones emergen de las restricciones de los sistemas distribuidos: costo de coordinación, aislamiento de fallos, requisitos de throughput y observabilidad.

Patrón 1: Orquestador-Trabajador

Cómo Funciona

Orquestador-Trabajador es el modelo de coordinación multiagente de nodo centralizado con estructura de estrella (hub-and-spoke). Un único agente orquestador recibe la tarea, la descompone en subtareas, delega cada subtarea a un agente trabajador especializado y agrega los resultados. Los trabajadores no se comunican directamente entre sí; toda la coordinación fluye a través del orquestador, que mantiene el plan completo y la autoridad de toma de decisiones.

Cuándo Usarlo

• Flujos de trabajo multifuncionales con descomposición clara de tareas
• Escenarios de triaje y enrutamiento (soporte al cliente, clasificación de incidentes)
• Cargas de trabajo donde se requiere un único punto de responsabilidad
• Tareas donde el orquestador puede usar un modelo capaz mientras los trabajadores usan modelos más baratos y específicos para la tarea

Ejemplo del mundo real: Salesforce Agentforce 2.0 utiliza orquestador-trabajador para descomponer las consultas de los clientes en etapas de investigación, borrador y revisión.

Cómo Falla

Punto único de fallo. El orquestador es tanto un cuello de botella como un punto de fallo. Si la llamada al LLM del orquestador tarda 3 segundos y tienes 20 trabajadores esperando asignaciones, tu límite de throughput de descomposición es de aproximadamente 6,7 tareas por segundo. Si el orquestador malclasifica una tarea, el trabajador incorrecto la recibe; y las tasas de malclasificación se compunden a gran escala.

Desbordamiento de contexto. El orquestador acumula contexto de todos los trabajadores. Con 4 o más trabajadores, el orquestador frecuentemente excede los límites de contexto porque mantiene el historial completo de la conversación para cada interacción de trabajador simultáneamente.

Explosión de costos. Los flujos de trabajo que cuestan $0,50 en pruebas pueden llegar a $50.000/mes con 100K ejecuciones. El orquestador realiza múltiples llamadas al LLM para la descomposición y la agregación encima de cada llamada de trabajador. A gran escala, la sobrecarga domina el costo del trabajador.

Mitigaciones

• Establecer contratos de interfaz explícitos entre el orquestador y los trabajadores
• Requerir salidas estructuradas de los trabajadores (esquemas JSON, respuestas tipadas)
• Delimitar los presupuestos de subtareas (límites de tokens, límites de pasos) para prevenir costos descontrolados
• Considerar una variante jerárquica (ver Patrón 4) cuando el número de trabajadores exceda 5

Patrón 2: Pipeline Secuencial

Cómo Funciona

El Pipeline Secuencial es la cadena lineal con estado compartido: una secuencia predefinida de agentes con orden determinista, donde cada etapa transforma o enriquece los datos y los pasa al siguiente. No hay ramificación en tiempo de ejecución; el orden de ejecución es fijo en tiempo de diseño, lo que hace que el patrón sea altamente predecible pero inflexible.

Cuándo Usarlo

• Flujos de trabajo de procesamiento de documentos (ingestión → extracción → validación → salida)
• Pipelines de generación de contenido (investigación → borrador → edición → publicación)
• Verificación de cumplimiento (generar → verificar → revisar → aprobar)
• Flujos de trabajo de enriquecimiento de datos y ETL

Ejemplo del mundo real: El flujo de trabajo de firmas legales de Microsoft Azure utiliza pipelines secuenciales para la generación de contratos: borrador → revisión → marcado de cambios → final.

Cómo Falla

Propagación de errores. Una salida errónea en la etapa 1 se propaga aguas abajo sin retroceso. Una alucinación en la etapa de investigación produce un borrador defectuoso, que el editor pule hasta convertirlo en una salida final confiable pero incorrecta.

Sobrecarga de coordinación. Un pipeline de 4 agentes añade aproximadamente 950 ms de sobrecarga de coordinación frente a 500 ms de tiempo de procesamiento. Estás pagando el triple por el mismo resultado si la especialización no es requerida. El consumo de tokens se compunde: 29.000 tokens en un pipeline de 4 agentes frente a 10.000 para un único agente haciendo el mismo trabajo.

Sin ramificación condicional. El pipeline no puede adaptarse basándose en resultados intermedios. Si la etapa 2 descubre que la entrada está mal formada, no tiene mecanismo para señalar a la etapa 1 que reintente; debe fallar o producir una salida degradada.

Mitigaciones

• Insertar puertas de calidad entre etapas (agentes de validación ligeros que verifiquen la salida antes de pasarla aguas abajo)
• Añadir bucles de reprocesamiento para etapas que puedan reintentar; los motores de flujos de trabajo duraderos como Temporal manejan la semántica de reintento de manera fiable
• Mantener los pipelines a un máximo de 3-4 etapas; más allá de eso, considera orquestador-trabajador para la ramificación condicional

Patrón 3: Fan-Out / Fan-In (Abanico de Salida / Abanico de Entrada)

Cómo Funciona

Fan-Out / Fan-In es ejecución paralela con agregación. Un despachador enruta el trabajo a múltiples agentes ejecutándose simultáneamente, y luego un colector agrega sus resultados mediante votación, fusión ponderada o síntesis de LLM. Los agentes operan de forma independiente durante toda la ejecución y no se comunican entre sí; el único límite compartido es el colector.

Cuándo Usarlo

• Análisis de múltiples perspectivas donde los puntos de vista diversos son valiosos
• Revisión de código concurrente (múltiples revisores en paralelo)
• 4 o más tareas independientes que pueden descomponerse anticipadamente
• Cargas de trabajo donde el tiempo real (wall-clock time) es más importante que la eficiencia de tokens

Métrica clave: El Fan-out reduce el tiempo real un 75% en comparación con la ejecución secuencial. Cuatro agentes ejecutándose en paralelo completan en el tiempo de uno.

Cómo Falla

Límites de tasa de API. La carga colectiva excede la capacidad incluso si los agentes individuales se mantienen dentro de los límites. Cinco agentes realizando cada uno 10 solicitudes por minuto pueden exceder un límite de 40 RPM que un único agente respeta.

Condiciones de carrera cuadráticas. Los conflictos de estado compartido escalan como N(N-1)/2. Con 5 agentes, eso son 10 conflictos potenciales. Con 10 agentes, son 45. La gestión del estado se convierte en la complejidad dominante.

Alucinación de agregación. La síntesis de LLM puede inventar consenso. Si el Agente A dice “sí” y el Agente B dice “no”, el agregador podría producir “quizás”, una zona media alucinada que ningún agente sugirió. Requiere resolución de conflictos explícita, no solo resumen.

Mitigaciones

• Usar mecanismos de votación explícitos en lugar de síntesis libre
• Implementar limitación de tasa a nivel del despachador
• Mantener estado separado por trabajador; fusionar en el colector
• Establecer un número máximo de agentes (5-8) para mantener las condiciones de carrera manejables

Patrón 4: Jerárquico

Cómo Funciona

Jerárquico es delegación estructurada en árbol con múltiples niveles: un gerente de nivel superior delega a supervisores de nivel medio, que a su vez delegan a trabajadores de nivel hoja. Cada nivel añade una capa de abstracción: estrategia en la parte superior, táctica en el medio y ejecución en las hojas. Las ventanas de contexto se gestionan de forma independiente en cada nivel, por lo que ningún agente necesita mantener todo el problema en su contexto.

Cuándo Usarlo

• Tareas empresariales complejas y multidominio que requieren 20+ agentes
• Auditoría de grandes bases de código donde diferentes módulos necesitan especialistas distintos
• Procesamiento masivo de documentos (miles de documentos en múltiples categorías)
• Tareas donde la ventana de contexto de un único agente no puede contener todo el problema

Ventaja clave: Los sistemas jerárquicos escalan logarítmicamente. Cada gerente maneja un número limitado de subordinados, por lo que añadir trabajadores no aumenta linealmente la sobrecarga de coordinación.

Cómo Falla

Acumulación de latencia. Cada nivel añade latencia. Una jerarquía de 3 niveles requiere un mínimo de 6-12 segundos, acumulándose por nivel. El gerente superior espera a todos los supervisores, quienes esperan a todos los trabajadores.

Pérdida de información. El resumen entre niveles es con pérdida. Un supervisor resume la salida del trabajador para el gerente superior, perdiendo detalles que podrían ser críticos para la decisión final.

Aislamiento de fallos de rama. Un fallo en una rama no se propaga a otras, lo cual es bueno para la tolerancia a fallos pero malo para la consistencia. Diferentes ramas podrían llegar a conclusiones contradictorias que el gerente superior no puede resolver.

Mitigaciones

• Establecer requisitos de resumen explícitos para cada nivel
• Implementar validación entre ramas en el gerente superior
• Mantener la profundidad de la jerarquía a un máximo de 2-3 niveles
• Usar salidas estructuradas en cada nivel para reducir la pérdida de información

Patrón 5: Enjambre (Swarm)

Cómo Funciona

El Enjambre es coordinación emergente descentralizada sin autoridad central. Los agentes autónomos toman decisiones locales basadas en un estado compartido (un pizarrón o blackboard) o señales del entorno, sin un orquestador que dirija el flujo. Los agentes descubren tareas disponibles, las reclaman y publican los resultados de vuelta al espacio compartido. La coordinación es emergente; el sistema se autoorganiza alrededor del trabajo disponible, similar a cómo las abejas navegan hacia un nuevo colmen sin un coordinador central.

Cuándo Usarlo

• Flujos de investigación donde la ruta de búsqueda óptima es desconocida
• Recopilación de inteligencia competitiva a través de múltiples fuentes
• Scraping web a gran escala con descubrimiento dinámico de objetivos
• Exploración paralela de hipótesis en dominios científicos o analíticos

Ventaja clave: Un enjambre de 50 agentes de investigación puede explorar 50 hipótesis en paralelo sin que ningún coordinador central planifique la búsqueda. El sistema se autoorganiza alrededor del trabajo disponible.

Cómo Falla

Pesadilla de depuración. Sin un flujo de control central, rastrear fallos requiere trazabilidad distribuida y reproducción del pizarrón. No puedes seguir un único camino de ejecución; debes reconstruir el comportamiento emergente a partir de los registros.

Sin garantías transaccionales. Los patrones de enjambre no pueden imponer un orden estricto o consistencia transaccional. Si necesitas que el Agente A se complete antes de que el Agente B comience, un enjambre es el patrón incorrecto.

Condiciones de terminación. ¿Cómo sabe el enjambre cuándo detenerse? Sin criterios de terminación explícitos, los agentes pueden continuar indefinidamente, consumiendo cómputo y generando retornos decrecientes.

Mitigaciones

• Implementar condiciones de terminación explícitas (basadas en tiempo, conteo de resultados o convergencia)
• Usar un pizarrón con entradas versionadas para rastrear cambios de estado
• Añadir un agente de monitoreo que observe el comportamiento del enjambre y pueda intervenir
• Establecer presupuestos a nivel de agente (máximo de pasos, máximo de tokens) para prevenir ejecución descontrolada; los despachadores estilo Kanban proporcionan patrones prácticos de limitación de tasa y concurrencia para despliegues de enjambre autoalojados

Patrón 6: Malla (Mesh)

Cómo Funciona

Malla es comunicación directa peer-to-peer con conexiones persistentes: los agentes se comunican entre sí a través de canales explícitos y predefinidos en lugar de a través de ningún hub central. El grafo de comunicación se define típicamente en tiempo de despliegue, por lo que el Agente A sabe que necesita al Agente B para consultas de base de datos y al Agente C para lógica de autenticación. Para la comunicación de agentes entre equipos o sistemas, el protocolo A2A proporciona una capa estandarizada de descubrimiento y mensajería para participantes de la malla que abarcan diferentes marcos o límites de propiedad.

Cuándo Usarlo

• Razonamiento colaborativo donde los agentes necesitan compartir estado intermedio
• Sistemas de codificación multiagente (bucles planificador ↔ codificador ↔ probador)
• Refinamiento iterativo de artefactos donde múltiples especialistas contribuyen
• Escenarios de negociación donde los agentes representan diferentes partes interesadas

Ventaja clave: Ideal para el refinamiento iterativo. Los agentes pueden pasar resultados paridos de ida y vuelta, construyendo sobre el trabajo de cada uno sin un agregador central.

Cómo Falla

Explosión combinatoria. El número de conexiones escala como N(N-1)/2. Con 3 agentes, son 3 conexiones. Con 8 agentes, son 28. Es mejor limitarlo a 3-8 agentes estrechamente acoplados.

Dependencias circulares. El Agente A llama al Agente B, que llama al Agente C, que llama al Agente A. Sin detección de ciclos, los patrones de malla pueden entrar en bucles infinitos.

Complejidad de depuración. El enrutamiento no determinista hace que rastrear fallos sea casi imposible. Cuando la salida es incorrecta, necesitas reconstruir qué agentes se comunicaron con cuáles, y en qué orden.

Mitigaciones

• Definir el grafo de comunicación en tiempo de despliegue (no en tiempo de ejecución)
• Implementar detección de ciclos con límites máximos de saltos (hops)
• Usar paso de mensajes con reconocimiento explícito
• Añadir un interruptor de circuito que termine las cadenas de comunicación después de N saltos

El Marco de Decisión

Comienza con el patrón más simple que se ajuste a tu problema. La mayoría de los equipos sobre-arquitectan hacia topologías multiagente mucho antes de que el enfoque de agente único haya sido genuinamente agotado.

Paso 1: Caracteriza Tu Problema

Paso 2: Estima Tus Restricciones

Paso 3: Comienza con Agente Único

El bucle canónico de agente —un único agente con herramientas, razonamiento e iteración— sigue siendo el valor predeterminado correcto para agentes de propósito general. Arquitectura de Asistentes de IA cubre el fundamento de cinco capas sobre el que se construyen los sistemas de agente único, y vale la pena dominar ese fundamento antes de agregar la coordinación multiagente. Ten en cuenta que los sistemas multiagente también son fundamentalmente diferentes del enrutamiento multi-modelo; para este último, consulta Diseño de Sistemas Multi-Modelo, que cubre patrones secuenciales, paralelos y de conjunto aplicados a la selección de modelos en lugar de la coordinación de agentes.

Escalación a multiagente solo cuando la medición diga que debes hacerlo:

• La ventana de contexto del agente único es insuficiente
• La tarea requiere paralelismo genuino (el tiempo real importa)
• La especialización proporciona una mejora de calidad medible
• El costo del enfoque de agente único excede la sobrecarga multiagente

Para el trabajo de agentes de fondo y proactivos —programación, ejecución basada en colas, bucles de sondeo duraderos— consulta Agentes de Sondeo en Asistentes de IA: 11 Patrones de Implementación, que complementa los patrones de orquestación multiagente con la capa de programación que se encuentra debajo de ellos.

Modos de Fallo: La Taxonomía MAST

La investigación de NeurIPS 2025 (MAST — Taxonomía de Fallos de Sistemas Multiagente) analizó más de 1.600 trazas de ejecución a través de siete frameworks multiagente populares. Los fallos se distribuyen en tres categorías raíz:

1. Ambigüidad de Especificación (33% de los fallos)

Los agentes malinterpretan roles, duplican trabajo o omiten verificación porque sus instrucciones están subespecificadas.

Solución: Usa esquemas de especificación. Define descripciones de rol explícitas, límites de tareas y formatos de salida para cada agente. Los esquemas estructurados (JSON, modelos Pydantic) superan a las instrucciones en lenguaje natural.

2. Roturas de Coordinación (33% de los fallos)

Los agentes se comunican utilizando protocolos no estructurados, lo que lleva a pérdida de mensajes, condiciones de carrera y transferencias circulares.

Solución: Implementa protocolos de coordinación estructurados. Usa paso de mensajes tipado, mecanismos de reconocimiento y condiciones de terminación explícitas.

3. Brechas de Verificación (33% de los fallos)

No hay validación independiente de las salidas de los agentes. Los agentes confían en la salida de los demás sin verificación, permitiendo que los errores se propaguen.

Solución: Añade agentes de validación independientes. Usa un modelo separado o un paso de verificación para validar las salidas antes de aceptarlas. Este es el patrón maker-checker (hacedor-verificador).

Control de Costos: El Multiplicador Oculto

Los sistemas multiagente tienen una estructura de costos que escala de forma no lineal:

Estrategias de optimización de costos:

1. Usa modelos más baratos para los trabajadores. El orquestador necesita capacidad de razonamiento; los trabajadores pueden usar modelos más pequeños y rápidos.
2. Delimita los presupuestos de ejecución. Establece tokens máximos, pasos máximos y tiempo máximo por agente.
3. Implementa terminación temprana. Detén los agentes que claramente han fallado o tenido éxito.
4. Almacena en caché el contexto compartido. Usa caché de prefijos (vLLM, SGLang RadixAttention) para evitar recomputar los prompts de sistema compartidos.
5. Monitorea el costo por agente. Rastrea el consumo de tokens por agente, no solo el costo total. Identifica los agentes más costosos y optimiza primero.

Para un tratamiento más profundo de las estrategias de optimización de tokens —compresión de prompts, caché, lotificación y selección inteligente de modelos— consulta Reducir Costos de LLM: Estrategias de Optimización de Tokens. Las técnicas se aplican por igual a las llamadas de agentes individuales dentro de un sistema multiagente.

Observabilidad: Mirando Dentro de la Caja Negra

Los sistemas multiagente fallan de maneras que hacen que la depuración tradicional sea inadecuada. Cuando múltiples agentes se coordinan, los problemas se propagan a través de los límites de los agentes, las rutas de ejecución se vuelven impredecibles e identificar las causas raíz requiere visibilidad en flujos de trabajo distribuidos. Observabilidad para Sistemas de LLM cubre el stack completo de observabilidad de producción —métricas, trazabilidad distribuida, registros, SLOs y comparativas de herramientas— en el que se basan los sistemas multiagente. Para instrumentar los puntos finales de inferencia de vLLM y llama.cpp con Prometheus y Grafana, consulta Monitorear Inferencia de LLM en Producción.

Componentes Esenciales de Observabilidad

1. Trazabilidad Distribuida

Captura el grafo de interacción completo a través de todos los agentes. Las herramientas tradicionales te muestran si los componentes están funcionando, pero la depuración multiagente requiere entender cómo interactúan los componentes y dónde se rompe la coordinación.

Spans clave a trazar:

• Paso de descomposición del orquestador
• Ejecución de cada trabajador
• Paso de agregación
• Comunicación entre agentes (malla/enjambre)

2. Reproducción de Pizarrón (Blackboard Replay)

Para patrones de enjambre y malla, mantén un pizarrón versionado que pueda ser reproducido. Esto te permite reconstruir el comportamiento emergente que llevó a un fallo.

3. Atribución de Costos

Rastrea el consumo de tokens por agente, por paso. Identifica qué agentes están consumiendo recursos desproporcionados.

4. Monitoreo de Convergencia

Para patrones de enjambre y malla, monitorea si el sistema está convergiendo o divergiendo. Establece alertas para:

• Conteo de agentes excediendo los límites esperados
• Conteo de iteraciones excediendo umbrales
• Calidad de salida degradándose con el tiempo

Matriz de Soporte de Frameworks

Poniéndolo Juntos: Un Ejemplo de Producción

Los sistemas del mundo real rara vez se mapean limpiamente a un único patrón; la mayoría de los despliegues de producción combinan dos o tres enfoques, cada uno manejando la parte del flujo de trabajo para la que está mejor adaptado. Los patrones de infraestructura como Microservicios Go para Orquestación de IA/ML describen la coreografía a nivel de servicio y los patrones saga que sustentan estas arquitecturas híbridas a gran escala.

Considera un sistema de soporte al cliente que maneja consultas técnicas:

1. Triaje (Orquestador-Trabajador): Ticket entrante → el orquestador clasifica → enruta al especialista
2. Investigación (Fan-Out): El agente especialista ejecuta consultas en paralelo (base de conocimientos, historial de tickets, documentación del producto)
3. Borrador (Secuencial): Investigación → borrador de respuesta → verificación de calidad
4. Escalación (Jerárquico): Si la verificación de calidad falla, escalar al agente senior → revisión humana

Este enfoque híbrido utiliza cuatro patrones porque ningún patrón único maneja el flujo de trabajo completo de manera óptima. La clave: componer patrones, no forzar que un único patrón haga todo.

Puntos Clave

1. Comienza simple. El agente único con herramientas es el valor predeterminado. Escala a multiagente solo cuando la medición lo exija.
2. Adapta el patrón al problema. Orquestador-trabajador para descomposición, pipeline para secuencias fijas, Fan-out para paralelismo, jerárquico para escala, enjambre para exploración, malla para colaboración.
3. Espera modos de fallo. Cada patrón tiene formas específicas de romperse. Diseña mitigaciones antes de desplegar.
4. El costo escala de forma no lineal. Los sistemas multiagente multiplican el consumo de tokens. Presupuesta 2-5 veces el costo de un agente único.
5. La observabilidad es innegociable. Sin trazabilidad distribuida y atribución de costos, no puedes depurar ni optimizar sistemas multiagente.
6. Componer patrones. La mayoría de los sistemas de producción usan 2-3 patrones combinados. No fuerces que un único patrón maneje todo.

El panorama de los multiagentes está madurando rápidamente. Los equipos que tienen éxito son aquellos que entienden las compensaciones, eligen patrones deliberadamente y construyen observabilidad desde el primer día.

Preguntas Frecuentes

¿Qué es la orquestación multiagente? La orquestación multiagente es el modelo de coordinación que rige cómo múltiples agentes de IA trabajan juntos en una tarea. El patrón que elijas —nodo central, pipeline, Fan-out, jerárquico, enjambre o malla— determina la latencia de tu sistema, la tolerancia a fallos, el límite de escalabilidad y la complejidad de depuración. Cada patrón hace diferentes compensaciones y se rompe de maneras diferentes.

¿Qué patrón multiagente es el mejor para sistemas de IA de producción? La mayoría de los sistemas de producción comienzan con orquestador-trabajador. Proporciona responsabilidad clara, flujo de control depurable y costos predecibles. Escala a jerárquico cuando el número de trabajadores excede 5-8 y a Fan-out cuando las tareas paralelas independientes dominan la carga de trabajo. Enjambre y malla permanecen como patrones de nicho reservados para flujos de trabajo de exploración y colaboración estrecha entre pares, respectivamente.

¿Por qué el 40% de los pilotos multiagente fracasa? Las tres causas raíz según la taxonomía MAST de NeurIPS 2025 son la ambigüedad de especificación (los agentes malinterpretan roles u omiten pasos de verificación), las roturas de coordinación (la mensajería no estructurada lleva a pérdida de mensajes y transferencias circulares) y las brechas de verificación (no hay validación independiente de las salidas de los agentes, permitiendo que los errores se propaguen sin control). Cada categoría representa aproximadamente un tercio de todos los fallos en más de 1.600 trazas de ejecución analizadas.

¿Cuánto más cuesta un sistema multiagente que un agente único? Espera de 2 a 10 veces el costo de tokens dependiendo del patrón. Orquestador-trabajador es el más barato con 2-3x. Fan-out y enjambre son los más caros con 4-10x porque los agentes se ejecutan en paralelo y cada uno consume un presupuesto de tokens completo de forma independiente. Estos multiplicadores se compunden a gran escala: un flujo de trabajo que cuesta $0,50 en pruebas puede llegar a $50.000 por mes con 100K ejecuciones.

¿Cómo depuras un sistema multiagente cuando algo sale mal? Comienza con la trazabilidad distribuida: una traza por ejecución, con spans para cada llamada de agente, invocación de herramienta y paso de agregación. Para patrones de enjambre y malla, implementa reproducción de pizarrón para que puedas reconstruir el comportamiento emergente a partir de los registros. La atribución de costos por agente ayuda a identificar qué agentes están desencadenando fallos en cascada o gastos descontrolados antes de que alcancen la escala de producción.