AI has created a “dog catches the car” moment for many data teams.

Teams spent years investing in a modern data stack to “democratize” access to analytics. They built dashboards, reports and marketplaces that non-technical users could use to make better decisions and finally “generate value from data.”

And then, almost overnight, AI gave anyone in the organization the ability to query data like a PhD analyst. The catch is that no one wants the dashboards and UIs teams spent years painstakingly building. Suddenly, everyone — every team, every partner, every customer — wants what only the most technical teams once required: the actual underlying data.

This is why we’re seeing a massive increase in data sharing. As data teams get flooded with requests for data access, many are looking for a quick, secure way to support these agents that’s already approved and battle-tested. So instead of rebuilding an entire collaboration workflow, data teams are provisioning access for each agent using the sharing protocols they already know and trust.

What is data sharing?

Data sharing is a way to grant internal and external teams access to larger analytical datasets. Instead of building a pipeline to replicate and send data to each consumer, a provider uses a data sharing protocol to grant one or multiple consumers permissioned views of the same dataset.

Every major data platform offers a sharing protocol. Snowflake has Snowflake Sharing, Databricks has Delta Sharing, BigQuery has Analytics Hub. Bobsled allows you to extend these capabilities by sharing to consumers outside the cloud or platform in which you work. That means you get the same dead-simple sharing experience no matter where they work.

Why are data teams turning to data sharing to support agents?

In many ways, a data share is already a near-perfect primitive for most agentic workflows. Data shares are built for consumers who write code. They’re fully ring-fenced, so there’s no concern of agent sprawl. And authentication is dead simple for both provider and consumer.

1. A battle-tested protocol: Many data teams are leaning on data sharing to meet agent demand because it’s already built and proven in production. The protocols have been hardened over years of use by some of the most advanced teams in the world. No need to build an MCP or new governance layer.
2. Granular control over what agents access: The AI rush has loosened governance requirements in many companies, but data teams are still on the hook to ensure only the right people get access to the right data. With data sharing, you can easily ring-fence a dataset for an agent by creating a simple logical view (or views) on top of your broader dataset. An agent cannot use what it cannot access.
3. Pay for the data, not the compute: Everyone is talking about “tokenomics,” but few are talking about the spike in traditional compute that agents can generate. Agents multiply queries on two fronts: more people asking questions, and more queries generated per question. That means compute bills are going way up. One of the best parts of data sharing is that the team sharing data does not pay for the compute run on its dataset. That means if another team’s agent goes rogue, you’re not on the hook for the bill.
4. (Agentic) analytics-ready: One of the reasons analysts love data shares is that there’s no prep work to get going. No need to ETL data from an API or file into a warehouse. The same goes for agents. At Bobsled, we have also introduced the ability to share context layers as part of a data share so that agents can navigate the share with almost zero additional work.

At Bobsled, we’re building the next generation of data collaboration infrastructure for the AI era. That means autonomous data agents, self-learning context layers, and federated access models. But it also means continuing to build on primitives from the last era that help teams deliver today.