Saltar al contenido
Condictor Studio
IA
IA

Sistemas multiagente: cuándo merecen la pena y cuándo son excesivos

Cuándo dividir el trabajo entre agentes mejora el resultado y cuándo solo aumenta el coste: patrones, criterios de decisión y costes.

Aprox. 6 min de lecturapor
Un sistema ordenado de cuatro nodos alrededor de un núcleo junto a una red enmarañada, separados por un límite coral

Un sistema multiagente es un conjunto de agentes de IA que colaboran, realizan de forma autónoma los objetivos que se les asignan y se transfieren resultados. Sin embargo, no toda cadena de varias llamadas a un modelo es un sistema multiagente: si todos los pasos y transiciones están definidos de antemano, es más preciso hablar de un workflow. Esta división solo tiene sentido cuando la medición demuestra una ventaja frente a una solución más sencilla.

La distinción es práctica. Anthropic describe un workflow como un recorrido por caminos definidos y los agentes como sistemas en los que el modelo dirige dinámicamente el proceso y el uso de herramientas. También recomienda empezar por la solución más simple y añadir complejidad solo tras evaluar los resultados. Fuente: Building effective agents — Anthropic.

Escribimos sobre ello de primera mano, porque así se realiza nuestro propio trabajo: destilación de materiales por varios agentes en paralelo, panel de borradores independientes con un juez que decide y auditoría adversarial que comprueba el resultado. Es un sistema que funciona, no una diapositiva; lo describimos en el laboratorio.

Cuándo deja de bastar un agente

Cuatro señales que conviene comprobar al evaluar un agente individual:

  1. La tarea tiene etapas de naturaleza distinta. Recopilar datos, analizar, redactar y comprobar pueden requerir instrucciones, herramientas y criterios de calidad diferentes.
  2. La instrucción es difícil de mantener. Cuando las reglas para muchos casos empiezan a entrar en conflicto, separar responsabilidades puede simplificar las pruebas.
  3. Hace falta control independiente. Un verificador separado puede detectar errores si recibe criterios medibles y no basa la evaluación únicamente en la opinión de otro modelo.
  4. El resultado es inestable. El mismo caso se resuelve unas veces bien y otras mal, sin una causa identificable.

Cuatro patrones de orquestación

1. Cadena (secuencia)

El modelo o componente A realiza un paso y entrega el resultado a B. Normalmente es un workflow, no un sistema multiagente. Es útil en procesos de orden fijo: extraer datos, verificar el formato e introducir el resultado.

2. División por roles con coordinador

Un coordinador reparte tareas entre especialistas y compone el resultado. Este patrón funciona cuando no se puede prever qué subtareas serán necesarias. Los roles deben tener límites claros, formato de entrega y criterio de finalización; solapar parcialmente los roles puede ser deliberado si proporciona una comparación independiente.

3. Trabajo paralelo con decisión

Varios agentes realizan la misma tarea de forma independiente y un rol separado compara los resultados y elige o combina. Aumenta el número de llamadas, pero puede revelar divergencias en tareas con un buen criterio de decisión. El mero acuerdo entre modelos no prueba la corrección, por lo que el resultado debe seguir evaluándose con casos de referencia. Utilizamos este patrón al planificar este sitio.

4. Bucle ejecutor-verificador

Uno realiza la tarea y otro la comprueba con una lista de criterios y la devuelve para corregirla. El bucle tiene sentido cuando el verificador puede señalar un error concreto y un límite de intentos evita vueltas improductivas. En tareas con una prueba inequívoca —por ejemplo, validación de esquema o ejecución de tests— puede ser especialmente eficaz. Lo desarrollamos en alucinaciones de IA.

Cuatro esquemas pequeños uno junto a otro: una cadena de flechas, una estrella con nodo central, varios carriles paralelos que convergen y un bucle cerrado de dos campos.
Cuatro patrones de orquestación: cadena, coordinador con roles, trabajo paralelo con decisión y bucle de verificación.

Por qué pagas realmente

Una lista honesta, porque esta clase de soluciones es costosa:

  • Más llamadas al modelo. Cuatro roles implican al menos varias operaciones separadas, pero la factura no tiene que crecer linealmente: los roles pueden utilizar modelos distintos y contextos de longitudes diferentes.
  • Trabajo de orquestación. Transferencias entre roles, manejo de casos en que un rol no entrega resultado y límites de tiempo y coste.
  • Diagnóstico más difícil. Cuando el resultado es malo, hay que determinar qué rol falló. Sin registros de entradas, salidas y transferencias, el diagnóstico queda muy limitado.
  • Riesgo de bucles. Dos roles que se devuelven una tarea pueden seguir hasta agotar el presupuesto. Hacen falta límites de intentos, tiempo y coste, además de una condición de detención segura.

Nuestros rangos para agosto de 2026 son: piloto de un sistema multiagente para un proceso, 15.000–40.000 PLN netos; sistema de producción con integraciones, 40.000–150.000 PLN netos; mantenimiento y evaluación, 3.000–8.000 PLN netos/mes.

Cuándo es un exceso de forma

Lo decimos claramente, porque en este tema es fácil vender demasiado:

  • Cuando el proceso tiene un único paso bien definido. Primero conviene comprobar la clasificación de un correo como una única tarea; los roles adicionales solo tienen sentido si mejoran el resultado medido.
  • Cuando los pasos son conocidos y fijos. Es una automatización, quizá con una llamada de modelo. Barata y predecible.
  • Cuando no dispones de un conjunto para evaluar la calidad. Sin medición no sabrás si añadir un tercer rol ayudó. Pagarás por una impresión.
  • Cuando nadie mantiene el primer agente. Más roles aumentan las transferencias, alertas y casos que diagnosticar; primero hay que establecer una persona responsable y un proceso de respuesta.

Regla práctica: empieza con un agente y añade roles allí donde la medición muestre una debilidad. No al revés. Los sistemas multiagente diseñados «por si acaso» son más caros y más difíciles de reparar que los que crecen a partir de un problema real.

Cómo lo implantamos

Este es el orden que seguimos:

  1. Mapa del proceso por roles. Qué es una etapa separada y qué solo parece serlo.
  2. Diseño de la orquestación. Orden, transferencias, puntos de control y límites.
  3. Implementación con registro de cada etapa. Sin él no hay diagnóstico.
  4. Bucles de verificación donde el riesgo es alto.
  5. Evaluación con un conjunto de casos reales, ejecutada después de cada cambio.
  6. Despliegue en producción con supervisión y un límite estricto de costes.

El paso de demostración a producción es una etapa independiente: exige límites de coste y tiempo, gestión de errores, control de permisos, monitorización y procedimiento de toma de control manual. Sin estas protecciones, incluso un prototipo prometedor no está preparado para gestionar un proceso real.

Preguntas frecuentes

¿Todos los agentes deben usar el mismo modelo?

No. Un rol rutinario puede funcionar con un modelo más barato y uno que requiera razonamiento complejo con otro más potente. No obstante, hay que confirmarlo mediante evaluación, porque un modelo más barato puede aumentar las correcciones o los errores; describimos los criterios en qué es un LLM.

¿Cuántos roles tienen sentido?

Los que justifiquen los resultados de las pruebas. No existe un número universalmente correcto. Cada rol adicional debe mejorar una métrica concreta en el conjunto de referencia lo suficiente para justificar el coste y el mantenimiento más complejo.

¿Hace falta una persona?

En procesos de alto riesgo, una persona debe aprobar acciones con consecuencias significativas o casos fuera del alcance probado. El límite concreto depende de la reversibilidad, los requisitos legales, la calidad de la medición y la posibilidad de detenerse con seguridad.


Construimos sistemas multiagente para nosotros mismos cada día, por lo que podemos mostrar un ejemplo en funcionamiento, no una idea. Consulta sistemas multiagente y nuestros workflows de investigación con IA, o descríbenos un proceso que requiera varias etapas.

Maciej Szukalski

Autor

Maciej Szukalski

Fundador de Condictor · arquitecto de sistemas · investigación y desarrollo

Diseña y desarrolla productos digitales desde 2014. Se especializa en arquitectura, investigación y aplicaciones con capas de automatización e inteligencia.

¿Tienes un problema que resolver?

Veamos cuál es el mejor primer paso

Describe tu situación en unas frases. Volveremos con preguntas o una propuesta concreta para el siguiente paso.

Describe tu tema

Ver también

Todos los artículos