6. Agentic loops between agents: stopping conditions

Description

By the end of this lesson you'll be able to identify the three distinct loops that exist in a multi-agent system and calculate the real ceiling of model calls your system can reach in a single conversation; you'll be able to install five complementary stopping conditions — of which only one is a parameter and the other four are design decisions; and you'll be able to recognize, in the execution trace, the signature of each type of runaway loop, including the most treacherous one, which produces no error and looks like an incomplete response.

This matters because delegation gave you power, and the power arrived with no brakes. In lesson 5 you taught the orchestrator to re-delegate when a specialist responds out_of_scope. Perfect — until two specialists with fuzzy boundaries hand the same case back and forth: orders says "this is billing's," billing says "this is orders'," and the orchestrator, obediently, keeps re-delegating. Every round costs real money and real time, the customer sees a message that never arrives, and there's nothing red in n8n's panel. The other failure is the reverse and even more silent: a specialist that runs out of iterations halfway through its reasoning and returns whatever it had up to that point, which looks like a response and is a fragment of one. A multi-agent system with no explicit stopping conditions isn't a system, it's a bet.

Connection to the module: lesson 5 gave you the contract, and with it re-delegation via out_of_scope — which is precisely what makes this lesson's loop possible. Here you install the brakes. This lesson also picks back up two things from Module 1: the reason-act-observe agentic loop (lesson 3) and the AI Agent node's Max Iterations parameter (lesson 4), which back then was a detail and here is one of five pieces. What here gets bounded in number of turns, lesson 7 translates into money and seconds.

The file that bounces between two offices

Think of some paperwork you had to handle at some point. You arrive at window A, explain what you need, and they tell you: "office B handles that, in the back to the right." You go to B, explain again, and they tell you: "no, this is A's, they handle that form." You go back to A. And A sends you back to B, because the person at A doesn't remember you were already there, and neither does the one at B.

Notice three things about that scene, because they're exactly this lesson's three pieces of the problem.

Nobody's doing anything wrong. The person at A honestly believes the case is B's. The one at B honestly believes the opposite. Every individual decision is reasonable. The problem isn't in either of them: it's that nobody's keeping count.

The system has no way of noticing it's stuck. If someone asked "how many times have we sent this person from one office to the other?", the answer would end the problem in a second. But nobody has that number, because each office only sees its own turn.

You, the one doing the paperwork, get no error at all. There's no alarm. The paperwork simply doesn't move forward, and you realize it from the clock, not from a notice.

A multi-agent system reproduces that scene with one important difference: it's much faster. What would take you a morning, two agents do in eleven seconds, spending one call to the model per round. And since each individual call finishes fine, n8n's engine has nothing to report.

The real-life solution is the same one you're going to install here: someone keeps count, and on the third round there's a rule that says "this doesn't get sent to any more offices, it goes to a supervisor."

Your system's three loops

Before installing brakes you need to know how many wheels there are. In the system you built in lessons 4 and 5 there are three distinct loops, nested inside each other. They get confused easily, and each one gets braked in a different way.

Loop 1 — Each specialist's internal loop

It's Module 1's classic agentic loop: the specialist reasons, calls a tool, observes the result, reasons again. It goes as many rounds as it needs until it produces its result.

billing_specialist
  reason → lookup_charge → observe
  reason → get_customer_profile → observe
  reason → open_dispute → observe
  reason → produce result

Braked with: the specialist's own Max Iterations. When it fails: the specialist cuts off halfway and returns a partial result, with no error.

Loop 2 — The orchestrator's loop

The orchestrator delegates, reads the result, decides whether to delegate again or compose the response. It's also an agentic loop — except its "tools" are agents.

triage_agent
  reason → billing_specialist → observe result
  reason → order_specialist → observe result
  reason → compose response

Braked with: the orchestrator's Max Iterations. When it fails: the orchestrator runs out of turns before having handled every topic in the message, and answers half of it.

Loop 3 — The re-delegation loop

This is the dangerous one, and it's new: it didn't exist before there were contracts. Specialist A returns out_of_scope pointing at B; the orchestrator delegates to B; B returns out_of_scope pointing at A; the orchestrator delegates to A.

triage_agent → order_specialist   → out_of_scope: "it's billing's"
triage_agent → billing_specialist → out_of_scope: "it's orders'"
triage_agent → order_specialist   → out_of_scope: "it's billing's"
triage_agent → billing_specialist → out_of_scope: "it's orders'"
...

Braked with: an explicit policy in the orchestrator's prompt and, even better, a counter. Max Iterations eventually cuts it off, but in the worst possible way: after you've already spent the whole budget.

Why it happens. Almost always because of a poorly drawn boundary between two domains. TuTienda's classic case: "I got charged for shipping twice." Is that billing (there's a duplicate charge) or orders (shipping is the logistics domain)? If the two Descriptions don't explicitly resolve that case, both specialists are going to be right to reject it.

There's a fourth form, which shouldn't exist in your system and is worth naming: direct circular delegation, where one specialist has another as a tool and calls it directly. A calls B, B calls A, A calls B, with the orchestrator never finding out about any of it. This is the reason for lesson 3's starting rule — workers don't delegate to other workers — and it's the only one of the four that gets prevented by construction: if the graph has no cycles, this loop is impossible. It's worth verifying in the exported JSON before signing off on an architecture.

The arithmetic of nested iterations

Here's the number most people don't calculate and should.

Max Iterations comes with a default value of 10 on the AI Agent node. If you leave it that way everywhere and you have an orchestrator with three specialists, your system's theoretical ceiling is:

Ceiling of model calls in one conversation (worst case):

  orchestrator:          10 iterations
  each delegation:      up to 10 specialist iterations

  10 × 10 = 100 calls to the model, worst case,
  to answer ONE customer message.

A hundred calls to the model. That's the ceiling you left installed without noticing, if you didn't touch anything. In practice it's almost never reached — most conversations get resolved in seven or eight calls, as you saw in lesson 3's trace — but the ceiling matters for two reasons: it's what's going to happen the day loop 3 triggers, and it's what defines your worst-case cost and latency.

Here's how to think about it:

With those numbers, TuTienda's system ceiling drops from 100 to 8 × 6 = 48, and in practice it stays under ten. Those are reference numbers, not a formula: the right value for your case comes from looking at your own traces and counting how many iterations a typical case actually uses, then giving it a margin.

A concrete method for calibrating: run twenty representative cases with Return Intermediate Steps turned on, count each level's iterations in each case, take the observed maximum and add two. If the observed maximum in billing_specialist was 4, set it to 6. That margin absorbs the odd cases without leaving the door wide open.

Worked example: two traces that fail with no error

Let's read the two most common failures, so you recognize them when they show up.

Failure 1 — The silent cutoff.

The customer writes: "I got charged $1,200 I don't recognize, and also order #4521 hasn't arrived, and I want to know if any compensation applies." Three topics. The orchestrator's Max Iterations is at 4.

# triage_agent's trace — Max Iterations: 4

iteration 1 → model call: decides to delegate the charge topic
iteration 2 → tool: billing_specialist
                 → status "resolved", dispute D-8842 opened
iteration 3 → model call: decides to delegate the order topic
iteration 4 → tool: order_specialist
                 → status "resolved", order in transit

[ the agent reached its iteration limit ]

final response: "I opened dispute D-8842 for the $1,200 charge and your
order #4521 is in transit, arriving between tomorrow and the day after."

What to expect. The execution shows up green. The response looks fine. And the third topic — compensation — never got addressed, because the orchestrator ran out of turns before it could delegate it or even mention it. The customer is going to write in again asking the same thing, and the team is going to conclude "the bot doesn't understand."

How it's detected. Count the steps in intermediateSteps and compare them against the Max Iterations value. If they match exactly, there's almost certainly a cutoff. It's the most reliable signal for this failure, and it's why Return Intermediate Steps deserves to stay on while you build.

How it's fixed. Raise the limit of the level that got cut, and add an honesty instruction to the orchestrator's system prompt: "if you weren't able to address every topic in the message, say so explicitly in your response instead of only answering what you got to." A system that says "I resolved two of your three questions, I'll check on the third right away" is much better than one that pretends there were only two.

Failure 2 — The ping-pong.

The customer writes: "I got charged for shipping twice on order #4521." The boundary between billing and orders isn't resolved for this case.

# triage_agent's trace — Max Iterations: 8

iteration 1 → model: looks like a duplicate charge, I'll delegate to billing
iteration 2 → tool: billing_specialist
                 → { "status": "out_of_scope",
                     "summary": "The charge matches an order's
                                 shipment; the logistics domain handles it,
                                 order_specialist." }
iteration 3 → model: it says it's orders', re-delegate
iteration 4 → tool: order_specialist
                 → { "status": "out_of_scope",
                     "summary": "It's a duplicate charge, not a shipping
                                 problem. Belongs to billing." }
iteration 5 → model: it says it's billing's, re-delegate
iteration 6 → tool: billing_specialist
                 → { "status": "out_of_scope", ... }
iteration 7 → model: re-delegate
iteration 8 → tool: order_specialist
                 → { "status": "out_of_scope", ... }

[ iteration limit reached ]

final response: (generic or empty text, depending on the model)

What to expect. Eight calls to the orchestrator's model, four calls to complete agents — with their own internal calls — and zero value produced. If you'd had Max Iterations at 10 everywhere, this could have been considerably worse. The customer waited twenty seconds to receive nothing.

How it's detected. Look through the trace for the same tool name showing up more than twice, or two names alternating. It's an unmistakable visual pattern once you know to look for it.

How it's fixed. Here Max Iterations isn't the fix — it's what kept this from being infinite, which is different. The real fix is the next section's stopping conditions, starting with the simplest one: a rule in the orchestrator's prompt that forbids re-delegating the same topic more than once.

The five stopping conditions

A well-braked multi-agent system has five, and they're complementary: each one catches a case the others don't.

1. The hard limit: Max Iterations at every level

It's the emergency brake. It isn't an elegant stopping condition — it's what stops a problem from turning into a bill.

# Node: AI Agent — triage_agent
Options → Max Iterations: 8

# Node: AI Agent Tool — billing_specialist
Options → Max Iterations: 6

# Node: AI Agent Tool — order_specialist
Options → Max Iterations: 5

# Node: AI Agent Tool — sales_specialist
Options → Max Iterations: 4

What it catches: any loop, eventually. What it doesn't catch: nothing gracefully. When this brake kicks in, you've already spent the whole budget and the result is a cut-off response. Think of it as the electrical system's fuse: essential, and if it blows often that means there's another problem to solve.

2. The exit criterion in the prompt

The semantic stop: the agent knows it's done because you wrote it down.

# Fragment of billing_specialist's System Message

  Your work is done when any of these things happens:
  - You found the charge and can explain it.
  - You didn't find it and opened the dispute.
  - You determined what data is missing to be able to search for it.
  - You determined the case isn't your domain.
  As soon as one of the four happens, return your result.
  Don't keep investigating "just in case."

What it catches: loop 1, the specialist's internal one, which is the one that runs longest when the prompt doesn't say when to stop. An agent with no explicit exit criterion tends to keep checking tools as long as it has iterations left. What it doesn't catch: loops between agents, because each individual specialist is correctly finishing its own turn.

3. Terminal states

From lesson 5's contract: there are status values after which nothing gets retried.

# Fragment of triage_agent's System Message

  Terminal states — when a specialist returns one of these,
  do NOT delegate again on that topic under any circumstances:
  - "needs_human": tell the customer the team will follow up and
    close the turn.
  - "pending_info": ask the customer exactly what's missing and close
    the turn. The conversation continues, but this turn ends here.

What it catches: the useless retry, which is the most frequent loop in practice. An orchestrator without this rule, faced with a pending_info, tends to try another specialist "to see if that one can" — and the other one can't either, because the data is still missing. What it doesn't catch: the out_of_scope ping-pong, which by definition isn't a terminal state — re-delegating is the right response the first time.

4. The delegation budget

Here's the specific fix for ping-pong. The idea: keep count of how many times a given topic has been delegated, and cut it off at two.

n8n has no native "delegation depth" counter — it's worth saying that clearly instead of inventing a parameter. There are three practical ways to get it, from simplest to most robust:

Form A — The rule in the prompt. The simplest, and surprisingly effective, because the orchestrator has the trace of its own calls in its context:

# Fragment of triage_agent's System Message

  Delegation budget: for a given customer topic, you can delegate at
  most TWICE.
  - First delegation: to whichever specialist seems to fit.
  - If it returns "out_of_scope", second delegation to the one it
    points to.
  - If the second one also returns "out_of_scope", do NOT delegate a
    third time. The case has no clear owner: tell the customer you're
    going to escalate it and close the turn.
  Never call the same specialist twice for the same topic.

Form B — The counter in the assignment. More explicit: the task includes which attempt this is, and the specialist sees it.

# In the AI Agent Tool's $fromAI

{{ $fromAI("task", "Self-contained assignment. ALWAYS start with the line 'Attempt N of 2:' where N is 1 if this is the first time this topic is delegated, or 2 if another specialist already rejected it. If it's attempt 2, include what the previous specialist said.", "string") }}

With that, the specialist receives "Attempt 2 of 2: order_specialist rejected this case saying it was a duplicate charge…" and its system prompt can have a rule: "if you receive an attempt 2, resolve it with what you have or return needs_human; don't return out_of_scope." The ping-pong gets cut off by design, at the level where it happens.

Form C — The hard wall in a sub-workflow. The only one that doesn't depend on the model obeying. If the specialist is set up as a sub-workflow (lesson 4), you can put a Code node at the start that reads the assignment's counter and ends the execution if it exceeds the limit, without ever calling the model:

// Code node — at the start of the specialist's sub-workflow
// Cuts off the delegation before spending a call to the model.
// The counter comes in the assignment; if it's not there, we assume the first one.
const attempt = $input.first().json.attempt ?? 1;

if (attempt > 2) {
  return [{
    json: {
      status: 'needs_human',
      summary: 'The delegation budget for this case ran out.',
      data: {},
      missing: [],
    },
  }];
}

// If it's within budget, let the assignment through to the agent.
return $input.all();

What it catches: loop 3, the ping-pong, which is the only one the other four conditions don't handle well. What it doesn't catch: nothing else — it's specific.

Which one to use. Start with Form A. If you see in the trace that the ping-pong still happens, move to B. Reserve C for systems where the cost of one extra round is significant, or where the specialist is already set up as a sub-workflow for other reasons.

5. The graph rule: workers are leaves

The stopping condition that costs nothing because it's structural: if no specialist has another agent connected to its ai_tool port, direct circular delegation is impossible. You don't have to trust any prompt or any counter — the graph has no cycles.

How to verify it, in thirty seconds: export the workflow as JSON and look for connections of type ai_tool. Each one should point to an agent that isn't a tool of anyone else further down. In a three-specialist system, the ai_tool connections should form exactly two levels: specialists → orchestrator, and domain tools → specialists. If a third layer shows up, or if a name shows up as both origin and destination in two different entries, you have a possible cycle.

What it catches: direct circular delegation, by construction. What it doesn't catch: the ping-pong via the orchestrator, which isn't a graph cycle but a reasoning cycle — the graph is still a tree and the loop happens anyway.

The table of five

Install all five. Each one catches a case the others don't, and none replaces another.

When the stop is imposed by an error

There's one case missing that isn't a loop and gets confused with one: the execution that stops because something failed technically.

If a domain tool fails — the carrier's API doesn't respond, the database rejects the connection — the default behavior depends on how that node's error handling is configured. There are two things worth deciding explicitly in a multi-agent system:

What reaches the specialist when its tool fails. If the error propagates and stops the entire execution, the orchestrator never receives anything and the customer sees silence. It's usually preferable for the error to reach the specialist as a result — "the query failed" — so it can apply its failure contract and return needs_human with an explanation. That gets configured on the tool's node, with the continue-on-error options n8n offers.

How long all of this can take. A system with nested delegations can take considerably longer than a standalone agent, and an execution left waiting indefinitely for a downed API consumes resources and leaves the customer hanging. n8n lets you configure a maximum execution time in the workflow's settings; in a multi-agent system it's worth setting that consciously instead of leaving it open. Lesson 7 gives you the calculation to know what value is reasonable for your case.

A note about retrying: if your specialist's failure contract says "retry exactly once," make sure that "exactly once" is written down and verifiable in the trace. A model you tell "retry if it fails" with no limit is going to retry as long as it has iterations left, and that's another loop, with the particular quirk that every round also hits the external system that was already failing.

Common mistakes

Trusting that Max Iterations is the stopping condition (conceptual). What happens: someone sets conservative limits on all agents and considers the topic closed. The system never hangs, true — but it produces cut-off responses on a regular basis, and nobody connects them to the limit because there's no error. Why it happens: it's the only brake that looks like a configurable parameter, and configuring something feels like solving it. How to spot it: count how many executions end with a number of steps exactly equal to the limit; if it's more than 5%, your system is living against the ceiling. How to fix it: Max Iterations is the fuse, not the switch. The stops you want acting day to day are the semantic ones: exit criterion, terminal states, and delegation budget.

Setting the same Max Iterations at every level (conceptual). What happens: someone leaves 10 on the orchestrator and 10 on every specialist, without noticing that multiplies. The system's worst case is 100 calls to the model, when the typical case is 7. Why it happens: the parameter is in the same place on every node and the default value is the same, so nothing invites differentiating it. How to spot it: multiply the orchestrator's limit by the most generous specialist's limit; that number is your worst case, and it's probably going to surprise you. How to fix it: calibrate with the observed-maximum-plus-two rule, per level, and remember a specialist with two tools rarely needs more than four iterations.

Treating out_of_scope as a specialist failure (conceptual). What happens: someone sees several out_of_scopes in the trace, concludes the specialists are misconfigured, and widens both their scopes so "neither rejects cases." The ping-pong disappears and something worse shows up in its place: two specialists that accept the same case and resolve it differently depending on which one got it. Why it happens: the ping-pong looks like a specialist problem when it's a boundary-between-them problem. How to spot it: gather the cases that produced ping-pong and look for what they have in common; they're almost always the same kind of ambiguous case, not a variety. How to fix it: resolve the boundary explicitly in both Descriptions — "a duplicate shipping charge belongs to billing_specialist, even if it refers to an order" — and let out_of_scope keep existing for what it's for: an honest signal that the orchestrator picked the wrong recipient.

Building the hard wall before you need it (practical). What happens: someone reads Form C, sets up all their specialists as sub-workflows with Code nodes counting attempts, and ends up with an eight-workflow system for three specialists that never had ping-pong. Why it happens: the most robust solution feels like the most professional one. How to spot it: ask yourself how many times you observed the problem you're preventing; if the answer is zero, you're paying for complexity in advance. How to fix it: Form A first, always. Move up to B or C when the trace shows you it's needed — and the trace is going to show you clearly, because ping-pong has an unmistakable visual signature.

Not checking the graph after adding a specialist (practical). What happens: six months later, someone adds an escalation_specialist and, so it can check billing data, connects billing_specialist to it as a tool. They just created a two-agent path that can call each other, and nobody noticed because on the canvas it looks like just another connection. Why it happens: the "workers are leaves" rule is a convention, not something n8n enforces. How to spot it: export the JSON and review the ai_tool connections; they should form exactly two levels. How to fix it: if a specialist genuinely needs data from another domain, give it the read tool it needs — lookup_charge — instead of the whole agent; sharing a read tool creates no cycle.

Exercises

Exercise 1 — Calculate the ceiling. A system has an orchestrator with Max Iterations at 10 and four specialists: two with a limit of 10, one with 6, and one with 3. (a) What's the worst case for calls to the model to answer one message? (b) If the typical case observed in the trace uses 3 orchestrator iterations and up to 4 for a specialist, what values would you set at each level?

Exercise 2 — Diagnose the trace. Read this trace and say what failure it is, how you recognized it, and which of the five stopping conditions would have prevented it:

triage_agent — Max Iterations: 8
  1 → model
  2 → tool: order_specialist   → status "pending_info", missing: ["order_id"]
  3 → model
  4 → tool: sales_specialist   → status "out_of_scope"
  5 → model
  6 → tool: order_specialist   → status "pending_info", missing: ["order_id"]
  7 → model
  8 → tool: billing_specialist → status "out_of_scope"
  [ limit reached ]

Exercise 3 — Resolve the boundary. The ping-pong for the case "I got charged for shipping twice on order #4521" keeps happening. Write the two lines you'd add to billing_specialist's and order_specialist's Descriptions so this case stops bouncing, and explain why that fix is better than raising Max Iterations.

# Added to billing_specialist's Description
  Duplicate charges are ALWAYS your domain, even when the duplicated
  charge corresponds to shipping, a service, or any concept tied to
  an order. If the customer reports being charged for something
  twice, it's yours.

# Added to order_specialist's Description
  Duplicate charges are NOT your domain, even if the charge refers to
  an order's shipping: billing_specialist handles that. You handle
  the shipment itself (where it is, when it arrives, at what
  address), not what got charged for it.

Summary and next step

You now have the brakes. Your system has three nested loops — each specialist's internal one, the orchestrator's, and re-delegation between agents — plus a fourth the graph rule makes impossible. Iteration limits multiply across levels, so a system with default values has a ceiling of a hundred calls to the model that almost nobody calculates. And the five stopping conditions are complementary: Max Iterations as a fuse, the exit criterion in the prompt for the internal loop, terminal states for useless retries, the delegation budget for ping-pong, and the cycle-free graph for direct circular delegation. The two typical failures — the silent cutoff and the ping-pong — produce no error in n8n and get recognized by their signature in the trace: steps that exactly match the limit, and the same tool showing up two or more times.

Before moving on you should be able to: calculate your system's worst case by multiplying limits; calibrate Max Iterations per level with the observed-maximum-plus-two rule; name the five stopping conditions and which loop each one catches; and diagnose a trace, telling a silent cutoff apart from a ping-pong.

What's left is translating all of this into the two units that matter outside the technical team: money and seconds. A hundred-call ceiling to the model sounds bad, but how much is that in dollars? How long does each delegation actually take? At what point does a specialist stop being worth what it costs? Lesson 7 puts the calculator on the table and gives you the levers to adjust — including the most uncomfortable one, which is deciding an agent shouldn't exist.

Resources

• AI Agent node — n8n Docs — reference for Max Iterations and Return Intermediate Steps, the two options this whole lesson rests on.
• AI Agent Tool node — n8n Docs — the same pair of options at the specialist level, which is where they multiply.
• Error handling — n8n Docs — how to decide whether a tool error stops the execution or reaches the agent as a result it can handle.
• Workflow settings — n8n Docs — where a workflow's maximum execution time gets set, an additional brake worth setting consciously in systems with nested delegations.
• Code node — n8n Docs — reference for the node Form C's hard wall is implemented with, including the [{ json: {...} }] return format.
• View past executions — n8n Docs — the panel where you read traces and count steps, which is how this lesson's two failures get detected.