Data Agent Kit brings Bigtable queries into coding agents

Google’s Data Agent Kit now includes Bigtable, bringing database-aware skills and MCP tools into coding agents. Google announced the kit’s general availability on September 30; the October 1 Bigtable release notes describe support for browsing instances and tables, designing schemas and querying with GoogleSQL.

During a rollout investigation, an SRE might want the assistant to explain whether a timeout setting changed before latency increased. Reading the configuration row is a useful start, but the latest values alone leave out the history needed to examine that sequence. The kit makes the database easier to reach from a coding agent; interpreting what comes back is still part of the investigation.

The kit connects the agent to the database

Data Agent Kit combines Google-authored skills with MCP connections to supported data services. It is available through an IDE extension and plugins for coding agents, including Codex CLI and Claude Code. The new Bigtable support packages guidance for tasks such as row-key design alongside tools that can inspect and query the service. Bigtable’s SQL history semantics are an existing capability, not something introduced by this announcement.

The connection still needs a selected Google Cloud project and appropriate credentials. The installation instructions distinguish the coding-agent plugin from its Google Cloud authentication setup. Installing the plugin alone does not make the database reachable or authorize a query. Start with the project and tables needed for the investigation, and check the requested actions against the kit’s permissions guidance.

A current row is not a configuration timeline

Consider a hypothetical service that stores configuration in a Bigtable table named service_config, with a config column family and a row key of search-api#prod. After a rollout, an assistant reads a timeout in milliseconds of 800 and a retry count of 3. Those two current values do not establish that they were written together, loaded by the application or responsible for a latency increase.

Bigtable’s GoogleSQL documentation explains why the current row leaves that question open. A normal query returns the latest cell value for each column qualifier. The timeout and retry values appear together in the result because they belong to the same row, even when their cell timestamps differ. That combined result is not a record of one simultaneous configuration change.

Adding with_history => TRUE returns each qualifier’s retained timestamped cell versions, ordered newest first. The assistant can then examine the timeout’s history separately from the retry setting’s history. For the illustrative row, the query is:

-- 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 retained timeout cells contain 500 with timestamp 09:10 and 800 with timestamp 10:04, while the latest retry setting has timestamp 09:20. These invented values and times illustrate the interpretation; they are not measured query output. The assistant can report two separate cell histories. It cannot yet report which configuration the running service used. Bigtable allows clients to override mutation timestamps, so interpreting these as a write sequence also requires checking how the application assigns them.

Require the answer to preserve what is unknown

Require the assistant to distinguish stored cell versions from application state, and ask for the next observation that could change the diagnosis. This applies our operational-prompt guidance to a concrete database result. An answer that confidently names the rollout as the cause without that evidence should fail review, even when its SQL is valid.

In this example, the useful next request is an application log or configuration readback showing which timeout and retry values a specific instance loaded, with an observation time. That could support or contradict the proposed sequence. Repeating the latest-value query would leave the same uncertainty.

History is limited to the cells Bigtable retains under its garbage-collection policy; it is not a complete deployment audit. A missing older version cannot prove a setting never changed. If the investigation needs an application-level timeline and that evidence is unavailable, keep the causal conclusion open.

For a first use of the kit, choose an approved row or key range whose retained versions can answer a specific investigation question. Ask for those versions, then compare the assistant’s account with the cells it returned. The Bigtable MCP guide distinguishes query tools from administration tools, so permission for that read does not imply permission to alter the service. The useful result is a more precise next check: in this example, finding out which settings the application actually loaded. No live Bigtable or Data Agent Kit trial is claimed here.