2. Agente, chatbot y IA procedural: tres cosas distintas

Descripción

En la lección anterior viste hacia dónde va esta guía: vas a terminar construyendo un agente que responde en varios canales. Antes de tocar el nodo que lo hace posible, necesitas un criterio para clasificar cualquier flujo con IA que te encuentres —el tuyo o el de un cliente— en una de tres categorías: IA procedural, chatbot de un turno o agente (lo que también se llama IA agéntica). Al terminar esta lección vas a poder mirar un flujo de n8n con un nodo de IA adentro y decir, en una sola frase, quién controla el siguiente paso: el flujo que ya diseñaste, o el modelo en tiempo de ejecución.

Esto no es un ejercicio académico. En proyectos reales de automatización, "necesito un agente de IA" es de las frases peor usadas del mercado: la mitad de las veces el cliente en realidad necesita un chatbot que conteste una FAQ —mucho más barato y predecible—, y otras veces necesita justo lo contrario de lo que pide: un flujo con reglas fijas, porque su proceso no puede darse el lujo de improvisar. Saber nombrar la diferencia con precisión es lo que te permite cotizar bien un proyecto y no sobre-construir ni sub-construir la solución.

Conexión con el módulo: este criterio de clasificación es la base sobre la que se apoya el resto del módulo. La próxima lección abre el nodo AI Agent y mira qué pasa adentro cuando decide llamar una herramienta; esta lección responde primero el por qué existe esa decisión en primer lugar.

El criterio: quién decide, no qué tan conversacional suena

Imagínate un mostrador de atención al cliente con tres configuraciones distintas para la misma pregunta: "¿cómo va mi pedido #3187?".

En el primer mostrador hay un empleado con un instructivo impreso: si el cliente dice la palabra "pedido", lo pasa a logística; si dice "factura", lo pasa a administración; cualquier otra cosa cae en un buzón genérico. El empleado no decide nada — el instructivo ya decidió todo antes de que el cliente llegara. Da igual si atienden 3 clientes o 3,000 ese día: la ruta ya estaba fija de antemano.

En el segundo mostrador hay alguien que conoce muy bien el catálogo y las políticas de la empresa, y responde con seguridad y buen tono —pero no tiene acceso al sistema de pedidos—. Si le preguntas por tu pedido #3187, te va a contestar algo razonable ("normalmente los envíos tardan de 3 a 5 días"), pero no sabe dónde está tu paquete en este momento. Conversa, pero no actúa sobre nada.

En el tercer mostrador hay alguien con las llaves del sistema: escucha la pregunta, decide por sí mismo si necesita consultar el sistema de pedidos, lo consulta si hace falta, y responde con el dato real. Si en cambio le preguntas por la política de devoluciones, contesta directo, sin tocar ningún sistema, porque decidió que no lo necesitaba para esa pregunta. Nadie programó un caso para cada pregunta posible: la persona decide en el momento, con cada pregunta nueva.

Esas tres configuraciones tienen nombre técnico:

• IA procedural: el flujo decide. Un nodo Switch (o IF) evalúa condiciones fijas por ti en tiempo de diseño y enruta el mensaje por un camino predeterminado. Puede haber un nodo de IA adentro de una de esas ramas —por ejemplo, para clasificar el sentimiento de un mensaje—, pero quién elige la ruta general sigue siendo el Switch, no el modelo.
• Chatbot de un turno: el modelo decide qué decir, no qué hacer. Recibe un mensaje, genera una respuesta en lenguaje natural, y se detiene ahí. En n8n esto se construye típicamente con el nodo Basic LLM Chain: según la documentación oficial de n8n, un chain de este tipo no tiene acceso a memoria ni decide entre herramientas — solo encadena una llamada al modelo.
• Agente (IA agéntica): el modelo decide qué hacer antes de decidir qué decir. Recibe un objetivo y un conjunto de herramientas, y en tiempo de ejecución elige si necesita llamar alguna, con qué argumentos, y cuándo ya tiene lo suficiente para responder. La documentación de n8n lo resume con una idea que vale la pena memorizar: un agente es, en esencia, un chain que ya sabe tomar decisiones por sí mismo (en el original en inglés: "a chain that knows how to make decisions").

Ahí está exactamente la frontera con la IA procedural: en ese terreno el flujo decide incluso cuando participa un modelo. Acá, en la IA agéntica, es el modelo el que decide el camino.

Ejemplo trabajado

Toma la misma pregunta del mostrador —"¿cómo va mi pedido #3187?"— y constrúyela tres veces en n8n, con la misma entrada (un nodo Chat Trigger, el punto de entrada estándar de n8n para chatbots y agentes) pero backends distintos.

1. IA procedural

Chat Trigger
  → Switch (¿el mensaje contiene "pedido" / "envío" / "estado"?)
      rama SÍ → Edit Fields (extrae el número de pedido con una expresión regular)
              → HTTP Request (GET a la API de envíos con ese número)
              → Edit Fields (arma el texto de respuesta)
      rama NO → respuesta genérica fija

Qué esperar: si el cliente escribe "¿dónde está mi paquete?" en vez de usar la palabra "pedido", el mensaje no matchea ninguna regla del Switch y cae en la rama genérica —aunque la intención sea idéntica—. El flujo es rápido, barato y cien por ciento predecible, pero solo cubre las frases que anticipaste al diseñarlo.

2. Chatbot de un turno

Chat Trigger
  → Basic LLM Chain (system prompt: "Eres el asistente de soporte de Envíos Rápidos")

Qué esperar: el modelo responde con buen tono y conoce las políticas generales de la empresa —porque se las diste en el prompt—, pero no tiene forma de consultar el pedido real. Una respuesta honesta sería "no tengo acceso a esa información en este momento"; el riesgo real es que, sin ninguna herramienta que lo frene, invente un estado de envío plausible, porque nada en su construcción se lo impide.

3. Agente

Chat Trigger
  → AI Agent (conectado a un modelo de chat + una HTTP Request Tool
              apuntando a la API de envíos)

En tiempo de ejecución, el modelo interpreta el mensaje y decide llamar la herramienta:

// Lo que el modelo genera para invocar la tool
{ "tool": "check_shipment_status", "arguments": { "order_number": 3187 } }

// Lo que la tool devuelve
{ "status": "in_transit", "eta": "2026-07-25" }

Y compone la respuesta final a partir de ese dato real: "Tu pedido #3187 está en tránsito, llega el 25 de julio."

Ahora, si al mismo agente —sin cambiar un solo nodo— le preguntas "¿cuál es la política de devoluciones?", el modelo decide no llamar la tool (no la necesita para esa pregunta) y responde directo desde su conocimiento. Mismo nodo, dos comportamientos distintos según lo que pide cada mensaje. Eso es lo que no puedes lograr con un Switch: tendrías que anticipar cada frase posible con una rama nueva. Ese vaivén interno —decidir, actuar si hace falta, decidir de nuevo— es justo el ciclo que vas a diseccionar en la próxima lección; por ahora quédate con el efecto que produce hacia afuera: decisión distinta, mismo nodo.

Una intuición rápida de cuándo usar cada uno

• IA procedural cuando el espacio de decisiones es chico, conocido de antemano, y necesita ser determinista y auditable —facturación, cumplimiento normativo, cualquier cosa donde "por qué tomó esa ruta" tiene que tener una respuesta exacta—.
• Chatbot de un turno cuando solo necesitas una interfaz en lenguaje natural sobre conocimiento estático —FAQ, onboarding, políticas que no cambian— y no necesitas tocar ningún sistema externo.
• Agente cuando el rango de pedidos del usuario es abierto y la acción que hace falta depende de lo que pregunte cada vez, algo que no puedes enumerar con ramas de Switch de antemano.

Esto es una intuición de arranque, no el criterio completo: más adelante en el módulo vas a construir una forma más rigurosa de decidirlo, con costos y señales de alerta incluidas.

Errores comunes

1. Pensar que "tener un nodo de IA en el flujo" ya es un agente (conceptual). Qué pasa: alguien arma un Switch que en una de sus ramas usa un Basic LLM Chain para clasificar el mensaje, y le llama "agente" en la documentación del proyecto. Por qué pasa: confunde presencia de un modelo con modelo que decide el camino. Cómo detectarlo: pregúntate quién eligió la ruta —si fue una condición fija que tú escribiste, es IA procedural con un ingrediente de IA adentro, no un agente, sin importar cuán sofisticado suene el prompt. Cómo corregirlo: si el requisito real es que el sistema elija la acción según lo que pide cada mensaje, reemplaza el Switch + chain por un AI Agent con tools; si el espacio de decisiones sigue siendo chico y fijo, corrige el nombre en la documentación, no el flujo.

2. Simular un agente a mano con Switch anidados cubriendo cada frase posible. Qué pasa: el flujo termina con quince o veinte ramas tratando de capturar variaciones de "¿dónde está mi pedido?", "quiero saber del envío", "no me llegó nada"... y cada frase nueva del cliente que no coincide con ninguna rompe el flujo. Por qué pasa: se intenta resolver con ramas fijas un problema —generalizar sobre lenguaje natural variable— para el que existe el modelo, precisamente. Cómo detectarlo: si tu Switch tiene más de cinco o seis ramas intentando capturar la intención del usuario (no un dato estructurado), esa es la señal. Cómo corregirlo: mueve esa decisión de intención al AI Agent —lo vas a construir en la lección 4— y deja el Switch solo para lo que sí es determinista, como enrutar por canal de entrada.

3. Descartar el chatbot de un turno como "no sirve para nada real" (conceptual). Qué pasa: por default se agentiza todo, incluso una FAQ estática que nunca necesita tocar un sistema externo, y el resultado es un flujo más caro en tokens, más lento y menos predecible sin ninguna ganancia real. Por qué pasa: cuesta ver que un agente no es "la versión mejorada" de un chatbot, sino una arquitectura distinta con un costo distinto, que solo se justifica cuando la tarea de verdad requiere decidir entre acciones. Cómo detectarlo: revisa si tu caso de uso alguna vez necesita variar la acción según lo que pide el usuario o tocar un sistema externo; si la respuesta es "nunca", un chatbot de un turno —o incluso IA procedural— resuelve con menos riesgo. Cómo corregirlo: aplica el criterio de "quién decide" antes de elegir la arquitectura, no después de construirla.

Ejercicios

Ejercicio 1. Un flujo recibe un mensaje de soporte. Un nodo Switch revisa si el texto contiene la palabra "urgente"; si es así, envía una notificación a Slack; si no, no hace nada más. No hay ningún modelo de por medio. ¿Es IA procedural, chatbot de un turno o agente? Justifica con el criterio de "quién decide".

Ver solución

Es IA procedural. El Switch evalúa una condición fija (contiene o no la palabra "urgente") escrita en tiempo de diseño, y la ruta queda determinada antes de que llegue ningún mensaje real. No hay ningún modelo tomando esa decisión —ni siquiera hay un modelo en el flujo—. Funciona porque la decisión no depende de interpretar lenguaje natural variable: es una búsqueda de texto fija.

Ejercicio 2. Tienes un AI Agent conectado a tres tools: consultar pedido, emitir reembolso, y escalar a un humano. Un cliente escribe: "quiero cancelar mi pedido #789 y que me devuelvan el dinero". ¿Qué determina cuál (o cuáles) tools se llaman y en qué orden?

Ver solución

Lo determina el modelo, en tiempo de ejecución, interpretando la solicitud —no un Switch ni una lista de reglas que tú hayas escrito—. Es razonable que el modelo primero llame a "consultar pedido" (para verificar que el pedido #789 existe y es cancelable) y después llame a "emitir reembolso", pero esa secuencia nunca quedó codificada con nodos de lógica. Aunque las tres acciones disponibles están perfectamente definidas —no es magia, son funciones concretas—, lo que hace que esto sea un agente y no IA procedural es que nadie fijó de antemano el orden ni cuáles de las tres se necesitan para este mensaje en particular.

Ejercicio 3. Una herramienta interna solo necesita responder "¿cuál es la política de vacaciones de la empresa?" usando el texto fijo del reglamento de RR. HH. Nunca necesita consultar un sistema externo ni variar la acción según lo que pregunte el empleado. ¿La construirías como chatbot de un turno o como agente? Justifica.

Ver solución

Como chatbot de un turno (Basic LLM Chain con el texto del reglamento en el prompt o como contexto agregado). No hay ningún sistema externo que consultar ni ninguna acción que variar según la pregunta —el espacio de "cosas que hacer" es cero, solo hay texto que interpretar y parafrasear—. Construirlo como agente añadiría el costo de tokens y la impredecibilidad de decidir entre tools, sin ganar nada a cambio: no hay ninguna tool que de verdad se necesite.

Resumen y siguiente paso

El criterio que te llevas de esta lección es simple de enunciar y difícil de aplicar mal si lo recuerdas bien: la pregunta nunca es "¿hay un modelo de IA en el flujo?", sino "¿quién decide el siguiente paso: el flujo que diseñaste, o el modelo en tiempo de ejecución?". IA procedural: decide el flujo. Chatbot de un turno: el modelo decide qué decir, no qué hacer. Agente (IA agéntica): el modelo decide qué hacer.

Lo que viste aquí es el qué distingue a un agente desde afuera. Lo que todavía no viste es el cómo: qué pasa exactamente adentro del nodo AI Agent cuando decide llamar una tool, lee el resultado, y decide otra vez. Ese ciclo de razonar, actuar y observar es el tema de la próxima lección, y es la razón de fondo por la que ese comportamiento no se puede replicar a mano con nodos de lógica, sin importar cuántas ramas de Switch le agregues.

Antes de avanzar deberías poder tomar cualquier flujo de n8n con un nodo de IA adentro y decir, en una frase, si el modelo controla el camino o si el camino ya estaba fijado de antemano —y explicar por qué, usando el ejemplo del pedido #3187 si hace falta.

Recursos

• Agents vs. chains — la distinción oficial de n8n entre ambos, con el rol de las herramientas y la memoria.
• What do AI agents do? — de aquí sale la definición "un agente es un chain que sabe tomar decisiones".
• How tools work — qué es una tool y cómo decide un agente cuándo usarla.
• Nodo AI Agent — referencia — documentación oficial del nodo que vas a construir en la lección 4.
• Nodo Basic LLM Chain — referencia — el nodo detrás del chatbot de un turno de esta lección.
• Nodo Chat Trigger — referencia — el punto de entrada compartido por los tres ejemplos.