Es un escenario cada vez más habitual y que casi nunca se planifica: el departamento comercial lleva meses usando un agente de IA que cualifica leads y agenda reuniones, y por su lado, administración ha implantado otro agente que genera facturas y concilia pagos. Funcionan bien, cada uno en su terreno. Hasta que un día alguien se da cuenta de que, cuando ventas cierra un trato, alguien tiene que copiar manualmente los datos al sistema de facturación para que el segundo agente pueda hacer su trabajo. Los dos agentes son buenos en lo suyo, pero nadie los diseñó para hablar entre sí, porque nadie pensó en ese momento que tendrían que hacerlo.
Esto no es un fallo de diseño necesariamente. Es lo normal cuando una empresa adopta IA de forma incremental, departamento a departamento, en vez de construir una arquitectura conjunta desde el primer día. La pregunta relevante no es "¿deberíamos haber pensado en esto antes?", sino "¿qué hacemos ahora que ha aparecido la necesidad?".
Por qué este problema es distinto al de una arquitectura multiagente diseñada desde cero
Cuando explicamos arquitecturas multiagente o cómo varios agentes de IA se comunican entre sí, partimos de un supuesto que aquí no se cumple: que alguien diseñó el conjunto desde el principio, con un formato común de datos y un orquestador que reparte el trabajo. La situación de dos agentes departamentales que "de repente" necesitan coordinarse es otra: cada uno se compró, se configuró o se entrenó de forma independiente, probablemente con proveedores distintos, con su propio modelo de datos y sin que nadie pensara en el otro al diseñarlo. Coordinarlos a posteriori no es un ajuste menor, es un proyecto de integración por derecho propio.
Las señales de que ha llegado el momento
No conviene esperar a que el problema sea evidente para todo el mundo. Hay señales que indican que dos agentes departamentales ya deberían estar coordinados, aunque hoy no lo estén:
- Una persona copia manualmente datos de un sistema a otro para que el segundo agente pueda actuar sobre información que el primero ya generó.
- El cliente o el proceso interno sufre un retraso perceptible entre que un agente termina su parte y el otro se entera de que tiene trabajo pendiente.
- Existen dos versiones ligeramente distintas del mismo dato (un cliente, un pedido, un importe) porque cada agente mantiene su propia copia sin sincronizar con la del otro.
- Alguien ha empezado a preguntar "¿por qué no se pasan esto automáticamente?" más de una vez en las últimas semanas.
Si reconoces dos o más de estas señales, ya no es una mejora deseable: es una fuente activa de errores y de trabajo invisible que alguien del equipo está absorbiendo sin que se contabilice en ningún sitio.
Tres formas de resolverlo, de menor a mayor complejidad
No hace falta construir un orquestador sofisticado para dar el primer paso. Hay tres niveles de solución, y conviene subir de nivel solo cuando el anterior se queda corto.
Integración punto a punto. El agente A escribe el resultado de su tarea en un lugar (una hoja, una tabla, un webhook) que el agente B consulta o recibe automáticamente. Es la solución más rápida de montar y la más razonable cuando solo hay dos agentes implicados y el flujo de información va en una dirección predecible. Su límite aparece en cuanto un tercer agente entra en juego: cada nueva conexión punto a punto multiplica la complejidad de mantenimiento.
Un dato compartido de referencia. En lugar de que los agentes se hablen directamente entre sí, ambos leen y escriben sobre una misma fuente de verdad (normalmente el CRM o el ERP que la empresa ya usa). Cada agente actualiza ese sistema central cuando completa su parte, y el otro lo consulta cuando lo necesita. Esta opción exige más disciplina de datos al principio, pero escala mucho mejor que las conexiones punto a punto cuando aparecen más agentes en el futuro. Es también el enfoque que subyace a la automatización de workflows entre departamentos, aunque aquí se aplica a agentes que nacieron por separado, no a un flujo diseñado como un todo desde el inicio.
Un orquestador dedicado. Cuando el número de agentes departamentales crece y las reglas de quién decide qué en cada cruce empiezan a ser complicadas, tiene sentido introducir una capa de coordinación explícita, tal y como se explica en qué es un orquestador de agentes. Es la opción más potente, pero también la que exige más inversión inicial: no conviene construirla para resolver la coordinación de solo dos agentes con un flujo simple.
Los riesgos de coordinar sin pensarlo bien
Conectar dos agentes que nacieron por separado tiene riesgos específicos que no aparecen cuando el sistema se diseña desde cero. El más frecuente es la duplicación de lógica: si ambos agentes tienen reglas propias sobre, por ejemplo, cuándo se considera "cerrado" un cliente, y esas reglas no coinciden exactamente, el sistema conjunto puede tomar decisiones contradictorias sin que nadie lo note hasta que ya ha pasado varias veces. Otro riesgo es la propiedad del dato: cuando dos agentes escriben sobre el mismo registro sin que quede claro cuál manda en caso de conflicto, aparecen inconsistencias silenciosas que erosionan la confianza en ambos sistemas, no solo en el que falló.
También hay un riesgo organizativo, más que técnico: cada agente tiene, normalmente, un responsable de departamento distinto. Cuando algo falla en el punto de cruce entre los dos, es habitual que cada responsable asuma que el problema es del otro lado, precisamente porque nadie tenía asignada la responsabilidad conjunta desde el principio. Definir quién es responsable de que la conexión funcione, no solo de que cada agente funcione por separado, evita ese punto ciego.
Cómo decidir si merece la pena coordinar o si es mejor dejarlo como está
No toda conexión manual entre dos agentes justifica un proyecto de integración. Antes de invertir tiempo en ello, vale la pena preguntarse cuánto volumen tiene ese cruce (si ocurre dos veces al mes, probablemente no compense automatizarlo todavía), cuánto tiempo humano consume hoy la copia manual de datos, y qué coste tiene un error cuando la sincronización falla, porque no es lo mismo un dato de seguimiento comercial desactualizado unas horas que un importe de facturación mal trasladado.
Conclusión
Que dos agentes de departamentos distintos necesiten coordinarse no es un síntoma de que algo se hizo mal al implantarlos por separado: es lo esperable cuando la adopción de IA avanza departamento a departamento, que es como avanza la mayoría de las pymes. Lo importante es reconocer las señales pronto, elegir el nivel de integración proporcional al problema real —punto a punto, dato compartido u orquestador— y asignar con claridad quién responde de que esa conexión siga funcionando con el tiempo.
En MG Solutions ayudamos a empresas que ya tienen varios agentes de IA funcionando por separado a decidir cómo y cuándo conectarlos sin rehacer lo que ya funciona. Si es tu caso, reserva una primera reunión y lo revisamos juntos.