Cómo orquestar 200 agentes de IA sin perder control

Escalar de cinco agentes de IA a doscientos no es un problema de potencia: es un problema de coordinación. Cualquier equipo puede desplegar decenas de agentes en semanas. Lo difícil �?"y lo que separa a una operación que se vuelve más rápida de una que se vuelve más caótica�?" es lograr que esos agentes trabajen como un sistema y no como doscientas voces hablando a la vez. Este artículo desarma la orquestación en las cuatro capas que la hacen sostenible: selección, contexto compartido, revisión y trazabilidad. Cada una resuelve un modo de fallo que aparece justo cuando dejas de tener pocos agentes y empiezas a tener muchos.

El problema no es tener agentes, es coordinarlos

La conversación sobre agentes de IA casi siempre empieza por el lugar equivocado: cuántos agentes tienes, qué modelo usan, qué tan capaces son. Pero en la práctica, el cuello de botella nunca es la cantidad de agentes ni su inteligencia individual. Es la coordinación. Un solo agente bien diseñado resuelve una tarea. Doscientos agentes sin gobierno resuelven doscientas tareas de formas distintas, se contradicen entre sí, repiten trabajo y, cuando algo sale mal, nadie puede decir cuál fue el responsable.

Considera un caso ilustrativo, representativo de lo que vemos en el mercado: una PyME que automatiza su operación comercial con IA. Empieza con tres agentes �?"uno responde WhatsApp, otro califica prospectos, otro redacta propuestas�?" y funciona de maravilla. Envalentonada, escala a cincuenta agentes en pocos meses: uno por canal, uno por vertical, uno por tipo de documento. Y el sistema, que antes volaba, empieza a arrastrarse. En un escenario así de descoordinado es fácil que el tiempo de respuesta se dispare �?"modelar un aumento del orden de 400% no es exagerado�?" porque cada tarea rebota entre agentes que no saben quién debe atenderla, y la tasa de error trepa a niveles del orden de 60% en tareas multi-agente, porque cada uno parte de supuestos distintos sobre el mismo cliente.

El síntoma es siempre el mismo: los agentes son buenos por separado y el conjunto es malo. No hay un solo agente al que puedas culpar. Es la ausencia de una capa de orquestación. Anthropic lo documenta bien en su guía sobre construir agentes efectivos: la mayoría de los sistemas que fallan no lo hacen por falta de capacidad del modelo, sino por exceso de complejidad no gobernada (Anthropic �?" Building Effective Agents ↗). La solución no es un modelo más grande. Es una arquitectura que decida quién hace qué, con qué información, revisado por quién y con qué rastro. Eso es la orquestación, y se construye con las cuatro capas que siguen. Si quieres el marco conceptual completo antes de entrar en detalle, revisa nuestra guía de sistemas multiagente en producción.

Selección: el agente correcto en menos de dos segundos

La primera capa es la más subestimada: dado un pedido, ¿qué agente lo atiende? Con tres agentes la respuesta es obvia. Con doscientos, elegir a mano es imposible y elegir mal es carísimo: mandas una tarea trivial a un agente de razonamiento profundo y pagas diez veces de más, o mandas una tarea compleja a un agente ligero y entregas basura. La selección correcta, hecha en menos de dos segundos, es lo que mantiene el sistema rápido y económico a escala.

El mecanismo es un enrutador semántico. En lugar de reglas rígidas del tipo "si el texto contiene 'factura', ve al agente contable", el enrutador convierte el pedido en un vector y lo compara contra un catálogo de agentes descritos también como vectores. Cada agente del catálogo declara tres cosas: su especialidad, su latencia típica y su costo por ejecución. El enrutador no solo pregunta "¿quién sabe de esto?", sino "¿quién resuelve esto al menor costo dentro del tiempo aceptable?".

Un ejemplo concreto. Llega la tarea "redactar un email de seguimiento para un prospecto que no respondió". ¿Va al agente de Email Copy o al de Marketing Lead? ¿En paralelo o en secuencia? El enrutador razona: es un email transaccional corto, no una estrategia de campaña, así que va a Email Copy �?"bajo costo, baja latencia�?" de forma directa. Pero si el pedido fuera "diseña la secuencia de nurturing de tres correos para reactivar prospectos fríos", el enrutador encadena Marketing Lead (define la estrategia) y luego Email Copy (redacta cada pieza) en secuencia, porque el segundo depende del primero. Cuando dos subtareas son independientes �?"traducir a inglés y a portugués el mismo texto�?" las despacha en paralelo para no acumular latencia.

Esta lógica de "el experto adecuado para cada entrada" tiene raíces en las arquitecturas de mezcla de expertos que popularizaron los grandes modelos, donde una red de enrutamiento activa solo a los especialistas relevantes por token (OpenAI �?" Training large neural networks ↗). La diferencia es que aquí los "expertos" son agentes completos con herramientas, no capas de una red. La siguiente tabla muestra cómo se ve el criterio de selección para diez tareas comunes:

En un sistema real, esta selección no vive en abstracto: cada decisión del enrutador queda registrada. En el Victor IA Tracker ↗ vemos, por cada tarea, qué agente se eligió, por qué, cuánto tardó y cuánto costó. Eso permite afinar el catálogo con el tiempo: si un agente resulta más caro de lo que aporta, se degrada o se retira, y el enrutador deja de mandarle trabajo.

Contexto compartido: una sola memoria de trabajo

El segundo modo de fallo a escala es la amnesia colectiva. El Agente A escribe una propuesta para un cliente. Media hora después, el Agente B tiene que redactar el contrato para ese mismo cliente. Si B no sabe nada de lo que hizo A, le pides al cliente que repita todo, o peor, el contrato contradice la propuesta. Multiplica eso por doscientos agentes y cientos de tareas diarias: el sistema se vuelve incoherente no por falta de inteligencia, sino por falta de memoria común.

La tentación ingenua es pasar la transcripción completa de A a B. No funciona a escala: es lento, caro �?"cada token de contexto se paga�?" y ruidoso, porque B recibe mil detalles irrelevantes para encontrar los tres que importan. La respuesta correcta es una memoria de trabajo compartida basada en una base de datos vectorial. Cada agente escribe lo que produce como embeddings indexados; cuando otro agente arranca una tarea, recupera solo los fragmentos semánticamente relevantes para ese cliente y esa tarea. B no lee toda la conversación de A: recupera "la propuesta que A escribió para este cliente incluía estos tres compromisos y este precio", y con eso redacta un contrato coherente sin que nadie se lo explique.

Este patrón es el que permite que un sistema de Fortune 500 pase de "agentes confusos" a "agentes coherentes". El cambio no fue poner modelos más capaces, sino darles una fuente de verdad común y recuperación selectiva. Anthropic describe una arquitectura análoga en su sistema multiagente de investigación, donde un orquestador reparte subtareas y los subagentes comparten hallazgos a través de una memoria común en lugar de reenviarse conversaciones completas (Anthropic �?" Multi-agent research system ↗).

La clave técnica es la selectividad: recuperar poco y relevante, no todo. Un buen sistema de contexto compartido mide qué tan a menudo un agente tuvo que "preguntar de nuevo" algo que ya estaba en la memoria; si esa tasa sube, la recuperación está fallando. Profundizamos en el diseño de este componente �?"chunking, embeddings, ventanas de recuperación y expiración de memoria�?" en nuestro artículo sobre memoria semántica compartida.

Revisión: la capa que firma el entregable

Ningún sistema serio deja que un agente entregue directamente al cliente sin una revisión. La tercera capa son los agentes de QA: agentes cuya única función es revisar el trabajo de otros agentes antes de que salga. No producen; verifican. Y verifican tres cosas distintas que conviene no mezclar: formato (¿el entregable tiene la estructura pactada?), exactitud (¿los datos, cifras y nombres son correctos?) y coherencia (¿contradice algo que ya dijimos a este cliente?).

El comportamiento por defecto de un agente de QA es el rechazo, no la aprobación. Si el entregable falla en cualquiera de las tres dimensiones, no se corrige a la fuerza ni se deja pasar con una advertencia: se rechaza y se re-enruta. Aquí la capa de revisión se conecta con la de selección. Un rechazo por exactitud numérica se re-enruta al especialista numérico; un rechazo por coherencia con el historial del cliente se devuelve al agente original junto con el fragmento de contexto que violó. El sistema no "tira" el trabajo: lo recicla hacia quien puede arreglarlo.

El impacto es medible y grande. En un flujo sin QA automatizado, es realista modelar una tasa de error cercana al 12% en entregables multi-agente �?"cifras mal copiadas, formatos inconsistentes, promesas contradictorias�?". Con una capa de QA que rechaza y re-enruta, ese error puede caer por debajo del 1%, porque ningún entregable sale sin pasar por un revisor cuya única tarea es buscar fallos. En retorno, es una de las inversiones más baratas del sistema: un agente de QA es ligero comparado con el costo de un error entregado a un cliente. Es el mismo principio de "verificación antes de aprobación" que aplicamos en nuestro harness de ingeniería.

Trazabilidad: auditar qué hizo cada agente

La cuarta capa es la que casi todos posponen y todos terminan necesitando. Cuando tienes doscientos agentes tomando decisiones, la pregunta "¿por qué el sistema respondió esto?" debe tener respuesta en segundos, no en semanas. Eso exige que cada ejecución quede registrada con su huella completa: qué entrada recibió el agente, qué modelo usó, qué herramientas invocó, cuánto tardó, cuánto costó y qué salida produjo.

Esta bitácora no es un lujo de cumplimiento: es la materia prima de todo lo demás. Alimenta el dashboard operativo �?"dónde se acumula la latencia, qué agentes consumen el presupuesto, dónde se concentran los rechazos de QA�?" y permite mejorar el sistema con datos en lugar de intuiciones. Sin trazabilidad, optimizar doscientos agentes es adivinar. Con ella, 'ves con claridad que una fracción pequeña de los agentes concentra la mayor parte del costo.'

El caso más contundente es el regulatorio. Imagina que un cliente en un sector supervisado �?"financiero, salud, legal�?" recibe una auditoría y le piden justificar cómo se generó un documento específico hace tres meses. Sin trazabilidad, esa respuesta cuesta semanas de arqueología digital y a menudo termina en "no lo sabemos". Con una bitácora por ejecución, la misma pregunta se resuelve en minutos: aquí está la entrada, el agente que la procesó, el modelo, las fuentes que consultó y la revisión de QA que la aprobó. La trazabilidad convierte una crisis regulatoria en una consulta de base de datos. En sistemas de alto volumen conviene además rastrear el consumo por token y por modelo; desarrollamos ese enfoque en telemetría de tokens, costos y modelos.

Arquitectura de ejemplo

Las cuatro capas anteriores se combinan en un flujo único, el que muestra el diagrama al inicio de este artículo. Vale la pena recorrerlo de principio a fin porque el orden importa: cada capa presupone la anterior.

Una tarea entrante llega al sistema. No va directo a ningún agente: primero pasa por el enrutador semántico, que la vectoriza, la compara con el catálogo y decide a qué agente �?"o a qué cadena de agentes�?" enviarla, en paralelo o en secuencia según las dependencias. El agente o agentes seleccionados no trabajan a ciegas: consultan el contexto compartido, esa memoria vectorial común donde vive todo lo que el sistema sabe sobre ese cliente y esa tarea, y recuperan solo lo relevante. Producen su entregable y lo pasan a la capa de QA, que lo revisa en formato, exactitud y coherencia; si falla, rebota al enrutador para re-asignación; si pasa, se firma y sale como entregable. Y en todo el recorrido, cada paso deja su huella en la bitácora de trazabilidad.

Lo elegante es que la arquitectura es la misma con tres agentes o con doscientos. No cambias el diseño al escalar; solo crece el catálogo que consulta el enrutador y el volumen que atraviesa las capas. Este patrón de orquestador y subagentes es hoy el estándar de facto en producción porque separa la coordinación (enrutador, contexto, QA, bitácora) de la ejecución (los agentes), y esa separación es lo que permite crecer sin caos.

ROI real: tiempo, costo y errores

La orquestación no se justifica por elegancia técnica sino por retorno, y el retorno se mide en tres monedas: tiempo ahorrado, costo reducido y errores evitados. Modelemos un escenario ilustrativo pero plausible, del tipo que se observa en una operación mediana que pasa de agentes descoordinados a un sistema orquestado.

Tiempo. Antes de orquestar, una tarea que cruza varios agentes rebota, se repite y espera; un ciclo que tomaba horas. Con enrutamiento correcto y ejecución en paralelo donde aplica, ese mismo ciclo baja a minutos. No es magia: es eliminar el trabajo repetido (el contexto compartido evita re-explicar) y el trabajo mal asignado (el enrutador evita el rebote). 'Un ahorro de tiempo sustancial en tareas multi-agente es un objetivo razonable.', no una promesa de marketing.

Costo. Aquí está la ganancia menos obvia. Sin selección por costo, todo se resuelve con el agente más capaz "por si acaso", y pagas de más en cada tarea trivial. Con un enrutador que asigna la tarea más barata capaz de resolverla, el costo por tarea cae de forma sostenida. La trazabilidad amplifica este efecto: al ver que un pequeño grupo de agentes concentra el gasto, se optimiza justo donde duele. Los reportes de industria coinciden en que la brecha entre las empresas que capturan valor con IA y las que no está cada vez más en la operación �?"gobierno, medición, reingeniería de procesos�?" que en la tecnología en sí (McKinsey �?" The State of AI ↗).

Errores. La capa de QA convierte errores caros �?"un dato equivocado enviado a un cliente�?" en rechazos internos baratos. 'Reducir la tasa de error a una fracción mínima no solo evita costos de corrección; protege la confianza.'; protege la confianza, el activo más difícil de recuperar. Los analistas proyectan que la gobernanza de agentes será un foco de inversión empresarial en los próximos años, porque el riesgo de agentes sin control ya es visible en el balance (Gartner �?" Newsroom ↗). La orquestación se paga sola: construir las cuatro capas cuesta una fracción de operar doscientos agentes sin ellas.

Roadmap: de 50 a 200 agentes sin caos

Escalar no es encender agentes; es endurecer capas. Este es el camino que recomendamos para pasar de una decena de agentes a doscientos sin que el sistema colapse en el intento.

Fase 1 �?" Cimentar el enrutador (agentes 1 a 30). Antes de sumar agentes, construye el catálogo y el enrutador semántico. Cada agente nuevo se registra con su especialidad, latencia y costo. Si el enrutador no existe, cada agente que agregas multiplica el desorden. Regla: ningún agente entra en producción sin ficha de catálogo.

Fase 2 �?" Instalar el contexto compartido (agentes 30 a 80). En este rango la amnesia colectiva empieza a doler. Es el momento de la memoria vectorial común y la recuperación selectiva. Migra a los agentes existentes para que escriban y lean de la memoria compartida en lugar de pasarse transcripciones. Mide la tasa de "preguntas repetidas" como indicador de salud.

Fase 3 �?" Blindar con QA (agentes 80 a 140). Con decenas de agentes produciendo, ningún entregable debe salir sin revisión. Despliega agentes de QA por dominio �?"numérico, legal, de coherencia�?" y conecta sus rechazos al enrutador para el re-enrutamiento automático. Aquí la tasa de error debe empezar a desplomarse.

Fase 4 �?" Industrializar la trazabilidad (agentes 140 a 200). A esta escala, operar sin bitácora completa es negligente. Cada ejecución registrada, dashboard en vivo, alertas por costo y latencia anómalos. La trazabilidad deja de ser un reporte y se vuelve el sistema nervioso de la operación. El escalamiento de esta infraestructura �?"despliegue, versionado de agentes, rollback�?" es un problema de ingeniería de plataforma; lo abordamos en nuestro artículo sobre DevOps y pipelines para sistemas de IA.

El error más común es invertir el orden: sumar los doscientos agentes primero y construir las capas después, apagando incendios. Se puede, pero cuesta el triple y quema la confianza del equipo en el camino. Las capas primero; los agentes después.

Preguntas frecuentes

Cerramos con las preguntas técnicas que más nos hacen quienes están a punto de escalar su operación de agentes.

¿Necesito doscientos agentes de verdad o basta con unos pocos muy capaces?

Depende de la diversidad de tareas, no del volumen. Si tu operación hace pocas cosas repetidas, unos pocos agentes bien afinados bastan. La especialización en muchos agentes se justifica cuando las tareas son heterogéneas: distintos dominios, idiomas, niveles de riesgo. Muchos agentes especializados y baratos suelen superar a pocos agentes generalistas y caros, siempre que exista un enrutador que sepa a quién mandar cada cosa.

¿Qué pasa si el enrutador se equivoca al seleccionar?

Para eso existe la capa de QA. Un enrutamiento incorrecto produce un entregable que falla en formato, exactitud o coherencia; QA lo rechaza y lo devuelve para re-asignación. Además, cada error de enrutamiento queda en la bitácora y sirve para reentrenar el catálogo. El sistema no depende de que el enrutador acierte siempre; depende de que los errores se detecten y se corrijan barato.

¿Cómo evito pagar de más al compartir contexto entre agentes?

No pasando transcripciones completas. La memoria compartida basada en recuperación vectorial entrega solo los fragmentos relevantes para cada tarea, no todo el historial. Eso mantiene bajo el costo por token y reduce el ruido. La métrica a vigilar es cuántos tokens de contexto consume cada tarea: si crece sin que mejore la calidad, tu recuperación es demasiado amplia.

¿La capa de QA no duplica el costo del sistema?

No, porque los agentes de QA son ligeros: verificar es mucho más barato que producir. Un revisor consume una fracción de lo que consume el agente que generó el entregable, y evita el costo �?"mucho mayor�?" de un error enviado al cliente. En retorno, es la capa más rentable de las cuatro.

¿Cuánto tarda implementar una orquestación así?

Las cuatro capas no se construyen de golpe; se instalan por fases conforme escalas, como describe el roadmap. Una operación puede tener el enrutador y el contexto compartido funcionando en semanas, y madurar QA y trazabilidad a lo largo de los meses siguientes, en paralelo al crecimiento del catálogo de agentes. Lo importante es no invertir el orden: capas primero, volumen después.