Google Cloud makes LookML semantic indexing generally available

Google Cloud has made LookML semantic indexing in Knowledge Catalog generally available for Looker Core on Google Cloud, a release dated 11 November 2026 and aimed squarely at enterprises running AI agents against business data. The feature brings LookML business logic into Knowledge Catalog by default, letting organisations expose data catalog metadata and metric definitions to Gemini Enterprise and custom AI agents from a single environment.

The release targets a problem that has become routine as companies move AI agents from experiments into production. Data teams can often show an agent where data sits, how it is tagged and how it moves across systems. That information does not tell the agent how revenue, churn or any other business measure should actually be calculated. Google's answer is to index the semantic layer itself, not just the surrounding metadata.

What does the release actually change?

LookML is Looker's modelling language for defining joins, filters and metric formulas. Knowledge Catalog aggregates metadata across structured data and documents, including lineage, governance rules and privacy tags. Until now, those two assets lived in separate worlds: the catalog described the data estate, while the semantic layer held the calculation logic.

Under the new arrangement, resolved LookML models, Explores, Views, lineage and dashboards are indexed directly into Knowledge Catalog. Synchronisation is enabled by default, and updates to production LookML are reflected in Knowledge Catalog in near real time. There is no separate pipeline to build or maintain; the indexing follows the models as they change.

The practical effect is that an AI agent can retrieve not only table descriptions or glossary terms but also a metric's underlying definition, its join path and its source lineage in one place. Google argued that this reduces the risk of AI systems generating inconsistent formulas or inflated totals through incorrect joins across one-to-many relationships — a failure mode familiar to anyone who has watched a text-to-SQL system double-count revenue.

Why the semantic layer matters for agents

Google set out a clear distinction between broad enterprise context and deterministic business semantics. In its framing, data catalogues can show what data exists and what governance applies, but they do not by themselves define how a business should calculate figures in SQL.

That gap matters when large language model agents write queries directly against warehouse tables. Without explicit semantic rules, such systems may assume the wrong fiscal calendar, include transactions that should be excluded, or expose restricted data fields if they rely only on raw schemas and general descriptions. The semantic layer converts those assumptions into checked definitions.

The indexing covers several layers of Looker metadata, and the depth of coverage is the substance of the release:

• Model level: Knowledge Catalog captures descriptive metadata, connection routing, include hierarchies and validation tests.
• Explore level: it records join logic, relationship cardinality, required joins and mandatory filters.
• View level: it extracts compiled SQL expressions, primary keys, timeframes, synonyms and derived table logic.
• Dashboards, Looks and tiles: these are catalogued too, including filters, chart types, ownership and usage statistics, allowing users to trace lineage from BigQuery tables to individual dashboard tiles.

That last point deserves emphasis. Lineage that previously required manual tracing across tools now runs from the raw table to the tile a executive sees on a dashboard, with ownership and usage statistics attached.

How does this change agent workflows?

Google contrasted three approaches to enterprise data agents. The first is a database agent with no semantic or catalog context, which writes SQL directly against warehouse tables and infers everything at runtime. The second uses Knowledge Catalog for metadata and governance but still relies on the model to infer metric logic. The third combines Knowledge Catalog with LookML indexing, allowing the agent to use both governance information and pre-defined SQL relationships.

In Google's description, the third model gives Gemini Enterprise and similar systems a two-step process. The agent first searches Knowledge Catalog for governance information and the relevant LookML objects. It then generates SQL grounded in those indexed definitions rather than inferring calculations at runtime. The calculation is retrieved, not improvised.

Google also drew a boundary between this setup and Looker Conversational Analytics. It described Conversational Analytics as a BI assistant for users working within curated Looker Explores. Knowledge Catalog combined with Looker is positioned differently: for broader enterprise agent use across BigQuery and other data sources, alongside unstructured documents. One product serves the analyst in a governed BI surface; the other serves agents roaming a wider data estate.

What about access control?

The release applies to Looker Core on Google Cloud and integrates with Gemini Enterprise through Knowledge Catalog. Users can attach a BigQuery, Spanner, Cloud SQL or AlloyDB data store in federated query mode, after which Knowledge Catalog support is enabled automatically.

Access controls remain tied to end-user credentials. Users can discover and query only the data assets they already have permission to view, and the assistant uses those same permissions when looking up indexed LookML definitions, join logic and starter queries in Knowledge Catalog. Governance travels with the lookup, not as an afterthought applied to the output.

Why it matters

The stakes are straightforward. Enterprise AI adoption has shifted from chatbot pilots to agents that must produce numbers a finance team can defend, and the semantic layer is where those numbers are defined. Vendors that own both the catalog and the metrics engine can close a gap that point solutions have struggled to bridge — and Google now indexes the two together by default for every Looker Core customer on its cloud.

Google said the result is that agents can move from raw SQL guesswork to using governed business definitions and catalog context from the same system. For organisations weighing agent deployments against data-governance risk, the default-on synchronisation turns that claim into an operational baseline rather than an integration project.