A calm read of the previews that matter this week, and what they change for the way you build.
Every week, a small set of preview features quietly appears inside Databricks. Most engineers scroll past them. That is fair. Preview features move, break, and sometimes disappear.
But if you read them slowly, they tell you where the platform is going. That signal is worth more than any keynote.
The batch that showed up in mid to late July 2026 is one of the more interesting ones in a while. It is not a single flashy launch. It is a quiet shift in what a data platform is expected to do.
Three things stood out. Agents got programmable. Agents learned to read files, not just tables. And pipelines finally started to feel like real software.
The rest of this piece is a calm walk through what changed and what it means for the way you build.
A quick note before we start. Everything below is in preview. That means the shape can change, the naming can shift, and some things will look different when they are generally available. Do not build your Monday morning production on a preview. Do use previews to test ideas and to shape your next quarter.
For most of the last year, Genie Agents were something you used in the Databricks UI. You opened a space, asked questions, watched an agent reason over your tables, and moved on. If you wanted to automate that experience, you were mostly limited to a simpler mode of Genie.
That gap is closing. Agent mode is now available through the API in preview.
This is a small change on paper. It is a large change in practice. It means an agent that can plan, call tools, and refine its own answer is no longer trapped behind a workspace tab. You can call it from a Python job. You can put it behind an internal application. You can build a small workflow that uses it once a day to draft a report.
The important part is not that we suddenly need to build agent apps everywhere. It is that the option now exists inside the governed platform, next to your Unity Catalog tables and your Lakeflow jobs. That matters, because the alternative is stitching together a separate stack of tools that do not know about your data governance at all.
If you are new to agents on Databricks, start with the Machine Learning chapter and then read Agent Bricks is GA. Here's how to ship an agent without regret before you touch the API.
The second update is the one that will change more day-to-day work.
Genie Agents can now analyze files stored in Unity Catalog Volumes, in preview. Not just tables. Actual files. PDFs, text, structured documents, anything you have already landed in a governed Volume.
For a long time, the honest answer to "can your agent read this policy document?" was "we have to build a small side pipeline, extract the fields, load them into a table, and then let the agent see the table." That works. It also takes weeks and adds a system to maintain.
Bringing files into agent scope changes the shape of that work. The document stays where it is. The permissions stay on the Volume. The lineage stays inside Unity Catalog. The agent reads what it is allowed to read, nothing more.
If you have been waiting for a governed way to let a small internal agent answer questions across a folder of onboarding documents, an archive of past incident reports, or a Volume of supplier contracts, this is the update you were waiting for.
Two lessons to read alongside this one. Start with Unity Catalog so you understand how Volumes fit next to tables. Then read Your AI is ready. Is your data foundation? for the wider story on why governed context matters more than model choice.

The third item is Lakebridge, in preview. Lakebridge is an assisted migration tool that helps translate legacy SQL from other warehouses into SQL that runs on Databricks.
Read that carefully. It is an assistant. Not autopilot.
A model can suggest a translation. A model can flag the parts it is unsure about. A model can save you a lot of typing. What a model cannot do is take responsibility for the answer at the end. That responsibility still belongs to the engineer reviewing the diff.
The interesting part of Lakebridge is not the translation. It is the fact that the assistant lives inside Databricks, next to the target tables and the target compute. When you accept a converted query, it does not land in a text file on your laptop. It lands in the environment where you can actually run it, compare it against the old system, and check the row counts.
If you are staring at a migration backlog right now, the honest move is not to translate everything. It is to translate the top ten most-used queries, test them carefully, and use those to build confidence in the tool. Then translate more.
The update that will make the most engineers smile is quieter than the others.
Lakeflow Declarative Pipelines now supports Python unit tests directly inside the Lakeflow Editor, in preview. Real pytest. Mock data. Assertions that fail the way tests should fail.
This is a small thing to describe and a large thing to live with.
For a long time, testing a pipeline meant one of two answers. Either you built a whole side project to structure your pipeline code as importable modules with real unit tests, which most teams never finished. Or you skipped it and tested by running the pipeline against a small dataset, hoping the results looked right.
Pytest inside the editor removes that gap. You can write a small function, mock its input, assert its output, and know that the transformation behaves the way you say it does. That single change turns a pipeline into something closer to real software.
Two lessons pair well with this update. Jobs & Pipelines shows how pipelines are shaped in the first place. Data Quality shows the runtime checks that sit next to unit tests. You want both. Unit tests catch logic mistakes before they run. Data quality checks catch reality when it disagrees with your logic.
A few other things showed up this month. None of them are headline features. All of them are useful.
Data Quality Monitoring can now detect anomalies in percent-null metrics, in preview. In plain language, it watches how often a column is null and tells you when that number drifts. If your customer email column suddenly goes from two percent null to twenty percent null, you want to know before your marketing team notices.
AI/BI Dashboards now let you model relationships between tables directly inside the dashboard, in preview. This is a small quality-of-life win. You do not have to leave the dashboard to define how two tables join. The model lives with the dashboard, which means the next person to open it can actually see how the numbers are being produced.
SQL Warehouses can now automatically end queries that run past a configurable timeout, in preview. If you have ever come back from lunch to a query that has been silently running for two hours, you already know why this matters. Timeouts protect budget, and they protect the shared warehouse from one runaway query dragging every other user down.
Lakeflow Connect also picked up two new source connectors. We are not naming them here because the exact scope changes as previews mature. If you have been waiting for a specific system to show up as a first-class source, it is worth opening the Lakeflow Connect page and scanning the list again.
Zoom out for a second and the direction is easy to see.
Agents are being pulled into the governed platform, not left outside it. Their reach is being extended from tables to files. The tools around them are learning to test themselves like real software. The infrastructure around them is learning to protect itself with sensible defaults like timeouts and null-checks.
The role of the data engineer does not shrink in this world. It sharpens. The engineer is the person who decides which tables the agent is allowed to touch, which files sit in which Volume, which pipelines have tests, and which queries are safe to run without a timeout.
None of that is glamorous. All of it is exactly the work that makes the fancier features actually work in production.
If you want to turn this reading into practice, pick three small actions. Not ten. Three.
First, spend an hour with Agent mode against one governed dataset that you already understand. Ask it three questions you already know the answer to. See how it reasons. Note where it is confident and where it is not.
Second, add exactly one pytest to a pipeline you own. Pick the transformation you are least sure about and test it with a small mock input. Feel what it is like to have that safety net.
Third, list the top five legacy queries in your organization that need to move to Databricks SQL. Do not translate them yet. Just list them. Next week you can try Lakebridge on one of them.
Three small moves. That is enough for one week.
If this piece was useful, these three reads go well next to it.
Read them slowly. Then go make one dataset a little more reliable than it was yesterday. That is always the right next step.