Our read
Build it in layers: validate the input before any AI call, keep the AI call to one bounded step, send failures to a dedicated error workflow, and store job state outside the run so a re-run does not repeat side effects. n8n's pricing page lists error workflows and automatic retries on Starter, Pro and Enterprise, so none of this needs a top tier.
Pick one process: a request that arrives by WhatsApp
This article draws on Icatu Seguros's assistant for insurance brokers, called AVI. A broker types something like a 29-year-old woman and coverage of one million. The assistant interprets the sentence with generative AI, extracts the parameters, calls the insurer's quotation API through n8n, and returns a simulation and a PDF in about forty seconds. The result is also saved to the broker platform. Icatu and its technology partner ED report this; it is a vendor case, not an independent test.
Brokers can also send voice notes and photos of handwritten notes, so the workflow has several input types before the AI step even starts. Use this as a skeleton: input, check, AI call, guardrails, fallback, retry. The error design below is our editorial proposal built on those pieces. Icatu's case describes the pieces, not a failure-recovery recipe.
Trigger and checks before the AI step
Icatu lists authentication and session management among the things n8n orchestrates, next to message interpretation, fallback handling, API calls and guardrails. Because n8n's Agent framework did not exist when the project began, ED built sessions with Redis and sub-workflows. The practical lesson: decide who the sender is and what state the conversation is in before you spend an AI call. A message that fails authentication should end in a cheap branch.
TUP shows the same discipline in a different setting. For remote work requests, the workflow checks calendar usage and whether the person has already used their allowed days, then accepts or rejects. For sick leave, an email is evaluated by AI and n8n handles the calendar entries and administrative messages that follow. The rule check is ordinary logic around the AI step. On the pricing page, webhook and queue triggers, JavaScript or Python code steps and custom HTTP requests are listed on all plans, which is the toolkit for these checks.
The AI step: one bounded job, with tools behind it
In AVI, the model interprets the message, and a function-routing mechanism in n8n translates OpenAI tool calls into calls to internal APIs. Audio is transcribed automatically and images are read for client data. ED says a new capability was a sub-flow connected to Icatu's internal APIs. It also says that after n8n added Agents and MCP tools, the architecture that took ten nodes could be built with three.
Editorial advice: keep each tool a separate sub-workflow, so a failure points at one tool rather than at the whole conversation. n8n's pricing page lists the AI Agent node, an MCP client and human approval for tool calls on Starter, Pro and Enterprise. Approval is the natural gate for any tool that writes data, such as saving a quotation or sending a message to a client. What happens when nobody answers an approval request is worth testing in your own workflow.
Errors and recovery: what n8n states, what you must design
The pricing page lists error workflows, execution logging, debugging in the editor and automatic retries on Starter, Pro and Enterprise. Searching executions by the data they contain starts at Pro. Hiding sensitive values in execution data is listed for Enterprise only. Two limits shape the design: saved executions are kept for 7 days on Starter, 30 on Pro and without limit on Enterprise, and a single execution may last 5 minutes on Starter versus 40 on Pro and Enterprise. A slow AI call plus retries has to fit inside that duration.
The pricing and case pages do not give the number of retries, the delay between them, or whether a failed run can be resumed from the failing step. Those settings belong to n8n's technical documentation, so check it before promising resumption. Until then, design recovery yourself. Our recommendation: on failure the error workflow alerts someone with the execution identifier and the user's session, and the user gets a fallback message. Job state sits outside the run, as Icatu's Redis sessions do, and each side effect carries a key so a re-run cannot save the same quotation twice.
TUP gives a sense of scale. Over 30 days on the Business plan, it reports 1,282 executions with 12 failures, a 0.94% failure rate. It is a self-reported figure for internal HR and knowledge workflows, not a benchmark for AI chat workflows. It does show that failures are counted and watched.
Cost, hosting and what the cases leave open
n8n prices by execution: Starter is $20 a month billed annually for 2.5k executions, Pro $50 for 10k, Business $800 for 40k and self-hosted only, and Enterprise is by quote. The page says steps are unlimited and that you pay when a workflow runs from start to finish. So extra validation and fallback branches do not raise the count. Whether failed or re-run executions count is not spelled out in that wording; read the pricing FAQ before budgeting retries. A free trial or plan exists.
On n8n Cloud, data is hosted on Azure in the European Union, and the privacy policy says personal data is not used to train n8n or third-party models. The vendor aligns its security program to SOC 2 without a type stated here. Self-hosters must encrypt data at rest themselves.
Do not use StepStone as an error-handling reference. Its case covers parsing 2 to 3 million job-related documents a month and governance with Okta SSO, an external secret store and a separate instance for IT security. It does not describe triggers or failure handling.
Method and limits
2026-11-13
This dated snapshot counts distinct companies in public customer evidence. CONFIRMED means a case study, named testimonial or press source; DECLARED means the company itself told usedby; OBSERVED means a vendor listing; SIGNAL means a job post. All four count, but their strength differs. Removed and unlevelled lines are excluded. Examples are a capped selection verified within 90 days. Vendor facts are sourced records checked within 60 days. Coverage is uneven and missing evidence is unknown. These figures measure neither market share nor product performance; capture dates are not adoption dates.