n8n + LLM Nodes — The Agentic Workflow That Doesn't Need a Framework
A working engineer's read on n8n's AI Agent and LLM nodes, the shape of agentic workflows you can build without a Python framework, and where the abstraction breaks down.
n8n has, over the last eighteen months, added an AI-and-agents track to a product that was originally a workflow automation tool in the Zapier/Make/Power Automate family. The track is more developed than most readers of this publication probably realize. The AI Agent node, the various LLM nodes (Chat Model, Embeddings, Text Classifier), the vector-store integrations, and the LangChain-rooted memory primitives now collectively cover a meaningful slice of what an agentic system needs. The pitch — “build agentic workflows without writing Python” — is, for a specific shape of workload, real.
This piece is a working engineer’s read on what you can actually build in n8n today, how the agent abstractions fit into the workflow model, where the abstraction leaks, and which workloads the n8n approach wins for. The reference is n8n 1.69+ on the self-hosted Docker image, against the publicly documented AI nodes (@n8n/n8n-nodes-langchain).
What n8n’s agent track looks like
The n8n workflow editor’s vocabulary is a graph of nodes, each of which takes a typed input and produces a typed output. The AI track adds several node families to the existing graph:
- AI Agent node — wraps a LangChain-rooted agent (Tools Agent, Conversational Agent, ReAct Agent, OpenAI Functions Agent, Plan-and-Execute). The node takes a language-model node and one or more tool nodes as inputs and exposes the agent’s input/output as a normal n8n graph edge.
- Chat Model nodes — wrappers around OpenAI, Anthropic, Google Vertex, Ollama, Mistral, and several other providers. The model is the agent’s brain.
- Memory nodes — Window Buffer, Postgres Chat Memory, Redis Chat Memory, Zep Memory, Motorhead Memory. The agent’s state lives here.
- Tool nodes — Code, HTTP Request, Vector Store retrieval, Workflow (call another n8n workflow as a tool), Calculator, Wikipedia, Wolfram. The agent’s hands.
- Vector Store nodes — Pinecone, Qdrant, Supabase, Postgres pgvector, MongoDB Atlas, Weaviate.
- Text Classifier, Output Parser, Information Extractor nodes — the building blocks for structured LLM calls inside a non-agent workflow.
The shape that emerges is recognizable. n8n is exposing the LangChain object model — Agent + Tools + Memory + Model — as a visual graph. The execution engine is n8n’s own workflow runtime, not LangGraph or any of the other framework runtimes. The LangChain primitives are vendored under @n8n/n8n-nodes-langchain and tracked against upstream LangChain releases.
The workloads n8n wins for
The clearest n8n-shaped agentic workload is the trigger-driven micro-agent. A new message arrives in a Slack channel; an agent classifies it, decides whether it needs a response, looks up context from a vector store, drafts a reply, and posts it back. A new row appears in a database; an agent looks at the row, decides whether it is interesting, summarizes the recent history, and writes to a different system. A new email arrives in a shared inbox; an agent triages it against a tool registry, applies labels, and either drafts a response or routes it to a human.
This shape — event in, agent does work, side effect out — is precisely what n8n’s workflow model is for, and the agent abstraction sits cleanly inside it. The win is that the workflow already has the trigger, the credentials manager, the rate-limit handling, the error-retry semantics, and the observability surface; the agent is just one node in the graph.
The second clearly winning shape is the multi-step ETL-with-judgment workflow. A document arrives; an LLM extracts structured data; a downstream step uses the structured data to make a deterministic decision; another LLM step generates a human-readable summary; the output is written to a CRM or a sheet. n8n handles the graph; the LLM nodes handle the judgment steps; the framework-shaped overhead of LangGraph or AutoGen is not needed because the workflow already is the graph.
The third winning shape is internal automation for non-engineering teams. n8n’s visual editor is operable by an analyst with a few hours of training. The combination of LLM nodes and the existing 400+ integrations means that the analyst can ship workflows that would, in a Python-first stack, require an engineer.
Where the abstraction leaks
The abstraction leaks at three predictable boundaries.
Long-running and durable agent state. The AI Agent node executes a single agent loop within a single workflow execution. n8n’s execution model is request/response with checkpointing at node boundaries; it does not have a first-class durable-agent shape that survives across many workflow invocations. If your workload is a single long-running assistant that needs to hold conversation state across days, n8n’s Postgres Chat Memory is the right primitive — but you are now managing the durable-state model yourself, and the workflow per-invocation shape stops paying for itself.
Complex multi-agent topologies. n8n’s graph model is the workflow graph, not an agent topology. You can build a multi-agent system by having one AI Agent node call a sub-workflow that runs another AI Agent node as a tool — and we have shipped this shape in production — but the developer ergonomics are noticeably worse than what AutoGen or CrewAI give you. The framework layer wins here.
Fine-grained agent control. The AI Agent node exposes the agent’s input, output, and a basic options surface (max iterations, system message, return intermediate steps). It does not expose the kind of fine-grained control over the agent loop that LangGraph’s checkpointer-and-state-machine model gives you. If you need to interrupt the agent, inspect its scratchpad, and resume from a chosen step, n8n is the wrong layer.
The leaks are predictable because they are the leaks of any low-code abstraction over an underlying SDK. n8n’s abstraction is good enough for the workloads above and not good enough for the workloads where the framework layer wins.
The cost picture
n8n self-hosted is, in inference terms, the cheapest of the agent surfaces in our active comparison. The workflow runtime is on your hardware (or your cloud VM); the only outbound spend is the model API call and the tool-side API calls. For a small fleet of micro-agents on Claude Sonnet or gpt-4o-mini, we have seen monthly inference bills in the low-three-figures handling thousands of agent invocations per day.
The n8n Cloud pricing — based on workflow executions and active workflows — is a different calculus. Cloud is the right answer for small teams and a poor answer for high-volume agentic workloads. The self-hosted economics are what makes n8n’s agent track interesting at scale.
The cost we underweight in early estimates is the engineering-time cost of building a custom node when the existing tool registry does not have what you need. The HTTP Request node covers most APIs cleanly; some legacy systems require a custom n8n node, which is a TypeScript package against the n8n node SDK. We have built two of these in the last year; both took longer than estimated.
When to pick n8n
Pick n8n for an agentic workload when:
- The workload is event-triggered or schedule-triggered, with a clear input/output shape.
- The agent loop is bounded — under ten iterations, under a few minutes of wall time.
- The team includes non-engineers who will own the workflow long-term.
- The tool registry the agent needs is mostly covered by n8n’s existing integrations or by the HTTP Request node.
- You want the workflow to inherit the observability, credentials management, and error handling that n8n already gives you.
Pick a framework — LangGraph, AutoGen, CrewAI, or one of the others — when:
- The workload requires durable agent state across long horizons.
- The topology is genuinely multi-agent in a way the workflow graph cannot express cleanly.
- You need fine-grained agent-loop control.
- The team is engineering-led and the deployment is part of a larger Python or TypeScript application.
Pick a bundled platform when:
- The user is an operator, not an engineer.
- The workload is the platform’s vertical (action runtime, browser automation, workforce-shaped operations).
- The operator wants a non-developer surface as the canonical interaction.
A working summary
n8n’s agent track is the most credible “agents without a framework” story in the public market in early 2026. The abstraction is good enough for a wide swath of trigger-driven and ETL-with-judgment workloads, the cost economics on self-hosted are excellent, and the integration story inherits from n8n’s existing 400+ nodes. The framework layer still wins for the workloads framework layers are designed for. The bundled-OS layer still wins for the operator-facing shape. n8n wins, cleanly, for the workflow-shaped middle.
That middle is bigger than the framework-first conversation usually credits. It is also the easiest place to ship agentic value to a non-engineering team, which is where most organizations’ real near-term ROI on agentic work is going to come from. We have shipped more n8n agent workflows in the last twelve months than LangGraph agents, and the cost-per-shipped-workflow ratio has not been close. The right reading is that the framework conversation is over-indexed in the public discourse, and the workflow conversation is under-indexed. n8n is one of the products that is correcting the balance.
Related reads
Retrieved 2026-06-12 — Permalink: https://agentic.review/articles/n8n-agentic-workflow-no-framework/
The Agentic Review · agentic.review