Poniższy tekst to notatki z webinaru „Dynatrace Intelligence: Get to know the Dynatrace agentic AI platform AMA”. Wszystkie obserwacje, wnioski i oceny techniczne przypisane są rozmówcom: Wolfgangowi Beerowi (Product, AI capabilities, Dynatrace) oraz Gabby (Product Manager, Generative & Agentic AI, Dynatrace). Sekcje „Jak zacząć dziś?” i „Kluczowy insight” stanowią interpretację autora notatek na podstawie materiału z webinaru.

TL;DR

Dynatrace Intelligence to nie rebrand Davisa ani Davis Copilota, lecz nowa architektura łącząca dane, kontekst platformy i modele AI w jeden ekosystem agentów.
Platforma rozwija się przez trzy fazy: AI amplification, AI augmentation i AI autonomy. Dynatrace dostarcza rozwiązania na każdym z tych poziomów.
Dynatrace Assist działa teraz jako pełna wersja agentyczna z operatorem LLM, katalogiem narzędzi i równoległym wywoływaniem agentów, co stanowi fundamentalną zmianę wobec poprzedniego modelu.
Agenty komunikują się między sobą oraz z zewnętrznymi platformami (ServiceNow, IDE) bez konieczności przełączania kontekstu przez użytkownika.
Root cause agent uruchamia się automatycznie przy każdym wykrytym problemie i nie wymaga żadnej konfiguracji.
Agentic workflows z gotowymi szablonami są dostępne w preview i obniżają próg wejścia w automatyzację do minimum.
Fine-tuned model NL2DQL oraz resources/instruction files mają znacząco poprawić jakość zapytań w naturalnym języku i są bliskie wydania.

Czym właściwie jest Dynatrace Intelligence?

Konferencja Perform 2025 przyniosła ogłoszenie Dynatrace Intelligence. Część klientów odebrała je jako zmianę nazwy istniejących produktów, jednak Wolfgang Beer i Gabby z zespołu produktowego podkreślali, że to interpretacja błędna.

Według rozmówców Dynatrace Intelligence to nowy sposób dostarczania AI przez całą platformę. Nie chodzi o jedną nową funkcję, którą można po prostu włączyć, lecz o zmianę architektury. Jak ujęła to Gabby: nie jest to wyłącznie zmiana nazwy Davisa i Davis Copilota, nie chodzi też jedynie o wymianę ikon. Celem jest połączenie kontekstu platformy, danych i funkcjonalności z modelami AI w taki sposób, by dostarczać wiarygodne i praktyczne wnioski na szeroką skalę.

Trzy fazy dojrzałości AI: od ABS do samojezdnego auta

Gabby przedstawiła model trzech faz, który Dynatrace stosuje zarówno do opisu własnego produktu, jak i do oceny gotowości klientów do adopcji AI. Do ich wyjaśnienia używa analogii samochodowej.

Faza	Analogia	Co oznacza w praktyce
AI amplification	ABS, wspomaganie kierownicy, nawigacja	Użytkownik w pełni kontroluje system. AI ułatwia pracę, ale nie ingeruje. Szybsze zapytania, podpowiedzi, automatyzacja prostych zadań.
AI augmentation	Tempomat adaptacyjny, asystent pasa ruchu	AI działa jak członek zespołu. Analizuje, doradza, podejmuje ograniczone akcje. Użytkownik prowadzi, jednak AI zapobiega błędom i redukuje obciążenie.
AI autonomy	Tryb samojezdny z planowaniem trasy	Użytkownik wyznacza cel, AI prowadzi i nadzoruje. W praktyce: analiza incydentów, auto-remediacja, optymalizacja obserwabilności.

Dynatrace podkreśla, że nie wszyscy klienci są gotowi od razu na trzecią fazę. Dlatego platforma dostarcza rozwiązania na całe spektrum, umożliwiając organizacjom adopcję AI we własnym tempie.

Fundament: Grail i Smartscape

Przed omówieniem agentów warto zrozumieć infrastrukturę, która je zasila. Wolfgang Beer wyjaśnił, że całość opiera się na dwóch elementach.

Grail to unified data lakehouse, czyli centralne repozytorium wszystkich danych obserwabilności. Wszystkie zapytania agentów, analizy i prognozy sięgają właśnie do niego. Smartscape z kolei to real-time dependency graph, graf zależności między elementami infrastruktury aktualizowany na bieżąco. Dostarcza agentom kontekst topologiczny: co jest z czym połączone, co na co wpływa i jak wygląda łańcuch przyczynowy problemu.

Oba elementy są dostępne przez MCP server, w rezultacie czego zewnętrzne agenty i narzędzia korzystają z dokładnie tego samego fundamentu co wewnętrzne agenty Dynatrace.

Co zmieniło się wobec Davis Copilota?

Poprzedni model opierał się na czterech izolowanych endpointach: Natural Language to DQL, DQL to Natural Language, Conversational Recommender i Document Search. Każdy był osadzony w konkretnej aplikacji i obsługiwał wąski zakres przypadków użycia. Gabby wskazuje, że w tym modelu brakowało zestawu wykonywalnych narzędzi: był LLM, był system prompt, były guardrails, jednak kluczowy składnik prawdziwego agenta pozostawał nieobecny.

Dynatrace Intelligence zmienia to w sposób zasadniczy. Pojawia się operator, czyli „driver LLM” z dostępem do całego katalogu narzędzi. Wszystkie cztery poprzednie endpointy stały się narzędziami, a do nich doszły narzędzia DQL, analizatory danych i możliwość egzekucji zapytań zdalnie. Dzięki temu Dynatrace Assist może wywoływać wiele agentów równolegle.

Gabby podkreśla przy tym jeden ważny aspekt filozofii produktu: każdy krok rozumowania agenta jest oparty na danych deterministycznych, a użytkownik widzi pełną ścieżkę dowodową. Nie chodzi wyłącznie o odpowiedź, lecz o możliwość weryfikacji, jak ta odpowiedź powstała.

Jak platforma radzi sobie z niestandardowymi nazwami?

Jedno z pytań publiczności dotyczyło tego, czy Dynatrace Intelligence poradzi sobie z własną topologią i nazewnictwem konkretnej organizacji. Gabby odpowiedziała twierdząco i wyjaśniła mechanizm.

Po włączeniu opcji Environment Aware queries w ustawieniach NL2DQL platforma stale buduje w tle tzw. semantic index danego środowiska. System nieustannie indeksuje własne nazwy metryk, usług i elementów topologii. W efekcie, gdy użytkownik pyta o coś specyficznego dla swojej infrastruktury, AI dysponuje tym kontekstem i uwzględnia go w odpowiedzi. Według Gabby to samo rozwiązanie, które przez 18 miesięcy budowało fundament pod NL2DQL, teraz zasila cały ekosystem Dynatrace Intelligence.

Co jest dostępne już dziś?

Wolfgang Beer wymienił elementy dostępne w tenancie bez żadnej dodatkowej konfiguracji:

Remote MCP server pozwala podłączyć własnych agentów AI lub zewnętrzne narzędzia i korzystać z tego samego katalogu narzędzi, którego używa Dynatrace Assist.
Root cause agent uruchamia się automatycznie przy każdym wykrytym problemie, generując graf wpływu i graf przyczyn źródłowych bez żadnych ustawień ze strony użytkownika.
Forecast agent odpowiada na pytania o prognozy bezpośrednio z poziomu Dynatrace Assist, włącznie z metrykami niestandardowymi i ich sezonowością.
Grail query agent umożliwia eksplorację danych przez konwersację zamiast ręcznego pisania DQL.
Agentic workflows z gotowymi szablonami są dostępne w preview. Wystarczy zarejestrować się i można z nich korzystać od razu.
Dynatrace Playground pozwala przetestować nowe funkcje bez własnego tenantu i jest przez Wolfganga Beera wskazywany jako najprostszy punkt wejścia.

Autokorekta i przejrzystość: Dynatrace Assist w praktyce

Gabby pokazała podczas webinaru przykład, który ilustruje kluczową różnicę między starym a nowym podejściem. W trakcie złożonej, wieloetapowej analizy agent danych popełnił błąd składniowy w zapytaniu DQL, jednak nie czekał na interwencję użytkownika. Samodzielnie zidentyfikował błąd i poprawił się.

W poprzednim modelu taka sytuacja wymagała ręcznej korekty i ponownego uruchomienia. Teraz system radzi sobie autonomicznie, a użytkownik na bieżąco obserwuje pełny przebieg rozumowania, łącznie z informacją o tym, które dane deterministyczne wpłynęły na wynik. Gabby podkreśla, że wykonanie tego samego zadania ręcznie wymagałoby otwarcia wielu zakładek i budowania notebooka krok po kroku. Dynatrace Assist sprowadza to do jednego okna konwersacji.

Agenty rozmawiają ze sobą: integracja z ServiceNow i IDE

Wolfgang Beer opisał dwa scenariusze obrazujące komunikację między agentami w praktyce.

Przypadek deweloperski: programista pracuje w swoim IDE (Cursor, GitHub Copilot, Claude Code lub innym). Zamiast przechodzić do Dynatrace i ręcznie filtrować logi przez DQL, zadaje pytanie bezpośrednio w IDE. Narzędzie kontaktuje się przez Dynatrace MCP server z Dynatrace Intelligence, które odpowiada logami, śladami i informacjami o użytkownikach rzeczywistych, bez zmiany kontekstu pracy. Andy Grabner dodał podczas webinaru, że MCP server jest rozszerzany o możliwość renderowania interaktywnych wykresów bezpośrednio w IDE, eliminując potrzebę otwierania Dynatrace w przeglądarce.

Przypadek SRE w ServiceNow: alert trafia do Service Operations Workspace. Jeśli administrator skonfigurował dostęp Now Assist do agentów Dynatrace Intelligence w kontekście alertów, użytkownik może zapytać o szczegóły zdarzenia bezpośrednio w ServiceNow. Now Assist identyfikuje, że pytanie wymaga danych z Dynatrace, wywołuje odpowiedni agent, ten odpytuje równolegle kilka wewnętrznych agentów, a wynik wraca do interfejsu ServiceNow.

Wolfgang Beer zaznacza, że żaden z tych mózgów nie jest nadrzędny. Agenty partnerują ze sobą, a kontekst, w którym pracuje użytkownik, determinuje, który z nich odpowiada.

Dynatrace CLI: sterowanie środowiskiem z terminala

Osobnym elementem ekosystemu jest Dynatrace CLI – narzędzie open source dostępne na GitHubie (autor: Christopher z zespołu Dynatrace). Pozwala na zdalne sterowanie środowiskiem Dynatrace bezpośrednio z IDE lub terminala, zgodnie z przypisanymi politykami uprawnień.

Za pomocą CLI można między innymi:

ustawiać alerty i modyfikować progi generujące nadmierny szum,
uruchamiać prognozy obciążenia usług na kolejne dni,
tworzyć testy syntetyczne bez nawigacji przez interfejs graficzny.

Wolfgang Beer wskazuje, że zamiast wracać do Dynatrace i przechodzić przez kreator konfiguracji, można wykonać te działania bezpośrednio tam, gdzie się już pracuje.

Onboarding agenta jak nowego pracownika

Istotnym wątkiem webinaru była dyskusja o resources/instruction files, mechanizmie umożliwiającym dostarczenie Dynatrace Intelligence wiedzy specyficznej dla danej organizacji.

Safiya (prowadząca) wskazała praktyczny problem: jeśli nowe wersje DQL wprowadzają składnię nieudokumentowaną jeszcze na stronie produktu (np. lookup tables), zewnętrzne agenty po prostu o niej nie wiedzą. Rozwiązaniem będzie możliwość dołączenia własnych plików z dokumentacją, regułami, niestandardowymi nazwami metryk i topologii.

Gabby porównała to do onboardingu nowego pracownika: „Mówisz mu, że u was pewne rzeczy działają trochę inaczej. Oto mapa terenu, oto co musisz wiedzieć.” W analogiczny sposób będzie można onboardować Dynatrace Intelligence do specyfiki własnej infrastruktury. Resources będą dostępne zarówno dla Dynatrace Assist, jak i dla zewnętrznych agentów podłączonych przez MCP server.

Guardrails: co chroni przed niekontrolowanymi działaniami agenta?

Pytanie o bezpieczeństwo agentów padło z publiczności. Gabby wymieniła mechanizmy zabezpieczające wbudowane w platformę:

Tool execution confirmation – każda akcja wymaga potwierdzenia użytkownika krok po kroku. Agent nie podejmuje działania bez zgody.
Domyślne limity zapytań DQL – zapytania działają według standardowych ustawień, chyba że użytkownik jawnie poprosi o szerszy zakres czasowy.
Kontrola kosztów zapytań – w trakcie prac. Gabby przyznała, że jest to najczęstszym zmartwieniem klientów i priorytet w bieżącym roadmapie.

Agentic workflows: co konkretnie można zautomatyzować?

Wolfgang Beer wymienił podczas webinaru rzeczywiste przypadki użycia dostępne w szablonach lub planowane:

Klastrowanie logów – automatyczne grupowanie linii logów w klastry i porównywanie ich z klastrami z poprzedniego dnia w celu wykrycia nowych wzorców błędów.
Tłumaczenie problemów – przekładanie informacji o problemie na wybrany język (francuski, hiszpański i inne), co jest przydatne w globalnych zespołach.
Analiza sentymentu komentarzy – klasyfikacja komentarzy użytkowników, obliczanie sentiment score i ponowne wstrzykiwanie wyników do Dynatrace w postaci własnych metryk.
Mobile crash remediation – workflow wyzwalany statystycznym alarmem crash, który pobiera dane z Grail, analizuje problem i generuje sugestię code-level fixu w formacie Markdown, gotową do wysyłki e-mailem lub dołączenia jako troubleshooting guide.
Security threat triaging – wielokrokowy workflow, w którym AI jest wywoływane kilkukrotnie, generuje raport o zagrożeniu z confidence score i rozsyła go odpowiednim osobom.
Tworzenie ticketów Jira – bezpośrednia integracja wyników analizy z systemem ticketowym.

Wolfgang Beer podsumowuje to następująco: workflow dostarcza framework, a krok z agentem lub promptem w środku rozwiązuje konkretny problem. Dostępne szablony są punktem startowym, który można adaptować do własnej infrastruktury.

Co nadchodzi?

Wolfgang Beer i Gabby wspomnieli o kilku funkcjach bliskich wydania:

Fine-tuned model NL2DQL – według Gabby testowany wewnętrznie model wykazuje znaczące przewagi nad aktualnymi modelami bazowymi w zadaniach DQL. Premiera blisko.
Problem insights API – pozwoli workflow, zewnętrznym agentom i integracjom takim jak ServiceNow na wstrzykiwanie spostrzeżeń w formacie Markdown bezpośrednio do problemu w Dynatrace, widocznych obok analizy root cause agenta.
Resources/instruction files – mechanizm onboardingu agenta opisany w poprzedniej sekcji, dostępny zarówno przez Assist, jak i przez MCP server.
Agentic workflows z dostępem do operatora – workflows zyskają dostęp do pełnego zestawu narzędzi i resources z MCP servera, zwiększając elastyczność w budowaniu własnych agentów.

Cztery obszary dostarczania wartości

Gabby nakreśliła mapę, według której Dynatrace porządkuje swoje ambicje agentyczne:

Obszar	Opis
AI assistance	Celowane możliwości AI dla dobrze zdefiniowanych, ograniczonych zadań.
Agentic apps	Otwieranie ekosystemu aplikacji Dynatrace na agentic framework.
Agentic workflows	Budowanie i konfigurowanie własnych agentów przez klientów.
Autonomous operations	Niezależny silnik agentyczny, który bada, decyduje i działa z pełnym nadzorem człowieka w pętli.

Jak zacząć dziś? Szybki start bez konfiguracji

Poniższe elementy są dostępne w tenancie już teraz (sekcja na podstawie materiału z webinaru):

Otwórz Dynatrace Assist i zapytaj o aktywny problem. Root cause agent odpowie automatycznie.
Zapytaj Assist o prognozę dla dowolnej metryki, w tym niestandardowej. Forecast agent przejmie zadanie od razu.
Włącz Environment Aware queries w ustawieniach NL2DQL, żeby semantic index zaczął budować kontekst Twojego środowiska.
Zarejestruj się do preview agentic workflows i uruchom gotowy szablon (mobile crash, problem summary, security triage).
Podłącz zewnętrznego agenta lub IDE przez Remote MCP server i przetestuj odpytywanie logów bez wychodzenia z IDE.
Pobierz Dynatrace CLI z GitHuba i przetestuj zdalne sterowanie środowiskiem z poziomu terminala.
Skorzystaj z Dynatrace Playground, jeśli nie dysponujesz własnym tenantem.

Podsumowanie

Dynatrace Intelligence to zmiana architektury, nie zmiana etykietki. Operator LLM jako centralny punkt sterowania, katalog wykonywalnych narzędzi, równoległe wywoływanie agentów, autokorekta i przejrzyste rozumowanie przestawiają platformę z trybu odpowiadania na pytania na tryb autonomicznego rozwiązywania problemów.

Dla zespołów deweloperskich i SRE najważniejsza zmiana praktyczna to dostęp do pełnej głębi Dynatrace bez wychodzenia z IDE czy ServiceNow. Dla platform engineerów kluczowy jest MCP server jako punkt integracji z dowolnym zewnętrznym agentem. Jak ujęła to Safiya podczas webinaru: Dynatrace przeszedł od podejścia „API first” do podejścia „MCP first” – i właśnie to sprawia, że integracja z ekosystemem narzędzi stała się domyślna, a nie wyjątkowa.

Kluczowy insight

Mocniejszy model to nie rozwiązanie

Standardowo myślimy: aby AI lepiej rozumiało nasze środowisko, potrzebujemy potężniejszego modelu bazowego lub kosztownego fine-tuningu na własnych danych.

W praktyce okazuje się, że: Gabby wspomniała niemal mimochodem, że wewnętrzny fine-tuned model NL2DQL firmy Dynatrace przewyższa najnowsze modele ogólne w zadaniach DQL – nie dlatego, że jest większy, lecz dlatego, że ma głęboki kontekst domeny. Tymczasem Wolfgang pokazał, że ten sam efekt można osiągnąć bez fine-tuningu w ogóle: przez Environment Aware queries, semantic index i resources/instruction files. Innymi słowy: kontekst pokonuje moc obliczeniową. Model nie musi być mądrzejszy, musi wiedzieć więcej o konkretnym środowisku użytkownika.

Dlaczego to jest istotne: większość organizacji szuka odpowiedzi na pytanie „który model wybrać?” lub „czy stać nas na najdroższy wariant?”. To pytanie jest postawione odwrotnie. Właściwe pytanie brzmi: „jaki kontekst jesteśmy w stanie dostarczyć dowolnemu modelowi?” To drugie pytanie jest tańsze, szybsze i w pełni pod kontrolą organizacji.

Test na jutro: następnym razem, gdy AI nie rozumie Twojego zapytania o własną infrastrukturę, zamiast szukać mocniejszego modelu przygotuj plik tekstowy z opisem 10-15 najważniejszych niestandardowych nazw, metryk i zależności w Twoim środowisku, dołącz go jako kontekst do zapytania i sprawdź, czy różnica w jakości odpowiedzi jest większa niż przy zmianie modelu.

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj: Dynatrace Intelligence AMA – LinkedIn

Tag: Ai Autonomy Observability

Dynatrace Intelligence: autonomiczny ekosystem agentów AI #EN383