Your AI Agent Isn't the Problem — Your Data Estate Is

To connect AI agents to enterprise data, expose your governed data sources through the Model Context Protocol (MCP) rather than exporting data or hand-building an API per question. S&P Global Energy did this with Databricks Genie Agents published as managed MCP servers, letting subject-matter experts curate trusted, natural-language access without writing agent code.

The hard part of enterprise AI was never the model. Any team can wire up a capable LLM in an afternoon. The wall everyone hits is the one S&P Global Energy names directly in its own account: agents are only as good as the context they can reach, and enterprise data almost never lives in one neat, documented place. If you’re evaluating how to make your siloed data agent-ready, the S&P Global rollout is a clear real-world blueprint — and it points to a repeatable decision framework, not a product you buy off a shelf.

Why do enterprise AI agents stall before they reach production?

Because the bottleneck is data access, not model quality. An LLM can reason well and still answer nothing useful about your business, because it has no governed bridge to your structured data. S&P Global Energy lays out the three bridges companies have historically built and why each one breaks: hand-built text-to-SQL pipelines that shatter on every schema change and ambiguous column name; custom APIs where each new question pattern demands a new endpoint, sprint, and release; and exporting data into external AI tools, which duplicates records, breaks freshness, and steps outside your governance perimeter.

All three share a deeper flaw. The people who understand the data best — the analysts and subject-matter experts — are not the people building the access layer. Every insight has to queue behind an engineering backlog, so a new conversational data experience gets measured in months. If your data team is currently the single point of translation between “what the business wants to ask” and “what the database can answer,” you already have this problem, whether or not you’ve tried to add AI yet.

How does the Model Context Protocol turn siloed data into agent-ready context?

MCP is an open standard that gives any AI agent a consistent, governed way to reach a data source — think of it as a universal adapter between agents and enterprise systems. Instead of custom-wiring each agent to each database, you publish your data once behind an MCP endpoint, and every MCP-compatible agent, internal or external, can use it. S&P Global Energy exposed each of its Databricks Genie Agents as a managed MCP server automatically, with nothing to deploy and nothing to host.

The practical shift is that integration becomes a contract, not a project. In the S&P Global architecture, each server exposes a tiny, clean tool surface — essentially an ask-then-poll pair: submit a natural-language question, then poll for the answer once the SQL runs against the warehouse. If you’re a team drowning in one-off integration requests, this is the change that matters: you build the bridge once and every current and future agent crosses it. Standardizing on MCP is the same bet enterprises made on REST APIs a decade ago, and the teams that treat it as core enterprise data pipeline infrastructure now will avoid a painful retrofit later.

How do you keep agent answers trusted across different business lines?

Governance has to come first, or the whole thing collapses the first time an agent returns a confident wrong number. S&P Global Energy’s answer was to inherit the controls it already had rather than build a parallel security stack. Every question an agent asks runs through Unity Catalog permissions, on governed tables — whether the data is native to Databricks or pulled in from outside sources through federation — with full auditability. An agent, or the user behind it, can only reach the data they’re permitted to see.

Trust also depends on the semantic layer that generic text-to-SQL tools skip. S&P Global’s experts embed table and column descriptions, example queries, and hard business definitions directly into each agent — for instance, defining “floating storage” as cargoes idling three days or more in vessels travelling below a threshold speed. In a domain where pricing, supply, and contract data drive real trades, that definitional precision is the difference between a demo and a product. Their teams also run repeatable benchmarks — test questions phrased the way users actually ask, scored automatically against verified answers — so accuracy is measured, not assumed, and can be re-checked after every change. Any enterprise putting agents in front of high-stakes decisions should copy this loop: curate, benchmark, improve, re-benchmark.

What can S&P Global Energy’s rollout teach your own team?

The estate S&P Global made conversational is sprawling — Chemicals, Crude Oil, Refined Products, Gas & Power, LNG and more, each a rich family of datasets. LNG alone spans facility specs, cargos, outages, supply and demand, netbacks, prices, and contracts, living across Databricks and several non-Databricks sources. The instinct would be to build one giant agent per commodity. They did the opposite, and that choice is the transferable lesson.

Subject-matter experts curate one narrowly scoped Genie Agent per dataset group — an LNG Cargo agent, an LNG Outages agent, an LNG Netbacks agent, and so on — because answer quality is highest when an agent covers one specific domain with clear instructions. Real questions, though, cross those groups: “How did recent outages at Sabine Pass affect cargo premiums into Asia?” touches both outages and cargo. So they used a FastMCP proxy layer to compose the narrow agents into commodity-wide composite endpoints with name-spaced tools, letting the agent route or fan out a question and synthesize the results. Narrow and accurate underneath, broad and conversational on top.

A rollout playbook you can actually follow

Strip the S&P Global story down and a repeatable sequence emerges. Start with a data estate audit: map where your structured data actually lives and who the true domain owners are. Next, for non-native sources, favor federation over new pipelines — S&P Global reached “conversational” without a single new ETL job, caching its busiest queries only after patterns emerged. Then hand curation to the people who understand the data. The organizational insight worth stealing is that curation became a domain activity, not an engineering activity; the person who knows what a metric means is the person who teaches the agent what it means.

From there, standardize the connection through MCP so every consumer uses one pattern, compose narrow agents into broader endpoints only at the integration layer, and instrument trust from day one by tracking how often experts agree with the generated SQL. If you’re a mid-market company with a handful of siloed systems, the same shape applies at smaller scale — the point is the ownership model, not the specific vendor stack. A well-scoped custom AI agent build fits squarely here, with guardrails and human oversight designed in rather than bolted on.

Should you build custom integration or buy an off-the-shelf connector?

Buy the off-the-shelf connector when your data is already clean, centralized, and well-documented, when your questions are simple and stable, and when you don’t need cross-source reasoning or fine-grained governance. Generic text-to-SQL tools and packaged connectors are fast and cheap for that world, and building custom would be waste.

Build custom integration when your reality looks like S&P Global’s: data scattered across multiple systems, business-specific definitions that off-the-shelf tools can’t know, high-stakes answers that demand auditable governance, and external parties who need to connect their own agents to your data safely. The tell is whether generic tooling can encode your semantic layer — your definitions, your trusted metrics, your permission boundaries. When it can’t, a connector will produce confident answers that are subtly, expensively wrong, and no amount of model quality fixes that. Our expectation is that within a couple of years MCP endpoints become a standard product deliverable — data providers will ship them the way they ship APIs today, and buyers will treat “does it expose governed MCP access” as a procurement checkbox. The decision between an agent and simpler automation is worth settling before you write a line of code.

If your data estate is siloed and your domain experts are stuck filing tickets to expose their own data, that’s the exact condition this architecture solves. Book a free enterprise AI data-readiness consultation to map your estate and decide where a custom build beats a connector.

FAQ

Q: What is the Model Context Protocol (MCP) and why does it matter for enterprise AI? A: MCP is an open standard that lets AI agents connect to data sources and tools through a consistent interface, so you integrate once instead of custom-wiring every agent to every system. It matters because it turns siloed enterprise data into governed, agent-ready context that any MCP-compatible client — internal or external — can safely use.

Q: Do I need to move my data to make it available to AI agents? A: No. S&P Global Energy used Databricks Lakehouse Federation to reach non-native sources without moving data or building new pipelines, letting federated tables inherit the same governance as native ones. Exporting or duplicating data breaks freshness and steps outside your controls, so federation-first is the safer default.

Q: When is a custom AI integration worth it over an off-the-shelf connector? A: Build custom when your data spans multiple systems, your metrics have business-specific definitions, answers carry real financial or regulatory stakes, or you need auditable per-user governance. Buy a connector when data is centralized, clean, and your questions are simple and stable.

Key Takeaways

• The blocker to enterprise AI is data access and governance, not model quality — audit your data estate before you evaluate any model.
• Standardize agent connectivity on MCP now; teams that treat it as core infrastructure will avoid an expensive retrofit as the ecosystem consolidates around it.
• Keep individual agents narrow and domain-scoped for accuracy, then compose them at the integration layer to answer cross-domain questions.
• Shift data curation from engineering tickets to your subject-matter experts — the people who define the metrics should be the ones publishing access to them.
• Instrument trust from day one with repeatable benchmarks and expert review of generated queries; measure accuracy, don’t assume it.
• Reserve custom builds for scattered data, high-stakes answers, and business-specific definitions a generic connector can’t encode — and skip it when your data is already clean and centralized.