A Zapier-to-agent migration goes wrong in a predictable way: someone reads that agents are the future, points one at the busiest zap in the account, and discovers three weeks later that a workflow which used to fail loudly now fails quietly and creatively. The fix is not better prompting. It is migrating on criteria — branching depth, exception rate, and how much genuine data judgment a step needs — and accepting that a large share of your automations should stay exactly as they are.
Both platform vendors have made the move easy to start. Zapier markets Agents as “superhuman teammates” that work across 9,000+ apps, equipped with company knowledge and built-in monitoring, and ships a Copilot assistant so you can describe an agent in a prompt rather than build it node by node. n8n exposes an AI Agent node that takes a chat model plus tool sub-nodes and decides for itself which tool to call. Neither vendor has much incentive to tell you which of your existing workflows should be left alone.
This playbook covers the part the comparison genre skips. Where the workflow-versus-agent line actually sits according to the people building the frameworks, a scoring rubric you can run against your own automation inventory, a primitive-by-primitive translation map from classic automation concepts to agent-framework concepts, the strangler pattern as the cutover method, unit economics with the billing-unit trap made explicit, and the categories of zap that should never become agents at all.
- 01Migrate on criteria, not on category.Branching depth, exception rate, and data-judgment requirement are the three tests. An automation that scores low on all three is a workflow forever, no matter how fashionable agents get.
- 02The vendors’ own guidance says start simple.Anthropic’s engineering guidance recommends beginning with the simplest workflow pattern and escalating to a full agent only when the simpler pattern demonstrably falls short — the opposite of agent-first migration.
- 03Use the strangler pattern, not a rewrite.Run the agent alongside the live zap, intercept a slice of traffic, compare outcomes, widen the slice. Martin Fowler’s argument against big-bang rewrites applies to automation exactly as it applies to legacy systems.
- 04Branch coverage stops being enumerable.A router has a countable number of paths. A model-directed agent does not. The moment you migrate, “we tested every path” becomes a sentence nobody on the team can honestly say — so testing has to move to sampling.
- 05Some zaps should never move — permanently.High-volume batch operations, strictly repeatable processes, and compliance-critical steps belong on deterministic workflows. That is not caution; it is the recommendation of both the framework guidance and a 2026 practitioner guide.
01 — Where the line sitsA workflow follows your path. An agent picks its own.
The most useful definition of the boundary does not come from an automation vendor. It comes from Anthropic’s engineering guidance on building effective agents, and it is a definition about control structure rather than about capability. A workflow is a system where models and tools are orchestrated through predefined code paths. An agent is a system where the model directs its own process and its own tool usage. Both can call an LLM. Only one of them decides what happens next.
That distinction is what makes the migration question tractable. You are not asking “is this automation smart enough to deserve AI.” You are asking a much narrower question: does the sequence of steps need to be decided at runtime, by something that can read the input, rather than at design time by you? If the answer is no, adding a model to the middle of the workflow may still be valuable — but that is an AI step inside a workflow, not an agent, and it should be built and budgeted as such.
Anthropic is equally explicit about when agents earn their complexity: open-ended problems where it is difficult or impossible to predict the required number of steps, and where you cannot hardcode a fixed path. Read that as a filter rather than an invitation. If you can draw your automation on a whiteboard as a finite set of boxes and arrows and be confident the drawing is complete, you have just demonstrated that it is not an agent candidate.
n8n’s own documentation describes the same shape from the implementation side. Its AI Agent node has three parts — a chat model that interprets the request, tool sub-nodes that expose external actions and data, and agent logic that decides which tool to use depending on the task. The node will not run at all without at least one tool sub-node connected, which is a small implementation detail with a large conceptual implication: an agent without tools is just a chat completion. As of n8n v1.82.0 the earlier menu of separate agent-type configurations was retired, and all AI Agent nodes work exclusively as the “Tools Agent” type.
If you want the platform-level feature tour rather than the migration method, we covered what AI Actions actually do inside a Zap in a dedicated guide — that post is the feature explainer for natural-language Zap creation, while this one is strictly about which existing automations to move and how. For the broader n8n side of the same question, see n8n’s wider AI node catalog.
02 — The three criteriaScore every automation on three axes before you touch it.
The rubric below is ours, but it is derived directly from the published guidance rather than invented: branching depth operationalises Anthropic’s “can you hardcode a fixed path” test, exception rate operationalises the predictability test, and data-judgment requirement operationalises the model-driven decision-making test. Score each automation on all three before it enters any migration queue. Two low scores and one high score is almost always an argument for an AI step inside a workflow rather than a full agent.
Branching depth
Draw the automation as a decision tree and count the leaves. If the count is finite, stable, and you are confident the drawing is complete, a router is the correct primitive and always will be. If new leaves keep appearing every month because reality keeps producing inputs you did not anticipate, you have found the first real agent signal.
Exception rate
Pull the last quarter of run history and count how many executions ended with somebody manually correcting the outcome. A low single-digit exception rate means the deterministic logic is fitting the domain well. A rate high enough that a person is effectively in the loop by default means you are already paying for judgment — the question is only whether a model can do part of it.
Data judgment
Ask what the step reads. Structured fields from a known schema is none. Reading a short free-text field to pick one of a handful of labels is light. Reading an unstructured document, weighing conflicting signals and producing a decision a person could disagree with is heavy. Heavy judgment is the only one of the three that a deterministic workflow genuinely cannot fake.
The reason to score all three rather than trusting any one of them is that they fail differently. Branching depth on its own overstates the case for migration, because a workflow with many branches may simply be a workflow that needs refactoring. Exception rate on its own can be a symptom of bad upstream data rather than of missing judgment; if half your exceptions are duplicate records, an agent will confidently process duplicates too. Data judgment on its own understates urgency, because a genuinely hard judgment call that fires four times a month does not justify a new runtime.
One warning about how this rubric gets abused in practice. It is tempting to run the scoring exercise on the automation you find most annoying, which is usually the one that breaks most often. Breakage frequency is not one of the three axes. A brittle zap that breaks weekly because an upstream API changes its schema will break exactly as often once an agent is calling that API — and the agent will be worse at telling you it happened, because a failed tool call inside a reasoning loop can be silently routed around rather than raised.
03 — Decision matrixThe migration decision matrix, scored.
Below is the rubric applied to nine automation shapes that show up in almost every marketing and operations stack. The rows are generic automation types, not client work — no organisation is named or described. The three verdict groups are the only outputs the rubric produces: keep it deterministic, wrap an agent step inside a deterministic shell, or run a strangler pilot with a human in the loop before any cutover.
| Automation type | Branching depth | Exception rate | Data judgment | Compliance sensitivity |
|---|---|---|---|---|
| Verdict: keep it deterministic — permanently | ||||
| Nightly data sync or batch export | Low — one path | Very low | None | Medium — the audit trail is the deliverable |
| Invoice approval above a fixed threshold | Low — one condition | Low | None — the threshold is the rule | High — finance controls |
| Three-branch lead routing by region | Medium — three fixed paths | Low | None | Low |
| Weekly report assembly from fixed dashboards | Low | Low | None | Low |
| Verdict: hybrid — an agent step inside a deterministic shell | ||||
| Field extraction from mixed-format documents | Low path count, unbounded input variance | High | Heavy | High — keep the deterministic wrapper for the audit trail |
| Inbound email classification into a fixed taxonomy | Medium | Medium | Light | Low |
| Verdict: strangler pilot, human in the loop before cutover | ||||
| Support ticket triage from free-text intake | High — hard to enumerate | High | Heavy | Low |
| Refund decisions read from a customer narrative | High | High | Heavy | High — human sign-off stays after cutover |
| Multi-source lead enrichment and dedupe | Medium | Medium | Light to heavy, depending on sources | Low |
Two patterns are worth reading off the table. The first is that compliance sensitivity never argues for migration and frequently argues against it — the invoice-approval row scores low on every capability axis and high on compliance, which is the clearest possible “leave it alone.” The second is that the hybrid verdict is not a compromise. Document field extraction genuinely needs model judgment in one step and genuinely needs a deterministic, logged shell around that step. Building it as a full agent throws away the audit trail to gain flexibility the automation does not need.
The refund row is the one that trips teams up. It scores as a migration candidate on all three capability axes, which reads like permission to automate the decision. It is not. High compliance sensitivity plus heavy judgment is the profile where a strangler pilot should run for a long time and where the human sign-off step survives the cutover permanently. The agent’s job in that shape is to prepare the decision, not to make it.
04 — Translation mapEvery automation primitive has an agent equivalent, and a new failure mode.
The mechanical part of a migration is a translation exercise. Classic automation tools give you a small vocabulary — triggers, action steps, filters, routers, formatters, delays, webhooks, multi-step workflows — and every one of those has a recognisable counterpart in agent-framework terms. What the mapping tables in vendor documentation tend to leave out is the third column: what actually changes about your operational risk when you make the swap.
| Classic primitive | Agent-framework equivalent | What actually changes | New failure mode |
|---|---|---|---|
| Entry points | |||
| Trigger | Event that starts an agent run | Nothing. The start of the run stays deterministic — agents do not fire themselves. | Teams assume the agent is “always on” and build no scheduler at all |
| Webhook | Inbound event, plus a tool definition for anything the agent calls back through | Payload validation moves to the front, because the model now reads the payload as input | Unvalidated third-party payloads become prompt content |
| Control flow | |||
| Filter or condition | Judgment step with an explicit confidence threshold | You now own a false-positive and false-negative rate that used to be structurally zero | No threshold is set, so the agent silently drops work nobody counts |
| Path or router | Model-directed tool choice — the agent decides which tool to call | Branch coverage stops being enumerable; you test by sampling rather than by counting | “We tested every path” becomes a claim nobody can honestly make |
| Delay or schedule | Asynchronous wait or poll inside the agent loop | A wait becomes state you have to persist and resume, not a timer the platform owns | Runs die mid-wait and nothing retries them |
| Actions and output | |||
| Action step | Tool call | The model chooses the arguments, so schema design and argument validation move to the front of the build | Well-formed calls carrying wrong arguments, which log as successes |
| Formatter | Structured output contract | Output shape becomes a validation problem rather than a formatting one | Downstream systems accept malformed records without complaining |
| Multi-step workflow | Multi-step agent loop with an explicit step budget | Step count becomes a distribution rather than a constant, so cost per run becomes a distribution too | Unbounded loops, and a bill that varies by input rather than by volume |
The router row is the one that changes how a team works, not just how a workflow runs. n8n’s documentation puts it plainly — the agent decides which tools to call to complete a task — and that single sentence deletes an entire category of quality assurance. With a router, test coverage is a counting exercise: enumerate the paths, exercise each one, sign off. With model-directed branching there is no finite list to exercise, so coverage becomes statistical. Migrating a router without also migrating the test strategy is the most common way a technically successful migration produces an operationally worse system.
The multi-step row is the one that changes the finance conversation. A classic workflow has a fixed step count, so cost per run is a constant and monthly spend is a straight function of volume. An agent loop decides how many steps it needs, so cost per run has a mean and a tail. Budget on the tail, not the mean, and put a hard step budget on every loop. If you want the full economics worked through rather than the shape of the problem, we built the total-cost-of-ownership math as a separate piece.
05 — Cutover methodThe strangler pattern, borrowed from legacy system replacement.
The safest known method for replacing a system you cannot afford to break is not a rewrite. It is the Strangler Fig pattern, named and popularised by Martin Fowler: build the new functionality alongside the old system and let it gradually intercept more of the old system’s behaviour until the legacy path can be retired. Fowler’s argument against the alternative is direct — complete rewrites typically fail because they take years to complete while business needs change, and because hidden behavioural requirements are difficult to replicate.
Both halves of that argument transfer to automation without modification. Automation stacks accumulate hidden behavioural requirements at an impressive rate: the filter that quietly excludes a legacy record type, the formatter step that trims a field because a downstream system chokes on long strings, the delay that exists because someone discovered a race condition in 2023. Nobody documented any of it. A rewrite discovers all of it in production.
"Like the fig, it begins with small additions...that are built on top of, yet separate to the legacy code base."— Martin Fowler, StranglerFigApplication
Fowler’s method has four moves: establish clear desired outcomes, identify the seams in the legacy system that let you break it into replaceable components, incrementally replace small pieces while the old system keeps running, and evolve organisational practice alongside the technical change. The automation-specific translation of those four moves is below.
Name the outcome
Write down what the agent must beat, in numbers you already have. Current exception rate, current median handling time, current cost per run. If you cannot state the baseline from existing run history, you are not ready to migrate — you are ready to instrument.
Find the seam
The seam is the narrowest place the agent can intercept: usually a single judgment step in the middle, not the trigger and not the final write. Intercepting at the write step is tempting because it is where the value lands, and dangerous for exactly the same reason.
Run both
Start in shadow mode: the agent processes the same input and writes its answer somewhere nobody acts on, while the zap continues to run production. Compare disagreements by hand. Only when disagreements are rare and explainable does the agent take a real traffic slice.
Retire deliberately
The legacy zap comes down only when the agent has held the slice through at least one full cycle of whatever seasonality your data has. Fowler’s fourth move matters here: the review process, the on-call expectation and the escalation path all change, and none of that happens by itself.
Shadow mode is the phase teams skip and the phase that pays for itself. Running the agent against live input with no authority to act costs you inference spend and nothing else, and it produces the single most valuable artefact of the whole migration: a list of the cases where the agent and the existing logic disagree. In our experience that list is rarely what anyone predicted. It usually splits into a small set of cases where the agent is obviously right, a small set where it is obviously wrong, and a frustrating middle where the disagreement reveals that the original zap encoded a rule nobody remembers agreeing to.
That middle set is the actual product of the migration. Whatever you decide about the agent, the discovery that a production automation has been silently applying an undocumented rule is worth the exercise on its own.
06 — The exclusionsThe zaps that should never become agents.
Vendor content has a structural reason to push every workflow toward the agent product: agent tiers are metered separately and generate revenue on a different curve. The published engineering guidance points the other way. Anthropic’s overarching principle is to start with the simplest workflow pattern — prompt chaining, routing, parallelisation — and escalate to a full agent only when the simpler pattern demonstrably falls short. A 2026 practitioner guide to n8n’s AI Agent node, published in February by the developer writing as kr8thor on dev.to, reaches the same conclusion from the implementation side: keep predictable repeatable processes, high-volume batch operations and strict compliance requirements on traditional deterministic workflows, and reserve agents for variable input requiring judgment, multi-step research, and decision trees too complex to hardcode.
High-volume batch operations
Ten thousand records processed identically is the shape deterministic workflows were built for. An agent adds per-record inference cost, per-record latency and per-record variance to a job whose entire value is that it does the same thing every time.
Compliance-critical steps
Where you have to be able to say exactly why a decision was made and reproduce it on demand, predefined code paths are not a limitation — they are the requirement. Model-directed branching cannot offer the same reproducibility guarantee.
Judgment in one step only
Document extraction, sentiment-dependent routing, free-text classification into a fixed taxonomy. Put the model inside the step that needs judgment and keep the deterministic shell — trigger, validation, write, logging — around it.
Unbounded step count
Multi-step research, investigation-style tasks, anything where the required number of steps depends on what the earlier steps found. This is the shape the framework guidance names explicitly, and the one place a full agent is straightforwardly the right tool.
There is a trend worth reading in the fact that both the framework authors and that practitioner guide landed on a restraint-first position while the product marketing moved the other way. Zapier ships a Copilot assistant specifically so users can construct Agents from a prompt rather than build them node by node, which is a reasonable on-ramp and also a signal about where the vendor believes growth comes from. The gap between “easiest thing to start” and “right thing to run” is where migration projects get expensive.
Projecting forward, the likely equilibrium is not agents replacing workflow automation but agents becoming a step type inside it. The hybrid row above is the shape that keeps winning on the criteria: a deterministic shell that owns triggering, validation, logging and writes, with model judgment invoked in the one or two places judgment is genuinely required. Teams that structure their migration around that assumption tend to end up with fewer surprises than teams that treat the agent as the new runtime for everything.
07 — Unit economicsWhat the swap costs — and the billing-unit trap.
Every figure in this section is labelled by the surface it was read from at the time of writing, and automation pricing moves — treat these as a snapshot for sizing, not as a quote. The important thing is not any individual number. It is that Zapier and n8n bill in units that are not interchangeable, so the two published price lists cannot be compared directly no matter how tempting the arithmetic looks.
Free-plan task ceiling
The free tier allows 100 tasks per month and two-step Zaps only, which means no branching automation is possible at all on Free. Embedding AI directly in a Zap via AI by Zapier requires the Professional tier or higher.
Free agent activities
Zapier Agents is metered separately from Zap tasks, with a free allowance of 400 activities per month and a paid tier above it. The paid figure on the published page reads as an annual-equivalent monthly rate — check the live pricing page before budgeting.
Execution = one full workflow run
n8n defines one execution as a single run of the entire workflow regardless of step count, and contrasts that explicitly with per-operation billing. Self-hosted deployments use your own model API key, so the Cloud AI-credit ceiling does not apply.
n8n Cloud · included executions per month by tier
Source: n8n published pricing page, read at the time of writing. Bars scaled against the Business tier allowance.The derived column in the table below is our arithmetic, not a vendor figure: published monthly price divided by the included unit allowance for that plan. It is useful for sizing a single plan and useless for comparing across the two vendors, because a Zapier task counts an individual action step while an n8n execution counts a complete workflow run. A Zap with five action steps consumes five tasks; a five-step n8n workflow consumes one execution. The prices are also quoted in different currencies on each vendor’s own page, and no conversion is implied or applied here.
| Plan (as published) | Price | Included units | Unit type | Derived cost per unit |
|---|---|---|---|---|
| Zapier — billed per task (one action step) | ||||
| Free | $0 | 100 / mo | Task · two-step Zaps only | Not derived — no branching available |
| Professional — entry | $19.99 / mo, annual | 750 / mo | Task | ≈ $0.0267 |
| Professional — top of published range | $3,389 / mo, annual | 2,000,000 / mo | Task | ≈ $0.0017 |
| Team — entry | $69 / mo, annual | 2,000 / mo | Task · up to 25 users · SAML SSO | ≈ $0.0345 |
| Team — top of published range | $3,999 / mo | 2,000,000 / mo | Task | ≈ $0.0020 |
| Agents — free allowance | $0 | 400 / mo | Activity · separate meter | Not derived |
| n8n Cloud — billed per execution (one full workflow run) | ||||
| Cloud Starter | €20 / mo | 2,500 / mo | Execution · 5 concurrent | ≈ €0.0080 |
| Cloud Pro | €50 / mo | 10,000 / mo | Execution · 20 concurrent | ≈ €0.0050 |
| Cloud Business | €667 / mo | 40,000 / mo | Execution · self-host option · SSO/SAML/LDAP | ≈ €0.0167 |
| Self-hosted | Your own infrastructure | No AI-credit ceiling — bring your own model API key | Execution | Not comparable |
The n8n rows contain a result that surprises people the first time they compute it. Cost per included execution falls from roughly €0.0080 on Starter to roughly €0.0050 on Pro, then rises to roughly €0.0167 on Business. Business is not a volume discount tier at all — the €667 buys the self-hosting option, SSO/SAML/LDAP and 30-day insight retention, and the execution allowance is close to incidental. If you are moving to Business for throughput you are buying the wrong thing; if you are moving for governance you are buying exactly the right thing and the per-execution number is irrelevant.
The other cost that does not appear on either page is inference. On n8n Cloud, model usage is metered as AI credits — 2,300 a month on Starter, up to 13,700 on Pro — while self-hosted deployments use your own model API key and have no credit ceiling, which shifts the cost from the platform bill to the model provider bill rather than removing it. Zapier’s Agents meter counts activities on its own tier. Either way, migrating a step from deterministic logic to model judgment converts a fixed platform cost into a variable one that scales with input complexity, not just with volume. For worked comparisons across the wider tool set, see our real-world cost comparisons and the marketing-automation landscape.
08 — Rollback safetyPlan the reverse before you plan the cutover.
A strangler migration only de-risks anything if the legacy path is genuinely still there. The failure mode is subtle: teams keep the old zap enabled but let it drift — a field gets renamed in the CRM, an API version is deprecated, a credential expires — so when the agent misbehaves in month three the rollback target no longer runs. The old path is not a backup unless something proves it still works. The cheapest proof is to keep it processing a small live slice throughout the pilot rather than switching it off entirely.
The second rollback requirement is a decision log. Deterministic workflows are self-documenting because the logic is the documentation; agents are not, and a run history that records only inputs and final outputs cannot tell you why a decision was made. Log the tool calls, the arguments, and the intermediate reasoning your framework exposes. This is precisely the visibility gap OpenAI named when it introduced its Responses API and Agents SDK: turning model capability into production-ready agents had required extensive prompt iteration and custom orchestration logic without sufficient visibility, and built-in tracing was the answer it shipped. If your chosen stack does not give you that, you are inheriting the problem rather than the solution.
The first month after a cutover should have a defined shape. Week one: every agent decision reviewed, no exceptions, however tedious. Week two: review a sample, and review every case where the agent took a path the old zap would not have taken. Weeks three and four: review by exception only, but keep the disagreement log running against the shadow copy of the old logic. Set an explicit rollback trigger before week one starts — a disagreement rate, an error rate, a cost-per-run ceiling — and write down who is allowed to pull it without convening a meeting.
One organisational note that matters more than any of the technical steps. The person who built the original zap is usually not the person championing the agent, and the original builder is the only one who knows about the undocumented rules in section 05. Getting them into the shadow-mode disagreement review is worth more than any amount of prompt engineering. If you are running this as a structured programme rather than a side project, our CRM and marketing automation engagements start with exactly this inventory-and-score exercise, and our AI transformation work covers the governance layer around it. For teams weighing whether to self-host the agent runtime at all, we covered the open-source and self-hosting decision separately.
09 — ConclusionMigrate the few, instrument the rest.
The right number of zaps to migrate is smaller than the number you want to migrate.
Run your automation inventory through three questions — how deep is the branching, how often does a human have to intervene, how much genuine judgment does the hardest step require — and the queue sorts itself. Most automations score low on all three and should be left alone. A meaningful minority need model judgment in exactly one step, and belong in a hybrid shape: an agent step inside a deterministic shell that still owns triggering, validation, logging and writes.
For the handful that genuinely need model-directed control flow, the method is old and well tested. Baseline the outcome in numbers you already have, find the narrowest seam, run the agent in shadow against live input until the disagreements are rare and explainable, take a traffic slice, and retire the legacy path only after a full cycle of whatever seasonality your data has. Fowler’s case against big-bang rewrites — years of work while requirements move, hidden behaviour nobody can reproduce — describes an automation stack as accurately as it describes a monolith.
The part worth carrying forward is the discipline, not the tooling. Model-directed branching trades enumerable test coverage for flexibility, fixed per-run cost for a distribution, and self-documenting logic for whatever your framework happens to trace. Those are reasonable trades for automations that genuinely cannot be drawn as a finite set of boxes and arrows. They are terrible trades for the nightly export. Knowing which of your automations is which is the whole job.