The visible connector problem is easy to see in cabling. The software version is less visible, but it has the same maintenance shape.
Zapier lists more than nine thousand apps it can connect to each other. Nine thousand pieces of software in regular business use that don’t talk to each other natively, and an entire company exists to be the translator between them.
The most-connected apps on the platform are the ones you’d expect, Google Sheets, Gmail, Slack, Outlook, calendars, CRMs. They sit at the top because that’s where the glue is needed. Someone takes a meeting, the calendar knows it happened, the CRM doesn’t get updated, someone has to copy across. A lead comes in via a form, the form fill goes to one place, the sales team works out of another, somebody bridges the gap, and the bridges are what people pay for.
Most of what people actually want from automation tools is some variation on updating the CRM after meetings, filtering leads out of LinkedIn into a list, turning a YouTube video into a blog post and tweets without retyping it five times. None of these are exotic, they’ve been buildable for years, and they’re hard because the apps underneath them weren’t built to be talked to programmatically. Every connector that exists to bridge them is a workaround for that fact.
Enterprises have been hitting the same wall for at least a decade and the technology built to climb over it has a name. Robotic process automation exists because the legacy applications people needed to integrate with didn’t have APIs that covered what they wanted to do, or had APIs locked behind licensing the company didn’t want to buy. Gartner’s original framing of RPA was that integrating with legacy systems was the main driver. The whole category is a polite name for screen scraping with a vendor contract attached.
The failure rates on RPA are public, the widely cited Ernst & Young figure is around fifty percent of initial projects failing, other estimates land in the thirty to fifty percent range, and HfS Research puts ongoing maintenance at seventy to seventy-five percent of total RPA budgets. The failure mode is the same one I’ve watched on application migrations for years, a bot is built to drive a UI, the UI changes, the bot breaks. SAP ships an update that moves a dropdown and the purchase order workflow stops running on Monday morning. The bot didn’t do anything wrong, the application it was driving moved out from under it.
When automation depends on where the interface puts the target, the interface becomes part of the contract.
I worked with a customer who was stuck running a legacy app in a colo and lift-and-shifted it to AWS, and the app itself couldn’t really be changed because of its age, so getting it to cloud was already a massive move on its own. Once it was up there we could automate some of the workflows around it with serverless and cloud storage, and the efficiency and reach went up because it wasn’t colo-bound anymore, but the app sat in the middle of all that as compatibility-resistant as it had ever been, with the cloud-native services working around it rather than touching it.
The Zapier version of the same problem is more graceful, the connectors are maintained centrally by Zapier rather than rebuilt internally by every customer, but it’s the same wall. The reason a Salesforce-to-Slack zap works is that someone at Zapier or Salesforce or both is keeping the integration alive as both products change. Pull that work out of the picture and the zaps stop working. The 9,000 number isn’t a feature, it’s a maintenance commitment, and most of the failure cases people quietly run into are versions of that commitment breaking down at the long-tail apps where nobody’s actively maintaining the connector.
Zapier shipped AI Agents in May 2025, then a natural-language builder called Copilot in September, then MCP support so external AI agents can call Zapier zaps directly. You tell an agent what you want done and it composes the integration on the fly across the 9,000 apps you’ve already connected your accounts to. The wall is the same, what changed is who’s allowed to drive over it.
Traditional RPA fails by breaking, the bot stops, the workflow halts, somebody gets paged. The cost is downtime and rebuilding the bot. With agent-driven automation there isn’t really a bot, there’s a model deciding which connector to call and what to do with the output, and when something goes wrong the model doesn’t stop, it picks a different action and keeps going. The error gets absorbed into the next step of the workflow and doesn’t surface as a failure, it surfaces as a result you have to inspect to know whether it was right.
Gravitee’s 2026 survey of around 900 executives and practitioners reported that 88 percent of organisations had confirmed or suspected AI agent security incidents in the previous year, with the figure for healthcare at 92.7 percent. The same survey found that 82 percent of executives were confident their existing policies covered unauthorised agent actions, while only 14.4 percent of organisations were sending agents to production with full security or IT approval. That gap between executive confidence and operational reality is where most of the incidents are happening. One example that’s made the rounds, a financial reconciliation agent was asked, in business-task phrasing, to export “all customer records matching pattern X”, where X was a regex that matched every record in the database, and the agent exported 45,000 records doing exactly what it was asked.
Underneath the model layer, what an agent actually has is access to a stack of connectors. Every one of those 9,000 Zapier integrations represents a credential bundle, the OAuth tokens, the API keys, the service accounts that let the platform act on behalf of a user inside another app. For a human user setting up a zap this is fine, the user can only set up zaps for accounts they actually have access to, and they have to consent each time. For an agent calling zaps via MCP the same authority is available without the same checks. An agent told to “follow up on stale leads” can read the CRM, draft emails, send them, log activity, mark records as worked, and update pipeline stage, because all of those are existing zaps the user has connected. No privilege gets escalated. The agent is using the privilege the user already granted to the platform, in a sequence the user didn’t preview.
The lesson from the RPA history is that the difficulty was never in the orchestration layer. Zapier works, Power Automate works, n8n works, UiPath works for what it does. The difficulty has always been in the contract between the orchestration and the underlying applications, which the applications were never designed to honour cleanly, and every generation of automation tooling has worked around that contract gap with whatever the current technology made possible. Screen scraping, then managed connectors, now a model that can guess at what to do when the contract is ambiguous, which is most of the time.
I’ve watched enterprises spend years trying to automate against applications that resisted being automated against, and the consistent lesson has been that you can’t outrun the underlying compatibility problem with better tooling on top. The agent shift doesn’t fix that, it changes what failure looks like from a bot that stops working to an agent that doesn’t. I’m watching what people do with agents on the gaps RPA and Zapier never quite closed.