What Happened
Google’s recent enterprise AI data stack updates point to a clearer pattern for production agentic analytics: LLMs should not reason directly over disconnected tables, ambiguous metrics, and ad hoc natural language-to-SQL generation. They need governed semantic context, relationship-aware data models, and identity-preserving access controls.
BigQuery Graph introduces a way to map existing BigQuery tables into an in-place property graph, without moving data through a separate ETL pipeline. The goal is to let AI agents reason across multi-hop business relationships such as orders, distribution centers, suppliers, products, regions, and operational dependencies, instead of treating each table as a flat isolated object [1].
The important technical addition is support for Measures in graph definitions. Data modelers can declare governed metrics directly in Property Graph DDL, then use graph traversal with GRAPH_EXPAND and the AGG aggregator so traversal paths are resolved before aggregation. This reduces common SQL errors caused by duplicated rows, incorrect joins, and metric inflation when querying complex relationship networks [1].
In parallel, Looker’s semantic layer is being integrated into Gemini Enterprise through the Agent-to-Agent protocol. Analysts can publish Looker agents into Gemini Enterprise, allowing business users to query structured systems such as BigQuery, AlloyDB, and Spanner, as well as unstructured documents, from a single chat interface [2].
The Looker integration is designed around deterministic, version-controlled SQL and codified business logic. Instead of allowing an LLM to invent definitions for terms such as “revenue,” “active customer,” or “gross margin,” the agent uses the governed Looker model. Gemini Enterprise also uses a pass-through security model: it does not ingest or store the underlying records, and user sessions are bound through OAuth to Looker credentials, preserving row-level controls, column-level controls, masking, and security isolation [2].
Why It Matters to Businesses
Many enterprise AI analytics pilots fail for the same reason: the model can produce a fluent answer, but the answer is not reliably grounded in the company’s actual metric definitions, data permissions, or operational relationships.
Flat-table retrieval and naive NL2SQL are particularly risky for operational decisions. A question such as “Why did Seattle orders decline?” may require traversing from orders to fulfillment centers, inventory availability, supplier lead times, product categories, promotions, weather disruptions, and customer segments. If an agent only sees order rows, it may produce a plausible but shallow explanation. BigQuery Graph addresses this by exposing business relationships as first-class queryable structure [1].
For executives and technology leaders, the practical implications are significant:
- Better root-cause analysis: Agents can reason across entities and dependencies instead of summarizing isolated tables.
- More consistent KPIs: Governed measures and semantic models reduce the risk that different users receive different definitions of the same business metric [1][2].
- Lower hallucination risk: Deterministic SQL and codified business logic reduce the amount of reasoning the LLM must invent [2].
- Stronger access control: Identity-centric pass-through security keeps permissions enforced at the semantic and data layers rather than relying on prompt instructions [2].
- Improved operational adoption: Native visualizations and chat-based access make analytics more usable, while version control and CI workflows make models manageable by engineering teams [1][2].
The strategic shift is from “LLM as analyst” to “LLM as interface and orchestrator over governed analytical systems.” That is the architecture pattern most likely to survive production requirements.
Kimbodo Engineering Perspective
From an implementation standpoint, the central lesson is that enterprise AI agents need a governed data operating model before they need more model capability. Bigger models can improve language understanding, but they do not automatically solve metric ambiguity, join correctness, access control, data lineage, or operational auditability.
Graphs help when relationships drive the answer
A graph model is valuable when business questions depend on multi-hop relationships: supply chain exposure, fraud rings, customer-product affinity, infrastructure dependencies, account hierarchies, or service incident blast radius. In these cases, encoding relationships directly can produce better analytical behavior than repeatedly asking an LLM to infer joins from table names and column descriptions.
However, graph modeling is not free. Teams must define nodes, edges, relationship semantics, ownership, and validation rules. For simple dashboard-style questions over well-modeled dimensional data, a semantic layer alone may be sufficient. The decision should be based on query patterns, not platform novelty.
The semantic layer remains the control plane for business meaning
Looker-style semantic modeling is still essential because graphs describe relationships, while semantic models define business meaning. A production analytics agent needs both: relationship context for traversal and governed measures for calculation. Without governed metrics, graph traversal can make wrong answers more elaborate rather than more correct.
Version-controlled SQL and reviewed business logic also create an engineering workflow. Changes to definitions can be tested, peer-reviewed, rolled back, and traced. That matters when AI-generated answers influence pricing, inventory, sales operations, finance, or compliance-sensitive reporting.
Agent orchestration should be constrained, not open-ended
The Agent-to-Agent pattern is useful because it allows specialized agents to expose capabilities to a broader enterprise assistant [2]. But multi-agent orchestration should be bounded by explicit contracts: what data each agent can access, what tools it can call, what outputs it can produce, and how confidence or uncertainty is represented.
In production, we would avoid giving a general-purpose LLM unrestricted database access. The safer architecture is to expose curated tools: governed semantic queries, approved graph traversals, document retrieval with citations, visualization generation, and workflow actions with human approval gates.
How We Would Implement It
1. Start with decision use cases, not infrastructure
We would first identify the business decisions the AI system must support: revenue analysis, supplier risk, customer churn, incident diagnosis, inventory allocation, financial variance analysis, or sales forecasting. Each use case should define approved data sources, required KPIs, latency expectations, access rules, and acceptable action boundaries.
2. Build a governed semantic layer for core metrics
The first technical foundation should be a governed metric layer. Definitions such as revenue, margin, conversion, customer count, backlog, on-time delivery, and churn should be codified in version-controlled models. These models should include ownership, tests, documentation, and review workflows.
For organizations using Looker, that means treating LookML as production code: pull requests, CI validation, environment promotion, and regression tests for metric changes. The benefit is that agents call approved analytical logic instead of generating inconsistent SQL from scratch [2].
3. Add a graph layer where multi-hop reasoning is required
For relationship-heavy use cases, we would model key entities as graph nodes and edges: customers, accounts, orders, products, facilities, suppliers, employees, devices, tickets, contracts, or applications. BigQuery Graph is compelling when the data already lives in BigQuery because it can map existing tables in place and avoid duplicative graph ETL [1].
Measures should be defined where aggregation correctness matters. Using graph-aware traversal and aggregation helps prevent duplicated counts or inflated metrics when queries move across many-to-many relationships [1]. We would also create test cases for known scenarios: supplier outage impact, regional demand drop, duplicate path handling, and metric consistency versus existing dashboards.
4. Expose analytics through constrained agent tools
The LLM should not directly write arbitrary SQL against production datasets. Instead, we would expose a small set of controlled tools:
- Semantic query tool: Executes governed measures and dimensions through the semantic layer.
- Graph reasoning tool: Runs approved graph traversals for dependency and root-cause analysis.
- Document retrieval tool: Retrieves policy, contract, support, or operational documents with citations.
- Visualization tool: Generates charts from approved query outputs, not from unverified model-created datasets.
- Workflow tool: Creates tickets, drafts recommendations, or triggers downstream actions only within defined permission scopes.
5. Preserve identity end to end
Enterprise AI applications should propagate the user’s identity into every data access path. The Looker-Gemini Enterprise model is directionally correct: OAuth binds the session to the user’s Looker credentials, and existing row-level, column-level, masking, and isolation policies remain in force [2].
We would extend the same principle across the broader AI system: no shared superuser database credentials, no prompt-based access control, and no copying sensitive source records into unmanaged vector stores. Every query, retrieval, and tool call should be attributable to a user, service account, policy, and request context.
6. Add evaluation, observability, and rollback
Production analytics agents need continuous evaluation. We would maintain a test suite of business questions with expected SQL patterns, expected metric values, allowed data sources, and required citations. We would log tool calls, query plans, model prompts, retrieved context, generated answers, user feedback, and policy decisions.
Dashboards should track answer acceptance, query failure rates, latency, token usage, warehouse cost, graph traversal cost, permission denials, and hallucination reports. When a semantic model or graph definition changes, regression tests should run before promotion.
Risks, Costs and Security
Cost trade-offs
Governed AI analytics can reduce analyst workload, but it may increase cloud consumption if not controlled. Graph traversal, conversational analytics, visualization generation, and repeated LLM calls can drive costs beyond traditional dashboard usage.
We would manage this with query budgets, caching for common questions, warehouse reservations or workload isolation, result reuse, maximum traversal depth, token limits, and separate environments for development, testing, and production. Not every user question should trigger a fresh high-cost graph traversal or large model call.
Security risks
The primary risks are unauthorized data exposure, prompt injection, indirect data leakage through summaries, and over-permissive agent tools. Pass-through identity and semantic-layer controls reduce these risks, but they do not eliminate them [2].
Controls should include least-privilege service accounts, user-level authorization checks, tool allowlists, row and column policy enforcement, masking, audit logs, sensitive data detection, and response filters for regulated fields. For document retrieval, the system must enforce document-level permissions before retrieval, not after generation.
Reliability risks
Even with governed metrics, agents can still misinterpret intent, choose the wrong tool, overstate causality, or produce recommendations without sufficient evidence. Graph models can also encode incorrect relationships or become stale as business systems change.
Mitigations include confidence scoring, citation requirements, deterministic query execution for metrics, human review for consequential actions, automated data quality checks, graph validation tests, and clear answer boundaries such as “observed correlation” versus “confirmed cause.”
Organizational costs
The biggest cost is often not software licensing or compute. It is the governance work: agreeing on metric definitions, assigning data ownership, cleaning source systems, documenting lineage, and maintaining model changes through an engineering workflow.
That cost is unavoidable for serious enterprise AI. The alternative is a conversational interface over ambiguous data, which may be cheaper to demo but more expensive to operate when users lose trust or decisions are made from inconsistent answers.
The practical conclusion for business and technology leaders is clear: production AI analytics should be built around governed semantics, relationship-aware data models, identity-preserving access, and constrained agent orchestration. LLMs add value as interfaces and reasoning coordinators, but the reliability comes from the architecture around them.
Where Kimbodo Comes In
Kimbodo builds and operates this in production for businesses — see our AI Infrastructure & MLOps practice. Wondering what it would cost for your organization? Get a preliminary range, timeline and architecture in about a minute.
