Dominar los sub-workflows de n8n puede hacerte peligrosamente bueno en IA
The agent
Writes one string: "everything about animals"
Inside the sub-workflow
- List 15 chaptersIDs and summaries only
- Pick 1 to 3Small model, structured output
- Fetch thoseBy record ID
- Strip the restTitle and content, nothing else
What comes back
Two chapters, cleaned. The large model never saw the other thirteen.
Un sub-workflow en n8n es un flujo de trabajo cuyo disparador es When executed by another workflow. Defines lo que entra, construyes los pasos y el resultado del último nodo es lo que recibe quien lo llama.
Es una función, o un microservicio si prefieres esa palabra. Puedes construirlo todo sin usar nunca uno, que es la razón por la cual mucha gente no lo hace.
Quiero hacer una afirmación más ambiciosa de lo que sugiere el título del vídeo. Dominar esto no es una habilidad de n8n. Es donde aprendes, en un lienzo donde cada paso es visible, las cuatro cosas que deciden si algo que construyes con IA es rentable: dividir un trabajo repetitivo en pasos, dar a cada paso solo el contexto necesario, elegir un modelo por paso y dejar de delegar decisiones a un agente una vez que ya conoces el orden. n8n no es el tema. Es el lugar donde esas cuatro cosas son más fáciles de ver.
Los sub-workflows son útiles para dos cosas. La primera es la obvia y te ahorra mantenimiento. La segunda es la que me enseñó todo esto.
La ventaja aburrida: construirlo una sola vez
Ejemplo de operaciones de ventas. Un flujo de trabajo gestiona las solicitudes de demostración. Otro procesa un CSV de asistentes a un evento. Ambos, en algún momento, necesitan enriquecer un lead: tomar un correo electrónico, obtener la empresa y el sector de un proveedor de datos, hacer que un modelo resuma la actividad de la empresa y calificar el lead.
Eso son cinco o seis nodos. Podrías construirlos en el flujo de solicitudes de demostración, luego volver a construirlos en el flujo del CSV y repetirlo en los otros ocho lugares que acaben necesitando lo mismo.
Llamadas
- Flujo de solicitudes de demo
- CSV de asistentes a eventos
- Otros ocho flujos de trabajo
Enriquecer un lead
- Entrada: un correo electrónico
- Apollo para firmografía
- Un modelo para el resumen y la puntuación
- Salida: los campos que necesita el CRM
Siguiente paso
- Crear registro en el CRM
- Notificar por Slack
- Añadir a una hoja de cálculo
La recompensa llega a los seis meses, cuando el proveedor de datos cambia o alguien quiere un campo más en la salida. Editas un solo flujo de trabajo y todos los que lo llaman se actualizan.
La ventaja interesante: una herramienta que devuelve solo lo importante
Este es el escenario. Un curso de biología está en Airtable: 15 capítulos, cada uno con un nombre, un resumen y el contenido completo. Un agente responde preguntas sobre él.
Este agente ya es mejor que la versión básica. Tiene dos herramientas en lugar de un volcado masivo de datos: buscar en todos los capítulos, que devuelve solo IDs y resúmenes, y obtener el contenido de un capítulo. El prompt del sistema le indica que lea primero los resúmenes, elija de uno a tres capítulos y luego los solicite.
Ese diseño de dos pasos ya supone la mayor parte de la mejora.
Palabras que llegan al modelo por una pregunta sobre animales
Entonces, ¿por qué cambiar algo? Por dos razones, y ninguna tiene que ver con el recuento de palabras.
El modelo grande se ejecuta una vez por llamada a la herramienta
Analicemos una ejecución. GPT-5.1 está conectado, es caro y es bueno, y fue llamado tres veces: una para decidir buscar capítulos, otra para decidir obtener el contenido y otra para redactar la respuesta.
Cada una de esas llamadas incluye el mensaje del sistema y la memoria acumulada de los resultados de las herramientas anteriores. La entrada crece en cada turno.
Dos de esas tres llamadas no requirieron un razonamiento que justificara un modelo caro. Simplemente eligieron qué capítulos parecían relevantes a partir de una lista de resúmenes.
La herramienta devuelve campos que no has pedido
La herramienta Get Record de Airtable no tiene filtro de campos. Si pides el contenido completo de un capítulo, también recibes el nombre, la fecha de creación y el resumen, datos que ya tenías de la primera llamada y que ahora duplicas.
Eso no se puede solucionar en la herramienta. Se puede solucionar un paso después, si existe ese paso.
Un subflujo para gestionar toda la recuperación
Elimina ambas herramientas. Sustitúyelas por una única herramienta de subflujo que pase de un tema al contenido completo de los capítulos correctos.
Sub-workflow, herramienta para agente
- Recuperación de capítulosTrigger. Entrada: temas a buscar, una cadena
- Buscar todos los capítulosAirtable. Los 15, con sus resúmenes
- Limpiar salidaSolo ID de registro y resumen, y renombrar id a record_id
- AgregarLos 15 resúmenes como un solo elemento
- Elegir capítulosNodo de IA, no un agente. Modelo pequeño, salida estructurada: 1 a 3 IDs de registroChat ModelModelo pequeñogpt-4.1-mini
- Split OutUn elemento por cada capítulo a recuperar
- Obtener contenido del capítuloAirtable, por ID de registro
- Limpiar y agregarTítulo y contenido completo, nada más
El paso de selección es en el que vale la pena detenerse. Su prompt de sistema es una sola frase: el mensaje del usuario indica un tema, encuentra de uno a tres capítulos relevantes, y aquí tienes la lista completa de capítulos con sus resúmenes. Su salida estructurada es una lista de IDs de registro.
Se trata de una tarea de clasificación frente a una lista de 15 resúmenes. GPT-4.1 Mini lo hace correctamente y rápido, y nunca pago precios de modelos frontera por ello.
- Antes: decidir listar capítulosModelo grandellamada 1
- Antes: decidir cuáles recuperarModelo grande, memoria incluidallamada 2
- Antes: escribir la respuestaModelo grandellamada 3
- Después: llamar a la única herramientaModelo grande escribe una cadena de temallamada 1
- Después: el sub-workflow clasificaModelo pequeño, salida estructuradabarato
- Después: escribir la respuestaModelo grandellamada 2
Llamadas a modelo grande3 a 2
Y debido a que hay un nodo Set entre Airtable y la salida, devuelvo el título del capítulo y el contenido completo. No viaja nada más.
El prompt de sistema del agente también se vuelve más corto, y no esperaba que esto importara tanto como importa. Ahora es: responde basándote en el curso de biología, llama siempre primero a esta herramienta y luego responde solo con lo que te haya dado. Una herramienta, sin reglas de orden, nada que pueda salir mal.
El mismo truco en una herramienta de búsqueda web
Segundo ejemplo, misma estructura. Un agente con una herramienta de búsqueda web, en mi caso Linkup, aunque Perplexity o cualquier otra herramienta se comporta igual.
Si conectas la API directamente, te topas con dos problemas. Acepta una pregunta por llamada, por lo que una pregunta amplia debe hacerse por partes, un viaje de ida y vuelta cada vez. Y la respuesta incluye la lista completa de fuentes, que acaba en el contexto quieras o no.
Sub-workflow, herramienta de búsqueda web
- Búsqueda webTrigger. Entrada: consultas web, un array
- Split OutUn elemento por pregunta
- API de LinkupEjecución en paralelo. Esta API tarda unos 10 segundos por llamada
- Limpiar salidaMantener la consulta y la respuesta, eliminar la lista de fuentes
- AgregarUn elemento de vuelta al agente
Pregunta algo como cómo encajan el SEO y la optimización de motores generativos en 2026, y el agente lo divide solo en tres búsquedas: tendencias y estrategias, cómo optimizar para ambos y mejores prácticas según el tamaño de la empresa. Una llamada a la herramienta, tres búsquedas paralelas, un solo elemento agregado y limpio de vuelta.
API como herramientaUna pregunta por llamada
- Tres sub-preguntas implican tres llamadas a la herramienta
- Se ejecutan una tras otra
- Toda la lista de fuentes entra en el contexto
Sub-workflow como herramientaUn array de preguntas
- Tres sub-preguntas en una sola llamada
- Split out y luego ejecución en paralelo
- Mantiene la consulta y la respuesta, elimina las fuentes
Es un único esqueleto, no tres workflows
Construí un tercero de estos para un agente RAG, sobre un curso vectorizado en Supabase. Se ve diferente en el lienzo, pero es lo mismo otra vez.
- TriggerAcepta un array, por lo que una llamada a la herramienta cubre varias preguntas
- Split OutUn elemento por pregunta
- Acceder a la fuenteAirtable, una API, un almacén de vectores. En bucle o en paralelo
- LimpiarMantener los campos que el modelo necesita, eliminar todo lo demás
- FiltrarSolo cuando la fuente ofrece algo para clasificar
- AgregarUn elemento, con la pregunta y sus resultados emparejados
El filtro es el paso que los otros dos no tienen, y está ahí porque un almacén de vectores devuelve una puntuación de similitud y Airtable no. Cuando la fuente te da un número, puedes descartar los resultados que no son lo suficientemente buenos. En ese workflow el límite es 0.4, y cualquier cosa por debajo nunca llega al agente.
Dos cosas que aprendí construyendo el tercero y que ahora aplicaría en todos.
Nombra los campos de salida. El agregado al final no produce un bloque anónimo, produce un campo llamado Knowledge base retrieval, y dentro de él, cada entrada empareja Query to the knowledge base con Chunks returned. El modelo lee esos nombres. Entregarle un array y esperar que deduzca qué resultado responde a qué pregunta es un coste que se paga en la respuesta final.
Indica cuando no hayas encontrado nada. Un filtro que elimina todo no produce elementos, y sin elementos el siguiente nodo nunca se ejecuta y el agente recibe silencio. Por eso hay un IF después del filtro, y su rama vacía escribe una frase: nada alcanzó el umbral de relevancia para esta consulta. En n8n, esto también implica configurar el filtro para que siempre devuelva datos, de lo contrario la rama que escribiste para este caso nunca se activa.
Ese segundo paso cambia lo que el agente puede hacer. Su prompt de sistema termina con la instrucción de decir que no lo sabe en lugar de responder basándose en conocimientos generales, y esa instrucción solo es sincera si la recuperación posterior es sincera al devolver un resultado vacío.
Nada de esto trata realmente sobre n8n
Los tres hacen lo mismo: intercalan pasos entre el agente y la respuesta bruta, y en esos pasos descartan información. He aquí por qué creo que esto vale más que un flujo de trabajo.
Dividir una tarea repetitiva en pasos es la clave. Una tarea que ejecutas una sola vez puede ser descuidada. Una tarea que ejecutas trescientas veces paga ese descuido trescientas veces, y un agente que decide el orden en cada una de esas ejecuciones es pagar a un modelo para que redescubra un esquema que podrías haber dibujado en un papel. En el momento en que conoces los pasos, escribirlos no es una pérdida de flexibilidad, es el objetivo.
Cada paso recibe el contexto que necesita y nada más. Eso es lo que hace cada nodo de limpieza de este artículo. Es también lo que medí con Jev: colocar un pequeño clasificador delante de un agente para decidir qué habilidades precarga y eliminar los campos que nunca leerá de cada respuesta de la herramienta resultó un 29 % más barato de media y un 61 % en la mejor tarea, sin pérdida de calidad. Misma idea, un nivel más arriba. El contexto no es gratuito y la mayor parte de lo que llega en él nunca llegaría a leerse.
El modelo adecuado para cada paso. Una tarea de clasificación frente a quince resúmenes no requiere el modelo más avanzado. Una vez que los pasos están separados, esto deja de ser una opinión y se convierte en un ajuste que puedes cambiar por nodo.
Orquestar, en lugar de delegar. Los pasos deben pasarse entre sí algo útil, por eso los campos de salida tienen nombre y por eso un resultado vacío lo indica explícitamente. Eso es orquestación, y es la parte que un agente hace de forma invisible y deficiente.
Es el mismo razonamiento que me hizo dejar de usar MCP en cualquier cosa que repita: un script contra la API puede hacer el filtrado, el mapeo y el bucle sin un modelo en medio, y MCP no puede, porque el modelo es el medio.
Los agentes ocultan estos cuatro puntos, que es exactamente por qué merece la pena haber construido uno a mano. Cuando estoy en Claude Code y algo parece lento o caro, lo que busco es el paso que devolvió todo cuando yo solo necesitaba tres campos. Casi siempre está ahí, y solo sé buscarlo porque una vez conecté ese paso yo mismo y observé el recuento de tokens.