7. Cost and latency of a multi-agent system

Description

By the end of this lesson you'll be able to calculate, with data already sitting in n8n's execution panel, how much a conversation in your multi-agent system costs and how long it takes compared to what it would cost and take with a single agent; you'll be able to apply six concrete levers to bring that number down without losing accuracy; and you'll be able to decide, with an explicit criterion, when a specialist isn't worth what it costs and needs to be collapsed back.

This matters because up to this point this module sold you an idea — separating responsibilities improves accuracy — without charging you the price. The price exists and it isn't small: in lesson 3's trace you saw seven calls to the model to answer a message a monolithic agent would have answered with three. That's more than double the cost and, what usually hurts more, more than double the customer's wait time. In a demo it doesn't show. In a system handling two thousand conversations a month it does, and sooner or later the conversation with whoever pays the bill arrives. Being able to say "each conversation costs X and takes Y, and without delegation it would cost 0.4X but fail in 15% of cases" is what turns a technical decision into a defensible one. It's also, very concretely, what separates someone who built a system from someone who put it in production.

Connection to the module: lesson 6 bounded how many rounds your system can take. This lesson translates those rounds into money and seconds, and gives you the levers to adjust them. It's the whole module's honest counterweight: this is where every agent you created in lesson 2 gets justified, or where you discover one of them doesn't. Lesson 8 applies all of this to the mini-project, with a real measurement as the delivery criterion.

The meeting that cost more than the decision

Think of a work meeting where something small needs to be decided: which coffee vendor to hire. Six people are there, each earns a salary, the meeting runs an hour. The annual savings between vendor A and vendor B are modest. Someone does the math under their breath and discovers the meeting cost more than the difference between the two vendors.

Nobody did anything wrong. Every person contributed something valid. The problem is the decision-making mechanism — six people, an hour — was disproportionate to the decision that had to be made.

A multi-agent system has exactly this risk, and with the same friendly face: every delegation contributes something valid, every specialist improves the accuracy of its part, and yet the whole can still end up costing more than it's worth. The difference from the meeting is that here you actually can do the math precisely, and you should.

And there's an asymmetry worth understanding from the start: the cost of delegating always gets paid, the accuracy it buys only gets collected sometimes. Every conversation pays for the specialist's calls to the model, including simple conversations where the monolith would have gotten it right anyway. The accuracy gain only shows up in the hard cases. If your traffic is 90% simple cases and 10% hard ones, you're paying the expensive mechanism 100% of the time to win on 10%. That can still be worth it — it depends on how much an error costs in that 10% — but it's a calculation that needs to be made, not an intuition.

Where the cost comes from

To bring a number down you have to understand what it's made of. The cost of a conversation in an LLM-based system is made up of input tokens and output tokens, and in a multi-agent system there are four sources that don't exist in a standalone agent.

Source 1 — Every iteration resends the whole context

This is the most important one and the least intuitive. A language model has no memory between calls: every turn of the agentic loop sends the complete system prompt again, the descriptions of all the tools, and everything accumulated up to that point.

So when billing_specialist takes four iterations, you don't pay for its system prompt once: you pay for it four times. And with it, its three tools' descriptions, four times. And the assignment, four times. Plus the tool results piling up.

Iteration 1: [system prompt] + [3 tool descriptions] + [assignment]
Iteration 2: [system prompt] + [3 descriptions] + [assignment] + [tool 1 result]
Iteration 3: [system prompt] + [3 descriptions] + [assignment] + [res. 1] + [res. 2]
Iteration 4: [system prompt] + [3 descriptions] + [assignment] + [res. 1] + [res. 2] + [res. 3]

The context grows every round and everything before gets paid for again. That's why Max Iterations isn't just a stopping condition: it's a first-order cost lever, and that's why a specialist that gets stuck is so expensive.

Source 2 — The orchestrator also iterates, and its context includes what the specialists return

The orchestrator does the same thing, with the added weight that its context includes the complete conversation (it has memory connected) plus every delegation's result. After two delegations, the orchestrator's third call to the model carries the conversation history, its three specialists' descriptions, and the two summarys it already received.

Source 3 — The self-contained assignment

Here you pay for a design decision you made in lesson 3. Since the specialist has no memory, the orchestrator has to pack every relevant piece of data from the conversation into the assignment. That assignment can be considerably longer than the customer's original message, and it travels on every one of the specialist's iterations.

It's a real cost and it's a good deal: the alternative — giving the specialist memory — would duplicate the full history instead of a summary, on top of lesson 3's sync problems. But it's worth knowing about, because it's where a lever hides: a well-written three-sentence assignment costs much less than a three-paragraph one, and usually works just as well or better.

Source 4 — The specialist's output tokens that nobody reads

The specialist produces a summary. The orchestrator reads it and writes its own response to the customer. In other words: you pay to generate an intermediate text the customer never sees. That's unavoidable in the pattern, and it's another reason lesson 5's output contract asks for a two-or-three-sentence summary and not a complete account.

The approximate formula

There's no exact formula — it depends on your prompts, your tools, and your case — but this approximation is useful for reasoning:

Cost of a conversation ≈
    (orchestrator's iterations × orchestrator's average context)
  + Σ for each delegation:
      (that specialist's iterations × that specialist's average context)

The important thing about that expression isn't calculating it precisely: it's noticing that iterations multiply, they don't add. Lowering a specialist's Max Iterations from 8 to 4 doesn't linearly cut its cost by 50% — it cuts it by more, because the eliminated iterations are the biggest-context ones, the last ones.

Latency: why it adds up instead of splitting

Cost can be argued about. Latency is felt by the customer.

The structural property to understand is this: a delegation is a call to a tool, and a call to a tool blocks the agent that made it. The orchestrator sends the assignment to billing_specialist and sits there waiting. While the specialist reasons, calls three tools, and reasons again, the orchestrator isn't doing anything. When the specialist returns, the orchestrator picks back up.

time →

orchestrator ██                    ██                    ██
                 └─ billing ─────┘     └─ order ──────┘
                    ████████████         ████████

Total time is the sum of everything, not the maximum. And inside each specialist's time is, in turn, the sum of its own calls to the model and to its tools.

A trace like lesson 3's — three calls to the orchestrator's model, two from the billing specialist plus three calls to tools, two from the orders one plus one to a tool — adds up to seven calls to the model and four to external systems, all in series. If every call to the model takes a couple seconds and every tool takes about the same, you're already in a range where the customer notices the wait.

Can it be parallelized? With nuances, and it's worth being honest. A model can, on a single turn, request more than one tool call; when that happens, those calls don't depend on each other and don't have to run one after the other. But it's not something you control with a parameter: it depends on the model deciding to request them together, which depends on the model, the prompt, and the case. Don't design counting on that. Design assuming delegations are sequential, and if they sometimes overlap, all the better.

What you do control is how many delegations there are. A message that triggers two delegations takes roughly twice as long as one that triggers one. That's the real latency lever, and it's the same as the cost one: fewer rounds.

Worked example: a conversation's cost sheet

Let's do the math for TuTienda. Important note before starting: the numbers that follow are hypothetical, put there so you see the shape of the calculation. Per-token prices from every provider change frequently and vary a lot between model families, so the number that matters to you has to come from the real execution and your provider's current price on the day you measure it. What doesn't change is the method.

The case: the message from earlier lessons — unrecognized charge plus an order inquiry — which triggers two delegations.

To make it comparable, we'll set a hypothetical unit: let's say one call to the orchestrator's model (with memory connected, large context) equals 3 cost units, and one call to a specialist's model (smaller context, short prompt) equals 1 unit. The numbers are made up; the proportions are plausible because the orchestrator's context includes the history and the specialist's doesn't.

Scenario A — Monolithic agent

Call	Units
Model (decides, calls lookup_charge)	3
Model (evaluates, calls get_customer_profile)	3
Model (evaluates, calls open_dispute)	3
Model (calls lookup_order)	3
Model (composes response)	3
Total	15 units

Scenario B — Team with delegation

Call	Units
Orchestrator: decides to delegate	3
billing_specialist: reasons	1
billing_specialist: after lookup_charge	1
billing_specialist: after get_customer_profile	1
billing_specialist: after open_dispute, produces result	1
Orchestrator: evaluates, decides to delegate the second topic	3
order_specialist: reasons	1
order_specialist: after lookup_order, produces result	1
Orchestrator: composes final response	3
Total	15 units

That result is surprising and worth looking at carefully, because it dismantles two oversimplified ideas.

The team made nine calls to the model against the monolith's five — almost double — and the cost still came out similar. The reason is source 1: the monolith pays for its giant context (nine tool descriptions, a 900-word system prompt, the full memory) in every one of its five iterations. The team pays large context only on the orchestrator's three calls; the specialist's six are cheap because their context is small.

That doesn't mean delegating is free. It means two more precise things:

1. In cost, the difference is usually smaller than the call count suggests, and depends mostly on how much context each level drags along. A monolith with an enormous prompt can be more expensive than a well-split team.
2. In latency, the difference really is the call count's. Nine calls in series clearly take longer than five, regardless of what each one costs. Here there's no offsetting: the team is slower, full stop.

Now let's do the math that actually decides things. Suppose — hypothesis, again — that in testing with a hundred cases the monolith answers correctly 82% of the time and the team 94%. With two thousand conversations a month:

Monolith: 18% of 2,000 = 360 conversations with some defect
Team:      6% of 2,000 = 120 conversations with some defect

Difference: 240 conversations a month resolved correctly
            instead of ending in an annoyed customer or a
            ticket someone on the team has to handle by hand.

If handling one of those conversations by hand costs more than the cost difference between the two scenarios — and in customer support it almost always does, because it involves a person's time — the delegation pays for itself. That's the complete argument, and notice it isn't "multi-agent is better": it's a comparison of two costs with a measured accuracy figure in the middle.

How to actually measure

Everything above is reasoning. This is what you do on your own instance.

1. Turn on the trace at every level. Return Intermediate Steps on the orchestrator and every specialist. Without this you can't count anything.

2. Count calls to the model per level. In the trace, each "model call" is one iteration. Note down how many the orchestrator made and how many each specialist made. That count is your latency metric, because the calls are sequential.

3. Read token usage. n8n's chat model nodes report each call's token usage in the execution's output data. Open them in the execution panel and note input and output tokens. That's where you're going to see, with your own eyes, source 1: the context growing on every iteration.

4. Read the time. The execution panel shows the complete execution's duration and each node's. Compare the total duration against the sum of the agents' durations to see where the time goes.

5. Build the sheet. With twenty or thirty representative executions you build something like this:

# Cost sheet per conversation — TuTienda, measured over N executions

                          typical    p90     worst observed
  Calls to the model         7       12          19
  Delegations                 1        2           3
  Input tokens             …        …           …
  Output tokens            …        …           …
  Duration (seconds)         …        …           …
  Estimated cost            …        …           …

The column that gets used most in practice isn't the typical case's: it's the p90, the value 90% of conversations fall below. The typical case tells you how the system feels; the p90 tells you what you're actually going to pay at the end of the month, because expensive cases weigh more than their frequency suggests.

And a method recommendation: measure before optimizing. Intuition about where the cost goes in a multi-agent system is notoriously bad — a lot of people swear the problem is the delegations and, once they measure, discover 60% of the spend is in the 900-word system prompt nobody trimmed.

The six levers

In roughly descending order of return on effort.

Lever 1 — Stagger models by level

The best effort-to-benefit ratio, and the most ignored one. The orchestrator makes a small decision: choosing between three well-described options and composing a text. It doesn't need the most capable model that exists. Specialists that make costly decisions — opening disputes, evaluating warranties — do.

triage_agent        → fast, cheap model
billing_specialist  → capable model (decisions about money)
order_specialist    → mid-tier model
sales_specialist    → fast, cheap model

And since every agent has its own Chat Model port, this gets done by connecting different model nodes. There's no technical complication: it's a decision you make or don't.

When you make it, measure again. Downgrading the orchestrator's model can degrade routing quality, and if that happens, the savings get eaten by the increase in badly delegated cases. How to verify it: run the same set of twenty cases with the expensive model and with the cheap one, and compare which specialist it delegated to in each one.

Lever 2 — Shorten the assignment

The assignment travels on every specialist iteration. A three-paragraph assignment on a specialist that takes four iterations gets paid for four times.

The rule: the assignment should carry the data, not the story.

# Expensive assignment (and worse)
"The customer wrote that they're very upset because a charge showed
up that they don't recognize, they say they checked their card and
found a $1,200 charge from last month, mentioned they bought
headphones a while back but that charge doesn't match anything, and
also asked earlier about an order but we already resolved that, so
now they need us to check this specific charge because…"

# Cheap assignment (and better)
"Customer C-9931. $1,200 charge on 07/18 not recognized. The customer
rules out that it matches their headphones purchase. Verify and, if
it doesn't match any purchase, open a dispute."

The second one has every piece of data the specialist needs and none of the narrative it doesn't use. And there's an additional benefit that isn't about cost: the specialist gets distracted less. The long story introduces irrelevant information competing for attention — the same dilution phenomenon from lesson 2, now inside the assignment.

This gets implemented in the $fromAI("task", ...)'s description: explicitly ask it for a brief, data-only assignment, no narrative.

Lever 3 — Lower Max Iterations

You already worked this in lesson 6 as a stopping condition. Here it's a cost lever, and a good one, because the iterations you eliminate are the biggest-context ones.

Calibrate it with the observed-maximum-plus-two rule, per level. If a specialist never went past three iterations in thirty executions, having it at 10 doesn't give it flexibility: it gives it room to get stuck expensively.

Lever 4 — Replace an agent with a deterministic sub-workflow

The biggest lever when it applies, because it doesn't reduce the cost: it eliminates it.

Ask yourself, for every specialist: is this agent making any decision that requires interpreting language or choosing between paths? If the answer is no — if what it does is check something, apply a fixed rule, and return a result — that's not an agent. It's a sub-workflow, and you already know how to build one from Module 4's lesson 6.

Concrete example: a "return eligibility specialist" that checks the purchase date, looks at the category, and applies a deadline. Zero interpretation, zero choice. As an agent it costs between two and four calls to the model every time it's used. As a sub-workflow it costs zero, it's deterministic, and it can be tested with fixed data.

This isn't shrinking the system: it's giving each piece the mechanism that fits it. A mature multi-agent system usually ends up with fewer agents than it started with and more sub-workflows.

Lever 5 — Collapse a specialist that isn't earning what it costs

The uncomfortable lever. If a specialist gets called very rarely, or if when it does get called its decisions are trivial, maybe it shouldn't exist as a separate agent.

The measurement: count how many times each specialist got called across a hundred conversations, and for each call, how many iterations it used. A specialist called three times out of a hundred that always resolves in one iteration with a single tool isn't contributing judgment — its tools could live in another specialist with a couple more lines of prompt, and the system would have one less level of indirection.

It's uncomfortable because it means undoing something you built. It's worth doing anyway: lesson 2 said a cut gets justified with evidence, and that rule cuts both ways.

Lever 6 — Teach the orchestrator not to delegate

Many conversations don't need any specialist. "Hi," "thanks," "what time are you open?", "ok great." If the orchestrator delegates in those cases, you're paying for a full delegation for a greeting.

# Fragment of triage_agent's System Message

  Don't delegate when:
  - The message is a greeting, a thank-you, or a confirmation
    ("ok", "got it", "thanks").
  - The question is about hours, location, or contact channels:
    answer it yourself directly with the information you already have.
  - You need a piece of data from the customer before you can build a
    useful assignment: ask for it first, delegate after.

  Only delegate when the case requires checking a system or applying
  a specific domain's business rule.

That last line in the block — asking before delegating — is especially profitable. Delegating an incomplete assignment almost always ends in pending_info, meaning: you paid for a full delegation just to be told a piece of data is missing that the orchestrator already knew was missing.

The decision rule

With everything above, the question "is it worth delegating here?" can be answered with a criterion instead of a preference:

Delegating is justified when the reduction in errors, measured on real cases, is worth more than the increase in cost and latency, measured on the same cases.

Three situations where the criterion clearly leans toward not delegating:

• Volume is high and cases are homogeneous. Ten thousand conversations a month of the same type. There, every unit of cost multiplies by ten thousand, and the accuracy gain on cases that were already easy is small.
• There's a hard latency constraint. A voice agent on the phone. Every delegation adds a full round trip; if your budget is a couple of seconds, delegation doesn't fit.
• The specialist makes no decisions. Lever 4: that's a sub-workflow.

And three where it leans toward yes delegate:

• The cost of an error is high. Money, deleted data, a legal commitment in front of a customer. There accuracy is worth much more than the cost difference.
• Domains have rules that contaminate each other. When a single prompt produces lesson 2's mode 3 and no amount of instructions fixes it.
• Blast radius matters. When you want an agent to be physically unable to execute certain actions, not just forbidden from doing so in writing.

Common mistakes

Measuring only the orchestrator (practical). What happens: someone looks at the orchestrator's model node's token usage, sees a reasonable number, and concludes the system is cheap. The specialists have their own model nodes, with their own consumption, which doesn't show up there. Why it happens: in the execution panel the orchestrator is the main node and it's where you look first. How to spot it: add up the tokens across every model node in the execution, not just the first one; if your total doesn't include a line for every specialist that got called, it's incomplete. How to fix it: the unit of measurement is the complete conversation, at every level — build the cost sheet by adding up every model node that participated.

Optimizing by intuition without measuring first (practical). What happens: someone is convinced the cost is in the delegations, spends a day collapsing specialists, and the cost drops 8% — because 60% of it was in a long system prompt that was getting resent on every iteration of every agent. Why it happens: delegations are the most visible part of the system and the newest, so the attention goes there. How to spot it: before touching anything, look at the input token usage of each agent's first iteration; that number is your per-call startup cost, and if it's big, that's where your problem is. How to fix it: measure first, and attack the biggest source — often it's shortening prompts and descriptions, which is easier and less risky than redesigning the architecture.

Confusing "fewer calls" with "cheaper" (conceptual). What happens: someone collapses two specialists into one to reduce calls to the model, and the cost goes up — because the merged specialist now has six tools and a prompt twice as long, resent on every one of its iterations. Why it happens: counting calls is easy and counting tokens is more work, so the easy metric gets used as if it were the right one. How to spot it: this lesson's worked example's scenarios A and B — nine calls cost the same as five. How to fix it: for cost, measure tokens; for latency, count calls. They're two different metrics answering two different questions, and optimizing one can make the other worse.

Downgrading every agent's model at the same time (practical). What happens: someone applies lever 1 by changing all five models in the same session, cost drops considerably, and quality does too — but since five things changed together, there's no way to know which one broke it. Why it happens: it's faster and feels efficient. How to spot it: if after a batch of changes quality dropped and you can't attribute it to a single one, this already happened to you. How to fix it: change one model, run your test case set, compare, and only then change the next one — it's slower and it's the only way to know what worked.

Presenting the cost without the accuracy figure next to it (conceptual). What happens: someone brings the number "the multi-agent system costs 2.3 times more than the previous one" to a meeting and the conversation ends there, with a decision to roll back. Why it happens: cost is a hard number and accuracy requires having measured it, so it's easy to bring only half the story. How to spot it: if your report has a cost figure and no accuracy rate, it's incomplete by design. How to fix it: measure both things on the same set of cases and present them together — "2.3 times the cost, and 12 points more accuracy, which is 240 conversations a month that no longer reach a human" is a sentence that can be argued about; half a sentence can't.

Exercises

Exercise 1 — Find where the cost is going. A team measures their system and finds this (hypothetical numbers, in input tokens per call):

triage_agent:        iteration 1: 4,200   iteration 2: 5,100   iteration 3: 6,000
billing_specialist:  iteration 1: 1,100   iteration 2: 1,400
order_specialist:    iteration 1: 3,900   iteration 2: 4,100

Where's the most obvious problem and which lever would you apply first?

See solution

The obvious problem is order_specialist: it starts at 3,900 input tokens on its first iteration, when billing_specialist starts at 1,100. Both are specialists, neither has memory connected, and both receive an assignment. A nearly fourfold difference at the starting point can only come from two places: a much longer system prompt, or much longer tool descriptions — or a disproportionate assignment.

The first move is opening both nodes and comparing. If order_specialist's system prompt is 800 words against billing's 140, that's 100% of the problem right there, and the fix is trimming it (it's probably dragging along rules from domains that aren't its own anymore). If the prompts are similar, look at the assignment: apply lever 2.

What you would not do first: touch the architecture. triage_agent growing from 4,200 to 6,000 between iterations is normal and expected — it has memory connected and it's accumulating the delegations' results; it's source 1 working as it should, not a defect.

Why it works: comparing two equivalent pieces' starting point is the fastest way to find an anomaly. When two things that should look alike don't, that's where the problem is, and it almost never takes calculating anything else.

Exercise 2 — Decide whether the specialist stays. Across a hundred measured conversations, sales_specialist got called 4 times. In all four it used a single iteration and called recommend_products once. Its system prompt is 120 words. Do you collapse it or keep it? What additional data would change your mind?

See solution

With that data, the evidence points toward collapsing it. Four calls out of a hundred is little traffic; one iteration with a single tool means it's not making any interesting decision — it receives an assignment, calls the tool, returns; and a 120-word prompt fits without a problem as an extra paragraph in another specialist, or its two tools could even hang directly off the orchestrator if the decision to use them is trivial. You're paying a level of indirection for something that contributes no judgment.

Two pieces of data that would change the decision:

The first, about risk: if the product recommendation has a rule you don't want mixed with another domain — for example, lesson 2's role contamination, where the agent ends up selling to a customer in a dispute — then the separation is justified by architecture, not cost, and the cost of keeping it is extremely low (four calls out of a hundred). Then it stays.

The second, about the future: if TuTienda's team is about to launch a campaign where sales traffic goes from 4% to 40%, collapsing it today only to have to separate it again in two months is wasted work. Past usage evidence doesn't always predict future usage, and it's worth asking before undoing something.

Why it works: lever 5 gets applied with data, but usage data isn't the only criterion. A specialist can be justified by what it prevents from happening, not just by what it resolves — and that benefit doesn't show up in a call count.

Exercise 3 — Build the argument. You have to justify to whoever pays the bill why the new system costs more than the old one. You have this measured data (hypothetical): the old system cost 1.0 units per conversation with 79% accuracy; the new one costs 2.1 units with 93% accuracy. Volume is 3,000 conversations a month, and every conversation the system doesn't resolve well costs the team about 8 minutes of a person's time. Write the argument in three or four sentences.

See solution

One possible argument:

"The new system costs 2.1 times more per conversation, so across 3,000 conversations a month the model spend rises by about 3,300 units. In exchange, the accuracy rate went from 79% to 93%: that's 420 conversations a month that used to end up with the team and now resolve on their own. At 8 minutes each, that's about 56 hours of work a month freed up. We'd need to check both numbers against next month's close to confirm, but with this measurement the team's time savings comfortably outweigh the increase in model cost."

Three things that make that argument work. First: it puts both figures together, cost and accuracy, instead of defending one and hiding the other. Second: it translates accuracy into the unit that matters to whoever decides — team hours — not percentage points. Third: it's presented as a measurement to be confirmed, not a closed truth, which is the honest way when you're working from a sample.

And one thing it avoids: promising net savings in dollars without knowing the team's cost per hour. If you don't have that data, the right sentence is "56 hours a month freed up," not a dollar figure you'd have to make up.

Why it works: the conversation about an AI system's cost gets won with the complete comparison, not with the most favorable number. And bringing the accuracy figure measured, not estimated, is what makes the comparison hold up when someone asks where it came from.

Summary and next step

You now have the calculator. A multi-agent system's cost comes from four sources: every iteration resends the whole context, the orchestrator drags along the full conversation, the self-contained assignment travels on every specialist round, and the intermediate summary gets paid for even if the customer never reads it. Iterations multiply, they don't add. Latency, on the other hand, is simply the sum of the calls in series, and there's no offsetting there: delegating is slower. It gets measured with Return Intermediate Steps, each model node's token usage, and the execution panel's timings, and it summarizes into a per-conversation sheet with its p90 column. And there are six levers: staggering models, shortening the assignment, lowering Max Iterations, replacing an agent with a deterministic sub-workflow, collapsing a specialist that isn't earning what it costs, and teaching the orchestrator not to delegate when it isn't needed.

Before moving on you should be able to: explain why nine calls to the model can cost the same as five; build a per-conversation cost sheet with data from your own execution panel; name the six levers and which one you'd attack first based on what the measurement shows; and present the cost alongside the accuracy figure, translated into the unit that matters to whoever decides.

With this you have the complete module: the diagnosis (lesson 2), the architecture (3), the wiring (4), the contract (5), the brakes (6), and the economics (7). What's left is putting it all together and verifying it works. Lesson 8 is the mini-project: a triage system with two or three specialists, built start to finish, with its handoffs verified, its stopping conditions tested against adversarial cases, and its cost sheet measured — the deliverable you can show and defend.

Resources

• View past executions — n8n Docs — the panel where you read per-node durations and open each model call's output data; the source for every number in this lesson.
• AI Agent node — n8n Docs — Max Iterations and Return Intermediate Steps, lever 3 and the measurement instrument.
• Cluster nodes — n8n Docs — the catalog of chat model sub-nodes, for picking different models per level (lever 1).
• Call n8n Workflow Tool — n8n Docs — the mechanism lever 4 gets executed with: replacing an agent with a deterministic sub-workflow.
• Building Effective AI Agents — Anthropic — this lesson's underlying argument: agentic complexity is only justified when it improves a measurable outcome, and it's worth starting with the simplest solution.