n8n’s checkmark turns green when the workflow finishes running. That’s it. That’s all it’s checking. It has no idea whether the AI step three nodes back invented a phone number, summarized a report with numbers that don’t exist, or replied to a lead with information from a completely different client’s data.
Nothing crashed. Nothing logged. Nothing told anyone. The workflow completed successfully — with garbage inside it.
Your client finds out when a lead never gets a reply, or a report goes out with a revenue number nobody can trace back to reality. That’s not a bug you missed. That’s a system you never built.
Why AI Steps Don’t Throw Errors
A traditional automation fails when an API call times out, a field is null, or a request gets rejected. Those are hard failures — n8n catches them and your Error Trigger fires. An LLM node almost never does this. It returns 200. It returns a full, confident, well-formatted response. The response is just wrong.
Hallucination isn’t a crash. It’s a successful API call with fabricated content. Your workflow has no native way to tell the difference between “the AI got it right” and “the AI got it right structurally, wrong factually.” You have to build that difference in yourself.
The Fix: Three Layers, Not One
Layer 1: Error Handling on Every AI Step
Every single node that calls an LLM needs a validation step immediately after it — not just the workflow-level Error Trigger, which only catches hard failures. Add an IF or Code node right after each AI call that checks the output against what you actually expect:
- Does the JSON match the schema you asked for? (missing fields, wrong types, extra hallucinated keys)
- Do referenced values actually exist in the source data — does the email/phone/name the AI “extracted” match a record in your CRM or sheet?
- Do numbers add up? If the AI is summarizing totals, recalculate the sum yourself in a Code node and compare.
If the check fails, route to a separate branch — don’t let it flow downstream. n8n’s own documentation on error handling and workflow-level error triggers is a good starting point, but note it’s built for exceptions, not for silently-wrong-but-valid output — which is why you need the manual validation layer on top. If you haven’t built this base layer yet, walk through the full node-by-node setup in this error handler build.
Layer 2: A Logging Node Someone Actually Checks
Logging that nobody reads is decoration. Every AI call — input, output, timestamp, node name, pass/fail from your Layer 1 check — should write to a table you or your team actually open. Airtable, Google Sheets, or Postgres all work. What matters is the habit, not the tool.
Set a recurring [X-minute] check or, better, have failures push directly to a Slack channel with the actual payload attached, not just “workflow failed.” You want to see the exact hallucinated output, not a generic alert. This is also where cost anomalies show up early — if you’re not already watching spend per run, pair this with cost caps on runaway loops so a bad AI step doesn’t also become an expensive one.
Layer 3: A Human Checkpoint Before Anything Reaches a Client
For anything client-facing — a report, a lead reply, an outbound message — add a pause. n8n’s Wait node combined with a webhook resume (or a Slack “Approve/Reject” button via the Slack node’s interactive message) lets a human glance at the output before it ships. This isn’t about reviewing everything forever. It’s about reviewing everything until you’ve logged enough passes to trust the specific node type, then sampling from there.
What This Actually Catches
The specific failure modes worth building checks for: fabricated contact details, invented statistics in reports, mismatched entity names (AI merges two leads into one), and confident summaries of data that was empty or malformed going in. None of these throw a workflow error. All of them will end up in a client’s inbox if you don’t build the check.
This is the same blind spot that shows up in content, not just automation. A post can look fine on the surface — reach numbers, impressions — while the actual engagement underneath tells a completely different story. The reach isn’t revenue breakdown covers the same principle from the content side: the surface-level metric that looks like success and the reality underneath rarely match unless you actually check.
Assume It Will Lie
I build every automation now assuming the AI will hallucinate eventually — not if, when. That assumption changes how you build. You stop trusting the green checkmark and start building systems that fail loud: validated at the node level, logged somewhere you check, and gated by a human before it touches a client. It’s more setup time upfront. It’s a fraction of the cost of a client finding the lie before you do — which is also why how you frame this work matters when you’re pitching it; see selling the outcome, not the automation for how to talk about reliability without sounding like you’re selling insurance.