Do you have to centralize your data before AI agents can use it?

1. The source count is the thing that broke centralization

Jitender Aswani, SVP of Engineering and Security at Starburst, puts the number plainly: “A traditional enterprise will have anywhere between 52 to 200 data sources.” His account of how they got there is ordinary rather than dramatic. Every SaaS tool and cloud service a company buys generates and stores its own data, so the source count grows with every tool a company adds.

Centralization was, in his words, “a fine, fine strategy. when the data was growing not as fast as your ability to move it.” That condition stopped holding. His framing is that federation “is the only model that scales with entropy,” a claim he states flatly in the episode’s cold open and hedges to “I think” when he makes it in full.

2. Moving the data does not end the work, it changes it

The pitch for a lake was that once everything lands in one place the problem is solved. Aswani’s read is the opposite: “Your problem starts to compound when you have moved all your data. Now you have a governance problems. you have this continuous ETL challenges.”

The mechanism is that data is not static. A SaaS vendor adds a column, and the pipeline that imported that table has to be retooled; until it is, someone is debugging why it fails. He describes leaders “spending days debugging why my pipelines are failing” as the steady state, not the incident.

3. Agents made the bill arrive sooner

Agents query differently from people. Aswani describes them operating in a reason-and-act loop, “generating queries at insane speed,” including unbounded ones, because an agent that lacks an answer fires another query rather than stopping to ask whether it should. When Starburst shipped its own MCP server, “we saw the query volume go through roof,” and customers had to scale compute behind it.

The failure he offers is his own team’s. Their internal FinOps agent had access to AWS cost data but not GCS or Azure. Asked to break spend down by cloud provider, “it starts fighting queries. It’s just frantically fighting queries without stepping back and thinking, do you even have GCS and Azure data?” That agent did not report its partial access. It worked harder.

4. Federation is a compute layer, not another copy

The alternative Aswani describes is to accept the fragmentation and move the compute instead: “the best way to live with that challenge is to actually put a virtual compute layer on top through data federation.” The data stays where it is; the query engine reaches across.

He extends the same argument to context. Knowing where the data lives is not sufficient, because meaning is scattered too: whether “customer” means account or opportunity, whether the fiscal year starts in February or July. His term for the layer that holds this is a context graph, which he distinguishes from a knowledge graph: the knowledge graph carries entities and relationships, and the context graph adds the business rules on top of them.

Why it matters

If a data-consolidation program is still underway when the agent pilot starts, the pilot does not wait for it. If the honest answer to “which systems can this agent reach” is a subset, decide that deliberately and tell the agent. Aswani’s FinOps agent did not work it out on its own. It just kept querying.

Federation solves reach, not authority. The separate question is how identity, source-level policy, and action controls combine once an agent can query across systems. See agent identity and permissions for that ownership model.