Databricks has shipped a lot in 2026. Genie One. Agent Bricks. Unity Catalog Metrics. Unity AI Gateway. LTAP. Lakebase. Plenty of new acronyms, plenty of new capabilities.

Look past the product list and there is a single argument underneath all of it: it is not an intelligence problem, it is a context problem.

The frame that ties everything together

That line came from CEO Ali Ghodsi at the 2026 Data + AI Summit keynote earlier this year, and it is the framing that pulls most of this year's announcements together. The argument: models are already good enough for most enterprise work. What is blocking real value is that they do not have the context they need, the right tables, the right business definitions, the right access controls, the right memory of prior interactions.

Every new product this year is essentially an attempt to close that context gap. Unity Catalog Metrics standardises business definitions across teams. Catalog Federation extends governance to data sitting outside Databricks. Unity AI Gateway wraps model access with observability and policy. The theme is AI that finally knows what it is looking at, which matters most for financial services and government teams where that context has direct compliance consequences.

Genie One and the agentic push

Genie One was pitched as an agentic coworker for every team, a natural language layer over a Databricks environment. Ask it questions, have it build queries, get answers grounded in governed data.

The interesting part is not the chat interface. It is the plumbing underneath. Genie now runs on pay-as-you-go pricing (150 free DBUs per user per month, then billed in DBUs), and admins can set per-user spending limits. That is Databricks acknowledging that agentic tools burn compute in unpredictable ways, and giving teams a way to control it before it becomes a finance conversation.

Agent Bricks in practice

I spent a day at Databricks AI Days back in May and sat through a session on building and evaluating production agents with Agent Bricks. Worth noting a few things from that session.

The framing was different from what usually shows up in agent tutorials. Instead of "here's how to build an agent," the entire class was structured around evaluation: how do you know your agent is actually working, how do you catch regressions when you change a prompt, how do you build a test suite that reflects real usage.

That is the right emphasis. Getting an agent to demo well is easy. Getting one that holds up in production, with governance and observability wired in, is where most builds stall. Agent Bricks is Databricks' bet on that being the harder, more valuable problem.

LTAP and the Snowflake conversation

LTAP (Lake Transactional/Analytical Processing), launched in June, is the announcement most likely to shift how teams evaluate Databricks against Snowflake. Powered by Lakebase, Databricks' serverless Postgres on open object storage, LTAP unifies transactional and analytical workloads on a single copy of data in the lake, without pipelines, replicas, or ETL between them.

If that holds up in production, it is a big deal. The classic pattern is Postgres or similar for transactional workloads, then Snowflake or Databricks for analytics, with ETL glue in between. LTAP replaces that stack with a single governed layer.

Two things worth noting. First, Lakebase already handles 12 million database launches per day across customers including Block, Zillow, and Superhuman, so the underlying tech is not a whiteboard concept. Second, the industry has attempted OLTP/OLAP convergence before: HTAP collapsed workload isolation to do it, and Zero ETL hid the pipeline rather than eliminating it. LTAP takes a different approach by unifying at the storage layer instead of the engine.

It is launched but rolling out through Lakebase, so we will be watching how it lands in production. Worth trialling on a use case where the added flexibility genuinely earns its keep before committing architecturally.

Governance keeps getting more serious

The security and governance updates did not get as many headlines, but they are the ones most enterprise clients care about.

Automatic Identity Management (AIM) for Entra ID reached general availability on AWS and GCP. AIM for Okta went to public preview. New Context-Based Ingress policies now govern access to Genie, dashboards, Databricks Apps, and AI experiences.

Translation: these are the moves that let organisations actually roll Databricks out to broader user bases without security anxiety. For a bank or a government agency that has been holding off on giving non-technical teams access because provisioning was painful, this is the release that changes that.

What we're taking away for Australian teams

A few things stand out from all of this:

• The context problem framing is the right lens. If the data foundation is not ready, governance, definitions, access controls, the new AI capabilities will not rescue it.

• Agent Bricks looks promising. Teams building AI agents should evaluate it against their custom framework. The evaluation tooling alone might be worth the switch.

• Cost management is finally being taken seriously. Per-user Genie limits and budget controls are new tools worth actually using, not just enabling.

• LTAP is launched and worth trialling on the right workload, but not worth betting the whole architecture on until it is proven in production.

Overall, Databricks is doubling down on the enterprise side of the equation: governance, observability, cost, integration, rather than chasing headline features. That matters more than a flashier release cycle would have.

Not sure how Databricks fits into your stack

The Omnia Collective works with financial services, government and enterprise teams across Australia as certified Databricks partners, helping teams work through what a Databricks build looks like in practice, the cost model, the governance work, and how it stacks up other technology. See our data engineering services or get in touch.