Databricks thinks agents are a data-platform problem

The useful idea in this episode is not that Databricks has a new agent product. It is that Databricks sees agents as a workload that breaks at familiar systems boundaries: protocols, state, permissions, cost controls, and data freshness. Latent Space's interview with Databricks cofounders Matei Zaharia and Reynold Xin, recorded around Data + AI Summit 2026, uses Omnigent and LTAP to make one argument: production AI advantage is shifting from model selection toward the operating layer around the model 1.

Zaharia's Omnigent pitch starts from a mundane pain: engineers now juggle coding agents, cloud sandboxes, local shells, markdown previews, session history, and team review. In the transcript, he says Databricks saw the same problems in both coding agents and customer-facing enterprise agents: switching harnesses, sharing sessions, keeping history, adding search, and controlling security 1.

That is why Omnigent matters less as another agent interface and more as a proposed protocol layer. Databricks describes it as a "meta-harness" above tools such as Claude Code, Codex, Pi, and custom agents, with composition, control, and collaboration as the main jobs 2. In the episode, Zaharia narrows the core API to a few primitives: send an agent a message or file, receive text streams and tool-call streams, and cancel a turn. The point is not a giant new stack. It is a stable surface over a fast-changing set of harnesses 1.

The open-source decision follows the same logic. Zaharia compares it to Spark: if a layer benefits from integrations, connectors, and shared conventions, openness is not charity. It is how the layer has a chance to become durable 1. Databricks' own announcement says Omnigent is open sourced under Apache 2.0 2.

The strongest section of the episode is about control surfaces. Zaharia says he does not want to be the person who installs a compromised npm package and leaks company code, but he also does not want to approve every shell command one by one 1. That is the real enterprise agent problem: too little autonomy and the agent is useless; too much and it can exfiltrate data, burn money, or mutate systems nobody intended it to touch.

Databricks' product framing matches the transcript. Omnigent's policy layer can track dynamic session state, enforce permissions, pause an agent after a cost threshold, and run agents inside stronger OS sandboxes 2. The episode adds the business reason. Zaharia says security is critical for Databricks as a cloud provider, while cost controls become a separate worry when many workers run agents at scale. His example is a consulting firm where 100,000 employees each spending an extra $1,000 a month would quickly become a serious bill 1.

That turns agent infrastructure into an observability problem. Databricks is already analyzing agent traces to see which models work better on different coding tasks, according to Zaharia 1. The implication for practitioners is straightforward: the agent layer should collect traces, enforce policies, and preserve collaboration context. A prompt wrapper cannot do that reliably.

Xin's LTAP explanation sounds like a database detour until the agent connection clicks. He walks through the old split: OLTP systems such as Postgres or MySQL run transactional workloads, while OLAP systems run analytics. As soon as an application grows, teams replicate operational data into analytical systems through change data capture. Xin jokes that CDC is brittle enough to mean "continuous data corruption" because schema changes and pipeline failures can break the chain 1.

Databricks' LTAP announcement makes the architectural claim explicit: unify transactional, analytical, streaming, and operational data on a single copy of storage in the lake, rather than maintaining ETL pipelines, replicas, and hidden synchronization layers 3. The company says Lakebase, the foundation for LTAP, already serves thousands of customers and handles 12 million database launches per day 3.

The episode's useful distinction is that Databricks is not trying to collapse every query engine into one HTAP database. Xin says LTAP is "HTAP done right" because it unifies storage, not the query layer. Postgres-style transactional systems and Spark-style analytical systems can keep their strengths if they read and write against one governed storage foundation 1.

For agents, that matters because troubleshooting and decision-making need live operational context. Xin describes a customer that wanted agents to investigate SLA dips, but telemetry alone could not show who was placing orders or what was happening inside the operational database. With the data available for reasoning and analytics without hammering the production database, those agents become more useful 1.

The Mosaic section clarifies Databricks' model strategy. Zaharia says the company did release DBRX and scaled beyond Llama 3 territory, but decided not to make general frontier model training the center of the strategy. The focus is on systems that make models useful: Genie as a first-party data agent, specialized document parsing models, advisor-style components, RL fine-tuning, and customer-specific customization 1.

That is consistent with the product surface. Databricks describes Genie Agents as a natural-language way for business users to ask questions of governed enterprise data, with Unity Catalog enforcing access and audit policies 4. Zaharia's argument is that customization should get easier as base models improve, synthetic data gets easier to generate, and traces from real workloads become training material 1.

The episode's practical claim is sharper than a normal product launch: if generic reasoning keeps improving, the scarce asset is not another chat UI. It is the governed context around the model. Xin ends by saying many traditional software products may be rewritten around a simpler pattern: get the data into the right place, then put an agent on top 1.

That is easy to oversimplify. The transcript actually argues for the opposite of magic. Agents need persistent sessions, common APIs, live data, security policies, cost controls, trace analysis, and enterprise governance. Databricks is betting that the winners in enterprise AI will be the platforms that make those boring layers reliable.