Connector counts stop mattering the moment a model decides what happens next. Where each platform actually breaks — the loop, the resume, the token bill — and the one rule we use to pick.
The Zap wasn't broken. Five steps, a 200 on every one, and it still routed a $14,200 invoice to auto-approve against a PO that didn't exist. Step 2 looked the vendor up in NetSuite. Step 4 asked a model to approve-or-flag. They were separate Zaps joined by a webhook, so by the time the model ran, everything step 2 learned was gone and it was reasoning from a subject line. Nobody misconfigured anything. The platform just has nowhere to put a loop.
Most n8n vs Zapier posts are a connector count and a price-per-task table. Fine answer in 2021, when automation meant new Airtable row, post to Slack. It predicts nothing once a model is choosing the next step. We've shipped agent workflows on both, and the deciding factor was never connectors — it was whether one run can loop over tool calls, run code between them, and resume three days later still holding its context.
A Zap is a directed line: trigger, steps, paths for branching. Zapier's agent features let a model pick an action, but the loop isn't yours. You can't say "keep calling tools until the vendor is identified, cap it at six iterations, then escalate." n8n's AI Agent node runs that ReAct loop inside one execution — tools hang off it as sub-nodes, an entire sub-workflow can be a single callable tool, and the scratchpad from iteration one is still there at iteration five.
Back to that invoice: three tool calls inside one decision — parse line items from the PDF, look the vendor up in Postgres, check NetSuite for an open PO. In n8n that's one agent node, three tools, and a Code node that normalizes the vendor string first, so "ACME CORP.", "Acme Corporation" and "ACIVIE CORP" (OCR eats the M) all resolve through one pg_trgm query. No model should be doing fuzzy matching a trigram index does for free. In Zapier it's three Zaps stitched by webhooks, hand-serializing the reasoning trace between hops — a loop rebuilt out of straight lines, billed per segment.
Agent runs fail in ways deterministic automations don't. Three we hit constantly: a 429 from the provider mid-loop, a tool that returns a fenced ```json block and blows up the parser, and a human who takes two days to approve. n8n answers each — a Wait node that parks an execution for days on a resume webhook, an error workflow that catches the failure with the triggering payload attached, and re-run-from-node with the exact data that broke it. Zapier's replay restarts the task from the trigger.
The n8n trap: re-running from a failed node cheerfully re-fires side effects. We watched one issue a second Stripe refund because the crash landed between the refund call and the ledger write — $2,800 out the door twice. The fix is boring and non-negotiable. Hash a deterministic key per run (invoice ID plus action), write it to Postgres before the side effect, and have every write-capable tool check it first. Stripe's idempotency header covers Stripe and nothing else your agent touches. Do this at fifty runs a day, not after the incident.
Zapier bills per task and every model step is a task — a six-tool-call agent is seven tasks before it's useful, so 1,000 runs a day is 7,000 tasks. Self-hosted n8n has no execution meter, which is why agencies love it, but you're running Postgres, Redis, and workers, and someone owns that pager. Both bills are rounding errors next to the model provider's.
The lever that moves the number is what your tools return. We took a support triage agent from ~11k tokens per run to ~2.6k with one change: the ticket tool stopped returning the whole Zendesk object and returned three fields — subject, last customer message, plan tier. The model never used the other forty, it just paid to read them on every iteration, and the loop ran three or four times. At $3 per million input tokens and 1,000 runs a day, that trim is roughly $750 a month, on either platform. Filter in code before the model sees anything.
If the workflow belongs to an ops lead who needs to change it without filing a ticket, Zapier wins and it isn't close. Same if you need the long tail of connectors nobody wants to write OAuth for, or you're eight people with a SOC 2 questionnaire due Friday. One model call that drafts a reply or classifies an email inside a five-step process is a good Zap and a bad reason to self-host.
Price the n8n side honestly. Community nodes break on minor upgrades and you find out in production. Execution data grows until someone sets EXECUTIONS_DATA_PRUNE and a max age — we've inherited instances sitting on 40GB of execution JSON and a Postgres volume nearly out of disk. Queue mode means EXECUTIONS_MODE=queue, Redis, and separate workers: a deployment, not a docker run. n8n Cloud drops most of that and keeps the agent loop.
More than two tool calls per decision, code between the calls, or data that can't leave the VPC: n8n. One model call inside a linear process that non-engineers will edit: Zapier, and we stop arguing. Past a few thousand agent runs a month, per-task pricing stops competing with a $40 container.
The move that makes the decision cheap to reverse: don't build the agent's tools inside the automation platform. Ship them as an HTTP service or an MCP server you own — versioned schema, real tests, with the vendor matcher, the idempotency table, and the trimmed payloads in code. Then n8n or Zapier is only the dumb thing that calls them. We've moved clients between platforms over a weekend that way. The teams who built everything on the canvas rewrote from scratch.
A software studio that ships and maintains its own products — KeepChats, Gwora and MoveProof — and builds the same way for clients. Founded and led by codewithumar.
Talk to the studio →Send the problem. You get one fixed number and a plan back within a business day.
We build software worth keeping — for clients, and for ourselves.
Founded & led by codewithumar