Ocho asistentes de IA que una agencia usa desde Slack

El reto

Los flujos de la agencia necesitaban un despachador, y el despachador era una persona. Las solicitudes llegaban como pedidos generales: necesitamos un plan de campaña para este cliente, dennos una ronda de conceptos, averigüen qué se está diciendo de esta marca. Cada uno se descomponía en un conjunto distinto de subtareas, en un orden distinto, según lo que se estuviera pidiendo.

Esa es justo la parte que la automatización convencional maneja mal. Se puede construir un flujo lineal para cualquiera de esas solicitudes, y la agencia ya tenía varios. Lo que no puede hacer es decidir cuál correr. Alguien con experiencia tenía que leer el pedido, descomponerlo y repartir las piezas, así que el trabajo estaba limitado por la atención de esa persona y se detenía por completo cuando estaba ocupada.

El enfoque

Movimos la decisión de enrutamiento hacia adentro del sistema, en vez de dejarla enfrente.

El diseño es un agente maestro con una red de especialistas debajo. El agente maestro interpreta la solicitud que entra y decide qué especialistas necesita y en qué orden. Cada especialista se mantiene acotado, porque un agente con una sola tarea es mucho más fácil de hacer confiable que uno general, y mucho más fácil de corregir cuando se equivoca.

Dos decisiones definieron el resto. La interfaz es Slack, porque ahí es donde la agencia ya trabajaba y una automatización que exige ir a un lugar nuevo suele durar una semana. Y la selección de modelo ocurre por paso y no una sola vez para toda la plataforma, porque un paso que clasifica un mensaje y un paso que redacta un plan de campaña no quieren el mismo balance entre costo, latencia y calidad de razonamiento.

La solución

Una plataforma, construida por capas.

Un agente maestro que lee la solicitud. Toma el pedido general que llega por Slack, resuelve en qué se descompone realmente y delega esas subtareas en la red. Nada de una solicitud tiene que estar registrado de antemano como una forma que el sistema ya conozca.

Ocho asistentes especializados. Cubren planeación de negocio, minería de datos de redes sociales y generación de piezas creativas. Cada uno es dueño de una parte del trabajo de la agencia y lo invoca el agente maestro, aunque una persona todavía puede ir directo a uno cuando sabe exactamente qué quiere.

Más de diez flujos en n8n, con orquestación de subflujos anidados. Un flujo puede llamar a otro flujo en vez de repetir sus pasos. Eso es lo que mantiene manejable la red de agentes a este tamaño: las piezas compartidas existen una sola vez, y el agente que necesita una la llama.

Selección de modelo con OpenRouter. Cada paso se enruta al modelo que le conviene, balanceando costo, latencia y calidad de razonamiento, y cambiar un paso a otro modelo es un cambio de configuración.

Generación de imagen y video dentro del flujo. Midjourney y Kling se operan desde los mismos pipelines, así que un pedido que termina en piezas visuales las produce sin salir de la conversación donde empezó.

Resultados

La agencia dejó de enrutar el trabajo a mano. Ocho asistentes corren detrás de una sola conversación de Slack, sobre más de diez flujos orquestados, y una solicitud que antes necesitaba una persona que la descompusiera ahora la descompone el sistema.

Ahora la parte honesta, que importa más que la arquitectura. Este proyecto nunca se instrumentó. Nadie midió cuánto tomaban estas solicitudes antes de que existiera la plataforma, así que no hay una cifra de antes y después que reportar, y no la vamos a inventar. Los dos números de arriba son conteos de lo que se construyó, no afirmaciones sobre lo que ahorró.

Esa es una limitación real de este caso de estudio, no una cuestión de estilo. Todos los demás proyectos de este sitio arrancan con una cifra que se registró al inicio y se volvió a medir al final. Este hay que leerlo por la arquitectura, y por si esa arquitectura calza con un problema que reconoces, y no por un resultado que no puede evidenciar.

Qué lo hizo difícil

La descomposición es todo el riesgo. Un agente maestro que parte mal una solicitud no falla de forma ruidosa. Produce una respuesta plausible a una pregunta que nadie hizo, y a quien la recibe le toca darse cuenta de que es, sutilmente, el entregable equivocado. Lograr que el agente maestro descompusiera como lo haría una persona con experiencia, y que se detuviera en vez de adivinar cuando el pedido era genuinamente ambiguo, tomó más iteración que cualquier especialista individual.

La orquestación anidada hizo más difícil ubicar los errores. Cuando un flujo llama a un flujo que llama a otro flujo, una falla tres niveles abajo llega arriba sin su contexto, a menos que las capas estén construidas para arrastrarlo. Eso se diseña desde el principio, no se agrega después de la primera falla confusa.

La generación de piezas es la parte sobre la que hay que ser franco. Midjourney y Kling no tenían una interfaz programática soportada para lo que se necesitaba, así que la integración va por soluciones alternas sobre APIs no oficiales. Funciona, y está haciendo trabajo real, pero no es un contrato estable: un cambio del lado del proveedor la puede romper sin aviso y sin período de transición. El cliente eligió ese tradeoff sabiendo lo que implicaba, y quien esté sopesando el mismo debería sopesarlo como costo de mantenimiento y no como una construcción de una sola vez.