Patrick: Willkommen zurück beim Daedrax Deutschland Podcast. Podcast, in dem wir nicht nur diesmal über KI Agenten sprechen, sondern auch darüber, was den Unterschied macht zwischen einem Agenten, der in der Demo funktioniert und einem, der tatsächlich auch die Produktion überlebt. Heute ist das kein theoretisches Thema, sondern wir wollen versuchen, sehr praktisch zu werden. Wir reden über Sprache, über die Begriffe, die im Moment durch jedes KI Projekt jedes Architekturgespräch, jedes Boardroombriefing spuken und die erstaunlich oft unterschiedlich oder schlicht verstanden werden. Halluzination, Rack, Agent, Harnes klingt Vokabular aus einer Science Fiction Serie, ist aber inzwischen der Alltag in Enterprise KI Projekten. Und wenn zwei Menschen unterschiedliches darunter verstehen, scheitert kein System am Code. sondern am Gespräch. Ich habe heute einen Kollegen dabei, den ich nicht erst groß vorstellen muss. Thomas Haas, Preset Solution Architekt bei uns in Germany Enterprise Team und selbst erfolgreich in Social Media Umfeld. Thomas betreibt ein YouTube Kanal, in dem er exzellente Tutorial Videos zu unterschiedlichen Deadwax Themen zur Verfügung stellt. Den Link zu dem YouTube Kanal von Thomas, den stellen wir natürlich in die Podcasts los, damit ihr euch die auch anschauen könnt, falls ihr sie noch nicht kennt. In seiner Hauptaufgabe ist er aber auch in Gesprächen, in denen diese Begriffe, über die wir heute reden wollen, auf den Tisch kommen. Thomas, bevor wir einsteigen, womit kommen Kunden gerade auf dich zu und wie oft ist Agent das Wort, das sie mitbringen, ohne dass beide dasselbe meinen?

Thomas: Sehr gerne. Hi, erst mal Patrick. Danke für die Einladung und danke für den YouTube-Shoutout. Danke schön. Danke schön.

Patrick: Wohl verdient.

Thomas: Wie du schon richtig erkannt hast, kommt das Thema Agent gefühlt in jedem zweiten Gespräch vor mit unseren Kunden. ist natürlich auch top priority von oben hinweg und wird auch oft unterschiedlich interpretiert. Wenn wir jetzt erst mal auf die Use Cases schauen. Meiner Meinung nach ist der Nummer 1 Use Case für Agents immer noch Coding. Das heißt, ich nutze einen Agent wie beispielsweise Claude Code, Programmcode zu schreiben. Auch in Databricks selbst, beispielsweise mit Genie Code, aber auch in anderen Programmen sieht man ja überall die ganze Coding Assistance, die man durch Agents kriegt. Und das ist der Nummer 1 Use Case, weil er einfach sehr gut funktioniert, weil er viel Business Value bringt, in dem Use Cases schneller implementiert werden können. oder Kosten eingespart werden können. Abgesehen vom Coding haben sich aber jetzt gerade in den letzten Jahren auch noch ein paar andere interessante Use Cases entwickelt. Vielleicht so ein bisschen die Weiterentwicklung von dem klassischen Chatbot, den man so gerade die ersten Jahre mit ChatGPT und Co. gesehen hat, ist vielleicht so was Richtung Field Service Assistant, also ein Techniker, beispielsweise ein Aufzugtechniker. oder einen Turbintechniker, der quasi vor Ort seinen Agent parat hat, der einem dann Hints geben kann, was dann vielleicht basierend auf den Daten, basierend auf den Errorcodes der Fehler sein könnte, der aber auch, und das ist so ein bisschen der Shift in Richtung Agents auch, der dann auch aktionenlos triggern kann, also der irgendwie auch Datenbanken abfragen kann, der gewisse Sachen ordern kann und Co. Das ist ein Key Use Case, den wir sehen. generell viel, natürlich auch Richtung Reasoning. Also immer wenn ich quasi eine Root Cause Analysis machen will, wenn ich verstehen will, warum meine Sales jetzt gedroppt sind, das ist so ein klassischer Use Case. Im Retail Sektor, wo ich viel unterwegs bin, sehen wir gerade den Voice of Customer Agent ziemlich oft. Das ist quasi die ganzen Impressionen der Kunden, das heißt irgendwelche Reviews, Kommentare und so weiter von Social Media. von den Wholesalern und so weiter aggregieren, sammeln und dann daraus quasi abzuleiten, was vielleicht Product Gaps sind. Also sei es jetzt allein auf die Delivery bezogen, die irgendwie oft als schlecht bezeichnet wird, sei es jetzt irgendwelche Schuhe, die in der falschen Größe geliefert werden, die nicht matchen. Das ist noch ein so typischer Use Case. auf deine zweite Frage einzugehen, was denn überhaupt Agent, als Agent gilt und als Agent definiert wird. Ich glaube, das ist auch sehr unterschiedlich und hat sich auch geändert. Also anfangs, würde ich sagen, vor rund drei Jahren war ja er ein Agent, ein LLM plus eine Aktion. Also ein LLM, das Aktionen ausführen kann, wie jetzt ein Ticket erstellen, beispielsweise. Ich habe das Gefühl, mittlerweile in vielen Kundengesprächen wird alles Agent genannt, also auch wenn ich einfach nur ein LLM quasi aufrufe. Ohne jetzt irgendwelche Tools, Skills und all die Terms, über die wir später noch sprechen, wird auch schon oft als Agent bezeichnet. also so bisschen unterschiedlich für mich persönlich ist es immer, wenn der Agent selbst auch irgendwelche Aktionen ausführen kann, Daten abfragen kann, Files erstellen kann und co. Das ist für mich in meiner Definition zumindest ein Agent.

Patrick: Super. Vielen Dank für diese Eingrenzung. Das ist auch ein sehr guter Ausgangspunkt. Für unsere Zuhörer möchte ich euch ganz kurz erklären, was wir jetzt dann im Folge dieses Podcasts vorhaben. Wir wollen versuchen, uns ein konkretes Szenario zu nehmen. Ein KI-Kopiloten für Data Engineering in einem Enterprise-Unternehmen und gehen durch die Begriffe, die in diesem Szenario wirklich auftauchen. versuchen auch zu erklären, was sie dann wirklich bedeuten. Also keine Vorlesungen, kein Glossar abarbeiten, sondern nah an der Realität bleiben. Wir folgen dem Weg, den so ein System von der Idee bis zur Produktion nimmt und wo ein Begriff in der Realität ein Missverständnis produziert hat, da sagen wir das dann auch. Thomas, ich fange mit dem Begriff an, vor dem ich die größte Angst in Kundengesprächen erlebe. Halluzination.

Thomas: Ja, das höre ich auch sehr oft. Ich glaube, jeder hat es schon selbst auch erlebt, wenn er irgendwie seinen Chat-GPT fragt nach einem Fakt beispielsweise und dann die Antwort super solide klingt und logisch klingt, aber faktisch eben falsch ist. Also eine Halluzination heißt einfach, das Modell produziert sachlich falsche Aussagen. Das kann unterschiedliche Gründe haben, warum es dazu kommt. Ich denke, ein Grund ist auf jeden Fall, der Hintergrund, wie LLMs selbst gebaut sind. Ende des Tages sind es statistische Mustererkennungsmaschinen. Das heißt, das LLM versucht, den nächsten Token oder das nächste Wort zu predikten, vorauszusagen. Und da quasi logisch klingende Sätze zu bilden, basierend auf den ganzen Trainingsdaten. Dann kann es eben dazu kommen, dass faktisch falsche Informationen entstehen. Das ist auch so, das lässt sich natürlich optimieren und so weiter, aber am Ende des Tages lässt sich das nicht vollkommen vermeiden. Ich glaube, was viel wichtiger ist, ist in der Diskussion zum einen, wie häufig kommt das vor, also was ist die Frequenz? Man will natürlich nicht in jeder seiner zweiten Frage Halluzinationen drin haben. Und viel wichtiger noch, was ist die Konsequenz davon? Weil das auch so bisschen dann den Use-Case definiert, der vielleicht passend ist aktuell für Agents und was vielleicht noch nicht passend ist. Also wenn ich jetzt beispielsweise irgendeine E-Mail schreibe oder einen Blogartikel schreibe und dafür AI nutze und Agents nutze, dann kann ich vielleicht die Halluzination selbst noch spotten, dann kann ich vielleicht Anpassungen machen. Im schlimmsten Fall habe ich halt einen faktisch nicht ganz korrekten Blogartikel. Das ist aber so ein bisschen anders, wenn ich jetzt irgendwie einen Medizin-Assistent-Agent baue, der mir irgendwelche Empfehlungen gibt. Dosierungen. Da ist es natürlich kritischer, wenn da dann irgendwelche Halluzinationen entstehen und dann der Patient danach handelt und es dann irgendwelche gesundheitlichen Konsequenzen haben kann.

Patrick: Ja, diese Situation und diese viel Halluzinationen, kennen wir natürlich. Was ich schon erlebt habe ist, sobald dieses Wort im Kundengespräch fällt, dann schießt die virtuelle Hand des z.B. Chief Risk Officers hoch, der sagt, also dann können wir das nicht deployen und in Produktion nehmen. Was sagst du dazu?

Thomas: Ja, wie gesagt, ich denke, es kommt halt auf den Use-Case an und wie kritisch das ist. man sollte viel weniger an Go oder No-Go quasi denken, sondern sich so bisschen an der Halluzinationsrate orientieren. Also es gibt ja gewisse Metriken und Ewals, über die wir später auch sprechen, die das quasi messen können. Also ich kann dann quasi mein Output danach nochmal reviewen und kann umschauen, einen Check vorweg zu nehmen, zum Beispiel prüfen, stimmt der Output jetzt mit dem überein, was der Agent als Kontext bekommen hat, oder ist das auch schon fehlerhaft? Und dafür kann ich auch wieder LLMs beispielsweise verwenden. viel weniger, was ich da quasi antworten würde, wäre weniger in den Terminologien zu sprechen, deployen oder nicht deployen. sondern was sind denn die Anforderungen, wie viel Halluzination kann vielleicht durchgehen, ohne jetzt massiven Impact daraus zu haben quasi. Generell sind es ja so ein paar Dinge, die man steuern kann. E-Well-Abdeckung habe ich schon so bisschen angeteasert, werden wir später noch drüber sprechen. Es gibt ja bei den ganzen Modellen auch so eine Temperatureinstellung, die man machen kann. Das heißt einfach, inwieweit soll sich das LLM quasi auf die statistisch wahrscheinlichste Output-Variante entscheiden und wie viel Spielraum soll da sein. Gerade wenn man vielleicht irgendeinen Use-Case hat, in Richtung Kreativität geht, macht es vielleicht Sinn, das hochzusetzen, was dann aber zu mehr Halluzination führen kann. Wie gesagt, Messbarkeit ist da so ein bisschen der Schlüssel meiner Meinung

Patrick: Das würde ich wirklich gerne kurz unterstreichen, ich das auch in Kundengesprächen manchmal verdreht höre. Kein Sprachmodell, keine Plattform und kein Vendor kann Halluzinationen vollständig eliminieren. Und es aber wichtig, dass es keine Schwäche eines bestimmten Anbieters oder eines LLMs, das ist der aktuelle Stand der Technik. Und wer irgendwas anderes behauptet, der, ich möchte jetzt nicht sagen, lügt. Aber der lehnt sich schon mal ziemlich weit aus dem Fenster heraus. Was Plattformen aber liefern können, ist die Messbarkeit und Steuerbarkeit. Das Ziel ist eben nicht Null Fehler, sondern Ziel ist messen, wie wir es sehen. Wir müssen die Schwelle kontrollieren können. Thomas, woran erkennst du, dass ein Team diesen Reifegrad erreicht hat.

Thomas: Ja, das ist eine gute Frage. Die ist aber, glaube ich, ziemlich einfach beantwortet. Wenn ich von einem Team höre, beispielsweise, sie haben irgendwie was am Prompt gemacht oder sie haben irgendwie ihre Wissensbasis erweitert und haben dann eher so das Bauchgefühl, der Agent ist besser geworden, aber haben quasi keine standardisierte Lösung, diese Halluzinationsraten beispielsweise zu checken oder generell Agentenqualität zu checken und keine Testcoverage quasi haben. Da können wir vielleicht später auch noch mal drauf eingehen, wie teste ich eigentlich Agents, wie billig dieses Evaluation-Data-Set und so weiter auf. Ein Team, das sich damit beschäftigt bei der Agent-Entwicklung, die gehen meiner Meinung nach den richtigen Weg.

Patrick: Okay, gut, dann gehen wir zur physikalischen Grundlage. Bei Halluzination, Herate, Grounding, Retrieval, alles was wir gleich besprechen, davon abhängt, was der Agent überhaupt sieht, wenn er arbeitet. Begriff Kontextwindow. Was ist das wirklich?

Thomas: Ja, gerne. ist zum einen mal extrem relevant für die Outputqualität von dem Agenten, das Context Window zu berücksichtigen. Wenn wir uns jetzt ein paar Jahre zurückblicken, gerade wenn als die ersten GPT-Modelle beispielsweise rauskamen, da war das Context Window noch ziemlich klein. Context Window heißt einfach alles quasi, was der Agent sieht. Man könnte die Metapher nehmen mit ... Mit einem Schreibtisch quasi alles, auf dem Tisch liegt, kann der Agent sehen und nutzen. Was dann aber irgendwie außerhalb im Aktenschrank oder irgendwo anders liegt, sieht der Agent nicht. Das heißt, auch die Anfragen an meinen Large-Language-Model, wenn ich jetzt Chat GPT quasi nutze, neuen Tab aufmache, dann sieht er quasi nur, was ich da reinschreibe. Und dann dazu kriege ich den Output. Wenn ich eine neue Session aufmache, dann hat mein Agent keine Ahnung mehr. was die andere Session quasi behandelt hat im normalen Stil. Natürlich gibt es auch Möglichkeiten, über die wir später noch sprechen, Richtung Memory. Früher war es so, dass diese Context Windows extrem klein waren. da die früheren GPD-Modelle hatten so 30.000 Tokens beispielsweise. Mittlerweile ist es schon deutlich höher. Also die ganzen Frontier-Modelle haben eher so eine Million Tokens. Und... Viel dreht sich natürlich darum, wie ich das Ganze optimiere, dass die relevanten Infos immer in diesem Kontext quasi landen. Aber es ist eben kein unendlicher Kontext. Man ist immer beschränkt auf diesen Kontext, was sieht der Agent, und darum herum kann ich eben viele Optimierungen machen, meine Accuracy am Ende des Tages zu steigern und meine Hallucination Rate quasi zu senken.

Patrick: Du hast gerade gesagt, dass das Kontext-Window nach jedem Gespräch, wenn einen neuen Tab öffnest oder die Session beende, leer gewischt wird. Der Schreibtisch wird aufgeräumt. Ist das aber auch selber den Begriff Agent Memory gerade reingebracht? Ist das dann nicht doch irgendwie dasselbe?

Thomas: Ja, also das spielt zusammen, genau. Also meine Aussage hat sich darauf bezogen, wenn ich jetzt beispielsweise einen rohen LLM-Call mache. Also wenn ich jetzt einfach nur über die API beispielsweise eine Chat-GPT-Modelle anspreche mit einem Prompt und dann einen weiteren Call mache, dann wird das leer geräumt. Was ich natürlich machen kann, ist mir so ein Agent-Memory aufzubauen und das machen auch viele, viele Frameworks, da gibt es unterschiedliche Lösungen für. dass dann unterschiedliche Informationen persistiert. Ja, also es gibt ganz unterschiedliche Arten von Agent Memory. Die einfachste Art, die, glaube ich, auch jedem bekannt ist, ist, dass ich einfach innerhalb von einem Chat auch schon Followerabfragen stellen kann. Da ist ja auch ein Memory-Mechanismus dahinter. Also wenn ich jetzt eine Frage in einem Thread in Chat-GPT schreibe und danach eine Folgefrage stelle, dann weiß der Agent ja auch, was ich da vorgefragt habe. Da wird quasi... die ganze Conversation History mitgegeben. Wenn es jetzt eher so Memory-Session übergreifend und so weiter geht, dann gibt es auch unterschiedliche Lösungen auf dem Markt, die Sachen irgendwie rauszuschreiben in Datenbanken, in Markdowns und so weiter. Es geht aber immer darum, quasi diesen Agent Memory, der relevant ist für die aktuelle Frage, in das Context Window reinzubringen. Also die beiden Themen spielen quasi zusammen. Ich brauche auf jeden Fall Memory, Ergebnisse über eine Session hinweg zu haben, die persistent sind und die logisch sind, basierend auf den ehemaligen Fragen.

Patrick: Okay, das heißt, wenn ich jetzt auf dein Schreibtischbildnis zurückgehe, ist es dann korrekt, ich sage, das Kontext-Window ist der Schreibtisch. Agent Memory ist ein Notizbuch, das ich habe und ich entscheide, welche Seiten aus diesem Notizbuch auf den Schreibtisch kommen, wenn ich eine neue Interaktion mit dem Agent starte.

Thomas: Ganz genau, das ist eine sehr gute Metapher. Und ich würde vielleicht noch mal einen Schritt weitergehen und noch mal einen Begriff in den Raum werfen, weil der Begriff gerade auch brandaktuell ist in allen Kundengesprächen, und zwar Context Engineering. Das ist ja quasi die Kunst dann am Ende, die richtigen quasi auf den Tisch zu bringen. Also wenn ich jetzt mein Notizbuch irgendwo außerhalb von meinem Schreibtisch liegen habe, welche Seiten bringe ich dann tatsächlich rein? Wenn ich auch vielleicht Tausende von Seiten habe, wie fasse ich die vielleicht erstmal zusammen und auch welche Wissenstiefe bringe ich quasi mit rein. haue ich mir quasi einfach nur meine gesamte History rein oder haue ich mir lieber die Metadaten in das Context Window über das Gespräch beispielsweise. Also das ganze Thema Context Engineering ist extrem relevant für die Qualität. Also auch beispielsweise der Databricks-CEO hat das auch bei der Data-NEI Summit gesagt, dass das Hauptproblem für effektive Agenten ist der Kontext. Und da Kontext Engineering quasi genau die Thematik, die sich damit beschäftigt. Wie designe ich mein System, dass die richtigen Informationen zur richtigen Zeit in das Kontext-Window von dem Agenten landen.

Patrick: Okay, vielen Dank für die Erklärung. Das beantwortet für mich aber noch nicht, woher das Wissen denn überhaupt kommt, das auf den Schreibtisch gelegt wird. Der Agent kennt ja nicht von Haus aus meine internen Company Policies, die Datenschematar, die Dokumentation. Hier kommt dann ja Rack als neuer Begriff ins Spiel. Hast du dafür eine gute Metapher?

Thomas: Ja, gerne. Genau, REC steht ja für Retrieval Augmented Generation. Das Problem ist folgende, was REC auch versucht zu lösen. Und zwar wurden die ganzen LLMs ja auf einem riesigen Datensatz gespeichert, der aber quasi Public Knowledge ist, also auf den ganzen Internetdaten beispielsweise. Mein Agent weiß ja jetzt nicht out of the box, was meine internen Policies beispielsweise sagen oder was mein internes Jargon ist für einen gewissen Begriff. Und da kommt REC eben ins Spiel, steht für Retrieval Augmented Generation, wie gesagt, und funktioniert technisch so, dass ich im ersten Schritt mir meine internen Dokumente zusammenhole, also meine PDF-Files beispielsweise zu irgendwelchen Policies, und die dann in Vektoren quasi transformiere und abspeichere. Da kommt auch der Begriff Vector-Datenbank her, da gibt es eine Lösung von Databricks, gibt es ganz viele andere Lösungen auch. Und was diese Vektordatenbanken quasi machen, wie der Name schon sagt, speichern dann den Text aus dem ursprünglichen Dokument in Vektoren ab. Warum macht man das? Der Grund ist, dass man dann auf Basis dieser Vektoren eine semantische Suche durchführen kann. Das heißt, ich frag irgendwie meinen Chatbot nach, was sind die Holiday Policies bei Databricks? Kann ich mir einfach mal so drei Wochen freinehmen oder gibt es da irgendeinen Prozess für? Dann würde mein System quasi diese Vektor-Datenbank, also mein Agent würde diese Vektor-Datenbank abfragen und natürlich will ich jetzt wieder nicht alle meine zigtausenden Dokumente in dieses Kontext-Window laden, sondern es würde mir nur diesen Schnipsel aus meinen Dokumenten zurückgeben durch diese semantische Suche basierend auf den Vektoren und die dann in den Kontext-Window mit einfügen, sodass ich dann eine Antwort bekomme von meinem Agenten, die dann auch faktisch korrekt ist, basierend auf dem Dokument, das quasi retrieved wurde. Man sagte auch, die Antwort ist grounded quasi oder geerdet. Und so funktioniert ein REC System. REC ist nicht die Lösung für alles, aber es gibt auch viele andere Ansätze, die mit Skills beispielsweise gelöst werden, wo wir, glaube ich, später noch darauf eingehen werden.

Patrick: Jetzt hast du gleich den neuen Begriff eingeführt mit grounded oder geerdet. Das ist etwas, ich oft von Kunden auch höre, die dann einfach sagen, wir haben REC, also sind wir geerdet, gegrounded. Ist das so nonöbar? Ist das das gleiche? Ist das richtig so?

Thomas: Also das würde ich so nicht unterschreiben, dass nur der Fakt, dass man ein Rack-System hat, bedeutet, dass man gegroundet ist. Grounding bedeutet viel eher und da gibt es auch unterschiedliche Ewals für die genau diese Retriever Groundedness checken von einem Rack-System. Das heißt quasi der Agent gibt eine logische Antwort basierend auf dem Kontext, er bekommen hat. Aber wenn jetzt natürlich beispielsweise die das RUG-System selbst, also diese semantische Suche, schon die falschen Dokumentschnipsel geliefert hat oder die Antwort, die ich brauche, gar nicht da drin steht. Dann habe ich quasi eine Antwort, die gegroundet sein kann in den Dokumenten, die ich bekommen habe, aber die Dokumente selbst konnten ja die Frage gar nicht beantworten. Also ich würde jetzt nicht gleichstellen mit, ich habe ein grounded System zwingendermaßen mit, ich habe die richtigen Antworten. Da gibt es noch viele andere Metriken und Co., die man sich da anschauen kann.

Patrick: Okay, prima. Jetzt haben wir Kontext, Wissensbasis, Grounding als Qualitätsziel. Jetzt wollen wir den Agenten in Aktion sehen. Was passiert, wenn dieser Data Engineering Co-Pilot eine Anfrage...

Thomas: Ja, da passieren mittlerweile ganz viele Sachen, bevor es zur Antwort kommt. Also, ich erinnere mich noch ganz an den Anfang von Chatchie Pity & Co. Da war es ja oft so, man hat eine Frage gestellt und hat direkt eine Antwort bekommen. auch gerade so komplexere Systeme, die waren da eher schwieriger umzusetzen. Was heutzutage ein extrem wichtiges Thema ist, ist diese agentic loop. Das heißt, ich designe einen Agent, der, bevor er mir die Frage beantwortet, erst mal sich den gesamten Kontext anschaut, dann einen Plan macht, dann diese Aktion gegebenenfalls durchführt. Jetzt mit einem konkreten Beispiel von einem Data Engineering Agent. Ich gebe die Anfrage, dass ich eine Spark-Declarative-Pipeline implementieren möchte, die meine Daten cleanen und Historization macht. Was dann diese Agentic Loop quasi macht in diesem Agenten ist, Sie sammelt sich erstmal die ganzen Infos über die Daten, die ich Zugriff habe, die Daten, relevant sind für diese Anfrage, implementiert dann den Code und führt beispielsweise das Notebook aus oder führt das Python-File aus und prüft dann quasi das Ergebnis. Und wer schon viel mit Coding-Agents gearbeitet hat, der weiß, dass sehr oft quasi die erste Ausführung nicht korrekt ist, weil irgendwelche Syntax-Fehler drin sind oder weil der Agent irgendwas falsch verstanden hat. Was aber diese Agents loop dann auch macht, ist, sich den Output anzuschauen, die Fehlermessage gegebenenfalls sich anzuschauen und dann nochmal quasi diese Loop zu durchlaufen. Okay, jetzt habe ich neuen Kontext, ich habe die Fehlermeldung, ich mache die Anpassungen am Code, die Aktion wieder aus und prüfe dann wieder das Ergebnis, bis ich zum richtigen Ergebnis komme, quasi.

Patrick: Okay, das ist ja schon ziemlich komplex und mächtig, was da passiert. Wenn wir da weitergehen in den Fragen und Begrifflichkeiten, was ich sehr regelmäßig aus Security oder Legal Teams höre oder als Frage bekomme, ist, was darf der Agent anfassen? Das ist Compliance-Frage, oder?

Thomas: Ja, ich würde es mal so definieren. Was darf der Agent anfassen? Es kommt ja immer auf die Tools an oder die Möglichkeiten, die der Agent hat. Also wenn ich jetzt einfach nur ein LLM habe, kann das erstmal einfach nur quasi die Common Knowledge, die das LLM hat, abfragen. Ich selbst als AI-Engineer, der den Agent entwickelt, definiere ja quasi, was ist der Scope von diesem Agenten. Das heißt, ich definiere selbst, welche Tools hat der Agent. Darf der beispielsweise Unity-Katalog-Tabellen abfragen? Darf der irgendwie meinen Jira updaten und so weiter und so fort? Das heißt, es gibt diese explizit definierten Schnittstellen, die Tools quasi genannt werden, Agent Tools, die ich meinem Agenten zur Verfügung stelle. Und dazu kommt ja auch noch, dass ich als AI-Engineer, der den Agenten entwickelt, auch definiere, wie denn das Security-Modell dahinter ist. Also hat der Agent quasi einen eigenen technischen User, der dann die ganzen Aktionen ausführt oder ist es quasi on behalf of user. Also wer auch immer den Agenten nutzt, dessen Permissions und dessen Identity wird dann genutzt, die ganzen anderen Schnittstellen aufzurufen. Und da sehen wir halt oft in Kundengesprächen, dass beispielsweise Schreibrechte eher nicht gegeben werden dem Agenten und Leserechte vielleicht hingegen schon, gerade bei Jira zum Beispiel. Da gibt es aber auch viele neue Innovationen aktuell, dass man quasi nicht einfach nur auf die einzelne Aktion vom Agenten guckt, also der darf jetzt was machen oder darf es nicht machen, sondern eher so Context Policies definiert, also basierend auf dem, was der Agent davor gemacht hat. dafür gewisse Aktion machen und andere wiederum nicht. Also das ist auch ganz, ganz spannend, wie sich da das Thema weiterentwickelt.

Patrick: Okay, ich merke die Komplexitätsrate steigt. Im Zusammenhang mit Tools fällt jetzt ja auch, nicht erst seit gestern, sondern gefühlt erst vorgestern, sehr oft jetzt auch der Begriff MCP oder MCP Server. Was genau steckt dahinter und wie hängt das mit Tools im Agentenumfeld zusammen?

Thomas: Ja, das ist ein offener Verwirrungspunkt auch in Kundengesprächen. Also MCP steht hier für Model Context Protocol. Das ist quasi ein offener Standard, der von Entropic, meine ich, entwickelt wurde. Oft wird das Beispiel genannt, das finde ich, habe ich jetzt schon bisschen zu oft gehört, aber es ist trotzdem eigentlich ziemlich gut. Also der Das MCP-Protokoll ist wie so USB-Standard quasi. Und alles, ich dann in meinen Agenten, wenn der der Laptop ist, reinplugge, sind quasi unterschiedliche MCP-Server. Was dann der MCP konkret macht, ist, es ist ein Server, wie der Name schon sagt, und der wird meistens dafür verwendet, andere Systeme standardisiert anzubinden. Das heißt, ich hab jetzt meinen Agenten, der hat erst mal nur sein LLM vielleicht und eine REC-Komponente, der soll jetzt ein Jira-Ticket updaten. Dafür die Alternative ohne MCP wäre, ich gebe dem einfach die gesamte API-Definition von Jira. Da ist das Problem, je nach System habe ich komplett andere API-Schnittstellen und das wäre auch wieder zu viel Arbeit für den Agenten selbst, erst mal rauszufinden, was da überhaupt möglich ist, wie er da vorgehen soll und so weiter. Ein MCP-Server gibt quasi vorgefertigt zum einen die Möglichkeit, die ganzen Tools zu listen, also da auch die Schnittstelle zwischen Tool und MCP Server, die ein MCP bereitstellt. Also im Beispiel von Jira könnte dann ein Tool quasi sein, erstelle ein Jira Ticket oder update ein Jira Ticket. Das sind dann die Tools, die dann tatsächlich im Hintergrund die API Calls machen, aber der MCP Server selbst stellt dem Agenten quasi nur diese ganzen Tools bereit, die es gibt und der MCP Server selbst führt dann die APIs und den Code und die Tools selbst aus. Das ist quasi einfach, diese gesamte Agent-Architektur ein bisschen zu vereinheitlichen und bisschen Komplexität rauszunehmen, dass man diese einheitlichen Schnittstellen hat, quasi über MCP Server.

Patrick: Okay, aber dann nochmal das klar zu stellen oder sicher zu stellen. Der MCP Server ist nicht ein drittes System, das ich irgendwo deploye und laufen lasse, sondern mehr eine Funktionalität in deinem Beispiel von Jira, das Jira bereitstellen muss. Und wie gesagt, nicht eine dritte Instanz wie in den frühen Zeiten ein Enterprise Service Bus oder irgendwas. was ich noch zentral irgendwo deployen, managen und betreiben muss.

Thomas: Genau, also oft stellen halt die, gerade die großen Vendoren stellen halt ihre eigenen MCP-Server bereit und hosten die. Wenn das nicht der Fall ist, könnte ich natürlich auch meinen eigenen MCP-Server irgendwie auf meiner eigenen Infrastruktur hosten und da diese ganze Logik mit den Tool-Retrieval, Tool-Execution und so weiter implementieren. Aber in der Regel genau stellt das ein Jira oder Atlassian oder Salesforce und Co. haben alle ihre eigenen MCP-Server. die Sie hosten bereitstellen und ich knüppsel dann einfach nur meinen Agenten da dran quasi.

Patrick: Okay. In dem ganzen Themenbereich taucht auch noch ein weiter Begriff auf, den ich gerne abgrenzen möchte. Skills. Ist das nur ein anderes Wort für Tools?

Thomas: Ja, das ist ebenfalls ein großer Verwirrungspunkt, also gerade die Zusammenspieler, Tools, MCP und Skills. Skills ist nochmal ein bisschen anders. Skill ist eigentlich mega simpel, das ist einfach nur, kann man sich vorstellen, eine Textdatei. Meistens ist es dann so ein bisschen strukturiert als Markdown-Datei, die einfach nur quasi eine eine gewisse Prozedur oder einen Ablauf beschreibt als Text oder best practices beschreibt. Wenn wir jetzt zurückgehen zu unserem Beispiel von dem Data Engineering Agent beispielsweise. Der hätte dann vielleicht ein Skill, wie ich idealerweise beispielsweise slowly changing dimensions in Databricks implementiere. der Skill würde dann so aussehen, der hätte einen Namen best practices, historization beispielsweise. Der Text wäre eine Beschreibung, wie ich das am besten mache. Inklusive vielleicht Codeschnipsel oder inklusive Tools. Da ist das Zusammenspiel, die ich verwenden sollte, diesen Ablauf quasi End-to-End auszuführen. gleich noch mal zusammenzufassen, Skill einfach nur eine Textdatei oder Markdown-Datei, die einen Teilprozess beschreibt. Die Datei kann dann wiederum auf Tools verweisen, die genutzt werden sollen, dieses Ziel zu erreichen, wie beispielsweise eine Spark-Declarative-Pipeline zu erstellen.

Patrick: Okay, sehr gut. Ich würde das tatsächlich noch bisschen aus meiner Sicht ergänzen wollen. Also der Agent ist nicht autonom im Sinne von tut, was er will. Er tut, was man ihm erlaubt. Das sind wir jetzt ja, glaube ich, einig. Das ist wichtiger Satz, den sich hauptsächlich die Zuhörer, die mehr im Legalbereich arbeiten, bitte merken sollten. Kein Freifahrtschein, so ein Agent, der macht was er will. Jetzt noch zu einer anderen Aussage, bei der ich noch letzte Woche einen Architekten im Kundengespräch kurz den Kopf schütteln gesehen habe. Nicht das Modell entscheidet über die Performance des Agenten. Was meinst du dazu?

Thomas: Ich würde es nicht ganz so scharf formulieren. sage mal, das Modell macht natürlich einen Unterschied, ob ich jetzt mega kleines Modell oder das neueste Frontier-Modell verwende. ich glaube, worauf der Architekt so bisschen hinaus wollte, ist, dass es ja noch viel mehr drum herum gibt, die Qualität der Antworten zu steigern. Man kann sich das ja so bisschen vorstellen, wir jetzt die Metapher nehmen, beispielsweise mit einem Formel 1 Auto. Da ist quasi das LLM selbst, also das Modell selbst, ist das Triebwerk oder das Brain quasi dahinter. Aber es gibt ja noch viele andere Komponenten. Was ist das Getriebe? Wie funktioniert die Lenkung? Wie funktioniert das Bremsen? Cockpit? Wie groß ist der Tank und so weiter? Und ähnlich ist es bei Agenten. Und da fällt quasi das Wort Harness, das zu beschreiben. Also alles quasi was den Agenten, das LLM drum herum noch aufgebaut ist. Das heißt, vordefinierte Tools, Memory, also eingebaute Memory, worüber wir vorher schon gesprochen haben, wie mache ich Retries, wie mache ich das Loop Engineering, wie mache ich das Context Engineering, also die beiden Begriffe, die wir vorher schon betrachtet haben, die sind auch Teil dieser gesamten Harness, was dann quasi als Endprodukt an den Nutzer gegeben wird. Und da würde ich mal von ausgehen, wollte der Architekt drauf hinaus, dass es noch viel drum herum gibt. Und gerade auch in der Forschung, glaube ich, beschäftigen sich sehr viele, wie sie dieses Drumherum optimieren und wie groß ist dann tatsächlich der Impact von dem Modell selbst.

Patrick: Okay, jetzt unser Databricks Summit ist ja nicht so lange her in San Francisco. Da wurde Omnigent vorgestellt und in dem Kontext auch ein damals für mich neuer Begriff MetaHarness. Was ist das jetzt schon wieder?

Thomas: Also ich hab das Gefühl, es klingt immer alles komplexer, als es tatsächlich dann ist. wir haben ja gerade die Harness besprochen. Also das ist quasi das Endprodukt eines Agenten mit allem drum herum, mit Memory, mit Context Engineering, mit Loop Engineering. Ein Endprodukt quasi. Wenn man sich jetzt im Coding Bereich umschaut, gibt es ja quasi Claude Code oder Codex beispielsweise. Das sind zwei Beispiele für eine Harness. Was aber quasi gerade so bisschen in der Industrie aufkommt, ist, dass ich manchmal mit unterschiedlichen Harnesses arbeiten möchte. Gerade beispielsweise das Team bei Databricks, die Engineers bei Databricks. Die haben in den letzten Monaten ein Workflow etabliert, dass sie quasi Cloud Code nehmen für die Entwicklung und die Entropic-Modelle, also die Harness quasi dafür genutzt wird. Die nehmen dann aber wiederum Codecs mit GPT-Modellen, den Code zu reviewen von Cloud Code. Die haben dann das Problem, ich muss jetzt die ganzen Infos aus der einen Harness in die andere bringen. Und da ist so bisschen die Idee dieser Meta-Harness entstanden, dass ich quasi nochmal eine Schicht drüber habe und dann quasi eine Meta-Harness definieren kann, die dann einen Workflow hat, wie der, den ich gerade beschrieben habe. Code immer mit Cloud Code und nutze Entropic Modelle und mache immer die Review in Codex. mit den GPT Modellen beispielsweise und alles quasi in einem Package ohne das nervige Hin und Her Kopieren quasi zwischen den unterschiedlichen Harnesses.

Patrick: Okay, dann kann ich das ja wahrscheinlich auf beliebig viele Agenten und Modelle hochskalieren. Entstehen da nicht Kosten, die ich nicht mehr überblicken kann? Ist das so Bereich,

Thomas: Ja.

Patrick: wo etwas wie von Databricks Unity AI Gateway ins Spiel kommt?

Thomas: Genauso Kosten, topaktuelles Thema bei allen Kunden aktuell. Und da kommt eben das Thema auf mit dem Gateway. Also ich will irgendwie einen zentralen Entry Point haben, wo alle meine Modellzugriffe quasi reingehen. Einen zentralen Proxy, das ist dann dieses AI Gateway. Wie du schon richtig gesagt hast, gibt es da von Databricks die Lösung. Es gibt auch ganz viele andere Gateways da draußen. Und dieses Gateway ist dann dafür da zum Eideln die Kosten. in Übersicht zu behalten. Das ist also ein Feature, das die meisten Gateways haben. Dadurch, dass ja alles getrackt wird, weiß man wie viele Tokens gehen rein, wie viele gehen raus und daraus lässt sich dann errechnen, wie die Kosten sind. Gateways haben oft noch andere Funktionalitäten, also Rate Limiting beispielsweise. Vielleicht will ich meinen LLM jetzt davor schützen, dass zu viele Anfragen reinkommen. Fallbacks auch ein wichtiges Thema, also gerade mit den Kapazitätsengpässen, die manche Modelle haben. dass es dann automatisch quasi rüber routet zu einem anderen Fallback-Modell. Und all das hilft quasi generell auch der der Governance für AI-Systeme.

Patrick: Klingt nach einer Aufgabe oder einem Posten, der irgendwo einen FinOps Verantwortung finden sollte, oder?

Thomas: Genau so sollte es sein, so sehen wir es auch bei fortschrittlichen Teams. AI Gateway ist quasi wo die KI Infrastruktur und die Kostenkontrolle dann zusammen wachsen.

Patrick: Okay, dann könnte man ja sagen, dass wir unseren Zuhörern da draußen eine kleine Empfehlung mitgeben können, nämlich frag bei jedem Agentenangebot nicht nur, welches Modell steckt dahinter, sondern frag, wie ist der Harness designed? Kann ich das Modell wechseln und über welchen Gateway läuft das alles? Bring mich direkt zu der Frage, die mir als Manager am häufigsten gestellt wird. von meinem eigenen Team aus Kundengespräch und ehrlich gesagt auch von mir selbst. Wie weiß ich eigentlich, was gut ist? Wie messe ich, und wir hatten das ja schon kurz angesprochen am Anfang, dass wir da reden wollen, ob dieser Co-Pilot das tut, was er soll. Nicht nur in der Demo, sondern optimalerweise auch in der Produktion mit echten Daten, unter echten Bedingungen. Und wie erkläre ich das meinem Compliance-Team dann? Das ist Thema, was wir jetzt im zweiten Blog mal durchgehen wollen. Ewalds, human the loop. und warum das der Unterschied ist zwischen einem System, das ihr intern ausprobiert und einem, das ihr mit gutem Gewissen auch deployen könnt. Thomas, ich stelle diese Frage jetzt sehr direkt, weil sie mir wirklich gestellt wird. Nicht von Architekten, nicht von Data Engineers, sondern von allen Personen im Raum. Vor allem von der, die am Ende die Hand hebt und sagt, ich unterschreibe das hier nicht, bevor ich verstehe, was dieser Agent tut. Thomas, was sage ich dem Compliance-Team?

Thomas: Ja, das habe ich tatsächlich auch schon von einigen Kunden so oder so ähnlich gehört, von deren Compliance-Team. Ich glaube, die Frage ist so ein bisschen im Kern, wer ist verantwortlich, wenn der Agent falsch liegt? Was, also auch noch das andere Thema von vorher, was kann der Agent überhaupt tun? Ich glaube, das haben wir so weit abgehakt, wird selbst definiert. Aber vor allem, wie habe ich diese Kontrolle über die Qualität vom Agenten und wie kontrolliere ich, wenn er falsch liegt? Ja. Und da ist das ganze Thema rund Evaluations extrem wichtig, dass ich quasi einen klaren Prozess habe, die Qualität von meinem Agenten und die Antworten von meinem Agenten zu checken. Da können wir gleich noch mal drauf eingehen, wie das konkret aussehen kann. Und so ein gutes Evaluation-Set hat quasi dann immer zum einen natürlich die meistgestellten Fragen. von einem Endnutzer, wenn es jetzt ein Chatbot Agent ist oder die meistgestellten Szenarien, wenn es jetzt eher ein Autonomer Agent ist. Das ist aber dann wahrscheinlich so der Happy Path. Oft, was man dann noch mit reinnehmen will in dieses Evaluation, das wären natürlich Edge Cases und auch die ganz Bad Cases. Also wenn wirklich jemand versuchen will, den Agenten in irgendeine Richtung zu steuern. Das ist extrem wichtig.

Patrick: Okay, jetzt komme ich persönlich ja mehr aus der Softwareentwicklung und darum drängt sich mir die Analogie zu Unit-Tests auf. Stimmt das so oder ist KI da ein Sonderfall?

Thomas: Das ist ziemlich richtig. Die Evaluation-Tests, die man macht, sind mehr oder weniger Unit-Tests, genau wie kein Software-Team jetzt irgendwie einen Release machen würde, ohne vorher die Test-Coverage zu prüfen. So sollte es auch bei den Agents sein, dass man bei jedem Change, wenn ich einen Prompt update oder wenn ich die Vector-Datenbank update, dass dann quasi mein Evaluation-Data-Set einmal abläuft und dass die Agentenqualität und den Impact vom Change quasi testet. Dafür gibt es beispielsweise in MLflow, das ist ja auch ein Open Source Projekt, viele Evaluation Capabilities, wo es jetzt auch so bisschen Richtung hingeht, ist vielleicht, bei deinem Beispiel zu bleiben, dem Software Engineering, ist vielleicht auch eher Richtung Integration Tests, also dass ich jetzt nicht nur eine Komponente oder eine Abfrage teste, sondern eine gesamte Session oder eine gesamte Konversation evaluiere auf Wie konsistent beispielsweise waren jetzt die Antworten von meinem Agenten?

Patrick: Okay, danke für die Erklärung. ist jetzt ja eigentlich nur die Antwort vor dem Deployment. Ich kenne jetzt aber schon den Anschluss Einwand, den wir von Kunden kriegen, nämlich die Frage, was ist nach dem Deployment? Da kann doch trotzdem noch alles passieren. Wie schließen wir die Lücke, Thomas?

Thomas: Ja, das ist ein valider Punkt. Genauso wie bei anderen Software-Systemen sollte man sich auch bei Agents darum kümmern, was denn nach dem Deployment ist. Human in the Loop ist eine Antwort. Was ich quasi für meinen Live-Agent will, ist zum einen, ich habe ein definiertes Set an E-Walls, die quasi eine gewisse Prozentzahl meiner ganzen Anfragen scanen und bewerten. Also was ich nicht will, ist jede Anfrage quasi evaluieren, weil das vielleicht auch zu viel Rechenleistung, je nachdem, je nach Agent, zu viel Rechenzeit kosten könnte. Was ich eher so als Setup typischerweise hätte, ist, ich habe ein klares Set an definierten Ewals. Das kann dann sowas sein wie Retrieval Groundedness beispielsweise. Also wie konsistent ist die Antwort, basierend auf dem Kontext, den der Agent bekommen hat. Und für die Antworten, die da eben schlecht abschneiden bei diesen Checks, weil diese Checks, sind ja LLM-Checks, das ist quasi ein LLM as a Judge, das selbst die Antworten quasi oder das Review macht. Und die schlechten Antworten kann ich dann quasi rüberrouten zu einem Human in the Loop, was dann üblicherweise ein Subject Matter Expert ist, der sich dann nochmal quasi die Antwort anschaut. und Feedback gibt und das dann quasi als Input geht, den Agenten wiederum weiter zu verbessern. Das ist so die End-to-End Loop, die wir ja üblich sehen.

Patrick: Okay, es gibt ja auch irgendwie Triggerlogik als Begriff, der diesen Kontext umgeistert. Kannst das auch kurz in Kontext bringen?

Thomas: Genau, das ist eigentlich genau das, was ich eben meinte. Die Frage ist halt, wann bringe ich den Human in the Loop mit rein, ab welcher quasi Fehlerrate. Wenn

Patrick: Okay.

Thomas: ich jetzt einen Agenten habe, eine Million Anfragen kriegt pro Minute, dann kann ich natürlich nicht jede zweite Anfrage an den Human weiterleiten, sondern ich würde erst diese LLM as a Judge Schicht vorstellen. Das würde die initiale Evaluierung machen und würde davon dann wiederum ein Subset die schlechten Ergebnisse an meine tatsächlichen Humans in the Loop weiterleiten. Das wäre dann so eine Prozentzahl, die man dann in gerade fortschrittlicheren Kundengesprächen sieht. 10 % davon wird dann oder 5 % oder 1 % wird weitergeleitet an tatsächlich die Human Experts.

Patrick: Hast du da Erfahrungswerte aus deinen Kundenprojekten, wie die Kunden momentan diese Triebgeschwelle setzen? Eher zu eng oder sehr locker?

Thomas: Ja, ich glaube, gerade anfangs sind ja die Kunden natürlich auch mit Agents und ist ja alles neu und will man vielleicht so bisschen überkontrollieren. Ich habe eher so das Gefühl, dass die anfangs zu hoch gesetzt wird, aber sich dann über die Zeit quasi legt, wenn man dann sieht, okay, wenn natürlich auch der Human Expert dann irgendwie einen Fall nach dem anderen vorgelegt bekommt und dann immer nur sagt, ja, ne, passt eigentlich, passt, passt, passt. Das ist dann eher so ein Zeichen, okay, wir senden zu viele Fälle an den Human in the Loop und das wird dann quasi von Zeit zu Zeit weniger je advance und reifer der Agent dann tatsächlich ist.

Patrick: Okay, dann lass mich das kurz zusammenfassen. Antwort ist also nicht vertraut dem Agenten. Die Antwort ist dann ja mehr, hier sind unsere Qualitätsschwellen, hier ist unser EVAL-Set, hier sind die Human-in-the-loop-trigger-Bedingungen und hier ist der Audit Trail. Das Ganze ist also dann ja tatsächlich kein KI-Problem mehr, sondern ein gutes, altes Systemdesign. Noch eine letzte Frage zu Human in the Loop, bevor wir das Gesamtbild aufmachen. Wann ist Human in the Loop zu viel des Guten?

Thomas: Ja, also ich würde sagen, eigentlich wie schon gesagt, wenn zu viele Anfragen zu den Menschen geschickt werden, die diese dann manuell prüfen sollen, dann ist das auf jeden Fall zu viel. Da sollte man natürlich continuous monitoren, wie der aktuelle Stand ist, wie viele Anfragen abgelehnt werden, angenommen werden, wie oft quasi die Agent Response dann doch die richtige Antwort war und darüber würde ich das dann festmachen.

Patrick: Okay prima, vielen Dank. Jetzt haben wir die Begriffe ein bisschen durchgespielt. Ich möchte jetzt aber einen Schritt zurücktreten und das Gesamtbild zeigen, das hinter allem steht. Weil die größte Fehlannahme im Moment ist, dass ein KI Agent ein besonders kluges Einzelsystem ist. Eine Superintelligenz im Kasten. Was wirklich deployed wird, ist ja aber ein Compound AI System. Thomas, wie sieht dieses System aus?

Thomas: Ja, das beobachte ich auch bei den Kunden. Also die These ist ja so ein bisschen. Ein Agent kann nicht alles perfekt abdecken. ich sollte nicht, wenn ich gerade einen komplexeren Use-Case habe, ein komplexeres System habe, dann sollte ich nicht einen Agenten haben, beispielsweise Data Engineering Copilot, sollte nicht ein Agent alles machen, sondern ich sollte mehrere Unteragenten definieren, die dann Experte sind in einem anderen Bereich. Also ich habe dann irgendwie für meinen Data Engineering Agent habe ich dann einen Data Quality Agent, der da dahinter steckt, einen Incremental Processing Agent beispielsweise und so weiter und so fort. Ähnlich wie wenn ich jetzt ein Haus baue, dann auch nicht irgendwie eine Person beschäftige, die alles macht, sondern es gibt einen Architekten, der sich mit gewissen Sachen auskennt. Es gibt einen Elektriker. die Bauaufsicht, also auch andere Komponenten, da noch mit reinspielen und Co. Und wenn ich so einen Compound-AI-System designe oder auch Multi-Agenten-System designe, ist das eben die Frage, wie ich diese Orchestrierung mache. Also wie raute ich dann die richtigen Fragen an den richtigen Agenten? Wie kontrolliere ich die Lösungen? Wann ist der richtige Zeitpunkt, dann die Antwort an den User zurückzugeben und so weiter und so fort?

Patrick: Okay, Compound AI System, Multiagentensystem verstanden. Das bringt mich zu dem Begriff, der für mich am meisten unterschätzt ist. Nicht weil er technisch wäre, sondern weil ohne ihn keines der anderen Themen wirklich in Produktion hält. Observability. Kannst uns das auch jetzt hier nochmal kurz zusammenfassend in den Kontext bringen?

Thomas: Sehr gerne. Also Observability sowohl bei der Entwicklung der Agents als auch im Live-System extrem relevant und extrem wichtig. Gerade bei der Entwicklung meiner Agents brauche ich ja einen Weg, so bisschen nachvollziehen zu können, was mein Agent macht. Also gerade wenn ich ein komplexes System habe, dann macht er irgendwelche Tool-Aufrufe, irgendwelche Rack-Komponenten sind mit drin. Andere Agenten werden aufgerufen und da will ich natürlich die Übersicht haben, wie lange braucht jeder Tool Call beispielsweise. Wie viele Tokens werden bei jedem Schritt quasi verbraucht, damit ich einfach eine Übersicht habe, wie mein Agent arbeitet, dann auch zu optimieren. Aber auch später dann im Live-Betrieb, dass ich quasi dann all diese Punkte nachvollziehen kann, gerade wiederum bei schlechten Traces, also bei schlechten Antworten vom Agenten, würde ich mir diese ganzen Komponenten angucken und nachvollziehen, woran es denn gelegen hat, dass vielleicht eine Antwort mega lang gedauert hat, oder super viele Tokens verbraucht hat. Komponente da drin war quasi dafür verantwortlich. Oft wird da auf den Open Telemetry Standard quasi gesetzt oder Framework gesetzt. Unter anderem das MLflow Tracing, was ja auch in Databricks dafür genutzt wird, setzt quasi auch auf diesen Standard.

Patrick: Okay, das vervollständigt so bisschen für mich das Bild von Rack, Retrieval, LLM, Tool Execution, Orchestrierung, Ewalds, Human Delube, Monitoring. Also ein System, das jemand verantwortet und das beobachtbar ist. Kein Blackbox Superhörn im Kasten. Stimmt das Bild so für dich oder würdest du noch etwas ergänzen, Thomas?

Thomas: 100%, das stimmt so, das sind so die wichtigsten Komponenten, auf jeden Fall aus technischer Sicht. Was man auch nicht vernachlässigen darf, ist die Ownership-Frage. Also wer owned quasi zum einen den Agenten, wer owned die Retriever-Quality, das Evaluation-Data-Set, wer und wie wird der quasi Human-in-the-Loop-Prozess getriggert und so weiter. Also das ist noch, würde ich sagen, gerade im Enterprise ein umfanglicher ... umfänglich reiche Fragestellungen, die man sich da stellt, ein ordentliches System live zu...

Patrick: Okay. Führt mich fast schon zum Abschluss und zum Ende unseres Podcasts. Kleine Challenge, kurz und direkt. Sache für einen Entscheider, eine für einen Practitioner. Thomas, du fängst an. Welche Kernaussage würdest du für einen Entscheider in den Raum stellen?

Thomas: Ja, das ist eine gute Frage. Vielleicht zusammengefasst würde ich sagen, Ewals und Observability sind essentiell. Also wer das hat, hat quasi das Argument gegenüber Legal, Compliance und Vorstand und Co. Wer das nicht hat, hat vielleicht eher eine fancy Early-Stage-Demo.

Patrick: Okay, würde ich tatsächlich gerne mit einem Satz ergänzen, den ich mir mal aufgeschrieben hatte. Fragt nicht welches Modell. Fragt, ob ihr die Fehlerquote kennt und ob ihr sie kontrolliert. Das ist der Reifegrad, zählt. Okay, Thomas, jetzt noch eine Kernaussage für einen Practitioner.

Thomas: Ja, ich glaube, da wird es den machen vieles, was wir schon besprochen haben. Also, so bisschen zusammenzufassen. Also, die Entscheidung, die wirklich zählt, ist jetzt nicht ausschließlich, welches LLM dann der Practitioner oder der AI-Engineer nimmt, sondern was auch gerade aktuell State-of-the-Art-Research ist, ist, dass man sich vor allem auch auf die Agentic Loops, auf die Orchestrierung, auf das Context Engineering und alles quasi, was in diese Agent-Harness mit reinfällt, inklusive dann eben auch bei der Entwicklung EVALS und Co. fokussiert. Und dass das gesamte System dann auch testbare und austauschbare Komponenten hat, dass man sich auch quasi diese Architekturfreiheit verschafft, dass wenn irgendwie nächste Woche das neueste Fable 6 rauskommt, dass man da dann quasi auch einfach nur den Switch machen kann und alle anderen Komponenten quasi weiterverwendet werden können.

Patrick: finde ich extrem wichtig, weil das ist ja genau das, was eine gute Technentscheidung von einem Vendor-Login unterscheidet. Thomas, vielen, Dank, dass du heute mein Co-Host hier im Podcast warst.

Thomas: Sehr gerne, danke für die Einladung.

Patrick: für alle da draußen. Ihr habt heute eine ganze Vokabular mitgenommen von Hallucination und Kontextwindow über Rack und Grounding, Agent Memory als persistentes Gedächtnis, Tool Use, MCP Server und Skills als die Werkzeugebene, Scaffolding und Harness als das Gerüst drum herum, Meta Harness und AI Gateway für den Multi-Agenten-Betrieb bis hin zu Agentic Loop. Ewald, Human Loop, Compound AI System und Observability. Das ist das Vokabular, das in den Räumen zählt, in denen die Entscheidungen fallen. Nutzt es und nutzt es richtig. Wir hören uns beim nächsten Mal im nächsten Podcast und denkt immer daran gute Daten.

Thomas: Gute Entscheidungen!