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

But if you look past the product list, there’s a single argument underneath all of it: it’s not an intelligence problem, it’s 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’s the framing that pulls most of this year’s announcements together. The argument: models are already good enough for most enterprise work. What’s blocking real value is that they don’t have the context they need, such as 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’s looking at.

Genie One and the agentic push

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

The interesting part isn’t the chat interface. It’s 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’s 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 experience.

The framing was different from what we usually see in agent tutorials. Instead of “here’s how to build an agent,” the entire class was structured around evaluation, so 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’s 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 (OLTP) and analytical (OLAP) workloads on a single copy of data in the lake, without pipelines, replicas, or ETL between them.

If that holds up in production, it’s 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 like Block, Zillow, and Superhuman, so the underlying tech isn’t 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’s launched but rolling out through Lakebase, so we’ll 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 didn’t get as many headlines, but they’re the ones most enterprise clients care about.

Automatic Identity Management (AIM) for Entra ID reached GA on AWS and GCP. AIM for Okta went to Public Preview. And new Context-Based Ingress policies now govern access to Genie, dashboards, Databricks Apps, and AI experiences.

Translation: the moves that let organisations actually roll Databricks out to broader user bases without security anxiety. If you’ve 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 we’re taking away from all of this:

• The context problem framing is the right lens. If your data foundation isn’t ready (governance, definitions, access controls), the new AI capabilities won’t rescue you.
• Agent Bricks looks promising. If you’re building AI agents, evaluate it against your 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 you’ll want to actually use, not just enable.
• LTAP is launched and worth trialling on the right workload, but not worth betting the whole architecture on until we see how it holds up 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.

Thinking about how Databricks fits in your stack?

If you’re working through what a Databricks build looks like in practice, the cost model, the governance work, or how it stacks up against Snowflake for your specific workloads, we’re happy to compare notes. Get in touch.