1. Introducción: la promesa entre workflows

Descripción

Al terminar esta lección vas a poder explicar por qué un sistema con más de un workflow es, en el fondo, un sistema de promesas entre workflows; vas a saber qué es un contrato de workflow a nivel intuitivo y por qué existe aunque nadie lo haya escrito; y vas a tener el mapa completo de las ocho lecciones de este módulo. También vas a reencontrarte con Cumbre, la distribuidora que acompaña toda la guía, y con su workflow order-triage, que en este módulo deja de trabajar solo y empieza a llamar a otros workflows.

Esto importa por una razón muy concreta: en los dos módulos anteriores tu preocupación fue un solo workflow que se disparaba dos veces. Aprendiste a ver el problema del duplicado y aprendiste a volver idempotente un efecto para que repetir no duplicara. Pero apenas tu sistema crece más allá de un workflow, aparece un problema nuevo que la idempotencia no resuelve: los workflows empiezan a llamarse entre sí, y cada llamada es una promesa. Uno pasa datos, el otro los recibe y devuelve un resultado. Esa promesa —qué campos van, con qué tipos, cuáles son obligatorios y qué forma tiene la respuesta— es un contrato. Y como todo contrato que nadie puso por escrito, se rompe en el peor momento y en silencio: alguien cambia un campo en un workflow, y otro workflow que dependía de ese campo empieza a fallar sin que nada grite.

Conexión con el módulo: esta lección no te enseña todavía a escribir ni a validar un contrato. Es el mapa. Aquí defines el problema —por qué un sistema de varios workflows es un sistema de contratos—, conoces la herramienta que los conecta —el nodo Execute Sub-workflow— y recuperas el caso de estudio con su primer sub-workflow, check-credit. La lección 2 define con precisión qué es un contrato de workflow. Las lecciones 3 a 6 te dan las piezas: diseñar el esquema, cruzar la frontera del Execute Sub-workflow, validar en esa frontera y versionar sin romper. La lección 7 lleva el mismo contrato al terreno de MCP y las herramientas de agente. Y la lección 8 cierra construyendo un sub-workflow validado con contrato de punta a punta. Una nota de límite desde ya: aquí no vas a coordinar muchos workflows dependientes entre sí —eso es el Módulo 5— ni a decidir dónde vive el estado del sistema —eso es el Módulo 4—. Este módulo es sobre la promesa entre dos workflows: cómo se define, se valida y se versiona.

De un workflow solitario a un sistema que conversa

Piensa en un restaurante. Cuando pides un plato, no entras a la cocina, no revisas cómo está organizado el refrigerador ni le explicas al cocinero con qué sartén freír. Miras el menú, dices "una arrachera término medio", y confías en que va a llegar algo reconocible: una arrachera, cocida a término medio, en un plato. El menú es una promesa. Del lado del comensal dice qué puedes pedir y con qué palabras; del lado de la cocina dice qué tienen que saber preparar. Mientras esa promesa se respete, el comensal y la cocina pueden cambiar cada uno por su cuenta: el cocinero puede estrenar un cuchillo nuevo, y al comensal no le afecta, porque lo que le prometieron —la arrachera— no cambió.

Ahora quítale el menú al restaurante. El comensal tiene que gritar hacia la cocina describiendo lo que quiere con las palabras que se le ocurran, y la cocina tiene que adivinar. Un día el comensal dice "carne roja" y le llega arrachera; otro día dice lo mismo y le llega un guiso, porque cambió el cocinero y entendió otra cosa. Sin menú, cada pedido es una negociación frágil que depende de que las dos partes casualmente entiendan lo mismo.

Un sistema de automatización con varios workflows es exactamente ese restaurante. Cada vez que un workflow llama a otro, hay un comensal (el que llama) y una cocina (el que responde). El menú es el contrato: qué datos se pasan y qué resultado se devuelve. Y aquí está lo importante, lo que hace que este módulo exista: ese contrato ya existe desde el primer día, lo hayas escrito o no. En el momento en que order-triage le pasa un customer_id y un amount a check-credit, y espera de vuelta un approved, hay un contrato. La única pregunta es si es un contrato que puedes ver, revisar y proteger —un menú colgado en la pared— o un contrato invisible que vive solo en tu memoria y en la forma en que casualmente conectaste los nodos hoy.

El contrato invisible funciona perfecto mientras nadie toca nada. El problema es que los sistemas de automatización viven para ser tocados: agregas un campo, cambias un tipo, renombras algo para que quede "más claro". Y cada uno de esos cambios, sobre un contrato que nadie escribió, es una apuesta a ciegas sobre quién más dependía de lo que acabas de cambiar.

Ejemplo trabajado: la rotura silenciosa

Vamos a ver el problema en su forma más pura, sin todavía enseñar cómo se arregla. Este es el escenario que se repite en toda empresa que crece de un workflow a varios.

Cumbre tiene su workflow order-triage: un Webhook recibe un pedido, un AI Agent lo clasifica, y un HTTP Request lo registra en el CRM. Hasta el módulo anterior, order-triage hacía todo solo. Pero clasificar un pedido incluye una decisión de negocio pesada: ¿el cliente tiene crédito suficiente para este pedido? Esa lógica —consultar el saldo del cliente, restar pedidos pendientes, comparar contra el total— es compleja, se necesita en más de un lugar y conviene poder probarla aislada. Así que el equipo de Cumbre la sacó a un sub-workflow propio: check-credit.

Ahora order-triage llama a check-credit y le pasa esto:

{
  "customer_id": "CUST-118",
  "order_id": "ORD-2041",
  "amount": 1842.50
}

Y espera de vuelta esto:

{
  "customer_id": "CUST-118",
  "approved": true,
  "available_credit": 5157.50
}

order-triage lee el campo approved. Si es true, sigue y registra el pedido; si es false, lo marca para revisión manual. Todo funciona. Nadie escribió el contrato en ningún lado, pero está ahí, vivo, en la forma en que los dos workflows se pasan datos.

Tres semanas después, otra persona del equipo mejora check-credit. Le parece que approved es un nombre pobre —"¿aprobado de qué?"— y lo renombra a credit_approved, que suena más claro. Guarda, publica, y en las pruebas de check-credit aislado todo se ve bien: el workflow corre, devuelve credit_approved: true, perfecto.

Qué esperar. Al día siguiente, order-triage empieza a mandar todos los pedidos a revisión manual. Todos. Los buenos y los malos. Y no lanza ningún error: no hay una raya roja, no hay una ejecución fallida, no hay una alerta. Simplemente, order-triage lee approved, encuentra undefined porque el campo ahora se llama credit_approved, y undefined no es true, así que manda el pedido a revisión. Desde afuera, el sistema "funciona": los workflows corren, no hay excepciones. Solo que el negocio se detuvo, y nadie lo va a notar hasta que un cliente llame preguntando por qué su pedido lleva dos días atorado.

Fíjate en lo que pasó, porque es el corazón de todo el módulo. Nadie hizo nada "mal" en el sentido técnico. La persona que renombró el campo mejoró la claridad de check-credit. El problema es que ese campo era parte de una promesa con order-triage, y romper una promesa que nadie escribió no produce un error ruidoso —produce un sistema que hace lo incorrecto en silencio, que es mucho peor—. Un workflow que se cae te avisa. Un workflow que rompió un contrato te deja creer que todo está bien.

Este módulo entero es sobre convertir ese contrato invisible en uno visible: escrito, validado en la frontera, y versionado de modo que renombrar un campo sea una decisión consciente y segura en vez de una bomba de tiempo.

Por qué la idempotencia no alcanza aquí

Quizás estés pensando: "en el módulo 2 aprendí a hacer las cosas robustas, ¿esto no es lo mismo?". Vale la pena separarlo con cuidado, porque son dos problemas distintos que se confunden todo el tiempo.

La idempotencia —el tema del módulo 2— responde a la pregunta "¿qué pasa si esta operación se ejecuta dos veces?". Es una defensa contra la repetición: que un webhook se dispare doble, que un reintento vuelva a llamar la misma API, que un efecto se aplique más de una vez. La idempotencia vive dentro de un efecto y lo protege de sí mismo.

El contrato —el tema de este módulo— responde a una pregunta completamente distinta: "¿qué pasa cuando dos workflows tienen que entenderse y uno de los dos cambia?". Es una defensa contra el malentendido entre partes. No tiene nada que ver con cuántas veces corre algo; tiene que ver con si el que llama y el que responde siguen hablando el mismo idioma después de que uno de los dos evolucionó.

Piénsalo así: la idempotencia protege a un workflow de repetirse; el contrato protege a dos workflows de dejar de entenderse. Un sistema puede ser perfectamente idempotente —cada efecto se aplica una sola vez, sin importar cuántas veces lo dispares— y aun así romperse por completo porque alguien renombró un campo en un sub-workflow. Los dos problemas se resuelven con herramientas diferentes, y los dos hay que resolverlos. Este módulo es el segundo.

Hay un punto donde se tocan, y lo vas a ver en la lección 5: cuando validas una entrada en la frontera, estás impidiendo que un dato malformado llegue a un efecto. Si ese efecto además mueve dinero —como issue-refund, el sub-workflow que emite reembolsos—, la combinación de un contrato validado y un efecto idempotente es lo que separa un sistema que puedes dejar corriendo de uno que reza. Pero eso es la unión de los dos módulos; primero necesitas el contrato.

El caso de estudio en este módulo: Cumbre, order-triage y sus sub-workflows

Como en toda la guía, trabajamos sobre Cumbre, la distribuidora mayorista latinoamericana de café y té que le vende a unas 400 cafeterías. Si vienes de los módulos anteriores ya conoces su workflow estrella, order-triage, y su forma de recibir pedidos por tres canales de distinta calidad de datos.

Lo nuevo en este módulo es que order-triage deja de ser una isla. A partir de aquí, cuando llega un pedido, order-triage delega decisiones pesadas a sub-workflows especializados:

Sub-workflow	Qué hace	Qué recibe	Qué devuelve
check-credit	Valida si el cliente tiene crédito suficiente para el pedido	customer_id, order_id, amount	approved, available_credit
issue-refund	Emite un reembolso sobre un pedido	order_id, amount, reason	refund_id, status

check-credit es nuestro sub-workflow principal en este módulo: lo vamos a diseñar, documentar, validar y versionar a lo largo de las ocho lecciones, hasta construirlo entero en el proyecto. issue-refund aparece cuando necesitemos hablar de un efecto que mueve dinero y que, por lo tanto, exige un contrato especialmente cuidadoso —porque un reembolso equivocado no se deshace con un botón—.

Los identificadores van en inglés, como en toda la guía y en todo el mercado real: order-triage, check-credit, issue-refund, customer_id, order_id, amount, approved. La prosa que lees va en español; los comentarios dentro del código también. Es la mezcla que vas a encontrar en cualquier equipo de la región.

Una nota honesta, la misma de siempre: los datos de Cumbre son inventados. El límite de crédito, los montos, los nombres de cliente son hipótesis razonables para practicar, no cifras de mercado. Lo que se transfiere de aquí a tu trabajo real no son los números, es la forma de pensar la promesa entre dos workflows.

Cómo se ve una llamada entre workflows, por dentro

Antes de cerrar la introducción, vale la pena mirar la mecánica en cámara lenta, aunque la desarmemos a fondo hasta la lección 4. Necesitas una imagen mental de qué está pasando físicamente cuando un workflow llama a otro, porque sobre esa imagen se apoyan las seis lecciones que siguen.

Una llamada entre dos workflows en n8n tiene tres piezas, y conviene nombrarlas desde ya:

El llamador. Es order-triage. En algún punto de su lienzo tiene un nodo —el nodo Execute Sub-workflow— que dice, en esencia, "detente aquí, ejecuta ese otro workflow con estos datos, y sigue cuando vuelva con su resultado". Ese nodo es el mesero que lleva tu pedido a la cocina y espera en la ventanilla.

La frontera. Es el punto exacto donde order-triage termina y check-credit empieza. Todo lo que cruza esa frontera hacia adentro es la entrada del sub-workflow; todo lo que cruza de vuelta hacia afuera es su salida. La frontera es la ventanilla de la cocina: lo único que pasa por ahí es la comanda y el plato terminado. El comensal no ve la cocina y la cocina no ve la mesa.

El que responde. Es check-credit. Su primer nodo no es un Webhook ni un Schedule; es un trigger especial que existe para una sola cosa: recibir la llamada de otro workflow. Ese nodo es la ventanilla vista desde adentro de la cocina —donde llega la comanda—.

Puesto en un diagrama, la llamada del ejemplo se ve así:

order-triage (el llamador)                     check-credit (el que responde)
──────────────────────────                     ──────────────────────────────
[Webhook]                                       [trigger que recibe la llamada]
   │                                                    │
[AI Agent]                                        (aquí adentro: consultar
   │                                                crédito, comparar, decidir)
[Execute Sub-workflow] ─── entrada ──►                  │
   │            ◄────────── salida ──────────── [último nodo devuelve el resultado]
[HTTP Request al CRM]

Fíjate en lo que ese diagrama hace evidente: el contrato vive exactamente en las dos flechas del centro. La flecha de la entrada es la promesa de qué le manda order-triage a check-credit; la flecha de la salida es la promesa de qué le devuelve check-credit a order-triage. Todo lo demás —cómo está armada la cocina por dentro, qué nodos usa check-credit para consultar el crédito— no es parte del contrato y puede cambiar libremente. Lo único que las dos partes se prometieron son esas dos flechas.

Por eso el renombre de approved del ejemplo trabajado fue tan destructivo: no tocó la cocina, tocó la flecha. Cambiar cómo check-credit calcula el crédito por dentro no habría roto nada; cambiar el nombre de un campo que viaja por la flecha de salida rompió todo. La regla que se destila de aquí, y que vas a ver una y otra vez en el módulo, es simple de decir y fácil de olvidar: puedes cambiar la cocina cuando quieras; la ventanilla es sagrada.

Con esa imagen —llamador, frontera, el que responde, y el contrato viviendo en las dos flechas— tienes lo que necesitas para el resto del módulo. La lección 4 le pone el nombre real a cada pieza en la interfaz de n8n 2.0; por ahora quédate con la forma.

Qué vas a poder hacer al terminar el módulo

La capacidad de salida de este módulo es acotada y concreta. Al final de la lección 8 vas a poder:

• Definir un contrato de entrada y de salida para un sub-workflow: qué campos entran, con qué tipos, cuáles son obligatorios y opcionales, y qué forma tiene la respuesta tanto en el caso de éxito como en el de error.
• Validar ese contrato en la frontera: hacer que el sub-workflow rechace una entrada que no cumple, con un mensaje claro, antes de ejecutar cualquier efecto.
• Versionar el contrato distinguiendo un cambio compatible —que no rompe a quien ya lo llama— de un cambio rompiente, y sabiendo cómo convivir dos versiones mientras migras a los llamadores.
• Escribir el contrato de un workflow expuesto como herramienta de un AI Agent o de un cliente MCP, de forma que el agente lo use en el momento correcto y con los datos correctos.

Lo que no vas a hacer en este módulo, y está bien: no vas a coordinar tres o más workflows dependientes entre sí (Módulo 5), no vas a diseñar dónde vive el estado del sistema ni un ledger de deduplicación (Módulo 4), y no vas a construir la lógica de reintentos y alertas (Módulo 6). Aquí el foco es la promesa entre dos workflows, hecha visible.

El mapa de este módulo

Lección	Qué resuelve
2	Qué es exactamente un contrato de workflow: la promesa entre quien llama y quien responde, la analogía con la firma de una función, y por qué escribirlo evita roturas silenciosas
3	Cómo diseñar el esquema de entrada y de salida como un objeto: nombres, tipos, obligatorios vs opcionales, valores por defecto, y la forma de la respuesta en éxito y en error
4	La frontera del nodo Execute Sub-workflow: dónde un workflow llama a otro, qué se pasa, qué se devuelve, y por qué conviene un solo punto de entrada
5	Cómo validar la entrada en la frontera: rechazar temprano lo inválido, con un mensaje útil, antes de que un dato malo llegue al efecto
6	Cómo versionar un contrato sin romper a los llamadores: cambios compatibles vs rompientes, versiones paralelas y migración gradual
7	Cómo se ve el contrato cuando un AI Agent o un cliente MCP consume tu workflow como herramienta: la Description más el esquema de entrada como firma estable
8	Proyecto: construir check-credit con contrato documentado, validación en la frontera y una segunda versión compatible

Fíjate en el orden, porque no es casual. Primero el qué es (lección 2), porque no puedes proteger algo que no sabes nombrar. Después el cómo se diseña (lección 3): el esquema en papel, antes de tocar n8n. Después el dónde vive (lección 4): la frontera concreta del nodo Execute Sub-workflow. Recién entonces el cómo se protege: validar (5) y versionar (6). La lección 7 extiende el mismo concepto al mundo de los agentes, y la 8 lo junta todo en un entregable.

Lo que este módulo deliberadamente no cubre

Vale la pena decirlo temprano, para que sepas dónde buscar lo que no está aquí.

No es el módulo del modelo de datos del sistema. Dónde vive la verdad —el estado que sobrevive entre ejecuciones, el ledger que recuerda qué ya procesaste— es el Módulo 4. Aquí un sub-workflow recibe datos, decide y devuelve; no guarda memoria de largo plazo.

No es el módulo de las dependencias entre muchos workflows. Coordinar tres o más workflows, el fan-out y el fan-in, el patrón outbox y el orden de ejecución son el Módulo 5. Aquí trabajamos la relación entre dos: uno que llama y uno que responde.

No es el módulo de reintentos ni de recuperación. Qué pasa cuando un sub-workflow falla a medias, cómo reintentar sin duplicar, dónde deben alertar los fallos y cómo reproducir un bug con el replay de n8n 2.0 es el Módulo 6. Aquí un contrato define qué es una entrada válida; qué hacer cuando algo se cae de verdad viene después.

No es la guía de agentes de IA como producto. La lección 7 toca cómo un agente consume un workflow como herramienta, con foco en el contrato. Construir el agente, sus tools, su memoria y su comportamiento es la guía de chatbots y agentes del ecosistema.

Errores comunes

Creer que el contrato no existe hasta que lo escribes (conceptual). Qué pasa: alguien conecta order-triage con check-credit, ve que funciona, y concluye que como "no definió ningún contrato", no hay ninguno que cuidar; empieza a cambiar campos con libertad. Por qué pasa: la palabra "contrato" suena a documento formal, y como no hay documento, parece que no hay obligación. Pero el contrato no es el documento —es la dependencia real entre los dos workflows, que existe desde la primera vez que uno le pasó datos al otro—. Cómo detectarlo: pregúntate "si renombro este campo del sub-workflow, ¿algún otro workflow deja de funcionar?". Si la respuesta es "sí" o "no estoy seguro", hay un contrato vivo, escrito o no. Cómo corregirlo: trata todo campo que un sub-workflow reciba o devuelva como parte de una promesa, desde el primer día. Escribirlo (lección 3) no crea la obligación; solo la hace visible para que puedas respetarla.

Confundir "no dio error" con "funcionó" (conceptual). Qué pasa: alguien cambia un sub-workflow, lo prueba aislado, ve que corre sin excepciones y da el cambio por bueno; el llamador, mientras tanto, quedó roto en silencio. Por qué pasa: la intuición dice que un problema se manifiesta como un error, y las roturas de contrato casi nunca lanzan un error —producen un undefined, una rama que no se toma, un efecto que no se aplica—. Cómo detectarlo: después de tocar un sub-workflow, no basta con probar el sub-workflow; hay que ejecutar al menos un llamador de punta a punta y verificar que el resultado de negocio sigue siendo el correcto, no solo que "no se cayó". Cómo corregirlo: adopta la regla de que cambiar un contrato exige probar a los llamadores, no solo al que cambió. La lección 6 formaliza cómo encontrar esos llamadores antes de tocar nada.

Pensar que la idempotencia del módulo 2 ya resolvió esto (conceptual). Qué pasa: alguien que hizo idempotente cada efecto asume que su sistema ya es robusto, y se sorprende cuando un renombre de campo lo rompe entero. Por qué pasa: los dos temas usan el vocabulario de "sistema confiable" y es fácil meterlos en la misma caja. Pero la idempotencia protege contra la repetición de una operación, no contra el malentendido entre dos workflows. Cómo detectarlo: si tu sistema se rompió sin que nada se ejecutara dos veces —simplemente un workflow dejó de entender a otro—, no fue un problema de idempotencia. Cómo corregirlo: mantén los dos lentes separados. "¿Qué pasa si esto corre dos veces?" es idempotencia; "¿qué pasa si el otro workflow cambia?" es contrato. Los dos importan y se resuelven distinto.

Ejercicios

Ejercicio 1 — Encuentra el contrato invisible. Toma el ejemplo trabajado de esta lección: order-triage le pasa a check-credit un objeto con customer_id, order_id y amount, y espera de vuelta approved y available_credit. Sin mirar la lección 3, escribe en tus palabras cuál es el contrato completo de check-credit: qué campos entran, cuáles te parecen obligatorios, y qué campos salen. Después señala cuál de esos campos, si se renombrara, rompería a order-triage.

Ver solución

El contrato, dicho de forma informal, es algo así: "check-credit recibe un customer_id (obligatorio, para saber de quién checar el crédito), un order_id (obligatorio, para saber a qué pedido pertenece la consulta) y un amount (obligatorio, el total del pedido que se compara contra el crédito disponible), y devuelve un approved (verdadero o falso) y un available_credit (el crédito que le queda al cliente)".

El campo cuyo renombre rompería a order-triage es approved, porque es el que el llamador lee para decidir si sigue o manda a revisión. Si check-credit deja de devolver approved con ese nombre exacto, order-triage lee undefined, y undefined no es true, así que manda todo a revisión —exactamente la rotura silenciosa del ejemplo trabajado—.

Por qué funciona: el ejercicio te obliga a poner en palabras un contrato que hasta ahora solo vivía en la conexión de los nodos. Ese acto —nombrar la promesa— es el primer paso de todo el módulo. Y notar que un solo campo (approved) es el que sostiene la relación te muestra lo frágil que es un contrato que nadie escribió: un renombre bien intencionado lo tumba.

Ejercicio 2 — Idempotencia o contrato. Para cada uno de estos cuatro problemas, decide si es un problema de idempotencia (repetir sin duplicar) o de contrato (dos workflows que dejan de entenderse), y justifica en una frase:

(a) El webhook de order-triage se dispara dos veces por el mismo pedido y se crean dos registros en el CRM. (b) Alguien cambió el tipo de amount en check-credit de número a texto, y ahora la comparación de crédito da resultados absurdos. (c) Un reintento de issue-refund emite un segundo reembolso sobre el mismo pedido. (d) check-credit dejó de devolver available_credit porque alguien borró ese campo del sub-workflow, y otro workflow que lo mostraba en un reporte ahora muestra un vacío.

Ver solución

(a) Idempotencia. El problema es que la misma operación se ejecutó dos veces y produjo dos efectos. No hay ningún malentendido entre workflows; hay una repetición no protegida.

(b) Contrato. Nadie ejecutó nada dos veces. El problema es que el sub-workflow cambió el tipo de un campo (número a texto) y el llamador ya no lo entiende como antes. Es una rotura de la promesa sobre qué forma tienen los datos.

(c) Idempotencia. Igual que (a): una operación que mueve dinero se repitió y produjo dos efectos. La defensa es una clave de idempotencia, no un contrato.

(d) Contrato. Un campo que era parte de la promesa de salida desapareció, y un consumidor que dependía de él quedó roto. Nadie repitió nada; alguien cambió lo que el sub-workflow promete devolver.

Por qué funciona: los cuatro casos suenan a "el sistema falló", pero se dividen limpiamente en dos familias. (a) y (c) son repeticiones —el mismo acto ocurrió dos veces—; (b) y (d) son malentendidos —el acto ocurrió una vez, pero las dos partes ya no hablan el mismo idioma—. Saber a qué familia pertenece un problema te dice con qué herramienta atacarlo, y ese diagnóstico es la mitad del trabajo.

Ejercicio 3 — Reconstruye el mapa. Sin volver a mirar la tabla de "El mapa de este módulo", escribe de memoria qué resuelve cada una de las siete lecciones que siguen (2 a 8), en una frase cada una. Después compara y marca las que se te escaparon.

Ver solución

(2) Qué es exactamente un contrato de workflow y por qué escribirlo evita roturas silenciosas. (3) Cómo diseñar el esquema de entrada y de salida: nombres, tipos, obligatorios vs opcionales, valores por defecto y forma de la respuesta. (4) La frontera del nodo Execute Sub-workflow: dónde un workflow llama a otro y qué cruza esa frontera. (5) Cómo validar la entrada en la frontera y rechazar lo inválido con un mensaje claro. (6) Cómo versionar un contrato sin romper a los llamadores: compatible vs rompiente. (7) Cómo se ve el contrato cuando un agente o un cliente MCP consume el workflow como herramienta. (8) El proyecto: construir check-credit con contrato, validación y una segunda versión compatible.

Por qué funciona: si reconstruiste al menos cinco de las siete, ya internalizaste la progresión del módulo, que va del concepto (¿qué es?) al diseño (¿cómo se escribe?) a la mecánica (¿dónde vive y cómo se protege?). Las que más se escapan suelen ser la 5 y la 6, que son las que se vuelven concretas solo cuando las ves aplicadas sobre check-credit.

Resumen y siguiente paso

En esta lección viste que en cuanto un sistema tiene más de un workflow, los workflows se llaman entre sí, y cada llamada es una promesa —un contrato— sobre qué datos van y qué resultado vuelve. Viste la imagen del restaurante con y sin menú: mientras la promesa se respeta, las dos partes pueden cambiar por dentro sin afectarse; sin promesa escrita, cada pedido es una adivinanza frágil. Conociste la rotura silenciosa —alguien renombra approved a credit_approved en check-credit, y order-triage empieza a mandar todo a revisión manual sin lanzar un solo error—, y entendiste por qué ese tipo de rotura es peor que una caída ruidosa: un workflow que se cae te avisa; uno que rompió un contrato te deja creer que todo está bien. Separaste el problema del contrato del problema de la idempotencia: uno protege a dos workflows de dejar de entenderse, el otro protege a un workflow de repetirse. Y recuperaste a Cumbre, con order-triage llamando por primera vez a check-credit, el sub-workflow que vas a diseñar, validar y versionar a lo largo del módulo.

Antes de avanzar a la lección 2 deberías poder: explicar en una frase por qué un sistema de varios workflows es un sistema de contratos; describir con tus palabras el contrato entre order-triage y check-credit; y distinguir un problema de contrato de un problema de idempotencia.

Lo que todavía no tienes es la definición precisa. Hablamos del contrato como "la promesa", pero una promesa que quieres proteger necesita partes concretas: qué campos, con qué tipos, cuáles obligatorios, qué forma de salida. La lección 2 le pone nombre y anatomía exacta a esa promesa, con la analogía de la firma de una función, para que en la lección 3 puedas escribirla.

Recursos

• Sub-workflows — n8n Docs — el panorama oficial de qué es un sub-workflow y cómo un workflow llama a otro; la base sobre la que se construye todo este módulo.
• Break workflows into smaller parts — n8n Docs — por qué y cuándo extraer lógica a un sub-workflow, con los criterios de reutilización y complejidad.
• Execute Sub-workflow — n8n Docs — la ficha del nodo que conecta dos workflows, que vas a habitar a partir de la lección 4.
• Execute Sub-workflow Trigger — n8n Docs — el nodo que recibe la llamada en el sub-workflow y donde, más adelante, vas a declarar el esquema de entrada.