The first time an n8n AI workflow fails, it often does not fail cleanly.
It returns a 200 status with garbage inside. It writes half a record. It retries a non-retryable error. It calls a tool twice. It asks the model again, spends more tokens, and produces the same malformed JSON. The workflow “completed,” but the system is now in a worse state than before.
That is the difference between an automation that runs and an AI system that recovers.
Recovery is not just adding a retry node. In AI workflows, failure can come from many directions: an API timeout, a model returning invalid output, a tool call with missing permissions, a prompt-injection attempt, a budget limit, a duplicate webhook, or a partial action that cannot simply be repeated.
If I were designing an n8n AI system for production, I would design it around one core assumption:
