Your Workflows Don't Live in One Vendor's Product. Your Agents Can't Either.

The workflows that enterprises want to automate are cross-system by definition. Vendor-native agents aren’t built for that reality, and that’s why an agent that lives in a CRM is a dead end.

At a recent customer roundtable, someone asked why their Salesforce Agentforce deployment wasn’t delivering on the automation promise. They weren’t expecting me to be so blunt in my answer. The problem isn’t Agentforce. The problem is that no single-vendor agent can ever solve this, because the workflows you actually want to automate don’t live inside any one vendor’s product.

I’ve had some version of that conversation dozens of times in the past year, and the pattern is always the same. A team buys Agentforce, runs a demo that looks compelling, gets executive sign-off, and then six months later, someone asks why nothing has actually changed. The demos were real. The automation wasn’t.

Here’s what I tell them: An agent in Salesforce can only do Salesforce things. A sales deal touches Salesforce, Slack, Google Drive, Gong, DocuSign, and a Jira backlog before it closes. A support escalation moves through Zendesk, a knowledge base, an ERP, and a human’s inbox. A vendor-native agent can only see one room in a house full of connected rooms. The agent can be very smart about that room, but just like the Eagles’ Hotel California, it can never leave.

That’s not a criticism of Salesforce’s engineering. The architecture itself is the constraint.

Why vendors build this way

Salesforce isn’t building Agentforce to solve your cross-system problem. It’s building Agentforce to deepen your dependency on Salesforce. The two goals are not the same, and when they conflict, you know which one wins.

This isn’t cynicism, it’s procurement strategy. SaaS companies have always built walls that make it painful to leave: proprietary data models, custom integrations, ecosystem lock-in. At times, that has been an advantage for enterprise teams. But as vendor-native agents extend that logic into the automation layer, it becomes a roadblock to performing real work. If your AI workflows are built on Agentforce, you aren’t just paying for CRM software anymore. You’re paying to keep running.

Arcade.dev’s ToolBench data, which analyzed more than 43,000 MCP servers and counting across the enterprise software stack, surfaces this pattern at scale. The vendors investing most aggressively in proprietary agent systems are often the same vendors restricting access through open standards. Slack, Workday, and LinkedIn all rate toward the closed end of the spectrum on MCP support. To its credit, Salesforce has embraced MCP: Agentforce can now connect to any MCP-compliant server, and Salesforce ships hosted MCP servers of its own. But look at the architecture. The agent still lives inside Salesforce and is governed by Salesforce. MCP became the doorway for pulling other systems into the CRM, not for letting the workflow run across them.

The result is an agent that works well inside Salesforce and hits a wall the moment the workflow needs to cross a system boundary.

Why the “every vendor will build their own MCP” assumption is wrong

I’ve written about this at length before. There’s a common assumption in enterprise AI right now: every SaaS vendor will eventually build their own MCP server, and when they do, the integration problem is solved. It won’t be, and here is why.

Suppose the assumption plays out and every vendor ships a first-rate MCP server. Salesforce exposes Salesforce capabilities. Slack exposes Slack capabilities. That’s exactly what those servers should do — but “close out this deal” isn’t a Salesforce task or a Slack task. It’s a workflow that reads and writes across both, plus DocuSign, the finance system, and wherever the contract lives. Vendor MCP servers give an agent access to each system. None of them executes the workflow that runs across all of them, because no vendor owns it. Access isn’t the same thing as orchestration.

The first problem comes down to coverage, and the second is composability. Even when the right servers exist, they have to be designed well enough to hand off reliably to each other. That requires clear tool descriptions, defined output schemas, and proper error handling so an agent moving from one server to the next knows what it’s receiving and what to do with it.

Most servers today aren’t built this way. When they aren’t, the agent doesn’t stop and ask for clarification. It guesses and hallucinates, in a multi-step workflow with the guesses compounding across every handoff.

This is the layer we built Arcade for. Our MCP servers don’t exceed the capabilities of their toolkits either, no server should. What Arcade adds is intent mapping: tools organized around what the agent is trying to accomplish rather than around any one system’s API, so when a workflow moves from a Salesforce action to a DocuSign signature to a Slack notification, each handoff lands correctly instead of leaving the agent to guess what comes next.

Vendor-native MCPs are organized around those vendors’ capabilities. Cross-system workflow automation requires something above that layer that maps intent to what the agent is trying to accomplish across all those systems. Those are very different end goals, and conflating them is why teams end up disappointed when their agents hit a dead end.

What the token data actually shows

Arcade’s recent State of MCP Tools report found that across 219,000 MCP tools throughout the ecosystem, only 0.5% earned an A grade. The most common failure was poor or missing tool descriptions. When that information is absent, the agent doesn’t stop and infers.

When an agent is running a multi-step workflow across systems, it needs tools that know their place in a larger sequence: what they return, what they expect, and where they hand off. A Salesforce tool that dumps a raw API response into the context window and leaves the agent to infer what comes next isn’t an MCP tool.

The result is that token cost compounds fast. Agentic models already consume 5 to 30 times more tokens per task than a standard chatbot. When tools don’t describe their outputs and agents have to infer them, those numbers get exponentially worse. Arcade ran identical CRM queries through two different Attio MCP toolkits and found a 100x difference in token consumption between a well-built and a poorly built toolkit. At enterprise scale, that gap runs into seven figures annually.

Vendor-native agents sidestep this problem by keeping the workflow inside a single system, but that comes with a different cost: the agent can only complete contained, single-system workflows. The task that requires a broader cross-system workflow, which is where the real ROI on automation lives, stays manual. You get an agent that handles pieces of the work, often valuable pieces, but still without ever completing the full job.

What to ask before you sign

If you’re currently evaluating Agentforce, Workday, or a similar vendor-native product, one question is worth asking before you commit: what happens when the workflow crosses a system boundary?

See what the agent does when it needs to read a contract from Google Drive and update a Salesforce opportunity in the same task. And ask the question underneath it: whose credentials is the agent using in Google Drive, and who approved that access? That workflow isn’t exotic, it’s just a normal Tuesday.

A vendor-native agent holds that vendor’s credentials. Every other system it reaches is another connection to configure, another credential to manage, another access decision governed inside one vendor’s walls. The question that matters — can this agent, acting on behalf of this user, take this action in that system? — has no answer a single vendor can give, because the user’s permissions live everywhere the workflow does.

Arcade is built for that reality. We’ve built thousands of high-quality MCP tools designed to make agents reliable across complete, end-to-end workflows. However, better tooling alone isn’t enough. A vendor-native agent holds that vendor’s credentials and has no legitimate path to authenticate against the other systems your workflow touches. Handling auth across every system that a workflow touches requires infrastructure that lives outside any single vendor’s four walls.

That is what Arcade provides. The agents that actually automate enterprise workflows move freely across systems because that’s where the work lives.