Orquestación multiagente en n8n: equipos de agentes para pymes

El agente lleva tres meses funcionando y cada semana lo hace un poco peor. Al principio redactaba ofertas a partir de cuatro puntos sueltos y la cosa salía decente. Después llegaron los precios del ERP, luego los plazos de entrega, más tarde el historial de clientes y, al final, la aprobación por correo. Hoy arrastra 34 herramientas en un único agente, el prompt ha crecido hasta los 4.000 tokens y la tasa de acierto ronda, a ojo, dos de cada tres intentos. El coste por ejecución ha subido un 180 por ciento en ese mismo periodo. El agente no está roto. Está sobrecargado.

El patrón no es una excepción, sino la curva típica de cualquier proyecto de automatización ambicioso: todo lo que de una forma u otra tiene que ver con el proceso acaba dentro del mismo agente, porque al principio así se va más rápido. En algún momento la cosa se tuerce, y no en silencio, sino con cifras equivocadas en ofertas de verdad.

En este artículo vas a ver por qué el agente que lo hace todo está condenado a fallar, cómo se monta un coordinador con tres especialistas, cómo se cablea eso en n8n de forma concreta, cuánto dinero ahorra y cómo pasar en cinco días de un agente sobrecargado a un equipo pequeño de agentes.

---

Índice

1. Por qué fracasa el agente que lo hace todo
2. El patrón: un coordinador, varios especialistas
3. En la práctica: cablear tres agentes en n8n
4. Costes, modelos y métricas
5. Cinco días para llegar al equipo de agentes
6. Conclusión

---

Por qué fracasa el agente que lo hace todo

La pyme alemana ya ha pasado la fase de prueba. El Índice de IA para la mediana empresa 2026, elaborado por Salesforce junto con la Asociación Alemana de la Mediana Empresa, sitúa en el 51,2 por ciento las empresas encuestadas que usan o prueban IA, un 54 por ciento más que el año anterior. El dato más interesante está al lado: el 16,6 por ciento ya emplea agentes de IA, frente al 8,7 por ciento del ejercicio previo. Y menos del cinco por ciento ha cancelado un proyecto de IA. La tecnología ha llegado; la desilusión aparece en otro sitio.

Aparece donde un piloto se convierte en operación diaria. Un estudio de T-Systems publicado en septiembre de 2026 marca la dirección: el 91 por ciento de las empresas punteras analizadas usa asistentes de conocimiento y el 83 por ciento genera documentos de forma automatizada. Son tareas de alcance limitado, con entradas claras y salidas verificables. Sven Giesselbach, CTO de AI and Data en T-Systems International, resume bien el criterio: no decide lo que es técnicamente posible, sino la utilidad concreta con un riesgo controlable. Un agente sobrecargado es justo lo contrario, porque su riesgo crece con cada capacidad nueva mientras la utilidad no avanza al mismo ritmo.

Técnicamente hay tres causas, y siempre aparecen juntas.

La elección de herramienta se convierte en una lotería. Un agente con 34 herramientas tiene que decidir en cada petición cuál le sirve. Cada opción adicional aumenta la probabilidad de elegir mal, y los errores se acumulan, porque una herramienta mal escogida condiciona todo lo que viene después.

El contexto se convierte en un vertedero. Cuando los datos del ERP, el historial de clientes, las listas de precios y las instrucciones de estilo comparten el mismo prompt, compiten por la misma atención. Reglas importantes, del tipo “ningún descuento por debajo del 12 por ciento sin aprobación”, se pierden entre plazos de entrega y pautas de tono. No es un fallo del modelo, es la consecuencia de que ya nadie sabe qué información importa de verdad en cada situación concreta.

Cada cambio afecta a todo. Si quieres los textos de oferta de otra manera, tocas el prompt y de repente el agente calcula distinto. Ese acoplamiento es el verdadero generador de costes en operación, porque cada ajuste mínimo obliga a una prueba de regresión completa sobre todas las capacidades.

A eso se suma la palanca del coste. Un agente todoterreno casi siempre corre sobre el modelo más grande disponible, porque tiene que estar preparado para la más difícil de sus tareas. Que el 80 por ciento de sus llamadas sean clasificaciones triviales no lo paga nadie.

El patrón: un coordinador, varios especialistas

La arquitectura contraria se llama orquestación, no es nueva y rara vez se implementa con limpidez. En lugar de un agente con muchas herramientas hay un agente con pocas herramientas, y cada una de ellas es otro agente.

El coordinador tiene una única tarea: entender la petición y pasarla al especialista adecuado. Maneja entre tres y cinco herramientas, y cada una es un subflujo completo. No investiga, no calcula, no redacta. Su salida es una decisión, no un contenido.

Los especialistas tienen una tarea cada uno, un prompt corto y solo las herramientas que necesitan para eso. El agente de investigación lee adjuntos de correo y datos maestros. El de cálculo trabaja con una fórmula fija y lee la lista de precios. El de redacción formula a partir de un encargo estructurado. Ninguno conoce el prompt de los demás.

Entre los agentes hay un traspaso en formato fijo. Aquí es donde falla la mayoría de las implementaciones: dejan que los agentes hablen entre sí en texto libre. Un coordinador que escribe “pásale esto a cálculo” no ha ganado nada, porque el receptor tiene que volver a interpretar. El traspaso debe ser un objeto con campos fijos que se valida antes de que arranque el siguiente agente.

Y hace falta una vuelta atrás con condición de corte. Cualquier especialista puede decir “esto no puedo”, por ejemplo si falta un campo obligatorio. Esa respuesta vuelve al coordinador, que entonces pregunta o deriva a una persona. Sin esa vuelta atrás aparece el peor estado posible: un agente que se inventa la información que falta para poder terminar la tarea.

El efecto no es solo calidad, es también trazabilidad. Si mañana una oferta sale mal, puedes leer la cadena: qué detectó el coordinador, qué entregó el agente de investigación, qué calculó el de cálculo, qué redactó el de texto. Con un monolito solo tienes un prompt y un resultado. Cómo trazar aprobaciones y límites con criterio en una cadena así lo explicamos a fondo en Permisos para agentes de IA: derechos y límites.

En la práctica: cablear tres agentes en n8n

El ejemplo es deliberadamente cotidiano: una oferta a partir de una consulta de cliente. Hasta ahora lo hace un agente todoterreno; ahora lo asumen tres especialistas.

El montaje en n8n. El flujo principal contiene el nodo AI Agent con tipo de agente “Tools Agent” y el modelo más pequeño que sepa clasificar con fiabilidad. Como herramientas cuelgan de él tres nodos “Call n8n Workflow Tool” que apuntan a tres flujos separados: agent_recherche, agent_kalkulation y agent_text. Cada uno de esos flujos es una pieza propia y testeable, con su prompt, sus credenciales y su gestión de errores.

El traspaso como contrato. El coordinador no devuelve un objeto de texto corrido, sino uno estructurado. En n8n eso se resuelve con el Structured Output Parser y un esquema JSON, o con un nodo Code que valida la salida y corta si algo no encaja. El nodo Code es el camino más robusto, porque deja la validación documentada:

// Nodo Code "Validar traspaso"
const d = $json;

const obligatorios = ['kunde', 'leistung', 'menge', 'quelle'];
const faltantes = obligatorios.filter(f => d[f] === undefined || d[f] === null || d[f] === '');

if (faltantes.length > 0) {
  return [{ json: {
    status: 'rueckfrage',
    fehlende_felder: faltantes,
    grund: 'Solicitud incompleta, no se inició el cálculo'
  }}];
}

if (typeof d.menge !== 'number' || d.menge <= 0) {
  return [{ json: {
    status: 'rueckfrage',
    fehlende_felder: ['menge'],
    grund: 'La cantidad no es un número positivo'
  }}];
}

return [{ json: {
  status: 'ok',
  auftrag: {
    kunde: d.kunde,
    leistung: d.leistung,
    menge: d.menge,
    quelle: d.quelle,
    eingegangen: d.eingegangen ?? new Date().toISOString()
  }
}}];

El nodo IF que viene después comprueba status. Si es rueckfrage, el flujo se va por una rama que manda un correo a ventas y termina la ejecución sin calcular absolutamente nada. Si es ok, arranca el flujo de cálculo. Esas pocas líneas evitan en la práctica más dolores de cabeza que cualquier mejora de prompt, porque atajan el caso de error más frecuente: una solicitud que llega formalmente correcta y es inútil en el contenido.

El agente de cálculo no calcula con el modelo. Esta es la parte más importante y la que más se hace mal. Los precios, los tramos de descuento y los márgenes pertenecen a un nodo Code o a una fórmula, no a un prompt. El modelo decide qué posición de la lista de precios encaja y entrega el ID de la posición. El cálculo lo hace JavaScript. La misma entrada lleva así siempre al mismo precio, y puedes revisar cualquier importe sin interrogar a un modelo.

El agente de redacción recibe solo el encargo terminado. Ve cliente, servicio, cantidad, precio y una indicación de tono. No ve la lista de precios ni las reglas de cálculo. Por eso no puede alterar precios, aunque quisiera. Ahí está la razón de que la cadena se mantenga estable: cada agente tiene solo la información que necesita para su tarea.

La aprobación sigue siendo humana. El agente de redacción entrega un borrador que queda en una cola. Se envía después de la aprobación. Cómo tratar los errores que nadie detecta lo contamos en Producción: detectar fallos silenciosos.

Consejo práctico: monta primero el coordinador con una sola herramienta y pruébalo dos semanas con solicitudes reales. Cuando la asignación sea correcta, es decir, cuando acierte el especialista en al menos nueve de cada diez casos, añade los demás. Quien arranca con tres especialistas a la vez no puede distinguir, cuando algo falla, si el problema está en el coordinador o en un especialista.

Costes, modelos y métricas

La orquestación también es un argumento de coste, y uno contundente. Un cálculo publicado en la comunidad de n8n en junio de 2026 compara un monolito sobre el modelo grande con un coordinador que enruta clasificación y pasos simples a un modelo pequeño: de 26,40 dólares por cada 1.000 ejecuciones se pasa a 8,80 dólares. Es un valor orientativo de una instalación ajena, no una medición propia, y las cifras se mueven con los precios y con la longitud del prompt. La dirección, aun así, se mantiene estable, porque el mecanismo es evidente: en un monolito todas las llamadas van al modelo caro; en una cadena, solo las que lo necesitan.

Tres reglas bastan para controlar el gasto.

El modelo más pequeño al principio. Clasificar, es decir, responder a “¿de qué va esto?”, es la tarea más barata de la cadena y no necesita un modelo de gama alta. Pero decide la mayor parte del coste, porque ocurre en cada ejecución.

El modelo grande solo para lenguaje. La redacción es la tarea en la que las diferencias de calidad entre modelos se notan ante el cliente. Todo lo demás, calcular, validar, asignar, se resuelve de forma determinista y por tanto es independiente del modelo.

Tokens por ejecución como indicador. Anota para cada agente los tokens medios por ejecución y el número de ejecuciones semanales. Con esas dos cifras ves si un agente se está encareciendo en silencio. En casi todos los casos crece el contexto, no la carga de trabajo.

A eso se suman tres límites técnicos que hay que fijar antes de la primera ejecución en producción. maxIterations por agente acota los bucles en los que un agente retoca su propio resultado hasta que le vale. Un timeout por subflujo impide que un especialista colgado bloquee toda la cadena. Y una rama de fallback por especialista define qué pasa cuando falla dos veces seguidas: consulta a una persona, no un tercer intento.

Cinco días para llegar al equipo de agentes

Día 1: descomponer. Escribe cada tarea de tu agente sobrecargado en una tarjeta: ¿qué hace realmente? Ordena las tarjetas en dos montones, “entiende y decide” y “ejecuta”. El primero será el coordinador; el segundo, los especialistas. En la mayoría de los casos quedan tres o cuatro tarjetas que en realidad son una sola tarea. Esas van a un agente, no a tres.

Día 2: construir el coordinador. Un agente, un modelo, como máximo cinco herramientas, y cada herramienta un subflujo. Valida el traspaso con un nodo Code como el de arriba. Prueba con diez solicitudes reales sacadas del buzón y anota cuántas veces eligió la rama correcta. Por debajo de nueve de diez: afina el prompt del coordinador, no toques a los especialistas.

Día 3: poner en producción el primer especialista. Elige el de resultado más claro, normalmente el de cálculo, porque ahí se pueden separar números y validación. Todas las cifras en código; el modelo solo elige posiciones. Compara veinte resultados a mano con el camino antiguo. Las desviaciones aquí no son errores de redondeo, son errores en tu descomposición.

Día 4: conectar el segundo y el tercer especialista. Ahora sí, con el coordinador funcionando y el traspaso validado. Define por especialista maxIterations, timeout y rama de fallback. Un agente que no responde tiene que cerrar la cadena con limpieza, no dejarla colgada.

Día 5: medir en lugar de esperar. Fija tres cifras que revisarás cada semana: tasa de acierto en la asignación, porcentaje de ejecuciones con corrección humana y tokens por ejecución. Añade el coste por caso resuelto, no por ejecución, porque esa es la cifra que al final cuenta en la oferta. Si esos cuatro valores se mantienen estables dos semanas, tienes una operación y no un experimento.

La parte que perdura: un especialista nuevo es una ampliación, no una reforma. Ahí está la ganancia real. Puedes cambiar el agente de investigación por uno mejor sin tocar el de redacción, y puedes sumar un especialista para otra tarea sin reescribir el prompt del coordinador. Un monolito no permite eso, porque en él cada cambio es un cambio en todo. Hacia dónde evoluciona esta cuestión con varios agentes y varios departamentos lo desarrollamos en Agentes de IA para empresas: qué funciona de verdad en 2026.

Conclusión

El agente todoterreno no es una mala idea, es una etapa intermedia. Al principio es el camino más rápido hacia un resultado, y así está bien. Desde el momento en que entra en operación se convierte en un problema, porque capacidades, contexto y costes se compensan dentro de un único prompt sin que nadie pueda ya leer esa cuenta.

Un coordinador con tres especialistas lo resuelve, no porque sea más moderno, sino porque separa lo que debe estar separado: decidir, calcular, redactar. Cada pieza se puede revisar por su cuenta, cambiar por su cuenta y apagar por su cuenta. El precio es un esfuerzo extra al principio, más o menos un día más de lo que costó el monolito.

Si quieres saber a qué distancia está tu agente actual de esta arquitectura: revisamos contigo tu ecosistema de agentes, lo descomponemos siguiendo estas líneas y montamos la cadena de forma que siga siendo legible dentro de doce meses. Nuestro propio enfoque está en Sistema B.R.A.I.N., y si necesitas la implementación como proyecto, el siguiente paso es nuestros servicios.

Sobre MadeByBrain: construimos automatización con IA para pymes, agentes de IA propios, flujos de n8n y estrategias de GEO, en uso real. De la primera idea a la automatización en producción.

Solicita una consultoría gratuita