MCP vs Custom Integrations: Rethinking Enterprise AI Connectivity

Every enterprise conversation about the Model Context Protocol begins as though the integration estate were a blank sheet of paper. It never is. The more useful question is not what to migrate, but which of the connections you already own deserve to be left exactly where they are.

Somewhere in a large company right now there is an integration architect with a spreadsheet open, and the spreadsheet has around four hundred rows in it. Each row is a working connection between two systems: a nightly file that moves closed invoices from the ERP into the warehouse, a webhook that tells the fulfillment system when an order clears fraud review, a synchronization job written by a contractor in 2017 that keeps two customer tables in agreement and has not been touched since, because it has not needed to be. Most of these connections are unglamorous and none of them are broken. Then a VP forwards an article about agentic AI and asks, in the tone of someone who believes this is a small question, what the plan is for migrating all of it to MCP.

The honest answer is that most of that spreadsheet should never be migrated at all, and the reason has nothing to do with effort or risk appetite. It has to do with what a custom integration actually costs an organization over its life, which is almost never what it cost to build. The instinct to treat four hundred point-to-point connections as four hundred units of technical debt is the single most expensive misreading available in this moment, because it converts a manageable, targeted piece of work into a multi-year program that will be half-finished when the budget cycle turns and someone asks what it bought.

Most of the estate is already finished

There is a habit in enterprise architecture of treating age as a defect. An integration written eight years ago in a style nobody would choose today feels like something that ought to be dealt with, and the feeling is strong enough that it usually survives contact with the evidence. But the cost of a piece of software is not incurred when it is written; it is incurred every time it has to be changed, understood by someone new, or extended to do something its author did not anticipate. An integration that moves the same fields between the same two systems on the same schedule, has one caller, and has not required a code change in three years is not accruing that cost. It is a solved problem with a runtime bill attached, and the only rational thing to do with a solved problem is leave it solved.

This is where the standard argument for a shared protocol quietly overreaches. The genuine weakness of bespoke integration work is not that any individual pipe is badly built — plenty of them are built fine — but that the effort does not compound. Every connection carries its own authentication handling, its own retry behavior, its own understanding of how the source system paginates and what its error codes mean, and none of that knowledge is available to the next person who needs to reach the same system. That is a real and serious weakness, and it is also entirely dormant as long as there is exactly one consumer. Nobody pays the non-compounding penalty on an integration that never has a second caller. The waste is potential, not actual, and rewriting it converts potential waste into actual spend.

So the first move in any serious assessment is subtraction. Walk the estate and mark every connection that serves a single consumer, moves a stable set of fields, and has a change history that flatlined years ago. In most enterprises that will be the clear majority of the rows, and every one of them is finished work. They do not need a protocol surface, a capability description, or a modernization ticket. They need to be left alone, monitored the way they already are, and removed from the conversation entirely so that attention can go where the actual economics are changing.

The second consumer is the event that changes the math

What makes a custom integration expensive is not time and not age but arrival — the moment a second thing needs the same data. Until then, a bespoke connection and a protocol-exposed one are economically indistinguishable, because the only advantage of the shared approach is that it can be reused, and nothing has asked to reuse it. After the second consumer arrives, the two diverge immediately and permanently. The second team building against the same system starts from nothing: they re-negotiate credentials with whoever owns the source, rediscover which of the four customer identifiers is the one that actually joins, re-derive that orders in one particular status are test records that must be filtered out, and encode all of it privately in their own codebase. The third consumer repeats the exercise. By the fifth, the organization has five slightly different working definitions of what a customer is, and the divergence is semantic rather than technical, which means no amount of monitoring will surface it. It shows up as two reports disagreeing, and it takes a week to find out why.

This is the specific failure that a shared protocol addresses, and it is worth stating in plain terms because the usual framing obscures it. The Model Context Protocol gives a system one described, discoverable way to expose what it can do and what it knows, so that any client capable of speaking the protocol can use it without a bespoke agreement negotiated in advance. The value is not that it is newer or cleaner than a custom connector. The value is that the second, third, and tenth consumer inherit the first consumer's hard-won understanding of the source system instead of reconstructing it — and that inheritance is worth nothing at all until the second consumer exists.

Which is why the arrival of autonomous AI workers changes the triage without changing the principle. An AI worker is not a second consumer in the ordinary sense; it is an open-ended one. You cannot enumerate in advance what it will need to ask a system for, because the whole point of giving work to something that reasons is that it decides which questions to ask as the work unfolds. The autonomous-enterprise publication enterpriseautonomy.ai has made a version of this argument in operational terms: the connective work an enterprise most wants to hand to software is precisely the work that crosses systems unpredictably, and unpredictable crossing is exactly what a fixed, single-purpose pipe cannot serve. The moment a system is in scope for autonomous work, it has effectively acquired a second consumer with an unbounded appetite, and the math has already flipped whether or not anyone has filed a ticket.

Wrap what earns it, rebuild almost nothing

The practical consequence is a triage list with three buckets, and the third one should be nearly empty. The first bucket is everything you leave alone, which is most of the estate. The second is the set of systems where a second consumer has appeared or is imminent — usually a handful of the crown-jewel sources, the ones every new initiative asks for first: the customer master, the order and ticketing systems, the document repositories, whatever holds pricing. Those earn a described protocol surface, and the crucial detail is that earning one does not mean replacing anything. The existing nightly job keeps running for its existing consumer. What gets added is a shared, described way in to the same underlying system, sitting alongside it, so that every new consumer after this one starts from a definition rather than from a discovery project. Capabilities like StudioX's Instant MCP exist precisely to make that wrapping cheap enough that it stays a wrapping and does not turn into a rewrite, because the moment it becomes a rewrite the whole economic argument collapses.

The third bucket — genuine rebuilds — is reserved for the small number of cases where the underlying access itself is the problem: an integration nobody understands, whose author is gone and whose behavior is only known empirically, sitting in front of a system several teams now need. That is a real hazard, and it was a hazard before anyone mentioned a protocol. Everything else that feels like it belongs in this bucket usually belongs in the first one, and the pressure to move it comes from tidiness rather than from cost.

Keeping the third bucket small is also the best available defense against the failure mode that swallows this kind of program. Gartner has predicted that over forty percent of agentic AI projects will be canceled by the end of 2027, pointing to escalating costs and unclear business value among the reasons. A four-hundred-connection modernization effort is the archetype of that outcome: enormous, uniformly expensive, and structured so that no value arrives until a great deal of money has been spent. Wrapping six systems that a dozen consumers are already queuing for produces something usable in a quarter and leaves the rest of the estate undisturbed, which is both cheaper and considerably easier to defend when someone asks what it bought.

The reframe worth carrying out of this is that an integration estate is not a portfolio of assets with vintages, some of them due for replacement. It is a map of who talks to what, and the only property that matters on that map is how many listeners each line has. Stop maintaining a migration roadmap organized by age and technology, and start maintaining a consumer census organized by demand — because the connections with one listener are finished, permanently, no matter how old they look, and the ones about to acquire a second are the entire job.