50+ Systems to Integrate: Automation Platform, or Build the Layer?

The question that arrives at about fifty systems

It usually shows up phrased as a tool comparison. We have fifty-something systems to connect, we need something that can orchestrate AI steps across them, does n8n cover all of it or should we evaluate Zapier, Make and Pipedream first?

It is a reasonable question and it is the second one. The first one is which of those fifty integrations you would be comfortable explaining to a customer if it ran twice.

Answer that and the platform question mostly answers itself, because the two categories have almost nothing in common except that both are currently drawn as boxes connected by lines.

The numbers behind the situation

The sprawl is real and it is worth being specific about, because the published figures vary enough that quoting one of them confidently is a tell.

The spread on the first three is the interesting part. Counts that differ by a factor of eight are not measuring the same thing: the low numbers count applications IT knows about, the high numbers count everything with an OAuth grant. If you are trying to size your own integration problem, the OAuth consent screen in your identity provider is a more honest inventory than the procurement spreadsheet, and it is usually a surprising afternoon.

Four failure modes that arrive before the ceiling does

Teams expect to outgrow a platform through volume or price. In practice the volume ceiling is generous and the thing that actually forces the decision is one of these four, all of which show up while you are still comfortably inside your plan.

1. You cannot answer what happened without opening a vendor UI

A customer says they were charged twice. To find out, somebody logs into the automation platform, finds the scenario, scrolls the execution history, and reads a JSON blob. That is not debugging, it is archaeology, and it does not survive contact with an incident review.

This is the reliable trigger to build. Once the answer to an operational question lives inside somebody else's execution log, you have lost the ability to reason about your own business process, and it happens long before you hit a published limit.

2. Retries are not safe, and you find out during an outage

Nearly every webhook system in production is at-least-once. Shopify documents that its webhooks can be delivered more than once and tells you to deduplicate on the webhook id. Stripe ships idempotency keys precisely so that a retried request returns the original response instead of creating a second charge.

Those are the vendors being responsible. The question is what your side does with a duplicate. On a no-code platform the honest answer is usually nothing: the scenario runs again, from the top, and does whatever it did last time. That is harmless when the last step posts to Slack. It is a refund issued twice when the last step touches a ledger.

3. A schema change breaks production instead of a build

A vendor renames a field. On a platform, the mapping silently starts passing undefined and the failure surfaces days later as missing data nobody noticed. In a typed integration layer the same change fails a compile or a contract test, in CI, before it ships.

This is the least dramatic of the four and it is the one that quietly costs the most, because the damage is measured in the gap between when it broke and when somebody spotted it.

4. The escape hatch is too small

Every platform has a code step for the last 5 percent, and its limits are where the model shows. Zapier's code steps run inside a restricted sandbox with a 30-second execution limit and a 256 MB memory cap. n8n is considerably more permissive, running arbitrary npm packages in its code node and letting you build custom nodes, which is exactly why developer teams tend to land there.

But notice what the escape hatch means. The moment your critical path depends on code inside a step inside a vendor's workflow engine, you have written software with none of the things that make software maintainable: no version control that matters, no tests, no code review, no local reproduction.

The dividing line is consequence, not complexity

The instinct is to sort integrations by how complicated they are. That is the wrong axis. A twelve-step workflow that ends in a Slack message is safer to leave on a platform than a two-step one that ends in a payout.

The canonical example of the second column is what airlines call irregular operations. A flight cancels at 22:40 and, within seconds, rebooking, crew rostering, catering, ground handling, hotel vouchers, loyalty accrual and refund eligibility all have to agree on a new version of reality across systems bought decades apart. Run the rebooking step twice and you have double-booked a seat you do not have. Skip it and somebody sleeps in a terminal.

No sane airline runs that on a drag-and-drop canvas, and the reason is not scale. It is that the workflow has to be replayable, ordered, and exactly-once, and those three properties are the definition of an integration layer.

What an integration layer actually is

Less than people fear. This is not an ESB and it is not a year of work. For most teams it is a small service holding four things:

• Idempotency keys. Every inbound event and every outbound mutation carries a key, and a repeat returns the first result instead of performing the action again. This single mechanism removes most of the fear from retries.
• A transactional outbox. The state change and the event announcing it commit in the same database transaction, and a separate process publishes from that table. This is what makes it impossible to update a record and then fail to tell anyone, which is the most common silent corruption in a platform-based stack.
• Typed contracts at the edges. One schema definition per external system, validated on the way in. A vendor's change breaks a build rather than a customer.
• A replayable log. Events stored so a bad afternoon can be reprocessed deliberately. This is the capability people miss most and specify least.

That is a few thousand lines of ordinary code, and it is boring on purpose. The interesting part of the system should be your business logic, not your delivery semantics.

The split stack, and the cost math that justifies it

The recommendation for a fifty-system estate is almost never one tool. It is a deliberate split, and the ratio tends to land near 80/20 by count: the many low-consequence flows stay on a platform where an operations person can edit them without a deploy, and the few load-bearing ones get built.

The billing models push in the same direction. Zapier prices per task, so a twenty-step workflow costs twenty times a one-step workflow, and when you hit the monthly limit affected Zaps stop, then bill at 1.25 times the base rate, and pause entirely at three times the subscription limit. n8n prices per workflow execution regardless of step count, which is why step-heavy automation migrates there as it grows. Neither model is wrong; they just make different things expensive.

But cost is the weakest argument for building, and I would be suspicious of anyone leading with it. The strong argument is that you get to keep your own operational history. The commonly cited threshold of roughly 500,000 operations a month is a real inflection for price, and most teams should have built the transaction-shaped 20 percent long before they reach it.

When not to build

Three cases where the honest answer is to stay entirely on a platform, and anyone selling you an integration layer here is selling you their preferences.

• Nothing in the estate is transaction-shaped. Plenty of real businesses genuinely only move information around. If running every workflow twice would be invisible, build nothing.
• The people who maintain it cannot read code. An integration layer that only one person can change is a worse outcome than a platform everyone can. This is an organisational constraint, not a technical one, and it is decisive.
• The workflows are still changing weekly. If the process is not stable, you are not integrating, you are still designing. Prototype on the canvas and build the parts that stop moving.

Where AI agents fit, and where they do not

This is worth being blunt about, because it is the expensive mistake of the moment. There is a widespread hope that an agent with enough tool access removes the need for integration architecture.

It does the opposite. An agent decides what should happen. An integration layer guarantees that what happens, happens exactly once and can be audited afterwards. Putting a non-deterministic decision-maker on top of an execution path that already cannot survive a retry does not replace the missing reliability, it multiplies the number of ways the system can be wrong, and it makes each failure harder to reproduce because the input was a model output.

The sequencing that works is unromantic: make the execution path deterministic and observable first, expose it as a small set of typed tools, then let an agent choose among them. At that point the agent is genuinely useful, because the worst thing it can do is pick the wrong tool, rather than corrupt a ledger. There is more on that boundary in the difference between an AI workflow and an agent and on the checkpoints in human-in-the-loop review.

The decision, in one table

For the platform-by-platform comparison underneath this decision, see n8n vs Zapier vs Make for AI automation. This post is about the layer above that choice, which is the one that turns out to matter more.