Where Should You Build the AI Agents That Talk to Your Data?

Where people will talk to their data has been a live question for years, and it has only gotten louder. For a while the phrase was "talk to your data", a natural-language box on top of a warehouse. Now the same idea has merged with a bigger one: the rush to build agents that interact with data on a company's behalf.

It helps to be broad about what counts here. The agent does not have to be a data-analysis tool. A customer success agent that looks up an account, or an e-commerce chatbot that answers a shopper's question about their order, is also an agent talking to data. It has a backend where it can query the business and return an answer. Once you look at it that way, almost every organization is building at least one of these, whether they call it an agent or not.

The scale is not hypothetical. Gartner expects 40% of enterprise applications to include task-specific AI agents by 2026, up from less than 5% a year earlier. So the interesting question is no longer whether to build them. It is where you should build them, because that choice quietly decides your cost, your security posture, and how locked in you end up.

It turns out everyone wants to be the place you build these agents, and the field sorts into three groups.

First, the hyperscalers. Microsoft, Amazon, and Google all ship agent-building platforms today and have made getting started fairly easy, from Microsoft Foundry to Amazon Bedrock AgentCore to Google's Vertex AI Agent Builder. Much of your data and most of your compute already sit with one of them, and the security and identity controls are already wired up. Building an agent there is close to the metal.

Second, the data platforms such as Snowflake and Databricks. They hold the data and run the compute, and they now want to be where you build the agents that use it, with offerings like Snowflake data agents and Databricks Agent Bricks, so the query never has to leave the platform.

Third, a set of third-party tools that hold neither the data nor the compute and still believe they should be where you build your agents. This is the group worth thinking hardest about, because the pitch sounds reasonable until you ask what the tool actually contributes to running the agent.

Line the three groups up and the market direction is not hard to read. The hyperscalers and the data platforms are going to keep building agent tooling, and they are going to do it well, because they are sitting on top of the two things an agent needs most. The data and the compute already live there, the security model is already in place, and they can offer all of it cheaper than a third party can, since they are not paying to move data anywhere or to stand up a separate runtime.

Put yourself in the shoes of a team choosing where to build. If your data is in Databricks and your identity and access controls are already enforced there, why would you run the agent on a third platform that owns none of that? You would be adding a network hop, a second security boundary, and another bill, in exchange for very little.

This is not a knock on the tools in that third group. Many of them are excellent at what they were built for. The point is narrower: hosting the agent runtime is not where a tool without data or compute adds value, and the big platforms will out-build and undercut anyone who tries to compete there.

There is one situation where building outside the big platforms has a real argument. It is the agent that has to connect to several data sources at the same time, where no single platform holds everything the agent needs to answer well. If the meaning it needs is spread across a warehouse, a BI tool, and an operational system, running the agent somewhere neutral can look appealing.

In practice this case is rare, and even when it comes up, a separate build layer is usually the wrong fix. The reason an agent struggles across sources is not where it runs. It is that the sources describe the business inconsistently, and no one has reconciled what a term means from one system to the next. Moving the runtime does not solve that. Reconciling the meaning does.

That is the thread worth pulling, because it points at what the third group is actually good for, and it is not hosting your agents.

Step back and ask what is genuinely hard to reproduce in all of this. It is not the agent. Agents are getting cheaper to build by the month, and the big platforms are commoditizing them fast. The hard, slow, valuable asset is the governed context behind your data: the definitions everyone has agreed on, who owns them, how data flows from source to report, and how it is classified. That is the piece that took years to build and the piece you least want trapped inside one vendor.

So the design goal flips. Instead of asking a tool to host your agent, you want governed context, not the agent, to be the thing that travels. You govern business meaning once, in a layer you own, and then serve it to whichever agent needs it, wherever that agent runs. This is exactly where a tool without data or compute earns its place. Its job is to make meaning consistent and portable, not to be another runtime.

Framed that way, the third group's real pitch stands out from the weak one. "Build your agents on our platform" is a soft form of vendor lock-in, the same instinct that leads a governance vendor to push its own data-quality engine and quietly steer you away from first-party tools. "Use your context anywhere" is the opposite promise. One ties your future to a runtime you rent. The other keeps the expensive asset in your hands and lets the runtime be whatever suits each use case.

This is the position we take at Dawiso, and it is a deliberate one. We are not trying to be the place you build your agents. We are the place your governed business meaning lives, and our job is to get that context into your agents wherever you choose to build them, whether that is natively on a hyperscaler, inside Databricks or Snowflake, or in a custom agent you stand up yourself.

One of our customers, Seznam.cz, did exactly this. They built their own conversational agent and connected it to governed context in Dawiso over the Model Context Protocol, an open standard now backed by every major AI vendor, rather than being told to build the agent inside a vendor's studio. That is the flexibility worth protecting. Dawiso connects to more than 40 platforms, defines each term once with an owner and an approval workflow, traces lineage and classification across the estate, and serves all of it to any MCP-compatible agent through an open MCP Server.

So the guidance is short. Build your agents where the work is already set up for them, on the platforms that hold your data and compute. Keep the context governed in a layer you own, and deliver it to those agents over an open protocol. That way the market can keep commoditizing agents, which is good for you, while the one asset that is genuinely yours stays portable and stays in your control.