Cloud Next 2026 Field Notes: Why Your Agent Needs a Context Graph

Post 5 of 5 from my Cloud Next 2026 field notes. This is the talk I came back from most genuinely useful — not because anything in it was new, but because the speakers ran a clean live experiment that showed something a lot of teams suspect but rarely demonstrate. I want to keep the framing humble, because the principle they articulated is one many practitioners have arrived at independently. The value was in watching the same question get a wrong answer and then a right answer, with only the context layer changing.

The session was given by an enterprise data-platform team presenting their work with Google. I will not name them — they did not formally introduce themselves on stage, and I do not want to invent affiliations. There was also a Google partner-engineering representative on the panel. The work below is theirs. The reading is mine.

The Demo Setup

They wired an agent up to two data products: an NPS data product and a customer lifetime value data product. Roughly fifteen tables in total, the kind of fan-out that exists in any real enterprise warehouse. Then they asked the agent a single hard business question:

If customer satisfaction goes up by one point, what is the net revenue gain?

That is not a “select sum from table” question. It crosses two data products. It requires the agent to understand that customer satisfaction means NPS in the satisfaction product, that revenue means lifetime value in the CLV product, that the two are joined at the customer level, and that “net” implies a delta against a baseline. It is the kind of question a good analyst would think about for ten minutes before writing SQL.

The First Pass: Metadata Only

In the first run the agent had access to only the standard table metadata you get out of the box from BigQuery — column names, data types, row counts, a description string. The agent did what these systems do when they are confident and wrong. It picked the parent table of the NPS product, found a column it could correlate with something it interpreted as revenue, did the arithmetic, and returned a number.

The number was wrong. More importantly, the agent never reached the CLV tables at all. It got stuck at the parent table of the satisfaction product, treated that as the whole world, and answered with conviction. This is the failure mode I keep watching teams hit. Not “the model can’t reason” — the model reasons. The reasoning was just over an incomplete map of the territory.

The Second Pass: Three Signals

Then they added three things to the agent’s context:

A business glossary. What does “customer satisfaction” mean in this organization? It means NPS, measured monthly, on the customer entity. What does “revenue gain” mean? It means delta CLV, measured against a baseline period. The glossary is short. It is plain language. It does not live in a graph database. It lives in a document.
AI-generated metadata layered on top of the table schema. Not just “this column is INT64.” Closer to: this column represents the customer’s NPS score for the most recent measurement period; nulls indicate non-respondents and should be excluded from gain calculations. This is metadata that knows what the data is for, not just what it is.
Lineage joins across data products. The technical lineage of how data flowed from raw events into the NPS product and the CLV product, plus the cross-product joins that connected them at the customer entity. This came directly out of BigQuery and dataform — the engine already knew the lineage; the agent just had not been given access to it.

Same agent. Same question. Different answer. Correct, with traceable navigation across both products.

The Formula

The presenter put a formula on stage that I copied into my notebook because it is the cleanest version of this idea I have seen written out:

Agent answer quality = f(metadata + navigation)

Metadata is the source of truth for entities — what the columns are, what they mean, what their boundaries are. Navigation is how you get from a question in business language to the right entities across data products. Most “AI on your data” demos give the agent metadata and stop there. The reason they fail on cross-product questions is that metadata without navigation is a dictionary without a map.

The framing I find useful: metadata answers “what is this,” navigation answers “how do I get there from here.” A reporting agent that can only do the first will produce confidently wrong numbers on every question that crosses a boundary, which is most of the questions worth asking.

Two Graphs

They distinguished cleanly between two graphs that often get smushed together when teams say “knowledge graph”:

Lineage graph. Technical. How data flows through transformations from source to product. Most enterprises with a modern stack already have this, even if they have not surfaced it. BigQuery and dataform produce it as a byproduct of running the warehouse. Surfacing it for an agent is an integration job, not a modeling job.

Context graph. Business. How concepts relate to each other in the language of the organization. NPS belongs to satisfaction. CLV belongs to revenue. Customer is the join entity. A “gain” is a delta. This graph is where most enterprises have nothing. Not because it is hard to build — because nobody has been responsible for building it.

When the speaker said “knowledge graphs,” he was careful: knowledge graphs are not a single thing, and they are certainly not synonymous with a graph database. He framed them as a layer that “helps me map where to go to get knowledge and whether I have the right context to use it correctly.” That sentence is the one I want to push on, because it changes what you are building. You are not building a graph. You are building a navigation layer over the artifacts that already exist.

The Counter-Intuitive Part

Here is the finding I did not expect from a Google session, and it is the part most teams will get wrong if they only read a summary:

Too much context is not good. Too much context makes the agent hallucinate. Take a minimalist approach.

The instinct, when the agent gets it wrong, is to give it more. More tables, more column descriptions, more documentation, more sample queries, more everything. The presenter’s experience — and I have hit this in our own customer work — is that more context expands the surface area the model can hallucinate over. The model finds a fragment of irrelevant context, treats it as load-bearing, and now you have a confidently wrong answer with a longer paper trail.

The right context is small. The wrong context is everything you have. The discipline of building a context graph is the discipline of choosing what not to include.

A Practical Recommendation

The headline I want to leave you with is simple, and I think it is the most actionable piece for any team that watched this kind of demo and felt it was beyond their stack: you can start your context graph as a markdown business glossary. You do not need a graph database. You do not need Neo4j. You do not need a vector store.

Open a markdown file. Write down your top twenty business concepts in plain language. For each one, name the entity it lives on, the data product that owns it, and the way it composes with other concepts. Commit it to the same repo that owns your data transformations. Make it the document an analyst would hand to a new hire on day one — that document, plus the lineage your warehouse already produces, is most of what an agent needs to stop being confidently wrong.

Whether you upgrade to a graph database later is an implementation detail. The investment in a context graph is small. It pays back the moment a reporting agent has to answer a “why did this number move?” question across more than one data product. Which, in any organization I have worked with, is most of the questions that actually matter.

The best demo I saw at Cloud Next 2026 was not a model release. It was a team showing, with two runs of the same question, that the agents we have already work — when we give them a map.

This analysis synthesizes the Google Cloud Next 2026 session on agent context and knowledge graphs (Google Cloud, April 2026), Google ADK documentation (Google, April 2026), and the author’s in-person notes.

Victorino Group helps teams build the context graph that turns a confidently-wrong agent into a navigable, governed one. Let’s talk.