Most operators buying AI capability right now are thinking about the immediate use case. What does this agent do, does it do it well, what does it cost. That is a reasonable frame for a first purchase. It becomes a less useful frame once you are running two or three agents and the question shifts from what does this one do to what do all of these know, and can they learn from each other.
The performance of an AI agent is not a fixed property of the agent itself. It is a function of what that agent can see: the data it has access to, the memory it carries from previous interactions, and the context it inherits from the rest of the system. An agent running in isolation, drawing only on its own history, is fundamentally limited in a way that an agent running inside a shared intelligence environment is not. This is the core argument for a platform architecture over a collection of point solutions. Not that point solutions are bad at their individual job, but that isolation has a ceiling.
The problem is that the platform argument is easy to dismiss when you are buying the first agent. The overhead of fragmented systems is not visible yet. The compounding admin cost, separate dashboards, separate vendor relationships, separate monitoring for each capability, has not accumulated. It only becomes tangible once the estate has grown, and by then the structural decision has already been made.
What your agents know about each other
The operators who are thinking most clearly about this tend to ask a different question from the start. Not just what the agent does, but where it lives and what it can see. A sales agent that has no visibility into what a retention agent has learned about the member base is working with a partial picture. A member services agent that cannot see what the sales conversation understood about a member’s original motivation is starting from scratch every time. The intelligence is there in the business, in the data, but it is siloed by architecture.
There is a secondary concern worth naming directly. Operators who have deployed multiple standalone agents often find themselves managing an estate that grows harder to oversee as it grows larger. Each agent is a separate system to monitor, a separate vendor to hold accountable when something goes wrong, a separate knowledge base to maintain. The AI is doing more, but so is the operator, and the things the operator is now doing are less visible and harder to fix when they break.
The interoperability problem, and how it got solved
There is a counterargument that is worth taking seriously. No single platform is going to serve every operator need equally well. There will always be use cases that are too specific, too niche, too tied to a particular facility type or operational model, for any general platform to build natively. A padel facility wanting specialist retention analytics for racquet sports. A competitive swimming club with performance data that has no equivalent in the standard fitness operator model. A studio running high-volume personal training programmes with detailed coaching data attached to every session. These are real needs, and the fact that a platform would not prioritise them does not make them less legitimate.
For a long time, this tension between platform coherence and specialist capability had no clean resolution. You either accepted the platform’s limitations, or you started buying specialist tools and accepting the fragmentation that came with them. That has started to change.
The agent interoperability problem has been a recognised issue in the industry since the earliest public discussions of how agents from different systems could communicate, which began in earnest in 2025. The protocol that emerged from those discussions, known as A2A, started as a Google initiative in April of that year and was picked up almost immediately by a wide range of technology organisations who saw the same problem. It has since been contributed to the Linux Foundation, reached version 1.0 in April 2026, and now has production support across Google Cloud, Microsoft Azure, and AWS, with over 150 organisations formally behind it. A competing standard that IBM had been developing merged into it last August. The market found a single answer faster than most protocol contests do.
What A2A defines, in plain terms, is how agents from different vendors discover each other, authenticate, and exchange tasks cleanly, without bespoke integration work on either side. An operator running a primary platform that supports this standard can integrate a specialist agent for a niche use case without that agent sitting outside the system, disconnected from the shared intelligence, invisible to the governance layer, and generating its own admin overhead. The specialist agent joins the platform rather than running alongside it.
What this means for how you build your AI estate
This matters because it means the platform decision and the specialist capability decision are no longer in tension. An operator can choose a primary environment for its shared intelligence and lower administrative overhead, and still add a specialist agent for a specific need, without returning to the fragmented model they chose the platform to avoid. The specialist capability inherits the context of the broader system. Observability stays in one place. The improvement that happens across the platform over time applies to the integrated specialist agents as well, not just the ones the platform built itself.
The operators who will get the most from AI over the next few years are almost certainly the ones who made a coherent architectural decision early, before the estate got complicated. Not because they predicted exactly which agents they would end up running, but because they chose an environment that could accommodate what they could not predict. The first agent is the easiest part of the decision. The harder question, and the more important one, is what happens when you need a second.
