Two incidents in late 2025 taught us a hard lesson: you can’t build a trustworthy agent on a foundation you don’t control, or can’t measure.

Everyone is racing to build agents that do real work. So were we. Our goal was easy to say and hard to do: an AI DBA that manages, optimizes, and operates cloud data platforms on its own, the way a great database administrator would.

Here’s what we learned along the way: the agent was the easy part. The hard part was everything underneath it. Two incidents made that painfully clear.

The night our AI DBA got slow, and we’d changed nothing

Late last year, we watched our AI DBA’s interactions visibly slow down. No deploy on our side. No config change. No new code. Nothing we did.

We root-caused it anyway. The culprit wasn’t us. It was a specific model from our LLM provider whose latency had jumped 5–10x, a change the provider attributed to their terms of use. Our agent was sitting there, patiently waiting on a model that had quietly gotten an order of magnitude slower overnight.

The day it tried to spend a fortune to save a little

The second incident was the opposite problem: not too passive, too ambitious.

On selected complex tasks, query optimization in particular, we caught our AI DBA firing 1M+ tokens at the LLM to crack a single problem. It wasn’t wrong, exactly. It was thorough. It just had no sense of whether the problem was worth that much compute in the first place.
‍

The moment we wired ROI into the loop, the behavior changed. The agent stopped treating every problem like a research project and started spending like it had a budget, because now it did.

These were never DBA problems. They were agent problems.

Notice what neither of those stories was actually about: databases. Swap “AI DBA” for any serious agent doing real work, and the plot is identical. Which model? At what latency? At what cost? And was the work even worth doing?

So we stopped treating them as one-off fires and built the layer underneath the DBA: an AI agent for agentic AI itself. The building blocks every trustworthy agent needs, ours included: auto model selection, prompt optimization, automated ROI of work, observability, token economics, and governance.

But a great DBA needs more than a great agent

Here’s the part that’s easy to miss, and it’s the most important one. That foundation makes our AI DBA trustworthy. It doesn’t make it a DBA.

What makes it a DBA is innate, hard-won expertise: the things a senior administrator carries in their head and never has to look up. The architecture of each warehouse. How each one bills consumption (credits, DBUs, slots, nodes) because on consumption-based pricing, the “thorough” query plan is often the expensive one. And the no-no’s: the specific things you simply do not do on a given platform, because they’re cheap on one and ruinous on another.

You don’t solve a Snowflake problem the way you’d solve a BigQuery one. An agent that doesn’t know that in its bones isn’t a DBA. It’s a very confident intern with a corporate card.

One foundation without the other doesn’t get you there. Agentic intelligence with no data expertise is a clever bot loose in your warehouse. Deep data expertise with no agentic foundation is a great tool that still needs a human babysitting every model call and every dollar. The AI DBA needs both, and that’s exactly what we built.

We didn’t read about these problems in a paper. We hit them, in production, with our own agent. And every fix became part of the foundation our AI DBA now runs on: the same foundation we’re opening up so you can build and trust agents of your own.

Because that’s the quiet truth of this whole agentic moment: the model is the easy part. The judgment underneath it, what to run, on which model, at what cost, and whether it’s worth doing at all, is the product.