What It Does

An AI operator that investigates incidents on its own.

The diagnostic bot lives in chat and works an incident the way an on-call engineer would — except in seconds. It queries the observability stack directly (Loki for logs, Prometheus for metrics, Tempo for traces), correlates what it finds across all three, sanitizes anything sensitive (PII and secrets) on the way out, and writes up a diagnosis with the exact remediation. Junior engineers get senior-level answers through a chat box; nobody has to learn the query languages first.

Just Ask — No Query Language Required

Because the bot exposes its capabilities as an MCP server, you don't have to know PromQL, LogQL, or TraceQL — or how to build a Grafana dashboard — to get an answer. You have a normal conversation with the agent of your choice: describe what you want to see in plain language, look at what comes back, and refine it out loud until it's exactly right.

And it goes beyond metrics and logs. Pointed at a database with introspection tools, the same approach lets a product manager or business owner ask for what they're after and have the agent work out where that data actually lives — which tables, which columns, which joins. No SQL, no schema spelunking, no waiting on an engineer. Ask in the language you already speak, and iterate until you have your answer.

Because the interface is simply conversation through your agent, it inherits whatever your agent can already do — including voice. We don't build the speech layer, but if you use an agent that listens, you can talk to your infrastructure out loud, and nothing on the platform side changes.

The Bot Isn't the Clever Part

Here's the honest version: the bot is a thin layer. It's a language model with a handful of tools that call the same query APIs an engineer would — no proprietary model, no secret sauce. Today, anyone can assemble one, and increasingly, everyone will.

The components it stands on — Prometheus, Loki, Grafana, Tempo — are open source and everywhere, so the models already understand them out of the box. Wiring up the bot is a weekend project. The value was never there.

The Real Work Is the Data

The reason the bot works — the reason it can work at all — is the observability platform underneath it: unified, structured, correlated metrics, logs, and traces, exposed through clean, consistent, queryable interfaces.

You've probably heard the phrase "getting your data ready for AI." This is what that actually means. Point an AI at siloed logs, numeric metrics jammed into a full-text search engine, and no traces — the "Observability 0.4" stack we see everywhere — and it has nothing to reason over. No model rescues bad data. Lay the same data out well — modeled, correlated, and queryable — and the intelligence layer becomes almost trivial to add.

Here's the part people miss: the work that makes data ready for AI is the same work that makes it more accessible to your engineers. Both do better with wide, flat data — everything laid out in the open, correlated and queryable in one place — than with siloed rabbit-holes you have to climb down one at a time. Make your data legible to a machine and you've made it legible to a human, too.

Built for Humans and Machines Alike

There is no separate "AI pipeline." The PromQL, LogQL, and TraceQL queries an engineer types by hand are the exact tools the bot calls — one data layer, one set of interfaces, read the same way by people and models. Design the data to be queryable and you get both audiences for free.

That's what makes it durable: as the models get better, the bot gets better on its own — no rework — because the substrate was built right. And because the whole stack is open source and self-hosted, the same design ships inside an on-premise product, diagnostics included, at the cost of infrastructure.