At Black Hat this year, agent sprawl was the phrase everyone kept using: enterprises spinning up dozens, then hundreds, of AI agents faster than anyone could govern them. Most of that conversation was about security — who's watching all these agents, and what happens when one goes rogue.
Talk to Vikas Mathur, MariaDB's chief product officer, and you get a different worry. Not whether the agents can be controlled, but whether they can actually understand each other.
Google's Agent2Agent (A2A) protocol just moved into the Agentic AI Foundation, joining MCP under one governance roof. Most of the coverage has called this consolidation — two standards, one home, interoperability problem solved. Mathur isn't convinced that's the right word.
"I think it's the right move for the industry in general," he said, "but I don't know about consolidation. Both of them happening to be there means that we'll move faster."
Faster at what matters here. A2A gives agents a way to describe what they can do and how to talk to each other. It doesn't tell them what to remember, or give them any shared sense of what's true.
"It doesn't solve for the agent amnesia, if that's the right word to use," Mathur said. "It solves for communication, but it doesn't solve for context."
That gap shows up fast inside a large company running dozens or hundreds of agents built by different teams and vendors. Mathur's example: an employee shows up in an HR system under one ID, a GitHub handle in another system, a full name in a third. A2A doesn't resolve any of that. Nothing in the protocol says these are the same person. Agents can be technically communicating and still be talking past each other.
"They could be saying they're talking about the same thing, but really interpreting them completely differently," Mathur said. "It comes down to not having shared context being communicated across them. It happens in the real world with humans. It happens with agents too."
MariaDB's answer is building that shared context underneath the protocol layer, not inside it. Over the past two years, the company has added vector search, JSON, and distributed analytics to what used to be a straightforward relational database, and it recently acquired GridGain, adding a distributed key-value and caching layer built for the short-lived, high-volume state agents generate. Mathur says GridGain customers are running close to 2 million read queries a second at roughly 200 microseconds of latency — a different order of magnitude than the 10 to 50 millisecond range a well-tuned relational database delivers at scale.
That speed helps with session state. It doesn't, on its own, solve the harder problem: building a dynamic knowledge graph that resolves entities across agents and gives them something to agree on. Mathur describes that graph as the layer that turns raw agent activity into a trustworthy shared history — what worked, what didn't, and why — built and resolved on the fly rather than hand-maintained the way older knowledge graphs were.
It also creates a new access problem. Pulling scattered data into one place makes it useful. It also makes it sensitive in a way it wasn't when it was scattered.
"The moment you get into knowledge graphs that are across agents, now you've got to start looking at who can really look at this," Mathur said. "You're pulling information out, connecting it, which is great, so nothing is lost. But it becomes sensitive the moment you get so much information in one place."
For developers building multi-agent systems now, Mathur's advice is unglamorous: skip the ontologies and knowledge graphs for a minute, and get the data out of application silos first. Most enterprise data is still locked to whatever system created it. MariaDB's pitch — echoed by other vendors doing something similar — is a layer in front of those systems, sometimes called a digital integration hub, that pulls data into one place without touching the systems of record underneath it.
"If there was anything to spend time on, if people have time to spend today, I would go do that," Mathur said. "Bring it together so you can actually build agentic workflows much more easily." Skipping that step is possible, he said, but it makes everything downstream a lot more painful.
Even if the memory and context problem gets solved, Mathur doesn't think the hard part is over. He puts orchestrating agents at real enterprise scale — thousands of them, not dozens — as the next bottleneck, right behind cost. Token spend is unpredictable in a way infrastructure spend isn't, and he's blunt about what happens when the accounting catches up.
"They're selling a plan for $200 and spending $8,000 in the backend," he said. "That's fine for now, with venture money. Three years from now, that's not going to happen."
A2A joining a shared foundation with MCP is a real step. It gives agents a common way to introduce themselves and describe what they do. But talking to each other was never the hardest part of building agents that work together. Remembering, and agreeing on what's real, still is. That part doesn't have a protocol yet.
