May 2026 · 4 min read · Part 1 · Wiring the Agentic Enterprise
An agent on the lake is fine
Pointing an agent at the lakehouse works for a lot of what agents do. It is not the ceiling. The bridge worth thinking about extends the lakehouse's semantic layer to the integration plane, so an agent operates on the same governed entities whether the data is at rest or in flight.
The Agentic Enterprise series made the case that agents fail when the foundation is wrong. Wrong entity definitions. Misaligned metrics. No decision routing. The technology is not the bottleneck. The system underneath is.
This series is about the next layer of that system. And it starts with a question that is easier to skip than to answer.
You have a lakehouse. Should the agent live there?
The natural move works most of the time
An organization builds a lakehouse. They model their entities, align their metrics, and establish a governed semantic layer. The lakehouse becomes the authoritative source for analytics. Dashboards run off it. Reports get published from it. The data is clean, trusted, and well-defined.
Then someone decides to build an agent.
The natural move is to point the agent at the lakehouse. The data is already governed there. The entities are defined. A lot of what an agent might do fits the lakehouse exactly: scoring accounts, surfacing patterns, summarizing retrospective state. The work is not wrong. It can be better.
The lake’s latency is mixed
The picture of “stale lake versus fresh systems” is a strawman. Modern lakehouses stream. Change data capture pipelines land operational changes in minutes, sometimes seconds. Some tables in the lake are near-real-time. Some are hours old. Some are still on overnight batch because nobody ever needed them faster.
This is the normal state of a real lakehouse. Mixed latency. The data lands when the pipeline that fills it lands, and the pipelines were built for the use cases they were built for.
For most analytical work, mixed latency is fine. Dashboards do not need second-by-second updates. Quarterly reviews do not care about ten-minute lag.
For an agent that is supposed to act when something happens, mixed latency is a constraint. The agent will operate on whatever picture the lakehouse hands it. If the table it needs is twenty minutes behind, the agent’s information is twenty minutes behind. That is not wrong. It is just not as good as it could be.
App-to-app integrations live somewhere else
There is another layer that often does not get included in the conversation: the integrations between operational applications.
A customer files a support ticket in the service platform. The service platform pushes an event to the CRM, which updates the account record. The CRM pushes another event to a marketing automation system, which adjusts the campaign queue. None of that necessarily passes through the lakehouse on the way. It is app-to-app, on its own cadence, with its own contracts.
That matters for the agent. The signal exists in the app-to-app plane before it reaches the lakehouse: a customer just escalated for the third time this week, a pipeline deal just went quiet, a delivery just missed its window. If the decision the agent wants to make depends on that signal, the agent can either wait for the lakehouse to catch up, or it can sit closer to where the signal lives.
That is not a critique of the lakehouse. It is a design choice about where the decision belongs.
Maybe we need another bridge
The lakehouse has a semantic layer. Governed entities. Defined metrics. Resolved customers. That is the work the analytics team spent months getting right.
The integration plane usually does not have one. Each integration is a point-to-point contract, with its own field names, its own assumptions about what a customer is, its own conventions for active versus inactive. The shared semantics that govern the lakehouse stop at the lakehouse boundary.
That is the bridge worth thinking about. Not a bridge to make the lakehouse faster. A bridge that extends the semantic layer outward, into the integration plane, so an agent that reads app-to-app signals is working with the same governed entities it would have used in the lake.
The ingredients exist. Event schemas with versioned contracts. Shared ontologies that the integration layer enforces. Identity resolution at the edge, not just at rest. The discipline that produced the lakehouse semantic layer can be applied to the integration plane too. It usually is not, because no one owns it that way.
The through-line
If The Agentic Enterprise was about what agents need to reason well, this series is about where those needs get met.
The lakehouse is one place. It is the right place for a lot of what agents do. It is not the only place. The integration plane is where decisions move closer to the signal, and the discipline that worked in the lakehouse should not stop at its boundary. Defined entities, resolved customers, governed metrics. Those should travel.
The data does not need to be in one place. The semantics do.