Un "sistema multiagente" de IA suena a la versión avanzada de un chatbot: en vez de un solo asistente, varios agentes especializados que se reparten el trabajo y hablan entre sí. Cada vez más proveedores lo venden como el siguiente escalón natural, el que hay que dar en cuanto un agente sencillo "se queda corto". En la mayoría de las pymes con las que hablamos, ese escalón no hace falta, y montarlo antes de tiempo cambia un problema por otro peor.
Qué vende el mercado cuando dice "multiagente"
La etiqueta agrupa cosas muy distintas bajo el mismo nombre: un agente que planifica y otro que ejecuta, un agente "supervisor" que reparte tareas a agentes "trabajadores", o varios asistentes con roles (uno que atiende, otro que factura, otro que analiza) que se pasan información entre sí. La promesa comercial es siempre la misma: más agentes, más capacidad.
El problema es que un sistema con varios agentes no añade capacidad por sí solo. Añade coordinación: alguien (o algo) tiene que decidir qué agente hace qué, pasar el contexto de uno a otro sin perder nada por el camino, y resolver qué pasa cuando dos agentes llegan a conclusiones distintas sobre el mismo dato. Cada paso de coordinación es un sitio nuevo donde algo puede romperse, y ese coste existe aunque el problema de negocio no lo necesite.
La pregunta que de verdad decide: ¿comparten contexto las tareas?
Antes de mirar cuántos agentes hacen falta, hay que mirar cuántas tareas independientes hay de verdad. La confusión más habitual es tratar como "tareas distintas" lo que en realidad son pasos de una misma tarea:
| Situación | ¿Es multiagente? | Por qué |
|---|---|---|
| Validar cliente, aplicar tarifa, comprobar stock y crear el pedido | No | Son pasos de una misma cotización, en el mismo contexto. Es un agente con varias herramientas. |
| Leer una factura, emparejarla con el proveedor y contabilizarla | No | Mismo flujo, mismo dato, distintas consultas al mismo sistema. |
| Atender WhatsApp de ventas y, en paralelo, vigilar la bandeja fiscal de la asesoría | Sí, o casi | Son procesos que no comparten contexto ni dependen el uno del otro. |
| Un agente que audita facturas de la mañana y otro que llama y agenda citas comerciales | Sí | Ritmos, datos y objetivos distintos; no hace falta que se hablen entre sí. |
La regla de decisión es esta: si puedes describir el trabajo como una lista de pasos que dependen unos de otros y usan el mismo dato, es un agente con varias herramientas, no varios agentes hablando entre sí. Solo hace falta más de un agente cuando hay tareas de verdad independientes, que podrían pararse una sin afectar a la otra, y que no necesitan compartir el hilo de la conversación.
Caso real: un agente con cinco herramientas, no cinco agentes
En una distribuidora industrial con más de 50.000 productos en catálogo montamos un comercial de IA que cotiza por WhatsApp dentro del propio ERP (el caso completo está en comercial de IA en el ERP). Cada cotización exige varias comprobaciones: quién es el cliente, qué tarifa tiene, si hay stock del producto, si aplica algún descuento acordado y, si se cierra, dejarlo registrado como oportunidad y pedido en Odoo.
Un enfoque multiagente habría montado un agente "validador de cliente", otro "consultor de stock", otro "calculador de tarifa" y un "orquestador" que los coordinara. En vez de eso, montamos un único agente con cinco herramientas: consulta al cliente, consulta la tarifa, consulta el stock, aplica el descuento y crea el registro. El agente decide en qué orden llamarlas según lo que pregunta el cliente, sin tener que pasarle el contexto de la conversación a nadie más ni esperar la respuesta de otro proceso.
El resultado, ya contado en detalle en de 30 minutos a 3 por cotización, es que cada cotización pasó de unos 30 minutos de trabajo humano a resolverse en minutos, sin perder ninguna de las comprobaciones que antes hacía una persona a mano. Ningún paso de ese proceso necesitaba un agente aparte: necesitaba una herramienta más, dentro del mismo agente.
Cuándo sí hace falta más de un agente
Hay casos reales donde montar más de un agente es lo correcto, y conviene reconocerlos para no caer en el extremo contrario (meterlo todo en un único agente gigante):
- Procesos que corren en paralelo y a ritmos distintos. Un agente que contabiliza facturas entrantes durante el día y otro que llama por voz y agenda citas comerciales no tienen por qué depender el uno del otro; que uno falle no debería parar al otro.
- Dominios con reglas y permisos incompatibles. Un agente con acceso de escritura al ERP comercial y otro con acceso de lectura a la bandeja fiscal de la asesoría no deberían compartir credenciales ni contexto, aunque los use la misma empresa.
- Volumen que satura a un solo agente. Cuando un mismo tipo de tarea llega en un volumen que un agente no puede procesar con margen razonable, tiene sentido repartir instancias del mismo agente, que es distinto de repartir roles distintos entre agentes distintos.
Checklist antes de pedir (o vender) un sistema multiagente
Antes de aceptar un presupuesto que incluya "arquitectura multiagente", conviene pasar el proyecto por esta lista:
- ¿Puedo escribir el proceso completo como una lista de pasos, del primero al último, sin bifurcaciones raras?
- ¿Todos esos pasos usan el mismo dato de partida (el mismo cliente, el mismo documento, la misma conversación)?
- Si un paso falla, ¿tiene sentido que pare todo el proceso, o de verdad debería seguir otro por su cuenta?
- ¿Necesito que dos procesos corran en paralelo sin esperarse el uno al otro?
- ¿Hay permisos o sistemas distintos que no deberían mezclarse en el mismo agente?
Si las tres primeras respuestas son sí y las dos últimas no, el problema pide un agente con varias herramientas. Si alguna de las dos últimas es sí, ahí sí hay motivo real para pensar en más de un agente, y entonces la pregunta deja de ser "cuántos" y pasa a ser "cómo se reparten el trabajo sin perder de vista quién hizo qué", que es la parte que de verdad hay que diseñar bien.
La pregunta que hay que hacerle a un proveedor
Cuando un proveedor propone un sistema multiagente, la pregunta que separa un diseño real de una venta de arquitectura es simple: "¿qué parte de mi proceso necesita que dos agentes trabajen sin saber el uno del otro?". Si la respuesta describe pasos de una misma tarea, lo que hace falta no es más agentes, son más herramientas dentro de uno solo, montado sobre el sistema real del negocio en vez de una capa por encima. Es la misma idea que aplicamos en cada proyecto: primero se ordena el dato y el acceso al sistema real, y solo entonces se decide cuántos agentes hacen falta, casi siempre menos de los que parecía.
Si quieres que revisemos si tu caso pide un agente o varios, en nuestros servicios puedes ver cómo trabajamos la integración con el sistema real antes de tocar nada de IA. Y si ya tienes claro que quieres empezar, contáctanos y lo miramos juntos.
