The real story from Databricks Data + AI Summit is not that Databricks announced more data and AI products. It is that Databricks is trying to make enterprise data the control plane for agentic work. That is a much bigger move than "lakehouse plus AI." The company is arguing that enterprise agents will not work without four things — and spent Summit building an architecture around all four.

The Same Move, From the Data Layer

If Apple is turning the consumer OS into an agent runtime, Microsoft is packaging the enterprise agent stack as the product, Figma is making the canvas a production runtime, Vercel is turning deployment into agentic infrastructure, Cannes showed advertising becoming agentic media infrastructure, and Adobe is turning the customer lifecycle into an agentic operating system, Databricks is making the same move from the data layer. The runtime is enterprise data.

Every enterprise wants agents. Most fail for the same reason: they don't understand the business well enough to be trusted. An agent can answer in fluent language, call a model, retrieve from a database, and summarize a dashboard — and still not know what "revenue" means in your company, which dashboard is trusted, which team owns the metric, which customer definition applies, which policy governs the data, or whether the query is cheap, expensive, allowed, stale, or wrong. That is the gap Databricks is attacking.

From Lakehouse Platform to Agentic Data Control Plane

The company is still anchored in the lakehouse — that is the moat. But DAIS 2026 made clear the lakehouse is no longer the full story. The new story is broader: data foundation, semantic context, real-time infrastructure, transactional state, agent orchestration, governance, security, open sharing, vertical applications, business-user agents, developer agents, model choice, and cost control. Databricks is trying to turn the governed data estate into the place where enterprise agents are built, grounded, monitored, and controlled.

Context Is the Moat

The most important word at Summit was context. Databricks' argument is simple: enterprise AI does not fail mainly because models are weak. It fails because models are disconnected from business reality — a reality that lives across tables, dashboards, notebooks, pipelines, jobs, queries, documents, Slack threads, tickets, SharePoint, Drive, CRM, and institutional memory. A model can read a table and still misunderstand the company.

That is why Genie Ontology matters. It is Databricks' attempt to build a self-improving business knowledge layer from the actual environment and connected systems — extracting meaning from data assets, usage patterns, dashboards, queries, pipelines, and external work systems so agents reason over business concepts, not raw tables. The future of enterprise agents depends less on "which model did you use?" and more on "what business context did the model have permission to reason over?" If the ontology is weak, the agent sounds smart and is wrong. If it's strong, the agent answers with the company's actual operating logic.

Genie One Turns the Data Runtime Into a Coworker

Genie One is the most visible expression of the strategy — turning the data intelligence layer into an AI coworker for business users across web, mobile, Slack, and Teams. But the chat surface is not the important part. What sits underneath is: governed enterprise data, business context, permissions, and the semantic layer. It answers questions, creates documents, runs scheduled tasks, monitors metrics, triggers alerts, takes action through tools, and helps create domain-specific agents.

Dashboards don't disappear — they stop being the only way business users touch enterprise data. The platform becomes conversational, scheduled, agentic, and embedded where people already work. The governed agent becomes the interface.

Genie One Is Only as Good as Genie Ontology

The ontology layer is more strategically important than the assistant interface, because every enterprise has conflicting definitions — and agents amplify the problem. When a human analyst is uncertain, they ask someone. When an agent is uncertain, it may generate confidence. That is dangerous.

Genie Ontology makes meaning explicit and governed before agents act on it. The open question is verification: building an ontology from usage patterns is powerful, but usage does not always equal truth. A widely used query can be wrong; a popular dashboard can be outdated; a definition can be contested. Success depends on whether teams can inspect, correct, certify, monitor, and govern the meanings agents rely on.

Unity Catalog Becomes the Spine for Agents

Unity Catalog is no longer just about governing data assets. It is becoming the governance spine for data, models, tools, agents, apps, metrics, and AI activity — because enterprise agent sprawl is coming. Different teams will build on different frameworks: Databricks, Microsoft, OpenAI, Anthropic, Google, Salesforce, ServiceNow, Vercel, Adobe, internal tools, custom orchestration. Without a spine, the enterprise gets chaos.

The most important additions are semantic and agent-facing: business glossary, domains, governed metrics, model and tool controls, tracing, policy, spend visibility, AI activity monitoring. Domains matter most — agents should not see the entire catalog by default, but the slice relevant to their purpose, role, and permission boundary.

Unity AI Gateway Governs Model and Agent Sprawl

Every large company is heading toward model and agent sprawl — different models for different jobs, frontier and open-source and specialized and hosted and local, agents deployed inside apps, workflows, notebooks, dashboards, support, marketing, security, and internal tools. The question is no longer "which model is best?" but which is approved, what data it can see, which tools it can call, what it cost, which trace explains the output, which policy applied, which agent triggered the request, which user was represented, and which response needs review.

Omnigent Accepts That Enterprises Won't Standardize

Omnigent is interesting because it acknowledges the obvious: enterprises will not standardize on one coding agent or framework. They'll have many — Claude Code, Codex, Cursor, Replit, custom internal agents, Databricks agents, vendor agents, department-specific tools. The fantasy of one enterprise agent framework is convenient for vendors and unrealistic for customers. Omnigent is a meta-harness above multiple coding agents, designed to coordinate, route, compose, and control work across them.

The future of orchestration is not only "build one better agent." It is "manage a fleet of heterogeneous agents without chaos." Omnigent is early — the real question is how it connects back to Unity Catalog, Unity AI Gateway, permissions, traces, domains, and policy. If that connection becomes real, it's a control surface for agentic software work. If not, it's an interesting orchestration layer without enough enterprise trust.

Lakebase Turns the Lakehouse Into an Operational System

Lakebase matters because agents need state. The lakehouse was historically strongest for analytical workloads, but agents don't only analyze — they remember, transact, update, coordinate, and operate. They need low-latency state stores, transactional consistency, inserts/updates/deletes, operational data, online features, application state, and memory. Lakebase brings serverless Postgres into Databricks as an operational layer governed by the same platform.

For agents, that collapse matters: the fewer copies, hops, and disconnected control planes, the easier it is to build reliable agentic applications that can reason over analytical data and act against operational state without leaving the platform.

Lakehouse//RT Makes Real-Time Agents Plausible

If agents make decisions in production workflows, they cannot always wait for slow analytical queries — they need fast access to fresh, governed data: real-time inventory, fraud signals, pricing, personalization, operational metrics, risk scoring, security events, customer behavior, supply-chain state. Historically teams copied data into separate low-latency systems, creating synchronization problems, cost, and governance gaps. Lakehouse//RT makes low-latency, high-concurrency queries possible directly on open lakehouse data — a big deal if the production numbers hold.

OpenSharing Extends Delta Sharing Into the Agentic Era

The original problem was sharing structured data safely across platforms and organizations. The new problem is broader: agents need more than tables.

OpenSharing is Databricks' attempt at an open, vendor-neutral protocol for sharing data and AI assets — including agent skills and Genie agents. Companies won't build every skill themselves; they'll consume trusted skills from vendors, partners, internal teams, and marketplaces. The question is whether that exchange happens through closed marketplaces or open protocols. Databricks is making the open-protocol bet — strategically smart, because if agent skills become a meaningful asset class, the company that helps define the sharing protocol gains influence beyond its own platform.

CustomerLake Is a Lakehouse-Native CDP

CustomerLake is Databricks' clearest move into enterprise application territory — a lakehouse-native CDP, a direct challenge to Salesforce Data Cloud, Adobe Real-Time CDP, and Segment. The argument is simple: why move customer data into a separate CDP if the governed data already lives in Databricks? CustomerLake sits inside the lakehouse, uses the data where it resides, applies Unity Catalog governance, and supports identity resolution, Customer 360, audience building, activation, and personalization agents.

That's a strong architectural argument — every CDP struggles with data movement, duplication, identity resolution, governance, latency, activation complexity, and ownership, and starting where the data lives removes some of it. But not all of it: customer data quality, identity, consent, organizational ownership, and cross-system activation are still hard. The CDP problem is not only a data-location problem. It is an operating-model problem. That is the adoption test.

LakeWatch Goes After SIEM

LakeWatch is the other major vertical move — going after SIEM and security analytics with a lakehouse-native approach. The logic mirrors CustomerLake: security data already lives at massive scale, and traditional SIEMs are expensive because they require separate ingestion, storage, indexing, and query. Keep the data in the lakehouse, govern it with Unity Catalog, query at scale, and use agents to detect, investigate, and respond. The TCO argument will get attention — but the migration reality is harder. SOCs are process-heavy: runbooks, alerting patterns, MSSP relationships, compliance workflows, analyst habits, and years of tooling around Splunk, Sentinel, CrowdStrike, Palo Alto, and ServiceNow.

That is the pattern — and it is dangerous for any enterprise software category whose product is mainly a specialized data store plus a workflow layer.

Genie Code Is a BI Migration Weapon

The Tableau and Power BI installed base is enormous. Many enterprises moved data workloads into Databricks but left their analytics front ends elsewhere. The migration friction is real — dashboards carry business logic, formulas, user habits, layout, permissions, metric definitions, and executive trust; you cannot simply "convert" a BI estate and expect acceptance. But if Genie Code can ingest a Tableau or Power BI workbook and generate a Databricks AI/BI dashboard wired to Unity Catalog metric views, Databricks gets a powerful wedge.

That creates pressure on legacy BI licensing and reinforces the broader strategy: keep the data, metrics, governance, analytics, and agents inside one platform.

Free Edition Is the Talent Strategy

Databricks Free Edition is a talent strategy disguised as product access — expanding what practitioners can use without a contract: Genie Code, serverless GPUs, Lakebase, Agent Bricks, Lakeflow Designer, and more. Data platforms are chosen by enterprises but recommended and operationalized by practitioners, who learn tools through side projects, personal work, education, and community. A serious free environment increases the odds the next enterprise recommendation starts with Databricks. This is the Snowflake contrast: Snowflake is strong in enterprise warehousing; Databricks is trying to be stronger in practitioner gravity.

Data Platforms Are Becoming Application Platforms

The thesis is strong. It also changes what Databricks is. Several of these announcements are not platform features — they are something larger.

What Was Great, What Was Missing

Databricks was strongest where it connected enterprise AI back to governed data. The company didn't pretend agents are magic — it made the right argument: agents need context, control, cost discipline, and choice. The strongest part of Summit was coherence. Every announcement pointed back to one thesis: AI agents are only as good as the governed enterprise data and context they can safely use.

The data-store advantage is real. It is not the whole product.

Enterprise Data Is Becoming the Control Plane for Agentic Work

DAIS 2026 was not mainly a data-platform event. It was a declaration that enterprise data is becoming the control plane for agentic work — a stack reorganized from storage to agents.

The operator question is no longer "should our data live in the lakehouse?" It is: how much of our agentic enterprise should be governed by the lakehouse? If Databricks is right, the companies that win with agents will not be the ones with the best generic chatbot. They will be the ones with the best governed context layer.

The Direction Is Clear. The Execution Risk Is Real.

Databricks has to prove Genie Ontology produces trusted context, that Unity AI Gateway can govern real sprawl, that Lakebase and Lakehouse//RT hold up in production, and that CustomerLake and LakeWatch can compete in markets with entrenched workflows. Watch five things:

The deeper watch item is behavioral. When business users, data teams, and agents all operate against the same governed context layer, the center of gravity shifts. That is the real DAIS signal. Databricks did not just add agents to the lakehouse. It started turning enterprise data into the agentic control plane.