AI Agent Error Handling: Build It Before It Breaks

Your AI agent is going to fail. Not maybe. It will hit a rate limit, get a malformed response, or call a tool that times out, and it will do it on a Tuesday afternoon while you are on a call with somebody else.

AI agent error handling is the set of rules that decide what your agent does when a step fails, instead of stopping quietly and letting the client find out first.

Most solo builders skip this part. The agent worked in testing, so they ship it. Testing is a controlled range with known targets. Production is weather. After 16 years building enterprise automation before I built anything for myself, the biggest difference I see between a hobby workflow and a billable one is not the model somebody picked. It is what the system does on the bad run.

This post gives you the CATCH Protocol, a five step system for AI agent error handling you can wire into an n8n workflow this week. n8n is a workflow automation tool where you connect nodes on a canvas instead of writing a script from scratch.

Key takeaways

• AI agent error handling is the set of rules that decide what an automated agent does when a step fails, rather than stopping silently.
• The CATCH Protocol runs five steps: Classify the failure, Alert a human, Try again with a limit, Contain the blast radius, Hand off to a fallback.
• Every n8n node has a Settings tab with a Retry On Fail toggle and an On Error choice of Stop Workflow, Continue, or Continue using error output.
• An n8n error workflow is assigned in Workflow Settings and must begin with the Error Trigger node, which receives the execution ID, execution URL, error message, and the name of the last node executed.
• The Claude API returns 429 for rate limits, 500 for internal errors, 504 for timeouts, and 529 when overloaded, and its official SDKs retry transient failures with exponential backoff twice by default.
• Retries are only safe on steps that can run twice without doubling a real world action such as sending an email or charging a card.

Why AI agent error handling is harder than fixing a broken script

A traditional script fails loud. It throws an exception, the run stops, and you get a red line in a log. Ugly, but honest.

An AI agent has a second failure mode that no script has. It can finish green and still be wrong. The model returns a confident summary of an invoice it misread. It skips a tool call it was supposed to make and writes a plausible sentence instead. Nothing errored. Nothing alerted. The output went to the client.

So you are handling two categories, and they need different plumbing:

• Hard failures. A node throws. An HTTP call returns 429 or 500. Credentials expire. The run stops or branches.
• Soft failures. The run completes, the output is wrong or out of policy, and the system reports success.

Soft failures are caught before launch with validation and test cases, which is a separate discipline covered in my AI agent QA process. This post is about the hard failures, the ones that happen after the thing is already live and running without you watching.

The CATCH Protocol for AI agent error handling

Five steps, in order. Build them in order too, because each one depends on the one before it.

C: Classify the failure

You cannot decide what to do about an error until you know what kind it is. Every failure your agent hits falls into one of three buckets.

1. Transient. The request was fine, the service was busy. On the Claude API these are 429 rate limit errors, 500 internal errors, 504 timeouts, and 529 overloaded errors. Anthropic’s documentation says to retry a 500 with exponential backoff, and its official SDKs retry transient failures automatically, twice by default, honoring the retry-after header when the service sends one.
2. Permanent. The request itself is wrong. A 401 means the key is bad. A 403 means the key lacks permission. A 400 means the payload is malformed. Retrying a 400 a hundred times just burns tokens and gets you a hundred 400s.
3. Judgment. Nothing technically broke, but the output crossed a line you set. A refund amount above your threshold. A reply that names a price. These do not get retried. They get escalated.

Write this classification down before you touch the canvas. Three columns: error condition, bucket, response. That sheet is your error routing table, and it is the difference between engineering and guessing.

A: Alert a human

An agent that fails and tells nobody is worse than no agent at all, because you have stopped checking the work by hand.

In n8n, you build this once and reuse it everywhere. Create a new workflow with the Error Trigger node as the first node, name it something like Error Handler, and save it. Then in each production workflow, open Options, then Settings, and select that workflow in the Error workflow field. When an execution fails, n8n runs your handler.

The Error Trigger hands you the payload you need for a useful alert: the workflow name, the error message, the name of the last node executed, and the execution ID and URL so you can click straight into the failed run. One caveat worth knowing before you rely on it: if the failure happens in the trigger node itself, the workflow never really executed, so the execution ID and URL are not there.

Send that to Slack or email. Not “workflow failed.” Send workflow name, last node executed, error message, and the link. An alert you have to investigate is not an alert, it is homework. Deciding who reviews what, and how fast, is the job of an AI agent chain of command.

T: Try again with a limit

Only transient failures get retried. Open any n8n node, select the Settings tab, and enable Retry On Fail. The node then reruns automatically when it fails. Set Wait Between Tries in milliseconds to control the pause, and if you are working around a rate limit, n8n’s guidance is to set that wait longer than the limit itself. If the API allows one request per second, 1000 milliseconds is your floor.

Two rules keep this from turning into a self inflicted outage.

Cap the tries. Three attempts, then give up and route to the next step in CATCH. Infinite retry against a service that is genuinely down is a denial of service attack on your own budget. Every retry is another billable model call, which is why your AI agent cost per run has to be measured with retries included, not on the happy path.

Only retry what is safe to repeat. Reading a record twice is harmless. Sending an email twice is a support ticket. Charging a card twice is a refund and a lost client. Before you flip Retry On Fail on a node, ask whether running that node twice does anything to the real world. If it does, move the retry to a step that only reads, and let the write happen once at the end.

C: Contain the blast radius

One bad record should not kill the batch. This is where the On Error setting earns its keep. In n8n’s node Settings you get three choices, and picking the wrong one is the most common error handling mistake I see:

• Stop Workflow. Halts everything. Correct for a step where continuing would produce a wrong result, like a failed data lookup that feeds a client facing summary.
• Continue. Moves to the next node using the last valid data. Use this sparingly. It is how silent corruption gets downstream.
• Continue (using error output). Keeps running and passes the error information down a separate branch so you can actually handle it.

That third option is the one you want for batch work. Wire the error branch to a quarantine destination: a spreadsheet row, a database table, a Slack channel. Good records finish. Bad records land somewhere you can see them. Nothing disappears.

H: Hand off to a fallback

The last step is deciding what “degraded but still useful” looks like. A system that does 70 percent of the job during an outage beats a system that does nothing and waits for you.

Build a fallback ladder and let the agent walk down it:

1. Retry the same call, capped.
2. Route to a second model or a second provider.
3. Drop to a plain template response that does not need a model at all.
4. Queue the item for a human and acknowledge the sender so nobody is left hanging.

n8n also gives you the Stop And Error node, which forces an execution to fail on purpose under conditions you define. That sounds backward until you need it. If your agent produces output that violates a rule, you want a loud, deliberate failure that fires your error workflow, not a quiet pass. Failing on purpose is a feature.

Whatever the fallback does, log the state it stopped in. An agent that restarts cold after every failure repeats work you already paid for, which is the same problem AI agent memory solves on the happy path.

A worked example: the invoice intake agent

Example scenario. You built an agent for a bookkeeping client. It watches an inbox, reads invoice PDFs, extracts vendor, amount, and due date, and writes a row to a spreadsheet. Twenty to forty invoices a day.

Here is CATCH applied to it, node by node.

1. Classify. The model call can throw 429 or 529, both transient. The spreadsheet write can throw 401 when the credential expires, permanent. An extracted amount over 10,000 dollars is judgment, because a decimal misread there is expensive.
2. Alert. One Error Handler workflow, Error Trigger first node, posting workflow name, last node, error message, and execution URL to a private Slack channel.
3. Try again. Retry On Fail enabled on the model node only, three tries, Wait Between Tries set to 2000 milliseconds. The spreadsheet write does not retry, because a duplicate row is worse than a missing one.
4. Contain. The extraction node uses Continue (using error output). Failed invoices route to a Needs Review tab with the file name and the error attached. The other 38 invoices post normally.
5. Hand off. Anything over 10,000 dollars skips the automatic write, goes to the review tab, and pings the client contact directly. The agent never books a large number without a human looking at it.

Same agent, same model, same nodes. The only thing that changed is what happens when something goes wrong, and that is the entire difference between a workflow you demo and a workflow you invoice for.

Your action steps this week

1. Open your most important live workflow and list every node that calls an outside service. Those are your failure points.
2. Build the error routing table. Three columns: error condition, bucket, response. Do it on paper first.
3. Create one Error Handler workflow with the Error Trigger node, and assign it in Workflow Settings on every production workflow you own.
4. Turn on Retry On Fail for read only and model call nodes. Cap it at three tries. Leave it off anything that writes, sends, or charges.
5. Set On Error to Continue (using error output) on any node that processes a batch, and point the error branch at a quarantine destination you will actually check.
6. Break it on purpose. Revoke a test credential, run the workflow, and confirm the alert reaches you with a usable message. An untested error path is a guess.

If you have not built the agent yet, start with the wiring first and come back here. My walkthrough on how to build an AI agent with n8n covers the base workflow this protocol sits on top of.

Frequently asked questions

What is AI agent error handling?

AI agent error handling is the set of rules that decide what an automated agent does when a step fails. It covers classifying the error, alerting a human, retrying safely, containing the damage to a single record, and falling back to a degraded path that still produces something useful.

How many times should an AI agent retry a failed step?

Three attempts is a reasonable ceiling for most solo builds, and it should apply only to transient errors. For reference, Anthropic’s official SDKs retry transient failures twice by default with exponential backoff. Past three tries you are usually paying for the same failure repeatedly instead of escalating it.

What is an error workflow in n8n?

An error workflow in n8n is a separate workflow that runs automatically when another workflow’s execution fails. You assign it in Workflow Settings, and it must start with the Error Trigger node. One error workflow can serve many production workflows.

Should an AI agent ever continue after an error?

Yes, but only when the error affects one item rather than the whole job. Use Continue (using error output) so the failed item routes to a review queue while the rest of the batch finishes. Avoid the plain Continue option, because it carries the last valid data forward and hides the failure.

How do I catch an agent failure when nothing threw an error?

Add your own validation and force the failure yourself. Check the output against rules you can express in code, such as required fields, value ranges, and expected formats, then use the Stop And Error node to fail the execution deliberately when a rule breaks. That converts a silent wrong answer into a loud alert.

Does error handling slow an agent down?

Barely, on a normal run. Retry settings and error branches cost nothing when nothing fails. The measurable cost shows up only during failures, in extra model calls from retries, which is why capping tries matters.

Recap

AI agent error handling is not extra credit. It is the part of the build that decides whether a client keeps paying you after the first bad week.

Run the CATCH Protocol. Classify every failure into transient, permanent, or judgment. Alert a human with a message they can act on. Try again with a hard cap, and only on steps that are safe to repeat. Contain failures to one record with the error output branch. Hand off to a fallback that still delivers something.

Anybody can build an agent that works on a good day. Building one that behaves on a bad day is the skill people pay for.

If you want the next build broken down like this one, subscribe and follow along.

References

Anthropic. (n.d.). Claude API errors. Claude Platform Docs. Retrieved September 1, 2026, from https://platform.claude.com/docs/en/api/errors

n8n. (n.d.). Handle errors gracefully. n8n Docs. Retrieved September 1, 2026, from https://docs.n8n.io/build/flow-logic/handle-errors-gracefully

n8n. (n.d.). Handle rate limits. n8n Docs. Retrieved September 1, 2026, from https://docs.n8n.io/integrations/builtin/handle-rate-limits

n8n. (n.d.). Work with nodes. n8n Docs. Retrieved September 1, 2026, from https://docs.n8n.io/build/understand-workflows/workflow-components/work-with-nodes

n8n. (n.d.). Stop And Error. n8n Docs. Retrieved September 1, 2026, from https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.stopanderror