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 tracks procurement, and procurement does not slow down.

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, which is the honest version of it.

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 before anyone notices it broke. 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, which is the useful part. 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?” An agent with partial access does not report partial access. It works 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

The two-year data-consolidation program and the agent pilot are usually run by different teams, and the pilot does not wait. If the honest answer to “which systems can this agent reach” is a subset, decide that deliberately and tell the agent, because it will not work it out on its own. It will just keep 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.