Agents are getting their own data layer: branches, governed metadata, AI-native storage

Every pull request gets its own production-data branch

The most concrete version of the agent-era data layer comes from Hamlet, which indexes meetings from more than 7,200 governing bodies across every state. Hamlet runs on Databricks' Lakebase Postgres and gives every pull request its own branch of production data. The branches are copy-on-write, so there is no full duplication — each branch is an independent Postgres environment that starts with the parent's schema and data and shares storage with it. Branch compute scales to zero when idle, so customers pay only for active compute hours. m:…3969

The payoff is for agents: Hamlet hands AI coding agents like Claude and Codex access to the branch and lets them run their own checks against real production-shaped data before a human approves the merge. Before Lakebase, the company's staging setup on AWS RDS took 15 to 30 minutes per pull request just to get into a testable state — Hamlet's own account in Databricks's first-party case study, but directionally the toil that branching eliminates. m:…3969

Snowflake governs the metadata agents browse

Snowflake's answer is Horizon Context, a governed context layer inside Horizon Catalog that collects metadata, enriches it with business meaning, and makes it useful to people, BI tools, and AI agents. Metadata connectors for 18 sources are in public preview — spanning Power BI, Tableau, Looker, Sigma, Hex, dbt, SQL Server, Oracle, PostgreSQL, Databricks, and BigQuery — and the connectors collect metadata without requiring the underlying datasets to be replicated into Snowflake. m:…9109

The governance detail matters for agents: metadata visibility separates browsing the catalog from accessing the underlying data, so an agent can discover what exists without being able to read it. Stewards get a targeted APPLY COMMENT privilege to curate descriptions without broader modify or ownership rights, and column descriptions propagate along lineage to downstream columns — stopping where values are transformed, combined, or aggregated. m:…9109

Glean and DeepL: agents at the warehouse, storage under it

Glean's new "Glean for Data Analysis" pushes the same idea into everyday workflows: natural-language data insights for every employee, with its Enterprise Graph pairing governed, structured warehouse data with the unstructured context found in documents, conversations, and tickets. The data-analytics context is exposed to agentic clients over MCP, and partnerships with Snowflake and Databricks carry Glean's permission-aware context into the data and AI applications employees already use. m:…5372

Underneath it all, the storage layer is being reworked for AI density. DeepL is deploying the VAST AI Operating System as the data foundation for its AI research and development environments, and expects to get roughly three times the storage capacity out of its existing hardware — an expectation, not a measured result — with a migration from its current environment via VAST's SyncEngine. m:…6641

The loop closes when the work comes back

Writer's blog on always-on agents supplies the framing for why this matters: most of the enterprise AI conversation is about getting data into the model, but Writer argues that compounding results over time also depend on getting the work back into the data warehouse. Its agents already write briefs and assets back into Snowflake as governed rows with IDs and owners, stored next to the outcomes they produce. m:…3173

That loop only compounds if the agents never really stop: Writer describes always-on agents that monitor data for changes and act proactively without manual requests, writing results back into Snowflake to optimize the workflow on the next run. Each iteration's work lands as data the next iteration can read — memory, of a sort, at the warehouse level. m:…3173