Semantic Layer Evolves: Google Embeds Relationships into Agent Context

Historically, the Semantic Layer solved the problem of "how to calculate a metric and keep its definition consistent" across BI tools. In the emerging Agent era the question shifts to "why a metric changes and through which business relationships the change propagates".

Google’s response

On August 13, Google Cloud published Using BigQuery Graphs with Measures for Trusted Agentic Workloads , a detailed explanation of why governed Measures and a Graph are placed in the same analytical model. The article notes that this is not the first announcement – the April 22 BigQuery update at Google Cloud Next 26 already introduced native support for Graphs with Measures, positioning it as a "business map" for enterprise agents. The feature remains in Preview.

Why relationships matter

Google’s retail example illustrates the new requirement: a 12 % drop in Seattle winter‑jacket sales is easy to detect, but explaining the drop requires traversing multiple hops – from Seattle orders to distribution centers, from centers to suppliers, and from suppliers to regional storms. Without this relationship map, an agent might suggest a 15 % price cut, missing the underlying supply‑chain issue.

Google summarizes the analysis process in three layers: Metadata Grounding (identify available data), Business Metrics (use Measures to compute performance), and Relationship Mapping (use Graph to trace causality).

Graph + Measure mechanics

BigQuery Graph with Measures does more than combine graph queries with SQL aggregates. Because graph traversal can duplicate rows, ordinary SUM or AVG would over‑count. Measures are defined on node or edge properties (e.g., SUM, AVG, COUNT, COUNT DISTINCT, MIN, MAX) and are bound to a unique KEY. This binding guarantees that aggregation respects the key even when rows are repeated. Queries expand the graph with GRAPH_EXPAND and then invoke the pre‑defined measure via AGG. Google likens the division of labor to an agent needing a "calculator" (SQL/Measure) for numbers and a "map" (Graph) for paths.

The official documentation example shows how to count distinct users served by each distribution center. The graph finds the path User → Order → Product → Distribution Center, while a user_count measure defined on the User node prevents double‑counting of the same customer after expansion.

Zero‑ETL property‑graph mapping

Measures do not replace Graph, nor does Graph replace the Semantic Layer; they solve complementary problems. Without Measures, an agent can locate a relationship but may mis‑aggregate KPIs; without Graph, an agent can compute KPIs but cannot explain their business lineage. Google’s approach places both in a single governed model without requiring data migration to a separate graph database. Existing BigQuery tables are mapped in‑place to a Property Graph, a "zero ETL" capability that lowers the barrier for adopting relationship modeling.

Agent‑ready interfaces

Conversational Analytics can now use a Graph as a data source, leveraging Graph‑defined descriptions, synonyms, and Measures to improve answer quality. Agents can generate GQL for traversal or use GRAPH_EXPAND to access the graph via SQL. BigQuery Studio’s Visual Graph Modeler provides a UI for creating nodes, edges, and relationships without hand‑written DDL.

Integration with Looker

The April update also linked BigQuery Graph with Looker’s semantic model. One direction maps an existing Looker model to a BigQuery Graph, exposing Graph attributes and Measures as LookML. The reverse direction lets LookML define a Graph model, which Looker then materializes as Graph DDL in BigQuery. This ensures that core KPIs such as churn rate have a single definition across dashboards and agents.

Broader context: Knowledge Catalog

Google Cloud Knowledge Catalog, launched in April, is positioned as an enterprise "Context Engine" for agents. It aggregates Measures, LookML, data products, and metadata from various platforms, continuously enriching them to discover entities, relationships, business vocabularies, and validated query patterns. Unlike traditional data catalogs that focus on table schemas, Knowledge Catalog emphasizes business semantics and relationships to avoid hallucinations in agents.

Implications

The evolution of the Semantic Layer can be summarized as moving from Metrics + Dimensions + Joins to Metrics + Entities + Relationships + Business Context . Google is not merging Semantic Layer, Knowledge Graph, and Ontology into a single product, but it is extending the semantic infrastructure to absorb more business‑relationship information. For future agents, the data exposed will likely include not only tables and metric definitions but also a governed business model that tells the agent both "how to calculate" and "why the objects are connected". This structured business context is essential for agents to perform root‑cause analysis, cross‑domain decisions, and long‑chain executions.