How frontier models and MCP can turn connected enterprise platforms into a composable intelligence layer.
Executive Summary
For years, enterprise platforms have invested in an integration fabric, the connections that let point-of-sale, ecommerce, CDP, marketing, analytics, and loyalty systems exchange data and run predefined processes. Frontier models and the Model Context Protocol (MCP) now make possible an intelligence fabric above those connections, where AI agents discover the capabilities of each platform and combine them around an objective. The underlying systems still provide trusted data, business rules, security, and accountability. MCP does not replace APIs. It consumes them, adding the context a model needs to understand and safely use what is already there.
Imagine starting the day with a briefing from your loyalty program before opening a dashboard. It tells you what changed overnight, which member groups are behaving differently, where offer performance has moved, and which opportunities deserve attention. You ask a follow-up question, explore an audience, compare possible treatments, and prepare a recommendation without navigating across several platforms or knowing where every capability lives.
That experience is becoming possible because frontier models can do more than generate content. They can reason across the systems an organization already uses, discover the capabilities available to them, and coordinate those capabilities around an objective.
What is the integration fabric?
For years, enterprise platforms have invested heavily in what I think of as an integration fabric. Point-of-sale systems, ecommerce platforms, customer data platforms, marketing tools, analytics environments, service desks, and loyalty platforms exchange data and execute predefined processes. Those integrations remain essential, but they still rely heavily on people knowing which systems to use, where information lives, and how the pieces fit together.
What is the intelligence fabric?
AI introduces the possibility of an intelligence fabric above those connections. The underlying platforms continue to provide trusted data, business rules, transactions, security, and accountability. The model helps people understand what is available across the ecosystem and combine those capabilities without requiring every possible journey to be designed in advance.
How does MCP fit with existing APIs?
Model Context Protocol, or MCP, is one of the standards making that possible. MCP gives AI applications a consistent way to discover and use capabilities exposed by external systems. An MCP server describes what a platform can do, what information it can provide, what inputs are required, and how each capability can be invoked. An authorized AI assistant or agent can then understand the tools available to it and select the appropriate ones as it works toward an outcome.
MCP does not make APIs obsolete. In our architecture, MCP consumes the APIs we already provide. Those APIs continue to authenticate users, retrieve data, execute transactions, apply business rules, and protect the integrity of the platform. MCP adds the context a model needs to understand what those capabilities do, when they may be useful, and how they can be combined.
Public APIs went through a similar transition. At the turn of the millennium, exposing a platform programmatically was still an emerging product decision. Within a decade, APIs had become foundational because they allowed systems to exchange data, automate processes, and participate in broader ecosystems. Today, it is difficult to imagine a serious enterprise platform without them.
I believe MCP is at a similar point. APIs made software accessible to other software. MCP makes the capabilities behind that software understandable to models that can reason and act on behalf of people.
This does not mean MCP will replace every traditional integration. Large data movements, real-time transaction processing, event streams, and tightly governed operational pipelines will continue to rely on purpose-built APIs and integration patterns. MCP is not a shortcut around identity, permissions, privacy, auditability, or transaction integrity. It gives agents a standardized way to use trusted capabilities without weakening the systems behind them.
What does this look like in a loyalty program?
MCP can amplify the value of integrations that already exist and, in some cases, remove the need for another narrow point-to-point integration. Consider a service representative helping a loyalty member. Today, the representative may rely on a custom integration that exposes a fixed set of loyalty fields, or they may need to open another application, authenticate again, search for the member a second time, and navigate an unfamiliar platform. With MCP, the AI agent inside the service desk could use governed ES Loyalty™ capabilities to review recent activity, explain a balance change, identify an available offer, or answer a program question without requiring another fixed interface for every possible question. The underlying ES Loyalty APIs, permissions, and controls would still perform and govern the work, but the agent could discover and use the appropriate capability in context.
This matters because Exchange Solutions already operates within extensive client ecosystems. ES Loyalty connects with point-of-sale systems, ecommerce platforms, mobile applications, customer data platforms, marketing tools, analytics environments, payment systems, partner networks, and client data infrastructure. We have spent years making loyalty part of a broader operating environment rather than an isolated application.
Frontier models can unlock far more value from that connected ecosystem. A loyalty leader could start each morning with the kind of briefing described earlier, delivered through email, Slack, Teams, or the AI assistant their organization has standardized on. The same agent could continue the investigation by requesting additional information from ES Loyalty, reviewing signals from other systems, exploring a potential audience, comparing treatment strategies, and preparing a recommendation. Depending on the client's governance, it could stop there, route the recommendation for approval, or invoke additional capabilities to move the work forward.
Different stakeholders could use the same ecosystem in very different ways. A marketer might explore engagement and campaign opportunities. Finance might focus on program economics and liability. A service representative may need to understand the activity of a single member. An executive may simply want to know what changed, why it matters, and where attention is required.
Many of those capabilities already exist. What changes is who can access them and how easily they can be used.
How does this change enterprise software?
Enterprise software has traditionally required people to learn how the platform is organized before they can get meaningful value from it. Users need to understand its terminology, navigation, reports, and workflows, and training often focuses as much on finding capabilities as it does on applying them.
MCP begins to reverse that relationship. Instead of requiring every stakeholder to become an expert user of every platform, their AI can discover the available capabilities and help them use those capabilities through the language and objectives they already understand. People will still need business expertise, judgment, and accountability, but they will not need the same depth of product-specific knowledge simply to begin exploring what the platform can do.
The potential of the platform no longer has to be discovered one screen at a time.
This shift should also cause product teams to revisit their roadmaps. Some features that once would have required another screen, report, or predefined workflow may be delivered more effectively by a frontier model using capabilities that already exist. Natural-language exploration, summarization, guided analysis, and cross-system navigation are obvious examples.
That does not reduce the importance of product development. It changes where the investment belongs. Product teams will need to distinguish between durable platform capabilities that must be built, governed, and supported, and interface features that an agent may be better positioned to assemble around the user's objective. In some cases, the best way to deliver a planned feature may no longer be to add another destination inside the application.
Why composability and grounding matter
This is why composability matters so much to Exchange Solutions. We have deliberately built ES Loyalty as a set of capabilities that can operate independently and be combined around different client needs. APIs made those capabilities available to developers and integrations. MCP makes them discoverable and usable by agents.
Our loyalty intelligence layer provides the grounding that general-purpose models cannot supply on their own. Frontier models can reason, summarize, and orchestrate, but they do not inherently understand a client's loyalty program, members, offers, economics, configurations, or business rules. They need trusted data and context from the platforms that do.
The frontier model brings general reasoning. Exchange Solutions brings the loyalty intelligence, program context, composable capabilities, and accountability behind the result.
That is the role we are positioning ES Loyalty to play within the client's intelligence fabric. We do not need to own the client's assistant, interface, or broader AI strategy. The client may choose Microsoft Copilot, ChatGPT, Claude, Gemini, a self-hosted model, or something that has not yet emerged. Our responsibility is to ensure that when their AI needs to understand a member, assess program performance, discover an audience, recommend an offer, or act within the loyalty program, ES Loyalty is available as a trusted and governed source of those capabilities.
Why this will become table stakes
I expect this will become table stakes much faster than many organizations anticipate. At one time, APIs were an emerging feature that differentiated enterprise platforms. Before long, a platform without them was isolated from the client ecosystem. As more work moves through AI assistants and agents, a platform without governed, agent-accessible capabilities risks becoming invisible in much the same way.
The question will not be whether every software vendor has added another proprietary chatbot. It will be whether the client's chosen AI can understand what the platform knows, discover what it can do, and safely use those capabilities alongside the rest of the client's ecosystem.
We have spent years building an integration fabric that allows enterprise systems to exchange data and execute processes. Frontier models and MCP create the next opportunity: an intelligence fabric where agents can navigate those systems on behalf of people, make their capabilities accessible to a broader group of stakeholders, and bring the combined value of the ecosystem into the flow of work.
APIs allowed systems to work together. MCP and frontier models will help people realize far more of what those connected systems can do.
Build for the intelligence fabric
See how Exchange Solutions exposes governed, composable loyalty capabilities so intelligent agents, and your team, can orchestrate work across the systems you already run.
Frequently Asked Questions About ES Loyalty
Find answers to common questions about our platform and solutions