By using our site, you acknowledge that you have read and understand our Privacy and Cookie Policy.
All trademarks listed on this website are the property of their respective owners. All rights reserved.
Copyright © 2026 DataArt

Databricks Data + AI Summit 2026 opened with a provocation. Ali Ghodsi asked the audience to raise their hands if they thought AGI was already here. Roughly 5% did.

He then put a graduate-level algebraic topology problem on the screen and noted that every frontier model can solve it trivially. His point: the intelligence question has largely been answered. What frontier models still can't do is reason about your organization — your definitions, your data, your processes, your people. That gap, not intelligence, is the actual constraint on enterprise AI agents.
Everything for the next two days flowed from that framing. The announcements weren't about more capable models or faster inference — they were about solving the organizational context problem and building the governance, cost infrastructure, and AI agent orchestration capabilities that enterprise AI agents need before they reach production at scale. That's a different kind of conference from the capability showcases of the past two years.
At DataArt, our teams work with enterprises building modern data platforms, cloud-native architectures, and AI solutions.
Rather than simply recap announcements from Databricks Data + AI Summit 2026, our goal is to evaluate which innovations meaningfully change enterprise architecture today, which remain roadmap promises, and what they mean for organizations preparing enterprise AI agents for production.
Below are the areas that matter most, with enough detail to evaluate the claims rather than just the headlines.
The centerpiece announcement of Tuesday's keynote is also the one that will take longest to play out in practice. Databricks' diagnosis is sharp: most organizations solve the context problem by stuffing custom instructions, skills files, and semantic layers into each individual agent. It works at small scale, but as agent count grows it recreates the inconsistency problem semantic layers were invented to fix — except now agents confidently give different answers to the same question, rather than dashboards disagreeing silently.
For organizations deploying enterprise AI agents, this is fundamentally an AI agent orchestration problem: maintaining context separately inside every agent becomes difficult to govern, expensive to maintain, and increasingly inconsistent as agent count grows.
Genie Ontology is the proposed alternative: a knowledge graph of the organization built continuously in the background from everything that already exists — query histories, dbt models, dashboards, Spark pipelines, Jira, email, Slack, SharePoint, Google Calendar. The engine behind it, OntoRank, works like PageRank over enterprise knowledge assets, scoring facts by frequency of reference, source authority, and domain expertise. High-scoring snippets get injected into agent context at query time, permissions already enforced — no new authoring workflow, no separate tagging exercise.
The accuracy numbers Databricks cited — jumping from roughly 25% to over 80% on their internal benchmark — were caveated on stage by the presenter himself, and rightly so: that's one benchmark on one company's data. But the directional argument doesn't depend on the specific number — a self-building, shared knowledge graph is a different architecture from per-agent context hacks, and the difference matters more at scale, not less.
Ken's live demo made the mechanics concrete. Genie One was asked to prepare for an exec review, pulling procurement data from Databricks, Jira tickets, and a Google Drive document. Rather than doing a live traversal of all those systems — the approach that makes coding agents slow and expensive — it looked up relevant ontology snippets first, found an authoritative definition of "engagement" and the right SQL for pulling it by region, then went directly to the sources it needed. Thirty seconds versus thirty minutes. The accuracy came from the organization having already defined things, with the ontology making that work available at query time.
The commercial implication was stated directly: Thomson Reuters consolidated 23 customer-data sources into a single governed semantic foundation before deploying agents, and that prior investment is what makes their agents trustworthy today. The broader lesson: organizations with authoritative definitions of their business concepts will get dramatically more value from enterprise AI agents than those relying on fragmented, per-implementation context.
Three structural announcements landed across Tuesday and Wednesday, each addressing a different facet of the same problem: the enterprise data stack was designed for human workflows, and it doesn't serve agents well. Taken together, Reyden, Lakebase, and LTAP mark a significant evolution in lakehouse architecture — Databricks is increasingly designing the platform around agents operating at production scale, not just analysts or applications.
Reyden (the engine; the product is Lakehouse RT) is the most immediately testable. Most database engines take academic techniques and validate them against benchmarks that don't fully represent real production traffic. Reyden was built the other way: Databricks profiled trillions of real customer queries, modeled which algorithmic choices actually perform well, and built the engine around those findings. The result is millisecond tail latency at high concurrency, directly on Delta or Iceberg data, without a separate serving tier.
Design-partner numbers were striking — Enverus reported a 16x average speedup, with longest queries shrinking nearly 100x — with the usual caveat about workload specificity. The more durable claim is architectural: if Lakehouse RT holds up on your workload, the overhead of a separate real-time serving stack (Pinot, Druid, ClickHouse) potentially goes away.
Lakebase (serverless Postgres on the lake, GA since February) got meaningful hardening at Summit — PrivateLink, customer-managed keys, cross-cloud disaster recovery — but branching drew the most attention. Any Lakebase database can be cloned in under 500 milliseconds using copy-on-write semantics, essentially free until writes diverge. For agents: branch from production, run an experiment, verify, commit or discard, with no risk to live data. MasterCard's story was the most concrete validation — a virtual CFO product with full multi-tenant isolation for thousands of issuing banks, from concept to scale-ready MVP in seven weeks.
LTAP (Lake Transactional Analytical Processing) is what Reynold Xin called "probably as big as Reyden" and arguably should have been the headline. HTAP as a category has mostly failed because a single engine simultaneously optimized for row-oriented transactional and column-oriented analytical workloads forces compromises on both. CDC is the industry's fragile workaround — hence the on-stage joke that it more often stands for "continuous data corruption."
LTAP sidesteps the engine problem. Lakebase's storage layer is IO-bound but leaves CPU idle; LTAP uses that idle CPU to transcode incoming row-format writes into columnar Delta/Iceberg at write time, so the same physical data is simultaneously available in row format for transactions and column format for analytics — no pipeline, no secondary copy, no governance split. In the demo, an active Lakebase database feeding transaction processing also appeared as a managed Unity Catalog table readable by SQL warehouses in real time, sub-second fresh, with no measurable impact on transactional throughput.
If both people and enterprise AI agents increasingly require governed, real-time access to operational data, does maintaining separate transactional and analytical systems still make sense? The caveat: LTAP is rolling out incrementally — the initial capability is read-path analytics from Lakebase tables, with the reverse direction on the roadmap. Evaluate the current capability, but design against the roadmap.
Genie is now a complete system with three distinct layers. Genie One is the business-user surface — one interface, backed by the ontology, usable by any employee without warehouse configuration or data engineering context. The PepsiCo adoption signal was striking: 30,000 procurement queries in the first weeks, for a capability that previously took three to six months to productionize per use case. Accuracy crossed the threshold where business users trusted the answers, and adoption became spontaneous.
Genie Agents converts a working Genie conversation into reusable infrastructure. A business user builds a conversation that works — say, a weekly procurement report pulling from four systems — turns it into a scheduled, shareable agent, no code required. It runs on schedule, surfaces anomalies proactively, and answers follow-ups. The HR Q&A agent, the supply-chain exception tracker, the sales-forecasting briefing all become self-service rather than recurring data-team tickets.
Genie Code is the most operationally significant layer for data engineering and ML teams. Pipeline authoring is already established — 60% of new Lakeflow pipelines are now written by Genie Code within three months of launch. The new capability, Genie Zero Ops, runs autonomous pipeline operations continuously: when a pipeline breaks, it detects the anomaly via per-table ML models, walks lineage in Unity Catalog to find the upstream cause, writes a fix, validates it in a copy-on-write clone of production, and surfaces a pull request — often faster than an on-call engineer could open their laptop.
Genie Zero Ops for ML is the more novel piece. A ticket-sales forecasting model had drifted because a key feature was missing from training data. Zero Ops detected the drop, identified and built the missing feature, retrained the model, validated against the team's own evaluation scripts, and prepared a one-click deployment. The on-call engineer received a solution, not a problem.
The governance announcement got the most sustained attention across both keynotes. Uber burning through a year's AI budget in a single quarter is a cautionary tale, not an outlier: agentic workloads generate costs that vary wildly by individual and compound silently, in ways FinOps frameworks built around predictable batch jobs never anticipated.
Unity AI Gateway is the answer — a single choke point every model call, MCP tool invocation, agent action, and skill execution passes through, with five distinct governance layers.
The agent registry is the prerequisite for everything else: a centralized inventory of every agent, model, MCP server, and skill in the organization, regardless of which tool built it. You can't govern what you can't see.
Contextual security policies are the most technically interesting control. Traditional IAM is static — permissions attached to an identity — but an agent acting for a long-tenured employee will attempt to use every permission that person has accumulated over years, including ones tied to a previous role. Contextual policies are stateful instead: the gateway tracks what data an agent has touched in the current session and updates what it's allowed to do next. An agent that has read PII-tagged records cannot subsequently write to an external endpoint; the same agent in a session that only touched public data, can. No prior governance framework has had this primitive.
Intelligent routing automates the cost-quality tradeoff most organizations leave to individual developers, which defaults to the most expensive model. In Databricks' own engineering org, 90% of coding-agent sessions defaulted to Opus; routing steers simpler tasks to cheaper models — including Databricks Kimmy, a new cost-optimized model — and escalates only complex ones.
Budget policies go beyond alerting. An alert that fires after a budget is exhausted is an audit record, not a control. The gateway supports automated circuit breakers — spend policies that warn, then downgrade model choice, then stop, at configurable thresholds per user, group, or project.
Agent tracing via MLflow stores complete session records — input, reasoning chain, output — in Unity Catalog tables governed by the same ABAC policies as any other sensitive data. Debugging and cost analysis are the stated use, but the link to Lakewatch for real-time anomaly detection on agent behavior may matter more long-term.
Matei Zaharia's Wednesday session named a real problem honestly: the proliferation of agent frameworks (Claude Code, Codex, LangGraph, the OpenAI Agents SDK, and a long tail of custom harnesses) has produced an ecosystem where teams on different tools can't collaborate, can't compose agents across harnesses, and can't apply consistent cost or security policies. Vibe-coding your own harness faster only adds to the fragmentation.
Omnigent, open-sourced the Saturday before the conference, is a meta-harness: a layer that wraps existing agent tools and provides shared primitives for composition, live collaboration, cost policies, and OS sandboxing — without replacing any harness. It works with Claude Code, Codex, and any SDK-based custom agent, giving each a web and mobile interface alongside its native terminal; multiple wrapped agents can run in parallel on a shared workstream, a colleague can join an active session to comment or message the agent in real time, and full session history is stored centrally.
The composition demo was most practically relevant: Omnigent ran a multi-agent coding supervisor (Polly) that dispatched subtasks to both Claude Code and Codex in parallel, collected outputs, and synthesized a judgment — a pattern practitioners already run manually by toggling windows and copy-pasting, now native, auditable, and cost-governed. Pairing Omnigent's routing with the Unity AI Gateway's budget policies meaningfully reduced AI spend on real engineering workloads in the demo.
Omnigent requires no Databricks at all — it runs on Docker, Postgres, and OpenTelemetry. That open-source posture is the right call: a meta-harness that only works inside one vendor's ecosystem doesn't solve the interoperability problem.
Databricks has been the most consistent advocate for open data formats in the industry, and DAIS 2026 delivered progress rather than reaffirmation. Iceberg v3 is now GA in Databricks Runtime, and full Delta/Iceberg format unification means the same physical files are readable as either format without conversion. Ryan Blue (Iceberg's creator, now at Databricks via Tabular) confirmed Iceberg v4, which completes metadata unification, is on track for Q4.
Open Sharing supersedes Delta Sharing and now covers AI assets (agents, models, skills) as well as data tables, with no Databricks account required on the receiving end — relevant for sharing governed AI capabilities across subsidiaries, partners, or regulatory boundaries.
Lakeflow Connect reached 100-plus connectors; Lakeflow Jobs added 50-plus third-party orchestration integrations including Snowflake. Lakeflow Designer, a no-code tool that compiles visual transformations into open-source Spark pipelines, went GA, extending the open foundation to business analysts who currently build shadow pipelines in proprietary tools.
Unity Catalog is free and open-source, and the AI Gateway is part of it at no extra charge — Databricks keeps betting that platform adoption follows from a free governance layer.
The model posture at DAIS 2026 is unsentimental about which model wins — it changes week to week, and the platform's job is to make switching cheap rather than pick a winner. Grok joins Anthropic and OpenAI as natively integrated families; Databricks Kimmy targets high-volume simple queries; AI Runtime brings serverless GPU access for fine-tuning and deep learning with no upfront commitment.
On the vertical side, Lakewatch (agentic SIEM) tackles a security problem that's gotten genuinely harder — LLMs have lowered the barrier to exploiting vulnerabilities, automated attacks now outpace human SOC teams, and legacy SIEM tools can't ingest the needed data volume. The Panther Labs acquisition adds a production security layer and a customer list validating the problem is real. Customer Lake (agentic CDP) introduces Infinity Campaigns, per-customer agent-driven marketing personalization, as an alternative to audience-segment design. Both are early, but the logic holds: governed agents against data already in the lakehouse cost far less than a purpose-built SaaS with its own integrations.
The thread connecting all of it: agents need organizational context to be useful; context needs to be built as shared infrastructure rather than per-agent; shared infrastructure needs cost and security controls designed for agentic workloads; and the data layer underneath needs to be unified enough that agents don't face a different governance world depending on which system they're querying.
For organizations evaluating enterprise agentic AI, DAIS 2026 raises three practical questions:
DAIS 2026 addressed each step with concrete product announcements, not roadmap slides. The gap isn't the platform anymore — it's organizational readiness: whether teams deploying enterprise AI agents plan for context, governance, and cost discipline from the start, or intend to retrofit them later. The retrofit path is consistently harder than it looks in advance.
The most important takeaway isn't that AI models became dramatically more capable, it's that the conversation has shifted from model performance to enterprise readiness. The technical building blocks for enterprise agentic AI — shared organizational context, modern lakehouse architecture, AI agent orchestration, and agentic AI governance — are rapidly falling into place. The remaining challenge is whether organizations build these as foundational infrastructure now, rather than retrofit them later.
If you'd like to discuss what these announcements mean for your own AI roadmap, connect with DataArt's Data & AI team to explore how these architectural shifts apply to your organization.
Subscribe now to get a monthly recap of our biggest news delivered to your inbox!