[00:00:00] So, Trutz, Folge 0 ist im Kasten. Wir haben erzählt, warum wir das Ganze machen und schon
[00:00:06] gesagt, was Thema von der ersten Episode wird. Der AMALYTIX-Agent, den du gebaut hast, den
[00:00:15] ihr gebaut habt, ist Thema heute. Erzähl mal ein bisschen, was ist das denn, was macht
[00:00:20] der, was ist die Idee dahinter?
[00:00:21] Gerne. Ich muss mich vielleicht ein bisschen ausholen. Das Ganze hat ja angefangen mit
[00:00:26] dieser OpenClaw-Dynamik, die ja vor ein paar Monaten losgebrochen ist, wo jeder in OpenClaw-Feier
[00:00:33] war und so auch ich. Ich habe mir dann auch das Ding installiert, fand das auch sehr überzeugend,
[00:00:40] die Idee dahinter. Habe aber gemerkt, dass ich jetzt diesem Ding nicht Zugriff auf unsere
[00:00:45] Unternehmensdaten direkt geben möchte, weil das Ding steht irgendwie auf dem Server im
[00:00:49] Internet. Es war ja noch in einer sehr frühen Phase, da war ja auch das Risiko hoch, dass
[00:00:57] da vielleicht noch irgendwelche Sicherheitslücken sind etc. Aber die Idee hat mir gut gefallen
[00:01:01] und da habe ich schon gemerkt, das ist nochmal was anderes. Ich meine, die haben auch nur
[00:01:05] letztlich Sprachmodelle und Tools zusammengestöpselt, aber damit konnte man schon irgendwie Dinge
[00:01:10] machen, die so mit ChatGPT und Co. nicht möglich waren. Die Idee hat mich dann auch nicht mehr
[00:01:15] losgelassen, sodass ich dann einfach nochmal angefangen habe, mir so einen Agenten selber
[00:01:18] zu bauen. Wenn man ehrlich ist, das ist ja nicht sehr aufwendig. Das ist ja eigentlich nur ein
[00:01:23] Sprachmodell, in dem man ein paar Tools an die Hand gibt. Die Sprachmodelle unterstützen ja
[00:01:28] dieses Tool-Calling schon von Hause aus. Es geht eigentlich nur darum, diesem Sprachmodell die
[00:01:35] nötigen Tools in die Hand zu drücken, damit es Zugriff auf Daten bekommt, mit denen es was
[00:01:41] anfangen kann. Je mehr Tools man ihm gibt und je mehr Zugriff auf Daten man bekommt,
[00:01:45] umso mächtiger wird das Ganze. So habe ich eigentlich an einem Wochenende einfach mal
[00:01:51] angefangen, mir diesen Agenten, so eine Art Mini-OpenClaw, selbst nachzubauen. Aber halt
[00:01:57] in einer sehr, sehr simplen, aber wie sich herausgestellt hat, doch sehr mächtigen Art und
[00:02:01] Weise. Ich glaube, dieser OpenClaw-Moment ist schon irgendwie ein beeindruckender. Ganz viele
[00:02:06] Leute. Es ist jetzt nicht so, dass es da noch keine Idee gab, wie man Agenten baut. Aber
[00:02:11] tatsächlich einfach mal mit OpenClaw anfangen, das da hinzulegen. Ich glaube, meine erste
[00:02:18] Kommunikation mit OpenClaw war dann irgendwie im Telegram-Channel.
[00:02:21] Exakt. Ja, bei mir auch.
[00:02:22] Genau. Das ist so der erste Weg. Der Moment ist schon ganz cool, wenn man sagt, ich habe
[00:02:28] da einen Agenten hingestellt und der schreibt mir auf mein Handy plötzlich eine Nachricht,
[00:02:31] dass er irgendwas getan hat. Das war schon ganz cool. Deshalb würde mich echt auch mal
[00:02:36] interessieren, wie viel da so heraus entstanden ist. So wie du gerade gesagt hast, ich habe es
[00:02:40] mal ausprobiert und habe mal gesehen, was möglich ist und habe dann mich hingesetzt und
[00:02:44] habe tatsächlich mal was Echtes gebaut. Total spannend. Du hast gesagt, du hast dich dann für
[00:02:51] ein Framework entschieden. Was hast du genommen? Hast du dir ein bisschen angeguckt, was es so
[00:02:57] gibt? Hast du dir mehrere angeguckt oder einfach mit dem genommen, was am weitesten verbreitet ist?
[00:03:04] Genau. Letzteres. Es gibt ja so ein paar Agenten-Frameworks. Ich glaube, Entropiq hat
[00:03:08] etwas herausgebracht, wo man praktisch so eine Art Cloud-Code selber nachbauen kann. Aber eins
[00:03:12] der bekanntesten Frameworks, die schon wirklich lange am Markt sind, ist ja dieses Long-Chain-
[00:03:15] Framework. Ein Unterprodukt von denen ist ja auch deren Agent-Framework. Das habe ich einfach mal
[00:03:23] genommen, weil ich dachte, das müsste eigentlich mittlerweile gut abgehangen sein und funktionieren.
[00:03:29] Und Python – nee, andersrum, das gibt es auch für TypeScript. Das ist ja auch die Sprache,
[00:03:36] die wir hier bei AMALYTIX nutzen. Dann habe ich damit einfach mal angefangen und es jetzt
[00:03:40] auch nicht bereut, zumal wir jetzt auch nicht die wildesten komplizierten Funktionen nutzen.
[00:03:44] Aber ich habe mir in der Tat jetzt nicht mehrere angeschaut. Aber wahrscheinlich könnte man das
[00:03:48] genauso mit vielen anderen Frameworks bauen, die alle diesen sogenannten Agenten-Harness,
[00:03:53] wie das heißt, bereitstellen. Aber wichtig war halt nur, dass es von Haus aus Tool-Calling
[00:03:58] unterstützt. Weil das ist, glaube ich, das Entscheidende.
[00:04:02] Ja, der Agent muss irgendwie an Daten kommen, Dinge tun können. Das ist, glaube ich, das Spannende
[00:04:10] daran. Okay, das heißt, du hast ein bisschen mit Long-Chain gestartet, hast einen Agenten
[00:04:15] gebaut. Vielleicht können wir gleich mal durchgehen, wie du so Schritt für Schritt vorgegangen bist,
[00:04:21] was so die wichtigen Dinge waren. Aber vielleicht vorher mal eine kurze Zusammenfassung. Was ist
[00:04:25] denn der Kontext von dem Agenten? Wo bewegt er sich denn? Was ist die Idee? Und dann können wir
[00:04:30] nachher nochmal genau reingehen, was sind denn die Datenquellen, die er hat? Was sind die Dinge,
[00:04:35] die er tatsächlich tut? Warum tut er die? Wann? Wie wird er getriggert? Und all diese Dinge. Aber
[00:04:39] vielleicht mal einmal einen groben Überblick, was so der Kontext, in dem der sich bewegen soll.
[00:04:43] Genau. Ja, gute Frage. Wir müssen nochmal klarstellen, das ist kein Agent für die Nutzer
[00:04:49] von Amalytics, sondern wirklich ein, den wir nur intern hier im Unternehmen nutzen. Und da gab es
[00:04:53] auch schon mal so ein paar erste Gehversuche, wo ich das zum Teil auch schon mal in unsere
[00:04:58] Amalytics-Plattform für uns intern eingebaut habe. Es war ein ganz einfacher Use-Case. Da habe ich
[00:05:02] einfach versucht, unser Ticket-Management anzubinden. Also sprich, da, wo unsere Kunden
[00:05:06] ihre Bug-Reports fragen usw. reinlesen, um das zu verknüpfen dann mit der Code-Basis. Also es gab
[00:05:13] schon mal so einen ersten Versuch, so eine Art Customer-Service-Agenten zu bauen, mit einfach
[00:05:17] ganz zwei Datenquellen. Letztlich nur unserem Quelltext und letztlich den Tickets, die halt
[00:05:22] reinkommen. Und das hat schon funktioniert und fand ich schon ganz eindrucksvoll. Aber jetzt
[00:05:26] sind wir praktisch einen Schritt weiter gegangen, haben das rausgelöst aus Amalytics, läuft also
[00:05:29] völlig unabhängig und soll einfach Zugriff kriegen auf diese ganzen verstreuten Datenquellen,
[00:05:35] die wir haben. Denn wir haben auf der einen Seite ein CRM-Tool, wir haben ein Rechnungstool,
[00:05:39] wir haben mit Stripe einen Zahlungsdienstleister, wir haben unsere natürlich Kundendatenbank,
[00:05:45] wir haben unsere Knowledge-Base intern und dann im technischen Bereich noch diverse Logging-Tools
[00:05:53] wie Datadog oder andere Logging- und Überwachungstools. Und überall liegen eigentlich diese ganzen
[00:06:00] Daten verstreut. Und immer wenn so eine Frage kommt, warum ist das gerade kaputt, warum gibt
[00:06:05] es diesen Bug, da muss man sich eigentlich aus verschiedenen Datenquellen immer so die
[00:06:07] ganzen Infos zusammenklauben. Und die Vision und die Idee war, dass man halt praktisch dem
[00:06:13] Agenten Zugriff auf all diese Daten gibt, so dass er oder sie dann praktisch sich die Daten
[00:06:19] selber zusammensuchen kann. Und das klappt in der Tat auch wirklich sehr, sehr gut. Der erste
[00:06:25] Use-Case, den wir direkt hatten, war, dass ein Kunde sagte, hier, ich glaube, ihr habt mich
[00:06:32] doppelt abgebucht und das schon seit längerer Zeit. Und normalerweise ist das ein Case, da fängt
[00:06:37] man dann an, okay, dann guckt man ins Rechnungstool, holt sich alle Rechnungen runter, dann geht man
[00:06:40] ins Zahlungstool, guckt, okay, wir haben irgendwie bei Kreditkarte und dann auch über Lastschrift
[00:06:46] parallel abgebucht, weil es gab eine Umstellung und das andere wurde nicht angehalten. Und bis
[00:06:49] man sich all diese Daten dann in so einem Excel-Sheet mal zusammengeklaubt hat, dauert das
[00:06:54] ein, zwei Stunden. Und jetzt mit diesem Agenten war es in der Tat so, den konnte ich, als diese
[00:06:59] Anbindung schon stand, konnten wir den fragen, hier, Kunde XY sagt, wir haben abgebucht, guck mal
[00:07:04] bitte. Und dann ist der losgerannt und hat sich die Daten aus den verschiedenen Tools geholt und
[00:07:08] konnte das in der Tat wirklich sehr gut nachvollziehen. Und das war ein Moment, wo ich
[00:07:14] dachte, Wahnsinn, Alter, hätte ich locker eine Stunde, wie gesagt, für gebraucht und der hat
[00:07:18] das irgendwie innerhalb von fünf Minuten sich zusammengestückelt. Und das war so mein erster
[00:07:23] Aha-Moment, wo ich dachte, das ist die Zukunft. Also so wird es, glaube ich, laufen. Und seitdem
[00:07:30] haben wir eigentlich angefangen, habe ich einfach angefangen, weitere Datenquellen zu ergänzen. Das
[00:07:34] fing dann erst mit wenigen Datenquellen an und immer, wenn wir gemerkt haben, Mist, der hat
[00:07:37] darauf noch keinen Zugriff, dann haben wir eben dem halt gegeben. Das Ganze halt alles über Coding
[00:07:42] Tools mit Code Code. Das habe ich ja nicht selber programmiert. Worauf es ankommt ist letztlich,
[00:07:47] bietet dieser externe Dienst irgendeine Form von Schnittstelle an. Und das kann entweder eine API
[00:07:52] sein, dann baut man vielleicht ein kleines CLI-Tool, mit dem man darauf zugreifen kann. Das
[00:07:57] kann aber auch ein MCP-Server sein. Wir nutzen zum Beispiel Linear als internes Task-Management
[00:08:03] für unsere Entwickler, wo wir die ganzen Aufgaben beschreiben. Und Linear selbst bietet einen
[00:08:07] MCP-Server an. Das funktioniert super. Der kann sämtliche internen Tickets lesen, der kann auch
[00:08:12] Tickets erstellen und vieles mehr. Und seitdem ist das wirklich ein nicht mehr wegzudenkendes
[00:08:20] Tool bei uns im Unternehmen.
[00:08:21] Ja, beeindruckend. Ich freue mich auf die Details gleich. Lass mal kurz einen Schritt
[00:08:27] zurückgehen. Du hast eben gesagt, der erste Teil war quasi, warum haben wir doppelt abgebucht?
[00:08:34] Das kenne ich auch ganz viele Cases, wo man sagt, da muss man mal herausfinden,
[00:08:39] was überhaupt los ist und Daten von da mit dem zusammenbringen und erstmal herausfinden,
[00:08:44] wie man das denn matcht. Da habe ich schon Stunden verbracht mit Dingen. Warum fehlt
[00:08:51] denn hier jetzt irgendwie Summe X und warum passt das alles nicht zusammen? Vielleicht machen wir
[00:08:58] es da mal, wenn du sagst, das war so der erste Case, wo du gesagt hast, wir haben die Zahlungsdaten
[00:09:04] da reingenommen. Wie bist du denn reingegangen? Du hast gesagt, du hast Cloud Code genutzt,
[00:09:08] Langchain. Das heißt, du hast ein Framework aufgesetzt. Wie bist du denn vorgegangen? Was
[00:09:13] für ein LLM steckt dahinter? Was sind so die ersten Schritte, bis du tatsächlich das erste
[00:09:18] Mal gesagt hast, der Agent hat etwas Sinnvolles getan, nämlich mir eine Idee gegeben, was da
[00:09:22] schiefgelaufen ist? Und letztendlich musst du das ja auch irgendwo sehen. Mit OpenClaw gibt es
[00:09:27] eine UI dazu, wo du Dinge siehst oder eine Kommunikation zu Telegram. Das heißt,
[00:09:32] vielleicht mal so den Anfang. Wie waren so die Schritte, bis der das erste Mal etwas getan hat?
[00:09:36] Und was war denn dann das UI? Wie hast du es denn gesehen?
[00:09:40] Genau. Ja, gute Fragen. Das Ganze ist eigentlich eine relativ schlichte Web-App. Das heißt,
[00:09:47] man kann die über den Browser aufrufen. Man kann sich das optisch so vorstellen wie ChatGPT. Man
[00:09:51] sieht einfach nur ein Chatinterface und letztlich die Antworten des Agenten innerhalb dessen. Das
[00:09:58] Ganze läuft also über den Browser, ist unter der Haube eine einfache ExpressJS-App mit diesem
[00:10:04] Langchain-Framework eingebettet. Und man kann mit dem chatten. Als Sprachmodell, das war uns
[00:10:09] halt auch wichtig. Und deswegen, vielleicht habe ich mich auch deswegen auch für das
[00:10:13] Langchain-Framework entschieden, weil ich dann gesehen hatte, das funktioniert, nutzen wir halt,
[00:10:17] weil wir mit sensiblen Daten arbeiten. Die AWS Bedrock Cloud nutzen wir halt auch bei
[00:10:22] AMALYTIX, weil da ist sichergestellt, dass die Daten nicht für Trainingszwecke genutzt werden,
[00:10:27] die werden nicht gelockt. Wir haben praktisch dieses Thema Zero Data Retention, wie es so
[00:10:31] schön heißt. Hätte ich jetzt OpenAI genutzt oder Entropiq direkt, da weiß man ja nicht,
[00:10:36] was die mit unseren Chats und unseren Daten machen. Noch schlimmer mit irgendwelchen chinesischen
[00:10:40] Modellen in der Alibaba Cloud oder Ähnliches. Also uns war sehr wichtig oder mir war sehr
[00:10:45] wichtig, dass die Daten sicher sind, die wir da irgendwo hinschicken. Und deswegen diese AWS
[00:10:50] Bedrock Cloud. Aber die Applikation als solche ist eigentlich super simpel und das macht es halt
[00:10:55] auch so. Und trotzdem ist es so mächtig. Also es ist wirklich ein ganz simpler Chat-Agent.
[00:11:00] Mittlerweile haben wir dann noch so ein paar Sachen jetzt ergänzt mit Statistiken und so
[00:11:05] Kontrast und so weiter. Aber die erste Version war eigentlich wirklich nur so eine ganz einfache
[00:11:10] Chat-Oberfläche. Man haut dann prompt rein und man sieht die Antworten, die dann reingestreamt
[00:11:14] kommen. Und dann fängt man halt an, wenn das sozusagen steht, einfach diese Tools zu bauen.
[00:11:19] Tools sind ja, kann man sich ja vorstellen, wie so ein Werkzeugkoffer, wo man halt eine Zange rein
[00:11:23] legt, einen Hammer und einen Schraubendreher und so weiter. Und man sagt dem Agenten hier,
[00:11:27] auf die hast du jetzt Zugriff. Und erklärt vielleicht noch so ein bisschen, ich habe
[00:11:30] immer noch so ein kleines Skill-File erstellt in Markdown, wo da einfach nur beschrieben wird,
[00:11:35] was kannst du damit machen. Hier, das ist das CRM-Tool, damit hast du Zugriff auf unser CRM.
[00:11:39] So funktioniert das. Das ist die API, da findest du die und die Daten. Also eher allgemein und
[00:11:44] generisch, damit er weiß, wann er dieses Tool aufrufen soll. Denn der Agent entscheidet ja
[00:11:49] selbstständig, wie er die Aufgaben löst. Er muss nur wissen, welche Werkzeuge habe ich denn und
[00:11:53] kann dann situativ das eine oder andere Werkzeug aufrufen oder halt auch nicht. Das heißt,
[00:11:59] es ist ja nicht mehr, und das ist ja auch das Mächtige daran, es ist ja kein deterministischer
[00:12:04] Ablauf, mach das, dann das, dann das und komm so zum Ziel. Sondern der Agent entscheidet ja selbst,
[00:12:08] basierend auf den Werkzeugen, die er hat. Und wenn man ihm halt die Aufgabe gibt,
[00:12:13] kannst du mal bitte hier die Zahlungen und Rechnungen nachvollziehen, dann braucht er
[00:12:16] halt natürlich die Tools, um auf unser Rechnungstool zuzugreifen. Er braucht das
[00:12:19] Tool, um auf Stripe zuzugreifen. Er braucht das Tool, um auf unseren Lastschriftdienstleister
[00:12:24] zuzugreifen. Und vielleicht auch noch, wobei das ist es eigentlich. Und er muss natürlich wissen,
[00:12:29] wie findet er den gleichen Kunden in den verschiedenen Tools. Die Kunden haben alle
[00:12:35] irgendeine User-ID in jedem Tool und die sind natürlich unterschiedlich. Also wir brauchen
[00:12:39] irgendwo natürlich noch, muss er wissen, okay, der Kunde heißt hier 123, im anderen Tool heißt
[00:12:44] er 456 und im dritten und so. Das ist klar, das muss er natürlich auch wissen. Aber wenn er das
[00:12:48] weiß und er versteht die APIs, die dahinterstehen, dann kann er sagen, okay, gib mir doch erstmal für
[00:12:53] den Kunden die Rechnungen aus dem Jahr 2025. Und jetzt zeig mir mal, welche Zahlungen da
[00:12:57] gelaufen sind in Stripe. Und jetzt zeig mir mal, welche Abrufungen da über Lastschrift gelaufen
[00:13:00] sind. Und die Daten holt er sich halt alle zusammen. Ja, und dann kommt wieder die Macht
[00:13:04] des Sprachmodells und dann analysiert er dir. Fun Fact war, da kamen relativ viele Daten zusammen,
[00:13:10] weil es über einen längeren Zeitraum ging. Und es war in der Tat so, dass dann natürlich bei
[00:13:15] jeder Abfrage immer ein leicht anderes Ergebnis rauskam. Weil ich habe dann gefragt, wie viel
[00:13:18] müssen wir denn den Kunden jetzt erstatten? Und bei der ersten Abfrage war es dann irgendwie
[00:13:22] so und so viel, bei der zweiten so und so viel. Es war immer leicht anders, minimal,
[00:13:25] aber so immer ähnlich. Aber es hat natürlich schon mal geholfen, das zu verstehen. Am Ende
[00:13:30] haben wir es natürlich per Hand dann nochmal alles nachgerechnet. Aber es hat einen sehr
[00:13:35] guten Indikator gegeben, was überhaupt das Problem war, wann das entstanden ist. Und das
[00:13:40] hat also sehr geholfen. Das einzige Problem war, was ich total unterschätzt habe, ist,
[00:13:44] wie teuer dann doch diese API-Kosten sind. Wir sind ja alle irgendwie gewohnt mit diesen
[00:13:47] Subscriptions, dass wir da irgendwie 20, 60, 200 Dollar im Monat zahlen für eine Flatrate. Aber
[00:13:53] bei der API wirst du ja auf Tokenbasis abgerechnet. Und wenn du jetzt mehrere,
[00:13:58] viele Daten an das LLM schickst und die immer ausgewertet werden, da brennt man richtig Token
[00:14:03] durch. Und das war mir ehrlicherweise nicht so bewusst. Das heißt, ich habe an diesem einen
[00:14:07] Tag, weil ich dann total on fire war und habe auch verschiedene Modelle durchgetestet. Welches
[00:14:12] Modell löst die Aufgabe am besten? Ich habe da, glaube ich, an einem Tag 800 Dollar durchgebrannt
[00:14:17] über die API. Das habe ich aber gar nicht gewusst. Das habe ich erst hinterher gemerkt,
[00:14:20] als ein paar Alerts losgingen. Das war für mich auch nochmal so ein Aha-Moment, wo ich dachte,
[00:14:26] man darf nicht einfach das beste, teuerste Modell nehmen. Denn die Kostenstruktur über die API bei
[00:14:32] Bedrock oder auch bei Entropic oder OpenAI ist das Gleiche. Das ist eine ganz andere als diese
[00:14:38] Coding-Tools, die wir nutzen, wo du über die Token-Usage gar keine Gedanken machen musst.
[00:14:43] Das war nochmal ein Aha-Moment. Und dann haben wir hier auch nochmal angefangen,
[00:14:46] mit verschiedenen Modellen zu experimentieren. Denn man hat schon gemerkt, klar, ein starkes
[00:14:54] Modell löst die Aufgabe halt besser. No-brainer. Und je schwächer das Modell ist, umso schwächer
[00:15:00] wird es auch im Tool-Calling, umso schwächer bricht es manchmal ab, weil es das Tool falsch
[00:15:04] aufgerufen hat. Aber es ist natürlich deutlich günstiger. Und das Gute ist ja, bei dieser AWS
[00:15:08] Bedrock-Plattform werden ja auch verschiedene Modelle angeboten. Einmal hat man Zugriff auf
[00:15:12] die ganzen Entropic-Modelle mit Clode Sone, Clode Opus. Aber es gibt auch die Modelle von
[00:15:20] einigen chinesischen Anbietern, die dann aber auf der AWS-Plattform gehostet werden und laufen.
[00:15:25] Deswegen kann man die halt auch guten Gewissens nutzen, wie GLM 5.1, Kimi irgendwas, Quenn,
[00:15:31] you name it. Und da habe ich halt sehr viel rumprobiert und geguckt, was funktioniert
[00:15:37] denn jetzt gut. Und dadurch halt sehr, sehr viele Tokens und auch Geld verbrannt leider.
[00:15:40] Das ist, glaube ich, auch nochmal ein Thema für eine andere Episode. Das ganze Thema
[00:15:45] auch lokale Modelle. Ich habe ja auf dem Schreibtisch ein Mac Mini stehen, wo auch ein
[00:15:49] Quenn gerade drauf läuft oder ein Gemma mit rumprobiert auf meinem MacBook. Das ist, glaube
[00:15:56] ich, auch ein total spannendes Thema. Was geht denn vielleicht auch mit lokalen Modellen, die
[00:15:59] man selber betreibt? Das geht schon tatsächlich ganz gut. Aber die Qualität ist sehr unterschiedlich.
[00:16:06] Da habe ich auch mal für einen anderen Case durchgetestet. Eigentlich ähnlich große Modelle,
[00:16:11] die auch ähnlich gelagert waren. Aber manche funktionieren für den Case total gut, andere
[00:16:15] nicht. Es ist ein spannendes Thema, mal zu sehen, was geht tatsächlich mit lokalen Modellen,
[00:16:22] die ich vielleicht auch selber betreibe. Das wäre ja der Traum. Das Ganze kommen wir gleich
[00:16:31] auch nochmal zu. Läuft jetzt bei mir auch auf dem MacBook Air hier bei uns im Büro,
[00:16:35] weil ich jetzt auch Angst hatte, das irgendwo ins Netz zu stellen. Das ist ja natürlich auf der
[00:16:40] Seite auch ein Security-Risk. Aber wenn man es dann auch schaffen würde, ein lokales Modell
[00:16:42] da anzuschalten, dann hat man ja gar keine Kostenstruktur mehr. Dann ist es vielleicht
[00:16:46] nur noch ein Zeitthema, weil es vielleicht nicht so schnell ist. Aber das wäre natürlich der Traum.
[00:16:50] Und die werden ja immer besser. Deswegen ist das mit Sicherheit auch mal ein Thema für eine eigene
[00:16:53] Folge, lokale Modelle selber hosten lassen. Und da spielt uns ja, glaube ich, die Zeit in die
[00:16:58] Karten. Das heißt, wie du sagst, die werden ja immer besser, die Modelle. Und das ist natürlich
[00:17:01] echt ein Traum. Also da warte ich, da freue ich mich schon drauf, wenn es mal irgendwann so weit
[00:17:04] ist. Ja, ich auch. Ich habe gerade auf dem MacBook ein bisschen rumprobiert, ob ich nicht
[00:17:09] lokal mit OMLX tatsächlich ein Modell laufen lassen kann, was ich so als tagtägliches Modell
[00:17:15] nutze. Mal sehen. Sprechen wir auf jeden Fall auch nochmal drüber. Lokale Modelle, glaube ich,
[00:17:20] total interessantes Thema auch. Aber die 800 Dollar, die du da durchgebracht hast,
[00:17:27] ist natürlich auch ganz viel Input-Output-Token. Das geht, glaube ich, sehr schnell. Vor allem,
[00:17:33] wenn man große Datenmengen analysiert. Deshalb dieses Context-Management, das heißt,
[00:17:36] was packe ich in den Kontext und was nicht, ist, glaube ich, da auch ein ganz wichtiges Thema. Du
[00:17:41] kannst natürlich entweder alle Zahlungsdaten da einmal rein und lässt das LLM da raussuchen,
[00:17:47] was denn jetzt die Zahlungen von dem Kunden sind, die dich interessieren. Oder du baust vorher halt
[00:17:51] einen sauberen Filter ein, der das schon mal eindampft. Und das ist, glaube ich, auch das Neue,
[00:17:57] dass man es wirklich als Kostenthema sieht. Bei klassischen Anwendungen hat man das irgendwie
[00:18:02] immer in Zeit und Performance der Anwendung irgendwie gemessen. Da hat man gesagt, okay,
[00:18:06] ich schmeiße das alles mit rein, dann dauert es halt irgendwie drei Sekunden länger. Aber ist
[00:18:09] mir egal. Aber wenn man das alles ins Sprachmodell packt, dann ist das halt tatsächlich plötzlich
[00:18:14] ein Kostenthema. Dann dauert es nicht nur länger, sondern ich haue dann auch Token da rein und raus,
[00:18:18] die ich im Zweifel alle einzeln bezahlen muss. Absolut.
[00:18:22] Ein Millionenstück.
[00:18:24] Das haben wir auch auf die harte Tour lernen müssen, leider. Weil da bieten wir ja auch einen
[00:18:28] Chat-Agenten an, der auch gerne und gut genutzt wird von unseren Kunden. Und da haben wir dann
[00:18:32] auch gemerkt, oh, das wird schnell teuer. Weil bei jeder Abfrage, ich weiß nicht, ob das allen so
[00:18:37] bewusst ist, aber wenn man so mit dem Agenten chattet, man schickt ja immer die komplette
[00:18:41] Konversation zurück. Denn der Agent leidet ja praktisch unter Gedächtnisverlust. Und je länger
[00:18:48] man chattet, je mehr Tools man einbindet, umso länger wird dieses Ganze, wie du sagst, der ganze
[00:18:53] Kontext, umso teurer wird das auch. Und da wird dann auch angefangen mit Prompt Caching und
[00:18:58] Kompaktisierung und etc. Das ist vielleicht ein Thema für eine andere Folge. Aber ja, da lernt man
[00:19:03] wirklich einiges nochmal. Und wie du genau sagst, Kosten spielen plötzlich absolut eine Rolle.
[00:19:07] Das ist, glaube ich, auch ein wichtiges Thema für alle, die die Sprachmodelle, Chat-Interfaces
[00:19:15] irgendwie für tagtägliche Dinge nutzen. Auch da ist es wichtig, den Kontext im Blick zu haben.
[00:19:19] Wann fange ich eine neue Konversation an und schmeiße den alten Kontext weg und versuche,
[00:19:24] das eher in kleine Dinge zu machen? Also es geht nicht nur um Token-Usage, sondern tatsächlich auch
[00:19:30] Qualität. Wenn ich über sieben verschiedene Themen spreche mit meiner KI, dann am besten
[00:19:37] nicht in einem Kontext, nur in einem Chatverlauf. Das ist auch etwas, wo man darauf achten kann.
[00:19:44] Okay, das heißt, die erste Version sah eigentlich so aus. Du hast so etwas wie Chatshippity oder
[00:19:51] Claude. Also ein Sprachmodell, das irgendwie Tools hat. Chatshippity oder Claude können Web-Suche
[00:19:56] machen. Die haben so ein paar Tools. Du hast dir quasi deinen eigenen gebaut mit deinen eigenen
[00:20:01] Tools. Keine Web-Recherche, sondern Recherche in deinen Zahlungssystemen. Und dann hast du
[00:20:09] eigentlich einfach eine Frage gestellt, warum hat der Kunde bezahlt und natürlich sprachlich mit
[00:20:17] dem interagiert. Total spannend. Du hast eben gesagt, er braucht noch die Information, wie er
[00:20:23] die Kunden matcht, quasi in den unterschiedlichen Systemen. Hast du ihm das dann mitgegeben im
[00:20:27] Chatinterface? Hast du das irgendwie noch mal irgendwo als MD-File abgelegt oder sowas? Oder
[00:20:31] ist das etwas, was du dann in der Version einfach ihm mitgegeben hast? Oder ist es ein Kunde,
[00:20:34] der heißt da so und da ist er so und dann analysieren wir das? Gibt es irgendwie noch
[00:20:39] etwas, wo du ihm im Kontext Wissen mitgegeben hast, wo er sowas auch selber nachgucken kann
[00:20:44] in Zukunft? Genau. All diese Informationen führen wir auch bei uns in Amalytics zusammen. Das heißt,
[00:20:50] dort ist der Kunde zentral angelegt und da hat er auch die Eiderwissen. Amalytics weiß auch,
[00:20:54] welche ID hat er bei Stripe, welche ID hat er beim Rechnungstool etc. Das ist eigentlich so
[00:20:59] ein bisschen die Quelle der Wahrheit. Und auf diese Datenbank hat er auch Zugriff,
[00:21:02] lesend natürlich nur. Dem würde ich niemals Schreibzugriff auf irgendwas geben. Und meistens
[00:21:08] würden wir dann sagen, hier Kunde XY mit der ID, ich sage jetzt mal 1, 2, 3, 4, 5 in Amalytics,
[00:21:13] hat folgende Frage gestellt und dann weiß das Tool, okay, dann gehe ich jetzt erstmal in Amalytics
[00:21:17] rein, hol mir da den Kunden. Dann sieht er praktisch den gesamten Kundendatensatz und
[00:21:20] dort findet er dann auch die entsprechenden IDs für das Rechnungstool, für Stripe,
[00:21:26] für Lastschrift etc. und kann damit dann mit den entsprechenden Tools dann die Abfragen starten.
[00:21:30] Exakt. Und das muss man halt irgendwie irgendwo haben, diese Wahrheit und diese Verknüpfung.
[00:21:36] Ansonsten müsste er suchen. Das geht natürlich auch. Man kann ja auch in Stripe nach Kunden
[00:21:43] suchen und sagen, okay, dann suche ich jetzt noch diese E-Mail-Adresse und ach, da ist ja der Kunde,
[00:21:46] dann nehme ich doch den und dann macht er von dort aus weiter. Das geht natürlich auch,
[00:21:48] wenn man das nicht hat. Also es heißt nicht, dass man das haben muss. Es muss nur für den
[00:21:52] Agenten irgendeine Möglichkeit geben, über so einen eindeutigen Identifizierer den Kunden
[00:21:56] irgendwie ausfindig zu machen. Hast du das denn, also kleine Detailfrage, wir können auch gleich
[00:22:03] weitermachen, aber hast du dieses Matching, hast du das im Stripe-Tool zum Beispiel,
[00:22:08] dass das Stripe-Tool welche IDs aus dem AMALYTIX-Kontext nehmen muss, um den Kunden zu
[00:22:15] matchen? Also hast du das nochmal irgendwo explizit hinterlegt? Amalytics weiß, wie der
[00:22:21] Kunde in Stripe heißt. Wir nutzen also Webhooks und so weiter. Also wenn Stripe irgendwas macht,
[00:22:27] schickt Stripe uns eine Info und da wissen wir dann halt, dass da ein Kunde 1, 2, 3 ist. In
[00:22:32] Stripe wissen wir, dass es bei uns Kunde 4, 5, 6 ist in Amalytics. Aber ja,
[00:22:35] irgendwo muss man diese Verknüpfung haben, damit man die Daten sinnvoll irgendwie
[00:22:39] zusammenführen kann. Okay, erster Schritt war, du hast dir deinen eigenen Chat-Agenten gebaut quasi,
[00:22:46] der auch deine eigenen Datentools für deine eigenen Daten hatte und konntest ihm Fragen
[00:22:51] stellen. Das ist der erste Schritt. Dann hast du aber, wenn ich das richtig verstehe,
[00:22:57] auch tatsächlich Agentenverhalten implementiert, die nicht durch Chat getriggert werden. Das heißt,
[00:23:06] Dinge, die regelmäßig laufen, die durch irgendwelche Events getriggert werden. Was hast du da? Ist das
[00:23:12] der nächste Schritt oder fehlt noch was? Das Charmante ist, diese Grundarchitektur ist ja
[00:23:18] wirklich simpel. Es ist einfach ein Chat mit Tool-Calling, also mit Zugriff auf Tools,
[00:23:23] fertig. Damit hat man schon einen sehr mächtigen Agenten, den man dann on-demand oder ad hoc
[00:23:28] dann Fragen stellen kann. Dann ergeben sich aber plötzlich Anwendungen, wo man denkt,
[00:23:33] das kannst du ja nicht jeden Tag machen. Der hat auch Zugriff auf unser internes Chat-System. Der
[00:23:39] hat Zugriff auf diverse Logs. Also immer, wenn ein Problem reinfließt, kriegen wir das häufig
[00:23:44] bei uns in unseren Slack-Kanal rein. Den hat er lesend Zugriff und sogar auch schreibend.
[00:23:51] Das heißt, was wir zum Beispiel machen, ist, wir machen ein tägliches Sales-Update oder ein
[00:23:57] tägliches Customer-Service-Update. Das heißt, er guckt sich dann die ganzen Nachrichten,
[00:24:01] 24 Stunden an, guckt sich vielleicht auch noch Fehlermeldungen an etc. und sieht dann,
[00:24:04] ach übrigens, guckt euch mal bitte den Kunden an, der hat scheinbar gerade ein Problem mit
[00:24:08] dem Login. Der kommt nicht mehr rein oder da haben wir den Account gesperrt, weil er sich
[00:24:13] fünfmal falsch angemeldet. Bitte schaltet ihn wieder frei. Das heißt, das ist wirklich ein
[00:24:18] zusätzliches Paar Augen, was halt die diverse Log-Dateien oder Nachrichten im Blick behalten
[00:24:25] kann. Und auch hier gilt wieder, man muss ihm halt nur den Zugriff darauf geben. Man muss erst
[00:24:29] mal diese Events sichtbar machen in irgendeiner Form, die dann irgendwie in den Zugriff des
[00:24:34] Agenten geben und irgendwo persistieren. Und wenn er das einmal hat, dann kann er dir auch
[00:24:39] Unterstützung geben im Kundenservice-Bereich. Wir haben solche auch mal, der guckt alle vier
[00:24:45] Stunden in unser Nutzen-Dafür-Help-Scout, in unser Ticket-Management rein, wo die Kunden halt
[00:24:49] Tickets erstellen können und klassifiziert schon mal alles als Spam, was typischerweise Spam ist.
[00:24:55] Da kann er halt auch dann schreibend darauf zugreifen. Oder wir können ihm auch sagen,
[00:25:01] hier kam gerade Ticket XY rein, kannst du mal gucken, schon mal eine Vorrecherche machen.
[00:25:05] Dann holt er sich die Anfrage von dem Kunden, holt sich den Kunden in AMALYTIX, analysiert
[00:25:10] im Zweifel den Quelltext, versucht das Problem zu verstehen, holt sich die Daten aus der
[00:25:13] Datenbank, guckt nochmal bei Datadog in den Logs nach und dann kann der im Zweifel,
[00:25:17] macht der Bug-Fixing schneller als wir gucken können. Oder schon mal so eine erste Vorrecherche
[00:25:22] und sagt, ja stimmt, der Kunde hat recht, da ist ein Bug, habe ich so und so verifiziert und das
[00:25:26] wäre der Fix. Und dann sagt man ihm im nächsten Schritt, kannst du mal ein Linearticket dazu
[00:25:30] erstellen, damit wir es dem Entwickler geben können? Hat er gemacht. Und die Tickets sind
[00:25:33] natürlich zehnmal besser, als wenn man die per Hand schreibt, weil die viel detaillierter sind,
[00:25:36] viel mehr Kontext. Also das ist schon wirklich mind-blowing, was da passiert.
[00:25:43] Ja, das ist schon krass, glaube ich. Wenn du tatsächlich einfach sagen kannst, da kommen
[00:25:47] Tickets rein und der macht eine Qualifizierung einfach, guckt sich an, ist das plausibel? Wo
[00:25:53] kommt der Fehler her? Und das im Tagesgeschäft. Du musst ihm ja im Zweifel nicht einzelne Tickets
[00:26:01] geben und sagen, guck dir das mal an, sondern er kann sicher eigentlich jedes Ticket vornehmen.
[00:26:06] Einmal überlegen, ist das tatsächlich ein Bug im System? Wie kritisch ist das? Wie viele Kunden
[00:26:11] wird das vermutlich in der nächsten Zeit betreffen? Und wie hoch priorisiere ich das dann? Das sind
[00:26:16] Dinge, die automatisch laufen können. So muss man sich immer noch fixen lassen und direkt in
[00:26:21] Produktionscode pushen. Das ist, glaube ich, keine so gute Idee. Aber allein die ganze Arbeit vorher
[00:26:28] schon mal, sich das anzugucken. Woher kommt das? Wie groß sind die Auswirkungen? Da kann man ja
[00:26:33] auch alles mit einbeziehen. Was ich, glaube ich, spannend finde, ist, dass du noch mal viel mehr,
[00:26:38] du kannst ja dann, der Agent kann ja auch sogar die Business-Sicht mit einbeziehen.
[00:26:41] Sonst, wenn du so ein Ticket einem Entwickler gibst, kann er das aus technischer Sicht
[00:26:46] irgendwie beurteilen. Aber welche Business-Auswirkungen hat das denn? Ist das ein Kunde,
[00:26:50] der viel auf der Plattform macht, der häufig da ist, wo wirklich Umsatz irgendwie verloren geht,
[00:26:55] wenn er jetzt das Problem weiter hat? Das kannst du ja dann in einem Agenten kombinieren,
[00:27:01] was du ja typischerweise nicht hast. Sonst hast du technische Bewertung, Business-Bewertung sind
[00:27:05] halt eigentlich andere Menschen. Und da kannst du so ein Ticket tatsächlich einmal aus allen
[00:27:10] Blickwinkeln irgendwie bewerten lassen und priorisieren. Finde ich auch total spannend,
[00:27:14] dass die Agenten einfach so vielschichtig Dinge bewerten können. Nicht nur technische Experten
[00:27:23] sind, sondern das Gesamtbild tatsächlich im Blick haben können. Echt total spannend.
[00:27:28] Der hat halt auch über das CRM Zugriff auf die bisherige E-Mail-Kommunikation und kann dann da
[00:27:32] im Zweifel mal nachgucken und sagen, das hat der Kunde vor vier Wochen schon mal angesprochen. Oder
[00:27:36] ach nee, ich habe schon gesehen, der Junior hat ihm schon geantwortet. Dann ist das Thema ja schon
[00:27:39] erledigt. Also es ist wirklich verrückt. Und das Schöne ist halt auch, dass damit diese Fähigkeit,
[00:27:46] ich will jetzt nicht, demokratisiert ist vielleicht ein großes Wort, aber bisher
[00:27:50] kamen irgendwie solche Tickets halt erstmal entweder bei den Entwicklern an oder bei mir.
[00:27:54] Und dann fängt man an. Dann macht man die Datenbank auf, guckt sich die Daten an. Und
[00:27:58] unser Customer Success oder unser Sales Team hatte natürlicherweise nicht Zugriff irgendwie
[00:28:04] da direkt drauf. Aber über diesen Agenten können die jetzt schon sich direkt selber helfen und fast
[00:28:09] schon im Telefonat das mal oder Fragen stellen, auch zum Quelltext und sagen, wie funktioniert
[00:28:13] das jetzt nochmal ganz genau eigentlich? Wie ist denn die Business-Logik jetzt dahinter? Und
[00:28:18] können damit auch sich, also haben damit Zugriff auf eine Wissensquelle, die vorher auf wenige
[00:28:23] Köpfe verteilt war oder wo wir erstmal selber nachgucken mussten im Code. Ja, wie war denn das
[00:28:27] mal? Wie haben wir das denn gebaut? Und so können die das jetzt alles den Agenten fragen und kriegen
[00:28:30] in der Regel schneller eine bessere Antwort, als wenn sie mich fragen, eine halbe Stunde warten
[00:28:34] müssen. Ach ja, stimmt, ich gucke nochmal nach. Also und deswegen haben wir den halt auch irgendwie,
[00:28:39] wir sind ja ein kleines Team hier bei Malutix, aber da haben jetzt alle Zugriff drauf und können
[00:28:44] entsprechend schnell sich selber helfen. Ja, beeindruckend. Und das läuft jetzt lokal bei
[00:28:52] euch. Sollen wir da mal drauf gehen? Also du hast quasi den Agenten gebaut, Langchain, dann läuft
[00:29:00] das wo bei euch? Und wie, ja können wir nachher glaube ich nochmal auf die Tools und die Daten
[00:29:05] anbinden, was so die Herausforderungen da waren. Aber vielleicht erstmal so Deployment,
[00:29:09] wo lebt der Agent denn? Ja, genau. Und das ist auch ein wichtiges Thema, weil das ist ja auf
[00:29:14] der einen Seite ein ganz, ganz tolles Tool, aber es ist natürlich auch der Security-Eintraum. Wenn
[00:29:18] man da drauf Zugriff hat, hat man ja praktisch Zugriff auf alles. So als würde man hier im
[00:29:23] Büro stehen und ein Rechner wäre ungeschützt, setzt man sich ran und hat alles im Blick. Insofern
[00:29:28] war das Thema Sicherheit natürlich schon irgendwie von Anfang an wichtig. Und deswegen
[00:29:33] habe ich mich entschieden, das irgendwie auf dem Hetzner-Server frei ins Internet zu stellen. Frei,
[00:29:39] in Anführungsstrichen. Auch den kann man ja absichern. Aber das ist nochmal was anderes,
[00:29:43] finde ich, als wenn das jetzt bei uns hier lokal läuft. Und in der Tat läuft das jetzt auf dem
[00:29:48] MacBook Air, das wir noch über hatten. Der Rechner steht bei mir auf dem Tisch. Das heißt, er ist
[00:29:53] schon mal hier bei uns physisch im Büro und jetzt nicht frei im Internet irgendwie ansprechbar. Und
[00:29:59] er ist auch nicht von außen erreichbar. Und der Rechner selber ist auch Teil unseres Mobile-Device-
[00:30:04] Management. Selbst wenn der jetzt mal mitgenommen wird. Der ist verschlüsselt. Der ist immer mit
[00:30:10] Passwort geschützt. Den können wir aus der Entfernung löschen lassen und sperren. Das
[00:30:14] heißt also auch, selbst wenn der physisch weg käme, wäre das kein Problem. Und er ist auch
[00:30:21] Teil eines sogenannten Tailscale-Netzwerkes. Denn wir wollen ja auch, dass verschiedene Leute Zugriff
[00:30:26] trotzdem auf diesen Rechner bekommen über eine Art internes Netz. Und da haben wir uns halt für
[00:30:30] Tailscale entschieden. Das ist ein super Tool. Da kann man halt ein internes Netz aufmachen, installiert
[00:30:36] dann die entsprechende Software auf den verschiedenen Geräten. Und dann sagt man hier, die gehören
[00:30:40] zusammen. Und dann haben wir praktisch auch andere Rechner, können dann jetzt zugreifen auf diese App,
[00:30:46] die einen Port freigibt. Und dann kann man halt auch von zu Hause darauf zugreifen. Das heißt,
[00:30:52] solange ich mit meinem Rechner, der auch im Tailscale-Netz unterwegs ist, kann ich von überall
[00:30:56] aus auf diesen Rechner zugreifen, der hier bei uns im Büro steht. Und das ist natürlich auch
[00:31:02] ein Riesenvorteil. Und wir können auch schnell wieder Rechner daraus entfernen. Das heißt,
[00:31:05] das Ding hängt halt nicht öffentlich im Internet. Das gibt mir das gute Gefühl,
[00:31:10] dass das relativ gut abgesichert ist. Ja, ich glaube, die Kombination lokaler Rechner,
[00:31:16] den du wirklich selber im Griff hast, und dann die Datenanbindung auch nur da,
[00:31:21] da Schreibrechte, wo man es dem System auch zutrauen würde. Das heißt,
[00:31:25] irgendwie einen Slack schreiben, das geht schon, glaube ich. Oder ein Ticket anlegen,
[00:31:30] aber sonst sehr gut auch absichern, wo auch nur tatsächlich Leserechte möglich sind,
[00:31:36] ist, glaube ich, eine sehr gute Kombination. Aber schon ein bisschen verrückt, dass wir sagen,
[00:31:41] da ist jetzt so ein Agent, der irgendwie schon total mächtig ist. Der lebt auf einem
[00:31:46] MacBook Air auf deinem Schreibtisch. Das ist schon extrem spannend. Das funktioniert natürlich nur,
[00:31:51] weil irgendwo noch so ein bisschen mehr Hardware mit ein bisschen mehr Stromverbrauch steht,
[00:31:57] um das LLM zu betreiben. Aber auch das ist, glaube ich, im Lauf unserer Podcast-Serie hier,
[00:32:04] dass uns nochmal ausprobiert, ob wir den Agenten nicht tatsächlich auch mit einem lokalen Modell
[00:32:08] auf so einem Mac Mini irgendwie betreiben können und welche von den Cases man dann
[00:32:11] tatsächlich mit einem lokalen Modell auch betreiben kann. Wäre vielleicht auch mal ein
[00:32:15] cooles Experiment, dem mal so Real-Life-Aufgaben mit einem lokalen Modell zu geben.
[00:32:21] Das wäre mein Traum, ja.
[00:32:23] Ja, aber tatsächlich extrem spannend, dass das alles möglich ist. Tatsächlich auch mit Cloud
[00:32:31] Code oder Codex oder womit auch immer man tatsächlich anfängt, dann so einen Agenten zu
[00:32:38] bauen, erstmal das Framework aufzusetzen, Chat-Interface zu haben, die Anwendung da zu
[00:32:41] haben und dann tatsächlich Schritt für Schritt das weiter auszubauen. Du hast eben gesagt,
[00:32:47] die ganzen Anbindungen, die du hast, gab es da Highlights, die größten Herausforderungen oder so,
[00:32:52] was so Tools an? Du hast gesagt, API oder MCP-Server, gibt es unterschiedliche Varianten.
[00:32:59] Hast du da noch irgendwelche Highlights? Das heißt, du konntest die alle eigentlich auch
[00:33:04] gut über eine Schnittstelle anbinden, musstest nirgendwo so, ich klicke mit dem Agenten auf
[00:33:08] der GUI rum, um Daten rauszuholen. Das war nicht nötig. Du hattest entweder ein API oder
[00:33:13] einen MCP-Server oder sowas.
[00:33:17] Genau, richtig. Das war eigentlich der problemloseste Teil, ehrlicherweise. Das war
[00:33:22] alles immer nur ein Prompt entfernt. Voraussetzung ist natürlich immer,
[00:33:25] dass das jeweilige Tool eine API-Anbindung bietet oder ein MCP-Server bereitstellt oder beides.
[00:33:33] Und das Schöne an diesem Long-Chain-Framework ist, glaube ich, auch, dass es diese MCP-Einbindung
[00:33:38] schon vorsieht. Das heißt, es war auch relativ trivial, dem dann beizubringen,
[00:33:43] hier das neue MCP-Server kannst du nutzen. Und immer, wenn wir gemerkt haben,
[00:33:49] ach, hier fehlt ja noch was, dann war das Ganze im Prompt entfernt. Dann zeigt man eben hier,
[00:33:53] da ist die API-Doku. Hier, das ist mein API-Key, den habe ich schon in meine Umgebungsvariable
[00:33:58] abgelegt. Kannst du nutzen. Und dann legt der los und baut sich dann die Tools. Das ging also
[00:34:04] wirklich problemlos. Ich habe also fast eigentlich kein Tool gefunden, wo es nicht ging. Das war
[00:34:11] eigentlich der unkomplizierteste Teil tatsächlich. Und immer, wenn man merkt, es fehlt noch was,
[00:34:15] dann baue ich schnell ein. Neu gestartet, zack, hat er wieder einen Zugriff mehr.
[00:34:20] Das war für mich auch nochmal so der Aha-Moment, wo ich dachte, das ist die Zukunft. Da ist bei mir
[00:34:27] der erste Mal dieser Begriff gefallen, AI-first-company, wo man sagt, so muss man eigentlich
[00:34:31] heute Unternehmen aufstellen, dass ein Sprachmodell oder ein Agent immer die Möglichkeit hat, auf die
[00:34:36] meisten Daten zuzugreifen, um sinnvoll helfen zu können. Und da mache ich mir auch gerade viel
[00:34:42] Gedanken, was das eigentlich genau bedeutet. Natürlich Tools nutzen, die die Daten jetzt
[00:34:46] nicht verstecken, sondern man noch Zugriff hat. Aber auch dieses ganze interne Firmenwissen. Wie
[00:34:52] bringt man ihm das jetzt bei? Wir nutzen dafür ein Tool, das nennt sich Outline. Das kann man
[00:34:57] sich vorstellen wie eine Art Wikipedia, wo man Seiten anlegen kann. Andere nutzen wiederum Notion
[00:35:01] dafür. Es gibt viele Möglichkeiten. Andere nutzen dafür ein Obsidian Vault. Ich habe wieder mit
[00:35:06] anderen gesprochen, die nutzen dafür ein GitHub-Repo. Aber irgendwo muss man ja das gesamte
[00:35:10] Firmenwissen, wie man Sachen macht, wofür man steht, vielleicht auch Branding-Geschichten,
[00:35:16] irgendwo ablegen, damit der Agent eine Chance hat, das zu lernen und entsprechend danach zu
[00:35:21] handeln. Und da mache ich mir auch gerade viel Gedanken. Also eigentlich müsste man jetzt das
[00:35:24] ganze Wissen, was irgendwie auf alle Köpfe verstreut ist, inklusive meinem, muss man
[00:35:29] schaffen, irgendwie in so eine Art Knowledge Base zu kriegen, damit im Zweifel ein Agent die
[00:35:34] Möglichkeit hat, darauf zuzugreifen und das zu nutzen. Und ich glaube, das ist ein echter
[00:35:39] Paradigmenwechsel von diesem Silo-Denken hin zu alles dokumentieren, Prozesse dokumentieren,
[00:35:45] wie macht man was. Und wenn das da ist, dann ist natürlich ein interner Agent umso mächtiger,
[00:35:52] was die Unterstützung angeht.
[00:35:54] Das glaube ich. Ich glaube, da wird nochmal ein spannendes Thema, gerade auch, wenn wir
[00:35:59] über größere Organisationen sprechen. Wie vergisst man denn auch, wenn ich mir angucke,
[00:36:05] wo wir so unterwegs sind. Bei manchen Organisationen gibt es halt irgendwie 17
[00:36:09] Beschreibungen für einen und dasselbe, einen und denselben Prozess irgendwie, die alle,
[00:36:15] im Zweifel alle nicht stimmen und irgendwie eine Mischung daraus eigentlich die Wahrheit ist. Und
[00:36:19] wenn du dir so über eine gewisse Historie anguckst, wie auch andere Wissensbasen irgendwie
[00:36:26] sich entwickelt haben, ist glaube ich auch ein spannender Teil, wie gehe ich damit um und wie
[00:36:31] vergesse ich bestimmte Dinge auch wieder und wie verstehe ich, was wichtig ist, was richtig ist
[00:36:36] und was ich vielleicht auch einfach nicht berücksichtigen soll, weil das hat mal jemand
[00:36:39] vor sieben Jahren da reingeschrieben. Aber das hat nichts mehr mit unserer Realität zu tun.
[00:36:44] Total.
[00:36:44] Und je größer die Organisation wird, desto spannender wird das tatsächlich. Wie geht man
[00:36:49] denn damit um? Was ist der Kontext? Was sind die Dinge, die man, die das Modell tatsächlich
[00:36:55] braucht, um die Aufgabe zu lösen? Aber glaube ich auch echt ein sehr spannendes Thema.
[00:37:00] Auch so Sicherheitsberechtigung, also man will ja nicht alles irgendwie, wir sind ein kleines Team,
[00:37:05] wir sind eh intern sehr transparent. Bei uns hat naturgemäß jeder fast Zugriff auf alles.
[00:37:10] Aber das ist ein Großunternehmen, geht das natürlich nicht. Und es darf natürlich nicht
[00:37:14] der Fall sein, dass nur wenn man Zugriff auf so einen Agenten hat, plötzlich, keine Ahnung,
[00:37:17] die Gehaltsdaten aller Mitarbeiter einsehen kann, weil der Agent hat die halt im Zugriff.
[00:37:21] Also ich glaube, da stellen sich noch ganz, ganz viele Fragen. Und genau wie du sagst,
[00:37:25] in großen Unternehmen, da nutzen die hier ein SAP und versuchen da mal an die Daten
[00:37:29] ranzukommen oder dem Agenten Zugriff zu geben. Ich meine, die werden sich da jetzt auch Gedanken
[00:37:32] machen. Aber da sind die Daten natürlich noch viel mehr in irgendwelchen Silos versteckt. Und
[00:37:37] bis man sich ein Unternehmen traut, die in irgendeinem Sprachmodell so in den Zugriff zu
[00:37:43] geben, das wird noch dauern. Aber das wird sein. Also da bin ich mir hundertprozentig sicher.
[00:37:48] Auf jeden Fall. Und das ist ja auch ein spannender Teil, wie du eben gesagt hast,
[00:37:51] wenn man so über AI First Company nachdenkt. Was sind denn die Dinge, wo ich tatsächlich
[00:37:56] Menschen einstellen würde? Was sind die Dinge, wo ich lieber eine KI dran setze,
[00:38:00] weil die das auch gut macht? Oder wie schaffe ich es, mit neuen Rollen dann einfach mehr abzudecken
[00:38:07] und mehr Themen zu adressieren, als ich sonst irgendwie mit den Mitarbeitenden gemacht hätte?
[00:38:12] Ja, extrem spannendes Thema. Das heißt, ihr habt jetzt einen Agenten, der euer Tagesgeschäft
[00:38:20] irgendwie unterstützt, ganz viele Dinge regelmäßig tut. Das heißt, die sind auch
[00:38:26] einfach getriggert. Manche Dinge sind einfach getriggert dann auch durch Conjobs oder was,
[00:38:31] die dann morgens laufen, hast du eben gesagt. Das heißt, manche Dinge laufen von alleine,
[00:38:34] manche dann über das Chatinterface, wo man Dinge nachfragt, recherchiert. Und das ist so
[00:38:39] Tagesgeschäft. Der Agent legt Tickets an, der Agent meldet sich mal auf Slack bei euch und
[00:38:45] kommuniziert irgendwelche Dinge. Das heißt, das MacBook Air arbeitet jeden Tag und meldet sich fleißig.
[00:38:53] Exakt, genau so kann man sich das vorstellen. Wie gesagt, entweder ad hoc reinschreiben,
[00:38:57] Fragen stellen oder halt als Task hinterlegen. Und da kann man halt sagen, bitte jeden Tag,
[00:39:03] jede Woche einmal. Ich hatte auch mal den Task hinterlegt, bitte prüfe unsere App auf
[00:39:07] Sicherheitslücken. Und dann habe ich auch verschiedene Modelle ihm gegeben und dann
[00:39:12] auch Claude Obrus, das starke Modell. Da habe ich nur gemerkt, das war jetzt keine gute Idee,
[00:39:17] nicht weil er nichts finden würde, aber das ist halt richtig tokenintensiv. Wenn der sich
[00:39:20] da durch den Quelltext wühlt. Ich habe auch irgendwann mal so eine Art Kill-Switch eingebaut,
[00:39:26] ein Kosten-Kill-Switch, weil ich vermeiden wollte, dass wenn das Ding im Automatikmodus läuft und
[00:39:32] dass das Ding im Hintergrund Tokens verbrennt oder im Kreis läuft und immer wieder die gleichen
[00:39:37] Abfragen stellt. Da kann man ja sehr schnell auch in so eine Kostenfalle tappen. Mein Albtraum ist,
[00:39:41] dass irgendwann plötzlich die Kreditkartenabrechnung kommt und sagt, ja, schön, dass sie hier 10.000
[00:39:46] Dollar an Tokens ausgegeben haben. Insofern haben wir da auch so ein paar Sicherheitssachen
[00:39:50] eingebaut, dass wenn ein gewisses Limit erreicht wird, dann schaltet er sich selbstständig ab und
[00:39:55] dann schickt er uns eine Nachricht und sagt, hier, ich habe gerade 100 Dollar verbraten. Soll ich
[00:39:58] weitermachen? Und dann müssen wir das aktiv freischalten wieder und sagen, okay, und das ist
[00:40:03] zum Beispiel getriggert worden bei so einem Security-Check. Das war eigentlich ganz witzig,
[00:40:08] weil der hat bis dahin immer ein paar Sachen, jetzt nichts Kritisches, aber wo man sagt,
[00:40:11] okay, sollten wir das mal beheben, fixen. Das machen wir jetzt aber nicht mehr mit den Agenten,
[00:40:15] das machen wir einfach über Code regelmäßig anschieben, weil da nutzen wir die Subscriptions,
[00:40:20] also diese Abos. Da merkt man auch erst mal, finde ich, wie stark subventioniert die sind.
[00:40:25] Das ist ja Wahnsinn, was man mit denen arbeiten kann. Im Agenten über die API würde das Tausende
[00:40:32] Euro kosten, was wir da durchbraten. Da bin ich mal gespannt, wie sich das entwickelt. Denn ich
[00:40:39] weiß nicht, wie lange die großen Anbieter das noch mitmachen werden, dass diese Abomodelle noch
[00:40:44] so stark subventionieren. Das kann für die fast nicht kostendeckend sein. Und dann wäre es
[00:40:48] natürlich der Albtraum, wenn man irgendwann auch da viel Geld ausgeben muss. Aber das ist vielleicht
[00:40:53] mal was für eine andere Folge dann irgendwann. Spannendes Thema, glaube ich, auch regelmäßig
[00:40:58] Thema im Doppelgänger-Podcast, wie hoch kann die Subscription gehen, sodass ich es tatsächlich auch
[00:41:10] noch bezahlen würde. Ich glaube, mein Limit wäre auch relativ hoch, wenn ich von heute auf
[00:41:15] morgen überlegen müsste, ich mache meine Arbeit ohne KI. Das wäre mir auch mehr als 20 Dollar
[00:41:21] im Monat wert, um ehrlich zu sein. Und das sieht man, glaube ich, dann. Aber na ja, das Thema bleibt
[00:41:29] auf jeden Fall spannend. Wie wird sich das alles entwickeln? Weil da hat man ja schon relativ große
[00:41:35] Freiheiten. Aber wir bleiben da dran, verfolgen das vielleicht in dem Kontext noch mal. Du benutzt
[00:41:42] aber im Moment nur ein Modell oder hast du für unterschiedliche Tasks unterschiedliche Modelle
[00:41:47] auch? Hast du das fest eingebaut, dass manche Dinge auch einfach mit kleineren, günstigeren
[00:41:51] Modellen laufen? Unterscheidet der Agenda? Ja, genau. Guter Punkt. Also ich habe angefangen ganz
[00:41:55] naiv mit hier Klozone 4.6. Das ist es, nimm das. Voll drauf. Weil das hat ja auch gut funktioniert.
[00:42:01] Das ist ja ein sehr schlaues, gutes Modell einfach. Ist nicht ganz billig, aber es kann
[00:42:08] jede Aufgabe gut lösen. Ist sehr souverän im Tool-Calling, vertut sich da nicht und weiß,
[00:42:13] wie es die Tools aufzurufen hat. Also wirklich super. Aber man merkt halt auch, es ist nicht
[00:42:18] ganz billig. Da kann eine komplexe Anfrage schon direkt mal ein paar Dollar wegverschlingen. Was
[00:42:23] unter dem Strich wahrscheinlich immer noch okay ist, wenn man dagegen rechnet. Ja gut,
[00:42:25] sonst hätte da ein Mensch zwei Stunden dran gesessen. Aber es muss nicht immer das starke
[00:42:30] Modell sein. Für eine einfache Geschichte reicht auch ein etwas schwächeres Modell,
[00:42:33] was natürlich deutlich günstiger ist. Also habe ich angefangen, mehrere Modelle,
[00:42:37] die bei AWS angeboten werden, anzubieten. Also GLM 5.1, Quen, irgendwas, Kimi 2.5. Und das ist
[00:42:47] ja, hat man jetzt zur Auswahl. Also da haben wir unsere Mitarbeiter mutig versucht, erst mal mit
[00:42:51] dem günstigeren Modell. Wenn ihr dann merkt, das wird nichts oder er bricht plötzlich ab oder das
[00:42:56] Ergebnis ist einfach Quatsch, dann geht auf das nächsthöhere Modell. Und das kann man auch im
[00:43:00] Cronjob einstellen, dass man sagen kann, jeden Morgen um neun mache diesen Prompt und nimm das
[00:43:04] Modell. Und je nach Aufgabe oder auch je nach Druckenumfang nimmt man dann vielleicht mal das
[00:43:11] stärkere oder das schwächere Modell. Aber es ist auf jeden Fall ein Punkt. Und deswegen freue ich
[00:43:14] mich auch jetzt schon, wenn viele weitere tolle, wenn diese ganzen Modelle wie DeepSeek und so
[00:43:20] weiter, die werden ja immer stärker. Und ich hoffe, dass die auch bald auf der AWS Cloud zur
[00:43:24] Verfügung stehen. Dann wird das Ganze für uns nämlich deutlich günstiger und besser.
[00:43:27] Sehr gut. Perfekt. Ich glaube, dann haben wir einen guten Überblick bekommen. Einen Namen hat
[00:43:35] der Agent aber nicht, oder? Oder hat der direkt eine Mitarbeitendenummer bekommen und einen Namen?
[00:43:40] Intern heißt er die AMALYTIX Intelligence Platform, AIP. Und er hat sogar einen Google
[00:43:47] Workspace Account bei uns. Also er kann theoretisch E-Mails empfangen, Kalendereinträge erstellen. Wir
[00:43:51] haben ihm aber verboten, per E-Mail irgendwie E-Mails rauszuschicken, weil das wäre auch nochmal
[00:43:55] so eine Sicherheitslücke. Aber nein, einen eigenen Namen hat er jetzt. Keinen menschlichen
[00:44:03] Namen etc. Aber man kann ihm einen Termin einstellen, wenn man möchte. Oder umgekehrt.
[00:44:07] Sehr schön. Mache ich vielleicht mal, wenn ich die E-Mail-Adresse rauskriege. Perfekt. Dann haben
[00:44:15] wir es, glaube ich, oder? Es war spannend. Ich finde es beeindruckend, total spannend. Und ich
[00:44:22] glaube auch so dieser Weg von OpenClaw hin zu ich-baue-mir-einen-eigenen-agenten.de. Und
[00:44:28] der macht jetzt im Tagesgeschäft mit. Extrem spannend. Vielen Dank.
[00:44:32] Absolut. Ich kann jedem empfehlen, da mal loszulegen. Das war für mich wie gesagt so
[00:44:37] ein Freitags-Nachmittags-Projekt. Dann war die erste Version dieses Chat-Interfaces da. Dann
[00:44:42] kann ich einfach mal zwei, drei Tools einbinden. Und dann merkt man schon die Magie, die sich da
[00:44:46] plötzlich entsteht. Es war wirklich überschaubar vom Aufwand her. Natürlich dann im Detail
[00:44:52] Sicherheit und MacBook einrichten etc. Dann vergeht hier und da schon mal ein bisschen Zeit. Aber ich
[00:45:00] kann jedem nur empfehlen, das mal auszuprobieren in seinem Unternehmen, in seinem persönlichen
[00:45:04] Umfeld. Das muss ja jetzt nicht zwingend im Unternehmensumfeld sein. Kann ja theoretisch
[00:45:08] auch im privaten Umfeld sein. Vielleicht sprechen wir ja nächstes Mal in der nächsten Folge,
[00:45:12] wie AI als Fitness-Coach agieren kann. Da kann ich auch was zu erzählen. Das ist aber das gleiche
[00:45:16] Prinzip nämlich. Ich bin gespannt. Man sieht ja auch, GPT und Cloud gehen ja auch in die
[00:45:22] gleiche Richtung. Auch bei Cloud kann man ja mittlerweile Google Workspace anbinden. Andere
[00:45:28] Tools sind angebunden. Das wäre für mich jetzt hier im Unternehmen nicht in Frage, weil ich will
[00:45:35] halt wirklich kontrollieren, wo gehen hier welche Daten hin? Wer liest hier mit? Das wäre mir noch
[00:45:40] ein Ticken zu heiß. Aber da geht die Reise ja auch bei den größten Anbietern hin. Also den Bereich
[00:45:44] auf jeden Fall mal im Auge behalten. Sehr schön. Gut. Trotz, ich würde sagen, Folge 1 haben wir
[00:45:52] fertig. Und dann freue ich mich auf die nächsten Themen. Ja, ich mich auch. Kai, vielen Dank.
[00:45:58] Alles klar. Mach’s gut. Ciao, ciao.