Módulo 1: De chatbot a agente: qué cambia con la IA agéntica

3. Qué es un bucle agéntico: razonar, actuar, observar

Siguiente →

Descripción

Al terminar esta lección vas a poder trazar, paso a paso, el ciclo que un agente ejecuta por dentro cada vez que responde algo, y vas a poder explicar —con un ejemplo concreto, no en abstracto— por qué ese ciclo no se puede clonar armando una cadena de nodos IF o Switch, por más cuidado que le pongas.

En la lección anterior trazaste la frontera entre un chatbot de un turno y un agente que actúa, y entre la IA procedural (donde el flujo decide) y la IA agéntica (donde el modelo decide). Esta lección abre esa caja: ¿qué hace exactamente el agente por dentro cuando "decide"? La respuesta importa en el trabajo real. Si vas a construir un bot de soporte, un asistente de ventas o cualquier automatización que use el nodo AI Agent, vas a necesitar depurarlo cuando responda algo raro, y no vas a poder hacerlo si para ti el agente es una caja negra. Entender el ciclo —y en qué momento exacto se rompe algo cuando se rompe— es lo que separa a quien arma el flujo de quien lo sostiene en producción.

Conexión con el módulo: este es el mecanismo interno que justifica la frontera que trazaste en la lección 2. En la lección 4 vas a ver dónde vive este ciclo dentro del nodo AI Agent nativo de n8n 2.0; hoy te quedas solo con el mecanismo, sin abrir todavía la interfaz del nodo.

El ciclo detrás de cada respuesta

Piensa en la última vez que tu wifi en casa dejó de funcionar. No revisaste un manual con 40 pasos numerados de antemano. Hiciste algo más parecido a esto: sospechaste algo ("quizás el router necesita reiniciarse"), hiciste esa acción concreta (lo reiniciaste), y después revisaste si el problema seguía ahí (observaste el resultado). Si seguía roto, formulaste otra sospecha distinta con esa nueva información —ahora sabes que no era el router— y probaste otra cosa. Repetiste ese ciclo hasta que el wifi volvió, y en ese momento paraste: ya tenías la respuesta, no hacía falta seguir probando cosas.

Ese ciclo —sospechar algo, probarlo, ver qué pasó, y usar ese resultado para decidir el siguiente paso— es exactamente lo que hace un agente por dentro, turno a turno. Tiene nombre: se conoce como razonar, actuar y observar (el patrón se documentó formalmente como ReAct en un paper de Yao et al. de 2022, y es la base conceptual de cómo funcionan hoy los agentes con herramientas). Cada palabra corresponde a un paso concreto:

  • Razonar: el modelo mira la conversación completa —lo que el usuario pidió, el system prompt, y todo lo que ya observó en vueltas anteriores del ciclo— y decide qué sigue: ¿ya tiene suficiente información para responder, o necesita hacer algo primero?
  • Actuar: si la decisión fue "necesito hacer algo", el modelo no escribe una respuesta para el usuario todavía. Genera una llamada estructurada a una de las herramientas conectadas al agente —con el nombre de la herramienta y los argumentos que decidió enviarle—, y n8n ejecuta esa herramienta como si fuera cualquier otro nodo del flujo.
  • Observar: el resultado de esa herramienta —lo que devolvió la API, la búsqueda, el workflow que se llamó— se agrega de vuelta a lo que el modelo puede ver, como si fuera un dato más de la conversación.
  • Repetir: el modelo vuelve a razonar, pero ahora con ese resultado nuevo disponible. Puede decidir que necesita otra herramienta más, o puede decidir que ya tiene todo lo necesario y ahí sí produce la respuesta final para quien preguntó.

La documentación de n8n lo describe así: cuando corre un agente, "el agente se ejecuta varias veces. Por ejemplo, puede hacer una configuración inicial, seguida de una ejecución para llamar a una herramienta, y luego otra ejecución para evaluar la respuesta de esa herramienta" antes de contestarte. Esa es la parte que casi nadie ve al mirar el flujo desde afuera: un solo mensaje tuyo puede disparar varias vueltas completas del ciclo antes de que aparezca cualquier respuesta.

Y hay un detalle importante que se te va a hacer útil enseguida: el número de vueltas no está fijo. Puede ser cero —si preguntas "hola, ¿cómo estás?" el paso de razonar puede resolver que no necesita ninguna herramienta y responde directo—, puede ser una, pueden ser cinco. Lo decide el modelo, caso por caso, leyendo el contenido real de cada situación. Ese es precisamente el punto que vas a necesitar para la siguiente sección.

Ejemplo trabajado

Imagina un agente de soporte conectado a dos herramientas: una que busca el estado de un pedido por número, y otra que consulta la política de devoluciones según la categoría del producto. Un cliente escribe:

"Mi pedido #4521 llegó dañado, ¿lo puedo devolver?"

Así se ve el ciclo completo, vuelta por vuelta:

Vuelta 1 — Razonar: el agente lee el mensaje. Sabe que necesita el número de pedido, pero todavía no sabe la categoría del producto ni cuándo se entregó —datos que va a necesitar para decidir la ventana de devolución. Decisión: llamar a la herramienta de búsqueda de pedidos.

Vuelta 1 — Actuar:

search_order(order_id="4521")

Vuelta 1 — Observar: la herramienta devuelve

{"category": "electronics", "delivered_at": "2026-07-15", "status": "delivered"}

Vuelta 2 — Razonar: el agente ya sabe que es electrónica y que se entregó hace 6 días, pero todavía no sabe cuál es la ventana de devolución para esa categoría, ni si un producto dañado tiene alguna regla distinta. Decisión: llamar a la segunda herramienta.

Vuelta 2 — Actuar:

get_return_policy(category="electronics")

Vuelta 2 — Observar: la herramienta devuelve

{"return_window_days": 30, "damaged_item_extra_window": true}

Vuelta 3 — Razonar: ahora el agente tiene todo lo que necesita: se entregó hace 6 días, la ventana normal es de 30 días, y encima el producto llegó dañado, lo cual activa una excepción adicional. No necesita ninguna herramienta más. Decisión: responder.

Respuesta final: "Sí, tu pedido #4521 está dentro de la ventana de devolución de 30 días para electrónica, y como llegó dañado aplica además una excepción adicional. Te explico cómo iniciar la devolución..."

Qué esperar: dos llamadas a herramientas, tres vueltas completas de razonar, antes de la respuesta. Si el mismo cliente hubiera escrito "¿cuál es el horario de atención?", el ciclo habría tenido una sola vuelta —razonar, sin actuar ni observar— porque esa información ya está en el prompt del agente y no requiere consultar nada externo. El mismo agente, el mismo nodo, dos números de vueltas completamente distintos según lo que pidas.

Por qué no puedes reproducir el ciclo a mano con IF o Switch

Con esta idea del "razonar" decidiendo caso por caso, ya puedes ver por qué la tentación de armar el mismo comportamiento con nodos de lógica manual no funciona, aunque al principio parezca que sí.

Para clonar el ejemplo anterior con nodos IF/Switch tendrías que fijar de antemano: una rama que pregunte "¿el mensaje menciona un número de pedido?", otra que pregunte "¿el pedido llegó dañado o no llegó, según el texto?", otra para "¿cuántos días pasaron desde la entrega?", y combinar todas esas ramas en el orden correcto. El primer problema ya aparece ahí: la pregunta "¿el pedido llegó dañado, según el texto?" no es algo que un nodo Switch pueda evaluar comparando un valor contra una lista de opciones fijas —es una interpretación semántica de una frase libre, y el cliente puede escribirla de mil formas distintas ("llegó roto", "vino golpeado", "la caja estaba destruida"). Eso es exactamente lo que hace el paso de razonar del agente, y exactamente lo que un nodo de comparación de valores no hace.

El segundo problema es el número de vueltas. En el flujo con IF, tú decides, al diseñar el workflow, cuántas ramas existen y en qué orden se recorren. En el ciclo agéntico ese número lo decide el modelo en el momento, leyendo el resultado de la herramienta anterior. Si mañana agregas una tercera herramienta —por ejemplo, verificar si el producto todavía tiene garantía—, el agente simplemente la va a usar cuando el caso lo amerite, sin que vuelvas a tocar el flujo. Con IF/Switch, cada caso nuevo que aparece en producción es una rama más que tienes que anticipar, escribir y mantener; el árbol de condiciones crece sin límite y nunca alcanza a cubrir la variedad real de cómo la gente escribe.

Errores comunes

1. Pensar que el ciclo es literalmente un texto "Thought: ... Action: ... Observation: ..." que vas a poder leer crudo en el output del nodo. El paper original de ReAct describía el ciclo como una traza de texto libre que el modelo escribía y que después había que parsear línea por línea. Los agentes de n8n de hoy (el nodo AI Agent trabaja como lo que se conoce como Tools Agent) logran el mismo ciclo razonar-actuar-observar, pero mediante llamadas a función estructuradas que expone la propia API del modelo —no un párrafo de texto libre que el nodo tenga que interpretar. Cómo detectarlo: si buscas en el output un campo con la palabra literal "Thought" y no aparece, no significa que el ciclo no esté ocurriendo; solo significa que hoy se implementa distinto a como se describió en el paper original. Cómo corregirlo: pensar el ciclo como tres roles que interactúan (decidir, ejecutar, recibir resultado), no como un monólogo de texto que hay que leer.

2. Intentar reemplazar el paso de razonar con una cadena de IF/Switch fijada de antemano. Qué pasa: funciona perfecto en la demo con los 2 o 3 casos de prueba que armaste, y se rompe en el primer caso real que no anticipaste —un cliente que pregunta las cosas en otro orden, o que menciona un problema que combina dos categorías a la vez. Por qué pasa: codificaste una decisión fija donde el problema real necesitaba una decisión semántica variable, tomada caso por caso. Cómo detectarlo: cada caso nuevo en producción te obliga a agregar una rama más al árbol de condiciones, y el árbol nunca deja de crecer. Cómo corregirlo: dejar que el modelo tome esa decisión dentro del ciclo agéntico (vas a ver dónde configurar esto en la lección 4), en lugar de precomputar las ramas tú mismo.

3. Asumir que cada turno del agente incluye por lo menos una llamada a herramienta. Como viste en el ejemplo del horario de atención, el paso de razonar puede terminar directo en una respuesta final, sin pasar nunca por actuar ni observar. Cómo detectarlo: si esperabas ver una ejecución de herramienta en los logs y el agente respondió sin ejecutar ninguna, no es un error del flujo —es el ciclo terminando en la primera vuelta porque el modelo decidió que no necesitaba nada externo. Cómo corregirlo: cuando depures un agente, no busques "¿por qué no llamó a la herramienta?" como si fuera obligatorio; pregúntate primero si el caso realmente la necesitaba.

Ejercicios

Ejercicio 1. Un agente de viajes tiene tres herramientas conectadas: search_flights, search_hotels y convert_currency. Un usuario escribe: "Necesito volar a Tokio la semana que viene y saber cuánto me costaría el hotel en yenes." Traza el ciclo completo, vuelta por vuelta (razonar/actuar/observar), indicando cuántas veces se repite y en qué orden probable se llaman las herramientas.

Ver solución

Una traza razonable:

  • Vuelta 1 — Razonar: falta la fecha exacta y el destino está claro (Tokio), pero necesita disponibilidad de vuelos primero. Actuar: search_flights(destination="Tokyo", date_range="next_week"). Observar: devuelve vuelos disponibles con fechas y precios en dólares.
  • Vuelta 2 — Razonar: con las fechas de vuelo confirmadas, ahora necesita el costo del hotel para esas mismas fechas. Actuar: search_hotels(city="Tokyo", check_in=..., check_out=...). Observar: devuelve precio del hotel, probablemente en yenes o en dólares según la fuente.
  • Vuelta 3 — Razonar: el usuario pidió el costo específicamente en yenes; si el resultado anterior no vino en esa moneda, necesita convertir. Actuar: convert_currency(amount=..., from="USD", to="JPY"). Observar: devuelve el monto convertido.
  • Vuelta 4 — Razonar: ya tiene vuelos, hotel y el monto en la moneda pedida. Responde con la respuesta final.

Por qué funciona: cada vuelta solo se dispara si la anterior dejó una pregunta abierta que el modelo identificó como necesaria para responder completo. Si el resultado de search_hotels ya hubiera venido en yenes, la vuelta 3 no habría ocurrido —de nuevo, el número de vueltas no es fijo, depende de lo que cada observación deja pendiente.

Ejercicio 2. Un compañero de equipo te dice: "Total, para el bot de soporte con lo de pedidos dañados son solo tres casos: dañado, no llegó, o quiere cambiar de talla. Los armo con tres IF y listo." Dale una razón concreta —no genérica— de por qué eso se va a romper, usando un caso puntual que ninguno de esos tres IF cubre.

Ver solución

Un caso concreto que rompe los tres IF: un cliente escribe "me llegaron dos de las tres piezas del pedido, y una de las que sí llegó vino con un rayón". Esto no es "dañado" puro (falta mercadería, no solo hay daño), no es "no llegó" (llegó parcial), y no es "cambio de talla". Es una combinación —envío incompleto más daño parcial— que ninguno de los tres IF anticipó, porque el compañero diseñó las ramas mirando los casos que ya conocía, no la variedad real de cómo la gente describe problemas. El agente, en cambio, no necesita una rama para "envío incompleto + dañado": el paso de razonar interpreta la frase completa y decide qué herramientas consultar (estado del envío, política de reembolso parcial) sin que nadie haya anticipado esa combinación exacta de antemano.

Ejercicio 3. Un cliente le escribe al mismo agente de soporte: "Hola, ¿hacen envíos a Bolivia?" Basándote en lo que viste sobre el largo variable del ciclo, ¿esperarías que el agente llame a alguna herramienta antes de responder? Justifica.

Ver solución

Depende de dónde vive esa información, no de la pregunta en sí. Si "hacemos envíos a Bolivia: sí/no" es un dato fijo que ya está en el system prompt del agente (política de envíos, no cambia por cliente ni por pedido), el paso de razonar puede resolver la respuesta en la primera vuelta, sin actuar ni observar —igual que el ejemplo del horario de atención. Si en cambio esa información depende de datos que cambian (por ejemplo, restricciones de envío que varían por categoría de producto o por proveedor logístico actual), el agente va a necesitar una herramienta que consulte eso antes de responder. La lección aquí es que el número de vueltas no lo decide la complejidad aparente de la pregunta del usuario, sino si la respuesta ya está disponible en lo que el modelo ya sabe o si necesita ir a buscarla.

Resumen y siguiente paso

Ya puedes trazar el ciclo que corre por dentro de cualquier agente: razona con lo que tiene, decide si necesita actuar, observa el resultado, y repite hasta que decide que ya puede responder —con un número de vueltas que nadie fija de antemano, ni siquiera tú como diseñador del flujo. Y ya puedes explicar, con un ejemplo puntual y no en abstracto, por qué ese ciclo no se deja clonar con una cadena de IF/Switch: la decisión de cada vuelta es semántica, no una comparación de valores, y el número de vueltas varía caso por caso.

Este mecanismo es la base de todo lo que viene. En la próxima lección vas a ver dónde vive exactamente este ciclo dentro de n8n 2.0: el nodo AI Agent nativo, su anatomía, y qué reemplazó a la lógica manual que hasta hace poco tenías que armar tú mismo con nodos de lógica.

Antes de avanzar deberías poder: explicar sin ver ningún nodo por qué el número de veces que un agente llama a una herramienta no está fijo de antemano, y dar un ejemplo propio (no el del pedido dañado) de un caso donde el ciclo terminaría en cero vueltas de herramienta.

Recursos

← Anterior2. Agente, chatbot y IA procedural: tres cosas distintasSiguiente →4. El nodo AI Agent nativo en n8n 2.0