The question that keeps coming up in Exec meetings right now is some version of: "How do we get our products in front of AI agents? How do we show up when someone asks ChatGPT to find what we sell?"
That is a legitimate question. Agentic Commerce is arriving, and organisations that are not visible to AI platforms will be invisible online.
It's the correct place to start, and it is also the wrong place to stop, because solving for agentic commerce properly means solving a much bigger problem: how to make the next AI agent trivially cheap to deploy, and the one after that even cheaper.
Most organisations have spent the last eighteen months building one-off AI automations.
Someone on the team gets a meeting notes summariser working, so another team builds a support ticket triage workflow, and then finance wants a reporting agent that pulls numbers from a dashboard.
They all work fine. The problem is that every single one costs a similar ballpark to build, because largely each agents starts from scratch in the organisations we're talking to.
Meanwhile...
The signal captured in customer service never reaches the sales team.
A pattern the CRM flagged three weeks ago still has not surfaced anywhere near the operations dashboard.
Everything runs in its own little silo, and silos do not compound. They definitely do not get cheaper with repetition.
The organisations pulling ahead have stopped asking "what should our next AI project be?" and started asking something harder: "How do we build this so that any agent, internal or external, can access the right data under the right rules without someone rebuilding the plumbing every time?".
That is really a question about how to make agent building scalable.
Forget the acronyms for a moment.
Every business has data spread across systems: the CRM, the ERP, the knowledge base, the data warehouse. Right now, when an AI agent needs something from one of those, someone has to build a custom connection for that specific agent talking to that specific system. So agent number one costs $20-50K. Agent number two costs another $30K. By agent number ten, the finance team is asking why AI keeps showing up as a line item that never gets smaller, despite the headlines of how easy and cost effective cheap AI is to implement. The cost curve is flat because there is no shared infrastructure underneath.
The fix is Shared AI Infrastructure, made up of two parts.
Wrap each system in a standardised access point so any authorised agent can interact with it the same way
And then put a governance layer across all of those access points so there is one place to manage permissions, one audit log, and one set of rules.
In the technical world, the access points are called "MCP servers" (Model Context Protocol, an open standard now governed by the Linux Foundation with backing from Anthropic, OpenAI, Google, and Microsoft). The governance layer is called an "MCP gateway". The labels matter far less than what they do: turn agent deployment from a flat cost line into a curve that bends down with every new agent.
The diagram below shows the basic architecture.
On the right, the AI platforms (Claude, ChatGPT, internal copilots) act as "MCP hosts", the things doing the thinking.
They talk through "MCP clients" to the MCP servers on the left, which are the standardised access points wrapped around each business system: Gmail, Google Calendar, Slack, the CRM, local databases, and so on.
Each server knows how to speak its system's language so the AI does not have to.
What the diagram does not show is the Shared AI Infrastructure layer: the MCP gateway. It sits above all of those servers and acts as the single front door for agent access, permissions, and audit.
Internal operations agents, first-party customer-facing agents, and third-party agents on external platforms all connect through the gateway, not directly to individual servers.
This is the shared control layer. It decides who gets access to what, logs every interaction, and enforces one set of rules across every agent and system.
Without it, every agent type needs its own set of connections and its own permission model.
With it, adding a new agent, whether it is an internal copilot or an external shopping bot, is a configuration change rather than a development project.
Easiest way to think about it is a corporate office.
Each department has a receptionist who knows what is on their floor.
The lobby has a security desk that verifies identity, issues access cards, and keeps a record of who went where.
Without the lobby, every floor runs its own security with its own rules and its own gaps, and adding a new floor means building a whole new security operation.
With the lobby, adding a new floor means issuing a new access card.
That is the difference between scaling agents and just adding more of them like point solutions.
Why every executive role should care
This does not start off as a technology project. It is a decision about whether AI scales in the business or stays a collection of expensive one-offs.
The CEO should be thinking about whether AI compounds or just accumulates. Every future investment either builds on a shared layer or starts from scratch. The twentieth agent should cost a fraction of the first.
The CFO is looking at standalone costs on every new AI initiative. Shared infrastructure changes the maths, and one audit log beats five that nobody reconciles.
The COO needs cross-functional intelligence. An agent that sees signals from sales, customer service, and inventory in a single governed view only works when the data infrastructure supports it.
The CMO has two problems that share a root cause. Agentic commerce needs product data that is accurate, structured, and accessible to external AI platforms. Internal marketing needs the same data feeding campaign agents and personalisation engines. Build it once, serve both.
The CTO and CIO are watching shadow AI emerge: the 2026 version of shadow IT. Centralised infrastructure means one policy, one audit trail, and a simpler architecture. The CTO's team stops being the bottleneck for every new agent deployment.
"But we already have a data warehouse"
This is the most common objection. A fair one in some sense, but it comes misguided.
A data warehouse stores and aggregates data. What it does not do is decide which agents can access which data, under what conditions, with what audit trail. The marketing team, an external commerce bot, and a customer service agent all need different access rules. The warehouse stores everything and governs nothing.
The gateway does not replace the warehouse, it sits alongside it. The warehouse answers "where does our data live?" and the gateway answers "who gets to use it, how, and can we prove it?" Without both, agents cannot scale safely.
What this looks like across the business
The CEO asks an AI assistant for a quarterly snapshot. The gateway verifies the executive role, pulls high-level metrics from the ERP and a sales summary from the CRM.
The finance team, using the same infrastructure, sees the detailed breakdown. Same systems, different views, one set of rules. That is agent number five running on infrastructure built for agent number one.
Then an external shopping agent on a third-party platform asks for product availability. The gateway returns only publicly available inventory data. Nothing internal, nothing financial, and the interaction is logged. That external agent can be deployed in days rather than months, because the access points and rules were already in place.
When the supply chain team decides it needs an anomaly detection agent, the integration work is minimal. The ERP access points were already wrapped and governed for those earlier agents. Agent number eight cost a tenth of agent number one.
Trade-offs to note
It would be dishonest to present this as the answer to everything.
Perplexity's CTO recently said the company was moving away from MCP internally, favouring traditional APIs for production systems. The issue was overhead: in some deployments, the protocol consumed significant resources (clogging context window leads to context rot) that could have been used for actual processing. Garry Tan at Y Combinator built a custom command-line tool instead of using MCP, citing speed and reliability.
Those criticisms land in specific contexts (and I won't pretend to be technical enough to overexplain the differences):
APIs are faster and leaner when the set of tools is fixed and known in advance, and direct connections give technical teams low-overhead access.
The orchestration layer earns its keep where governance, multi-system coordination, and audit trails are non-negotiable, which tends to be exactly where agent scalability matters most.
In practice, most organisations will end up running a hybrid.
Centralised orchestration around sensitive data and cross-system operations, direct API connections where speed is the priority and governance is less critical. The question is not which approach to pick but where centralised governance creates enough value to justify the layer, and where it just adds friction.
How to decide where to start
The entry point is business impact.
Follow the revenue pain. If agentic commerce is the catalyst, start there. Make product data accessible, governed, and accurate for external platforms. That work immediately benefits internal agents too, so the infrastructure starts paying for itself on agent two.
Follow the data fragmentation. Where does scattered data actually cost money, time, or customer trust? Maybe support tickets take too long because customer history is split across three systems. Maybe sales forecasting is unreliable because the CRM and ERP do not talk to each other. Fix that junction, and the next three agents that need the same data get it for free.
Follow the existing agents. Most organisations already have AI running inside Copilot, their CRM, their service desk. Those agents are already accessing data, often with inconsistent rules and no audit trail. Wrapping governance around what already exists is faster than building from scratch, and it sets the foundation for everything that follows.
The sweet spot is where those three overlap: revenue impact, fragmented data, and existing ungoverned agent activity. Prove value there, measure the cost curve change, and expand.
The progression
Not every organisation needs a full gateway on day one.
Stage 1 is where most organisations sit right now. Individual agents connected to individual systems. They all work, but a win in customer service teaches the sales team nothing, and agent number ten costs the same as agent number one.
Stage 2 is wrapping key data sources in standardised access points so any agent can interact with them the same way. This is where the cost curve starts to bend. The second agent connecting to a wrapped system costs less than the first, and by the fifth, it costs almost nothing.
Stage 3 is Shared AI Infrastructure: a governance layer across all access points, with centralised access control, a single audit log, and reusable rules across agents. Deploying a new agent becomes a configuration exercise, not a development project.
The tipping point between stages tends to show up when changing a permission means updating five systems instead of one, or when nobody can answer "what data has been accessed, by which agent, and when?".
Future proofing the business
The organisations building this infrastructure now are not just preparing for agentic commerce, although that is often what starts the conversation. They are building the layer that determines whether AI scales across the business or stays a collection of expensive experiments.
The question is not whether to invest in AI agents. That decision is already made. The question is whether the tenth agent costs the same as the first, or a fraction of it. That is an infrastructure decision, and it is the one that separates organisations that scale from those that just spend.
Passionate about all things AI, emerging tech and start-ups, Mike is the Founder of The AI Corner.
Subscribe to The AI Corner
