Today’s AI agents are smart enough. They fail at Kubernetes chores anyway, because the answers they need are scattered across repos, templates and clusters. Give the agent a database instead of a grep target, and retrieval stops being the failure mode.

Platform teams have started typing requests like this into a chat window:

“Find every workload in the fleet without a CPU request, rank the worst offenders by environment, and propose a fix.”

Whether that request ends well has surprisingly little to do with the model. It depends on what the agent has to retrieve from.

In Querying Kubernetes Fleets Like a Database, I showed how ConfigHub’s --where-data flag answers fleet-wide questions in one command. I wrote that article for humans. This one asks what changes when the one running the query is an AI agent.

The short answer: the pattern that works is a strict division of labor. The probabilistic component decides which question matters. A deterministic component guarantees the answer is complete and correct.

The Failure Is Retrieval, Not Reasoning

Point an agent at a conventional GitOps setup and the task decomposes into a chain of fragile steps. It has to find the right repositories. It has to understand each one’s templating scheme. It has to render Helm charts and Kustomize overlays with the correct values for every environment, then parse the resulting YAML. Some agents skip the rendering and regex their way through raw templates instead. And one thing is fairly certain: for now, nobody wants an AI agent scraping production clusters for those answers.

Every step is a chance to retrieve the wrong thing and reason confidently from it.

Even for teams willing to let an agent near their clusters, the mechanics are no better. Shelling into kubectl across a dozen contexts retrieves live state instead of declared intent, one cluster at a time, and it floods the context window with JSON the agent must summarize before it can think.

None of these are reasoning failures. The agent’s judgment may be fine. The stack forces it to do error-prone retrieval before judgment even starts. This is the same Visibility Gap from the previous article, with one difference: an agent cannot shrug and go ask a colleague.

Alexis Richardson’s GitOps in the age of AI series opens with exactly this failure: an agent raises one Helm memory value, every GitOps principle holds, and the fleet still breaks.

A Query Surface Instead of a Grep Target

ConfigHub stores fully rendered configuration for every environment in one database, so the retrieval chain collapses to a single query. Three design choices matter for agents.

The agent asks; the database answers. The open source confighub-skills plugin ships a cub-query skill that teaches Claude Code, or any agent that reads Agent Skills, ConfigHub’s query surface. Handed the request at the top of this article, the agent loads the skill and runs the same command a human would type:

cub unit list --space "*" \
  --resource-type apps/v1/Deployment \
  --where-data "spec.template.spec.containers.*.|resources.requests.cpu = ''"

No cloning, no rendering, no YAML parsing. The response is structured data describing exactly the matching units. The split-path edge case from the previous article, catching containers with no resources block at all, works identically here, so the agent’s compliance answer has the same correctness properties as the human’s.

Nothing about the query language is tribal knowledge, either. The skill carries the translation from workload-speak (“our frontend in us-east”) into spaces, slugs and labels, and cub function explain plus the CLI’s own help expose every field, type and operator. The agent learns the syntax the way it learns everything else: by reading structured descriptions.

Read-only is enforced, not requested. Everything above is investigation, and the skill’s allowed-tools manifest turns that into a mechanical guarantee. It permits only the read verbs: get, list, diff, tree and the read-only inspection commands. No mutation verb is in the list. An agent running under it can explore the fleet as aggressively as it likes and cannot change anything, which is the posture you want while the agent is still forming a hypothesis.

The agent’s questions become artifacts. When the agent lands on a useful query, it can save the predicate as a Filter, a named entity a human can review, reuse and later attach to policy. The audit trail covers not just what the agent changed, but what it asked.

When Retrieval Is Exact, Mistakes Become Reviewable

The division of labor pays off in how failures present. The agent decides which question matters: missing CPU requests, worst in production first. The database guarantees the answer set is complete, including the absent-field cases that regex retrieval silently drops.

An agent’s mistakes then become disagreements about judgment, which humans can review. They stop being silent errors of fact, which nobody catches until an incident does.

The Read-Only Half of the Job

Agents do not need a smarter way to grep rendered YAML out of pipelines. They need the rendering to have already happened, the results to sit still and the query language to be discoverable. None of that is an AI feature bolted onto ConfigHub. It is what Configuration as Data was always shaped like, and what Alexis’ Generative GitOps principles call held as data, not files. The agent is just the newest client of the same database.

Finding problems, though, is only half the request. The prompt at the top of this article said “propose a fix.” The moment an agent starts writing configuration, the questions change: what stops it from shipping something bad? Part 4 of the GitOps AI series already states the rule: whether a change succeeded is decided by evidence from the running systems, not by the agent that made it. The mechanics are the next article: agents, triggers, and the gates that make agent-written changes safe.

Explore Further