Chain agents together only where it pays, cap the loops, and recognise an always-on personal agent when you see one.
Module 09 ~50 min read + lab No codePrerequisites: Module 8: Building Your First Agent. Your Ops Desk assistant workflow should be working.
Once a single AI step or agent works, the temptation is to add more. Three shapes cover nearly every case, and each maps to a way of organising people that you already know.
An assembly line. Extract the fields, then classify, then draft. Each step gets the previous output. Easiest to test and log; slowest if the steps are heavy.
Fan out, then merge. Three summarisers each read one tracker at the same time, and a fourth step combines them. Faster, and each part can use a different model.
A manager agent reads the request and hands it to a specialist: scheduling, suppliers, reporting. Flexible, but the supervisor is another model call that can misroute.
| Office task | Shape | Why |
|---|---|---|
| Invoice to approved payment file | Sequential | Every invoice takes the same steps in the same order |
| Weekly report from five project trackers | Parallel | Trackers are independent; summarise them at once, then merge |
| A department chat desk that handles scheduling, suppliers and reports | Supervisor | The request type is not known until it is read |
In n8n the shapes are literal: sequential is nodes in a row, parallel is branches into a Merge node, supervisor is an AI Agent whose tools are other workflows.
The most useful two-agent pattern in office work is the writer and critic. One step drafts; a second step, with a different prompt and ideally a different model, checks the draft against a checklist and either approves it or returns specific fixes; the writer revises. It is a code review for text.
What the critic checks is whatever you would check: facts match the source, tone matches policy, nothing promised that we cannot deliver, no personal data, under the word limit. Write the checklist into the critic's prompt and make it answer in a fixed form: APPROVED or REVISE: followed by numbered points.
Two agents can disagree forever, and each round costs money. Set a hard maximum, two revisions is typical, and route to a person when the cap is reached. In n8n the cap is a counter field incremented on each pass and checked by an IF node before looping back. Module 10 treats the cap as a formal control.
A critic loop with a cap of two roughly triples the cost of a draft step. Use it where the reader is a customer, a regulator or the board; not for internal reminders.
When one agent passes work to another, the hand-off should carry three things: the task in one sentence, the facts gathered so far, and the constraints (deadline, tone, what not to do). Anything not passed is lost; the next agent does not see the previous conversation unless you send it. Passing everything is expensive and confusing; pass a summary plus the raw items that matter.
MCP (Model Context Protocol, Module 7) standardises how an agent talks to tools and data: one plug for CRMs, calendars and files. A2A (Agent-to-Agent) standardises how an agent talks to another agent, possibly from a different vendor: how it announces what it can do, how a task is handed over, and how progress and results are reported back. In short, MCP is the agent's hands; A2A is the agent's colleagues. For an administrator, both mean one thing: the supplier's agent and yours can be made to cooperate without a bespoke integration project.
Multi-agent designs are fashionable, and most of them should be one good prompt. Add a second agent only when at least one of these is true:
| Design | Model calls per item | Typical latency | Failure points |
|---|---|---|---|
| Single AI step | 1 | 2 to 5 seconds | 1 |
| Sequential, three steps | 3 | 6 to 15 seconds | 3 |
| Writer + critic, cap 2 | 3 to 5 | 10 to 30 seconds | 3, plus the loop |
| Supervisor + three specialists | 2 to 6 | 10 to 40 seconds | Misrouting, plus each specialist |
Every extra agent is another prompt to maintain, another log to read and another place for something to go wrong. Count the calls and the failure points before you draw the diagram.
Everything so far runs inside a workflow you trigger. A newer category runs all the time as a service on a server or laptop, and you talk to it on the messaging app you already use. Two open-source examples are widely used in 2026, and your instructor will demonstrate them live. This section is for recognition, not for building.
Open-source (MIT licence), a long-running service that connects to WhatsApp, Telegram, Slack and more. Its capabilities are skills: folders with a SKILL.md file describing when and how to do something, installable from a public marketplace called ClawHub. It can run tools inside a Docker sandbox, but that isolation is off by default.
From Nous Research. Built around persistent memory in three layers (working, episodic and long-term skills), so it remembers across sessions and gets more capable with use. When it works out a non-trivial procedure it saves it as a reusable skill. Reachable from twenty-plus messaging platforms through one gateway, and it runs on cloud or local models.
What to notice in the demo: the four parts are still there (model, tools, memory, instructions), but the memory is deep and personal and the tools are broad (shell, files, browser, email). That combination is powerful for one person and unsuitable for a shared department desk, which is why Module 8's memory advice was the opposite.
Both tools need a server, API keys and broad permissions, and both have had real security incidents: malicious skills in the OpenClaw marketplace that stole API keys and rewrote the agent's memory files, and sandbox escapes fixed in later releases. They are shown here so you can recognise the category and ask the right questions. Module 11 uses the OpenClaw incidents as a case study in agent security and supply-chain controls. If your organisation wants an always-on agent, that is an IT and security project, not a lab exercise.
You will extend Module 8 into a writer, critic, reviser chain for supplier emails in n8n. The writer drafts; the critic checks against a checklist and returns APPROVED or numbered fixes; the writer revises, at most twice; every pass is logged to a Sheet, and anything still not approved after two revisions goes to a person.
New workflow Supplier email with review. Add an n8n Form Trigger with fields: supplier name, purpose of email, key facts, deadline. This replaces the chat so the run is repeatable.
Add a Set node that creates a field revision with value 0 and a field feedback that is empty. The counter is your loop cap.
Add a Basic LLM Chain called Writer. Prompt:
Add a second Basic LLM Chain called Critic, ideally on a different model. Prompt:
After the critic add a Google Sheets node, Append row, into a sheet Review log with columns timestamp, supplier, revision, critic verdict, draft. This is the audit trail Module 10 will ask you for.
Add an IF node: verdict starts with APPROVED. True branch: a Gmail node, Create draft, for a person to send. False branch: a Set node that increments revision by 1 and copies the critic's points into feedback, then a second IF: revision is 2 or less. True: connect back to the Writer. False: a Slack or Gmail node that notifies a person with the last draft and the critic's points.
Submit the form three times: a simple request (should approve first pass), one with a tempting missing fact such as "ask them to confirm the payment date" with no date given (should trigger a revision), and one that is impossible to satisfy (should escalate after two revisions). Check the Review log shows every pass.
A screenshot of the loop on the canvas with the counter and both IF nodes visible, and the Review log sheet showing at least five rows across the three cases, including one escalation. Save as M9-writer-critic.
Pick one answer per question, then check your score. These mirror the style of the final exam.
Answer in your own words first, then open the model answer.
Sequential: nodes in a row (invoice extract, classify, draft). Parallel: branches into a Merge node (tracker summaries). Supervisor: an AI Agent whose tools are other workflows (department desk).
The task in one sentence, the facts gathered so far, and the constraints such as deadline, tone and prohibited actions.
Personal agents have deep, persistent memory and broad tools for one trusted user; shared assistants need per-user, short-window memory and narrow, mostly read-only tools.
Further reading: Agent-to-Agent Protocols · Model Context Protocol · LangGraph: agents as graphs · OpenManus multi-agent architecture
