Why MCP Servers Aren't Enough for Production AI Agents: Permissions, Aggregation, and the Snowflake Problem of Every CRM and ERP

By Chris Lopez, Founding GTM at Ampersand

Introduction

If you build AI agents for businesses, you have probably spun up an MCP server in the last six months. Maybe a few. The Model Context Protocol gives an LLM a clean way to call a tool, and the spec has done a great job of standardizing what used to be a mess of bespoke function-calling adapters. For demos and internal copilots, MCP is excellent. For production AI agents that operate inside enterprise CRMs and ERPs, on behalf of paying customers, it stops short of what the job actually requires.

In our work with engineering teams shipping vertical AI products, we have seen the same pattern repeatedly. The first MCP server gets stood up in an afternoon. The second one takes a week. By the third or fourth, the team has accumulated a backlog of custom auth handlers, half-finished permission filters, error retries that do not retry the right things, schema mismatches nobody noticed in dev, and tenant-specific edge cases nobody had time to model. It is death by a thousand cuts. The agent works on the demo account. It breaks on the customer's account. The gap between those two states is exactly where production-grade integration infrastructure lives.

This post is about what MCP integrations can and cannot do, why every CRM is a snowflake, why every ERP is even worse, and what an AI agent platform actually needs underneath it to scale into the messy reality of enterprise systems of record.

What MCP Gets Right

Credit where it is due. The Model Context Protocol solved a real problem. Before MCP, every model provider had its own tool-calling format, every framework wrapped tools differently, and every integration developer wrote glue code that did not compose. MCP made tool definitions portable, gave us a shared transport, and let an agent discover capabilities at runtime. If you are building a single-user copilot that needs to query GitHub, hit a weather API, or read a file, an MCP server is exactly the right primitive.

MCP also makes prototyping incredibly fast. An engineer can scaffold a server, expose a function, and have an agent calling it within an hour. That speed is not nothing. It is genuinely useful for internal tooling and proofs of concept. It is the reason MCP has spread so quickly across the agent ecosystem, and the official protocol spec is worth a read for anyone who has not already wired one up.

What MCP does not do, and was never designed to do, is replace the layer of integration infrastructure that sits between an AI product and its customer's system of record. That layer has to handle authentication for thousands of tenants, normalize wildly different data models, enforce permissions, sync data on schedules, batch writes, manage rate limits, recover from outages, surface errors, and keep doing all of that while every Salesforce admin in your customer base reconfigures their org on a Tuesday afternoon. None of that is in the protocol. It cannot be. MCP is a way for an agent to call a tool. Production integrations are an entirely different category of software.

The Death-by-a-Thousand-Cuts Problem of Production MCP

Here is the pattern teams describe. They build an MCP server for Salesforce. The first version queries opportunities and creates tasks. It works in dev. They show it to the customer. The customer says, "Great, but we need it to use our custom field for deal stage, ignore opportunities owned by the sales-ops user, only read accounts in the Enterprise segment, and write back to a custom object called Deal_Activity__c." Now the team has to rebuild the server's tool definitions for that one customer, or worse, parameterize them by tenant.

Then the second customer onboards. Their custom field for deal stage is named differently. Their permission model is record-level rather than role-level. Their custom object has a required lookup field that the agent does not know how to populate. The team adds a second layer of configuration. Then they hit Salesforce's API limits because the agent is doing point reads instead of bulk operations. Then they discover their auth refresh logic does not handle the case where a customer's admin revokes the connection from the Salesforce side without notifying anyone. Then the agent starts returning stale data because nobody implemented incremental sync. Then a customer asks why the agent cannot see records that were created two minutes ago, and the team realizes MCP's request-response model has no concept of subscription or change capture.

Each of these problems looks small in isolation. None of them is a single dramatic failure. They are paper cuts: a missing field here, a permission edge case there, a rate-limit retry that needs to be smarter, a webhook that nobody wired up. Stack them together over six months and you have a team of three engineers spending most of their week on integration plumbing instead of on the agent itself. That is not a hypothetical. It is the predictable trajectory of any team trying to operate production integrations through MCP servers alone, and we have seen variations of it across nearly every conversation with founders building vertical AI products.

The deeper structural problem is that MCP servers are written once and then expected to work against environments that drift continuously. A Salesforce admin pushes a new validation rule. A NetSuite customer adds a custom segment to a transaction record. A HubSpot portal adds a required custom property to the deal object. Your MCP server has no way to detect those changes, no way to surface them to the customer's success team, no way to route around them. Each one becomes a silent failure that surfaces as a bug report from a frustrated customer two weeks later, and the engineering team has to scramble to figure out why the agent worked yesterday and does not work today.

Every CRM Is a Snowflake

This is the line that captures why integration looks easy from the outside and proves brutal from the inside. Every Salesforce org is a snowflake. Every HubSpot portal is a snowflake. Every Microsoft Dynamics tenant is a snowflake. The product names are familiar. What lives inside any given customer's instance is not.

Take Salesforce as the canonical example. Salesforce ships with standard objects: Account, Contact, Opportunity, Lead. Every customer modifies those objects with custom fields, custom validation rules, custom record types, and custom workflows. Many customers add entirely new custom objects to model their business. A B2B SaaS company might add Subscription__c, Product_Line__c, and Renewal_Forecast__c. A logistics company might add Shipment__c and Route__c. A vertical AI product that only understands standard objects is useless to those customers.

Custom fields are worse than custom objects, because they multiply silently. Two customers might both have a custom field called "Deal Stage." One stores it as a picklist with eight values. The other stores it as a free-text field. A third uses the standard StageName field and ignores the custom one entirely. Field mapping is the work of figuring out, per tenant, where the data the agent needs actually lives. There is no universal schema for "deal stage." There is only what each customer's admin decided.

Permissions add another layer. Salesforce's permission model is one of the most expressive in the industry: profiles, permission sets, role hierarchies, sharing rules, field-level security, record-level access, and Apex managed sharing. An AI agent operating on behalf of a user has to respect all of that. If your MCP server runs as a single integration user with admin permissions, every customer ends up with an agent that can read and write data their actual users would not be allowed to touch. That is a security incident waiting to happen, and any enterprise security review will catch it immediately.

HubSpot has the same shape with different specifics. Custom properties replace custom fields, custom objects exist on certain tiers, and the permission model is simpler but still tenant-specific. Microsoft Dynamics is a universe of its own, with solutions, environments, security roles, and a data model that varies by industry vertical. A useful piece for teams getting deeper into this terrain is Building Multi-Tenant CRM Integrations at Scale: Why Traditional Platforms Fall Short, which goes into why architectures built for single-tenant integrations fall over when you operate them across hundreds of customer orgs at once.

The point is this. There is no such thing as a generic CRM integration. There is only the integration into a specific customer's specific configuration, and your agent has to learn that configuration to be useful.

Every ERP Is an Even Bigger Snowflake

If CRMs are snowflakes, ERPs are glaciers. NetSuite is the most extreme example. It has SuiteScript, custom records, custom segments, locked features, environment-specific configurations, role-based field access, and a permissioning model so granular it can take weeks to map. Every NetSuite implementation reflects an accountant's specific decisions about how their general ledger should work, which subsidiaries roll up to which entities, which custom fields gate which approvals, and which automations run on save versus on submit.

SAP is similar in spirit and even more entrenched. A given SAP customer might be on S/4HANA, ECC, or Business One, with extensions written in ABAP, custom IDocs, and integration patterns that predate the modern API era by a decade. Sage adds yet another set of variants: Sage Intacct, Sage 100, Sage X3, all with different data models and different access patterns.

For an AI agent, this means you cannot just expose a "create_invoice" tool through an MCP server and expect it to work. You have to know which entity, which customer, which item, which class, which department, which custom segment, and which approval workflow that invoice needs to flow through, and all of that varies per tenant. A useful read on this shape of problem is Multi-Tenant ERP Integrations for AI Products: Why NetSuite, SAP, and Sage Each Break Your Architecture Differently, which lays out how each system breaks the assumption you can write one integration and reuse it.

The takeaway is the same across every system of record. The protocol layer (whether MCP, REST, GraphQL, or SOAP) is the easy part. The hard part is mapping each customer's specific configuration into a model your agent can actually reason about, and keeping that mapping correct as both the customer and your product evolve.

The Four Things MCP Cannot Give You

When teams describe what is missing from an MCP-only approach, four themes recur. None of these are gaps in the protocol itself. They are categories of work the protocol explicitly does not cover, because the protocol was never meant to.

Permissions

An AI agent operating on behalf of an end user has to enforce that user's permissions on the underlying system. If the user cannot see a record in Salesforce, the agent cannot return it. If the user cannot write to a field, the agent cannot update it. MCP servers typically run as a single service account with broad permissions, because that is the easy way to get them working. Doing it correctly means propagating per-user OAuth tokens, respecting field-level security, and degrading gracefully when permissions change. Building this yourself means writing per-system permission logic for every tool you expose, and then keeping it correct as platforms add new permission features. There is a useful framing of why this is its own discipline in Auth and Token Management Isn't an Integration, which makes the case that handling auth well is a product surface in its own right.

Aggregation

A useful AI agent often needs to combine data from multiple records, multiple objects, or multiple systems. "Show me the renewal pipeline for accounts where the support ticket count is above ten and the last QBR was more than ninety days ago" is not a single API call. It is a join across CRM, ticketing, and calendar data, and the agent needs results fast enough to feel real-time. MCP servers expose individual tools. Aggregation across tools is the application's problem, and it gets expensive fast: every aggregation either requires N round trips or a separate caching layer you have to build and maintain. Without integration infrastructure that can do scheduled reads, materialize a unified view, and serve aggregations from local storage, you end up doing a lot of slow, brittle fan-out work at agent runtime.

Per-Tenant Customizations

We covered this with the snowflake framing above, so we will keep it brief. Each customer's CRM and ERP configuration is unique, and the agent has to operate against that unique configuration. MCP tool definitions are static. They do not carry per-tenant configuration, do not version with the customer's schema, and do not give you a place to manage field mapping at the platform level. You can build all of that around an MCP server, but at that point you are building integration infrastructure with extra steps. There is a good piece on this from the agent-memory angle in Why Your AI Agent's Memory Is Only as Good as Your Field Mapping Strategy, which makes the case that the agent's effective intelligence is bounded by how accurately you map customer-specific schemas into the model's working context.

Performance and Reliability

MCP is a request-response protocol over a stream. It is not slow because the protocol is slow. It is slow because every call to a customer's CRM has to traverse the public internet, hit OAuth refresh logic, marshal a response, and come back. That is fine for one tool call. It is painful for the third or fourth one in a single agent turn, especially when the customer is waiting on the other end of a phone call or chat. There is a public quote from 11x's engineering team that captures the stakes here: "Using Ampersand, we cut our AI phone agent's response time from 60 seconds to 5." That kind of latency improvement does not come from optimizing MCP calls. It comes from having data already replicated into a layer the agent can hit instantly, with the writes batched and queued for asynchronous flush back to the system of record.

Reliability is the same story. MCP servers fail when the upstream API fails. Production integration infrastructure handles the failures: retry policies, circuit breakers, dead-letter queues, alerting, observable error states the customer can debug, and SLA-grade uptime that does not depend on any one engineer being awake.

What Production Integration Infrastructure Actually Looks Like

If MCP gives you a phone, integration infrastructure is the cellular network the phone runs on. The work that has to happen between "agent wants to read an account" and "agent gets the right data, fast, with the right permissions, in the right shape, from the customer's specific configuration" is enormous, and it is the same work for every team building agents on top of CRMs and ERPs.

This is the category Ampersand was built to occupy. We are not an MCP alternative. We are the layer underneath, the place where multi-tenant authentication, dynamic field mapping, scheduled reads, on-demand reads and writes, batched writes, custom objects, error handling, and version-controlled integration configuration all live together. Engineering teams declare what they want their integration to do in a YAML file, push it through CI, and Ampersand handles the runtime. When a customer connects their Salesforce org, Ampersand manages the OAuth handshake, refreshes tokens forever, discovers their custom objects and fields, and lets your product map those into your application's model with as much per-tenant nuance as you need.

The way this stacks with MCP in practice is straightforward. Your agent can still expose MCP tools. Underneath those tools, instead of calling a system of record directly, the tool calls Ampersand. Ampersand returns data that has already been synced, normalized, and permission-checked. Writes go through Ampersand's bulk-optimized write path, with retries and idempotency handled for you. The agent stays fast because the slow integration work happens out of band. The protocol layer stays clean because all the snowflake complexity is handled below it. There is a longer treatment of this layering pattern in How AI Agents Break Every Integration Pattern That Worked for Traditional SaaS for teams that want the architectural depth.

This is what Native Product Integrations look like in practice. They are not generic, they are not embedded inside a configuration panel that ships with your product, and they are not an MCP server with a config file taped to the side. They are integration infrastructure designed for the exact problem of operating thousands of unique customer configurations under one product, at production scale, with the latency and reliability AI agents demand.

MCP Servers vs Ampersand: A Side-by-Side

The table below compares the two approaches across the dimensions that decide whether your AI agent can actually run in production.

The point of the comparison is not that MCP is bad. It is that MCP is the wrong altitude for the production integration problem. You can build everything in the right column on top of an MCP server if you want to. Many teams do, for a while. The question is whether building and maintaining that layer is the work your engineering team should be doing, or whether they should be shipping product on top of it.

Why This Matters for Vertical AI Companies

The teams feeling this pain most acutely right now are the ones building vertical AI products: AI sales agents, AI customer service agents, AI revenue ops agents, AI billing agents, AI scheduling agents. Their entire value proposition is that the agent does real work inside the customer's existing systems of record. The agent that cannot read the customer's pipeline, cannot write to the customer's renewal forecast, or cannot respect the customer's permission model is not a product. It is a demo.

The companies that move fastest in this category decide early not to own integration infrastructure. They use a platform layer underneath their agent so their engineering team can spend its time on the agent's behavior and not on connector maintenance. The companies that decide to build this layer in-house do ship faster initially, then watch their integration backlog grow until it consumes a meaningful fraction of engineering capacity. We wrote about this dynamic in The Integration Debt Trap: Why Building Integrations In-House Breaks Down at Scale, and the shape of the curve is the same across nearly every team we have advised.

The other path teams sometimes consider is using an embedded iPaaS, the kind of generic integration tool that drops a configuration UI into your product. That category solves a different problem. It makes integrations end-user configurable, often at the cost of depth, performance, and engineering control. Embedded iPaaS works for marketing automation flows and basic data pipes; it tends not to hold up for AI agents that need real-time bi-directional reads and writes against deeply customized customer environments. There is a fuller comparison in Why migrating from embedded iPaaS to Native Product Integrations Reduces Engineering Overhead for teams weighing that tradeoff.

Vertical AI is also where the snowflake problem compounds, because the customers who buy vertical AI products tend to be the ones with the most heavily customized systems. A vertical AI product for revenue ops will sell into customers whose Salesforce org has been customized over a decade by a revenue ops team. A vertical AI product for accounting will sell into customers whose NetSuite implementation reflects three subsidiaries, four currencies, and two acquisition migrations. These are not edge cases. They are the average customer. A useful broader read on this is Why AI Agent Companies Building Vertical SaaS Need Native Product Integrations, Not In-House Integrations, which makes the case that the integration layer is what determines whether a vertical AI product can actually land enterprise deals.

The Ampersand Pitch, Made Plainly

If you are building an AI agent product and you have started accumulating MCP servers for each new customer system you need to support, the day you realize you are now operating an integration platform is the day to look at Ampersand. Ampersand is integration infrastructure for native product integrations: bi-directional reads and writes, custom objects, dynamic field mapping, managed auth, scheduled reads, backfills, bulk write optimization, on-demand endpoints, version-controlled YAML configs, CI/CD friendly, dashboards with logs and alerts, GDPR compliant and ISO certified.

Ampersand supports NetSuite, SAP, Sage, Salesforce, HubSpot, Marketo, Microsoft Dynamics 365, Zendesk, Gong, and hundreds more systems through a connector library you can extend. AI-native teams use it to ship Direct Integrations into customer CRMs and ERPs without building their own integration platform first. Hatch's CTO John Pena described the experience as moving from "months of maintenance headaches to just not thinking about it." That is the outcome we sell.

For teams who want the architectural depth, the Ampersand documentation walks through how to declare an integration, map fields, define read schedules, and wire up writes; the how it works overview lays out the runtime model end to end; and the Ampersand site covers the broader product story.

FAQ

Is MCP going to replace integration platforms like Ampersand?

No, and the framing misunderstands what each layer is for. MCP is a protocol for how an LLM calls a tool. Integration platforms are the layer that makes the tool actually work against thousands of unique customer configurations. The two compose. The most production-ready AI agents we see expose MCP tools at the top and call an integration infrastructure layer underneath those tools.

Can I just write a really good MCP server and skip all of this?

You can, for one or two systems and one or two customers. The effort scales superlinearly with the number of customers (per-tenant configuration explodes), the number of systems (each one has its own API surface, auth model, and rate limits), and the number of operations (writes are harder than reads, bulk is harder than single, scheduled is harder than on-demand). Most teams that try to build this end up with an in-house integration platform after twelve to eighteen months, and then have to maintain it forever. That is the integration debt trap, and the longer you wait to recognize it, the more expensive it is to move off of.

What about latency? My agent has to feel real-time.

This is the single strongest argument for not running production integrations through synchronous tool calls. Every API hop adds 200 to 800 milliseconds, and stacking three or four of them in a single agent turn pushes you into multi-second response times that destroy the user experience. The way to fix this is to replicate the data the agent needs into a layer it can hit in single-digit milliseconds, and to push writes asynchronously with idempotency guarantees. That is what Ampersand's architecture is built for, and it is why teams like 11x have seen 60-second response times collapse to 5 seconds after migrating off of synchronous integration patterns.

How do I handle per-customer custom fields and objects?

You need a field mapping layer that lets each customer (or your team on behalf of each customer) tell the agent which of their fields correspond to your product's data model. The mapping has to be discoverable from the customer's actual schema (Ampersand pulls custom fields and objects out of Salesforce, HubSpot, NetSuite, and Dynamics automatically), versionable, and queryable at runtime. Building this from scratch is non-trivial, especially the discovery and reconciliation logic, and it is the single most common piece of work that pulls product engineers away from product work.

Does this work for non-CRM systems too?

Yes. Ampersand supports CRMs, ERPs, GTM tools, HRIS, accounting platforms, ticketing systems, sales engagement, marketing automation, and the long tail of vertical SaaS through its connector library. The same patterns apply: managed auth, dynamic schemas, bi-directional reads and writes, scheduled syncs, and observability are useful in every system of record. AI agents that need to operate across multiple categories (read from CRM, write to ERP, log to ticketing) get the most leverage from a unified integration layer.

Is this only relevant for enterprise customers?

It is most acute for enterprise customers, because their CRM and ERP environments are the most customized and their permission requirements are the strictest. The same dynamics show up in the upper mid-market and even with smaller customers who happen to have a heavily customized Salesforce or HubSpot setup. The size of the customer is less predictive of integration complexity than how long they have been running their system of record and how much custom work has accumulated in it.

Conclusion

MCP solved a real problem and deserves the adoption it has gotten. It is the right primitive for letting an LLM call a tool. It is not, on its own, the right answer for production AI agents that need to operate inside enterprise CRMs and ERPs. The work of multi-tenant authentication, per-customer field mapping, custom object support, permission enforcement, aggregation, fast reads, batched writes, and reliability under partial failure is its own category of software, and pretending otherwise leads to a slow death by a thousand cuts as your engineering team accumulates integration debt one customer at a time.

Every CRM is a snowflake. Every ERP is a worse one. The teams that ship AI agents into those environments without owning that complexity are the ones using integration infrastructure built for exactly this shape of problem. If that is the trajectory you are on, Ampersand is the layer to look at, and the question worth sitting with is the one that decides whether your agent is a demo or a product: who owns the snowflake, you or your platform.