Agentic Workflows with n8n

What n8n is — and when to reach for it essential

Here's a scene you'll recognize the moment you work with a team. Someone asks for a small automation: "when a customer emails support, classify it and drop billing tickets into Slack." You could write a Python service — an API key in an env var, a webhook handler, a deploy, a place to run it, logs when it breaks. Three days later it works, and then the person who actually owns support wants to tweak the wording of the Slack message and can't, because it's code they can't read, on a server they can't touch. The automation becomes your permanent chore. That mismatch — a five-minute idea trapped behind an engineer — is the exact gap n8n was built to close.

The mental model is simplest if you picture a factory conveyor belt. A part drops on at one end (the trigger), moves past a line of stations that each do one small thing to it (the nodes), and comes off the end finished. You don't write the belt; you arrange the stations and draw the wires between them. That visual arrangement is the program — which is why a non-engineer can look at the canvas, see "email → classify → route to Slack," and change the last station without breaking the first. The workflow is legible because it's a picture, not a wall of syntax.

Now the precise definition, which will land because you have the picture: n8n is a workflow-automation platform where an automation is a directed graph of nodes, and you build it by dragging boxes onto a canvas and connecting them instead of writing code. Two properties make it worth a chapter of its own. First, it's self-hostable — you can run the whole thing on your own machine or server (the Docker lab below does exactly that), so your credentials and data never leave infrastructure you control. Second, it's fair-code, not "no-code-only": when the visual nodes run out, you can drop into a Code node and write real JavaScript or Python, so you never hit a hard ceiling. That combination is why it sits between click-only tools and hand-written services rather than competing head-on with either.

The common mistake is treating this as "the easy version for people who can't code." It isn't — the value is speed and ownership, not avoidance. A senior engineer reaches for n8n precisely because gluing five SaaS apps together with retries, a scheduler, and a shareable canvas is faster here than in Python, and hands it to a team that can maintain it. The skill this chapter teaches is knowing which side of the line a given problem falls on — and the table just below is your first cut at that judgement.

n8n ("nodemation") is a fair-code, self-hostable workflow-automation platform. You build automations by placing nodes on a canvas and connecting them; each node does one thing (fire on a schedule, call an API, run an LLM, branch on a condition) and passes data to the next. It sits between "click-only" tools like Zapier (N2) and writing everything in code: more power and control than the former, far less boilerplate than the latter.

The building blocks essential

Before you build anything, you have to be able to name the parts — and the good news is there are only five, and you already met their ideas in the agent chapters. The reason to learn the vocabulary first is practical: when a workflow misbehaves, the fix is almost always "the wrong kind of block, or a block wired to the wrong upstream data." If you can't tell a trigger from a node from a connection, you can't debug it. So spend two minutes here and the rest of the chapter reads itself.

Think of the whole thing as a sentence with grammar. The trigger is the subject that starts everything ("when an email arrives…"); the nodes are the verbs, each doing one action ("…classify it, then post it"); the connections are the word order that says which verb runs next; and the items flowing along the connections are the thing being acted on, carried forward station to station. A workflow reads left to right like a sentence, and every valid workflow has exactly one subject — one active trigger — because something has to decide when the sentence gets spoken.

Here is the one detail that trips up every beginner, so internalize it now: data does not flow as a single value — it flows as a list of items. Each item is a small bundle of JSON like { "message": "I was charged twice" }, and n8n runs each node once per item automatically. That's why a workflow that classifies one email works unchanged on a batch of fifty — the node body describes what to do to one item, and n8n loops for you. Beginners who assume "one run = one value" get baffled the first time a node emits three items and the next node runs three times; once you know items are a list, that behaviour is obvious instead of spooky.

The remaining two blocks are the plumbing that makes the sentence real. An expression — the {{ $json.field }} syntax — is how one node reaches back and reads a field a previous node produced, so stations can pass specifics forward, not just vague data. A credential is a stored, encrypted secret (an API key, an OAuth token) that a node references by name rather than containing — a separation that matters enormously the day you export or share a workflow, because the secret stays behind. Keep these five names in view as you read the diagram and table below; everything else in n8n is just which node you drop into this same skeleton.

Lab N1.1 · Get n8n running essential

The fastest way to lose an afternoon with a new tool is the install. You find three tutorials, one wants a global npm package, another a cloud signup, a third a from-source build, and each leaves a slightly different mess on your machine. n8n sidesteps all of that with a single Docker command — and it's worth understanding why that command is the recommended path, not just copy-pasting it, because the reasoning is the same one that makes n8n worth self-hosting in the first place.

Here's the key idea in plain terms: self-hosting means the software runs on infrastructure you own, so your secrets and data stay with you. An n8n workflow holds live API keys and can read your email, write to your CRM, and post to your Slack. When you run it yourself, none of that ever passes through someone else's server. The trade is that you become the operator — you're responsible for keeping it running, patched, and locked down (which is exactly what the danger callout below hammers home). n8n Cloud exists for people who'd rather pay to skip that responsibility; the Docker path below is for people who want the control.

The lab uses Docker because a container is a pre-packaged, isolated copy of an app plus everything it needs to run, so "install n8n" collapses into "download and run this one image" — no version conflicts with whatever else is on your machine. The one subtlety that beginners miss, and that the walkthrough spells out, is the split between the container (disposable — the --rm flag throws it away when you stop it) and the volume (persistent — the -v n8n_data flag is a named box on your disk where your workflows and credentials actually live). Get that distinction and you'll never panic when the container disappears; forget it and you'll think you lost all your work on the first restart. Follow the three steps in order: run the container, add your Anthropic credential once so every later node can reference it by name, and drop a Manual Trigger so you can click-to-run while you build.

Lab N1.2 · An LLM in a workflow intermediate

Everyone's first instinct with an LLM node is to type a prompt straight into it and hit run — and it works, once. Then you realize the whole point of a workflow is that the input isn't fixed: a real email, a form submission, a Slack message arrives, and the model has to see that text, not the sentence you hardcoded while testing. The moment you feel that gap — "how does the incoming data actually reach the prompt?" — you've hit the one concept that makes n8n's LLM nodes different from pasting into a chat window. This lab exists to make that wiring concrete on the smallest possible example: a one-node classifier.

The bridge is the expression, and the cleanest way to understand it is as a mail-merge slot. When you write a form letter, you don't retype the name for every recipient — you write "Dear {{first_name}}," and the system fills the slot from each record. n8n's {{ $json.message }} is exactly that: a slot in your prompt that n8n replaces, just before sending, with the message field of the item flowing in. So the prompt template stays fixed while the data behind it changes on every run. $json means "the item arriving at this node" and .message reaches into its named field — the visual, canvas-side twin of writing item["message"] in Python.

Two working habits in this lab are worth naming because they're the same discipline you learned coding, just relocated to the canvas. Pinning sample data on the trigger freezes one known input ({"message": "I was charged twice!"}) so you can re-run the workflow repeatedly and get a comparable result each time — it's a fixed test case, the visual version of the classifier tests from Chapter 2, and it's how you tune a prompt without a live event firing every time. And clicking a node to inspect its exact JSON in and out is n8n's genuinely killer feature: instead of guessing why a downstream step misbehaves, you see the precise data that entered and left every station. That per-node visibility is the thing seasoned n8n users lean on hardest; get in the habit early. Now build the two-node chain in the lab and watch a support message turn into a single clean label.

Start simple: a workflow that classifies an incoming message. This is the visual twin of Chapter 2's classifier.

Lab N1.3 · From workflow to AI Agent intermediate

You'll hit the wall the moment you ask your classifier a question it can't answer from the prompt alone. "What's today's EUR/USD rate?" A plain Chat Model node will happily invent a number — confidently, plausibly, wrongly — because all it can do is answer from what it already knows. The fix isn't a better prompt; it's a fundamentally different node that can go get the rate before answering. That leap — from a model that talks to a model that acts — is the single most important idea in this chapter, and in n8n it's a one-box upgrade: swap the Chat Model node for an AI Agent node.

If you built the agent in Chapter 4 by hand, you already know the machine hiding inside that box; if you didn't, here's the whole thing in one loop. An agent runs a cycle: reason about the goal, decide it needs a tool, call the tool, observe the result, then reason again — repeating until the task is done. In code (C2) you wrote that while loop yourself: send the messages, check whether the model asked for a tool, run it, append the result, resend. The AI Agent node is that loop, packaged. You no longer write the round-trips; you supply the three ingredients and the node runs the cycle internally. That's the exact same mental model you already own, with the plumbing hidden — which is why "if you understand Chapter 4, you understand this node" is not a slogan but a literal fact.

The three ingredients you attach are worth understanding as roles, because getting one wrong is the usual reason a canvas agent underperforms. The Chat Model is the brain — the actual Claude model doing the reasoning and choosing what to do next. Memory (the Window Buffer Memory node) is the notebook — it carries the conversation across turns, so a chat agent remembers what was said three messages ago instead of starting cold each time; it's the same messages list you appended to and resent by hand. And tools are the toolbox — sub-nodes the agent may call, each with a description that the model reads to decide when to reach for it. That last point is the one beginners underestimate: the agent selects tools purely from their descriptions, so a vague description ("does stuff with orders") makes it pick wrong, while a sharp one ("look up an order's status by its numeric id") makes it pick right. Read the diagram as manager-plus-resources, then build the agent in the lab and — crucially — ask it something that forces a tool call, so you can watch the loop actually fire.

A single LLM node answers. The AI Agent node acts — it runs the tool-use loop for you: given tools and a goal, it decides which tools to call, calls them, reads results, and loops until done. This is Chapter 4's agent, as one node.

The canvas ↔ code Rosetta Stone intermediate

There's a quiet anxiety that creeps in when you switch tools: the fear that you're learning something disposable. "If I get good at dragging n8n boxes, does any of it transfer the day I have to write the real thing in Python?" This section exists to kill that fear outright, because the honest answer is: a visual workflow is a program, and every box maps to a line of code you already know how to write. The canvas isn't a different world — it's the same computation wearing a different coat. Seeing the correspondence directly is what turns n8n from a black box into a tool you trust.

The table below is a literal dictionary between the two. A trigger node is your script's entry point — the event or handler that starts main(). A Chat Model node is one client.messages.create(...) call. A tool sub-node with a description is one entry in the tools=[...] array you pass to the API. The whole AI Agent node is the while tool-use loop you hand-wrote in C2. A Memory node is the messages list you keep appending to and resending. An expression {{ $json.x }} is just reading a field off the previous step's result. And a credential is a key loaded from an environment variable or secrets manager. Nothing on the left has no equivalent on the right; that's the point.

Read this two ways, because it pays off in both directions. Left-to-right, it lets you prototype on the canvas and know exactly what you'd write if you later needed the control of code — the visual version is a runnable spec. Right-to-left, it lets an experienced coder read any n8n workflow at a glance, because they can silently translate each box into the code they'd have written. That fluency — moving between canvas and code without friction — is precisely the FDE judgement this whole no-code module is building toward: knowing not just how to build each way, but which way a given problem deserves. Exercises 4 through 6 make you exercise that translation until it's automatic.

Common pitfalls advanced

The dangerous thing about a tool that ships a working demo in ten minutes is that it makes the hard parts feel optional. They aren't — they're just deferred. Every failure in the table below is one that doesn't show up on your laptop and only surfaces when the workflow meets real traffic, real secrets, or a public URL. The pattern worth internalizing is that "no-code" removed the boilerplate, not the responsibilities: your n8n instance still holds live API keys and still takes real actions in real systems, so it inherits every operational concern a hand-written service would have.

Read the pitfalls as three families. The first is secrets handling: pasting an API key into a node field bakes it into the workflow, so it leaks the instant you export, share, or version that workflow — which is the entire reason credentials exist as a separate, encrypted, reference-by-name mechanism. The second is exposure: an editor or webhook reachable from the open internet with no auth is a standing invitation, since anyone who finds the URL can drive your workflows and the credentials behind them; the fix is auth, HTTPS, and restricted webhook paths, exactly as you'd protect any secret-holding service. The third is trusting the model too much: routing a branch on free-text LLM output breaks the day the model phrases the label differently, and a vague tool description makes an agent pick the wrong tool — both fixed by forcing structure (a typed field, a sharp description) so downstream logic reads data, not prose.

The last row is the philosophy that ties them together, and it's the one to carry out of this chapter: "no-code" is not "no-ops." The workflow needs error handling on flaky nodes (retries plus an error branch), monitoring so you notice when it silently stops, and the same security posture you'd give a production API. Treating a canvas as somehow exempt from operations is how a convenient internal automation quietly becomes an unmonitored liability holding live credentials. Skim the fixes below now; you'll apply every one of them in the reliability and industry exercises on the practice ladder.

Exercises advanced

[ Webhook Trigger ]  --items-->  [ OpenAI / LLM node ]  --items-->  [ Slack node ]
      trigger                        action (transform)              action (output)

trigger      Webhook        starts the run, emits 1 item with the request body
node (LLM)   LLM Chat       reads item.json.text, writes item.json.reply
node (out)   Slack          posts item.json.reply to a channel
connection   the wires      pass ITEMS (an array of {json: {...}}) downstream

{
  "node": "OpenAI Chat Model",
  "parameters": {
    "system": "You are a support triage assistant. Reply in one sentence.",
    "prompt": "={{ $json.subject }}\n\n{{ $json.body }}",
    "temperature": 0.2
  }
}

                    +-- [ Tool: HTTP "get_order" ] (GET /orders/{id})
[ Chat Trigger ] -- [ AI Agent ] --+
       |                +-- [ Tool: Calculator ]
       |            (model: Chat Model node)
       +-- memory: [ Window Buffer Memory ]

{
  "tool": "get_order",
  "description": "Look up an order by its id. Input: {\"id\": \"string\"}",
  "method": "GET",
  "url": "https://api.example.com/orders/{{ $fromAI('id') }}"
}

canvas concept        code equivalent
-------------------   ---------------------------------
trigger               the event/handler that starts main()
node                  a function step
connection            passing the return value onward
item ({json:{...}})   a dict in a list
Set node              building/renaming dict fields
IF node               an if/branch
Loop / Split In Batches   a for-loop over items

// n8n Code node -- runs once, returns the new items array
return items.map(item => ({
  json: {
    fullName: item.json.first + " " + item.json.last,
    email: item.json.email.toLowerCase()
  }
}));

node settings (HTTP / LLM node):
  Retry On Fail:     true
  Max Tries:         3
  Wait Between:      2000 ms (exponential-ish)
  On Error:          "Continue (error output)"  -> wire error output to a branch

error branch:
  [ node error output ] --> [ Slack: alert #ops ] --> [ Set: mark row failed ]

seen = set()
def process(item):
    key = f"{item['source']}:{item['id']}"     # stable per-event key
    if key in seen:
        return "skip (duplicate)"
    seen.add(key)
    return "process"

evts = [{"source":"webhook","id":"A"}, {"source":"webhook","id":"A"},
        {"source":"webhook","id":"B"}]
print([process(e) for e in evts])   # ['process', 'skip (duplicate)', 'process']

[ IMAP Email Trigger ]
      |
[ AI Agent: classify {category, urgency, needs_human} ]
      |
[ Switch on {{ $json.category }} ]
   |-- billing  --> [ HTTP: create billing ticket ] --> [ Reply: template ]
   |-- howto    --> [ LLM: draft answer ] --> [ IF urgency=high? ] --> reply / queue
   |-- bug      --> [ Jira: create issue ] --> [ Reply: ack ]
   |-- default  --> [ Slack #support: escalate to human ]
      |
[ Append row to Google Sheet: audit log (id, category, action, ts) ]

def route(cls):
    table = {"billing": "auto-ticket + templated reply",
             "howto":   "LLM draft, human review if urgent",
             "bug":     "file Jira + ack"}
    return table.get(cls["category"], "escalate to human")

print(route({"category": "billing"}))
print(route({"category": "unknown"}))   # -> escalate

Knowledge check check yourself