n8n AI Workflow Automation: Architecture Guide (2026)

Q: What is n8n and how is it different from Zapier?

n8n is a source-available workflow automation platform: you build automations by wiring nodes — triggers, transformations, app integrations, AI steps — into visual flows, and it connects to 500+ applications. The two structural differences from Zapier are hosting and pricing. n8n can be fully self-hosted on your own server, which means your API keys, customer data, and workflow logic never live in a third-party SaaS — often the deciding factor for teams with compliance obligations or sensitive data — while Zapier is SaaS-only. On pricing, Zapier bills per task, meaning every step of every run counts against your plan, so long flows at high volume get expensive fast; self-hosted n8n costs whatever your server costs, regardless of how many steps or executions you run, and n8n Cloud bills per execution rather than per step. n8n also has a deeper technical ceiling: first-class JavaScript and Python code nodes for logic the visual builder cannot express, and a substantially richer AI layer (agent, LLM, memory, and vector-store nodes). Zapier remains easier for non-technical users automating simple two-app connections; n8n suits teams that want depth, volume, and control.

Q: Can n8n build real AI agents?

Yes, within a specific and useful scope. n8n's AI Agent node — built on LangChain under the hood — combines a model, a set of tools, and optional memory, and loops autonomously until the task resolves: it can call sub-workflows as tools, hit HTTP endpoints, query vector stores for retrieval, and speak MCP to external tool servers. That is a real agent in the architectural sense. The scope limit is horizon and complexity: n8n agents shine as bounded, tool-assisted judgment steps inside a visible workflow — "given this email and these five tools, resolve the customer's question or escalate" — where the surrounding flow provides the trigger, the guardrails, the approval gate, and the follow-up actions. What n8n is not the right runtime for is a long-horizon autonomous agent product: hundreds of reasoning steps, planning artifacts, sub-agent spawning, durable state across hours — that class of system needs a code-first framework where you control context management, checkpointing, and evaluation. The practical boundary: if the agent is a step in a business process, n8n is excellent; if the agent is the product, write code.

Q: Is n8n cheaper than Zapier at scale?

At meaningful volume, dramatically — and the gap grows with flow length. Task-based SaaS pricing bills every step of every execution: a 20-step workflow that runs 10,000 times a month consumes 200,000 billed tasks, which on typical SaaS automation plans lands in the hundreds of dollars per month, and doubling either flow length or volume doubles the bill. Self-hosted n8n decouples cost from usage entirely: the same workload runs on a $20-50/month virtual server, and a hundred flows cost the same infrastructure as ten. n8n Cloud sits between — it bills per execution (one workflow run counts once regardless of step count), which is already structurally cheaper for long flows than per-task billing. The honest counterweight is operational cost: self-hosting means you own updates, backups, database maintenance, and scaling, which is a real if modest time investment, and at very low volumes (a handful of short flows) a SaaS free tier can be cheaper than any server. The crossover arrives quickly though — AI-heavy automations tend to be long flows at growing volume, which is exactly the shape where per-task billing punishes and self-hosting wins.

Q: How do I add an LLM step to an n8n workflow?

Three node families cover the spectrum. For a single-shot judgment — classify this email, extract fields from this document, draft a reply — use the basic LLM/chain nodes: connect a model credential (OpenAI, Anthropic, Google, or a local model via Ollama's OpenAI-compatible endpoint), write the prompt with expressions that inject data from earlier nodes, and the response flows to the next node; ask for JSON output with a defined schema so downstream nodes can parse it reliably. For multi-step judgment, use the AI Agent node: attach tools (sub-workflows, HTTP requests, vector-store queries), optionally attach memory for conversational state, and let it loop until done. For retrieval-augmented steps, pair a vector-store node (Pinecone, Qdrant, pgvector, Supabase) with an embeddings node so the LLM answers from your documents. Practical disciplines that keep flows reliable: use a cheap model for classification and a better one only where quality shows, cap tokens per execution, log inputs and outputs for debugging, and put a human-approval gate between the LLM and any consequential action like sending an email or modifying a record.

Q: What are the best AI automation use cases to build first in n8n?

Start with the unglamorous, high-frequency flows where AI removes a daily manual chore — they pay back fastest and fail safest. Inbox or ticket triage is the classic first build: a webhook or email trigger feeds each message to an LLM that classifies intent and urgency and extracts entities, then the flow routes it to the right team and drafts a reply for human approval. Lead enrichment is second: a form submission triggers enrichment from public APIs, an LLM scores the lead against your ideal customer profile, and the result lands in the CRM with a Slack alert for hot leads. Document intake is third: invoices, CVs, or contracts arrive, an LLM extracts structured fields, validation rules check them, and clean data enters the system of record. Content operations is fourth: monitoring triggers (RSS, mentions) feed summarisation and draft generation, with a human approving before anything publishes. All four share the shape that works: event arrives, AI classifies/extracts/drafts, a human approves anything consequential, systems get updated automatically. Pick the one where your team burns the most repetitive hours; one good triage flow typically saves 5-10 hours a week.

Q: How do I run n8n in production reliably?

Treat it like any service that the business depends on, because it becomes one. Move off the default SQLite to Postgres early — SQLite is fine for evaluation but not for production concurrency or backup discipline. Enable queue mode once concurrent executions climb: it splits n8n into a main process and Redis-backed worker processes, so heavy flows scale horizontally instead of blocking each other. Attach an error workflow — n8n supports a global error handler that fires when any workflow fails — and use it to alert a channel, log the failure, and dead-letter the payload for replay; without it, failures are silent and the business discovers broken automation weeks later. Keep every credential in n8n's encrypted credential store, never pasted into node parameters, where they leak through workflow exports and screenshots. Export workflow JSON and commit it to git so changes are reviewable and restorable. Make triggers idempotent — webhook providers redeliver, and a replayed event must not double-send an email or double-write a record. And for AI steps specifically, cap token budgets per execution and log model inputs/outputs so you can debug the judgment steps like any other component.

Q: When should I NOT use n8n and write code instead?

The boundary is whether the thing you are building is an automation or an application. n8n excels when the shape is: an event arrives, some deterministic steps run, an AI step exercises judgment, a human approves, systems get updated — visible, linear-ish flows that a team can inspect and modify. Write code instead when you see these signals: the logic needs real branching state machines or complex error recovery that fights the visual paradigm; the AI component is long-horizon and autonomous (many reasoning steps, planning, sub-agents, durable state) rather than a bounded judgment step; you need SLAs, load testing, and deployment pipelines that treat the thing as a product; multiple developers need to collaborate with code review and tests as the primary workflow; or the flow has become so large that the canvas is itself the complexity. A useful graduation rule: when a workflow accumulates more code nodes than visual nodes, or when you find yourself wishing for unit tests, it has outgrown the tool — port it to a proper service with an agent framework. Mature teams run both deliberately: n8n for the long tail of business glue, custom services for the handful of flows that became products.

Q: Can n8n use local or self-hosted LLMs instead of cloud APIs?

Yes, and the combination is one of the strongest privacy stories in automation: a self-hosted n8n instance calling a self-hosted model means the entire pipeline — trigger data, prompts, model outputs, and actions — runs on infrastructure you control, with nothing leaving your network. The wiring is straightforward because local runtimes expose OpenAI-compatible endpoints: run Ollama or vLLM on the same server or network, and point n8n's model credential at the local base URL (for Ollama, localhost port 11434) instead of a cloud provider; n8n also ships a dedicated Ollama integration. The practical pattern most teams land on is hybrid by task: a local quantized 7-8B model handles high-volume, low-stakes judgment steps — classification, routing, extraction — where it is fast, free per token, and private, while a frontier cloud model is reserved for the low-volume steps where quality visibly matters, like drafting customer-facing text. This mirrors the model-routing pattern production AI systems use, applied inside workflow automation. For regulated or client-confidential data, the fully-local configuration turns the compliance conversation from "where does our data go" into "it doesn't go anywhere," which is frequently the difference between an automation shipping and dying in review.