Google Extends Semantic Layers with Graph Relationships for AI Agents

From "What Happened" to "Why It Happened"

Traditional semantic layers focused on unifying metric definitions across BI tools and analysts. In the agent era, the goal shifts: agents need to know not only metric values but also which business objects they relate to, how changes propagate along relationships, and where anomalies originate. Google Cloud's August 13 article Using BigQuery Graphs with measures for trusted agentic workloads details why governed Measures and Graph belong in the same analytical model. This capability was first announced at Google Cloud Next '24 (April 22) where BigQuery Graph gained native Measure support, positioned as a "business map" for enterprise agents; the August piece provides a deeper breakdown of Graph, Measures, and integration with Conversational Analytics and Looker. BigQuery Graph Measures remains in Preview.

Retail Example: Sales Drop Root Cause

Google illustrates with a retail scenario: Seattle winter jacket sales fall 12%. A flat-table query answers "what happened," but the "why" requires multi-hop relationships: which distribution centers serve Seattle orders, which suppliers those centers depend on, and whether a regional storm delayed those suppliers. Without the relationship graph, an agent might only see the sales drop and suggest a 15% discount promotion, failing to address the supply-chain issue and further eroding margin. Google frames the analysis in three layers: Metadata Grounding (what data exists), Business Metrics (Measures calculate performance), and Relationship Mapping (Graph traces causality).

Graph Finds Paths, Measures Guarantee Numbers

BigQuery Graph with Measures is not merely combining graph queries with SQL aggregation. Graph traversal expands nodes and edges; naive joins followed by SUM/AVG cause over-counting due to duplicated rows. BigQuery defines MEASURE directly on node or edge properties in Property Graph DDL, supporting SUM, AVG, COUNT, COUNT DISTINCT, MIN, and MAX. Aggregation binds to the node/edge KEY, so even after graph expansion duplicates appear, the measure computes on unique keys. Queries use GRAPH_EXPAND to unfold the graph into a table, then invoke the predefined Measure via AGG. Google's analogy: agents need to know when to use a "calculator" (SQL/Measure for accurate numbers) and when to use a "map" (Graph for relationship paths).

The official example: to answer "which distribution centers serve the most distinct customers," Graph traverses User–Order–Product–Distribution Center paths, while a user_count Measure on the User node prevents duplicate counting after expansion. Thus relationship traversal and business aggregation complete in one governed pipeline, without requiring the model to guess which duplicate rows to deduplicate.

This distinction is critical for Data Agents. Graph alone is not a semantic layer; Measures do not replace Graph. Without Measures, agents traverse relationships but may miscalculate KPIs after complex expansions. Without Graph, agents produce accurate KPIs but cannot explain the business lineage behind them. Google places both "computable business definitions" and "traversable business relationships" in a single governed data model, without requiring migration to a separate graph database. Existing BigQuery tables map in-place to Property Graphs, termed "zero ETL," lowering adoption barriers.

Semantic Layer Boundary Extends from Metrics to Business Structure

These capabilities now enter the agent interaction layer. BigQuery documentation shows Conversational Analytics can use Graph as a data source, leveraging Graph-defined descriptions, synonyms, and Measures to improve answer quality; explicit graph relationships reduce agent guesswork on join paths. Supported versions allow agents to generate GQL for traversal or use GRAPH_EXPAND for SQL access. BigQuery Studio provides a Visual Graph Modeler for point-and-click node, edge, and relationship creation, making Graph a callable business map for natural-language agents.

Google also integrates BigQuery Graph with Looker's semantic model bidirectionally: Looker can point to an existing BigQuery Graph, mapping its properties and Measures to LookML; or LookML can define a Graph model that Looker generates and maintains as BigQuery Graph DDL. Models remain manageable in Looker IDE, Git, and CI pipelines. The goal: core KPIs like Churn Rate must not have divergent definitions across dashboards and agents. Where semantic layers once unified metrics, dimensions, and joins, Graph now adds entities, relationships, and multi-hop paths, moving semantic models closer to business structure descriptions.

Google's Real Bet: The Agent Business Context Layer

Zooming out, this is not an isolated BigQuery change. The April-launched Google Cloud Knowledge Catalog targets an enterprise Context Engine for agents: it aggregates BigQuery Measures, LookML, data products, and cross-platform metadata, continuously enriching to discover entities, relationships, business vocabulary, and validated query patterns. Google notes traditional data catalogs focus on table schemas, while agents hallucinate without Business Semantics and Data Relationships. Knowledge Catalog combines Aggregation, Enrichment, and Search to unify semantics and generate/retrieve business relationships and context.

Connecting these moves reveals a clearer evolution: the semantic layer for agents approximates Metrics + Entities + Relationships + Business Context, versus the traditional Metrics + Dimensions + Joins. Google has not merged Semantic Layer, Knowledge Graph, and Ontology into one product, nor does it imply traditional semantic layers will be replaced by Graph. Rather, agent-oriented semantic infrastructure is absorbing more "business relationships" and "business context," with the Metrics Layer as one component.

This changes how enterprises expose data to agents. A reliable future Data Agent may receive not just dozens of tables, schema descriptions, and a metric catalog, but a governed business model containing metrics, entities, calculation rules, and relationships—telling the agent both "how to calculate" and "why these objects connect." As agents progress from point questions to root-cause analysis, cross-domain decisions, and long-horizon execution, such structured business context becomes essential.

Therefore, BigQuery Graph with Measures matters not because Google added another graph query capability, but because it exposes the next semantic-layer requirement: agents must not only compute correct numbers but also navigate a governable, queryable, reusable "business relationship network." We once wanted agents to understand tables, then to calculate correct metrics; next, they must understand how the company actually operates.

References: Google official sources — August 13 BigQuery Graph with Measures article; April 22 BigQuery Agentic Era update.