Cuando los equipos de desarrollo empiezan a construir sistemas con agentes de inteligencia artificial, suele aparecer una tentación casi irresistible: conectar los agentes directamente mediante llamadas síncronas. Después de todo, es el patrón más familiar. Un agente planificador invoca a un agente de enriquecimiento, que a su vez llama a un agente de precios, y así sucesivamente. Todo funciona en el demo, la latencia parece aceptable y el código queda limpio. Pero esa arquitectura, que en apariencia es sencilla, esconde una trampa que ya pagamos caro en la era de los microservicios: el monolito distribuido. Cuando los agentes se llaman directamente, cada interacción se convierte en un acoplamiento rígido, cada fallo se propaga en cascada y, lo peor de todo, la conversación entre agentes desaparece en cuanto la llamada termina. No hay registro, no hay posibilidad de repetición, no hay auditoría. Es el mismo problema de siempre, solo que disfrazado de inteligencia artificial.
Imaginemos un flujo típico de procesamiento de pedidos. Un agente planificador recibe una orden y, para enriquecerla, necesita datos de un agente de enriquecimiento. Ese agente, a su vez, consulta a un agente de precios, y este a un agente antifraude. Todo ocurre en una cadena de llamadas HTTP síncronas. En la demo, el tiempo de respuesta es de unos segundos, pero en producción, cuando un agente se encuentra con un registro de producto mal formado o una API externa inestable, la cadena se bloquea. El agente de enriquecimiento entra en un bucle de reintentos, no devuelve nada, y los agentes que esperan arriba se quedan colgados. La cola de pedidos se acumula, el rendimiento cae a cero y no hay errores en el panel de control, solo un silencio que duele. Y cuando alguien pregunta qué estaba haciendo el agente justo antes de colgarse, la única respuesta es un volcado de pila. No hay rastro de los mensajes intercambiados. La conversación ocurrió en memoria RAM y se perdió para siempre.
Este escenario no es un problema de inteligencia artificial. Es un problema de arquitectura de sistemas distribuidos que ya resolvimos hace una década con los microservicios, pero que ahora resucita bajo el disfraz de agentes. Las llamadas directas entre agentes reintroducen cinco males que cualquier arquitecto experimentado reconoce al instante: acoplamiento fuerte, fallos en cascada, tormentas de fan-out, ausencia de contrapresión y, el más crítico, falta de trazabilidad. Cuando el agente A tiene que conocer la dirección, el formato de petición y la respuesta del agente B, el grafo de dependencias queda grabado en el código. Añadir un nuevo agente de cumplimiento normativo obliga a modificar el planificador para que le envíe también los datos. La disponibilidad de una cadena de cinco agentes es el producto de sus disponibilidades individuales, y la latencia en el percentil 99 es la suma de todas las colas. Con agentes de IA, cuyas inferencias pueden tardar segundos, esas colas se vuelven enormes y el sistema se vuelve frágil.
La solución es conocida, aburrida y efectiva: no dejes que los agentes se llamen directamente. En lugar de eso, publican eventos en un broker o registro central, y otros agentes se suscriben a los eventos que les interesan. El agente planificador no invoca al de enriquecimiento; publica un evento 'order.enrichment.requested' y sigue adelante. El agente de enriquecimiento, cuando esté listo y a su propio ritmo, consume ese evento, hace su trabajo y publica otro evento con el resultado. Quien necesite los datos enriquecidos —el agente de precios, el de fraude, o uno nuevo de auditoría que se añada el próximo trimestre— se suscribe al evento de resultado. El planificador nunca sabe quién está al otro lado. El contrato entre agentes se reduce a un único elemento: el esquema del evento. Un esquema tipado y versionado es toda la superficie de acoplamiento. El resto desaparece.
¿Qué gana el sistema con este cambio? Primero, durabilidad. El evento se guarda en disco antes de que ningún agente lo toque. Si el agente de enriquecimiento se cae durante una hora, el trabajo espera en el registro. Cuando vuelve, continúa desde donde lo dejó. Segundo, repetición. Si un despliegue erróneo en el agente de precios causa problemas, se puede resetear el offset del consumidor y volver a ejecutar los eventos de ayer con el código corregido. Depurar una decisión extraña se convierte en leer la secuencia exacta de eventos asociada a un identificador de traza. No se puede repetir una llamada HTTP que no se grabó, pero siempre se puede repetir un registro de eventos. Tercero, auditoría gratuita. Lo que antes era una tarea onerosa de cumplimiento —tener un registro de cada decisión de cada agente— ahora es simplemente el log. Cada intención, cada resultado, con su sello de tiempo. Cuando un auditor pregunta por qué se marcó un pedido concreto, la respuesta no se reconstruye a partir de la memoria, se lee del registro.
Además, la contrapresión deja de ser un problema. Si un agente productor genera eventos más rápido de lo que el consumidor puede procesarlos, no es un fallo, es un retraso medible. El buffer es el punto: se puede observar cómo crece la cola y escalar en consecuencia. El acoplamiento se vuelve tan laxo que añadir un agente consiste simplemente en agregar un suscriptor; eliminarlo, en quitar un suscriptor; cambiar la implementación de un agente por completo sin que nadie arriba se entere, porque solo estaban hablando con el tema. El grafo de dependencias deja de ser código que mantener y se convierte en configuración de enrutamiento.
La objeción habitual es que se añade un salto de red y un broker que gestionar. Es cierto: una llamada directa tiene menos latencia que publicar y consumir. Pero el coste real de la arquitectura síncrona no son los milisegundos, sino la fragilidad y la ceguera. Los flujos de trabajo con agentes de IA no están limitados por la latencia de red, sino por los segundos que tarda una inferencia o una llamada a herramienta. Ahorrar un salto de broker en un camino que ya gasta tres segundos en un bucle de razonamiento es un error de redondeo. Lo que realmente importa es poder saber qué pasó y que el sistema no se caiga todo a la vez. Un evento que se puede repetir vale más que un milisegundo ahorrado.
Por supuesto, hay compromisos reales. Ahora hay que operar un broker: Kafka, NATS, SQS o Redis Streams, según la escala. Hay que diseñar para consistencia eventual y consumidores idempotentes —de ahí que el esquema incluya un campo de idempotencia. Y los patrones request/response, donde se necesita una respuesta inmediata para continuar, se modelan como un evento de solicitud y otro de respuesta correlacionados, lo que parece más trabajo hasta que se necesita repetir uno de ellos. Para intercambios genuinamente síncronos, de baja latencia y entre dos partes, una llamada directa sigue siendo válida. El problema no es la existencia de llamadas, sino la malla de agentes que se bloquean mutuamente.
En Q2BSTUDIO, llevamos años aplicando estos principios en el desarrollo de aplicaciones a medida para empresas que necesitan sistemas robustos y escalables. Sabemos que la arquitectura basada en eventos no es una moda, sino una necesidad cuando se trabaja con inteligencia artificial y agentes autónomos. Nuestro equipo integra estas soluciones con servicios cloud en AWS y Azure, garantizando ciberseguridad y trazabilidad en cada capa, y complementa la toma de decisiones con tableros de Business Intelligence en Power BI. No se trata de evitar las llamadas directas por dogma, sino de entender que la conversación entre agentes es el activo más valioso del sistema, y debe quedar registrada, no volatilizarse en la RAM.
La próxima vez que te sientas tentado a cablear el agente A directamente con el agente B, hazte una pregunta: cuando esto se cuelgue a las tres de la madrugada, ¿qué tendré que leer para entender qué pasó? Si la respuesta es un volcado de pila, has construido mal el sistema. Pon un registro en medio y deja que los agentes dejen un rastro de papel. No dejes que tus agentes de IA se llamen directamente. El broker no es un extra, es la pieza que sobrevive.
