Multi-Agent Orchestration in n8n: Agent Teams for Small and Mid-Sized Business

The agent has been running for three months and every week it gets a little worse. At the start it wrote quotes from bullet points, and that was decent. Then prices from the ERP came in, then delivery times, then customer history, then approval by email. Today 34 tools hang off a single agent, the prompt has grown to 4,000 tokens, and the hit rate feels like two out of three attempts. Cost per run rose 180 percent over the same period. The agent is not broken. It is overloaded.

That pattern is not a one-off, it is the typical curve of every ambitious automation project: everything that somehow belongs in the thing gets stuffed into the same agent, because that is faster at the beginning. At some point the whole setup tips over, and not quietly, but with wrong numbers inside real quotes.

In this article you will learn why the all-in-one agent is bound to fail, how a coordinator with three specialists is structured, how to wire that up in n8n, what it saves on cost, and how to get from one overloaded agent to a small agent team in five days.

---

Table of contents

1. Why the all-in-one agent fails
2. The pattern: one coordinator, several specialists
3. In practice: wiring three agents into n8n
4. Cost, models and metrics
5. An agent team in five days
6. Conclusion

---

Why the all-in-one agent fails

German SMEs are past the testing phase. The KI-Index Mittelstand 2026, compiled by Salesforce together with the German Association of Small and Medium-Sized Businesses (DMB), arrives at 51.2 percent of surveyed companies that use or test AI, a gain of 54 percent over the previous year. The more interesting figure sits right next to it: 16.6 percent already deploy AI agents, up from 8.7 percent the year before. And fewer than five percent of companies have shut an AI project down again. So the technology has arrived. The sobering part happens elsewhere.

It happens where a pilot turns into day to day operations. A study by T-Systems, published in September 2026, points the way: 91 percent of the front runners examined use knowledge assistants, 83 percent automated document creation. Those are tightly scoped tasks with clear inputs and verifiable outputs. Sven Giesselbach, CTO AI and Data at T-Systems International, nails the standard: what counts is not what is technically possible, but the concrete benefit at a manageable level of risk. An overloaded agent is the opposite of that, because its risk grows with every capability while the benefit does not grow at the same pace.

On the technical side there are three causes, and they always show up together.

Tool selection turns into guesswork. An agent with 34 tools has to decide on every request which one fits. Every additional option raises the probability of a wrong choice, and the errors pile up, because a tool chosen wrongly once shapes everything that follows.

Context turns into a dumping ground. When ERP data, customer history, price lists and writing instructions sit in the same prompt, they compete for the same attention. Important rules such as “no discounts below 12 percent without approval” get lost somewhere between delivery times and tone of voice guidance. That is not a model failure, it is the consequence of nobody being able to say which piece of information actually matters in a given situation.

Every change affects everything. If you want the quote wording handled differently, you change the prompt, and suddenly the agent calculates differently too. That coupling is the real cost driver in operations, because every small adjustment becomes a full regression test across all capabilities.

Then there is the cost lever. An all-in-one agent almost always runs on the largest model available, because it has to be equipped for the hardest of its tasks. Nobody gets compensated for the fact that 80 percent of its calls are trivial classifications.

The pattern: one coordinator, several specialists

The counter architecture is called orchestration, and it is not new, just rarely implemented cleanly. Instead of one agent with many tools, you get one agent with a few tools, each of which is another agent.

The coordinator has exactly one job: understand the request and hand it to the right specialist. It has three to five tools, each of them a complete sub-workflow. It does not research, it does not calculate, it does not write copy. Its output is a decision, not content.

The specialists each have one task, a small prompt and only the tools they need for it. The research agent reads email attachments and master data. The costing agent calculates with a fixed formula and reads the price list. The writing agent drafts from a structured brief. None of them knows the prompt of the others.

Between the agents sits a handoff in a fixed format. This is where most implementations fail: they let the agents talk to each other in free text. A coordinator that writes “send this over to costing” has gained nothing, because the recipient has to interpret it all over again. The handoff has to be an object with fixed fields, validated before the next agent starts.

And you need a return path with an abort condition. Every specialist can say “I can’t do this”, for instance when a required field is missing. That message goes back to the coordinator, which then either asks for clarification or hands over to a human. Without that return path you get the worst possible state: an agent that invents a missing piece of information just to finish the task.

The effect is not only quality, it is traceability. If a quote turns out wrong tomorrow, you can read the chain: what did the coordinator recognise, what did the research agent deliver, what did the costing agent calculate, what did the writing agent draft. With a monolith you have one prompt and one result. How to draw approvals and boundaries cleanly in a chain like this is covered in detail in Granting AI agents the right permissions.

In practice: wiring three agents into n8n

The example is deliberately mundane: a quote generated from a customer enquiry. Until now one all-in-one agent handles it, now three specialists take over.

The setup in n8n. The main workflow holds the AI Agent node with agent type “Tools Agent” and the smallest model that can classify reliably. Three “Call n8n Workflow Tool” nodes hang off it as tools, pointing at three separate workflows: agent_research, agent_costing, agent_writing. Each of those workflows is its own testable unit with its own prompt, its own credentials and its own error handling.

The handoff as a contract. The coordinator does not return a prose object, it returns a structured one. In n8n you do that with the Structured Output Parser and a JSON schema, or with a Code node that validates the output and aborts on a mismatch. The Code node is the more robust route, because it documents the check itself:

// Code node "Validate handoff"
const d = $json;

const pflicht = ['kunde', 'leistung', 'menge', 'quelle'];
const fehlend = pflicht.filter(f => d[f] === undefined || d[f] === null || d[f] === '');

if (fehlend.length > 0) {
  return [{ json: {
    status: 'rueckfrage',
    fehlende_felder: fehlend,
    grund: 'Anfrage unvollstaendig, keine Kalkulation gestartet'
  }}];
}

if (typeof d.menge !== 'number' || d.menge <= 0) {
  return [{ json: {
    status: 'rueckfrage',
    fehlende_felder: ['menge'],
    grund: 'Menge ist keine positive Zahl'
  }}];
}

return [{ json: {
  status: 'ok',
  auftrag: {
    kunde: d.kunde,
    leistung: d.leistung,
    menge: d.menge,
    quelle: d.quelle,
    eingegangen: d.eingegangen ?? new Date().toISOString()
  }
}}];

The IF node that follows checks status. If it is rueckfrage, the run moves into a branch that emails sales and stops, without anything being calculated. If it is ok, the costing workflow starts. In practice those three lines save you more grief than any prompt improvement, because they catch the most common failure mode: an enquiry that arrives in proper form and is unusable in substance.

The costing agent does not calculate with the model. That is the most important part, and the one that gets done wrong most often. Prices, discount tiers and contribution margins belong in a Code node or a formula, not in a prompt. The model decides which line item from the price list fits and passes on the line item ID. The arithmetic is JavaScript. The same input therefore always produces the same price, and you can verify any amount without asking a model.

The writing agent only receives the finished brief. It sees customer, service, quantity, price and a tone of voice note. It does not see the price list and it does not see the costing rules. That means it cannot change prices even if it wanted to. This is why the chain stays stable: every agent has only the information it needs for its own task.

Approval stays with a human. The writing agent delivers a draft that lands in a pipeline. Sending happens after approval. How to handle the errors nobody notices is covered in Production operations: recognising silent failures.

Practical tip: build the coordinator with a single tool first and test it for two weeks with real enquiries. Once the routing is right, meaning the correct specialist is called in at least nine out of ten cases, add the rest. Anyone who starts with three specialists at once cannot tell whether the coordinator or a specialist is the cause when problems show up.

Cost, models and metrics

Orchestration is also a cost argument, and a clear one. A calculation from the n8n community, published in June 2026, compares a monolith on the large model with a coordinator that routes classification and simple steps to a small model: 26.40 US dollars per 1,000 runs become 8.80 US dollars. That is a directional figure from somebody else’s setup, not our own measurement, and the numbers shift with pricing and prompt length. The direction holds anyway, because the mechanism is obvious: with a monolith every call runs on the expensive model, with a chain only the calls that need it.

Three rules are enough to keep cost under control.

The smallest model at the front. Classification, meaning “what is this about”, is the cheapest task in the chain and does not need a top tier model. But it decides the largest share of the cost, because it happens on every single run.

The large model for language only. Drafting text is the task where quality differences between models become visible to customers. Everything else, calculating, checking, routing, can be solved deterministically and is therefore model independent.

Tokens per run as a metric. Note down the average tokens per run and the number of runs per week for every agent. Those two numbers are enough to see whether an agent is quietly getting more expensive. In almost every case the context grows, not the workload.

On top of that come three technical limits you have to set before the first production run. maxIterations per agent caps the loops in which an agent revises its own result until it fits. A timeout per sub-workflow stops a hung specialist from blocking the whole chain. And a fallback branch per specialist defines what happens when it fails twice in a row: a question back to the human, not a third attempt.

An agent team in five days

Day 1: Break it down. Write every task of your overloaded agent on a card: what does it actually do? Sort the cards into two piles, “understands and decides” and “executes”. The first pile becomes the coordinator, the second the specialists. In most cases three or four cards remain that are really one task together. Those go into one agent, not three.

Day 2: Build the coordinator. One agent, one model, five tools at most, each tool a sub-workflow. Validate the handoff with a Code node as shown above. Test with ten real enquiries from the inbox and note how often the right branch was chosen. Below nine out of ten: sharpen the coordinator prompt, do not touch the specialists.

Day 3: Put the first specialist into production. Pick the one with the clearest output, usually costing, because that is where calculating and checking can be separated. All numbers in code, the model only selects line items. Compare twenty results by hand against the old route. Deviations here are not rounding errors, they are errors in your decomposition.

Day 4: Connect the second and third specialist. Only now, with a working coordinator and a validated handoff. Set maxIterations, timeout and fallback branch for each specialist. An agent that does not answer has to end the chain cleanly, not leave it hanging.

Day 5: Measure instead of hoping. Fix three numbers you look at every week: routing hit rate, share of runs with human correction, tokens per run. Plus cost per completed case, not per run, because that is the number that counts in the proposal at the end. If those four values are stable for two weeks, you have an operation and not an experiment.

The part that lasts: a new specialist is an extension, not a rebuild. That is exactly where the real gain sits. You can swap the research agent for a better one without touching the writing agent, and you can add a new specialist for another task without rewriting the coordinator prompt. A monolith does not allow that, because there every change is a change to everything. Where this question leads once you have several agents and several departments is covered in AI agents for companies: what actually works in 2026.

Conclusion

The all-in-one agent is not a bad idea, it is an intermediate stage. At the beginning it is the fastest route to a result, and that is the right call. From the moment it goes into operations it becomes a problem, because capabilities, context and cost are netted out inside a single prompt, and nobody can read the bill any more.

A coordinator with three specialists solves that not because it is more modern, but because it separates the things that belong apart: deciding, calculating, writing. Every part can be checked on its own, changed on its own and switched off on its own. The price for that is extra effort at the beginning, roughly one day more than the monolith needed.

If you want to know how far your current agent is from this setup: we look at your agent landscape with you, break it down along these lines and build the chain so that it is still readable in twelve months. Our own approach is described under B.R.A.I.N. AI System, and if you need the implementation as a project, an our services is the next step.

About MadeByBrain: We build AI automation for small and mid-sized businesses, our own AI agents, n8n workflows and GEO strategies, live in production. From the first idea to productive automation.

Book a free strategy call