4. Dry run y proteger los efectos secundarios

Descripción

Al terminar esta lección vas a poder correr order-triage de punta a punta sin disparar sus efectos irreversibles: probar toda la lógica —recibir el pedido, clasificarlo con el agente— sin que el nodo que escribe al CRM llegue a escribir nada. Vas a saber qué es exactamente un dry run (ejecución en seco), por qué en n8n no es un botón mágico sino un patrón de diseño que tú montas, y vas a manejar cuatro formas de protegerte: una compuerta por entorno con un nodo IF, desviar el efecto a un nodo que no hace nada, desactivar el nodo a mano, y ejecutar hasta justo antes del efecto para observarlo sin dispararlo.

Esto importa porque la llave sandbox de la lección 2 es la primera línea de defensa, pero no siempre alcanza. A veces el proveedor no tiene sandbox (la modalidad C que viste), así que cualquier escritura pega en producción. A veces quieres probar la lógica sin depender de que el CRM esté disponible. Y a veces, mientras iteras rápido, no quieres ni siquiera ensuciar el sandbox con basura. Para todos esos casos necesitas una segunda línea de defensa: la capacidad de correr el workflow con el efecto secundario apagado. Ese es el dry run.

Conexión con el módulo: en la lección 2 apuntaste el efecto secundario a un destino seguro (el sandbox). Esta lección te da el control para apagarlo por completo cuando lo necesites, que es el tercer punto del checklist. Se apoya en los entornos del Módulo 4: la compuerta que vas a montar decide qué hacer según en qué entorno corre el workflow —escribe de verdad en prod, no escribe en dev—. Y prepara la lección 5: una vez que puedes correr el workflow sin efectos, fijar sus entradas para repetir la corrida idéntica se vuelve natural. La idea de fondo del módulo se completa aquí: destino seguro (2) + entradas seguras (3) + salidas apagables (4).

El simulacro de incendio y la carta en el buzón

Piensa en un simulacro de incendio en una escuela. Suena la alarma, los niños se forman, los maestros los cuentan, todos salen por las rutas de evacuación, alguien cronometra cuánto tardaron. Se ejecuta el procedimiento completo, con seriedad, como si fuera real. Y sin embargo, no hay fuego, no se llama de verdad a los bomberos, y a las diez minutos todos vuelven al salón. El simulacro prueba que el procedimiento funciona —¿la gente sabe salir?, ¿las puertas abren?, ¿cuánto tarda?— sin pagar el costo de un incendio real.

Un dry run —"ejecución en seco", a veces "ensayo en seco"— es el simulacro de incendio de tu workflow. Corres el procedimiento completo —recibes el pedido, lo clasificas, pasas por toda la lógica— pero sin disparar la parte irreversible: la escritura al CRM no ocurre, como no ocurre el incendio. Verificas que todo lo demás funciona, sin pagar el costo del efecto real. "En seco" es una expresión que viene de ensayar sin el material de verdad —un ensayo en seco de una maniobra se hace sin agua, sin fuego, sin munición—: haces todos los movimientos, pero el elemento peligroso no está.

Para entender qué es lo que un dry run protege, necesitas el otro concepto: el efecto secundario.

Un efecto secundario (side effect) es una acción de tu workflow cuya consecuencia vive fuera del workflow y que el workflow no puede deshacer solo. Piénsalo como echar una carta al buzón. Mientras la carta está en tu mano, puedes leerla, corregirla, romperla. En el momento en que la sueltas en el buzón, cruzó una frontera: ya no es tuya, va a llegar, y no hay forma de sacarla. Ese instante —el punto sin retorno— es el efecto secundario. En order-triage, el nodo HTTP Request que escribe al CRM es echar la carta al buzón: antes de ese nodo, todo lo que pasó vive dentro de la corrida y se puede repetir sin consecuencia; en el momento en que el nodo escribe al CRM, algo cambió en el mundo de afuera y ya no se deshace.

No todo lo que hace un workflow es un efecto secundario. Leer no lo es —consultar el clima, listar clientes, leer un pedido no cambia nada afuera, aunque gaste un poco de cuota—. Transformar datos en memoria tampoco —el nodo Code que limpia un monto, el IF que decide una rama—. Los efectos secundarios son las acciones que escriben, mandan, cobran o borran hacia afuera: escribir al CRM, mandar un correo, cobrar una tarjeta, publicar un post, borrar un registro. Son justo la lista de "nunca contra producción" de la lección 2, y la razón es la misma: no tienen deshacer. El dry run es la técnica para correr todo el workflow excepto esos.

n8n no tiene un botón de "dry run"

Aquí una honestidad importante, porque es una confusión común. Algunas herramientas tienen un modo "dry run" global: un interruptor que dice "corre todo pero no ejecutes nada que cambie el mundo". n8n no tiene eso. No hay un botón que, al apretarlo, mágicamente desactive todos los efectos secundarios de tu workflow. n8n no sabe cuáles de tus nodos son "peligrosos"; para él, un nodo HTTP que lee y uno que escribe son el mismo tipo de nodo.

Esto no es una falla de n8n; es una consecuencia de que "efecto secundario" es un concepto de tu dominio, no de la herramienta. Solo tú sabes que ese nodo HTTP escribe al CRM y aquel solo lee. Así que el dry run en n8n es un patrón de diseño: tú diseñas el workflow para que se pueda correr en seco. No lo activas, lo construyes. Y hay cuatro formas de construirlo, de la más robusta a la más rápida. Veámoslas.

Los efectos secundarios escondidos

Antes de las formas, una advertencia: no todos los efectos secundarios se ven tan claros como "un nodo HTTP que hace POST". Algunos se esconden, y son los que más muerden porque no piensas en protegerlos. Vale la pena entrenar el ojo para cazarlos en order-triage y en cualquier workflow:

• Las herramientas del nodo AI Agent. Un agente no solo "piensa": puede tener herramientas conectadas que actúan —una herramienta que consulta el CRM, otra que crea un registro—. Si el agente decide usar una herramienta que escribe, eso es un efecto secundario disparado desde adentro del agente, más difícil de ver que un nodo suelto en el lienzo. Al probar el agente, revisa qué herramientas tiene y si alguna escribe.
• La respuesta del Webhook. Si order-triage responde algo al sistema que le mandó el pedido, esa respuesta también sale al mundo. Suele ser inofensiva, pero si el que llama toma decisiones con ella, cuenta.
• Un segundo workflow disparado. Un nodo Execute Workflow que llama a otro workflow hereda todos los efectos secundarios de ese otro. Un dry run del primero no protege los efectos del segundo a menos que el segundo también los proteja.

La disciplina: antes de dar por bueno un dry run, recorre el workflow nodo por nodo y pregúntate en cada uno "¿esto cambia algo afuera?". Los efectos evidentes los ves a la primera; los escondidos —dentro de un agente, en una respuesta, en un sub-workflow— son los que te alcanzan si no los buscas a propósito.

Forma 1: la compuerta por entorno (el patrón principal)

Esta es la forma que quieres para un workflow serio, porque queda dentro del workflow y viaja con él a todos los entornos. La idea: justo antes del nodo que escribe al CRM, pones un nodo IF que pregunta "¿en qué entorno estoy?" y desvía el flujo según la respuesta.

Un nodo IF es una compuerta: evalúa una condición y manda el flujo por una de dos salidas, true o false, como un guardia que revisa una credencial y te deja pasar por la puerta A o la puerta B. Lo vas a usar para preguntar por el entorno.

Para que el IF sepa en qué entorno corre, lee una variable de entorno. En el Módulo 4 cada instancia quedó con su propia configuración; supongamos que definiste una variable llamada CUMBRE_ENV que vale dev, staging o prod según la instancia. En una expresión de n8n, esa variable se lee como {{ $env.CUMBRE_ENV }}. La compuerta queda así:

                         ┌─ true  (es prod) ──→ HTTP Request: escribe al CRM de verdad
... → AI Agent → IF ─────┤
   {{ $env.CUMBRE_ENV }} └─ false (no es prod) → NoOp: "dry run, no escribo nada"
        == "prod"

La condición del IF es {{ $env.CUMBRE_ENV }} igual a "prod". En la instancia de prod, la condición da true, el flujo va al nodo HTTP y la carta se echa al buzón: se escribe al CRM real. En dev y staging, la condición da false, el flujo se desvía y el nodo HTTP nunca corre: es un dry run. El mismo workflow, sin cambiar una línea, escribe de verdad solo en producción.

Verifica el acceso a $env en tu instancia. El acceso a variables de entorno desde expresiones se controla con la opción N8N_BLOCK_ENV_ACCESS_IN_NODE, que por defecto está en false —es decir, el acceso está permitido por defecto—. Pero hay reportes de que en algunas configuraciones $env devuelve vacío aunque debería funcionar. Si tu IF no lee bien la variable, revisa esa opción en la configuración de tu instancia (es la que montaste en el Módulo 4) antes de dar por roto el patrón. Y si prefieres no depender de $env, la misma compuerta funciona leyendo cualquier otra señal del entorno que ya tengas —por ejemplo, un campo distinto en una credencial por entorno—. La idea del patrón no cambia; solo de dónde sale el "¿soy prod?".

¿Y el nodo que no hace nada?

Del lado false de la compuerta puse un nodo NoOp. Vale la pena explicarlo porque es una pieza clave y suena a broma la primera vez.

NoOp significa "No Operation" —"ninguna operación"—. Es un nodo de n8n cuyo único trabajo es no hacer nada: recibe los datos que le entran y los pasa tal cual a su salida, sin tocarlos, sin llamar a nada, sin efecto. Parece inútil, pero es exactamente lo que necesitas del lado seguro de la compuerta: un lugar a donde mandar el flujo cuando quieres que "no pase nada". Es el equivalente de la ruta de evacuación del simulacro que lleva al patio y no llama a los bomberos: el flujo termina ahí, tranquilo, sin consecuencias.

Hay una variante útil del NoOp para las pruebas: en vez de un NoOp puro, pon un nodo Edit Fields (Set) que arme un objeto diciendo qué habría hecho el nodo real. Algo como { "dry_run": true, "would_have_written": { "order_id": "ORD-TEST-002", "status": "manual_review" } }. Así, cuando corres en seco, no solo evitas el efecto: dejas registrada la evidencia de qué habría pasado, que es justo lo que la lección 8 va a querer guardar como prueba de que el pase corrió. El simulacro no solo evita el incendio; también anota "aquí habrían entrado los bomberos".

Ejemplo trabajado: order-triage en seco

Veámoslo corriendo. Tienes la compuerta montada y estás en tu instancia de dev, probando el caso large-order-manual-review (el pedido de 52 000 pesos que debe ir a revisión manual).

Corres el workflow. Qué esperar:

1. El pedido entra, el nodo AI Agent lo clasifica como manual_review.
2. El flujo llega al IF. La condición {{ $env.CUMBRE_ENV }} == "prod" se evalúa: como estás en dev, CUMBRE_ENV vale "dev", la condición da false.
3. El flujo se va por la salida false, al nodo Edit Fields, que devuelve { "dry_run": true, "would_have_written": { "order_id": "ORD-TEST-002", "status": "manual_review" } }.
4. El nodo HTTP Request queda gris, sin ejecutar: en el lienzo ves que no se coloreó, porque el flujo nunca pasó por él.

Vas al CRM sandbox: no hay ningún registro nuevo. Vas al CRM de producción: tampoco. La corrida fue completa —el agente clasificó, la lógica decidió— pero la carta nunca se echó al buzón. Probaste que order-triage clasifica bien el pedido grande, sin escribir ni una línea en ningún CRM. Eso es un dry run bien hecho.

Y cuando promuevas a prod y ese mismo pedido llegue de verdad, la condición dará true, el flujo irá al HTTP Request, y esta vez sí se escribirá —porque en producción, escribir es lo correcto—. El workflow es el mismo; el entorno decide.

Forma 2: desactivar el nodo a mano (el dry run rápido)

Para una prueba puntual y rápida, sin montar ninguna compuerta, n8n te deja desactivar un nodo en el editor. Un nodo desactivado se salta al ejecutar: el flujo lo atraviesa como si no estuviera, pasando los datos al siguiente nodo sin ejecutarlo.

Se hace seleccionando el nodo y desactivándolo (con la tecla D sobre el nodo seleccionado, o desde su menú; verifica el atajo en tu versión). El nodo se ve atenuado en el lienzo. Corres el workflow, el nodo HTTP del CRM está desactivado, y el efecto no ocurre.

Cuándo usarlo: para un experimento de treinta segundos —"déjame ver qué clasifica el agente sin que escriba nada"—. Cuándo NO usarlo: como tu estrategia de prueba permanente. El problema de desactivar a mano es que es frágil y no viaja: es un estado del editor que tienes que acordarte de poner y de quitar. El día que olvides reactivarlo antes de promover, promueves un workflow que no escribe al CRM en producción —un order-triage mudo que clasifica pedidos y no registra ninguno—. Peor aún, si desactivas el nodo, exportas y commiteas, ese estado "desactivado" puede quedar guardado en el JSON y colarse a producción. La compuerta de la Forma 1 no tiene ese riesgo, porque decide sola según el entorno y no depende de tu memoria.

Piénsalo así: desactivar a mano es como poner la mano frente al buzón para no soltar la carta hoy. Funciona ahora, pero depende de que te acuerdes; la compuerta por entorno es un buzón que solo se abre en producción, sin que tú tengas que hacer nada.

Forma 3: ejecutar hasta justo antes del efecto

A veces no quieres correr todo el workflow; quieres observar exactamente qué le llegaría al nodo del CRM, sin ejecutarlo. Para eso sirve la ejecución parcial de n8n.

n8n te deja ejecutar un nodo puntual con "Execute step" (ejecutar paso): seleccionas un nodo, abres su vista, y n8n ejecuta ese nodo y los nodos anteriores necesarios para darle su entrada. La clave para el dry run está en cuál nodo eliges: si ejecutas el nodo anterior al HTTP del CRM —digamos, el nodo que arma el cuerpo del pedido que se enviaría—, ves en su salida exactamente el dato que habría ido al CRM, y el nodo del CRM no se ejecuta, porque está después. Observas la carta terminada, a punto de echarse, sin soltarla.

Hay una sutileza que conviene tener clara, porque es una trampa: "Execute step" ejecuta los nodos anteriores. Si ejecutas un nodo que tiene el efecto secundario antes que él en la cadena, ese efecto sí se dispara para poder darle su entrada. Es decir: ejecutar hasta un nodo protege de los efectos que están después de ese nodo, no de los que están antes. En order-triage, si el nodo del CRM es el último, ejecutar el penúltimo es seguro. Pero si tuvieras un efecto secundario en medio del flujo, ejecutar un nodo posterior lo dispararía. Elige el punto de corte pensando en dónde están los efectos, no en dónde está tu curiosidad.

Y hay un segundo cuidado, que conecta con la lección 6: los nodos anteriores incluyen el nodo AI Agent. Si ese agente corre contra un modelo de pago, ejecutar hasta después de él sí cuesta —no es un efecto secundario en el sentido de "escribe afuera", pero sí quema presupuesto de API—. Por eso la lección 6 te va a enseñar a probar el agente contra un modelo local de Ollama: para que ni siquiera esa parte "de solo lectura" tenga costo. Un dry run que evita la escritura al CRM pero quema diez dólares en llamadas al LLM es solo medio dry run.

Forma 4: la compuerta como bandera de "dry run" explícita

Una variante de la Forma 1, para cuando quieres correr en seco incluso en producción —por ejemplo, para verificar la lógica de prod sin escribir—: en vez de que la compuerta pregunte por el entorno, que pregunte por una bandera dedicada, {{ $env.CUMBRE_DRY_RUN }}, que puede valer "true" o "false" en cualquier entorno.

                              ┌─ false (dry_run apagado) → HTTP Request: escribe al CRM
... → AI Agent → IF ──────────┤
   {{ $env.CUMBRE_DRY_RUN }}  └─ true  (dry_run encendido) → Edit Fields: registra qué habría hecho
        == "true"

La diferencia con la Forma 1: la compuerta por entorno ata el dry run al lugar (nunca escribo en dev); la bandera lo ata a una decisión que puedes prender y apagar donde quieras. En la práctica se combinan: la condición del IF puede ser "escribe solo si CUMBRE_ENV == prod y CUMBRE_DRY_RUN != true", de modo que en producción escribes normalmente, pero puedes forzar un dry run en producción prendiendo la bandera, sin tocar el workflow. Es la máxima flexibilidad, y la que vas a querer el día que necesites verificar algo en prod sin arriesgar una escritura.

Prueba la compuerta misma

Un cuidado que casi nadie toma y que separa una protección real de una ilusión de protección: la compuerta también hay que probarla. Una compuerta mal escrita —una condición invertida, un $env que devuelve vacío y hace que el IF caiga siempre por la rama equivocada— es peor que no tener compuerta, porque te da falsa tranquilidad: crees que estás protegido y no lo estás. Antes de confiar en tu compuerta, corre las dos ramas a propósito y confirma que cada una hace lo que debe. En dev, corre y confirma que el flujo va por la rama de dry run y el CRM no se toca. Y —el paso que casi todos saltan— confirma que en prod la condición daría true: puedes hacerlo temporalmente forzando el valor de la condición, o revisando que {{ $env.CUMBRE_ENV }} de verdad valga "prod" en esa instancia. Una compuerta que nunca probaste en sus dos ramas es una suposición, no una defensa. Trátala como cualquier otra lógica del workflow: no la des por buena hasta que la viste funcionar.

Cómo se apilan las defensas: sandbox y dry run juntos

Ahora tienes dos herramientas para el mismo peligro —la escritura al CRM— y conviene entender cómo se relacionan, porque no son alternativas, son capas.

La llave sandbox (lección 2) responde a "¿a dónde escribo?". Con ella, el efecto secundario ocurre, pero contra un destino de utilería: se escribe, pero al CRM de prueba. El dry run (esta lección) responde a "¿escribo?". Con él, el efecto secundario no ocurre: no se escribe a ningún lado.

Piénsalo como dos anillos de seguridad alrededor del buzón. El anillo interior es el sandbox: si sueltas la carta, cae en un buzón de prueba que puedes vaciar. El anillo exterior es el dry run: la mano nunca suelta la carta. Cuál usar depende de qué estés probando:

Situación	Herramienta	Por qué
Quiero verificar que el CRM recibe bien el pedido	Sandbox (escribe al de prueba)	Necesito que la escritura ocurra para comprobar que funciona; solo que caiga en utilería
Quiero verificar solo la lógica de clasificación, sin depender del CRM	Dry run (no escribe)	La escritura no me interesa ahora; la apago para aislar lo que sí pruebo
El proveedor no tiene sandbox (modalidad C)	Dry run, obligatorio	Cualquier escritura pega en producción, así que la única opción segura es no escribir
Estoy iterando rápido y no quiero ni basura de prueba	Dry run	Ni el sandbox quiero ensuciar mientras experimento veinte veces por minuto
Ensayo general antes de promover, lo más fiel posible	Sandbox en staging	Quiero que todo ocurra de verdad, contra utilería, para cazar lo que un dry run esconde

La combinación ideal de un pase completo, que vas a armar en la lección 8, usa las dos en momentos distintos: dry run mientras iteras la lógica en dev (rápido, sin ensuciar nada), y sandbox cuando ensayas de verdad en staging (fiel, con la escritura ocurriendo contra utilería). El dry run es para "todavía estoy construyendo la prueba"; el sandbox es para "esta es la corrida seria". Tener las dos capas te deja elegir cuánta realidad quieres en cada momento, sin arriesgar nunca la producción.

Errores comunes

Creer que n8n tiene un dry run global (conceptual). Qué pasa: alguien busca "el botón de dry run" de n8n, no lo encuentra, y concluye que n8n no sirve para probar sin efectos —o peor, asume que "ejecutar en el editor" ya es un dry run y prueba contra el CRM real sin saberlo—. Por qué pasa: otras herramientas tienen ese botón, y es razonable esperarlo. Cómo detectarlo: si no montaste ninguna compuerta ni desactivaste ningún nodo, y aun así crees que estás en dry run, no lo estás; el workflow está disparando sus efectos. Cómo corregirlo: entiende que el dry run en n8n se construye, no se activa. Monta la compuerta de la Forma 1 en cualquier workflow con efectos secundarios. Es una pieza de diseño, como el freno de un auto: no viene por magia, se instala.

Desactivar el nodo a mano y olvidar reactivarlo (práctico y peligroso). Qué pasa: alguien desactiva el nodo del CRM para una prueba, prueba, y se olvida de reactivarlo. Después promueve —o el estado desactivado se cuela al JSON exportado— y en producción order-triage clasifica pedidos pero no registra ninguno. Nadie se da cuenta hasta que falta un día entero de pedidos en el CRM. Por qué pasa: desactivar es un estado del editor invisible después de un rato; es fácil olvidarlo. Cómo detectarlo: antes de promover, revisa que ningún nodo esté desactivado —en el diff del JSON (Módulo 3) un cambio de disabled salta a la vista si normalizaste bien—. Cómo corregirlo: usa desactivar solo para experimentos de un minuto, nunca como estrategia. Para dry runs repetibles, la compuerta por entorno, que no depende de tu memoria.

Proteger la escritura pero no darse cuenta del costo del agente (conceptual). Qué pasa: alguien monta bien la compuerta que evita la escritura al CRM, corre su dry run cien veces contentísimo, y a fin de mes le llega la factura del modelo de lenguaje, porque cada una de esas cien corridas llamó al LLM de pago. Por qué pasa: es fácil pensar "dry run = no toco el mundo afuera" y olvidar que llamar a un modelo de pago también toca el mundo afuera —tu billetera—. Cómo detectarlo: si tu dry run incluye una llamada a un modelo de pago, cada corrida cuesta, aunque no escriba nada. Cómo corregirlo: es la lección 6. Prueba el agente contra un modelo local de Ollama, para que el dry run sea de verdad a costo cero, escritura y LLM incluidos.

Ejercicios

Ejercicio 1 — Clasifica efecto secundario o no. Para cada acción de un workflow, di si es un efecto secundario (algo que proteger en un dry run) o no, y por qué: (a) un nodo Code que convierte "3,500.00" a 3500; (b) un nodo HTTP que hace POST para crear un cliente en el CRM; (c) un nodo HTTP que hace GET para leer el clima; (d) un nodo que manda un correo al cliente; (e) un nodo IF que decide una rama.

Ver solución

(a) No es efecto secundario — transforma datos en memoria; nada cambia fuera del workflow. (b) Sí — POST para crear escribe en el CRM; cambia algo afuera y no se deshace solo. Protéjalo. (c) No — GET para leer no cambia nada afuera (gasta un poco de cuota, pero no deja rastro que deshacer). (d) Sí, y de los peores — mandar un correo le llega a una persona; no hay recall. Protéjalo siempre. (e) No — decidir una rama es lógica en memoria, sin consecuencia externa.

Por qué funciona: la prueba es la pregunta de la lección 2 —"¿puedo deshacerlo sin que nadie se entere?"— combinada con "¿cambia algo fuera del workflow?". Leer y transformar: no cambian nada afuera, no son efectos secundarios. Escribir (POST) y mandar (correo): sí. Fíjate que el método HTTP importa: el mismo tipo de nodo es o no es efecto secundario según si lee (GET) o escribe (POST/PUT/DELETE).

Ejercicio 2 — Diseña la compuerta. order-triage va a agregar, después de escribir al CRM, un nodo que manda un WhatsApp al cliente cuando su pedido se aprueba. Diseña la compuerta (o compuertas) para que ese WhatsApp solo se mande en prod, y describe qué pasa en dev al probar el caso happy-path-approve.

Ver solución

Igual que con el CRM, pones un IF antes del nodo de WhatsApp que evalúe {{ $env.CUMBRE_ENV }} == "prod". En la salida true va el nodo de WhatsApp; en la salida false va un Edit Fields que registra { "dry_run": true, "would_have_sent_whatsapp_to": "Café Aurora" }.

En dev, al probar happy-path-approve: el agente aprueba el pedido, el flujo del CRM ya lo cubre su propia compuerta (no escribe, o escribe al sandbox), y al llegar a la compuerta del WhatsApp, CUMBRE_ENV vale "dev", así que la condición da false y el nodo de WhatsApp no corre. Ningún cliente recibe un mensaje. En la salida ves el registro de que se habría mandado, como evidencia.

Por qué funciona: cada efecto secundario necesita su propia protección; el WhatsApp es un efecto nuevo —y de los que le llegan a una persona real, así que de los más importantes de proteger—. El patrón es el mismo del CRM, aplicado otra vez. En un workflow con varios efectos, cada uno lleva su compuerta, o una compuerta compartida los envuelve a todos.

Ejercicio 3 — Encuentra el hueco del dry run. Un compañero dice: "monté la compuerta que evita escribir al CRM en dev, así que mi dry run es a costo cero". Su workflow es: Webhook → AI Agent (modelo de pago en la nube) → IF (entorno) → CRM / NoOp. ¿Es de verdad a costo cero su dry run? Si no, ¿qué le falta?

Ver solución

No es a costo cero. Su compuerta protege bien la escritura al CRM —esa parte está perfecta—, pero el nodo AI Agent corre antes de la compuerta y llama a un modelo de pago en la nube. Cada dry run, aunque no escriba nada al CRM, gasta una llamada al LLM de pago. Si corre cien pruebas, paga cien llamadas.

Lo que le falta: probar el agente contra un modelo local de Ollama en lugar del modelo de pago (la lección 6). Con el agente apuntando a un modelo local, las cien corridas no escriben al CRM ni cuestan un centavo de LLM. Ahí sí, el dry run es a costo cero completo.

Por qué funciona: "a costo cero" tiene dos frentes —no ensuciar datos (lo cubre la compuerta) y no quemar presupuesto (lo cubre el modelo local)—. Es fácil resolver el primero y creer que ya está, olvidando el segundo. En un workflow con un agente de IA, el costo del LLM suele ser el mayor de los dos, justamente porque probar implica correr muchas veces.

Resumen y siguiente paso

En esta lección viste qué es un dry run —el simulacro de incendio de tu workflow: corres el procedimiento completo sin disparar la parte irreversible— y qué es un efecto secundario —echar la carta al buzón: una acción cuya consecuencia vive fuera del workflow y no se deshace, como escribir al CRM, mandar un correo o cobrar—. Entendiste que n8n no tiene un botón de dry run: es un patrón de diseño que tú construyes, con cuatro formas. La principal es la compuerta por entorno —un nodo IF que lee {{ $env.CUMBRE_ENV }} y desvía el efecto a un nodo NoOp o Edit Fields cuando no es prod—, que viaja con el workflow y no depende de tu memoria. Las otras: desactivar el nodo a mano (rápido pero frágil), ejecutar hasta justo antes del efecto con "Execute step" (para observar sin disparar, cuidando que el efecto esté después del punto de corte), y la bandera de dry run explícita para correr en seco incluso en producción. Y viste el hueco clásico: proteger la escritura pero olvidar que el agente de IA de pago también cuesta en cada corrida.

Con esto marcas el tercer punto del checklist: los efectos secundarios están protegidos.

Antes de avanzar deberías poder: definir "efecto secundario" con un ejemplo; explicar por qué n8n no tiene un dry run global; y describir la compuerta por entorno y por qué es mejor que desactivar el nodo a mano.

Ya puedes correr order-triage con destino seguro, entradas seguras y salidas apagadas. Falta una propiedad de la lección 1 que todavía no tienes: que la prueba sea reproducible. Si cada corrida usa entradas ligeramente distintas, no puedes comparar el efecto de un cambio. La lección 5 entra en los datos fijados (pin data) y el replay de ejecución: cómo congelar las entradas de una prueba para repetirla idéntica, y cómo usar el motor de depuración de n8n —"Debug in editor", "Copy to editor"— como una herramienta de prueba repetible, con sus límites bien marcados.

Recursos

• Manual, partial, and production executions — n8n Docs — cómo funciona la ejecución parcial ("Execute step") que usas en la Forma 3 para observar sin disparar.
• No Operation, do nothing — n8n Docs — el nodo NoOp, el destino seguro del lado "en seco" de la compuerta.
• IF node — n8n Docs — el nodo que arma la compuerta por entorno; su sintaxis de condiciones.
• Environment variables (nodes) — n8n Docs — la opción N8N_BLOCK_ENV_ACCESS_IN_NODE y cómo $env accede a las variables desde una expresión; verifícala si tu IF no lee CUMBRE_ENV.
• Edit Fields (Set) node — n8n Docs — para registrar "qué habría hecho" el efecto en un dry run, la evidencia que guarda la lección 8.