Sistemas multiagente

Cómo distribuir una tarea entre agentes especializados bajo coordinación común: coordinador, investigador, analista, redactor y crítico.

Un agente planificador puede descomponer un objetivo amplio y ejecutar varias subtareas.

Pero aparece una nueva pregunta cuando el trabajo crece:

¿debe un mismo agente hacerlo todo?

Imaginemos un encargo jurídico complejo:

“Prepara un informe sobre un proveedor de IA, incluyendo arquitectura, datos, contrato, riesgos, evidencia y una revisión crítica del resultado.”

Un único agente podría intentar:

Eso es posible.

Pero también podemos dividir funciones entre varios agentes especializados.

Ésa es la intuición de un sistema multiagente.

Idea central

Un sistema multiagente distribuye una tarea compleja entre varios agentes o componentes especializados bajo una coordinación común.

Para esta página utilizaremos cinco funciones pedagógicas:

coordinador · investigador · analista · redactor · crítico.

La idea central no es “tener muchos agentes”.

Es combinar:

especialización + coordinación + revisión cruzada.

Del agente único al equipo de especialistas

Google utiliza la intuición de un “team of specialists”: en vez de construir un superagente que resuelva todo, se segmenta la tarea y se asignan partes a componentes más focalizados.

La analogía con un equipo humano ayuda porque muestra división del trabajo.

Deja de servir cuando suponemos que cada agente tiene identidad, comprensión o responsabilidad comparable a la de una persona.

Técnicamente, varios “agentes” pueden incluso utilizar el mismo modelo subyacente con:

  • instrucciones distintas;
  • contextos diferentes;
  • herramientas específicas;
  • objetivos locales.

Lo importante es la separación funcional.

¿Por qué dividir?

La división puede aportar varias ventajas.

Contextos más pequeños

El investigador no necesita recibir todas las instrucciones de redacción.

El redactor no necesita acceso a todas las herramientas de búsqueda.

Cada componente puede trabajar con información más focalizada.

Responsabilidades más claras

Podemos definir:

investigador = fuentes;

analista = criterios;

redactor = presentación;

crítico = control de calidad.

Esto facilita evaluar qué parte falló.

Herramientas mínimas

Cada agente puede recibir solamente las capacidades que necesita.

El investigador puede tener herramientas de lectura.

El redactor puede no necesitar permiso para buscar en repositorios sensibles.

Revisión independiente

Un crítico puede recibir el producto final junto con un estándar y buscar defectos sin haber participado en la generación inicial.

La separación puede reducir algunos sesgos de autocorrección.

Pero dividir también cuesta

Cada separación crea una interfaz.

Y cada interfaz puede fallar.

Necesitamos resolver:

  • qué información se transfiere;
  • en qué formato;
  • qué estado es autoritativo;
  • quién resuelve contradicciones;
  • qué ocurre si un agente falla;
  • cómo se evita trabajo duplicado;
  • cómo se controla costo y latencia.

Por eso un sistema multiagente no es automáticamente más confiable que uno simple.

La complejidad debe justificarse.

Arquitectura básica

Podemos representar la versión pedagógica de las clases así:

flowchart TD
    C[Coordinador]
    I[Investigador]
    A[Analista]
    R[Redactor]
    CR[Crítico]
    H[Revisión humana]

    C --> I
    I --> C
    C --> A
    A --> C
    C --> R
    R --> CR
    CR --> C
    C --> H

El coordinador mantiene el objetivo general.

Los especialistas producen resultados parciales.

El crítico revisa.

La persona interviene donde el diseño lo exige.

1. Coordinador: divide, asigna y consolida

El coordinador tiene una función diferente de la de un analista sustantivo.

Puede:

  • recibir la misión;
  • dividirla en subtareas;
  • decidir qué especialista debe intervenir;
  • preparar el contexto de cada uno;
  • esperar resultados;
  • resolver dependencias;
  • consolidar estados;
  • solicitar correcciones.

Ejemplo

Misión:

“Preparar expediente de revisión de proveedor de IA.”

El coordinador podría asignar:

Investigador:
localizar documentación, políticas y fuentes.

Analista:
aplicar criterios de riesgo a los hallazgos.

Redactor:
preparar matriz y síntesis ejecutiva.

Crítico:
verificar cobertura, evidencia y contradicciones.

El coordinador no necesita realizar cada tarea.

Su producto principal es coherencia del proceso.

Riesgo del coordinador

Si interpreta mal la misión, puede distribuir correctamente el trabajo equivocado.

Por eso el objetivo general y las fronteras deben estar bien definidos.

2. Investigador: fuentes y antecedentes

El investigador recibe una tarea más estrecha.

Por ejemplo:

“Localiza los documentos necesarios para determinar las condiciones de uso de datos del proveedor.”

Puede buscar:

  • términos;
  • DPA;
  • lista de subprocesadores;
  • política interna;
  • documentación técnica.

Su salida debería privilegiar procedencia:

fuente
versión
fragmento
relevancia
laguna

No necesita resolver todavía toda la evaluación jurídica.

Ventaja de separación

Si el investigador se concentra en evidencia, podemos evitar que una primera interpretación sesgue prematuramente la búsqueda.

No elimina el riesgo de sesgo, pero permite diseñar una función más acotada.

3. Analista: riesgos y criterios

El analista recibe evidencia ya organizada y aplica criterios.

Por ejemplo:

Evidencia:
plazo contractual de notificación = 72h

Criterio interno:
48h

Tarea:
explicar desviación, impacto y necesidad de escalamiento

La separación entre investigador y analista hace visible una frontera:

ENCONTRAR
≠
EVALUAR

El analista también necesita límites

Puede clasificar según un playbook.

No se sigue de ello que pueda adoptar la decisión institucional final.

Su salida puede ser:

“Riesgo alto según criterio X; requiere aprobación de Y.”

No:

“Contrato rechazado.”

salvo que el sistema esté explícitamente diseñado y autorizado para ello.

4. Redactor: informe y matriz

El redactor recibe resultados ya estructurados y los convierte en un producto utilizable.

Puede preparar:

  • síntesis ejecutiva;
  • matriz de riesgos;
  • preguntas para proveedor;
  • minuta de revisión;
  • borrador de comunicación.

El redactor no debería inventar contenido para “rellenar”

Un riesgo típico de la generación es completar huecos para producir un texto fluido.

En un sistema multiagente podemos exigir que el redactor utilice solamente objetos entregados por etapas anteriores:

hallazgo
+
evidencia
+
criterio
+
estado

Si falta una pieza, debe marcarla como pendiente.

Esto convierte el redactor en una capa de presentación, no en una fuente silenciosa de hechos nuevos.

5. Crítico: objeciones y calidad

El crítico busca defectos en el producto.

Puede revisar:

  • ¿se cubrieron todas las materias?;
  • ¿cada hallazgo tiene evidencia?;
  • ¿la evidencia realmente sostiene la inferencia?;
  • ¿existen contradicciones entre secciones?;
  • ¿se omitió una fuente relevante?;
  • ¿hay afirmaciones demasiado categóricas?;
  • ¿la recomendación respeta los límites de autoridad?

Crítico no equivale a juez infalible

El crítico también puede equivocarse.

Su valor depende de que reciba:

  • criterios claros;
  • evidencia suficiente;
  • una función distinta de la del generador.

Un segundo agente que sólo diga:

“Revisa si esto está bien”

puede aportar poco.

Un crítico con checklist explícito es más evaluable.

Revisión cruzada

La arquitectura multiagente puede permitir que distintos componentes cuestionen resultados.

Ejemplo:

INVESTIGADOR
"Encontré cláusula 9.2."

ANALISTA
"La cláusula se desvía del estándar."

CRÍTICO
"La comparación utiliza la política 2025; existe versión 2026."

COORDINADOR
"Reabrir investigación con versión vigente."

Aquí aparece una ventaja real: la crítica no se limita al texto final.

Puede modificar la trayectoria.

Un caso completo: revisión de proveedor de IA

Misión

“Preparar antecedentes para decisión humana sobre contratación.”

Coordinador

Descompone:

A. documentación
B. datos
C. contrato
D. seguridad
E. síntesis
F. control de calidad

Investigador

Encuentra:

  • contrato;
  • DPA;
  • términos de IA;
  • política interna vigente;
  • cuestionario de seguridad.

Marca:

lista de subprocesadores = no localizada.

Analista

Aplica criterios:

Datos: riesgo medio
Seguridad: pendiente
Responsabilidad: riesgo alto
Continuidad: riesgo medio

Cada clasificación conserva evidencia.

Redactor

Prepara una matriz con:

  • hallazgo;
  • fuente;
  • criterio;
  • impacto;
  • estado;
  • pregunta.

Crítico

Detecta dos problemas:

  1. el informe afirma que no existen subprocesadores, aunque la evidencia sólo dice que la lista no fue encontrada;
  2. la recomendación propone “aprobar con condición” sin que exista todavía revisión de seguridad.

Coordinador

Reabre las subtareas correspondientes y no permite cierre.

El valor del sistema está en la división de funciones y la capacidad de corregir el producto antes de presentarlo como completo.

Secuencial versus paralelo

Algunas subtareas dependen unas de otras.

Por ejemplo:

investigar → analizar → redactar → criticar

Otras pueden ejecutarse en paralelo:

          ┌→ privacidad
coordinador ├→ seguridad
          └→ contrato

La elección afecta:

  • tiempo;
  • costo;
  • coherencia;
  • necesidad de sincronización.

No profundizaremos todavía en patrones de diseño porque la página siguiente está dedicada precisamente a router, planner, worker, critic, evaluator y human gate.

Aquí sólo necesitamos reconocer que multiagente no implica una única topología.

¿Un agente distinto significa un modelo distinto?

No.

Podemos tener:

Investigador → mismo modelo, prompt A, tools A
Analista → mismo modelo, prompt B, tools B
Redactor → mismo modelo, prompt C, sin tools sensibles
Crítico → mismo modelo, prompt D, criterios de revisión

La especialización puede surgir de:

  • instrucciones;
  • contexto;
  • herramientas;
  • permisos;
  • objetivo local;

sin cambiar el modelo base.

También podríamos usar modelos distintos cuando costo, latencia o capacidades lo justifiquen.

La arquitectura y el modelo son decisiones separables.

Cuándo puede tener sentido un sistema multiagente

Puede ser razonable cuando:

  • la tarea tiene funciones claramente separables;
  • cada función requiere contexto o herramientas distintas;
  • existe valor en revisión cruzada;
  • el trabajo puede paralelizarse;
  • un único agente se vuelve difícil de evaluar;
  • la coordinación puede definirse de forma observable.

Cuándo puede ser innecesario

Puede ser excesivo cuando:

  • la tarea es simple;
  • las subtareas son muy dependientes;
  • el costo de coordinación supera el beneficio;
  • un workflow sencillo resuelve el problema;
  • la revisión humana ya cumple adecuadamente la función crítica;
  • no existe un criterio claro para dividir responsabilidades.

El riesgo del “teatro multiagente”

Es posible construir cinco agentes que simplemente se pasan texto sin una razón funcional.

La arquitectura parece sofisticada, pero añade:

  • llamadas;
  • latencia;
  • costo;
  • puntos de error;

sin mejorar necesariamente calidad.

La pregunta correcta es:

¿qué problema resuelve la separación de este agente respecto de los demás?

Si no existe una respuesta clara, probablemente la división es ornamental.

Conflictos entre agentes

Un investigador puede concluir:

“No existe evidencia suficiente.”

Y un redactor puede intentar completar un informe igualmente.

O dos analistas pueden clasificar el mismo riesgo de forma diferente.

El sistema necesita una política para conflictos:

  • pedir nueva evidencia;
  • ejecutar revisión crítica;
  • aplicar prioridad de fuente;
  • escalar a una persona;
  • mantener el estado como no resuelto.

No deberíamos resolver contradicciones ocultándolas mediante una síntesis fluida.

En trabajo jurídico, preservar desacuerdo puede ser más correcto que fabricar consenso.

La coordinación también necesita evidencia

No sólo debemos observar qué produjo cada agente.

También puede importar:

  • quién recibió cada subtarea;
  • qué contexto se le entregó;
  • qué resultado devolvió;
  • qué versión fue utilizada;
  • qué corrección se pidió;
  • qué producto se consolidó.

Cuanto más distribuido sea el sistema, mayor importancia adquiere la reconstrucción de la trayectoria.

La observabilidad tendrá una página propia más adelante.

Qué debes recordar

Un sistema multiagente no es simplemente un conjunto de chatbots hablando entre sí.

Es una arquitectura donde una tarea se distribuye entre componentes especializados bajo coordinación común.

La versión pedagógica de esta página utiliza cinco roles:

  • coordinador: divide, asigna y consolida;
  • investigador: busca fuentes y antecedentes;
  • analista: aplica riesgos y criterios;
  • redactor: convierte resultados en un producto;
  • crítico: busca objeciones, errores y omisiones.

La ventaja potencial es especialización y revisión cruzada.

El costo es coordinación adicional.

El problema que todavía queda abierto

Ya sabemos qué significa dividir trabajo entre varios agentes.

Pero todavía no hemos estudiado formas recurrentes de organizar esa división.

¿Cómo enrutar tareas?

¿Cómo separar planificación y ejecución?

¿Cómo introducir crítica?

¿Cómo evaluar?

¿Dónde colocar una aprobación humana?

La siguiente página introduce los patrones de diseño que permiten responder esas preguntas sin inventar una arquitectura nueva desde cero en cada proyecto.

Back to top