For forty years we split running the business from analyzing it. That split, not model intelligence, is the real bottleneck for agentic AI.
For about forty years, almost every data stack has carried the same quiet split. One set of systems to run the business. Another set of systems to analyze it.
You have lived inside this split even if you never named it.
The systems that run the business are transactional. They take orders, update accounts, move money, record a signup. They are built to handle many small writes, fast and safely. Postgres, MySQL, and friends live here. Engineers call this side OLTP.
The systems that analyze the business are analytical. They answer questions across millions of rows. How did sales trend this quarter. Which customers are about to leave. They are built to scan and aggregate, not to take orders. Warehouses and lakes live here. Engineers call this side OLAP.
Both sides are useful. The problem is the gap between them.
To get data from the running side to the analyzing side, we built bridges. Pipelines. Then more pipelines.
We copied data out of the app database and into the warehouse. We copied it again into feature stores for machine learning. We wrote the same business logic in two or three places. We watched syncs go stale and woke up to numbers that did not match.
A lot of energy went into moving data between systems instead of building value on top of it.
This was normal. It was so normal that we stopped questioning it. The split felt like a law of nature, not a choice.
But it was a choice. And the cost of that choice is now showing up in a new place.
Here is the reframe worth sitting with.
The limit on agentic AI is not model intelligence. The models are already strong. The limit is the divide between live operations and trusted history.
Think about what an agent actually needs to do useful work.
It needs to act in the moment. Approve a refund. Update an account. Place an order. That is the transactional side.
It also needs to reason over context. What has this customer done before. What is normal for this account. What happened the last hundred times. That is the analytical side.
An agent that has to wait for an overnight pipeline cannot act in the moment. An agent that can only see live state, with no memory, acts blindly.
The split forces a choice between fast and informed. For decades that tradeoff was annoying. For agents, it is the whole game.
[!notice] At the Data and AI Summit, Databricks framed the answer as one idea. Both transactional and analytical engines running on a single copy of data, in an open format. One data, zero compromises, zero copies.
Databricks gave this idea a name: LTAP, short for Lake Transactional and Analytical Processing.
Strip away the acronym and the idea is simple.
Instead of keeping a transactional database over here and an analytical store over there, you keep one copy of the data in an open format. A transactional engine can write to it fast. An analytical engine can read across it deeply. Same data, two ways of working with it.
This sits on Lakebase, the managed Postgres foundation in the lakehouse. Postgres is one of the most trusted databases in the world, so this is not asking you to learn an exotic new system. It is meeting builders where they already are.
We wrote about Lakebase on its own when it reached General Availability. If you want the deeper tour of branching, autoscaling, and Unity Catalog integration, that piece is linked at the end. The point here is the shape of the idea, not the feature list. This real-time capability is further powered by Lakehouse//RT and the Reyden engine for millisecond query latency.
The shape is this. The wall between running the business and analyzing the business is coming down. One copy of data is meant to serve both.
There is one detail from the keynote that is easy to read past and worth slowing down for.
Across the platform, agents now create roughly 80 percent of databases. As Databricks co-founder and CEO Ali Ghodsi put it, "Our primary user is already the agent."
Read that again. The main creator of new data systems is no longer a person clicking through a console. It is a machine, spinning up what it needs to do a job.
That changes what good infrastructure means.
When humans create databases, we tolerate quirks. We remember the weird table. We know which column is really the key. That knowledge lives in people's heads.
When agents create databases, nothing can live in someone's head. The systems have to be self describing. Governed by default. Safe to create and safe to throw away. The data has to carry its own meaning, because the thing using it does not have a hallway to ask questions in.
This is why one copy of data, under one governance layer, matters so much in an agent world. It is not a convenience. It is the only way the whole thing stays trustworthy at machine speed.
It is fair to wonder where you fit when machines create most of the databases and agents write a lot of the code.
Here is the honest answer, and it is a hopeful one.
When one copy of data serves both worlds, the brittle copy pipelines start to disappear. The work of babysitting syncs, reconciling mismatched numbers, and rewriting the same logic in three places gets smaller. That was never the valuable part anyway.
What grows in value is the thing underneath all of it. Understanding the data.
Data modeling. How entities relate, what the grain of a table is, what a key really means. Governance. Who can see what, and why. Freshness. How current the data needs to be for a given decision. Lineage. Where a number came from and what it depends on.
These are the skills that decide whether an agent can trust what it reads. They do not go away when the tools change. They become the foundation everything else stands on.
This rewards fundamentals, not tool memorization. Which, quietly, has always been the better bet.
If this is the direction, the move is to go deep on the foundations the new world runs on.
Open formats and one source of truth are the heart of LTAP, and that is exactly what Delta Lake teaches. Start there to understand how one copy of data can be both reliable and fast.
Governance is the other half. Unity Catalog is where you learn how access, lineage, and trust work across operational and analytical data, the same governance an agent leans on.
And the medallion architecture lesson is where these ideas come together into a way of shaping data that stays trustworthy as it flows.
If you are just getting started, the start here lesson is the calm first step.
You can reach all of these from the lessons: Delta Lake, Unity Catalog, and medallion architecture.
If you want to go further on the announcements behind this shift:
For forty years we accepted the distance between running the business and understanding it. We built our careers, in part, on moving data across that gap.
LTAP is a bet that the gap was never necessary. That one copy of data, open and governed, can serve both the moment and the memory.
If that bet pays off, the next decade of useful systems will come from shrinking the distance between live operations and trusted data.
And the engineers who understand that distance, who know how data really behaves, will be the ones who shape what gets built on top.
That understanding is something no agent can hand you. It is something you build. The good news is that you can start building it today.