The cheapest context is the one your agent never loads. Google turns its developer docs into an agent API

A common assumption in coding agents: the more documentation you put in front of the model, the better its answers. Paste the whole API reference, let the agent scrape a few pages, and accuracy should follow.

It mostly does not. Large, scraped context is slow, expensive, and often stale: a forum post from two years ago looks just as authoritative to a model as the current reference. On October 7, Google described what the alternative looks like for its own platforms, and it is worth reading as a counterexample to the assumption.

What Google built instead

The Developer Knowledge API is, in Google’s words, its official, programmatic source of truth for developer documentation about Google Cloud, Firebase, Android and more. It offers semantic and keyword search, chunk retrieval that returns relevant passages rather than whole pages, grounded question answering, and full pages as Markdown when an agent needs the complete text. Google says the index is refreshed frequently, so agents see documentation changes with little lag.

Access comes through the gcloud CLI (preinstalled in Cloud Shell), an agent skill over MCP that Google lists for Antigravity, Claude Code, Cursor and GitHub Copilot, client libraries in seven languages, and an API Explorer.

The recommended workflow is the interesting part: search chunks first, and fetch full Markdown pages only when needed. Google’s post does not label the API as generally available or preview, or give pricing. The documented default quotas are 100 chunk searches and 100 document fetches per minute per project, and 50 grounded answers per day per project, so check status and terms before building production pipelines on it.

Testing the assumption

More context is not more accuracy. A few relevant passages give the model less irrelevant text to wade through. Escalating to a full page only when the passages fall short usually improves answers and cuts tokens at the same time. Agents already put heavy load on data systems, as we described in our analysis of the agent data path; retrieval design is where much of that load is decided.

Authority is a property of the path, not of the model. An agent that retrieves from the vendor’s own, current documentation is less likely to use a deprecated parameter than one that scraped a forum. No model upgrade fixes a retrieval path that points at the wrong source.

One source for many agents. Exposing the same knowledge through CLI, MCP and libraries means every coding tool in a company reads the same truth, instead of each one building its own scraper.

The same mistake, inside the company

Internal platform teams have the problem Google just solved for its own docs. API references, runbooks, architecture standards and security policies live in wikis that agents scrape badly, or get pasted whole into prompts.

The fix has the same shape. Publish internal knowledge as a retrieval service, with search, chunks and full documents, exposed over MCP so every approved agent uses it; that is the managed retrieval decision we discussed in our piece on Cohere’s Compass, applied to internal knowledge. Give each source an owner and an update cadence, or the agent will retrieve stale truth with great confidence. Then measure retrieval on its own, whether the right chunk came back, and track tokens spent on context per task, which is often the largest line in a coding agent’s bill.

The cheapest context is the one your agent never had to load. The most reliable is the one that came from the owner of the truth.