The most important thing I took away from Data + AI Summit 2026 was not one product announcement.
It was the direction.
Databricks is building around a very real enterprise problem: companies want AI to help with decisions, operations, customer engagement, software development, security, and analytics, but the AI has to work inside the reality of the business.
That reality includes messy data, strict permissions, different definitions of the same metric, pipelines that break, models that drift, sensitive customer data, many clouds, many tools, and teams that already have enough platforms to manage.
This is why I found this year’s announcements interesting. They were not only about adding more capability. They were about reducing the distance between data, context, AI, governance, and action.
Context is becoming the real AI foundation
The announcement around Genie One, Genie Agents, and Genie Ontology was one of the strongest signals from the summit.
The reason is simple. A business user does not need another generic chatbot. They need an AI experience that understands how their company works.
In most organizations, the business meaning of data is spread across dashboards, SQL queries, notebooks, pipelines, documents, wikis, tickets, and team knowledge. A table may be accurate, but the real definition of the metric may live somewhere else. A dashboard may be popular, but not always certified. A calculation may be used in production, but not documented clearly.
This is the gap Genie Ontology is trying to close.
The interesting part is not only that Genie can answer questions. The interesting part is that Genie can use business context, source authority, freshness, usage, relationships, permissions, and trusted definitions to decide how to answer. That is the difference between an AI answer that sounds right and an AI answer that the business can trust.
Genie One then puts that experience where people work: data, apps, Slack, Teams, mobile, MCP-based experiences, and agent workflows. Genie Agents extend it further by letting teams create domain-specific agents grounded in the same trusted context.
For clients, this is a major point. AI accuracy will not come only from better models. It will come from giving the model the right business context, close to the governed data.
Agent engineering is becoming a platform problem
Agent Bricks and Omnigent were also important to me because they address what many teams are starting to learn.
Building an agent demo is easy. Running agents safely at enterprise scale is not.
Databricks made a very useful point in the Agent Bricks announcement: the core agent loop is only a small part of the work. The hard parts are token capacity, deployment, security, evaluation, monitoring, context, sharing, memory, cost control, and safe execution.
That matches what I see with clients. The excitement around agents is real, but the operating model is still immature. Teams are using different coding agents, different models, different harnesses, different prompts, and different security patterns. That works for experimentation. It does not scale cleanly.
This is where Agent Bricks becomes relevant. It is moving from agent building into a broader agent platform, with model choice, secure sandboxes, memory, skills, MCP support, evaluation, governance, and token controls.
Omnigent is also a smart move. Enterprises are not going to use only one coding assistant or one framework. They will use Claude Code, Codex, custom agents, internal tools, and new tools that are not even popular yet. A meta-harness gives teams a way to compose, control, and share agent workflows without locking everything to one tool.
The managed Omnigent direction on Databricks is especially practical: shared history, remote access, collaboration, isolated execution, and governance through Unity AI Gateway.
My view is that agent development is about to look more like software engineering and platform engineering. The teams that treat agents only as prompts will struggle. The teams that treat agents as governed systems will move faster and with less risk.
ZeroOps is one of the most practical announcements
I liked Genie ZeroOps because it is close to the daily pain of data and ML teams.
Anyone who has worked on a production data platform knows this pattern. A pipeline fails. A schema changes. A table looks fine but the data quality has silently changed. A dashboard number moves and nobody immediately knows whether it is a real business change or a data issue. A model starts producing weaker predictions without throwing an error.
A general coding agent can help write code, but data and AI operations need more than code. They need lineage, logs, telemetry, platform events, data quality signals, job history, permissions, and safe validation against real data.
That is why the ZeroOps flow is useful: detect, assess, remediate, and verify.
The verify step is the part I care about most. Proposed fixes can be tested in a secure sandbox using zero-copy clones, scoped permissions, and isolation before anything touches production. That is a practical enterprise pattern. It keeps people in control while cutting down the time spent on investigation and root-cause analysis.
For ML, this becomes even more important. A model can be technically “up” and still be wrong. Genie ZeroOps for ML can help investigate drift, serving errors, pipeline problems, and production performance issues. As more teams use AI to build more models and pipelines, this operational layer becomes necessary.
Real-time is moving closer to the lakehouse
Lakehouse//RT, Lakebase, Lakeflow, and LTAP all connect to a long-running architecture issue.
Many companies still use separate systems for transactions, analytics, streaming, serving, applications, and AI. This creates copies of data, sync jobs, governance gaps, and additional places where things can fail.
Lakehouse//RT is Databricks’ answer for real-time operational analytics, BI, app serving, and observability workloads directly on the lakehouse. The message I liked from the Lakehouse//RT announcement is that separate serving layers have a real cost: duplication, governance drift, and engineering overhead.
Lakehouse//RT, powered by Reyden, is aimed at millisecond performance without moving data away from the lakehouse. The benchmark numbers are impressive, but the architecture point is more important to me. If teams can serve real-time apps, dashboards, and agent workflows from the same governed data foundation, they reduce a lot of unnecessary complexity.
LTAP goes in the same direction. Lakebase supports transactional workloads. Lakeflow supports ingestion, transformation, orchestration, and pipeline development. Together, they bring transactional and analytical processing closer to the governed lakehouse.
This is very relevant for AI. Agents need current data. Customer experiences need current data. Fraud, supply chain, finance, security, and operations use cases need current data. If data is delayed or copied across too many systems, AI becomes less useful and harder to trust.
Governance has moved into the AI runtime
The Unity Catalog and Unity AI Gateway announcements may be less flashy than agents, but they are extremely important.
Governance is changing. It is no longer only about who can query a table or access a dashboard. Agents can call tools, invoke MCP servers, write code, generate artifacts, trigger workflows, and act across systems. That means governance has to follow the AI interaction itself.
Unity AI Gateway is important because it extends governance into models, agents, MCP services, skills, tools, cost controls, routing, monitoring, and runtime policy enforcement.
The partner ecosystem around Unity AI Gateway also matters. Databricks is integrating with AI security, identity, observability, DLP, runtime guardrail, and agent governance providers. That is important because large companies already have security and identity tools. AI governance cannot live in a separate island.
I also paid attention to the security and compliance announcements: Automatic Identity Management for Entra ID, Okta support in preview, Context-Based Ingress, Private Network Gateway, Lakebase private connectivity, HITRUST across clouds, expanded GovCloud support, and FedRAMP High support coming on Azure Commercial.
This is the work that makes AI usable in regulated environments. It may not get the loudest applause, but clients will care about it when they move from pilots to production.
Apps, Marketplace, and OpenSharing show a broader ecosystem play
The Apps, Marketplace, and OpenSharing announcements were also meaningful.
Databricks Apps is becoming more important because many useful enterprise solutions are small and very specific: an operations portal, a workflow manager, a data quality review app, an internal AI assistant, a model interface, or a business process app. These apps often get delayed because of infrastructure, cost, security review, or unclear ownership.
App Spaces gives admins a way to define access, resources, API scopes, and security policies for groups of apps. Genie App Builder helps teams build apps with awareness of Databricks data, Unity Catalog semantics, and workspace context. Serverless Micro Apps make the economics better for apps that are useful but not always running.
This is a good pattern: let the people closest to the business problem build, but do it inside a governed boundary.
Marketplace and OpenSharing extend this to partners and data providers.
The Marketplace commit drawdown and upcoming transactability are important for commercial adoption. Partners can reach Databricks customers more directly and shorten sales cycles by using pre-committed spend. Apps and Genie Agents can also be distributed through Marketplace, which opens new packaging models.
OpenSharing is the larger architecture move. Delta Sharing was about open, zero-copy data sharing. OpenSharing extends that idea to the agentic era: structured data, unstructured data, models, skills, semantics, and Genie Agents across clouds, platforms, and organizations.
The ability to share a Genie Agent is very interesting. A provider can share an AI experience over their data without forcing the customer to learn the schema, build a UI, or access every underlying table. That can change how proprietary data providers package their value.
This is where “pay per question” becomes more than a marketing idea. A data provider could let customers ask governed natural-language questions against proprietary data, with limits on prompts, rows, and access. That is a very different commercial model from traditional data licensing.
CustomerLake is a good example of AI moving into business workflows
CustomerLake caught my attention because it shows how Databricks is moving closer to business functions, not only technical teams.
Customer data is one of the hardest areas in any company. It is sensitive, duplicated, fragmented, and constantly changing. Traditional CDPs helped marketers activate customer data, but they often created another platform outside the governed data foundation.
CustomerLake takes a different approach by embedding the CDP into Databricks.
The idea of Golden Context is important. A customer profile is useful, but it is not enough. The AI also needs business goals, live signals, channel context, past decisions, and what has already been tried with that customer.
The idea of Infinity Campaigns is also interesting. Instead of static campaigns and large segments, the direction is always-on, real-time, 1:1 engagement where agents help adapt timing, message, and channel based on current context.
This will be a major discussion for marketing, customer experience, and data teams. The CDP conversation is moving closer to the data foundation, governance model, and AI architecture.
ML is becoming more native to the platform
The AI Platform announcements also had a strong practical angle.
Genie Code for ML is useful because ML work is not only writing Python. It includes feature engineering, experiment tracking, evaluation, model registration, deployment, serving, monitoring, drift analysis, and retraining. A generic coding agent will not understand the full ML lifecycle unless it is connected to the platform context.
Genie Code integrates with Unity Catalog, Feature Store, MLflow, AI Runtime, Model Serving, Inference Tables, and production observability. That context is what makes it more useful for ML teams.
AI Runtime is another important step. Serverless A10 and H100 GPUs, multinode training, Lakeflow Jobs support, MLflow observability, and Unity Catalog governance help teams train and fine-tune models without spending so much time on GPU infrastructure.
The real-time ML announcements also matter: streaming features, declarative feature engineering, online feature serving on Lakebase, and high-QPS Model Serving. These are the capabilities that support fraud detection, recommendations, personalization, search, and other low-latency production use cases.
The platform direction is clear: ML should not feel like a separate stack attached to the lakehouse. It should be part of the same governed system.
My takeaway
DAIS 2026 showed Databricks moving toward a more complete operating foundation for enterprise AI.
The common thread I saw across the announcements was this:
- Bring context closer to data.
- Bring governance closer to AI behavior.
- Bring real-time and transactional workloads closer to the lakehouse.
- Bring agents closer to safe engineering practices.
- Bring apps and business workflows closer to the governed data foundation.
- Bring operations closer to automation, but keep humans in control where it matters.
That is a very practical direction.
For clients, the next phase of AI will not be won by creating more disconnected AI agents. It will be won by building a foundation where AI can understand the business, access trusted data, follow governance, work with current context, and take action safely.
That is why I think the DAIS 2026 announcements are worth paying attention to.
They show Databricks moving closer to how real companies actually need AI to work.
