No Lifeguard on Duty: Agents Will Drown in a Data Lake Full of Numbers Without Financial Intelligence

In Part 1 of this series, we argued that you can’t vibe code the Office of Finance. Writing code that produces a number is relatively easy. Producing one that can stand up to an audit or to the board question is infinitely much harder.

That leads to a question we increasingly hear from customers:

“We’re moving everything into Databricks. We’re pointing Claude at it. Why do we still need the Finance platform?”

To be fair, the question is reasonable. But the answer comes down to an important distinction: Centralizing financial data isn’t the same as centralizing the intelligence that makes that data meaningful.

Bringing enterprise data into a governed, centralized environment makes sense. Snowflake, Databricks, Microsoft Fabric, OneLake, and others combine scalable storage with governance, cataloging, semantic modeling, and increasingly, managed ways for AI agents to access enterprise data through open standards such as the Model Context Protocol (MCP).

The benefits are significant: fewer extracts, a shared catalog, better governance, and the ability to answer questions across functions from a common data environment.

So yes, move data into the lake when it makes sense. Here’s the most important question, though: What happens to the financial intelligence behind that data when you do?

If you move a customer record into a lake, you’ll still have the customer record. If you move a consolidated financial result, you have the result but not necessarily everything that produced the result.

Consolidated revenue isn’t simply a row sitting in a source system. Instead, that revenue is the result of an engine. The engine applies ownership structures, currency translation, intercompany eliminations, account treatment, minority interest, and other rules across entities and periods.

For Finance, that chain matters just as much as the final number. Why? The chain makes the result explainable, repeatable, and auditable.

When the result is exported, the number travels. Much of the intelligence behind it doesn’t.

You can export results and metadata. However, recreating the executable financial model that turns them into an answer on demand? Well, that’s much harder to create given the consolidation and planning logic, process state, provenance, and security required.

Many financial values also don’t exist as stored rows. Ratios, allocations, alternate hierarchy views, DynamicCalc results, and parent rollups can be produced when someone asks for them. While these values can be extracted, they must first run through the financial engine. The problem? There’s no complete set of stored rows for a traditional pipeline to simply copy.

For known reporting and analytical needs, materializing governed financial results into the lake can make perfect sense. The challenge starts when an agent needs to answer open-ended questions across the financial model. You simply cannot pre-materialize every financial intersection it might need.

That’s the difference between moving financial data and moving financial intelligence.

Analysts bring judgment to centralized data. How? They often know when a number looks wrong, which system contains the authoritative answer, and when they need more context.

Yet agents don’t automatically have that intuition.

If you ask an agent why an operating margin declined this quarter, you’re not simply asking the agent to retrieve a number. You’re asking the agent to interpret a financial result.

If the agent only has exported figures, it may calculate or infer an answer. What the agent cannot know is whether it has all the financial logic required to produce the same answer Finance certified.

The agent might also be missing important information about the number itself. Was it entered, calculated, translated, consolidated, or generated dynamically? Is the underlying calculation current? Those distinctions are part of the financial data contract, not just technical metadata.

Security adds another layer. Since Finance access can depend on the intersection being requested, reproducing permissions outside the Finance platform isn’t always simply about copying roles alongside the data.

A plausible answer isn’t necessarily a correct financial answer, and confidence isn’t a substitute for traceability.

For Finance, AI-ready data therefore must mean more than making rows accessible to a model. Financial semantics, business rules, permissions, provenance, and query-time calculations must be accessible too.

The answer isn’t to give the agent more copies of the data. Instead, the answer is to give the agent governed access to the systems that know how to answer the question.

Until recently, Finance largely had two choices:

1. Keep the work inside the Finance platform, where the logic and controls lived
2. Export the data, then recreate enough context somewhere else

Agents and open protocols like MCP change that equation.

Instead of moving every piece of data and logic into one place, agents can increasingly reach governed systems directly. Agents can then use each for what it does best.

A variance investigation offers the good example. The consolidated variance may live in the Finance platform. Supporting detail may sit in staging. The transaction explaining it may live in an enterprise resource planning (ERP) system.

However, an agent shouldn’t need all three recreated in a lake before being able to investigate the variance. An agent should be able to start with the governed consolidated result, drill into the supporting detail, reach the source transaction, and explain what happened.

That changes the architectural question. How? The question is no longer about how to move every piece of data and logic into one place. Instead, the question focuses on which system is best equipped to answer each part of the question:

• The Finance platform calculates and certifies the financial result.
• The ERP provides the underlying transaction.
• The lake provides broader enterprise context.

The agent then works across all systems.

That architecture also reflects how Finance actually works.

Controllers live in Excel. Analysts may use Copilot in Microsoft 365. Others may prefer Claude, ChatGPT, or Gemini.

The architecture should accommodate that reality rather than force everyone into one interface or every piece of intelligence into one data store.

At this point, build-and-buy becomes practical.

Governed platforms can be used for processes that must be deterministic, controlled, and defensible. Such processes include consolidation, currency translation, financial reporting, and processes governed by audit or SOX requirements.

Agents and workflows can be built around exploratory, cross-functional, and business-specific work.

The goal isn’t to rebuild Finance’s intelligence in the lake. Rather, the goal is to make that intelligence available wherever Finance wants to work.

This role is filled by OneStream’s Finance Agentic Layer.

Built on MCP, the Finance Agentic Layer enables tools such as Microsoft Copilot, ChatGPT, Claude, and Gemini governed access to OneStream. The layer simultaneously applies the financial logic, permissions, and auditability behind each request.

However, the important part isn’t MCP by itself. It’s what the platform can expose through MCP.

Calculations can run against the current financial model when the question is asked rather than relying solely on static copies of exported results. Plus, OneStream can provide context an outside agent would struggle to infer on its own. That context can include semantic search across financial dimensions and members and guidance to the right cubes, fields, and financial structures.

And the flow works both ways. Governed financial results can still move back into the enterprise data environment when that’s the right architecture.

The point isn’t to keep data trapped inside Finance. Rather, the point is to avoid recreating Finance’s intelligence somewhere else just so an agent can use that intelligence.

Data can be moved into Snowflake, Databricks, Fabric, BigQuery, or another enterprise data platform when it makes sense. For many organizations, it absolutely does.

You can and should materialize governed financial results there when you have defined reporting and analytical needs.

But don’t assume that moving financial data also moves the financial intelligence that produced the data.

The agentic architecture doesn’t need to centralize every piece of intelligence. Instead, the architecture can let each system do what it does best and give agents governed access across them.

The lakehouse ultimately brings enterprise data together. While the Finance platform produces and certifies financial truth, the ERP owns the underlying transactions. MCP gives agents a way to work across those boundaries.

In other words, don’t move every answer to the agent. Give the agent governed access to where the answer is produced.

That’s what Finance needs from an agentic architecture: not another copy of its numbers, but governed access to the underlying intelligence.

For a deeper look at how Finance leaders can prepare their operating model for the AI era, read Forward Finance.