What Your Agent Reads in the Four Seconds Before It Writes the Query

The interesting question about AI agents and BigQuery is not whether an agent can write SQL. It plainly can. The question is what it consults in the moment before it does.

Today, for most teams: a table listing, some column names, maybe a sampled row, and a great deal of inference. An agent sees a column called status typed STRING, samples a few hundred rows, finds three distinct values, and proceeds as if those three are the contract. It sees customer_id in two datasets and assumes they join, because BigQuery enforces no foreign keys and nothing in the warehouse says otherwise. It picks whichever orders table looks canonical.

Most of the time this works, which is exactly the danger. The failures are silent and plausible: a query over the deprecated copy, a join across columns that were never the same identifier, a filter built from whichever values happened to appear in a sample.

The agent is not being careless. It has nothing better to consult. The CoreModels BigQuery integration exists so that it does.

Governed facts an agent can read instead of infer

Once a BigQuery estate is imported, the things an agent most needs are recorded rather than guessed:

• Identity. Every table and view is a governed Type carrying its full project.dataset.table identity as an explicit mapping, with materialized views and external tables distinguished. "Which orders table" stops being a judgement call.
• Allowed values. Where a value set is governed, it exists as a taxonomy with named terms. An agent filtering on a status reads the agreed set rather than the sampled set.
• Obligation. is_nullable = NO becomes a NotNull check on the governed element, so an agent knows which columns it may rely on.
• The native type, verbatim. The exact BigQuery type string is preserved on the vendor metadata mixin, so an agent casting a value reads NUMERIC rather than inferring it from a governed double.
• Documentation, where it exists. Descriptions captured from TABLE_OPTIONS and COLUMN_FIELD_PATHS travel into the model with the objects they describe.
• Relationships, once a human states them. Because BigQuery enforces no keys, the connector reads none and invents none — but a reference asserted in CoreModels becomes a fact the agent can read, instead of a pattern it has to spot.

Consultation over MCP, with the write path closed

CoreModels serves these facts over MCP — the protocol AI clients already speak — from an OAuth-protected endpoint such as https://coremodels.example.com/mcp. An agent connects once and consults the model mid-task rather than being briefed up front.

The general tools do the orientation: list the caller's projects, summarize a project's types, elements and taxonomies, search nodes, validate a JSON document against the project's schema, or export the governed schema as JSON Schema, Avro, LinkML, ShEx, JSON-LD, SQL or OWL.

Three integration tools are BigQuery-relevant, all read-only:

• get_vendor_integration_status — with a vendor of bigquery, the last-import state: when it happened, the artifact fingerprint, the counts, how many governed datasets exist. Without a vendor, the registered connectors and their capabilities.
• audit_vendor_project — a fresh information_schema extract against the governed model, read-only, returning coverage, drift and conformance findings plus a readable report.
• generate_vendor_artifacts — governed model to BigQuery DDL, for an agent drafting a change.

Artifacts go inline under artifacts or, when an extract is too large to inline, by URL under artifactUrls. Those server-side fetches are deliberately constrained: https only, redirects disabled, hosts resolving to loopback, link-local or private ranges refused outright, and the response size capped. An agent handing us a URL cannot use us as a probe into an internal network.

The permission story matters as much as the tool list. The public endpoint serves read-only tools only. Importing an estate or reconciling two estates are Admin-role operations on a separate admin endpoint, and the enforced boundary is per-project membership, not merely which URL a token came from. An agent wired up for consultation cannot alter governed meaning — structurally, regardless of prompt.

The audit as a pre-flight check

The most underrated agent behavior is checking before acting, and the audit makes it cheap. Before building on a dataset, an agent can run one and learn, in coded machine-readable findings, whether reality still matches meaning: field-type-drift where a column no longer holds its governed type, field-removed or dataset-removed where something it planned to query is gone, dataset-unmapped where an estate object was never brought under governance at all. An error count above zero is the same fail signal a CI pipeline uses; an agent can adopt the same discipline a build does.

Two BigQuery-specific rules are, in effect, written for agents. table-no-description flags undocumented tables — its stated rationale is that undocumented datasets resist governance and agent grounding alike. semi-structured-column warns wherever STRUCT, ARRAY or JSON columns carry ungoverned inner schemas, and names them. For an agent, that second one is gold: it marks precisely where the model's knowledge stops and the right move is to lower confidence or ask a human. A grounding source that maps its own blind spots beats one that implies omniscience — which is also why the honesty channel matters: a NUMERIC column governed as an approximated double says so, on the record.

Semantics that travel back into the warehouse

There is a second-order payoff. When CoreModels generates BigQuery DDL from the governed model, it writes the agreed meaning — allowed values, references — into table and column descriptions, because BigQuery enforces no keys or check constraints and descriptions are where meaning can actually live. Deploy that script and those descriptions flow back out through INFORMATION_SCHEMA and the console. Even an agent with no connection to CoreModels now meets real semantics in BigQuery's own metadata instead of blank fields.

Why this beats a bigger context window

The reflex in agent engineering is to fix grounding with volume: dump the schema, paste the samples, attach the wiki. But a schema dump is structure without meaning, samples are anecdotes, and wikis drift. What an agent needs is what a new senior engineer needs — a maintained account of what the data means, an honest boundary around what is not known, and a fast way to check that reality has not moved since yesterday. No context window supplies that by size alone.

Agents will read your schema far more often than any human does. Treating their grounding as a governance output rather than a prompt-engineering afterthought is the difference between an agent that answers from the record and one that answers from the column names.

The Google BigQuery quickstart lists the MCP tool calls alongside the HTTP surface.