n8n AI agents in production, what actually breaks

Consider a hypothetical support-triage workflow: a model reads a ticket, tags it, drafts a reply and asks a human to review it. A useful demo still leaves questions about spending limits, routing mistakes and failed calls to connected tools.

This article covers five failure modes to test around that workflow. Their order depends on your workload; the month labels below are examples, not a forecast.

First, the honest definition

An n8n AI agent is the AI Agent node with an LLM (Claude, OpenAI, Gemini) as the reasoning engine and a set of tools it can call. The agent gets a prompt, decides which tools to run, runs them, reads the results, decides what to do next, and stops when it thinks it is done. n8n handles the input trigger, the tool wiring, the memory, and the execution log.

The reason it is compelling is not the AI part. It is that a non-engineer can look at the workflow, understand what happens, and change one step without a pull request. That is the durable value. The AI is table stakes.

What breaks, in order

1. Cost, in week one

For a hypothetical cost test, compare a short demo run with a full batch of input. Include retries and long documents when choosing the budget cap.

Two rules that keep this from happening:

• Every workflow starts with a budget check node. Track spend per run in a Postgres table. If the running total for the day is over the cap, route to a fallback (queue for later, send to a cheaper model, or just error clean). Never call the LLM blindly.
• Cheap classifier first, expensive model second. Use gpt-4o-mini or Haiku to decide whether the request even needs Claude Sonnet. Measure which requests can use the smaller model without failing your checks.

2. Silent failures, in month one

n8n executions can fail without anyone noticing. A Google Sheets append gets rate-limited. A Slack webhook returns a 403 because someone rotated the token. The workflow marks itself green because the AI Agent node succeeded, and the tool call after it just did not run.

The fix is not more monitoring. The fix is loud failure. Every workflow that touches an external system gets:

• An error trigger workflow that catches every failed execution.
• A Slack message to a #ai-alerts channel with the workflow name, the error, and a link to the failed execution. Not an email. Emails get ignored. Slack pings do not.
• Idempotency keys on every external write. If a ticket create runs twice, it should not create two tickets. Store the key in Postgres with a unique constraint and let the second insert fail.

3. The agent looping, in month two

You will get a Claude call that thinks the search tool returned nothing useful, so it searches again with slightly different words, and again, and again. n8n's default max iterations is ten. Ten iterations at Sonnet pricing with a big context is real money for one stuck request.

4. Retrieval that lies, in month three

Around month three, someone will ask why the AI keeps citing a policy document from 2023 that was replaced last quarter. Your vector database still has the old chunks. Nobody set up a re-index. The agent is confidently wrong.

Three habits that keep retrieval honest:

• Every chunk carries a source URL, a version hash, and a last-indexed timestamp. The agent quotes the source when it answers.
• A nightly workflow re-embeds anything changed in the last 24 hours, not the whole corpus. Cheap and it stays current.
• A weekly eval that runs 50 known questions against the retrieval layer and alerts if pass rate drops. This is the eval nobody builds until they get burned once.

5. Prompt drift, in month six

Your prompt started as three sentences. Six months later it is eight hundred words of "please do not confuse invoice number with PO number again" patches. Every fix is a reaction to one bad output. Nobody remembers why half the rules are there.

The fix is version control on prompts and a small eval suite. Prompts live in a Postgres table with a version number and a changelog. When someone changes the prompt, the workflow runs the eval suite (10 to 30 test cases) before the new version goes live. If pass rate drops, the change is rejected. Boring. Effective.

An example stack

Self-hosted n8n on Fly.io, sitting in front of:

1. Anthropic Claude Sonnet for reasoning and drafting.
2. gpt-4o-mini for cheap classification and routing.
3. Postgres with pgvector for retrieval.
4. A separate Postgres schema for prompt versions, budgets, and audit logs.
5. Slack for alerts. PagerDuty for anything that touches money.

Nothing exotic. The value is not in the parts. It is in how they are wired: budget check first, cheap model routing, loud failure, idempotency keys, versioned prompts, versioned retrieval, a weekly eval that runs without anyone remembering to click it.

How to build your first one, honestly

Pick a workflow that currently costs a human three to five hours a week and has clear inputs. Support triage. Lead enrichment. Contract summary. Meeting notes to CRM. Something with a shape.

1. Build the deterministic version in n8n first. No AI. Just the plumbing: trigger, tool calls, storage, alerts. Get it to green.
2. Add one AI Agent node in the middle where the human judgment was. Give it two or three tools. Cap iterations at five. Log everything.
3. Run it in shadow mode for a week. Human still does the work. Agent also does the work. Diff the outputs. Measure agreement.
4. Choose acceptance thresholds for the task before testing. Keep human review for actions whose consequences require it.
5. Set the weekly eval. Set the budget cap. Ship the runbook to the team that owns it. Walk away.

What I would skip

• Multi-agent orchestration on run one. You do not need CrewAI, you do not need a supervisor pattern, you do not need a swarm. One agent, a few tools, a fallback. Ship that. Add complexity only when the single agent visibly fails at something.
• Building your own vector database. Postgres pgvector is fine up to about a million chunks. Do not add Pinecone until you can prove Postgres is the bottleneck.
• Streaming to end users through n8n. If the workflow needs sub-second streaming to a chat UI, that is not an n8n workflow. That is a backend. n8n is for orchestration, not for real-time UX.

The AI is the interesting part. The idempotency keys and the budget cap and the alert on the failed Google Sheets append are what keep it running.

Common questions

If you want a shortcut

If an existing workflow is unreliable, review its traces, permissions and failure handling before agreeing on changes. For a paid review of one existing AI workflow, see TechTide AI's Systems Decision Audit. The audit reviews data, permissions and failure handling and provides a written recommendation. Implementation requires a separately approved scope.

Related reading

• Self-hosting n8n at scale for the infrastructure side of the same story.
• n8n vs Make vs Zapier if you have not committed to a platform yet.
• Why AI pilots die at handoff for what happens after the workflow works.