Starting this year, Dynatrace has consolidated its AI capabilities under a single name: Dynatrace Intelligence. Davis remains in place and serves as a core component, primarily for root cause analysis. We spoke with Florian Ortner, SVP of Product Management, Observability, about how built-in agents, Grail, and DQL together form the foundation for what the company calls autonomous operations.
The name Davis is fairly well known among Dynatrace users. It was the company’s only AI engine, used exclusively for incidents and root cause analysis. While those capabilities are highly valuable, they represent a limited application given AI’s capabilities today.
If, for example, you want to optimize your cloud costs, it’s not just about incidents. “So we want to also have something that is more neutral for explorative analytical use cases,” Ortner explains. Davis isn’t going away, but it’s now the root cause capability within a broader umbrella: Dynatrace Intelligence. Ortner compares it to Apple Intelligence, where various standalone features have also been brought together under a single umbrella.
Grail and Smartscape now fully integrated
Under the hood, it all revolves around a few building blocks. Grail is the lakehouse where all telemetry lands. Smartscape is the topological model that maps how components are connected to one another. That model isn’t separate; it’s embedded within Grail itself.
How is this different from simply storing metrics and logs? Context. If a metric and a log come from the same container, you’ll see that container connecting the two signals in Dynatrace. You can then drill down to see which containers it communicates with. It’s a graph database for navigating between data points. It works for logs, spans, metrics, and events.
What’s new is that Dynatrace can now take a much broader approach. The platform stores and analyzes all telemetry signals in Grail and links them via Smartscape. According to Ortner, the company implemented this transition in phases over about a year.
Agents that don’t touch all the data
According to Ortner, this year’s focus is on the agent-based approach. Dynatrace provides built-in agents, including a Root Cause Analysis agent and an Analytics agent. These run autonomously on the data but do not yet trigger any actions.
They deliberately do not examine everything. A petabyte of data flows through the platform every day, and running agents on all of it is, according to Ortner, economically unfeasible. You would, so to speak, burn through a trillion tokens a day, which amounts to about a million dollars a day. That’s why the data first undergoes statistical, deterministic, and algorithmic analysis. Only a fraction of that data then reaches an agent equipped with full context and an LLM.
The agents are enabled by default for customers using the latest platform version. Customers can disable them, but this almost never happens. There are no additional costs: it’s included in Dynatrace.
Does Dynatrace guarantee that these agents work flawlessly? No. But Ortner qualifies this: even with earlier analyses, the answer was no. For the noisy tasks that Dynatrace could barely handle in the past, he argues that the quality is now better than ever, simply because much more data is being analyzed.
DQL and the path to natural language
To query Grail, Dynatrace built its own query language: DQL. PromQL and Splunk’s SPL already exist, but according to Ortner, neither language could traverse the Smartscape model during a query.
The second reason was its usability further down the chain. DQL is intended not only for analysis but also for ingestion pipelines and data sources. A single language for both analyzing and configuring what is recorded and how it is transported.
Hardcore DQL remains the domain of experts. That’s why Dynatrace trained its own model that converts natural language into DQL. Ortner cites a success rate that has risen from about 60 percent a year ago to around 90 percent, better than a generic model based on the documentation. That model has been live for three to four months and powers the Assist chat interface. In addition, users can retrieve the underlying DQL with a single click on every screen and every out-of-the-box alert, which, according to Ortner, provides thousands of examples.
OpenInference as OpenTelemetry for AI
Dynatrace recently acquired Arize. Together with a third party, it is working on the OpenInference standard. The guiding principle: AI services should not be a black box to customers. Two to three years ago, AWS and others were already using OpenTelemetry as an export format, via OTLP, to provide customers with insights. With the rise of services like Bedrock, standardization became more urgent, and OpenTelemetry alone proved insufficient.
The standard began as a fork, but the goal is to contribute something that will ultimately be incorporated into OpenTelemetry. OpenInference is a semantic convention layer on top of OpenTelemetry that standardizes spans and attributes for LLM calls, tool usage, retrieval, agents, and token usage.
Fewer ITOps, more developers
Historically, Dynatrace focused on ITOps and DevOps because they owned the production environment. That’s shifting. At large companies, Ortner sees fewer traditional ITOps people and, conversely, more developers. Tasks that Ops used to handle years ago have already shifted to development teams.
These two groups work in completely different ways. Developers have an IDE open and are comfortable with the command line. They often don’t use the Dynatrace UI, but they do use the MCP approach, APIs, and command-line interfaces. ITOps works with a UI, follows training, and adheres to a strict process. Another difference: developers don’t focus on costs. ITOps, on the other hand, always wants to discuss them.
Tip: Dynatrace offers developers new observability tools
Autonomous operations with a human touch
According to Ortner, all these building blocks, agents, Grail analytics, and Smartscape, serve a single purpose: to help companies adapt to autonomous operations. That doesn’t mean humans will be phased out. What can be automated, however, is manual, repetitive work. For example, ticking off a compliance check in ten minutes. Ortner speaks with many customers and hears the same thing everywhere: teams that are too small, a growing regulatory burden, and the desire to automate simple but time-consuming tasks. Autonomous operations can help with that, while still maintaining the “human-in-the-loop” concept.