The protocols are just plumbing. What you actually need is an orchestration layer that captures your business domain.
Everyone's talking about AI commerce protocols. MCP from Anthropic. UCP from Google. ACP from OpenAI. They're important, and they're the standards that will let AI agents interact with commerce systems.
But implementing these protocols doesn't make you AI-ready. You can have perfect MCP and UCP support and still have a mess. The protocols define how to communicate. They don't solve the real problem: giving your customers a consistent experience regardless of which channel they use.
Think about it. A customer browses your website, adds something to their cart, then asks an AI agent to complete the purchase. If the agent sees different prices, different stock levels, or applies different discount rules, you've broken the experience. Worse: you've broken trust.
What actually matters is the layer between those protocols and your backend systems. The orchestration layer that ensures every channel, whether that's your website, mobile app, or an AI agent, operates from the same source of truth. Same prices. Same availability. Same rules. Same experience.
Let's take the example of building a virtual shopping assistant, that helps the customer, based on what they know of the customer, to find new products in the catalogue, select the right variant or size, and place & pay the order.
To enable the Agent to perform these actions, we need a technical interface that it can talk to. Isn't this what all the MCP servers of the SAAS vendors can be used for? Or the recent announcements around ACP (agent commerce protocol)...
We don't think so. In order to act on behalf of your business, the agent should be aware of the business context: the glue that makes your implementation yours and prescribes how your business operates and wants to behave, what it allows and what it doesn't.
The problem with direct MCP integrations of the SAAS vendors as well as ACP directly on SAAS vendors, is that it lacks business context! It has no overarching awareness of it, or the system that you've built to operate it.
What you need instead, is a well designed API integration and orchestration component in your architecture, that provides this business context across several SAAS integrations and custom microservices.
Your business has rules. Pricing tiers for different customer segments. Promotions that only apply under certain conditions. Stock allocation across warehouses. Return policies that vary by product category. These rules define how your business operates.
Without a central orchestration layer, each channel implements these rules independently. Your web team builds the pricing logic. Your app team builds it again, slightly differently. Your AI agent integration? Another implementation. Three channels, three versions of "the truth", and customers who notice the inconsistencies.
A good integration layer captures this business domain in one place. It becomes the single source of truth that all channels consume. Whether a customer is on your website, your app, or talking to an AI agent, they get the same prices, the same promotions, the same experience.
SAAS services provide capabilities to implement your own business domain model
Your business domain model is constantly moving: the business expands, changes direction, wants to leverage new tools that are made available every day. A bad integration approach will slow you down and eventually block you from making significant progress. Unfortunately, this is where it often goes wrong and where the big bowls of entangled, tightly coupled spaghetti are created.
We see a lot of anti-patterns:
Integrating with MACH services directly from channels
, duplicating business logic and leading to inconsistent omni-channel experience
Creating a single BFF layer
that's tightly coupled to SAAS services behind the scenes
Creating a BFF per channel
, duplicating your business logic
Low-code integration solutions
that are hard to manage and have low performance
Building a proxy on top of MACH services
, leaking vendor API details
Stitching together different GraphQL schemas
with conflicting data models (we did this and are still working on getting rid of it)
What do you need to properly implement your business domain using APIs? Here are the requirements we see:
Flexibility
: integrate any API that lives anywhere, using any protocol or technology
Customisability
: implement any kind of business logic, full control over behaviour
Decoupling
: change parts without affecting the whole system
Scalability & performance
: scale across load, languages, brands, markets, and channels
Composability
: pick up isolated domains and leverage them elsewhere
Accessibility
: open technologies and industry standard protocols
Sovereignty
: own it and host it wherever you want
Statelessness
: state handled by integrated systems, not the layer itself
When we look at these requirements, this is quite something. Some would say it is utopian to require all of that in a single solution.
At Lab Digital, we've spent years building commerce platforms. We've learned that the key is having one unified API that represents your entire business domain. A single interface that all channels can talk to, whether that's your website, mobile app, or an AI agent.
This API becomes the single source of truth for how your business operates. It implements your pricing rules, your availability logic, your checkout flow, your bundling and promotions. It's the technical representation of your business.
When an AI agent connects to this API, it doesn't need to understand five different vendor systems. It gets one coherent interface that already encapsulates your business context.
The major AI players are converging on similar patterns. Anthropic, OpenAI, and Google rarely agree on anything, but they all agree that AI agents need standardized ways to interact with commerce systems.
MCP (Model Context Protocol): Anthropic's standard for AI-to-system connectivity, now with 97M+ monthly SDK downloads
UCP (Universal Commerce Protocol): Google's commerce standard, developed with 20+ partners including Shopify, Walmart, Target, Stripe, and Visa
ACP (Agent Commerce Protocol): OpenAI/Stripe's approach to transaction execution
A2A (Agent-to-Agent): Google's inter-agent communication protocol
These protocols are important. They're the plumbing that makes AI commerce possible. But the protocols themselves are not the answer. You can implement MCP, UCP, and ACP on your platform and still have a mess.
Why? Because protocols only define how to communicate. They don't provide the business context that makes your commerce experience yours. They don't know your pricing rules, your inventory logic, your checkout flow.
This is exactly what we've built with Evolve: an orchestration layer that sits between the AI agents (via any protocol) and your backend systems, providing the business context that makes everything work.
When an agent asks for products matching a customer's request, Evolve returns items from your catalogue, filtered by your availability rules, priced according to your pricing logic.
When adding to cart, Evolve handles bundling rules, promotions, and inventory checks. When completing an order, it orchestrates payment, fraud checks, inventory reservation, and order creation. All according to how your business operates.
The SAAS vendors provide the raw capabilities. Evolve provides the business context. The AI agent gets a coherent, reliable interface that represents your brand, regardless of which protocol it's using.
We've been running this architecture in production across 40+ commerce sites, processing over €2 billion in yearly revenue. It works.
When we decided to add AI agent capabilities to our platform, we didn't need to rebuild anything. The GraphQL API that powers our storefronts is the same API that powers our AI agents. We implemented support for the Universal Commerce Protocol in about a day, because the hard work of modelling the business domain was already done.
To put that in perspective: building protocol support from scratch typically takes 6-12 months. With a proper GraphQL foundation, it takes weeks. We can auto-generate UCP manifests from our schema, the capability declarations write themselves, and the business logic is already encapsulated in our resolvers.
This is what being "AI ready" actually means. Not having APIs (everyone has APIs). Not implementing MCP on top of your SAAS vendors (that's table stakes). It means having a well-designed orchestration layer that encapsulates your business context and exposes it through a clean, typed interface.
If you're looking at your current architecture and seeing some of the anti-patterns we mentioned, you're not alone. We've helped plenty of organisations untangle these situations.
The good news: you don't need to rebuild everything at once. A federated approach lets you strangle the legacy piece by piece, domain by domain. Start with one subgraph (products, content) and prove the pattern. Then expand.
The important thing is to start thinking about this now. The businesses that figure out their AI integration strategy in 2025 will have a significant head start over those who wait until it's urgent.
We're happy to share more about how we've approached this with Evolve. Reach out if you want to dig deeper.