Susana López Blanco Llega una solicitud de propuesta de un cliente importante. Para responder hay que entender qué pide, recuperar el historial de la cuenta, comprobar precios, calcular rentabilidad, revisar determinadas condiciones contractuales, preparar la oferta, solicitar una aprobación si el descuento supera un límite y registrar el resultado en el CRM.
Un único agente podría intentar recorrer todo el proceso. También podemos dividirlo. Uno recupera la historia del cliente. Otro trabaja con costes y márgenes. Un tercero revisa las condiciones que afectan al contrato. Otro prepara la propuesta a partir de los resultados anteriores.
En un diagrama queda estupendo. Cuatro cajas, unas flechas y, si queremos impresionar a alguien, distintos colores para cada agente. Al llevarlo a producción empiezan preguntas bastante menos vistosas: quién decide qué agente interviene primero, qué información recibe cada uno, dónde queda registrado lo que ya se ha hecho, cuánto esperamos una respuesta y qué sucede cuando Finanzas y Comercial llegan a conclusiones diferentes.
También tendremos que decidir qué ocurre si uno falla después de que los anteriores hayan terminado correctamente. O si dos agentes ejecutan a la vez consultas costosas que ya había hecho otro. O si un agente interpreta mal el identificador del cliente y todos los siguientes trabajan impecablemente sobre la cuenta equivocada.
Un sistema multiagente reparte un proceso entre componentes especializados y necesita una forma explícita de coordinar ese trabajo. Esa coordinación incluye el orden de ejecución, el estado del proceso, las entradas y salidas de cada función, los permisos, la memoria compartida, los errores y las condiciones que permiten dar una tarea por terminada.
Partimos de que el lector ya conoce cómo funcionan los agentes de IA en la empresa. Aquí nos ocuparemos de la siguiente decisión: cuándo conviene separar funciones y cómo conseguir que el trabajo llegue desde el primer agente hasta el último sin construir una arquitectura que dentro de seis meses necesite a su creador para explicar qué hace.
Índice de contenidos
Cuándo tiene sentido repartir el trabajo
La especialización aporta valor cuando las partes del proceso tienen diferencias reales. Un análisis financiero puede necesitar acceso a costes que un agente comercial no debería consultar. La revisión contractual trabaja con documentación e instrucciones distintas. La investigación de mercado quizá utilice fuentes externas mientras el cálculo de margen debe limitarse a datos internos controlados.
Separar esas funciones permite asignar a cada una instrucciones, herramientas, permisos y contexto específicos. También facilita cambiar una parte sin rehacer todo el proceso. Si mañana modificamos la lógica de aprobación financiera, podemos trabajar sobre ese componente y conservar el resto del flujo.
El paralelismo ofrece otra razón. Mientras se recupera el historial comercial, el análisis financiero y la revisión documental pueden avanzar si ninguno depende del resultado del otro. El tiempo total puede reducirse aunque aumente el número de ejecuciones.
Muchas automatizaciones etiquetadas como multi-agent systems siguen siendo, en la práctica, workflows en los que distintos componentes realizan funciones determinadas. Eso está perfectamente bien. Una secuencia conocida suele ser más fácil de comprender, probar y mantener. Si después de A siempre viene B y después C, añadir un modelo para decidir cada transición aporta poco.
El routing, o enrutamiento, empieza a ser útil cuando el recorrido depende del caso. Una solicitud puede ir directamente a soporte, pasar antes por una comprobación financiera o requerir revisión jurídica según sus características. Los agentes especializados empiezan a justificar su coste cuando separar funciones mejora permisos, contexto, paralelismo, mantenimiento o calidad de una manera que podamos observar.
En nuestro Máster en Agentes IA y Automatización No-Code trabajamos precisamente desde esta lógica de proceso: decidir primero qué función debe ejecutar cada componente y después qué grado de autonomía merece.
Quién reparte el trabajo
Alguien —o, más exactamente, algo— tiene que mantener el proceso. A ese componente solemos llamarlo orquestador. Puede ser código convencional, un workflow, un motor de estados, un conjunto de reglas, un modelo o una combinación de varios mecanismos.
Su trabajo consiste en saber qué tarea está activa, qué pasos han terminado, qué resultados existen, qué falta por hacer y qué componente puede intervenir a continuación. También controla esperas, excepciones, reintentos y finalización.
La orquestación más sencilla sigue un recorrido fijo. El análisis comercial termina, después se ejecuta Finanzas y finalmente se prepara la propuesta. Es fácil de probar y resulta apropiada cuando conocemos el flujo.
En otros procesos podemos utilizar reglas. Si el margen calculado supera cierto umbral, la propuesta continúa. Si queda por debajo, pasa a aprobación. Si el contrato contiene una cláusula determinada, se activa una revisión adicional. Buena parte de la lógica empresarial funciona mejor expresada así que delegada en una decisión probabilística.
Un modelo puede participar en el routing cuando la clasificación requiere interpretar lenguaje o situaciones difíciles de enumerar mediante reglas. Por ejemplo, puede decidir si una solicitud pertenece a una categoría comercial, técnica o contractual. Esa decisión debería producir una salida suficientemente clara para que el workflow pueda continuar sin tener que interpretar después un párrafo ambiguo.
En sistemas reales suele funcionar bien una combinación: modelos donde hace falta interpretar y reglas donde la empresa ya conoce la condición. Si un descuento superior al 20 % necesita aprobación humana, no necesitamos pedir a un LLM que reflexione sobre ello en cada ejecución.
Qué información recibe cada agente
Enviar todo el contexto a todos los participantes parece cómodo al principio. También genera llamadas más caras, añade ruido y amplía innecesariamente el acceso a información.
El agente que calcula rentabilidad necesita el identificador correcto del cliente, precio propuesto, costes relevantes, condiciones económicas y quizá determinados datos históricos. No necesita veinte correos sobre cómo se negoció la fecha de una reunión. Quien prepara la propuesta comercial sí puede necesitar preferencias, antecedentes y argumentos tratados con el cliente, pero quizá carezca de permiso para consultar determinados costes internos.
Diseñar estas vistas obliga a conocer qué datos necesita realmente cada función. Una infraestructura común puede aportar identificadores, hechos empresariales y herramientas compartidas; la explicación de cómo organizar esa base pertenece a nuestra guía de arquitectura de IA a largo plazo.
La reducción de contexto ayuda además a depurar. Si un resultado financiero sale mal y conocemos exactamente qué cinco campos recibió el agente, podemos reconstruir la ejecución. Cuando le entregamos una conversación de cien páginas, varios documentos y acceso amplio al CRM, averiguar qué información influyó en la respuesta se vuelve bastante más incómodo.
Este diseño también limita la propagación de información sensible. Los permisos se aplican antes de recuperar datos y antes de construir el contexto. Un componente que carece de acceso a salarios, márgenes internos o información jurídica restringida debería trabajar sin recibirla.
Cómo se pasan el trabajo sin perder el estado del proceso
Supongamos que el primer agente termina el análisis del cliente y devuelve: «He revisado la cuenta y parece bastante interesante. Hay algunas incidencias, pero creo que podemos seguir». Esa respuesta puede ser razonable para una persona. Para el siguiente paso de una automatización es bastante pobre.
Cuando los componentes intercambian información conviene definir contratos de salida. El análisis anterior podría devolver campos como estos:
- cliente_id
- riesgo
- margen_estimado
- incidencias_abiertas
- recomendacion
- evidencia
- confianza
- requiere_revision
Las salidas estructuradas reducen ambigüedad, permiten validar tipos y valores, facilitan las reglas posteriores y dejan un rastro bastante más legible cuando algo falla. El siguiente agente recibe los campos que necesita en lugar de tener que deducirlos de una explicación generada.
El proceso necesita además un identificador propio y un estado persistente. Ese estado registra qué pasos terminaron, qué salidas produjeron, cuáles están pendientes y si existe una aprobación o excepción abierta. Un checkpoint guarda un punto desde el que podemos continuar después de una interrupción sin repetir todo el trabajo anterior.
Los eventos ayudan a representar transiciones útiles: «análisis financiero completado», «revisión jurídica requerida» o «propuesta aprobada». El orquestador utiliza esos cambios para decidir qué puede ejecutarse después.
El paralelismo encaja bien en este diseño. Historial comercial, análisis de rentabilidad y comprobación documental pueden arrancar a la vez si utilizan entradas independientes. El orquestador espera las salidas imprescindibles antes de preparar la propuesta. Los resultados pueden llegar en momentos diferentes y alguna fuente puede haber cambiado mientras tanto, por lo que conviene guardar también cuándo se obtuvo cada dato.
Esta manera de diseñar entradas, salidas y dependencias se parece bastante a gestionar un proyecto pequeño que se ejecuta miles de veces. Por eso nuestro Máster en Digital Project Management encaja especialmente bien con problemas de orquestación: secuencias, dependencias, estados, bloqueos y responsabilidades siguen existiendo aunque parte del trabajo lo hagan modelos.
Qué memoria comparten y qué memoria conserva cada uno
Los participantes de un mismo proceso necesitan recuerdos diferentes. Un agente puede mantener memoria privada relacionada con su función. El proceso necesita conservar decisiones y resultados parciales. La cuenta del cliente tiene una historia que varios componentes pueden consultar. Además puede existir conocimiento corporativo compartido.
La separación evita que cada ejecución reconstruya la misma historia y ayuda a controlar quién consulta qué. Un agente financiero puede recuperar acuerdos económicos anteriores sin recibir todas las conversaciones comerciales. Otro dedicado a atención puede consultar incidencias pasadas sin acceder a análisis internos reservados.
El orquestador debería pasar referencias y contexto útil en lugar de copiar indiscriminadamente toda la memoria de un componente al siguiente. Si una decisión anterior afecta a la propuesta, se recupera esa decisión con su fecha, procedencia y vigencia. El resto permanece fuera del contexto.
Los permisos vuelven a aplicarse antes de recuperar. Una memoria compartida no significa acceso universal. También conviene controlar quién puede escribir recuerdos persistentes: un agente quizá pueda proponer una actualización mientras determinados datos requieren validación antes de incorporarse a la historia común.
En nuestra guía sobre memoria para agentes de IA desarrollamos cómo seleccionar, fechar, versionar y recuperar información durante meses. Aquí basta con conservar una regla operativa: cada participante recibe la parte de la historia que necesita para ejecutar su función.
Qué hacemos cuando dos agentes discrepan
El agente comercial recomienda un descuento del 18 % porque considera prioritaria la cuenta. El análisis financiero calcula que ese precio deja un margen insuficiente. Ambos pueden estar funcionando correctamente desde sus respectivas instrucciones.
El proceso necesita saber qué hacer con esa discrepancia. En algunos casos existe una regla de precedencia: una condición financiera mínima bloquea la oferta. En otros conviene solicitar información adicional, ejecutar una revisión especializada o enviar el caso a una persona.
También podemos utilizar niveles de confianza y evidencia. Si una clasificación contractual tiene baja confianza, el sistema puede recuperar documentación adicional antes de continuar. Si dos resultados se apoyan en fuentes distintas, la revisión debería recibir esas fuentes y no únicamente las conclusiones.
Crear otro agente para que decida siempre quién tiene razón añade una nueva inferencia al proceso. Puede ser útil cuando la tarea de revisión está bien definida, pero tampoco convierte una incertidumbre en certeza por arte de arquitectura.
La votación entre varios modelos merece la misma cautela. Cinco respuestas iguales pueden aumentar nuestra confianza cuando los errores son suficientemente independientes. Cinco agentes que usan el mismo modelo, los mismos datos incompletos y una instrucción parecida pueden equivocarse de la misma manera cinco veces.
Las decisiones materiales necesitan una política comprensible. Restricciones duras mediante reglas, revisión especializada cuando aporte evidencia diferente y escalado humano cuando el coste de equivocarse lo justifique suelen producir sistemas bastante más previsibles.
Un fallo pequeño puede propagarse por todo el sistema
Un sistema multiagente introduce fallos compuestos. El primer componente identifica mal al cliente. El segundo consulta correctamente el CRM, pero ya trabaja con el identificador equivocado. Finanzas calcula impecablemente el margen de otra cuenta. El último agente redacta una propuesta coherente a partir de esos resultados.
Cada pieza puede superar una revisión superficial y el resultado completo seguir siendo incorrecto.
Las validaciones intermedias reducen esa propagación. Podemos comprobar identificadores antes de consultar herramientas, validar que un importe está dentro de rangos posibles, exigir evidencia para determinadas decisiones o detener el proceso cuando una salida carece de campos obligatorios.
Los checkpoints ayudan cuando falla una parte tardía. Si los tres análisis anteriores ya terminaron y sus resultados siguen siendo válidos, repetirlos porque falló la generación del documento añade coste y nuevas oportunidades de obtener respuestas distintas.
Los reintentos necesitan límites. Una caída temporal de una API puede justificar volver a intentar la llamada. Repetir cinco veces una petición que falla porque el dato requerido no existe consume tiempo sin modificar la causa.
Los timeouts fijan cuánto esperamos. Un proceso comercial no debería quedar indefinidamente abierto porque un servicio externo dejó de responder. El orquestador puede usar una alternativa, marcar la tarea como pendiente o escalarla según el caso.
La idempotencia importa cuando una operación tiene efectos externos. Reintentar una lectura suele ser inocuo. Reintentar sin control «enviar pedido», «emitir devolución» o «crear factura» puede ejecutar la acción dos veces. Cada herramienta con efectos debería disponer de identificadores y controles que permitan saber si aquella operación ya se realizó.
Cuando una acción admite reversión conviene definir también cómo deshacerla. Crear un borrador en el CRM puede revertirse con facilidad. Enviar un contrato firmado o ejecutar un pago pertenece a otra categoría y necesita controles previos más estrictos.
Los bucles son caros y a veces bastante absurdos
Un agente pide información a otro. El segundo considera insuficiente el contexto y solicita una ampliación. El primero vuelve a generar. Un tercero revisa la nueva versión y plantea otra objeción. El proceso continúa produciendo texto, llamadas y latencia mientras nadie tiene demasiado claro qué condición permitirá terminar.
La autonomía abierta necesita límites operativos: número máximo de iteraciones, presupuesto de ejecución, tiempo máximo, condiciones de salida y criterios que definan cuándo el resultado es suficiente.
También conviene detectar trabajo duplicado. Si tres agentes necesitan el mismo dato del CRM, recuperarlo una vez y compartir un resultado validado reduce llamadas y evita que cada uno trabaje con una instantánea distinta. Si un cálculo determinista ya existe, reutilizarlo suele ser mejor que pedir a tres modelos que lo vuelvan a interpretar.
Los bucles legítimos existen. Una propuesta puede revisarse después de recibir observaciones y volver a generarse. La iteración tiene entonces un propósito, un máximo y una condición de salida. Cuando esos tres elementos faltan, el sistema puede mantenerse muy ocupado sin avanzar demasiado.
Cuándo un sistema multiagente compensa la complejidad
Agregar un participante significa añadir una llamada, un contrato de entrada y salida, posibles errores, latencia, registros y mantenimiento. La especialización debería devolver algo a cambio.
| Señal | Qué puede justificar la separación | Qué añade |
|---|---|---|
| Herramientas distintas | Cada función accede solo a las aplicaciones que necesita | Más integraciones que mantener |
| Permisos distintos | Reduce exposición de datos y acciones | Políticas de acceso adicionales |
| Contextos muy diferentes | Instrucciones y datos más precisos por función | Más handoffs y contratos |
| Trabajo independiente | Permite ejecutar tareas en paralelo | Más llamadas simultáneas y sincronización |
| Salidas evaluables por separado | Facilita probar y sustituir componentes | Más puntos que observar |
| Responsabilidades claras | Hace más comprensible quién decide cada parte | Reglas para resolver conflictos |
Antes de añadir otro agente preguntaría si su función puede describirse de manera concreta, si necesita herramientas o permisos diferentes y si podemos evaluar su resultado por separado. También miraría cuántas veces se ejecutará el proceso y cuánto valor aporta la separación. Una arquitectura sofisticada para una tarea que ocurre veinte veces al año puede tardar bastante en devolver el esfuerzo de construirla.
La mantenibilidad ofrece otro criterio. Separar un cálculo financiero estable de una función creativa puede simplificar cambios y pruebas. Dividir una tarea homogénea entre cinco roles con instrucciones ligeramente diferentes suele aumentar el número de relaciones que alguien tendrá que entender después.
Hay una prueba práctica especialmente buena: explicar qué ocurre cuando falla cada componente. Si nadie puede responder sin abrir un diagrama enorme o revisar código durante media hora, la complejidad ya está empezando a cobrarse intereses.
Cómo construiría el primer sistema multiagente
Empezaría con un proceso que ya podamos dibujar sin IA. Qué dispara el trabajo, qué decisiones existen, qué herramientas intervienen, dónde hacen falta aprobaciones y qué resultado marca el final.
Después buscaría dos o tres funciones realmente diferentes. No diez. Por ejemplo: recuperar y analizar contexto comercial, validar rentabilidad y preparar una propuesta. Si la revisión jurídica solo aparece en un 5 % de los casos, puede entrar como ruta excepcional.
Definiría las entradas y salidas antes de escribir prompts. Cada función debería recibir campos conocidos y devolver una estructura que el siguiente paso pueda validar. El lenguaje libre queda para aquello que realmente requiere lenguaje libre.
También decidiría dónde vive el estado del proceso. El orquestador necesita saber qué terminó, qué queda pendiente y qué resultados se han validado. Esa información debería sobrevivir a un fallo o una espera larga.
Después asignaría herramientas y permisos. Cada componente recibe los mínimos necesarios para cumplir su función. La memoria y los datos compartidos se recuperan según el contexto y los permisos de esa tarea.
La primera orquestación debería ser deliberadamente sencilla. Reglas para los recorridos conocidos, modelos cuando hace falta interpretar y escalado cuando la incertidumbre supera lo que queremos automatizar. Nuestro Máster en Agentes IA y Automatización No-Code trabaja este tipo de diseño aplicado a procesos e integraciones reales, donde una arquitectura tiene que seguir funcionando después de la primera demostración.
Antes de añadir nuevos agentes probaría fallos. Identificador incorrecto. Respuesta vacía. API caída. Resultado contradictorio. Agente que tarda demasiado. Ejecución repetida de una acción. Una buena parte del diseño aparece precisamente al intentar romper el proceso.
Después mediría calidad, tiempo, coste y porcentaje de casos que necesitan intervención. Si una nueva especialización mejora alguno de esos resultados de forma suficiente, tiene sentido incorporarla. Si únicamente hace que el diagrama parezca más avanzado, puede esperar.
Un sistema multiagente bien construido debería permitir explicar en pocos minutos quién hizo cada parte del trabajo, qué información recibió, qué devolvió y por qué el proceso continuó. Cuando necesitamos un diagrama de dos metros para reconstruirlo, probablemente hemos añadido complejidad antes de necesitarla.
Preguntas frecuentes sobre sistemas multiagente
¿Qué es un sistema multiagente?
Es un diseño en el que varias funciones basadas en agentes participan en un mismo proceso. Cada una puede disponer de instrucciones, herramientas, contexto y permisos propios. Un orquestador o workflow mantiene el estado y decide cómo avanza el trabajo.
¿Cuándo merece la pena usar varios agentes?
Cuando el proceso contiene funciones claramente diferenciadas y separarlas mejora permisos, especialización, paralelismo, evaluación o mantenimiento. Si el recorrido es fijo y homogéneo, un workflow sencillo puede resolverlo con menos coste operativo.
¿Qué hace un orquestador de agentes?
Mantiene el estado del proceso: qué tarea está activa, qué pasos terminaron, qué resultados existen y qué debe ejecutarse después. También puede gestionar routing, esperas, errores, reintentos, límites y finalización.
¿Cómo comparten información varios agentes?
Conviene utilizar entradas y salidas estructuradas y un estado compartido. El primer agente devuelve campos definidos que pueden validarse y el orquestador entrega al siguiente únicamente los datos que necesita. La memoria compartida se consulta según permisos y contexto.
¿Pueden varios agentes trabajar al mismo tiempo?
Sí, cuando sus tareas son independientes. Un análisis comercial, uno financiero y una revisión documental pueden ejecutarse en paralelo y el proceso esperar a que lleguen los resultados necesarios. El diseño debe considerar costes simultáneos, tiempos diferentes y posibles cambios en las fuentes consultadas.
¿Qué ocurre si un agente falla?
Depende del tipo de fallo. Podemos reintentar errores temporales, continuar desde un checkpoint, usar una alternativa, detener el proceso o escalarlo. Las acciones con efectos externos necesitan además controles que eviten duplicarlas durante un reintento.
¿Es mejor un sistema multiagente que utilizar un único agente?
Depende de cómo esté dividido el proceso. Varios agentes aportan especialización cuando existen funciones, herramientas, permisos o contextos suficientemente diferentes. También añaden llamadas, estados, dependencias y puntos de fallo. La decisión merece evaluarse por la mejora que produce en el trabajo completo y por el coste de mantener esa coordinación.