What Is n8n? Visual AI Workflow Automation

// In plain English

n8n (pronounced "n-eight-n," short for nodenation) is a tool for building automations by dragging boxes onto a canvas and wiring them together with lines. Each box is a node — a single step like "when a new email arrives," "look up this customer in the database," or "ask an LLM to summarize this text." You connect the nodes in the order you want them to run, and n8n executes them one after another, passing data down the chain.

Think of it as a visual assembly line for data. Instead of writing a script that calls five APIs in sequence, you place five nodes side by side and draw arrows between them. The first node fires (a trigger), its output flows into the second, the second's output flows into the third, and so on until the last node finishes. You can see the whole flow at a glance, which is the entire point of node-based automation: the diagram is the program.

What makes n8n interesting for AI builders is that some of those boxes are now AI nodes and agent nodes. One node can call a large language model, another can act as a small AI agent that picks tools on its own. So an LLM stops being a separate project and becomes just another step in an automation — sitting right next to your Slack node, your Google Sheets node, and your HTTP request node.

// Why it matters

Most useful AI work isn't a single model call — it's glue. A real task looks like: a form gets submitted, you clean the data, you call an LLM to classify it, you branch on the result, you write to a database, and you post a message to Slack. Writing and hosting that glue as code means servers, queues, retries, secrets, error handling, and a deploy pipeline. n8n collapses all of that into one canvas you can build in an afternoon.

• It removes the boilerplate. Authentication, pagination, retries, scheduling, and webhook handling are built into the nodes. You wire logic, not plumbing.
• *It makes AI a step, not a project.* Dropping an LLM into an existing automation is far cheaper than standing up a whole new service just to call a model.
• It's visible and shareable. A non-engineer can look at the canvas and understand roughly what happens. The flow doubles as its own documentation.
• It's fast to change. Move a node, add a branch, swap the model — no redeploy, no merge request. This is the core appeal of low-code for automations that change often.

Who reaches for it? Operations and growth teams automating repetitive tasks; solo builders shipping an AI feature without a backend; and engineers prototyping an agent before committing to a full framework. If you've heard of Zapier or Make, n8n sits in the same family — but it self-hosts, exposes a raw HTTP/code escape hatch, and treats LLMs and agents as first-class citizens rather than bolt-ons.

The honest boundary: n8n is for workflow automation, not high-throughput application code. It shines when the value is in connecting many systems with some logic and an occasional AI call. It's a worse fit when you need millions of low-latency requests, fine-grained version control, or complex custom logic better expressed in a real codebase. Knowing that line is most of knowing when to use it.

// How it works

Every n8n workflow is a chain (or tree) of nodes. It starts with a trigger node that decides when the workflow runs, then flows through action nodes that do things. Data moves between nodes as a list of items — usually JSON objects — and each node receives the previous node's output, transforms it, and hands its own output to the next.

Triggers: what starts a run

A workflow does nothing until a trigger fires. Common triggers are a webhook (an external service calls a URL n8n gives you), a schedule (run every hour), a poll (check Gmail for new mail), or a manual click while you're building. One trigger, then everything downstream runs.

Items: how data flows

n8n passes data as an array of items. If a node fetches 50 rows, the next node runs 50 times — once per item — automatically. You reference earlier data with expressions like {{ $json.email }}, which pulls the email field out of the current item. This per-item looping is why you rarely write explicit loops.

AI and agent nodes: where the LLM lives

A plain integration node does one fixed thing ("send a Slack message"). An AI node sends text to a model and returns its reply — useful for summarizing, classifying, or extracting fields. An agent node goes further: you give it a goal plus a set of tools (other nodes it's allowed to call), and the model decides which tools to use and in what order, looping until it's done. That's the difference between calling a model and running an agent that reasons over tools.

// A worked example: an AI support triage

Say new support emails arrive and you want each one summarized, tagged by urgency, and posted to the right Slack channel. In code that's a small service. In n8n it's six nodes, no server to manage.

The AI node does the thinking. You give the model the email body and ask for a strict, machine-readable answer so the next node can branch on it reliably:

You are a support triage assistant. Read the email below and reply
with JSON only, no extra text:
{ "summary": "<one sentence>", "urgency": "high" | "normal" }

Email:
{{ $json.body }}

The {{ $json.body }} expression injects the email text from the trigger. The model returns JSON, a Switch node reads urgency, and high-priority tickets route to an on-call channel while the rest go to the normal queue. The whole thing runs on every incoming email, untouched, until you decide to change it.

// n8n vs Zapier vs writing code

These three approaches overlap, and the right pick depends on who's building and how much control you need. Here's the honest tradeoff.

The pattern: Zapier/Make win for the simplest "when X, do Y" connections with zero setup. n8n wins when you want self-hosting, real branching logic, or LLMs and agents as built-in steps — it's the most code-adjacent of the visual tools. Writing code wins when the logic is genuinely complex, latency-critical, or needs the full discipline of version control and tests. Many teams start in n8n to validate an idea fast, then rewrite the parts that grew up into proper services.

// Common pitfalls

Visual automation is easy to start and easy to outgrow. The failures are usually operational, not conceptual.

• Treating it like version-controlled code. A canvas is harder to diff and review than a pull request. For workflows that matter, export them to JSON and commit that file, and keep separate test and production instances.
• Forgetting the AI call costs money and time. Every run that hits an LLM has a token bill and added latency. A workflow triggered thousands of times a day with a model node can get expensive fast — see estimating AI app costs.
• Hardcoding secrets in nodes. Put API keys in n8n's credential store, not in plain node fields, so they're encrypted and not exported with the workflow. (More on secrets and API keys.)
• No error handling. By default a failing node can stop the run silently. Add an error workflow or retry settings so a flaky API or a bad LLM response gets caught instead of vanishing.
• Building a giant monolith canvas. A workflow with 60 tangled nodes is as unmaintainable as spaghetti code. Split it into smaller workflows that call each other.

// Going deeper

Once the basics click, a few directions are worth knowing as your automations get more serious.

Memory and chat history. An agent or chatbot built in n8n needs to remember the conversation. Memory nodes attach a store (in-memory, a database, or a vector store) so the agent has context across turns — the same problem covered in managing LLM chat history. Without it, every message starts from scratch.

RAG inside a workflow. You can wire a full retrieval-augmented generation pipeline as nodes: a vector-store node holds your embedded documents, a retriever node pulls the relevant chunks, and the agent node uses them as a tool. This turns n8n into a quick way to prototype a "chat with your docs" feature before hardening it.

Agents calling agents and external tools. Because any sub-workflow or HTTP endpoint can be exposed as a tool, an agent node can orchestrate other workflows, and the emerging Model Context Protocol gives a standard way to plug external tool servers in. That's how a single automation grows into a small multi-step agent system.

When to graduate to code. The clean migration path is to keep the orchestration in n8n while moving heavy or sensitive logic into a Code node, then into a real service the workflow calls over HTTP. Use n8n to discover what the automation should do, and a framework to harden the parts that earned their keep. Knowing where n8n stops and a proper app stack begins is the mark of using it well — it's a superb prototyping and glue layer, not a replacement for your whole backend.