Data Agent Kit finds the timeout history. The running instance has the next clue.

Imagine investigating slower requests after a rollout. The configuration row says the timeout is 800 milliseconds. That looks like a promising explanation, until someone asks a smaller question: did the slow instance ever load that value?

Google’s Bigtable integration in Data Agent Kit can help retrieve the history needed for that question. The kit reached general availability in the September 30 announcement. The October 1 Bigtable notes describe browsing instances and tables, designing schemas and running GoogleSQL from coding agents. Getting the row into view is useful progress. It is not yet an explanation of what the running service did.

Reach the intended row with the right access

An engineer can reach the row through Data Agent Kit, which combines Google-authored skills with Model Context Protocol connections. MCP gives the agent a way to request operations from the external database service. An IDE extension or plugins including Codex CLI and Claude Code provide routes into that workflow, not permission to inspect every table.

After installing the plugin, the engineer still needs Google Cloud authentication for the intended project and credentials allowing this read. The permissions guidance distinguishes that access from other actions. An unauthorized query needs the appropriate permission, not a more persuasive prompt. Once connected, the kit reads history Bigtable already retains; it does not create a new past for the row.

Two settings beside each other can have different histories

In our invented table, the row key search-api#prod locates the service’s settings in service_config. Related values sit together in the config column family. Individual names, called qualifiers, identify settings such as timeout and retries. A timestamped cell holds a value; retaining several cells can preserve older versions.

The latest timeout is 800 milliseconds and the latest retry count is 3. They appear side by side, but that does not mean they arrived together. The row groups them; each setting has its own history.

An ordinary query returns the latest value of each qualifier. The GoogleSQL guide shows how with_history => TRUE retrieves retained timestamped versions instead, newest first:

-- Illustrative table and key; not executed against a real database.
SELECT _key, config
FROM service_config(with_history => TRUE)
WHERE _key = 'search-api#prod';

Suppose the timeout’s retained cells show 500 at 09:10 and 800 at 10:04. The latest retry cell says 09:20. These values and times are invented, not database output. The timeout history returns 800 before 500, while retries keeps its separate timestamp. Reading both settings in one result has not made them one simultaneous update.

There is another detail to ask the application owner about: clients can supply mutation timestamps. A timestamp is therefore not automatically a trustworthy account of write order. Find out how this application assigns it before reconstructing the sequence.

Ask the running instance which value it used

Now the investigation has a useful, narrower question. Storage retains 500 and the later timestamped 800; which reached the instance serving the slow requests? The operational-prompt principle encourages that explicit question. Valid SQL has found the values, but diagnosis needs the next step.

Suppose a configuration readback or log identifies that instance, the observation time and a loaded value of 500. The stored 800 does not explain this instance’s behavior in the proposed way. Investigate why they differ and what else changed. If the readback instead reports 800, the setting has reached the instance, but its presence alone still does not prove it caused the latency increase.

The old value may not be available. The garbage-collection policy can expire cells by age or retained-version count. An empty patch of history cannot establish that nothing changed. When the needed timeline is gone, leave the cause open.

Keep this first investigation inside an approved row or key range, and check the assistant’s account against the cells returned. The Bigtable MCP guide separates query tools from administrative ones: inspecting the timeout does not authorize changing it. No live kit or database trial is claimed here.

The latest row still says 800. What matters now is the fact beside it: this instance kept using 500, or it loaded 800 and the effect remains to be investigated. Data Agent Kit helps reach the retained history. Following that value into the application tells us how much of the story the history can actually explain.