Google Fellow argues enterprise AI is bottlenecked by data, not intelligence

1. One table, two views — ▶ 2:55

   Spanner Graph lets a single set of tables be queried as a graph or as ordinary tables. The design came from customer discovery roughly 5 years ago: many people who wanted a graph database had none yet, and much of their data already sat in a relational database. Customers also feared having to teach the whole company graph. Chris says the approach adds scale and brings in adjacent datasets, and nobody needs a graph query just to browse a customers table. He calls the later relevance to AI partly luck, since the work predated ChatGPT.

2. Assume the impossible — ▶ 8:03

   Chris says adoption has outpaced his expectations. Two years ago customers intended to use GenAI but had done none. A year later many had organized data and built chatbots. This past year more customers, though perhaps not most, had put something in production that makes money or changes how the business runs. He expects far more at Next '27. A colleague's heuristic: assume AI can do impossible things and lower expectations until you reach what it can do. Chris says that point is often higher than you would guess.

3. The enterprise data gap — ▶ 10:28

   Models are far better at public information than at enterprise information. Ask about the code in Postgres and the answer is strong because that material is in the training data. A company's private information is hidden, so the model must discover it or engineers must supply it. Chris argues that without closing this gap, increases in intelligence are hard to benefit from. He offers it as one reason excitement over model releases has cooled, and as the bridge enterprises still need to cross.

4. Saturated tasks change economics — ▶ 11:43

   The intelligence needed for many enterprise jobs is no longer frontier-level, Chris says. A relatively inexpensive model can match the top model on problems that are already solved well enough. His example, which he recalls seeing on X, is searching piles of PDFs: a couple of dollars per document before, pennies now. Work that was uneconomical becomes viable at scale. He compares this to Larry Page's push for search results that update with every keystroke, delivered at about 10 searches for the price of one, and suggests AI is having a similar moment.

5. Graph as prepared binder — ▶ 15:39

   Traditional RAG is like dropping a binder of notes on someone's desk. Graph RAG has AI pre-read the information, extract the connections and model them, so the next AI answering under time pressure does not have to reconstruct them on the fly. The first step can be modest: make explicit the relationships you already know exist in relational data, such as customers, accounts and transfers. The advanced form extracts structure from unstructured data. Chris concedes the cost: there are agents on both sides to program.

6. Hill-climb the evaluation — ▶ 18:18

   Practitioners who stall over ontology and graph correctness should first define how to evaluate the end-to-end system, Chris says. Build a library of questions whose good answers are known, then test each change, such as letting an AI add entities and edges, and keep what improves results. Much of the ambiguity goes away once you hill-climb the evaluation. He compares this to Google's search quality work, where teams may have 20 ideas, maybe only one good, and speed comes from testing all 20 and picking the winner.

7. Two-hop graph expansion — ▶ 20:30

   Graphs improve agent context in a simple pattern: find an entry point with vector or text search, expand two hops in the graph, and feed the result to the agent. Facts like a person's spouse, children and boards are one hop away in a knowledge graph. Chris says the agent then knows more things that are true, which he calls more true than it guessing. A customer asked which boards someone sits on. The graph could answer, while a vector database often cannot unless a document spells it out. He calls the techniques complementary.

Chris's central claim is that enterprise AI has shifted from a model problem to a data problem. Models are far better at public information than at enterprise information, he argues. Ask one about the code in Postgres and it performs well because that material sits in its training data. A company's private information is hidden, and either the model must discover it or engineers must supply it. Hence his line that the "most intelligent robot in the world doesn't know what you didn't tell it." Without closing that gap, he says, increases in intelligence are hard to benefit from. The claim also offers an explanation for why excitement over each model release has cooled, which the interviewer attributed to plateauing benchmarks.

A second force reduces the pull of the frontier: saturation. Chris observes that the intelligence needed for useful enterprise jobs is not necessarily frontier-level, as it was a year ago. A relatively inexpensive model can often match the top model on problems already solved well enough. His example, which he recalls seeing on X rather than measuring himself, is combing through a pile of PDFs. That once cost a couple of dollars per document and now costs pennies. The consequence is economic. Work that was uneconomical becomes viable at scale. He compares this to Larry Page's insistence that search results change with every keystroke, which Google delivered at about 10 searches for the price of one. The analogy is suggestive, not evidence.

The evidence for adoption is Chris's own customer conversations, and he is candid about their reach. Two years ago, customers intended to use GenAI but had done none. A year later they had organized data and built chatbots. This past year more customers, though "maybe not even most," had something in production that earns money or changes how the business executes. He expects far more at Next '27. A colleague's heuristic frames his optimism: assume AI can do impossible things, then lower expectations until you reach what it can do. That point, Chris says, is often higher than you would guess. Because he works at a cloud vendor and offers no aggregate figures, this is a credible vantage point but not a measurement.

Graphs are his proposed bridge across the data gap. The core value of a graph database is that it explicitly represents connections. In a relational schema, customers, accounts and transfers sit in separate tables, and their relatedness is neither declared nor very visible. In a graph, the edges are plainly visible and an agent can follow them. The first step is modest: take the relationships you already understand and make them explicit. Spanner's design reflects that pragmatism. Customer discovery showed that most data was already relational and that companies feared retraining everyone on graph, so Google built one set of tables usable as a table or a graph. Chris says the timing, with work starting before ChatGPT, was partly luck.

The more ambitious version moves effort from query time to preparation time. Chris likens traditional RAG to dropping a binder of notes on someone's desk. Graph RAG has AI organize the binder first, extracting and modeling connections so the next AI, answering under time pressure, does not reconstruct them. At retrieval, the pattern is to find an entry point with a classic technique, expand two hops, and hand the agent facts that exist in the knowledge graph. A customer's question about which boards a person sits on is his example. A graph can answer it, while a vector database often cannot unless a document states it. He calls the two techniques complementary, and concedes the cost: agents on both sides must be programmed.

The strongest objection comes from the interviewer, who says practitioners stall because they lack a clear ontology, enough metadata, or a way to verify that the graph is right. Chris's answer is to turn the ambiguity into a measurement problem. Build a library of questions with known good answers, change the graph, and keep the changes that improve results. He draws on Google's search quality work, where the discipline is testing all 20 ideas because perhaps only one is any good. The weakness is that hill-climbing optimizes only what the library measures. The approach also presumes a team can already say what a good answer looks like, which is the very uncertainty that stalled it.

If Chris is right, competitive advantage in enterprise AI shifts toward organizations that can structure and evaluate their own data, and away from those chasing the newest model. That is an editorial inference, not a claim he makes outright. It also rests on an assumption he himself qualifies: that cheaper models keep matching the frontier on the tasks enterprises care about. He concedes that where AI goes is hard to predict. If a future model capability opens tasks that today's saturated problems do not touch, the data gap would matter again in a different form. The open issue is whether prepared, well-evaluated data compounds into a lasting advantage or simply raises the price of entry.