AI Agents Are Opening Up, but What About the Data?

Picture a company running a dozen AI agents. One monitors supply chain disruptions, another handles customer support and a third helps developers troubleshoot applications. Others might analyze financial data, prepare reports or automate routine IT work. Those agents may come from different vendors and run on different models, but that doesn't stop them from working together effectively. A growing set of open protocols is giving developers common ways to connect systems that previously required custom integrations. Google's Agent2Agent Protocol, better known as A2A, gives independent AI agents a way to discover one another, as well as communicate and delegate work. Model Context Protocol, or MCP, addresses another piece of the puzzle by standardizing how AI applications connect to external tools and data. The effort gained more momentum in August when A2A moved to the Agentic AI Foundation, joining MCP and other open agent infrastructure projects under the same umbrella. A2A is already backed by more than 150 companies and other groups, with the protocol being put to use in areas including financial services, supply chains and mobile platforms. Developers are getting better tools for connecting agents, but another interoperability question is starting to surface. Those agents still need access to company data, and changing the agent doesn't make that underlying data any easier to move, govern or protect. The Agent Layer Is Getting Easier to Mix and Match Companies experimenting with AI agents have had to make important decisions about models and frameworks, knowing that the technology they choose could look very different a year from now. Open protocols, on the other hand, can give developers room to change those pieces without rebuilding every connection around them. A2A, for example, allows an agent to publish information about its capabilities and communicate with another agent even if the two were built using different frameworks. MCP gives AI applications a standard way to reach tools and data. Together, protocols like these make it more practical to build systems using agents and services from multiple providers. That flexibility matters because companies rarely have a single reason for choosing an AI model or agent. Cost may matter for one workload, latency for another, while a specialized model may perform better on a narrow technical task. Those requirements can also change as new models arrive or a company's internal needs shift. Open standards can make swapping those components less disruptive. An agent still needs somewhere to get the information required to do its job, however, and that's where portability becomes harder. Max Romanenko, Chief Engineering Officer at EnterpriseDB, sees that underlying data layer as a crucial part of the stack companies have the clearest ability to control. The control point an enterprise actually owns is the data layer,” Romanenko said. “Open protocols can make it easier for agents built by different providers to communicate, but interoperability at the agent layer means little if every agent still depends on data trapped in a proprietary platform. An Open Agent Can Still Depend on a Closed Data Stack Agents need context to be useful, and depending on the task, they may retrieve customer records, query databases, analyze transactions, call internal tools or pull information from multiple systems before producing an answer or taking an action. And while that has its merits, it can create a complication for companies trying to keep their AI architecture flexible. An agent may be easy to replace, but the change becomes more involved if its data has been copied into a vendor-specific environment or if a new provider requires the company to rebuild pipelines, permissions and governance controls. What looked like an agent swap can quickly touch a much larger part of the company's infrastructure. Teams have to account for where the agent gets its information, how current that information is, and which controls still apply when another system enters the picture. Romanenko argues that keeping live data under the company's control gives teams more room to make those changes. “When live data and governance remain under the enterprise’s control, models and agents become components that can be inspected, replaced or sandboxed as requirements change,” Romanenko said. “That is what gives companies genuine flexibility.” The issue becomes more pronounced as companies add agents and providers. Being able to connect two agents through a common protocol solves one technical problem, but the practical value depends partly on how much surrounding infrastructure has to change when one of them is replaced. When Agents Start Delegating, Permissions Get Complicated The governance questions also get harder once agents begin handing tasks to one another. An AI assistant answering an employee's question is easy to picture, but a network of agents that can retrieve information and take actions across internal systems creates many more paths to track. Consider a procurement agent that's allowed to read certain supplier records. It might delegate part of a task to a financial analysis agent, which then calls another tool to retrieve additional information. The company still needs to know which permissions apply throughout that chain, whether each system should have access to the requested data, and what happened if someone needs to review the interaction later. Those questions are already appearing in technical research around agent interoperability. Work examining protocols such as MCP and A2A has pointed out that common communication standards can help agents coordinate without providing every security and governance control a company will need around them. Companies still have to decide what an agent is allowed to access once it reaches an internal system. Identity controls, roles, permissions and audit trails have handled versions of that problem for years, but autonomous agents can make many more requests and decisions without a person approving each step. A lot of those requests eventually reach company data, making the policies around that data an important part of the agent architecture. If several agents are involved in completing a task, teams also need enough visibility to understand which agent accessed what and whether each action fell within its permissions. The Data Has to Live Somewhere Giving an AI system access to internal information involves moving or copying data somewhere it can use it. It may be useful for experimentation or particular workloads, but every additional copy introduces another place where information needs to remain current, secured and subject to the right access rules. That can become cumbersome when companies frequently change models or add new agents. A new AI tool may require another integration or data pipeline, leaving technical teams to manage a growing web of connections between agents and the information they rely on. Romanenko says there is value in keeping those access policies attached to the source data rather than recreating them around each new AI system. According to Romanenko, “An open data foundation enforces access policies at the source and allows intelligence to move to the data, rather than requiring the data to move with every new model or agent.” The idea becomes especially relevant in multi-agent systems, where the same information could be requested by several agents built by different providers. Keeping permissions close to the data can give companies a common reference point even as the software requesting access changes. It can also make investigations less dependent on the individual agent. If something goes wrong, teams need to understand which information was accessed and whether the request should have been allowed, regardless of which model or vendor happened to be involved. Open Protocols Won't Make Every Layer Portable A2A's move to the Agentic AI Foundation puts another major agent protocol into a neutral open-source home at a time when companies are trying to avoid building every AI integration from scratch. More vendors are supporting common protocols, and developers should have more options for connecting agents built in different ecosystems, which can make it easier to change tools as prices, capabilities and internal requirements shift. But companies evaluating that flexibility will also have to look at how tightly each agent is connected to the systems and data beneath it. An open protocol can still rely on data sitting inside a proprietary platform. And it can still require custom pipelines, carry its own set of permissions or create another copy of sensitive information that teams have to govern. The details are less attention-grabbing than watching two autonomous agents coordinate a task, but they'll matter as companies move from agent demos to systems that touch real customer, financial and operational data. This story was distributed as a release by Jon Stojan under HackerNoon’s Business Blogging Program.