El 10 de septiembre de 2026, n8n publicó su última versión estable con tres cambios que, aunque no parecen dramáticos a primera vista, afectan bastante el comportamiento de los agentes y workflows con IA. No es un lanzamiento de los que generan titulares — pero si construyes automatizaciones con n8n todos los días, vale la pena saber exactamente qué tocaron antes de actualizar.
Qué trae la versión de septiembre de n8n
Tres cambios principales que importan para quienes trabajamos con IA en n8n:
- ▸MCP discovery handshake (spec 2026-07-28): soporte nativo del nuevo protocolo de descubrimiento del Model Context Protocol en su versión de julio de 2026.
- ▸Motor de expresiones vm como default: el motor vm reemplaza al anterior como opción por defecto en todos los workspaces, trayendo mayor aislamiento y mensajes de error más claros.
- ▸Tab "Changes diff" en el panel de revisión: ahora puedes ver exactamente qué cambió en un workflow comparado con su versión anterior, como un diff visual específico para workflows.
Más fixes en el Slack Node, Schedule Node, webhooks y mejoras de estabilidad en AI tools y credentials. Algunos de esos fixes son más importantes de lo que parecen, como verás más abajo.
MCP discovery handshake 2026-07-28 — por qué importa
Desde su versión 2.37 (agosto 2026), n8n soporta MCP tanto como servidor como cliente. Eso permite que tus workflows expongan herramientas a cualquier cliente MCP compatible — Claude Code, Cursor, otros agentes — y también que consuman herramientas de servidores MCP externos sin escribir código de integración manual.
El handshake de descubrimiento es el paso que ocurre cuando un cliente MCP se conecta al servidor por primera vez: negocia qué capacidades están disponibles, qué formato de mensajes acepta y cómo se van a comunicar. La especificación del 28 de julio de 2026 actualizó cómo funciona ese proceso, e implicó cambios en los mensajes de negociación inicial. Esta versión de n8n implementa esa spec correctamente.
Si tenías un workflow que expone herramientas via MCP y tu cliente ya usa la spec de julio 2026, antes podías encontrarte con errores de compatibilidad silenciosos durante la negociación inicial — el cliente no conseguía la lista de herramientas y simplemente no funcionaba, sin un mensaje de error claro. Ahora n8n y el cliente hablan el mismo protocolo.
Es un cambio de infraestructura más que de funcionalidad visible. Pero en producción, esos son los que más molestan cuando fallan: no te dicen que fallaron, simplemente algo no funciona y tardas horas en encontrar dónde está el problema.
El motor de expresiones vm como default
n8n tiene dos motores para evaluar las expresiones que escribes en los nodos (las que van entre dobles llaves, como {{ $json.nombre }}): el motor anterior y el motor vm, que corre en un sandbox más aislado usando la API vm de Node.js. Desde esta versión, vm es el motor por defecto en todos los workspaces.
Lo que cambia en la práctica:
- ▸Mejor aislamiento: las variables de una expresión no "se escapan" inadvertidamente a otras evaluaciones del mismo nodo. Esto eliminaba una clase de bugs difíciles de reproducir en workflows complejos.
- ▸Mensajes de error más legibles: cuando una expresión falla, el motor vm da mensajes que apuntan directo a la causa, en lugar del stack trace genérico del motor anterior.
- ▸Overhead mínimo: unos 2-5 ms por nodo en workflows complejos. En la mayoría de los casos no se nota; sí podría notarse en loops con miles de ítems procesados en paralelo.
Si venías usando expresiones JavaScript avanzadas que dependían de comportamientos específicos del motor anterior, vale hacer una pasada de pruebas en un ambiente de desarrollo antes de actualizar a producción. En el 90% de los casos no habrá diferencia, pero si tienes lógica compleja en expresiones — objetos mutables compartidos, closures poco convencionales — el sandbox más estricto puede rechazar algo que antes pasaba silenciosamente.
Tab "Changes diff" — para equipos que trabajan colaborativamente en workflows
Esta es la novedad más visible para quienes trabajan en equipo. En el panel de revisión de n8n Cloud (y en instancias self-hosted con versionado activo) aparece una pestaña "Changes" que muestra un diff visual entre la versión actual de un workflow y la anterior.
Lo que muestra el diff:
- ▸Nodos agregados o eliminados en el workflow
- ▸Parámetros modificados en nodos existentes
- ▸Cambios en las conexiones entre nodos
Es parecido a un git diff, pero visual y específico para la estructura de workflows. Útil cuando trabajas en un workspace compartido y quieres entender qué cambió antes de aprobar un workflow para producción, sin tener que recorrer nodo por nodo buscando diferencias.
Lo que nadie menciona aún: el diff funciona bien para cambios estructurales (nodos, conexiones), pero no es granular dentro de expresiones complejas. Si alguien modificó 5 líneas de una expresión JavaScript larga, el diff te dice que ese nodo cambió, no te resalta exactamente las líneas. Útil igual — pero no lo trates como un Git completo, porque no lo es.
Fixes de estabilidad que importan en producción
Junto a los tres cambios principales, hay cuatro fixes que conviene conocer:
- ▸Slack Node: corrección de un bug donde el envío de mensajes con bloques de rich text fallaba silenciosamente en ciertos formatos de payload, sin lanzar error ni log visible.
- ▸Schedule Node: fix de un edge case donde el trigger no se ejecutaba si el timezone del servidor cambiaba durante una ejecución de larga duración.
- ▸AI tools: mejoras en cómo n8n maneja respuestas de modelos que devuelven tool calls anidados — problema que aparecía especialmente con Claude y Gemini en agentes con herramientas complejas.
- ▸Webhooks: fixes de estabilidad en workflows que reciben webhooks de alta frecuencia simultánea.
El del Slack Node es especialmente tramposo: fallaba silenciosamente, así que muchos workflows seguían ejecutándose sin enviar el mensaje y sin ningún error en el log. Si tienes notificaciones de Slack en flujos críticos y te has preguntado por qué algunos mensajes no llegaban, este fix puede ser tu respuesta.
Cómo aprender n8n y construir agentes con IA en DataPath
Si estás empezando o quieres llevar tus workflows de n8n a otro nivel, en DataPath tenemos el curso de Automatización e IA con n8n — construyes desde cero workflows con agentes, nodos de IA y conexiones con APIs reales. Si lo tuyo es IA conversacional integrada en canales de mensajería, el curso de Agentes de IA para WhatsApp con n8n cubre ese caso de punta a punta.
Para entender el contexto más amplio de los agentes de IA — MCP, orquestación con LangGraph, sistemas multi-agente, decisiones de arquitectura — la ruta AI Agentic Engineer cubre todo ese ecosistema en profundidad, incluyendo cómo encaja n8n dentro de una arquitectura de agentes más grande.
Si quieres practicar junto a otros que están construyendo con n8n y herramientas similares, en la Comunidad AI Builders hacemos talleres en vivo cada semana — desde USD 19/mes. Es un buen espacio para llevar casos reales y resolverlos con otros en la misma situación.
n8n sigue iterando rápido. El soporte MCP actualizado es lo más relevante de esta versión si estás construyendo agentes. El diff de workflows es lo más útil si trabajas en equipo. Revisa tus expresiones complejas antes de actualizar. → Automatización e IA con n8n · Ruta AI Agentic Engineer · Agentes para WhatsApp con n8n
