Databricks Data + AI Summit 2026: Context, Control, and Choice for the Agentic Enterprise

Databricks Data + AI Summit 2026 showed a company leaning hard into the next phase of the AI stack. Not just building models, but operationalizing agents against enterprise data. The company’s core message of context, control, and choice  is the right one. Enterprises do not need another isolated AI demo. They need a governed environment where agents can understand business context, act within policy, and operate across a mix of models, tools, data sources, and frameworks.

The announcements are large in scope. Genie Ontology addresses the context problem. Unity AI Gateway addresses governance and cost control. Agent Bricks and Omnigent address agent development and orchestration. Apps on Marketplace addresses distribution and activation. Lakehouse RT, Lakebase, Lakeflow, and ZeroOps address the infrastructure layer needed to support higher concurrency, lower latency, and more automated operations.

But the bigger question is not whether Databricks has assembled a compelling set of platform pieces. The question is whether enterprises are ready to trust these systems at scale. Accuracy, verification, governance consistency, and operational accountability remain the gating issues. Databricks is making the right moves, but the market should separate more capable from production-safe.

From Lakehouse to Agentic Data Platform

Databricks is positioning the next era of the lakehouse around agentic workloads. The company makes the case that today’s siloed data estate was not built for an era of conversational analytics, agents, operational analytics, and AI applications that all need low-latency access to governed data.

Agents create new requirements for data platforms. They need fresh data, fast retrieval, transaction-aware context, secure memory, traceability, tool access, and governance at runtime. They also create much higher load patterns. A world of thousands of human analysts querying dashboards is different from a world of agents continuously reading, reasoning, writing, retrying, and creating intermediate artifacts.

Databricks’ Agentic Data architecture is its answer to this shift. The company is extending the platform across real-time ingestion, Lakehouse RT, Lakebase, Lakeflow, Unity Catalog, Unity AI Gateway, Agent Bricks, Genie, and Apps. Databricks is no longer just competing as a data platform. It is increasingly competing as an AI operating layer.

Genie Ontology Helps Accuracy, but Verification Remains the Gap

Genie Ontology is one of the most important announcements because it targets the central problem in enterprise AI: models do not understand the business unless business context is made explicit.

Databricks describes Genie Ontology as a self-improving enterprise context graph that can learn from agents, tools, knowledge sources, APIs, MCP services, permissions, and user interactions. Enterprise data agents need more than schema awareness. They need business definitions, metric logic, process context, permissions, usage history, project knowledge, and organizational language.

We like the move toward ontology because it can improve accuracy by giving Genie a stronger business-context layer. But this is where we remain cautious. If Databricks’ own data shows ontology and related techniques can improve accuracy up to roughly 91%, that is meaningful progress, but it is still roughly one in ten wrong answers. That is not accurate enough for workloads where the cost of being wrong is high, where answers trigger downstream actions, or where the system is operating at scale.

The issue is not whether Genie can produce better answers. It likely can. The issue is whether Databricks is doing enough on verification. Databricks should talk more explicitly about confidence thresholds, answer validation, exception handling, approval workflows, lineage-backed explanations, and mechanisms to prevent wrong-but-confident answers from entering high-stakes workflows.

Unity AI Gateway Addresses Agent Sprawl

Unity AI Gateway may be the most practically important announcement for CIOs. Agent sprawl is real, and we do not think most enterprises have fully internalized how difficult it will be to manage.

Every developer may use a coding agent. Every business function may want an AI coworker. Every application may expose agents or MCP tools. Every vendor may bring its own agentic layer. Very quickly, enterprises could have thousands of agents interacting with sensitive data, operational systems, documents, APIs, and each other.

That creates a new governance surface. It is not enough to govern data access. Enterprises need to govern model access, tool access, MCP calls, agent identity, cost, memory, logs, traces, skills, prompts, policies, and runtime behavior.

Unity AI Gateway is Databricks’ answer to that problem. The strategy makes sense: extend the governance foundation of Unity Catalog into runtime AI interactions. The challenge is execution. Enterprises will not only run Databricks-native agents. They will use Microsoft, AWS, Google, OpenAI, Anthropic, internal tools, third-party SaaS agents, coding agents, and industry-specific agents. Unity AI Gateway’s value will depend on how well it governs not just Databricks workloads, but the messy reality of enterprise AI systems outside the Databricks perimeter.

Omnigent Is Interesting, but the Governance Model Needs Clarity

Omnigent is one of the more interesting announcements because it acknowledges a real pattern in agent development. Enterprises are not going to standardize on one harness, one agent framework, or one model provider. Teams will use different coding agents, business agents, custom agents, frameworks, SDKs, and model combinations.

If agents are becoming composable systems, enterprises need a way to combine, control, and collaborate across multiple harnesses. Omnigent’s approach could help teams coordinate agents, share sessions, apply policies, and avoid being locked into a single agent development environment.

However, we would like more clarity on how Omnigent fits with Unity AI and Unity AI Gateway. Where are policies authored? Where are they enforced? How are identities assigned? How does Omnigent handle tools, memory, context, and session history in a way that remains auditable in Unity Catalog? Omnigent is directionally aligned with where agent development is heading, but for enterprise buyers, the governance architecture will matter as much as the developer experience.

Apps on Marketplace Blurs the App-Agent Boundary

The Apps on Databricks Marketplace announcement is strategically important because it moves Databricks further into application distribution. The idea that third-party data and AI applications can run inside the customer’s governed Databricks environment is compelling. It reduces the need to move sensitive data to external applications and gives providers a new way to package and monetize data-driven software.

But the announcement also raises a question we keep coming back to: how do we define an app versus an agent? A traditional app has a user interface, business logic, permissions, and workflow. An agent also has logic, permissions, tools, memory, and workflow execution. As Databricks Apps, Genie, Agent Bricks, Marketplace, and AI workflows converge, the distinction gets blurry.

This matters because governance models may differ. If an app displays data, the risk profile is one thing. If an app embeds an agent that can retrieve data, invoke tools, trigger workflows, write back to systems, or make recommendations at scale, the risk profile changes. Databricks should be more explicit about the taxonomy. Data apps, AI apps, agents, agentic workflows, agent tools, and packaged solutions should not all collapse into one bucket.

ZeroOps and Agentic Infrastructure Point to the Operational Burden Ahead

ZeroOps is interesting because it reflects the broader truth that enterprises cannot scale agentic systems if the infrastructure burden scales linearly with usage. As agents generate more queries, pipelines, jobs, sessions, traces, and intermediate artifacts, the operational surface expands. Data teams will need automated optimization, monitoring, cleanup, debugging, and reliability management.

Databricks’ positioning around ZeroOps, Lakeflow, Lakehouse RT, Lakebase, and real-time infrastructure recognizes that AI workloads are not just another analytics workload. They are more dynamic, more concurrent, more iterative, and often more latency sensitive. Agents blur the line between analytics and transactions. They read and reason before they act, and in many cases they need operational state, memory, and recovery.

The caution is that zero ops is an aspiration, not an absolute state. Enterprises will still need controls, architecture decisions, data quality practices, observability, incident response, and cost governance. But the direction is right considering AI scale will require more automation in the data stack.