Sistemas multi-agente para empresas: cuándo usarlos

Un patrón conocido: una empresa dedica meses a un chatbot de atención al cliente. El bot funciona bien en demos, pero en producción inventa políticas, da precios incorrectos o manda al cliente al siguiente paso equivocado. No siempre. Solo lo bastante como para que soporte deje de fiarse.

El modelo quizá no sea el problema principal. Puede que un solo agente esté intentando hacer demasiados trabajos: consultar catálogo, verificar stock, calcular precios con descuentos, gestionar devoluciones y responder dudas generales. Demasiado contexto, demasiadas herramientas, demasiadas reglas que se pisan.

Dividir el trabajo puede ayudar. También puede hacer el sistema más lento, más difícil de depurar y más frágil. La decisión debería salir de fallos observados, no del atractivo de una arquitectura más compleja.

Decisión rápida

Usa arquitectura multi-agente cuando separar dominios, herramientas, permisos o pasos de revisión haga el flujo más controlable. Evítala cuando un solo agente con mejores herramientas, mejor recuperación y mejor evaluación pueda hacer el trabajo.

La palabra clave es control. Si añadir agentes solo añade mensajes entre modelos, probablemente no estás mejorando la arquitectura.

Qué es un sistema multi-agente sin humo

Piensa en un hospital. No hay un médico que haga todo. Hay especialistas: cardiólogos, radiólogos, cirujanos. Y hay triaje, que decide a quién enviar cada paciente.

Un sistema multi-agente funciona parecido. En lugar de un LLM gigante con un prompt enorme, tienes agentes especializados que dominan tareas concretas. Y algo que coordina quién hace qué.

Los componentes típicos:

Orquestador: Recibe la petición, decide qué agente o agentes necesitan actuar, y combina los resultados. No hace el trabajo real, solo dirige tráfico.

Agentes especializados: Cada uno tiene su propio prompt, sus propias herramientas, acceso a datos específicos. El agente de inventario sabe consultar la base de stock. El de precios tiene acceso a la API de pricing. Cada uno es experto en su dominio.

Memoria compartida: Un sitio donde los agentes dejan información para otros. El agente de catálogo encuentra el producto, el de precios añade el coste, el de envío calcula la entrega. No se hablan directamente, pero comparten contexto.

Herramientas: Funciones que los agentes pueden ejecutar. Llamar APIs, consultar bases de datos, enviar correos. Sin herramientas, un agente es solo un generador de texto.

Cuándo NO usar multi-agentes

Esto es lo que nadie te cuenta: la investigación reciente sugiere que en muchos casos un solo agente bien configurado supera a sistemas multi-agente.

Un estudio de 2025 encontró que en entornos con más de 10 herramientas, los sistemas multi-agente sufren una penalización de eficiencia de entre 2x y 6x comparado con agentes individuales. Eso es bastante.

Los de Cognition, los que crearon Devin, lo dicen claro: en 2025, ejecutar múltiples agentes en colaboración resulta en sistemas frágiles. Su recomendación es empezar con un agente lineal donde el contexto sea continuo.

No uses multi-agentes cuando:

La tarea se puede resolver en un solo paso lógico. Resumir documentos, clasificar tickets, extraer datos de facturas. Un solo agente bien configurado con buen RAG es suficiente.

Tienes muchas herramientas. Suena raro, pero con más de 10 herramientas la coordinación entre agentes puede añadir más coste y fragilidad de lo que compensa.

Tu agente individual ya funciona razonablemente bien. Hay investigación que sugiere que si tu agente único supera el 45% de accuracy en la tarea, añadir más agentes probablemente no mejore las cosas. A veces las empeora.

Las tareas son principalmente de escritura. Las operaciones de lectura se paralelizan bien. Las de escritura crean problemas de coordinación.

Eres un equipo pequeño. Multi-agente requiere seguimiento, depuración distribuida y pruebas de integración. Si sois dos personas, empieza simple.

Cuándo SÍ tiene sentido

Sí tiene sentido cuando:

El problema cruza varios dominios con reglas diferentes. Un asistente de e-commerce que gestiona catálogo, pagos, envíos y devoluciones. Cada área tiene su propia lógica, sus propios datos, sus propias excepciones.

Las tareas tienen dependencias claras y pases múltiples. Primero buscar producto, luego verificar stock, luego aplicar descuentos, luego calcular envío. Cuando el orden importa y cada paso necesita información del anterior.

Necesitas auditoría estricta. En banca, seguros, o cualquier sitio regulado, saber exactamente qué decisión tomó quién es obligatorio. Con multi-agentes puedes tracear cada paso.

Equipos diferentes mantienen partes diferentes. Si el equipo de pricing cambia sus reglas cada semana y el de logística cada mes, que cada uno tenga su agente facilita que iteren sin romperse mutuamente.

Los números reales de latencia (y la complejidad que nadie te cuenta)

Esto es más complicado de lo que parece. La latencia viene de muchos sitios, no solo de la generación del modelo.

Infraestructura del LLM:

Desde dónde llamas al modelo importa. Si tu servidor está en Europa y usas un endpoint en US, añades entre 80 y 150ms solo de red, en cada llamada. Y en multi-agente haces muchas llamadas. Pharosyne ha visto sistemas donde el 30% de la latencia total era solo round-trips transatlánticos.

La propia infraestructura del proveedor añade variabilidad. En horas pico puedes pasar de 200ms de tiempo hasta el primer token a 800ms o más. Esto multiplica en multi-agente.

Gestión de contexto:

Cada agente necesita contexto. Cómo lo comprimes, cuánto mantienes, cómo lo pasas entre agentes, todo suma. Pharosyne ha visto sistemas donde la serialización y deserialización del estado entre agentes añadía 50-100ms por salto.

Si usas memoria compartida con persistencia, añade latencia de base de datos. Si usas cache, tienes que gestionar invalidación. Si comprimes conversaciones para no pasarte de tokens, esa compresión tiene coste.

Comunicación entre agentes:

Si los agentes se pasan mensajes, cada paso de comunicación añade coste. Hay que parsear respuestas, validar formato, gestionar errores y reintentar. En un sistema de 5 agentes con orquestador, puedes acabar con 8-10 llamadas entre componentes por cada petición del usuario.

Los números que Pharosyne ve en producción:

Sumando: un request simple a través de 3 agentes puede tardar 8-15 segundos fácilmente. Un request complejo con 5 agentes y múltiples pasadas, 30 segundos o más.

Si necesitas respuestas en menos de 2 segundos, la arquitectura multi-agente probablemente no sea para ti. Y si crees que puedes optimizarlo después, piénsalo dos veces. La complejidad crece exponencialmente con cada agente que añades.

Enfoque de implementación

Pharosyne no usa frameworks. Anthropic lo dice bien en su documentación: las implementaciones más exitosas no usan frameworks complejos ni librerías especializadas. Construyen con patrones simples y componibles.

Los frameworks añaden abstracción. La abstracción esconde lo que pasa. En producción necesitas ver exactamente qué llega a la API. Es más código, sí, pero también es mucho más fácil de depurar.

El patrón básico es un orquestador con enrutado:

El orquestador es otra llamada al LLM con un prompt específico para clasificar y routear. Cada agente es su propia llamada con su propio system prompt y herramientas. La memoria compartida suele ser un diccionario o store que pasas entre llamadas.

No es magia. Es ingeniería de software básica aplicada a llamadas de API. El trabajo real está en diseñar buenos prompts, definir herramientas claras, y sobre todo en el manejo de errores y la observabilidad.

Evaluaciones: esto no es testing tradicional

Aquí es donde la mayoría se pierde. Piensas que puedes probar un sistema multi-agente como pruebas software tradicional: unitarias, integración, extremo a extremo. No funciona así.

Con LLMs no tienes determinismo. La misma entrada puede dar salidas diferentes. Un test que pasa hoy puede fallar mañana sin que hayas cambiado nada. Y cuando tienes múltiples agentes, la variabilidad se multiplica.

Lo que necesitas son evaluaciones, no solo tests.

Las evals son evaluaciones continuas sobre datasets representativos. No verifican que la salida sea exactamente X, verifican que la salida sea "suficientemente buena" según criterios definidos. Accuracy, relevancia, ausencia de alucinaciones, formato correcto, tono adecuado.

Por qué es más complejo que testing tradicional:

En software clásico, un test falla o pasa. Con LLMs tienes gradientes. Una respuesta puede ser 80% correcta. O correcta pero mal formateada. O correcta pero con tono inadecuado. Definir qué es "suficientemente bueno" es un problema en sí mismo.

En multi-agente se complica más. Si el resultado final es malo, ¿qué agente falló? ¿El orquestador routeó mal? ¿Un agente intermedio corrompió el contexto? ¿La combinación de respuestas perdió información? Necesitas evals a nivel de cada agente y a nivel de sistema.

Lo que hace Pharosyne en producción:

Datasets de evaluación por agente. Mínimo 50-100 casos representativos por agente, con salidas esperadas o criterios de evaluación.

Evals automáticas en CI. Cada cambio de prompt dispara evaluación contra el dataset. Si la accuracy baja del umbral, no se despliega.

LLM-as-judge para casos complejos. Usar otro modelo para evaluar si la respuesta es correcta cuando no hay una respuesta "exacta". Tiene sus problemas, pero escala mejor que revisión humana.

Monitorización continua en producción. Las evals no terminan en deploy. Muestreo de requests reales, evaluación offline, alertas cuando las métricas se degradan.

El coste que nadie menciona:

Construir un buen sistema de evals puede llevar más tiempo que construir el sistema multi-agente en sí. Pharosyne ha visto proyectos donde el 40% del esfuerzo fue en evaluación y observabilidad. Pero sin eso, no sabes si tu sistema funciona. Solo esperas que funcione.

Errores comunes

Empezar con demasiados agentes. La tentación es modelar toda la organización desde el día uno. Empieza con dos, máximo tres. Añade cuando tengas un problema real que resolver, no antes.

No definir contratos. Cada agente necesita una especificación clara: qué recibe, qué devuelve y cuándo falla. Sin esto, cuando algo se rompe, depurar es casi imposible.

Ignorar observabilidad. Un sistema multi-agente sin logs estructurados y tracing es una caja negra. Necesitas poder reconstruir qué pasó cuando algo falla.

Subestimar costes. Cada agente es otra llamada al LLM. Pharosyne ha visto facturas duplicarse o triplicarse después de migrar a multi-agente. Presupuesta desde el principio.

Depender de frameworks. Cuando el framework se actualiza, o deja de mantenerse, o tiene un bug en producción, estás atrapado. Con código propio sobre la API, tienes control total.

Sobre-ingeniería. Los modelos mejoran rápido. Lo que hoy necesita tres agentes, en seis meses quizás lo haga uno solo. No construyas para problemas que no tienes todavía.

El siguiente paso

Si tienes procesos que hoy dependen de humanos haciendo trabajo repetitivo con múltiples sistemas, los sistemas multi-agente pueden ayudar. No son magia. Son ingeniería de software aplicada a LLMs, con sus tradeoffs.

La recomendación: empieza con un solo agente bien hecho. Mide dónde falla. Solo cuando tengas datos claros de que la arquitectura simple no escala, considera partir en múltiples agentes.

Para revisar tu caso, contacta con Pharosyne. El servicio de sistemas multi-agente encaja si tu flujo ya tiene herramientas, permisos, traspasos y fallos medibles. Si el sistema ya existe y se siente inestable, empieza por una auditoría técnica de IA.