flowchart LR
T[Trigger: webhook / email / schedule] --> V[Validate / shape data]
V --> L[LLM node: classify + extract]
L --> R{Route}
R -- urgent --> N[Notify / Slack]
R -- record --> DB[(Upsert to DB / CRM)]
R -- answer --> RAG[RAG reply]
DB --> LOG[Log + audit]
LLM Workflows: Automating Real Work with n8n
There are two ways to put an LLM to work. One is a code pipeline - you write the orchestration (see LLM pipeline patterns). The other is a workflow: an event fires, data flows through a few steps, an LLM is one node, and something happens in the real world. For the second, I reach for n8n - open-source, self-hosted, dev-friendly.
- n8n notes: https://bthek1.github.io/WEB_doc/16_n8n
- Repo: github.com/bthek1/WEB_doc
What an LLM workflow actually is
An LLM workflow is event-driven glue: a trigger starts it, data passes through nodes, the LLM classifies / extracts / drafts, and action nodes write to a DB, call an API, or notify someone. The model is a step, not the whole show.
Code pipeline vs visual workflow - when to use which
Both are legitimate. The question is who owns the logic and how often it changes.
| Code pipeline | n8n workflow | |
|---|---|---|
| Lives in | Your app / repo | A workflow engine |
| Best for | Core product logic | Ops / business automation |
| Changes | Deploy | Edit in the UI |
| Integrations | You write clients | 400+ prebuilt nodes |
| Testing | Unit tests | Manual runs + retries |
| Ceiling | Unlimited | Great until logic gets deep |
Rule of thumb from the n8n notes: business automation -> n8n; core product logic -> app code; massive data pipelines -> Airflow/Dagster. For the code-first LLM patterns, see LLM pipeline patterns.
The n8n mental model
Four concepts and you can build most things:
| Concept | Role |
|---|---|
| Triggers | Start a run: webhook, schedule, email, app event |
| Nodes | Steps: logic, HTTP, DB, an LLM node, code |
| Expressions | { $json.field } - pass data between nodes |
| Credentials | Encrypted secrets, referenced not inlined |
An LLM node (OpenAI / Anthropic / a self-hosted model) drops in like any other node - prompt in, structured JSON out - then downstream nodes act on that JSON. Details in https://bthek1.github.io/WEB_doc/16_n8n.
A worked example: inbound form -> triage -> action
A pattern I keep reusing: an inbound submission (webhook / form) is classified and extracted by an LLM, then routed. It’s the ops-automation version of the healthcare API integrations - LLM as the triage brain in the middle.
sequenceDiagram
participant Form
participant n8n
participant LLM
participant CRM
Form->>n8n: webhook (new submission)
n8n->>n8n: validate + normalise
n8n->>LLM: classify intent + extract fields (JSON)
LLM-->>n8n: {intent, priority, fields}
alt high priority
n8n->>CRM: create record + flag
n8n->>n8n: notify on-call
else normal
n8n->>CRM: upsert record
end
Why bother: build time
For an ops automation with 4-5 integrations, a visual workflow ships in an afternoon where hand-coding the same glue (clients, retries, deploy) takes days.
Reliability is the hard part, not the LLM
The model is rarely what breaks - the glue is. The workflow equivalents of good service hygiene:
| Concern | n8n practice |
|---|---|
| Transient failures | Retry-on-fail + backoff per node |
| Bad LLM output | Validate JSON; branch to a fallback |
| Duplicates | Idempotent upsert on a stable key |
| Partial runs | Error workflow + dead-letter / alert |
| Secrets | Credentials store, never inline in nodes |
| Observability | Execution log; alert on failed runs |
Treat the LLM node as untrusted - always validate its JSON before an action node acts on it.
The tool landscape
Where n8n sits among workflow tools - the trade is openness/self-hosting vs turnkey SaaS:
| Tool | Strength |
|---|---|
| Zapier | Fast, simple, SaaS-only |
| Make | Visual, complex flows |
| n8n | Open, self-hosted, dev-friendly |
| Airflow / Dagster | Heavy ETL, data engineering |
| Temporal | Durable workflows, code-first |
| Celery | Task queue, no UI |
Representative split of what I automate with LLM workflows:
Takeaway
Reach for an LLM workflow when the value is connecting a model to real triggers and tools, and the logic will change often - self-host n8n, drop the LLM in as one node, and spend your effort on validation and error handling, not plumbing. Reach for a code pipeline (patterns) when it’s core product logic. And when a step needs grounded answers, that node is a RAG system.