Google's Graph + Measures: Semantic Layer Adds Business Relationships for Agents

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. The 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 the architecture and its integration with Conversational Analytics and Looker. BigQuery Graph Measures remains in Preview.

From "What Happened" to "Why It Happened"

Traditional semantic layers focused on unifying metric definitions — ensuring Revenue, Churn Rate, and Active User compute identically across BI tools and applications. For agents, this remains critical because raw schema access leads to wrong SQL, incorrect joins, and inconsistent calculations. However, when questions shift from "What is sales?" to "Why did sales drop?", metric definitions alone are insufficient.

Google illustrates with a retail example: Seattle winter jacket sales fall 12%. A flat-table query answers "what happened" easily. The harder question — "why?" — requires traversing a multi-hop relationship: Seattle orders → distribution centers → suppliers → regional storm delays. Without this relationship network, an agent might only see the sales dip and recommend a 15% discount, failing to address the supply-chain root cause and further eroding margin. Google frames the analysis in three layers:

Metadata Grounding — determine what data exists.

Business Metrics — use Measures to compute performance.

Relationship Mapping — use Graph to trace causality.

Joins express how tables connect but not the business meaning between entities. Graph explicitly models Customer, Order, Product, Distribution Center, Supplier and their relationships, turning paths the model would otherwise guess into governed, reusable, verifiable business structures.

Graph Finds Paths, Measures Guarantee Numbers

BigQuery Graph with Measures is not merely bolting graph queries onto SQL aggregation. Graph traversal expands nodes and edges; if standard joins are followed by SUM/AVG, duplicate rows from expansion cause overcounting. BigQuery's solution: define MEASURE directly on node or edge properties in the Property Graph DDL. Supported aggregations: SUM, AVG, COUNT, COUNT DISTINCT, MIN, MAX. The measure's aggregation binds to the node/edge KEY, so even when graph expansion produces duplicate rows, aggregation still computes on unique keys. At query time, GRAPH_EXPAND unfolds the graph into a table, and AGG invokes the pre-defined Measure.

Google's analogy: agents need to know when to use a "calculator" (SQL/Measure for correct 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 finds the path User → Order → Product → Distribution Center, while a user_count Measure defined on the User node prevents the same customer from being double-counted after expansion. Relationship traversal and business aggregation thus complete in a single analytical chain without requiring the model to deduce which duplicate rows to eliminate.

This distinction matters for Data Agents. Without Measures, agents can traverse business chains but may miscalculate KPIs after complex expansions. Without Graph, agents can produce accurate KPIs but cannot explain the business lineage behind them. Google places "computable business definitions" and "traversable business relationships" in one governed data model — without mandating migration to a separate graph database. Existing BigQuery tables map in-place to Property Graphs, a capability Google calls zero ETL , lowering the barrier to introducing relationship modeling into existing warehouses.

Semantic Layer Boundary Expands from Metrics to Business Structure

These capabilities now enter the agent interaction layer. Conversational Analytics can use Graph directly 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's Visual Graph Modeler lets users create nodes, edges, and relationships visually rather than writing DDL by hand — Graph becomes a callable business map for natural-language analytic agents.

Simultaneously, Google connects BigQuery Graph with Looker's semantic model (announced April). Integration works bidirectionally: Looker can point to an existing BigQuery Graph, mapping its properties and Measures into LookML; or LookML can define a Graph model that Looker then generates and maintains as BigQuery Graph DDL. Models remain manageable through Looker IDE, Git, and CI pipelines. The goal is explicit: core KPIs like Churn Rate must not have two different definitions in dashboards and agents. Where the semantic layer once unified "metrics, dimensions, joins", Graph now adds "entities, relationships, multi-hop paths", moving the semantic model closer to describing business structure rather than just data structure.

Google's Real Bet: The Agent Business Context Layer

Zooming out, this is not an isolated BigQuery change. Google Cloud Knowledge Catalog (April) targets an enterprise Context Engine for agents: it aggregates BigQuery Measures, LookML, data products, and cross-platform metadata, then continuously enriches 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 — unifying semantics and definitions on one side, generating and retrieving business relationships and context on the other.

Connecting these moves reveals a clearer evolution. The legacy semantic layer simplified to Metrics + Dimensions + Joins. For agents, it becomes Metrics + Entities + Relationships + Business Context. Boundaries matter: Google has not declared Semantic Layer, Knowledge Graph, and Ontology merged into one product, nor that traditional semantic layers will be replaced by Graph. The accurate framing: agent-oriented semantic infrastructure is absorbing more "business relationships" and "business context", with the Metrics Layer as one component.

This shifts 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 both metrics and entities, both calculation rules and relationships — telling the agent not only "how to calculate" but "why these objects connect". As agents move from point questions to root-cause analysis, cross-domain decisions, and long-chain execution, this structured business context grows essential.

Thus, BigQuery Graph with Measures matters not because Google added another graph query flavor, but because it surfaces the semantic layer's next requirement: letting agents calculate correctly is just the starting point; to operate inside real business, they also need a governable, queryable, reusable "business relationship network." We once wanted agents to understand tables, then to compute metrics correctly; next, they must understand how the company actually operates.

Sources verified against Google official publications: August 13 BigQuery Graph with Measures deep-dive article April 22 BigQuery Agentic Era update