The n8n + Claude workflow pattern we use for every single project

If you pulled open 50 of our production AI workflows, you'd see the same 7-node pattern in most of them. It's not sexy. It's reliable, maintainable, and hard to mess up. Here it is.

The 7-node pattern

Why each node matters

Node 1: Trigger

Obvious but critical — use webhooks wherever possible instead of polling. A webhook fires within milliseconds of an event. A poll adds 2-5 minutes of latency and wastes compute. n8n supports webhooks natively; use them.

Node 2: Validate input (this is where 90% of bugs die)

The single most important node, and the one DIY builders always skip. Before ANY processing happens, validate the incoming data against a schema: required fields present, types correct, string lengths reasonable, email formats valid. Reject bad input immediately with a clear error log.

Why it matters: 90% of 'my workflow broke' issues are actually 'upstream system sent weird data and everything downstream cascaded.' Validating at node 2 catches all of this before it becomes a debugging nightmare.

Node 3: Enrich

Before classifying, fetch anything the LLM will need to make a good decision: the customer's history, the product catalog, the company data. Pull it all into a single enriched object. This is much better than making the LLM call external tools mid-reasoning — faster, cheaper, and easier to debug.

Node 4: Classify (Claude) — the only LLM call

One LLM call per workflow execution. Always returns structured JSON. Always has an explicit 'confidence' field. Never allowed to return freeform text that downstream nodes have to parse.

You are a [ROLE] for [BUSINESS]. Your job is to classify
the input into one of these categories: [ENUM_LIST].

RETURN JSON ONLY IN THIS FORMAT:
{
  "classification": "one of the enum values",
  "confidence": 0.0 to 1.0,
  "reasoning": "1-sentence explanation",
  "extracted_data": { ...structured fields... }
}

IF CONFIDENCE < 0.7, STILL RETURN A CLASSIFICATION
BUT FLAG IT. THE DOWNSTREAM LOGIC WILL ROUTE TO HUMAN.

INPUT DATA:
{enriched_data_from_node_3}

Node 5: Branch

Route based on the classification + confidence. The critical pattern here is that low-confidence outputs ALWAYS route to human review, not to automated action. This is the single best way to prevent 'the AI did something weird and broke things.'

Node 6: Act

The actual action: send an email, book a meeting, update the CRM, etc. This is usually 1-3 parallel actions depending on the branch taken. Wrap each action in retry logic (n8n supports this natively) so transient API failures don't kill the workflow.

Node 7: Log (this is what makes everything maintainable)

Every execution — successful or failed — writes a log entry to a persistent store (Google Sheet, Postgres, Supabase, whatever). The log should include: input, classification, confidence, action taken, success/failure, timestamp, error (if any).

Why this is non-negotiable: when something goes wrong 3 months from now (and it will), you need to be able to ask 'what did the workflow do on lead X?' without guessing. The log is the answer. Skip this and you're flying blind.

What this pattern prevents

• Silent failures — every execution is logged, so nothing disappears silently
• Confident wrong answers — confidence gating forces human review on uncertain cases
• Cascading bugs from bad input — validation catches malformed data at node 2
• Runaway LLM costs — only one LLM call per execution, capped by the workflow structure
• Unmaintainable spaghetti — every workflow looks the same, so new team members can navigate any of them

FAQ