Four days. Thirty thousand people on the floor at Moscone. Over 800 sessions. And one thesis that ran through every keynote, every breakout, every conversation in the hallways: the agent is now the primary consumer of enterprise data, and the platform either serves that reality or becomes legacy. This is not a summary of announcements. It is a field report on what the announcements mean architecturally, what changes in your stack, what questions it opens, and where I am still not convinced.
1. The data layer: LTAP, Lakebase, and Reyden
The most structurally significant announcement of the summit was not an agent product. It was LTAP - Lake Transactional/Analytical Processing. The claim is fundamental: a single storage layer, in open formats (Delta and Iceberg), serving both OLTP (transactional, via Lakebase serverless Postgres) and OLAP (analytical, via the Lakehouse) with no CDC pipelines between them, no hidden replication, no ETL sync jobs.
Lakebase, now handling twelve million database launches per day, adds git-style database branching (spin up a full-fidelity copy of production in seconds for safe agent debugging), cross-cloud disaster recovery, autonomous database operations where an AI agent monitors health and proposes indexes, and Lakebase Search — hybrid vector and full-text retrieval native to Postgres with 32x compression for billion-scale vector indexes. The vectorized Reyden engine underneath delivers sub-100ms analytical query latency at twelve thousand queries per second directly on Delta and Iceberg tables - no separate serving layer required.
LTAP architecture: what it removes from the stack
- Open storage layer: Delta Lake + Apache Iceberg -single copy of data, no replication, no ETL
- Unity Catalog: Single governance plane: identity, permissions, lineage, audit across both OLTP and OLAP
- Lakebase (OLTP): Serverless Postgres · full ACID semantics · git branching · autonomous ops
- Lakehouse//RT (OLAP): Reyden engine · sub-100ms latency · 12,000 QPS · no separate serving tier
- LTAP promise: Transactional + analytical workloads on one copy of data - eliminates CDC pipelines and reverse-ETL tooling entirely
Architectural tradeoff analysis
What it changes
- Eliminates CDC pipelines and reverse-ETL tooling from the stack
- Single governance model for transactional and analytical data
- Agents can read and write operational state without pipeline lag
- Lakebase branching enables safe agent debugging on live production data
- Reyden removes the need for a separate real-time serving layer
What to stress-test
- LTAP is “coming soon” - not GA, not in production anywhere yet
- Mixed OLTP/OLAP workload isolation at scale is a historically hard problem
- Reyden latency benchmarks are internal - independent validation needed
- Migration path from existing Postgres + Lakehouse setups is not yet documented
2. The agent platform: Omnigent, Agent Bricks, Unity AI Gateway
Omnigent - the meta-harness
Omnigent is an open-source orchestration layer that sits above existing agent frameworks - LangGraph, CrewAI, coding agents, custom agents - and provides three things those frameworks do not individually offer: composition (run multiple agents from different harnesses as a single workflow), collaboration (shared memory and history across agents, not just within one agent), and control (cost enforcement, security policy, and routing applied uniformly regardless of which harness is underneath). Managed Omnigent on Databricks runs these workflows on Lakebox with isolated cloud execution. The fact that this is open-sourced is not altruism - it is a bid to define the standard above the harness level, the same way Delta Sharing defined the standard for open data sharing.
Agent Bricks - the governed runtime
Agent Bricks provides the four things any production agent needs: choice of model (frontier models, reinforcement learning models, managed Omnigent workflows, or custom agents), context (Unity Catalog, Genie Ontology, Document Intelligence, Managed External MCP, Agent Memory), a sandbox (Databricks Sandbox for isolated execution), and the Unity AI Gateway as the control plane. The combination is the closest thing to a governed agent runtime I have seen from any platform vendor - the key word being “governed,” not just “capable.”
Unity AI Gateway - the control plane
The Unity AI Gateway is the piece that makes Agent Bricks enterprise-ready rather than just enterprise-marketed. It provides an Agent Registry (every agent is a registered Unity Catalog asset), Contextual Policies (access control applied at inference time), Budget enforcement (hard spend caps per agent, per team, per model), Smart Routing (quality-cost tradeoff routing across model endpoints), and Agent Tracing piped directly into Lakewatch. This is the architecture for AI governance in a world where agents are running autonomously, not just responding to individual human queries.
Agent platform layer diagram
- Omnigent: Open-source meta-harness · composition across frameworks · shared history · uniform control · open-sourced
- Choice (Agent Bricks): Frontier models · RL models · Custom agents · Managed Omnigent workflows
- Context (Agent Bricks): Unity Catalog · Genie Ontology · Document Intelligence · Managed External MCP · Agent Memory
- Sandbox (Agent Bricks): Databricks Sandbox · isolated cloud execution on Lakebox
- Unity AI Gateway: Agent Registry · Contextual Policies · Budget caps · Smart Routing · Agent Tracing → Lakewatch
Architectural tradeoff analysis
What it changes
- Harness choice becomes portable - Omnigent abstracts above LangGraph, CrewAI, etc.
- Cost and policy governance is now an infrastructure concern, not an application concern
- Agent Registry in Unity Catalog means agents are governed assets, not scripts
- Smart Routing reduces model cost without application code changes
What to stress-test
- Omnigent adds a layer - any new abstraction adds latency and failure modes
- Open-source bets on community adoption; without critical mass it stays Databricks-specific
- Budget enforcement requires all AI spend to route through the gateway - incomplete coverage breaks the model
3. Genie One and Genie Ontology - the context layer
Genie has become a full product family. Genie Ontology is the piece that matters architecturally: a continuously updated context layer that ingests enterprise data, documents, tags, application metadata, and usage patterns to build a live semantic model of the organization. It is Databricks’ answer to the enterprise AI context problem - the reason most enterprise AI gives confidently wrong answers is not that the model is bad, it is that the model does not know what “margin” means in your organization specifically, what the authoritative source of truth is for a given metric, or which of six competing definitions of “customer” your finance team uses.
Genie One is the application layer on top: an agentic coworker available on web, iOS, and Android that answers ad-hoc data questions, produces reports and documents, manages alerts, and executes actions through MCP tools. Native integrations with Google Drive, Jira, Slack, Confluence, and SharePoint are included. Genie Agents lets non-technical users create and share reusable agents - domain knowledge packaged as a governed Unity Catalog asset. Genie App Builder creates applications from plain language descriptions, built on AppKit (a TypeScript SDK with pre-built plugins), governed by Unity Catalog from the start.
4. Agentic ML Engineering
The ML engineering announcements were framed by a simple claim: “we want to automate ML.” AI Runtime is a serverless GPU infrastructure for enterprise deep learning with multi-node training support, now generally available after two months in preview. Genie Code for ML is a natural language interface for ML workflows - writing training code, debugging pipelines, selecting hyperparameters. Genie ZeroOps for ML is the production operations layer: an agent that monitors model health, detects degradation, and manages retraining pipelines without requiring manual intervention.
The architectural implication is significant but uncomfortable. If Genie ZeroOps for ML works as described, the ML engineer role shifts from pipeline plumbing toward outcome definition - specifying what you want the model to do, not how to build the infrastructure to do it. That is a genuine change in what a senior ML engineer spends time on. It is also a change that historically takes two to three years to materialize in practice after the tooling is announced, because the institutional knowledge, the debugging expertise, and the edge-case handling that currently live in engineers’ heads do not transfer to an automated agent overnight.
5. Databricks Apps - the delivery layer
Databricks Apps is the managed application runtime: any framework, AppKit plugins for TypeScript, managed containers, built-in Unity Catalog governance, and real-time observability out of the box. Three new capabilities were announced: App Spaces (a governance boundary that sets resource access, security policies, and Unity Catalog permissions once for a group of apps), Serverless Micro Apps (a lightweight runtime that scales to zero when idle, making a broad portfolio of internal tools economically viable), and Genie App Builder (natural language app creation from descriptions, with full awareness of your data assets and Unity Catalog semantics).
The prediction of one billion apps built by citizen developers sounds like marketing. The architectural underpinning is more interesting: if Genie App Builder generates AppKit-based applications that are governed by Unity Catalog at generation time, then the compliance and access control problem for a portfolio of internal tools becomes a configuration problem rather than a development problem. That is a genuine architectural shift — not in how you build individual apps, but in how you manage the governance of many apps at scale.
6. Data governance, quality, and reliability at scale
Unity Catalog - extended
Unity Catalog received a meaningful set of extensions across the summit. External access to managed Delta tables (public preview) lets Spark and Flink write directly from outside Databricks. A new FILE type enables native governance of unstructured data - PDFs, images, audio, video - in Delta and Iceberg tables. Geospatial types in Delta and Iceberg v3 are now GA. External lineage is generally available, extending the lineage graph to upstream source systems and downstream BI tools. Lakeflow Connect pipelines automatically contribute their lineage. Column-level popularity signals feed the Genie Ontology. ABAC policies for row filtering and column masking are GA. The Governance Hub (private preview) centralizes governance operations across data, AI, cost, and performance.
OpenSharing - the open protocol for AI assets
OpenSharing, now a Linux Foundation project, is the evolution of Delta Sharing for the agentic era. Where Delta Sharing covers structured data, OpenSharing extends the protocol to cover AI assets: agent skills, models, Genie Agents, and unstructured data. On-premises storage partners - MinIO, Qumulo, NetApp, Nutanix, HPE - implement the protocol natively, enabling zero-copy access to data that cannot move to the cloud. SecureConnect enables one-time network setup for unlimited cross-cloud recipients. Global Distribution provides automatic cross-region replication with no egress overhead. Iceberg Interoperability enables sharing to any platform supporting Iceberg, including Snowflake.
Lakewatch SIEM - security and AI observability
Lakewatch is Databricks’ lakehouse-native SIEM: built on Unity Catalog and the Open Cybersecurity Schema Framework, it unifies security telemetry with business data and deploys Genie agents for threat detection and response. Agent Tracing from the Unity AI Gateway feeds directly into Lakewatch, creating a unified observability layer that covers both data operations and AI agent activity. The claimed TCO reduction of up to 80% versus traditional SIEM tools is based on the elimination of the dedicated security data lake that most enterprise SIEMs require.
Governance layer architecture
- Unity Catalog: Metadata + governance plane: lineage · ABAC · multimodal data types · geospatial · Governance Hub
- OpenSharing: Linux Foundation protocol: data · models · agent skills · Genie Agents · zero-copy cross-cloud
- Lakewatch SIEM: OCSF-based · unified security telemetry · AI agent tracing · Genie threat detection · up to 80% lower TCO
- Delta Lake / Iceberg: Open storage foundation: single source of truth for data and AI governance
7. CustomerLake - the agentic CDP
CustomerLake is Databricks’ answer to the traditional customer data platform: an agentic CDP built directly into the lakehouse, governed by Unity Catalog, with no data movement required. Profile Agents maintain continuously updated customer profiles (“Golden Context” - their replacement for the static “Golden Record”). Campaign Agents analyze customer signals and orchestrate personalized engagement across channels autonomously, replacing static segmentation and one-off campaign design.
The architectural bet: the best place to run marketing intelligence is where your customer data already lives, not in a separate MarTech platform that requires a copy of it. Whether this is true depends on your organization - if your customer data is already high-quality and in Databricks, CustomerLake is a compelling architectural simplification. If your customer data is fragmented across a CRM, an email platform, a web ana
The full platform stack assembled
Looking at all of the above together, the picture that emerges is not a collection of product announcements. It is a vertically integrated platform architecture where each layer has a clear role and each layer produces outputs consumed by the layer above it.
- Delivery layer: Databricks Apps · Genie One · Genie App Builder · CustomerLake (agentic CDP)
- Agent runtime: Omnigent + Agent Bricks · model choice · context · sandbox · Unity AI Gateway (policies · budgets · routing · tracing)
- Context + ML: Genie Ontology (enterprise context layer) · AI Runtime · Genie Code for ML · Genie ZeroOps for ML
- Governance plane: Unity Catalog · OpenSharing · Lakewatch SIEM · ABAC · External lineage · Governance Hub
- Data + pipeline layer: Lakeflow · Lakebase · LTAP (unified OLTP/OLAP) · Lakehouse//RT · Reyden engine
- Open storage: Delta Lake · Apache Iceberg · open object storage · single copy of data
What this collectively signals
Databricks is not building a better data warehouse. The warehouse is one component in a platform designed around a different primary consumer: the agent. Every layer of the stack announced this week serves an agent’s needs - low-latency transactional access via LTAP, governed context via Genie Ontology, isolated execution via Agent Bricks and Omnigent, cost control via Unity AI Gateway, security observability via Lakewatch. The architecture is coherent and the integration between layers is tighter than anything they have shown before.
The strategic bet is vendor consolidation: Databricks wants to be the layer at which every enterprise architectural decision converges - the place where data, models, agents, and applications all operate under a single governance model, with a single cost model, with a single identity and access model. That is a compelling value proposition in an environment where most enterprises are managing five to fifteen separate platforms that do not share governance. It is also a significant concentration of vendor risk, which is the conversation every CTO should be having with their team now rather than after the contracts are signed.
My honest question leaving San Francisco
The velocity of announcements is real. The integration story is coherent. The architecture is intentional in a way that it has not always been from Databricks. But the question I am sitting with is not whether the vision is right - it is how fast teams can actually realize value from this stack. Historically, the gap between a compelling summit demo and a stable production deployment has been twelve to eighteen months at minimum. Several of the most important pieces - LTAP, Omnigent, Genie ZeroOps for ML - are in preview or “coming soon.” The operational maturity of Genie Ontology at scale, where the quality of the context layer depends entirely on the quality of the enterprise metadata underneath it, is genuinely unknown until customers with complex data estates run it in production.
None of this is pessimism. It is the right question to ask before committing your roadmap. The Agentic Era is not coming. It is being engineered, in Moscone, this week, by thirty thousand people who build the platforms the rest of the world runs on. The question is not whether it arrives — it is whether your organization is ready to extract value from it on the timeline you need, or whether the gap between the demo and the deployment is the thing that costs you most.
.webp)
