We're three weeks in, have you tried the new Assist yet?

[GabrieleHB]

Hey all 👋

In case you haven't heard, we shipped a major Assist release with 338. Our agentic AI experience has literally been rebuilt from the models up. Here's the rundown of the four changes that shipped three weeks ago. 

1. Claude Sonnet 4.6 is now the foundation model

The LLM behind Assist switched from OpenAI's GPT-4o to Anthropic's Claude Sonnet 4.6. Complex investigations feel different now: you should notice sharper multi-step reasoning, and more reliable tool use.

One thing worth noting: this isn't a raw Sonnet endpoint with a chat UI bolted on. Every interaction still flows through the Assist guardrails and system prompt, the Skills (see below), and tool calls into Grail and Smartscape. The model is just the engine; it's the Dynatrace context that makes it truly useful.

What I'd like to know: does Assist handle your harder, multi-step questions better than it used to? If you've run the same kind of investigation now and a few weeks ago, where do you notice the difference?

2. Skills: a curated Dynatrace knowledge base

Assist now consults a curated set of skills, Dynatrace-specific procedural knowledge in the same open format as Anthropic's Claude Agent Skills. It's the same pattern we open-sourced earlier this year as Dynatrace for AI for external coding agents, now applied inside the product.

The skills shipping in this release cover advanced problem analysis (root cause analysis, impact assessment, correlation), hyperscaler and Kubernetes observability, distributed traces, and logs. We're shipping new skills with each release.

Later this year we're opening this up so you can contribute your own skills, bringing your team's internal know-how into Assist alongside ours.

What I'd like to know: when Assist's answers feel deeper or more opinionated than they used to, that's the Skills doing their job. If you spot a domain where it still reasons from scratch when it should be applying expertise, that's a gap. Let me know.

3. A purpose-built NL2DQL model

We retired the RAG-based DQL generation in favor of a purpose-built, fine-tuned foundation model based on Llama 3.1 8B, trained on hundreds of thousands of real DQL examples. Natural-language-to-DQL is significantly more reliable now.

You'll see it in Assist chat, the Prompt sections in Notebooks and Dashboards, and via the Dynatrace MCP server. If you tried NL2DQL a few months (or years!) ago and it was hit-or-miss, this is the version worth coming back to.

What I'd like to know: specific queries that work now where they used to fail. Also the opposite, queries that still fail, especially the ones you'd expect to work. Pasting the natural-language prompt and the resulting query is most useful.

4. Side-by-side mode: Assist without switching context

The chat interface no longer takes over your screen. Assist now opens as a side panel next to whatever you're working on, with two modes:

• Floating, for quick questions on smaller screens.
• Pinned, parked alongside a dashboard, notebook, or other app for long investigations.

A few smaller things came with this:

• Apps now have their own dedicated prompt examples. Type `/` in the chat to bring them up.
• The Assist settings screen shows which tools Assist has access to.

What I'd like to know: are your sessions getting longer or more useful with the side panel? Any pages where the layout breaks down or fights with the app underneath?

What's coming next

The things I get asked about most are also the next big ones we're working on: letting Assist create notebooks, dashboards, and workflows for you, and giving it the ability to manage alerts or configs on your behalf. Neither is in this release. Both are coming.

What else would you want Assist to do? That's the kind of input that shapes what we ship next.

Where you come in

I want both kinds of feedback: what's working, and what's still rough.

The "what's working" half matters because we don't always know which changes are landing for customers until we hear it from YOU. It helps us figure out where to invest next.

The "still rough" half is what I learn from. The most useful feedback I get is from people willing to tell me what they tried, what they expected, and what they got instead. No need to sugar-coat, I want to know what's not matching your expectations, I want to know which queries are still coming back wrong. 🐛

Reply in this thread, or DM me if that's easier. I'll be reading. 👀

– Gabi

Links

• Release notes
• Assist docs
• Dynatrace MCP servers
• Playground
  • 💡Test this prompt: Predict the load for the top 3 services for the next 24h and highlight any trends.

[Khejazi]

Thanks

[dylan_taelemans]

I recently started using it again, and it is already a major improvement compared to the previous version.

It is also useful that you can see the sources it has used, especially when I want to validate information that I remember seeing somewhere in the Dynatrace documentation but cannot remember exactly where.

It can sometimes be challenging to find your way through the Dynatrace documentation. One of the main advantages of AI is that it can scan and search through documentation much faster than a human, making it much easier to quickly find information or validate assumptions.

I still have some small observations:

DQL queries

When asking for a DQL query, it redirects me to ask the same question from Dashboards or Notebooks. I understand the reasoning behind this, as those are the logical places where queries are executed. However, in some cases, it would be more convenient to work on the query directly within the chat.

Having the conversation history available would make it easier to understand how the query was built, track the different iterations, and identify where something went wrong if the final query does not produce the expected results.

In Dashboards or Notebooks, you only have the final version of the query and lose the different iterations and reasoning steps that led to it.

Troubleshooting Guides

The Troubleshooting Guides feature is another nice feature. It does take some time to build up a sufficient number of TSGs, but that is expected.

One thing I would like to understand better is how the linking between problems and Troubleshooting Guides actually works.

I have a few use cases where I ingest events from third parties. These metrics end up at the environment level, which has never really been an issue. However, the Troubleshooting Guide linking seems to rely heavily on entities and does not appear to take the previous problem title or description into account.

I am currently addressing this by creating custom entities and linking the different cases to their corresponding custom entity. However, it would be interesting to better understand which attributes are used exactly for the matching process and whether there are ways to improve the linking for custom problems or metrics besides EntityTypes.

I will update or add new comments if I have any additional feedback.