Most teams that ask us about a custom SI agent already have a Zapier account or an n8n instance, and often the honest first answer is to keep using it. Both tools now handle LLM steps, agent-style tools and knowledge sources, and a well-built workflow in either one can run for a long time without anyone touching it.
But some workflows outgrow them, and the signs are easy to miss until a bill, an outage or an audit makes them obvious. This guide is fair to the no-code tools first, then walks through the six places they tend to stop, and ends with a checklist you can run against your own workflow.
What Zapier and n8n do well today
Zapier is a fully managed cloud service. You never run a server, and it connects to thousands of apps out of the box. Workflows can branch with Paths, run custom JavaScript or Python in Code steps, and keep a version history you can roll back from on paid plans. Zapier Agents add a layer on top: you give an agent company knowledge such as documents and FAQs, connect it to your apps, and let it act on a trigger or when you ask.
n8n takes a different route. You can use its hosted cloud or self-host it on your own infrastructure, on premises or in a private cloud, typically with Docker. It has code nodes for JavaScript and Python, agent nodes that combine LLM providers with tools, memory and vector stores, support for MCP servers, and built-in evaluations for testing LLM workflows. Higher tiers add Git-based source control and separate environments. Its Sustainable Use License allows free self-hosting for internal business use, with limits on reselling or white-labelling it.
That is a lot of capability. If your workflow is a handful of steps across common SaaS apps, with a model drafting, classifying or summarising in the middle, either tool will get it live faster than any custom build. We say the same in our guide to choosing between an SI agent, a chatbot and workflow automation: when the steps can be written down, plain automation is usually the right answer.
When should you build a custom agent instead of using Zapier?
Build a custom SI agent when the workflow has outgrown what a hosted automation tool is designed for, not simply because a model is involved. Zapier and n8n both handle LLM steps and agent-style tools now, and for short, mostly linear workflows across apps they already connect, they are usually the faster and cheaper choice. The case for custom code appears when several of these are true at once: the work runs at high volume, so per-run billing and rate limits shape the design; the logic branches deeply and must remember state across many steps or across days; jobs run for a long time or wait on people; the data must stay inside your own infrastructure under your own access rules; you need automated tests, code review and versioned releases; or finance needs running costs it can forecast. One of these alone rarely justifies a build. Three or more usually do, especially when the workflow is core to how the business earns money.
When to stay with no-code
- The workflow is mostly linear, with a few branches you can draw on one screen.
- Volume is low to moderate, and a delayed or retried run costs little.
- Every system involved already has a supported connector.
- The people who own the process can read and change the workflow themselves.
- The data involved is allowed to pass through a third-party cloud, or you self-host n8n.
- A failure is visible and cheap to fix by hand.
Where no-code tools start to strain
None of these is a flaw in Zapier or n8n. They are the natural edges of tools built to make workflows easy to assemble. The question is whether your workflow lives near those edges.
High volume
Hosted automation bills per unit of work: Zapier counts tasks, n8n counts executions. At modest volume that is simple and fair. At high volume, every extra step you add for safety or logging shows up on the bill, so teams start removing checks to save runs. Platform rate limits and throttling also hold or delay runs when traffic spikes, which is fine for a daily report and painful for a customer-facing queue.
Deep branching and state
Visual builders are excellent for trees you can see. Zapier, for example, caps how deeply Paths can nest and how many steps a single Zap can hold, and suggests sub-Zaps beyond that. Agents add another problem: they need state. Which documents were checked, what the customer said three messages ago, which approvals are pending. Keeping that in workflow variables or a spreadsheet-style table works until two runs touch the same record at once. A custom agent keeps state in a real database with transactions, so concurrent work does not corrupt it.
Long-running work
Many useful agents do not finish in one go. They wait for a supplier reply, a human approval or an overnight batch, then resume. Code steps in hosted tools have runtime limits, and waiting patterns rely on delays and webhooks stitched together by hand. A custom build can use a durable job queue or workflow engine that pauses, retries and resumes cleanly, and that is also where approval patterns for human-in-the-loop agents are easiest to enforce.
Data control and hosting
Zapier is cloud only, so every payload passes through its infrastructure under its terms. For a lot of businesses that is acceptable. For regulated data, client contracts with residency clauses, or internal rules about where personal data may go, it can rule Zapier out. Self-hosted n8n solves the hosting question, but you then own patching, uptime, credentials and backups, which is a real part of what a custom build would ask of you anyway.
Testing and versioning
Zapier keeps versions, and n8n can sync workflows to Git, though its own docs say this should not be treated as full version control. What neither gives you natively is the full software release loop: unit tests on each tool an agent can call, a regression suite of real inputs run on every prompt or model change, code review, and staged rollouts. Once a workflow makes decisions that matter, that loop is what lets you change it without fear. It is the habit we describe in eval-first SI.
Cost predictability
No-code is usually cheaper to start. The issue is forecasting. Per-run billing, model calls through platform features and add-ons for longer runtimes all scale with usage in ways that are hard to predict when an agent decides for itself how many steps to take. With custom code you still pay for model calls and hosting, but you control the loop: caps on steps per task, caching, cheaper models for simple steps, and a budget the system enforces.
What custom costs you in return
A custom agent is software you now own. Someone has to maintain the integrations when a vendor changes an API, keep dependencies patched, watch the logs and answer the alert at night. You lose the ability for a non-engineer to open the workflow and change a step. And the first version takes longer to build than the no-code equivalent. If none of the six pressures above apply, those costs buy you nothing, and the guardrails in designing autonomous agents that stay in bounds become your team's job rather than the platform's.
A checklist before you decide
- Write down the workflow end to end, including every exception a person currently handles.
- Estimate volume at today's level and at the level you expect if the business grows.
- Count the branches and the state the agent must remember between steps and between runs.
- Note any step that waits on a person, a supplier or a batch job.
- List the data that passes through, and check whether contracts or regulation limit where it can go.
- Decide how you will test a change before it reaches production.
- Ask finance whether usage-based running costs are acceptable, or whether they need a ceiling.
- If three or more of these point to strain, scope a custom build. If not, stay with the tool you have.
The middle path: keep the tool, move the hard part
It is rarely all or nothing. A common pattern is to keep Zapier or n8n for triggers and simple app-to-app steps, and move the reasoning, state and risky actions into a custom service the workflow calls through a webhook or API. The no-code layer stays easy for the operations team to change, and the part that needs tests, logs and access control lives in code. Our guide to business process automation with SI agents covers how to pick which process to move first.
If you are weighing a custom build
Most of the effort in a custom agent is the plumbing between systems, not the model. That was the lesson of the telecom orchestration platform for 46 Labs, where dependable workflow automation across voice, data and messaging mattered more than any single smart step. If your checklist points toward custom, Octalcode's SI applications team can review your current workflow with you and tell you plainly whether it is worth rebuilding, or whether a few changes in the tool you already use will do.