N8N AI agent, který nespadne: error handling a retry

N8N AI agent je nejsilnější kousek automatizace, jaký doma nebo ve firmě postavíš — a zároveň nejjistější způsob, jak si jednou ráno zjistit, že ti devadesát minut nikdo neodpovídal na e-maily. Rozdíl nespívá v modelu ani v promptu, ale v nastavení, které většina lidí přeskočí: error handling, retry a monitoring. V tomto návodu ti ukážu konkrétní nastavení v n8n, díky kterému tvůj AI agent přežije výpadek API, přetečení kontextu i svou vlastní smyčku — a ty se to dozvíš během minut, ne týdnů.

Buildíš-li agenta poprvé, mrkni nejdřív na základní průvodce n8n AI agentem pro zákaznický servis — tady pojďme o krok dál, do produkce.

Proč AI agent v n8n padá častěji než klasický workflow

Klasický workflow je deterministický: spustí se, projde uzly ve stejném pořadí a skončí. Když něco selže, selže to na jednom konkrétním místě.

AI agent funguje jinak. Jak popisuje oficiální dokumentace n8n, agent se v rámci jedné exekuce spouští opakovaně — jednou pro úvodní nastavení, podruhé když se rozhodne zavolat nástroj, potřetí, když vyhodnocuje odpověď. Každý z těchto běhů je samostatná příležitost k selhání. Přidej k tomu LLM provider s rate limity, tooly volající externí API a paměť, která roste s každým rozhovorem, a dostaneš komponentu, jejíž spolehlivost musíš navrhovat stejně pečlivě jako samotnou logiku.

Typická místa pádu:

• Rate limit a výpadky LLM API — agent zavolá model, model vrátí 429 nebo timeout.
• Tool selže — HTTP požadavek na externí službu spadne nebo vrátí neočekávaný formát.
• Kontext přeteče — dlouhá historie konverzace přeroste okno modelu.
• Nekonečná smyčka — agent se zasekne v volání jednoho toolu dokola.
• Fallback chybí — chyba jednoho uzlu zastaví celý workflow a nikdo se to nedozví.

Nastav retry a On Error na každém kritickém uzlu

První a nejdůležitější krok se nedělá v agentovi, ale v nastavení uzlů. Otevři uzel, přepni se na záložku Settings a projdi tato pole (viz oficiální přehled nastavení uzlů):

• Retry On Fail — když exekuce uzlu selže, uzel se zopakuje, dokud neprojde nebo nedosáhne limitu pokusů. U HTTP requestů a volání LLM to zapni vždy.
• On Error: Stop Workflow — výchozí chování; při chybě se celý workflow zastaví. Pro agenta v produkci to většinou nechceš.
• On Error: Continue — workflow pokračuje s posledními platnými daty. Hodí se pro nekritické kroky typu logování nebo notifikace.
• On Error: Continue (using error output) — chyba se předá dalšímu uzlu jako data. Tohle je přesně to, co chceš u AI agenta: místo aby celý běh spadl, dostane chyba tvou pozornost a můžeš na ni navěsit fallback.

Praktické pravidlo: Retry On Fail zapni na všech uzlech, které volají vnější svět (LLM, HTTP, databáze). U agenta samotného nastav Continue (using error output) a za něj dostav fallback větev — například Send Message uzel, který zákazníkovi napíše, že odpověď chvíli potrvá, a tobě pošle detail chyby.

Konkrétní postup pro agenta se záchrannou sítí

1. Otevři AI Agent node → záložka Settings.
2. Zapni Retry On Fail — přechodné chyby modelu se tak vyřeší samy.
3. Nastav On Error → Continue (using error output).
4. Z outputu chyby přived IF uzel: když chyba obsahuje rate_limit nebo timeout, počkej a zopakuj; jinak pošli notifikaci.
5. U modelového (LLM Chat Model) uzlu také zapni Retry On Fail — vyčerpaný rate limit bývá nejčastější příčina prvního pádu.

Error workflow: notifikace, která ti chodí dřív, než si stěžuje zákazník

Retry vyřeší přechodné chyby. Ale co chyby, které přetrvají? Pro ty má n8n dedikovaný mechanismus — error workflow. Podle dokumentace k error handlingu vytvoříš nový workflow, jehož prvním uzlem je Error Trigger. Ten se spustí vždy, když selže exekuce workflow, ke které je připojen.

Postup:

1. Vytvoř nový workflow, jako první uzel vlož Error Trigger.
2. Doplň akce: zpráva do Slacku nebo na Telegram s názvem workflow, časem a chybovou zprávou.
3. V hlavním workflow otevři Options → Settings → Error workflow a vyber svého error handlera.
4. Ulož. Od teď každá selhaná exekuce spustí notifikaci.

Klíčová vlastnost: jeden error workflow může obsluhovat více workflow. Vytvoř si centrálního error handlera pro celý projekt a připoj ho ke všem produkčním agentům. Chybová data, která Error Trigger přijímá, obsahují název workflow, exekuci i stack trace chyby — vše, co potřebuješ k rychlé diagnóze.

Pokud provozuješ self-hosted instanci, mrkni na návod na self-hosted n8n workflow bez zbytečných nákladů — error handler je ideální první krok k produkční hygieně.

Monitoring: sleduj, co agent dělá, než se to pokazí

Notifikace ti řekne, že něco spadlo. Monitoring ti řekne, že to začíná padat častěji. n8n nabízí několik vrstev:

Executions a Insights

V seznamu Executions vidíš každý běh — úspěšný i selhaný — a můžeš data z předchozí exekuce načíst přímo do editoru pro debugging. Dashboard Insights pak agreguje za každý workflow: celkový počet produkčních exekucí, počet selhaných, failure rate a průměrnou dobu běhu (viz dokumentace Insights). Pravidlo jednoduché: když failure rate agenta roste z 2 % na 10 %, něco se změnilo — nová verze modelu, změněné API nebo nafouknutá paměť — a ty to chceš vidět před tím, než to uvidí zákazník.

Health endpointy a metriky

U self-hosted instance máš k dispozici tři endpointy (viz monitoring n8n instance): /healthz ti vrátí 200, když instance běží; /healthz/readiness ověří i připojení k databázi; /metrics vystavuje metriky pro Prometheus. Napoj je na svůj oblíbený monitorovací nástroj nebo aspoň na jednoduchý cron, který kontroluje dostupnost instance.

Workflow nastavení má i přehlíženou lahůdku: Save execution progress. Když ho zapneš, n8n ukládá data po každém uzlu a při chybě se exekuce obnoví z místa, kde skončila — za cenu mírně vyšší latence. U dlouhých agentích běhů to znamená, že výpadek v polovině nezahodí celou práci.

Kontext a paměť: kde agent umírá pomalu

AI agent padá nejen náhle, ale i pomalu. Paměť konverzace roste, tokeny se sčítají a jednou přetečne kontextové okno modelu. Řešení:

• Omez window buffer memory — drž jen posledních N zpráv, ne celou historii.
• Sumarizuj místo archivace — starší část konverzace nech zpracovat levným modelem do shrnutí.
• Drž tool outputy krátké — když tool vrací tisíc řádků JSONu, řež je hned v uzlu, než se dostanou do kontextu agenta.

Toto téma má na aicku vlastní hlubší rozbor v článku o kontextovém inženýrství pro AI agenty — ovládání toho, co model vidí, je levnější než výměna modelu za silnější.

Zabezpeč agenta i proti sobě samému

Spolehlivost úzce souvisí s bezpečností. Agent, kterému věříš API klíče a databázi, dokáže napáchat škodu rychleji než jakýkoli bug. Nastav mu:

• Minimální oprávnění k datům (číst může, mazat ne).
• Timeout na úrovni workflow — ve Workflow Settings lze nastavit Timeout Workflow, po jehož uplynutí se běh ukončí. Zabrání tak nekonečným smyčkám.
• Sandbox pro akce s vedlejšími účinky. Jak na to popisuje návod na izolaci AI agenta v produkci.

Hlubší pohled na obranu proti zneužití promptu najdeš v článku Prompt injection: vrstvy obrany kolem AI agenta.

Kontrolní seznam před nasazením agenta do produkce

Než workflow aktivuješ, projdi těchto osm bodů:

1. Retry On Fail zapnutý na všech uzlech volajících externí služby.
2. On Error → Continue (using error output) na agentovi, s fallback větví.
3. Error workflow s Error Triggerem připojený ke všem produkčním workflow.
4. Insights sledované — failure rate pod 5 %, ideálně pod 2 %.
5. Timeout Workflow nastavený (zabrání nekonečným smyčkám).
6. Window buffer memory omezená, kontext pod kontrolou.
7. Minimální oprávnění pro credentials a databáze.
8. Health check instance napojený na monitoring.

Agent, kterým projde tento checklist, není neprůstřelný — ale když spadne, dozvíš se to ty jako první, zotaví se sám, kde to jde, a zbytek důkladně zaloguje. To je rozdíl mezi demo a produktem.

Časté otázky

Jak nastavím retry v n8n?

Otevři uzel, přepni na záložku Settings a zapni Retry On Fail. Uzel se pak při selhání opakuje, dokud neprojde nebo nedosáhne limitu pokusů. U AI agenta doplň ještě On Error → Continue (using error output), aby jedna chyba nezastavila celý workflow.

Co je error workflow v n8n?

Workflow, jehož prvním uzlem je Error Trigger. Připojí se k jinému workflow přes Workflow Settings a spustí se vždy, když exekuce selže — typicky pošle notifikaci do Slacku nebo na e-mail. Jeden error workflow může obsluhovat více workflow najednou.

Jak zjistím, že mi n8n workflow spadl?

Třemi způsoby: notifikace z error workflow (aktivní upozornění), seznam Executions v editoru (dohled) a dashboard Insights s failure rate pro každý workflow (trend). U self-hosted instance doplň health endpointy /healthz a /metrics pro sledování dostupnosti instance.

Proč AI agent v n8n padá častěji než běžný workflow?

Protože se v jedné exekuci spouští vícekrát — při rozhodování, volání toolů a vyhodnocování odpovědí. Každý běh závisí na dostupnosti LLM API, externích služeb a omezené paměti kontextu. Více pohyblivých částí znamená více míst, kde může dojít k chybě.

Stojí monitoring a error handling za tu práci u malého projektu?

Ano, hlavně proto, že nastavení zabere půl hodiny a platí napořád. Error workflow je jeden uzel plus notifikace, Retry On Fail jsou dvě kliknutí. Nejdražší varianta je zjistit po týdnu, že agent tiše nepobíral e-maily a nikdo si toho nevšiml.