Module 1: From Chatbot to Agent: What Changes with Agentic AI

3. What is an agentic loop: reason, act, observe

Next →

Description

By the end of this lesson you'll be able to trace, step by step, the cycle an agent runs internally every time it responds to something, and you'll be able to explain — with a concrete example, not in the abstract — why that cycle can't be cloned by building a chain of IF or Switch nodes, no matter how carefully you build it.

In the previous lesson you drew the boundary between a single-turn chatbot and an agent that acts, and between procedural AI (where the flow decides) and agentic AI (where the model decides). This lesson opens that box: what exactly does the agent do internally when it "decides"? The answer matters in real work. If you're going to build a support bot, a sales assistant, or any automation that uses the AI Agent node, you're going to need to debug it when it answers something strange, and you won't be able to if the agent is a black box to you. Understanding the cycle — and exactly where something breaks when it breaks — is what separates the person who assembles the flow from the person who keeps it running in production.

Connection to the module: this is the internal mechanism that justifies the boundary you drew in lesson 2. In lesson 4 you'll see where this cycle lives inside n8n 2.0's native AI Agent node; today you're just staying with the mechanism, without opening the node's interface yet.

The cycle behind every response

Think about the last time your home wifi stopped working. You didn't check a 40-step numbered manual ahead of time. You did something closer to this: you suspected something ("maybe the router needs a restart"), you did that specific action (restarted it), and then you checked whether the problem was still there (observed the result). If it was still broken, you formed a different suspicion with that new information — now you know it wasn't the router — and tried something else. You repeated that cycle until the wifi came back, and at that point you stopped: you already had the answer, no need to keep trying things.

That cycle — suspect something, test it, see what happened, and use that result to decide the next step — is exactly what an agent does internally, turn by turn. It has a name: it's known as reason, act, and observe (the pattern was formally documented as ReAct in a 2022 paper by Yao et al., and it's the conceptual basis for how agents with tools work today). Each word maps to a concrete step:

  • Reason: the model looks at the entire conversation — what the user asked, the system prompt, and everything it already observed in previous turns of the cycle — and decides what's next: does it already have enough information to respond, or does it need to do something first?
  • Act: if the decision was "I need to do something," the model doesn't write a reply for the user yet. It generates a structured call to one of the tools connected to the agent — with the tool's name and the arguments it decided to send it — and n8n executes that tool like any other node in the flow.
  • Observe: the result of that tool — what the API, the search, or the workflow that got called returned — gets added back to what the model can see, as if it were one more piece of data in the conversation.
  • Repeat: the model reasons again, but now with that new result available. It can decide it needs yet another tool, or it can decide it already has everything it needs, and only then does it produce the final response for whoever asked.

n8n's documentation describes it this way: when an agent runs, "the agent executes multiple times. For example, it might do an initial setup, followed by one execution to call a tool, and then another execution to evaluate that tool's response" before answering you. That's the part almost nobody sees when looking at the flow from the outside: a single message from you can trigger several complete turns of the cycle before any response appears.

And there's an important detail that's about to become useful: the number of turns isn't fixed. It can be zero — if you ask "hi, how are you?" the reasoning step might resolve that it doesn't need any tool and answer directly — it can be one, it can be five. The model decides it, case by case, reading the actual content of each situation. That's precisely the point you're going to need for the next section.

Worked example

Imagine a support agent connected to two tools: one that looks up an order's status by number, and another that checks the return policy based on the product category. A customer writes:

"My order #4521 arrived damaged, can I return it?"

Here's what the complete cycle looks like, turn by turn:

Turn 1 — Reason: the agent reads the message. It knows it needs the order number, but it doesn't yet know the product category or when it was delivered — data it's going to need to decide the return window. Decision: call the order lookup tool.

Turn 1 — Act:

search_order(order_id="4521")

Turn 1 — Observe: the tool returns

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

Turn 2 — Reason: the agent now knows it's electronics and that it was delivered 6 days ago, but it still doesn't know the return window for that category, or whether a damaged item has a different rule. Decision: call the second tool.

Turn 2 — Act:

get_return_policy(category="electronics")

Turn 2 — Observe: the tool returns

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

Turn 3 — Reason: now the agent has everything it needs: delivered 6 days ago, the normal window is 30 days, and on top of that the product arrived damaged, which triggers an additional exception. It doesn't need any more tools. Decision: respond.

Final response: "Yes, your order #4521 is within the 30-day return window for electronics, and since it arrived damaged an additional exception applies. Here's how to start the return..."

What to expect: two tool calls, three complete reasoning turns, before the response. If the same customer had written "what are your business hours?", the cycle would have had just one turn — reason, without acting or observing — because that information is already in the agent's prompt and doesn't require checking anything external. Same agent, same node, completely different number of turns depending on what you ask.

Why you can't reproduce the cycle by hand with IF or Switch

With this idea of "reasoning" deciding case by case, you can now see why the temptation to build the same behavior with manual logic nodes doesn't work, even though it might seem like it would at first.

To clone the previous example with IF/Switch nodes you'd have to fix in advance: one branch asking "does the message mention an order number?", another asking "did the order arrive damaged or not, based on the text?", another for "how many days have passed since delivery?", and combine all those branches in the right order. The first problem already shows up right there: the question "did the order arrive damaged, based on the text?" isn't something a Switch node can evaluate by comparing a value against a fixed list of options — it's a semantic interpretation of free-form text, and the customer can write it a thousand different ways ("it arrived broken," "it came in beat up," "the box was destroyed"). That's exactly what the agent's reasoning step does, and exactly what a value-comparison node doesn't do.

The second problem is the number of turns. In the IF-based flow, you decide, when designing the workflow, how many branches exist and in what order they're traversed. In the agentic cycle, that number is decided by the model on the spot, reading the previous tool's result. If tomorrow you add a third tool — say, checking whether the product is still under warranty — the agent will simply use it whenever the case calls for it, without you ever touching the flow again. With IF/Switch, every new case that shows up in production is one more branch you have to anticipate, write, and maintain; the condition tree grows without limit and never manages to cover the real variety of how people write.

Common mistakes

1. Thinking the cycle is literally text you'll be able to read raw in the node's output, like "Thought: ... Action: ... Observation: ...". The original ReAct paper described the cycle as a free-text trace the model wrote out, which then had to be parsed line by line. Today's n8n agents (the AI Agent node works as what's known as a Tools Agent) achieve the same reason-act-observe cycle, but through structured function calls exposed by the model's own API — not a free-text paragraph the node has to interpret. How to spot it: if you search the output for a field with the literal word "Thought" and it doesn't appear, that doesn't mean the cycle isn't happening; it just means it's implemented differently today than it was described in the original paper. How to fix it: think of the cycle as three interacting roles (decide, execute, receive result), not as a text monologue you have to read.

2. Trying to replace the reasoning step with a chain of IF/Switch fixed in advance. What happens: it works perfectly in the demo with the 2 or 3 test cases you built, and it breaks on the first real case you didn't anticipate — a customer who asks things in a different order, or who mentions a problem that combines two categories at once. Why it happens: you hardcoded a fixed decision where the real problem needed a variable semantic decision, made case by case. How to spot it: every new case in production forces you to add one more branch to the condition tree, and the tree never stops growing. How to fix it: let the model make that decision inside the agentic cycle (you'll see where to configure this in lesson 4), instead of precomputing the branches yourself.

3. Assuming every agent turn includes at least one tool call. As you saw in the business-hours example, the reasoning step can end directly in a final response, without ever going through act or observe. How to spot it: if you expected to see a tool execution in the logs and the agent responded without executing any, that's not a flow error — it's the cycle ending on the first turn because the model decided it didn't need anything external. How to fix it: when debugging an agent, don't look for "why didn't it call the tool?" as if it were mandatory; ask yourself first whether the case actually needed it.

Exercises

Exercise 1. A travel agent has three tools connected: search_flights, search_hotels, and convert_currency. A user writes: "I need to fly to Tokyo next week and know how much the hotel would cost in yen." Trace the complete cycle, turn by turn (reason/act/observe), stating how many times it repeats and in what likely order the tools are called.

See solution

A reasonable trace:

  • Turn 1 — Reason: the exact date is missing and the destination is clear (Tokyo), but it needs flight availability first. Act: search_flights(destination="Tokyo", date_range="next_week"). Observe: returns available flights with dates and prices in dollars.
  • Turn 2 — Reason: with the flight dates confirmed, it now needs the hotel cost for those same dates. Act: search_hotels(city="Tokyo", check_in=..., check_out=...). Observe: returns the hotel price, probably in yen or in dollars depending on the source.
  • Turn 3 — Reason: the user specifically asked for the cost in yen; if the previous result didn't come in that currency, it needs to convert. Act: convert_currency(amount=..., from="USD", to="JPY"). Observe: returns the converted amount.
  • Turn 4 — Reason: it now has flights, hotel, and the amount in the requested currency. It responds with the final answer.

Why it works: each turn only fires if the previous one left an open question the model identified as necessary to answer fully. If the search_hotels result had already come back in yen, turn 3 wouldn't have happened — again, the number of turns isn't fixed, it depends on what each observation leaves pending.

Exercise 2. A teammate tells you: "Come on, for the support bot with the damaged-order thing there are only three cases: damaged, didn't arrive, or wants to change size. I'll build them with three IFs and call it done." Give a concrete reason — not a generic one — why that's going to break, using a specific case that none of those three IFs covers.

See solution

A concrete case that breaks all three IFs: a customer writes "I only got two of the three pieces from my order, and one of the ones that did arrive had a scratch on it." This isn't pure "damaged" (some merchandise is missing, not just damaged), it isn't "didn't arrive" (it arrived partial), and it isn't "size change." It's a combination — incomplete shipment plus partial damage — that none of the three IFs anticipated, because the teammate designed the branches by looking at the cases they already knew about, not the real variety of how people describe problems. The agent, on the other hand, doesn't need a branch for "incomplete shipment + damaged": the reasoning step interprets the full sentence and decides which tools to consult (shipment status, partial refund policy) without anyone having anticipated that exact combination in advance.

Exercise 3. A customer writes to the same support agent: "Hi, do you ship to Bolivia?" Based on what you saw about the cycle's variable length, would you expect the agent to call any tool before responding? Justify your answer.

See solution

It depends on where that information lives, not on the question itself. If "do we ship to Bolivia: yes/no" is a fixed piece of data already in the agent's system prompt (a shipping policy that doesn't change per customer or per order), the reasoning step can resolve the answer on the first turn, without acting or observing — just like the business-hours example. If instead that information depends on data that changes (for example, shipping restrictions that vary by product category or by the current logistics provider), the agent is going to need a tool that checks that before responding. The lesson here is that the number of turns isn't decided by how complex the user's question appears to be, but by whether the answer is already available in what the model already knows or whether it needs to go look it up.

Summary and next step

You can now trace the cycle running inside any agent: it reasons with what it has, decides whether it needs to act, observes the result, and repeats until it decides it can respond — with a number of turns that nobody fixes in advance, not even you as the flow's designer. And you can now explain, with a specific example rather than in the abstract, why that cycle can't be cloned with a chain of IF/Switch: each turn's decision is semantic, not a value comparison, and the number of turns varies case by case.

This mechanism is the foundation for everything that follows. In the next lesson you'll see exactly where this cycle lives inside n8n 2.0: the native AI Agent node, its anatomy, and what replaced the manual logic you used to have to build yourself with logic nodes until recently.

Before moving on you should be able to: explain, without looking at any node, why the number of times an agent calls a tool isn't fixed in advance, and give your own example (not the damaged-order one) of a case where the cycle would end in zero tool turns.

Resources

← Previous2. Agent, chatbot, and procedural AI: three different thingsNext →4. The native AI Agent node in n8n 2.0