Do not replace your workflow engine. Replace one step inside it. The teams rebuilding deterministic automations as agents in 2026 keep reaching for a new visual builder with an "AI Agent" node in the palette, and that is the wrong shape of decision. The engine was never the problem. The problem is that one step in the middle now takes a variable number of actions, decided at runtime by a model, and almost every automation platform on the market bills you per action and retries per action.
If you are already on n8n, self-host it, keep the agent inside a sub-workflow, and put the steps that move money behind Temporal or Inngest. If you are on Zapier and the workflow is genuinely agentic, you are on the wrong platform — not because the product is bad, but because Zapier Agents includes 1,500 activities a month on Pro and caps a single run at 40 activities, per Zapier's own usage documentation. That is 37 runs a month if every run hits the ceiling — and the same document's worked examples consume 3 to 7 activities apiece, which puts a realistic figure nearer 215 to 375 runs. Either way it is a prototyping budget, not a production one, and the ceiling is the number to plan against because an agent decides for itself which end of that range it lands on.
| Platform | You pay per | Self-host | Secrets scoped per step | Don't pick it if |
|---|---|---|---|---|
| n8n | One execution per run, any number of steps | Yes, Sustainable Use Licence | Enterprise licence only | You need a failed tool to fail the run |
| Zapier | Successful task, plus a second "activities" meter for Agents | No | No | Data cannot sit in the US |
| Make | One credit per module action | No | No | The model decides the step count |
| Temporal | Per action | Yes, open source | You bring your own vault | Nobody on the team writes code |
| Inngest | Per step execution | Yes, open source | You bring your own | You need a visual builder |
| Windmill | Seats plus workers; executions unmetered | Yes, AGPLv3 | Yes — path-scoped, decrypt is audited | You want 9,000 prebuilt connectors |
| LangGraph Platform | Seats plus compute and storage units | Enterprise plan only | Via your own deployment | Forecastable cost beats tracing depth |
| Activepieces | One credit per whole run, plus 2-20 per AI step unless you bring your own key | Yes, MIT except packages/ee |
Enterprise tiers | You need a mature support story |
Every price below was read from the vendor's live pricing page on 7 September 2026. These pages change; re-check before you sign anything.
The Reference Workload, So the Numbers Mean Something
Comparison pages cheat by quoting each vendor's favourite metric. Here is one workload, held constant: a refund-triage automation, 50,000 runs a month, eight steps of which two are model calls at roughly 6,000 input and 800 output tokens each, EU data residency required, three engineers maintaining it.
That is 600 million input tokens and 80 million output tokens a month. At Claude's published API pricing — Haiku 4.5 at "$1 / MTok" input and "$5 / MTok" output, Sonnet 5 at "$2 / MTok" and "$10 / MTok", Opus 5 at "$5 / MTok" and "$25 / MTok" — the model bill is $1,000 a month on Haiku, $2,000 on Sonnet, $5,000 on Opus.
Hold that next to the orchestration bill. Inngest's Pro plan is "Starting at $99/mo" and includes "1M executions"; at eight steps and 50,000 runs you need 400,000, so you are inside the base plan. Temporal Cloud's Essentials plan starts at $100/mo including 1M actions, with the "Next 5M" at "$50" per million. Windmill's enterprise tier starts "from $120/mo" at "$20 /mo/dev" and "$100/mo" per two standard workers.
On a per-run or durable-execution meter, the orchestrator is a rounding error against the model. Note the qualifier, because it does not generalise. Price the same workload on a per-action platform and the orchestrator stops being noise: 400,000 tasks a month on Zapier's Pro curve is "$1,269.00" on annual billing, per its pricing page — more than the entire Haiku model bill for the same work. Which orchestrator you pick is a rounding error right up until the meter counts a unit the model controls, and that is the whole point of this page.
Per-Step Billing Hands Your Budget to a Temperature Setting
A deterministic workflow has a fixed step count, so per-step billing is a fixed cost. An agentic workflow does not. The model decides how many tool calls to make, and it decides differently on Tuesday than it did on Monday.
Watch what one extra loop costs on each platform. Zapier counts a task "whenever Zapier successfully completes a unit of work for you", per its pricing page — three extra tool calls is three extra tasks, on a curve that runs from "$19.99" to "$3,389.00" a month on Pro. Make charges one credit per module action: "Each module action in your scenario, like adding a Google Sheet row or fetching Gmail account data, counts as one credit," per Make's pricing page — three extra credits. Inngest defines an execution as "A single durable function run or step execution" — three extra executions. Temporal bills actions, which "track billable operations within the Temporal Cloud Service, such as starting Workflows, recording a Heartbeat or sending messages" per the Temporal Cloud pricing docs — roughly six extra, once you count the activity scheduling.
n8n charges nothing extra. Its unit is the run: "An execution is a single run of your entire workflow. It doesn't matter how many steps are in the workflow or how much data it processes," per n8n's pricing page. Activepieces is the same shape for ordinary steps — "One credit covers a whole run, however many steps" — but AI steps are explicitly carved out: "A step on a fast model is 2 credits, a smart model is 10, and a frontier model is 20," and on Plus and above your own provider keys drop "every AI step to 1 credit." So the meter does follow the model's step count; bringing your own key is what flattens it.
This is the single most important structural difference in the category and almost nobody frames it this way. When the model picks the step count, a per-step meter converts a model's verbosity into a line item on your invoice, and no amount of budget discipline in the finance team reaches a decoding parameter. On n8n's Business tier at €667 a month for 40,000 executions, a chattier prompt costs you exactly zero. On Make, at eight modules and 50,000 runs, you are already buying 400,000 credits a month against a Core tier that lists "$12/mo" for 10,000 — and an agent that loops adds to that linearly.
But do not read per-run billing as a flat curve — n8n's tier boundary is the sharpest cliff on this page. Business tops out at 40,000 executions, and our 50,000-run reference workload is already past it. n8n's own pricing page puts overage at "4,000 EUR for extra buckets of 300,000 executions", so crossing the line by 10,000 runs buys a €4,000 bucket you will use a thirtieth of, taking the real bill to roughly €4,667 a month — the Opus-tier model bill, from the orchestrator alone. Per-run billing protects you from the model's step count and hands you a step function on run volume instead. Price the tier you land in, not the unit you are billed by.
The counter-argument is real and worth stating: per-run billing means n8n has no incentive to make your workflows efficient, and heavy runs subsidise light ones until the vendor reprices. Make and Zapier's per-action model is more honest about what compute costs. That is true. It is also not your problem this quarter.
Deterministic Steps Still Do the Work. The Model Only Picks the Branch.
The architecture that survives production is boring: the model chooses which step runs next; it does not run the step. An agent that emits a structured decision — {"action": "refund", "amount": 4200, "reason": "..."} — into a deterministic dispatcher is testable, replayable and auditable. An agent holding live credentials to your payments API is none of those things.
This is exactly the line Temporal draws, and it is why durable execution keeps showing up in agent architectures that were not designed around it. "While Temporal requires that your Workflow code is deterministic, your AI Agent can absolutely make decisions based on non-deterministic LLM outcomes," the company writes. The model call lives in an activity, where anything goes. The orchestration lives in a workflow, which must replay identically. On recovery, "The Workflow replays your agent's progress using the recorded LLM decisions from the Event History" — the crashed run does not go back and ask the model whether it still wants to issue that refund.
Inngest reaches the same property with far less ceremony. Its step.run wrapper means "the code will be retried if it throws an error and when successful, it's result is saved to prevent unnecessary re-execution," per the Inngest docs. A retry resumes at the failed step with every completed step's result memoised. For most teams that is the whole benefit of durable execution at a tenth of the adoption cost. We have walked through that migration decision before in our look at durable-execution alternatives to LangChain.
Your Retry Config Assumes Steps Are Idempotent. Agent Steps Aren't.
Retrying a failed HTTP POST is safe when the endpoint is idempotent. Retrying a model call is a different operation: you get a different answer, and if the first attempt already fired a side effect before timing out, you now have two refunds.
The failure mode is not theoretical, and n8n's own community documents it precisely. A user configuring retryOnFail: true, maxTries: 2 on a parent AI Agent node found that sub-agent failures still killed the workflow, because — in a reply on the n8n community thread — "retryOnFail applies to the node itself failing, not to tools/sub-agents returning errors." The error "propagates up as tool execution result (failure)". Tools have no "On Error" setting the way an HTTP Request node does.
The practical rule: write the idempotency key with status pending before the external call, not after it. A timeout after the write is recoverable; a timeout before it is a duplicate waiting to happen. Every platform here will let you build that — none of them build it for you.
The Agent Node Stays Green While Its Tools Fail
This is the observability problem that catches teams two months into production, and it is worth naming precisely, because your dashboard will not name it. An agent that swallows a tool error completes successfully. The run is green. Nothing pages anyone.
The mechanics, as one practitioner writeup puts it — a blog run by a commercial n8n tooling vendor, so read it as an interested account: n8n's Error Trigger fires when a node fails, but the agent node treats a failed tool call as information rather than as a fault — "The agent treats that error as reasoning, not as an execution error." Three variants all produce a green run: the tool threw and the agent absorbed it, the tool returned empty data, or the agent skipped the tool entirely and answered from the model's weights. Setting "Continue (using error output)" does not help; it "only branches when the Agent node itself throws. It does not convert a consumed tool error into a failed run."
Treat that as one of two documented behaviours, not the rule. n8n's own issue tracker describes the opposite failure — in issue #24042, open and team-assigned at the time of writing, "any error returned by the tool causes the entire workflow to fail immediately. The error is not passed back to the AI Agent for processing." Which of the two you get depends on the path the error takes out of the tool, and that is precisely the problem: the same platform can hard-fail a run or pass it green on what a reader would call the same fault. The last two green variants — empty data, and the agent skipping the tool to answer from its weights — are not error paths at all, so no fix to either behaviour reaches them.
The fix is the same everywhere: tools return structured status, and you assert on it after the agent. Make every tool return {status, count, data}, add an explicit check, and throw deliberately before any destructive write. That converts a silent wrong answer into a loud failed run, which is the only kind you can operate.
If your budget for this problem is a product rather than a discipline, LangSmith is the strongest tracing story in the category — it is what LangGraph Platform is really selling. LangChain's pricing page lists Developer at "$0 / seat per month then pay as you go" with "Up to 5k base traces / mo", Plus at "$39 / seat per month", and metered usage in compute and storage units at "$1.50 / LCU" and "$1.00 / LSU". Note the shape of that meter carefully: it is the least forecastable bill on this page, and it grows with exactly the thing agents do most.
Credential Scoping Is Where Windmill Wins Outright
Ask the question this way: when the model decides to call the Salesforce tool, which credential does that step run as? On most of this list, the answer is "the same account credential every other step uses."
Windmill is the exception, and it is not close. Every script, flow, resource and variable has a path with explicit permissions: "A secret in u/alice/secret will only be accessible by alice, unless explicitly shared. A secret in f/devops/secret will be accessible by anyone with read access to f/devops," per Windmill's docs. More usefully for anyone who has to answer to an auditor: "Accessing secrets generates variables.decrypt_secret event that ends up in the Audit logs. It means that you can audit who accesses secrets." That is a per-step, per-decrypt audit trail on a non-deterministic run — the thing you will be asked for and will not have.
n8n gets to a defensible position through external secret stores, supporting "1Password (using Connect Server), AWS Secrets Manager, Azure Key Vault, GCP Secrets Manager, HashiCorp Vault, and Infisical" — but the docs are explicit that this is "available on: n8n Cloud: Enterprise; Self-hosted: Enterprise". Budget for the licence, not just the hosting.
Temporal and Inngest have no credential store at all. For this buyer that is a feature: your secrets stay in the vault you already run, and the orchestrator never holds them.
Self-Hosting and Residency: Three Real Options, Two Non-Options
If data cannot leave your infrastructure, the shortlist is n8n, Windmill, Temporal, Inngest and Activepieces. Zapier and Make are out, full stop. Zapier "is hosted on Amazon Web Services (AWS) in the United States," per its security page, which also lists SOC 2 Type II, SOC 3, GDPR and CCPA — good compliance posture, wrong geography, no self-hosted build.
n8n Cloud is the interesting middle: "The physical hardware powering n8n, and the data stored by the platform, is currently hosted in the European Union," on Azure, with data at rest encrypted using "Azure Storage server-side encryption (using AES256 and a FIPS-140-2 compliant implementation)," per n8n's security page. For an EU buyer that is often enough without self-hosting at all.
Read the licences before you assume "open source" means what you want. n8n ships under the Sustainable Use License, which permits use "only for your own internal business purposes or for non-commercial or personal use" and allows distribution "only if you do so free of charge for non-commercial purposes" — see the licence in the repo. Internal automation is squarely permitted; reselling it as a service is not. Windmill's backend is AGPLv3 "except any snippets of code under the compile flag 'enterprise'". Activepieces is MIT except the packages/ee/ directories. LangGraph Platform's self-hosted and BYOC deployments both require an Enterprise plan.
And if you are a Microsoft shop, the incumbent is already licensed: Power Automate Premium is "$15.00 user/month, paid yearly" and Power Automate Process is "$150.00 bot/month", per Microsoft's pricing page. It has none of the agent ergonomics of the others. It also has your identity model already wired in, which is worth more than it sounds.
Who Should Not Pick Each of These
- Not n8n if a silently failed tool is unacceptable in your domain, or if your run volume sits near a tier boundary. Its per-run billing is the best cost shape here within a tier — the €4,000 overage bucket above 40,000 executions is the worst — and its agent node's error semantics are inconsistent enough that you are trading money for a monitoring obligation you must actually staff.
- Not Zapier for anything genuinely agentic. Activity caps of 40 per run, 1,500 a month on Pro, US-only hosting, no per-step credential scoping. It remains excellent at what it was built for: deterministic glue across 9,000 SaaS apps that nobody wants to maintain.
- Not Make if the step count is model-decided. Its credit model is meaningfully cheaper than Zapier's per operation and its agent runs cost "1 credit per operation + credits based on ai tokens" with the native provider, or flat "1 credit per operation" if you bring your own key, per Make's help centre. Bring your own key. But the meter still counts steps you don't control.
- Not Temporal if nobody on the team writes and deploys code. It is a library and a cluster, not a canvas. The payoff — event-history replay, retries you can reason about, runs that survive a deploy — is real and it is engineering work.
- Not Inngest if you need a visual builder for non-engineers. It is Temporal's durability with a fraction of the operational surface, which is the right trade for most teams, and it is still code.
- Not Windmill if connector coverage is the job. Best-in-class secret scoping, unmetered self-hosted executions, and you will write more integrations by hand than you expect.
- Not LangGraph Platform unless the graph is the product. Its tracing is the best available and its metering is the least predictable, and self-hosting is gated behind Enterprise.
- Not Activepieces if you need an enterprise support story today. The billing unit is right for deterministic steps and the licence is permissive, but AI steps meter separately unless you bring your own key, and the maturity gap against n8n is real.
The loser, for this buyer, is Zapier. Not on quality — on fit. Every design choice that makes Zapier excellent for deterministic glue (managed hosting, per-task billing, account-level connections, an activity cap that protects you from runaway spend) is the wrong choice when a model is choosing the steps. The 40-activity ceiling is the tell: it exists precisely because Zapier knows an unbounded agent loop would be ruinous on a per-task meter.
The Decision, in the Order That Predicts Regret
Ranked by how much pain the wrong answer causes, not by how often it gets discussed:
- Can a half-finished run cost you money or trust? If yes, you need durable execution — Temporal or Inngest — regardless of what the canvas looks like. Nothing else on this list recovers a crashed run without re-asking the model.
- Where must the data live? Answered second because it eliminates candidates faster than any feature comparison. US-only hosting removes two vendors before you evaluate anything.
- Who scopes the credential the agent's tool call runs as? If the honest answer is "nobody", you have an audit finding waiting, not a platform choice.
- Is your meter counting a unit the model controls? If yes, forecast the bad month, not the median one.
- Who maintains this in 18 months? The team that can operate a Temporal cluster is a different team from the one that can maintain 40 n8n workflows. Pick for the team you have.
This month: instrument the thing you cannot currently see. Make every agent tool return {status, count, data}, assert on it after the agent node, and count how many of last month's green runs were actually failures. That number decides whether this is a platform migration or a monitoring fix.
This quarter: move the two or three steps that touch money into a durable engine and leave everything else where it is. Inngest's Pro plan at "Starting at $99/mo" is cheaper than the meeting in which you debate it.
Before renewal: price your worst month, not your average one — the month the model loops. Then check whether your contract's meter counts steps the model chose. We covered how these consumption meters behave under pressure in our breakdown of agentic AI pricing models.
The Bottom Line
Every platform migration in this category is being sold as an agent story and is actually a durability story. The industry spent fifteen years building deterministic workflow engines, then discovered that inserting one non-deterministic step breaks retries, breaks cost forecasting, breaks credential scoping and breaks the definition of a failed run — and reached for a new vendor instead of a new step boundary. Durable execution solved most of this a decade ago for payments and logistics; agents are rediscovering it under a new name, which is what Orkes and Netflix's Conductor lineage has been arguing all along.
Keep the deterministic shell. Move the model inside one step of it. Put a durable engine under the steps that cannot run twice.
The agent does not need a new platform. It needs a smaller blast radius.
Continue Reading
- LangChain Alternatives: Fix Durability Before You Rewrite
- LangGraph vs CrewAI vs AutoGen: One of Them Is Retired
- Agentic AI Pricing: Don't Buy Consumption Without a Cap
- The Build-to-Buy Spectrum: 5 Tiers for Enterprise AI Agents
- Why Temporal Lost to Mistral in the $2B AI Orchestration War
- AI Agent Hidden Costs: Why ROI Calculations Miss 40%
- Orkes Raises $60M: Netflix's Conductor Goes Agentic
- Glean vs Copilot vs Dust: Buy the Permission Model