TL;DR: n8n is a solid orchestration layer for AI agents — but most tutorials show toy examples with a single Claude API call. This covers three patterns we actually run in production: a multi-source research pipeline, a scheduled content bot, and a webhook-triggered classification agent. Each has a workflow ID you can inspect and real timing data.
At a glance
- Research Agent v2 (workflow O8qrPplnuQkcp5H6) runs daily at 06:00 Kyiv, processes 40+ URLs in 87-second median runtime
- n8n 1.35 introduced native AI Agent nodes — useful for simple chains, limited for conditional branching
- Webhook-triggered agents: median first-response 1.2 seconds; scheduled triggers add 0–30s cron lag
- Claude API HTTP Request node requires
x-api-keyheader — n8n’s built-in “Anthropic” credential type adds it automatically since n8n 1.31 - Parallel branch execution in n8n uses the Merge node — race conditions are real (see Deep Dive below)
- Error Trigger workflow catches all failures and routes to Telegram topic #8 in under 2 minutes
- PostgreSQL node needs
ssl: "disable"(string, not boolean) for localhost connections in n8n 1.35+
Q: What does a production research pipeline look like in n8n?
Our Research Agent v2 (workflow ID: O8qrPplnuQkcp5H6) runs every morning at 06:00 Kyiv time. It starts with a Schedule Trigger, pulls a list of target URLs from a PostgreSQL research_sources table, uses an HTTP Request node to fetch each page, passes the HTML through a Code node that strips tags and truncates to 3,000 tokens, then calls Claude API to extract structured insights.
The workflow has three parallel branches after the source fetch: one for content extraction, one for metadata (published date, author), and one for a relevance score check. All three merge into a single aggregation node before the final Claude synthesis call. Total runtime: 87 seconds median, 140 seconds 95th percentile on 40 sources.
Key config detail: the HTTP Request node calling Claude uses Continue on Fail enabled, so a single failed source doesn’t abort the entire run. Failed URLs are logged to a research_errors table for manual review.
Q: How do you build a scheduled content bot that doesn’t spam?
Our @FL_content_bot Telegram bot (n8n workflow, active since March 2026) generates and schedules 3 posts per week. The Schedule Trigger fires Monday/Wednesday/Friday at 09:00. A PostgreSQL read node checks a content_queue table — if nothing is queued, the workflow exits early via an IF node. This prevents duplicate posts if we manually queue items.
The Claude API call uses a system prompt stored in the database (not hardcoded in the node), which means we can update tone or style without touching the workflow. The response goes through a Code node that validates JSON structure — if Claude returns malformed JSON, the node logs the raw response and returns null, which the downstream IF node catches and routes to an error handler.
One non-obvious issue we hit in May 2026: n8n’s Split in Batches node resets $runIndex to 0 on each batch, not across the full run. If you’re using $runIndex to select a different prompt template per post, you’ll get the same template every time. Fix: use a counter stored in PostgreSQL and increment it in a Code node.
Q: How do webhook-triggered AI agents differ from scheduled ones?
Webhook agents respond to external events — a user submits a form, a Stripe payment lands, a GitHub PR is opened. The n8n webhook URL receives the POST, and the workflow runs immediately. Response latency is 1.2 seconds median (mostly Claude API time). Scheduled workflows have 0–30 second cron lag depending on when the trigger fires.
We use webhook-triggered classification in our lead scoring pipeline: an incoming contact form POST triggers an n8n webhook, Claude classifies the lead intent into one of 5 categories (enterprise/SMB/freelancer/student/spam), and the result writes to PostgreSQL. Total round-trip: 2.1 seconds including DB write.
The catch: webhook workflows must be active (not just saved). Test webhooks only work when the workflow editor is open. Production webhooks use the path https://n8n.docsentry.services/webhook/{path} — not /webhook-test/. We’ve broken this distinction three times by forgetting to activate after a workflow edit.
Deep dive: The Merge node race condition every n8n AI developer hits
When you run parallel branches in n8n (multiple nodes processing simultaneously, merging at a Merge node), you will eventually hit this: the Merge node fires before all branches complete. This happens because n8n’s execution model processes branches as they finish, and the Merge node can trigger when the first branch completes if not configured correctly.
The correct Merge mode for AI pipelines is “Merge by Index” or “Wait for All Inputs” (n8n 1.30+). The default “Append” mode merges as soon as any input arrives. We learned this in production when our Research Agent started producing half-empty reports — the Claude synthesis branch was running with only 60% of the source data because the Merge node fired too early.
According to Anthropic’s n8n integration docs (updated February 2026), the recommended pattern for parallel Claude calls is: fan out with a Split node, run Claude calls in each branch, merge with “Wait for All Inputs” mode, then run the final aggregation. This adds ~200ms overhead but guarantees all data is present.
A related issue: the Code node in n8n can reference upstream nodes by name using $('Node Name').first().json. If that node hasn’t executed yet (race condition in parallel branches), n8n throws Cannot read properties of undefined. The fix is a try/catch:
let data;
try {
data = $('Upstream Node').first().json;
} catch(e) {
return []; // signal upstream not ready
}We applied exactly this fix to our FF Daily Token Report workflow in May 2026 after the Build Report Code node started returning empty objects intermittently. The try/catch solution has been stable since.
The n8n community forum (1.2M+ members as of Q1 2026) has extensive discussion on this pattern — search “parallel branch merge Code node undefined” for 50+ threads on the same root cause.
Key takeaways
- Research Agent v2 (O8qrPplnuQkcp5H6) processes 40+ sources in 87s using parallel branches + Claude synthesis
- Merge node must use “Wait for All Inputs” mode — default “Append” causes race conditions in AI pipelines
- Webhook agents respond in 1.2s median; scheduled triggers add up to 30s cron lag
- Store Claude system prompts in PostgreSQL, not hardcoded in nodes — enables runtime updates without workflow edits
ssl: "disable"(string) required for localhost Postgres connections in n8n 1.35+
FAQ
Q: Can n8n AI agents handle rate limits from Claude API automatically?
Not natively. Add a Wait node (30–60 seconds) before the Claude HTTP Request node, and use an IF node to detect 429 status codes and retry. n8n’s built-in “Retry on Fail” (Settings tab) works for transient errors but doesn’t respect Retry-After headers — manual wait nodes are more reliable.
Q: What’s the best way to pass large documents to Claude through n8n?
Chunk the document in a Code node before sending it to Claude. We chunk at 3,000 tokens (roughly 2,200 words) using a simple character-count split. Store chunks in a PostgreSQL table with a run_id, then loop through with a Split in Batches node. This avoids the 100KB n8n item limit and gives you per-chunk error recovery.
About the author
Sergii Muliarchuk — founder of FlipFactory.it.com. Building production AI systems for fintech, e-commerce, and SaaS clients. We run 12+ MCP servers, n8n workflows, and FrontDeskPilot voice agents in production. Our Research Agent v2 and content automation workflows handle daily AI-powered operations — every pattern in this guide came from real n8n incidents.