# Strategic Deployment of Enterprise AI Agents

**Podcast:** AI FIRST Podcast
**Published:** 2026-08-28

## Transcript

Herzlich willkommen zum AI First Podcast.
Heute geht es um den State of AI Agents und ich habe Jonas Dietzun, den Gründer von...
Beam zu Gast.
Wir hatten das letzte Mal vor ungefähr einem halben Jahr einen Podcast aufgenommen, wie er sein CEO-Office aus KI-Agenten gebaut hat und noch einige andere Themen drumherum.
Ist super angekommen, deswegen dachte ich, wir müssen unbedingt ein Update machen.
Ich will heute mal verstehen, wo stehen wir eigentlich mit KI-Agenten oder jetzt wird ja schon über agentische Systeme gesprochen.
Was ist das eigentlich?
Was ist der Unterschied und was muss ich jetzt tun?
Wie sieht eigentlich so ein Schritt für Schritt...
Vorgehen aus von einem Unternehmen, was den ganzen Tag lang KI-Agenten in Prozesse bringt.
Wie macht man das?
Was funktioniert?
Worauf muss man achten?
Was sollte man bleiben lassen?
Und wir sprechen auf jeden Fall auch über die Weiterentwicklung vom CEO-Office, weil ich will natürlich wissen, was ist in den letzten sechs Monaten da in deinem Setup passiert?
Jonas, ich freue mich auf die Folge.
Schön, dass du da bist.
Ich freue mich jedenfalls.
Sehr schön, wieder da zu sein.
Erzähl nochmal kurz, wer du bist und was ihr mit Beam macht.
Genau, Jonas, einer der Gründer von Beam.
Mein Hintergrund ist, ich habe mal ursprünglich Elektrotechnik und BWL gemacht, dann Kurzberatung angeschaut, aber relativ schnell beschlossen, dass Firmenaufbau mehr Spaß macht und das die letzten zehn Jahre gemacht.
Ich habe tatsächlich in AI angefangen, damals bei Konux, wo wir ja eigentlich Daten von Sensorik ausgewertet haben und daraus Predictive Analytics oder darauf gemacht haben.
Und damals haben wir gesehen, okay, wir können irgendwie crazy Sachen mit AI machen.
Rocket Internet was gebaut, dann Razer Group gegründet, was relativ groß geworden ist und dann tatsächlich mich mit einem aus dem Studium zusammengetan und Beam gegründet.
Und damals so ganz, am Anfang haben wir naiv gesagt, hey, AI entwickelt sich exponentiell, Menschen nicht, also bauen wir sie einfach nach.
Und dann haben wir am Anfang ein bisschen rumprobiert und dann kam die Simulacra-Paper raus über AI Agents.
Irgendwann hat gesagt, okay, wir bauen jetzt einfach Agents und sind auf diese Journey gegangen die letzten Jahre.
Und von den Anfängen, wo wir gedacht haben, okay, cool, jetzt können wir AI nutzen, um irgendwie komplexe Sachen zu machen.
und nichts hat funktioniert.
Bis hin zu, wir bauen für Großunternehmen und Middständler diverse Agents, um Prozesse zu automatisieren, primär im Finance und Data-R-Bereich und davon individuelle Insellösungen, wo wir sagen, okay, wir haben einen Agent, der einen bestimmten Prozess oder eine Aufgabe macht, jetzt immerhin mehr, wie du es auch schon erwähnt hast, zu Systemen, die tatsächlich dann komplette Teams augmenten oder supporten und Stück für Stück mehr Aufgaben übernehmen und zusammenarbeiten fleißig.
Wir haben das letzte Mal im Februar diesen Jahres gesprochen.
Das war auf jeden Fall eine Zeit, erinnere ich mich noch dran, wo gerade Antropic fleißig getrommelt hat.
Krasse Modelle sind rausgekommen, mit denen man auf einmal viel mehr machen konnte, viel mehr Autonomität in so Agenten hatte.
Und jetzt ist nochmal ein halbes Jahr, sind wir die Linie weiter runtergegangen.
Was würdest du denn sagen, wo stehen wir heute?
Sam Altman hat die Singularity ausgerufen.
da oder was würdest du sagen, was ist der Stand von KI-Agenten heute?
Also, jetzt will man noch unfassbar schnell, wie sich Sachen entwickeln.
Ich glaube, wir haben noch mal bessere Modelle die letzten sechs Monate gesehen.
Ich glaube, so wirklich der Sprung war so Herbst letzten Jahres, wo man gesehen hat, okay, ich kann jetzt Opus schon wirklich komplexe Aufgaben geben und das funktioniert ganz gut.
Jetzt haben wir irgendwie 5.6 Sol, wir haben Fable und wir sehen, okay, die Modelle sind noch mal wieder besser geworden.
Ich glaube aber gleichzeitig, der Grenzennutzen ist so ein bisschen abnehmend.
Also klar, wenn ich jetzt code, dann ist das noch immer besser, weil es noch mehr Sachen direkt versteht.
ich kann es meine Probleme jetzt auch schon lösen.
Und dementsprechend geht es jetzt tatsächlich eher darum, wie bringe ich das in Produktion, wie baue ich daraus Systeme?
Nicht nur irgendwie, wie habe ich die Intelligenz auf der einen Seite, sondern wie baue ich jetzt wirklich produktiv Systeme?
Und auch zu welchen Kosten kann ich das machen?
Ich glaube, was wir dann im April, Mai gesehen haben, dass sie alle angefangen haben, über die Kosten zu beschweren.
Dann kamen die Chinesen oder die DeepSync-Modelle und auf einmal waren die Kosten doch nicht mehr ganz so ein Thema, beziehungsweise weniger.
Und jetzt gerade, glaube ich, nochmal sehr interessant, die letzten drei Monate, wie stark die Kosten gesunken sind.
um eigentlich eine Intelligenz zu nutzen, die, sagen wir mal, schon sehr, sehr gut ist, vielleicht so ein bisschen auf unserem Level und eigentlich diese Aufgaben übernehmen kann, aber für Kosten, die halt irgendwie auf ein, zwei Prozent sind von dem, was wir über vielleicht Januar, Februar gesprochen haben.
Es sind ja dann so nochmal ein Sprung in den Modellfähigkeiten kam mit Fable zum Beispiel.
Habt ihr für diese letzte Modellgeneration Use Cases gesehen, neben Coding, wo man diese Modelle wirklich braucht?
oder sie einen klaren Mehrwert bieten zu dem, was es vorher gab?
Also ich, nicht wahnsinnig viel.
Also erstmal, Fable war immer super nervig, weil nichts funktioniert hat.
Ich glaube, Fable war nicht so der Markteintritt, den sich da alle vorgestellt haben.
Ich sehe es vielleicht jetzt so mit Codex oder mit Sol und den neuen 5.6 Generationen.
Wo das schon hilft, ist, wenn ich extrem viele Informationen zusammensuchen muss und drüber nachdenken muss.
Ja, dann hat man vielleicht so ein bisschen Vorteil, aber ich ehrlicherweise sehe jetzt auch nicht mehr den Unterschied zwischen Sol und Terra.
Und so wahnsinnig die Riesenunterschiede sehe ich nicht mehr.
Und ich glaube, was für mich zum Beispiel die wichtigste oder beste Neuerung ist, waren dann die Sachen drumherum, ob man das jetzt Harness nennt oder das System, ob das jetzt ein Goal-Mode ist, wo ich dem Agent sagen kann, hey, pass mal auf, arbeite da dran und sag mir Bescheid, wenn du fertig bist.
nicht mehr irgendwie dauernd rechts und nichts kopieren musste.
Ich glaube, diese ganzen kleinen Sachen, die drumherum passieren, sind deutlich interessanter.
Und jetzt, ich glaube, jetzt die letzten Wochen auch mit Cursor und jetzt kommt von OpenAI dann auch wieder Cloud-Agents.
Das ist dann nochmal das Nächste, dass ich dann mein Laptop vielleicht nicht immer mehr brauche, sondern das einfacher steuern kann.
Aber Modelle, ja, ist noch nett.
Doch, eine Sache, die noch interessant ist, mathematische Probleme jetzt die letzten zwei, drei Wochen, die auf einmal alle gelöst werden.
Also ich glaube, da sehen wir jetzt, wo ungefähr die Modelle sind.
Also die Top-Mathematiker, die zehn Jahre an Problemen arbeiten, die werden auf einmal arbeitslos, weil die Modelle das machen.
Aber das ist ein bisschen übermeinfähig, normalerweise.
Ja, aber hast du das mitbekommen, wie der eine dieses, ich kriege es nicht mehr zusammen, welches mathematische Problem, der da gelöst hat, aber wie der das gelöst hat?
Also der hat ja wirklich das Modell einfach immer wieder angestupft und hat gesagt, Try again, try harder.
Ja, genau.
Make it better.
Ja, und das ist super interessant.
Also ich glaube, die Probleme, die wir auch vorher bei LLMs haben, die haben wir immer noch.
LLMs sind immer noch faul, haben immer noch manchmal einfach keinen Bock, was zu machen.
Und selbst wenn du einen Speck schreibst und sagst, pass mal auf, du hast hier eine klare Anleitung, was du machen sollst, dann gibst du ihm was, dann mach das und dann fragst du später, hast du das jetzt wirklich gemacht?
Ja, nee, ich habe doch irgendwie nur die Hälfte gemacht.
Also die Probleme gibt es immer noch.
Insofern haben diese Techniken interessanterweise immer noch Erfolg.
Ja, das ist auch, würde ich sagen, die größte Veränderung, die ich durch Fable gesehen habe, nämlich vor allem einen niedrigeren Kontostand.
Es hat eine Zeit lang, hatten wir das Gefühl, wir können jetzt auf den Teppich fliegen, aber dann sind wir doch wieder runtergegangen und wieder stärker ins Micromanagement und gesagt, nee komm, lass uns mal doch so ein bisschen enger wieder dran sein.
Very true, ja.
Okay, gut.
Also, da sind wir.
Jetzt lese ich immer mehr, dass wir uns, das KI-Agenten ist ja schon wieder alt und wir kommen eigentlich zu agentischen Systemen und du musst eigentlich in agentischen Systemen und agentic AI denken.
Kannst du einmal aufklären, was denn da der Unterschied ist?
Ja, und es ist ein bisschen schließend und interessant.
Wir sagen mittlerweile auch intern, dass ein Agent ein System ist.
Ich glaube, man hat das vielleicht am Anfang ein bisschen simplifiziert.
Man hat gesagt, okay, ein Agent ist irgendwie...
eigentlich ursprünglich, woher kommt das?
Ich habe einen Prompt oder einen LLM-Call und ich führe ein Tool aus.
Und dann hat man diesen Begriff Agent erstmal auf alles geschrieben, was es rechts und links irgendwie gibt.
Ich mache irgendwie einen Go-to-Market-Agent, ich mache einen Research-Agent und ich mache eigentlich alles irgendwie in Agent.
Und dann hat man über Zeit gesehen, naja, okay, es gibt jetzt sehr viele unterschiedliche Ausprägungen von Agenten.
Ganz am Anfang hatten wir immer die Diskussion, naja, okay, was ist jetzt der Unterschied zwischen Chatbot um einen Agenten?
Also Chatbot ist, ich stelle eigentlich nur eine Frage, Agent macht tatsächlich was und jetzt dann haben der auch schon mal gesagt, ja, also du kannst jetzt einen Agenten machen, der macht nur irgendwie Data Extraction aus dem PDF.
Aber ich kann auch einen Agent bauen, der ist eigentlich ein Multi-Agent-System, der macht hier den ganzen Order-Abwicklungen.
So, und dann sieht man, dass dieser Begriff ein bisschen fließend ist.
Und ich glaube, was jetzt klarer geworden ist, dass ein Agent nicht einfach nur ein Prompt ist, was ich irgendwo draufschmeiße und dann macht das vielleicht irgendwie ein, zwei Aktionen, sondern ist es ein System, was auf der einen Seite aus dem LLM besteht.
Ich habe vielleicht auch...
deterministische Variablen oder Prozesse da drin.
Beispielsweise muss ich irgendwelche Kalkulationen machen oder ich muss einfach nur Entscheidungen treffen, die einfach deterministisch ausgeführt werden.
Und dann habe ich bestimmte Loops, wo der Agent was ausführt und dann gehe ich eigentlich in den Retry und schaue, okay, habe ich bestimmte Kriterien, die jetzt erfüllt sind oder die ich nicht...
habe und muss das vielleicht nochmal machen.
Und dementsprechend sagen wir mittlerweile, du musst das ganze System anschauen und für uns ist dann eigentlich der Agent wieder das System.
Und jetzt kann ich das natürlich wieder nebeneinander pflanzen und sagen, okay, ich habe jetzt irgendwie mehrere Agenten, die eigentlich dann wieder ein großes System mehr geben, was dann irgendwie meine Firma oder mein Team ist.
Aber ich glaube auch weiterhin, die Grenzen werden ein bisschen fließend sein.
Ich glaube, was wichtig ist, dass diese einfache Definition von eines Agenten halt nicht ausreicht, weil die Fragestellungen oder auch die komplexen Probleme, die so ein Agent löst, dem angepasst sein muss, was das Problem ist.
Und das ist halt nicht immer ganz einfach zu lösen, indem ich nur einen prompt drauf schmasse.
Manchmal habe ich auch das Gefühl, dass im KI-Bereich neue Begrifflichkeiten und so dann einfach wieder erfunden werden, um einfach wieder was erzählen zu können und irgendwie wieder krasser zu sein als die anderen.
Ja, das ist, glaube ich, auch ein bisschen so schon.
Also jetzt hat man irgendwie, ich glaube, vor drei Monaten kamen so Operating Loops auf, die auf einmal der heiße Scheiß waren.
Dann hat man festgestellt, okay, Operating Loops, vielleicht ist das eine Automation, vielleicht auch nicht, vielleicht ist das was anderes.
Und ich glaube, da sind die ganzen Grenzen sehr fließend und ändern sich dauernd.
Und wichtig ist, am Ende, ja, es passiert wahnsinnig viel.
Für uns ist manche oder für mich auch manchmal noch so ein bisschen der North Star.
Also was machen wir eigentlich?
Wir versuchen ja Arbeit zu ersetzen oder wir machen Arbeit, die vorher eigentlich exklusiv wir Menschen gemacht haben.
Und wenn man anschaut, was wir als Menschen machen, das ist schon sehr komplex.
Ich nehme Informationen auf, ich schreibe Informationen, dazwischen denke ich nach.
Aber ich kann jetzt auch warten auf einmal und sagen, okay, jetzt mache ich erst morgen damit weiter oder in drei Wochen.
Das heißt, ich habe ganz viele verschiedene Bausteine, die ich eigentlich zusammenbaue.
oder die ich als Mensch nutzen kann, um so eine Aufgabe auszuführen.
Und jetzt stellt man fest, natürlich, wenn ich jetzt eine Strategie plane oder wenn ich eine Sales Order mache, ich brauche auch all diese Bausteine.
Ich kann es halt nicht abkürzen.
Und dadurch wird mein System immer komplexer und vielleicht auch komplexer, als ich das eigentlich gedacht habe, wo ich vielleicht am Anfang naiv hingegangen bin und habe gesagt, hey gut, ich mache da jetzt prompt, das LLM wird das schon lösen.
So funktioniert es halt nicht, leider.
Ja, das kennt wahrscheinlich jeder, der mal dann wirklich diesen Agenten in einen produktiv laufenden Prozess, der auch einen gewissen Durchsatz hatte, so einsetzen wollte, dass man den nicht babysitten musste.
Da kommt das dann schnell raus.
Ich habe ein Zitat gefunden oder eine Headline habe ich gefunden.
Und zwar McKinsey-CEO Bob Sternfeld sagt, dass das Unternehmen jetzt 60.000 Mitarbeiter hat und 25 davon sind KI-Agenten.
Was sagst du zu solchen Aussagen?
Seht ihr das auch bei euren Kunden?
Ja, ich glaube, diese Aussagen muss man immer so ein bisschen mit Vorsicht genießen, weil wir haben ja gerade festgestellt, was ist jetzt ein Agent?
Also hat jetzt jeder Agent irgendwie, ist das quasi vollwertig wie ein Mitarbeiter?
Und da würde ich mal ganz klar sagen, bei McKinsey wahrscheinlich nicht.
Die Mitarbeiter sind sehr gut und ich glaube, dass die meisten Agenten noch nicht so fähig sind wie der durchschnittliche Mitarbeiter.
So, das heißt eigentlich, ich habe wahrscheinlich irgendwie viele kleine Agenten, die irgendwas machen.
Und es kann sein, dass ich jetzt einen Präsentationsagent habe und einen Excel-Agent.
Aber wenn ich jetzt den so definieren würde, dann brauche ich eigentlich McKinsey nicht unfassbar viel mehr.
Da habe ich einen Research-Agent, einen Excel-Agent, einen Präsentation-Agent.
Insofern, man sieht schon da, da bin ich eigentlich durch.
Also da sehe ich schon, je nachdem, wie ich das jetzt definiere, habe ich ganz unterschiedliche Grenzen.
Und insofern würde ich solche Aussagen immer so ein bisschen mit Vorsicht genießen.
Das ist die eine Sichtweise.
Also wie schneide ich den Agent?
Die andere Frage ist auch, jeder Agent gerade braucht eine Governance.
Ich kann nicht hingehen.
Also theoretisch könnte ich natürlich sagen, alle meine Agents arbeiten irgendwie autonom und die laufen einfach.
Aber de facto ist es ja so, dass jeder Agent auch eine bestimmte...
Überwachung braucht, wo jemand drauf aufpasst.
Und ich glaube, da könnte die Racial schon ungefähr hinhauen, dass jeder Mitarbeiter hat irgendwie ein bisschen weniger als einen Agent gerade.
Ich glaube, da ist auf jeden Fall noch Luft nach oben.
Insofern, wenn man das dann so schneidet, dann könnte das wieder Sinn machen aus der Governance-Perspektive.
Aber ich glaube, man sollte es immer aus unterschiedlichen Sichtweisen, wie habe ich das eigentlich gerade geschnitten und wie passt da drauf jemand aufschneiden, um dann zu überlegen, ob das jetzt Sinn macht oder nicht.
Und ich glaube, es ist genauso wie ein bisschen so, ja, es ist cool.
Am Ende die Frage ist, wie sehr hilft das in der Arbeit?
Ja, das würde mich aber nochmal interessieren, weil ich glaube, da gibt es ja so ganz unterschiedliche Philosophien.
Wir verfolgen da auch, wir sagen ja, KI eher als System zu denken und eher ein Betriebssystem zu bauen, auf dem KI möglichst gut arbeiten kann.
Und im System werden dann die Prozesse, Daten, Regeln, Schnittstellen in Tools organisiert und KI kann darauf dann zugreifen.
mit den Prozessdokumentationen, Schnittstellen, Daten usw.
arbeiten, um die Aufgabe zu erledigen.
Versus andere sagen, nein, wir bauen hier eine hybride Organisation mit Agenten und die sind halt Mitarbeiter und haben halt einen Namen, ein Gesicht, haben ein Stellenprofil, kriegen Feedbackgespräch und Co.
Und ich glaube, es gibt Argumente für beides davon und ich glaube, es ist auch nicht nie schwarz-weiß.
Aber wie geht ihr denn in Unternehmen vor?
Kommt ihr sicherlich natürlich von dem Problem, nehme ich mal, und guckt euch an, wo kann mehr Geld verdient werden oder Kosten eingespart werden.
Aber schneidet ihr dann die Rollen in KI-Agenten oder nehmt ihr die Prozesse auseinander und KI-Agenten erfüllen dann eine Funktion innerhalb dieses Prozesses?
Eher Letzteres.
Also wir kommen immer von, was ist das Business-Problem, was ich lösen möchte und was muss ich dafür bauen, damit ich dieses Problem löse.
Und da auch, wir sind jetzt nicht so, okay, dann schmeißt ein Agent drauf und dann wird das gelöst.
Es gibt viele Business-Probleme, die ich eigentlich auch nicht wirklich mit AI lösen muss, sondern ein Agent ist vielleicht ein Teil meines Business-Problems.
Und wenn ich jetzt beispielsweise viele Rechnungen erstellen muss oder überprüfen muss, dann ja, ein Agent in der Definition, dann kann ein Teil davon irgendwie LLM-Calls sein, aber ich werde auch sehr viel Code-Execution da drin haben.
So, und wenn ich jetzt irgendwie hingehe und sage, okay, ich baue irgendwie nur meinen einen Mitarbeiter, dann bin ich vielleicht nicht so flexibel, sondern wir schauen immer, was müssen die verschiedenen Bausteine sein, die ich zusammenbringe und was ist die beste Lösung dafür.
Und jetzt ist es für...
Menschen häufig sehr hilfreich zu sagen, okay, das ist jetzt mein einer Agent, der macht diese spezifische Aufgabe, einfach weil wir so gewohnt sind, irgendwie zu arbeiten.
Ich habe ja meine anderen Mitarbeiter, deswegen ist das sehr hilfreich und macht das sehr einfach.
Dementsprechend kann es am Ende doch sein, dann sagen wir, okay, das ist jetzt sein Sales Agent hier und der heißt jetzt, weiß ich nicht wie, aber wichtig ist, wir kommen eigentlich immer vom Problem, zerlegen das dann und überlegen uns dann, wie wir das zusammenbauen, eher als jetzt dann zu sagen, hier, guck mal, da machen wir jetzt auf jeden Fall mal drei Agents hin.
Ich würde gerne mit dir mal so eine Checkliste erarbeiten, weil ich glaube, ganz, ganz viele Unternehmen sind ja gerade da dran und dann geht es mal so wild los, wie wahrscheinlich bei McKinsey wird ein Tool ausgerollt und jeder kann sich hier seine eigenen Agents bauen, dann hast du irgendwann 25.000 Stück davon, keiner weiß mehr, wer eigentlich irgendwas davon macht und wahrscheinlich das meiste wird genau einmal genutzt und dann nicht mehr.
Und dann gibt es ein paar klare Use Cases.
Du hast jetzt Rechnungsprüfung, hast du gerade angesprochen, ich glaube Customer Support und so.
Ich glaube, diese gängigen, größeren Anwendungsfelder sind auch klar.
Aber die Frage ist ja, wie komme ich von meinem heutigen Prozess und dem Business-Problem, was ich habe, hin in eine produktive Anwendung, wo KI sinnvoll eingesetzt wird, qualitätsgesichert ist und mir am Ende ...
Geld spart oder Geld verdient.
Und wenn man hier mal so ein bisschen, ich würde gerne mit dir so ein bisschen dieses Playbook erarbeiten, also was kann ich jetzt tun als Business Leader, der genau dorthin kommt möchte?
Was hat sich da bewährt?
Vielleicht fangen wir mal ganz oben an.
Was sind meines Erachtens oder unseres Erachtens die wichtigsten Kriterien eigentlich, ob ich einen Agent einsetzen kann?
Das Erste ist, ich brauche eine bounded oder eine begrenzte Aufgabengebiet.
Wenn ich was habe, was unbegrenzt ist, was theoretisch immer in alle Richtungen laufen kann, dann ist das schwierig zu bauen.
Wenn ich jetzt sage, pass mal auf, ich will einen Agent, der eine Firma baut, das ist unbounded, dann kann ich theoretisch in alle Richtungen gehen.
Da werde ich nicht glücklich mit werden.
Wenn ich einen klaren Prozess habe, der irgendwie abgetrennt ist, wo ich ein klares Start, ein Ende und irgendwie was dazwischen habe, dann ist das was, wo ich idealerweise mit anfangen kann.
Und je weiter meine Grenzen sind, desto größer das Ganze ist, desto schwieriger wird es natürlich auch, weil ich dann mehr Fähigkeiten in diesem Aiden brauche.
Das Zweite ist, vielleicht nochmal zurück, warum es eigentlich...
Was fuelt denn gerade Agents?
Warum reden wir über Agents?
Es ist daraus gekommen, dass ich LLMs habe, die jetzt in den letzten drei Jahren so gut geworden sind, dass sie eigentlich Entscheidungen treffen können, dass ich Judgen können, dass ich Entscheidungen vorbereiten kann, dass ich Verständnis habe.
Ich hatte früher auch AI-Systeme, die konnten mir halt Trading machen und konnten das super schnell machen.
Aber wo es jetzt eigentlich darum geht, ist, dass dieses Judgment, was vorher eigentlich uns Menschen exklusiv vorbehalten war, auf einmal in der AI machen kann.
Beispielsweise, wenn ich jetzt eine Entscheidung treffen muss, die nicht ganz eindeutig ist, wenn ich ein deterministisches System habe und sagen kann, 3 plus 3 ist 6, okay, dann ist das irgendwie über 5 Euro, also schiebe ich das nach A, dann ist das, das konnte ich auch schon vorher machen.
Aber wenn jetzt ein bestimmtes Judgment drin ist, dann ist das was, was ich jetzt eigentlich erst seit kurzem machen kann, wo LLMs oder dann auch dementsprechend Agents sehr gut sind, beziehungsweise mir jetzt überhaupt erstmal die Möglichkeit geben, das zu lösen.
Das heißt, erstmal grobes, ich brauche was Begrenztes und das Zweite ist, Judgment sollte eine Rolle spielen, ansonsten kann ich auch ein deterministisches System nutzen und brauche jetzt, wenn ich nur irgendwie nach Fachbegriffen sortieren muss, dann brauche ich jetzt auch keinen Agent dafür im ersten Schritt erstmal.
Das ist mal so übergeordnet als ersten Input oder ersten Schritt.
Da hätte ich zwei Fragen schon mal zu.
Nämlich das erste, der abgegrenzte Prozess.
Wie glaubst du, also weicht sich das nicht auf, indem die Modelle immer besser darin werden, komplexere Aufgaben über einen längeren Zeitraum auch zuverlässiger?
stabiler auszuführen, also dass dieses Autonomiegrad zunehmen kann und sich diese Grenzen verschieben?
Das glaube ich hundertprozentig und es wird auch immer breiter.
Also Sachen, die wir vor zwei Jahren nicht machen können, können wir auf einmal machen.
Und dass wir jetzt einen Agent haben, der eine Firma baut, das sei auch so, weil ich glaube, dass das auch funktionieren wird.
Die Frage ist, wenn ich jetzt als Firma hingehe oder als Verantwortlicher und sage, ich mache jetzt das große Ganze, wie erkenne ich dann, ob das jetzt gut funktioniert?
Wie kann ich das jetzt gerade bewerten, wenn die Outputs ja irgendwie Könnte gut sein, könnte auch nicht so gut sein.
Ich weiß es nicht so ganz.
Und das heißt, wenn ich diese Begrenzung nicht mache, dann habe ich andere Probleme, die damit kommen, die da heißen, ich kann eigentlich gar nicht klar sagen, ob der Agent das jetzt gerade gut macht oder nicht.
Dann kann ich keine Evaluation-Criteria machen.
Dann kann ich irgendwie nicht klar sagen, ob ich jetzt eigentlich fertig bin oder nicht.
Insofern, glaube ich, ist das trotzdem jetzt erstmal für den produktiven Einsatz wichtig.
Nichtsdestotrotz wohl wissend, dass diese Grenzen immer weiter auseinander gehen.
Und bei der Entscheidungsfähigkeit?
Da verstehe ich total, also wenn etwas, wenn ich keine Flexibilität brauche, um verschiedene Daten zu analysieren, daraus eine Entscheidung abzutreffen, die nicht immer in eine, also nicht deterministisch mit diesem Rechenbeispiel zum Beispiel, was du genannt hast, geht.
Da gibt es ja dann aber wahrscheinlich auch Level darunter, weil ich würde sagen, Entscheidungen treffen ist ja auch wahrscheinlich noch was, was Menschen ganz gut kennen können, die manchmal noch mehr Kontext haben oder Zwischentöne oder sowas kennen.
Also eine Entscheidung ist ja nicht gleich eine Entscheidung.
Kannst du hier das noch, lässt sich das spezifizieren, was das für Entscheidungen sind?
So Low-Stake-Entscheidungen zum Beispiel, die so wichtig sind?
Ich glaube, auch da kann man wieder den, das ist am Ende kein irgendwie Black or White, sondern das ist ein Continuum.
Also ich kann hingehen bis hin zu, ich habe hochkomplexe, sagen wir mal einen Versicherungsfall, wo ich entscheiden muss, ob ich das jetzt auszahle oder nicht.
Da muss ich sehr viele Informationen zusammenziehen, um am Ende dann darüber nachzudenken und zu einer Entscheidung zu kommen.
Und da auch.
Das war vor zwei Jahren noch nicht so, aber mit den Thinking Steps im Modell sind die da halt sehr gut drin geworden, nochmal dann irgendwie zwei Schritte dazwischen zu machen, um zu dieser Entscheidung zu kommen.
Ich glaube, man kann das auch sehr einfach machen.
Ich muss vielleicht auch erstmal nur eine Entscheidung dadurch helfen, welche Daten ziehe ich mir eigentlich?
Das ist ja auch schon im ganz plumpen Fall auch eine Entscheidung.
Sagen wir mal, ich habe irgendwie jetzt zwei conflicting oder ich habe zwei PDFs und in beiden steht irgendwie was drin und ich muss jetzt trotzdem noch was entscheiden.
Deterministisch ist das jetzt in dem Sinne nicht mehr, sondern ich muss ja entscheiden, welche Information ist jetzt relevanter als die andere und an welche glaube ich.
Und jetzt kann ich nochmal dann wieder weiter drüber nachdenken.
Das heißt, auch das kann ich im sehr Einfachen sehen, was einfach nur in der Informationszusammenziehung ist, bis hin zu, ich habe den Case vielleicht beispielsweise in der Versicherung.
Was ich jetzt auch als AI gar nicht entscheiden dürfte, aus regulatorischen Gründen, wo ich dann wirklich eine Entscheidung treffe, um zu sagen A oder B.
Ich glaube, es gibt sehr viele Abzweigen oder Zwischenschritte dazwischen, die relevant sind.
Okay.
Empfiehlt sich auch nicht immer, da wieder mit dem Komplexesten anzufangen, sondern erstmal mit dem bisschen einfacheren Sachen.
Ja, ja, ja.
Okay, also wir haben eine gewisse Begrenzung und wir brauchen die Fähigkeit, eine Entscheidung zu treffen.
Das sind schon mal so zwei Checkmarks am Anfang, bevor wir weitergehen.
Kurz in eigener Sache.
Wenn dir der AI First Podcast gefällt und du mehr spannende Inhalte und hochkarätige Gäste hören möchtest, dann freue ich mich über deine Unterstützung.
Mit einer Fünf-Sterne-Bewertung und einem Abo für den Podcast hilfst du uns, sichtbarer zu werden und AI First weiterzuentwickeln.
Für dich und die gesamte Community.
Ich danke dir.
Was ist das nächste Wichtige?
Ich muss mir überhaupt erstmal anschauen, lohnt sich das, also aus der Business-Perspektive, lohnt sich das Ganze zu automatisieren oder lohnt es sich dafür, einen Agent zu bauen?
Wenn ich eine Entscheidung wie einmal im Monat treffe, dann ja, dann kann ich aber auch irgendwelche Co-Pilot-Lösungen nutzen, die mit mir zusammenarbeiten, als dass ich jetzt einen Agent dafür aufsetze, wo dann die Zielsetzung schon über Zeit eigentlich ist, dass er autonomer und autonomer arbeitet und nicht mehr eigentlich die Verantwortlichkeit über das.
abgebe und mache.
Also ganz viel, was wir heute häufig sehen, ist, ja, ich muss mir auf der einen Seite die Natur des Prozesses anschauen, aber ich muss mir auch den Business Case hinter dem Prozess anschauen und überlegen, okay, macht das jetzt Sinn, macht das keinen Sinn?
Tritt das häufig genug auf?
Ist das relevant?
Ist das nicht relevant?
Und dann nachgeordnet auch die ganzen sich daraus resultierenden Fragestellungen zu beantworten.
Was ist, wenn ein Fehler passiert, ist es schlimm?
Kann ich sagen, okay, wenn ein Fehler passiert, ist es eigentlich nicht so wahnsinnig dramatisch oder ist es jedes Mal so, dass ich eigentlich eine sehr hohe Genauigkeit brauche?
Daraus ergibt sich dann nämlich, wie ich das System aufbauen muss und welche Fehlertoleranz ich in dem System haben kann, um diesen Prozess einem Agent zu geben oder nicht.
Das heißt, ich komme über die Fehler und die Genauigkeit, die ich brauche, eigentlich zum Grad der Autonomie, den ich dem Agent geben kann.
Und dann auch dementsprechend im Aufwand den ich brauche, um dieses System zu bauen oder den Agent zu bauen.
Guckt ihr euch denn hier jetzt die Ende-zu-Ende-Prozesse an oder guckt ihr euch Teilprozesse an oder Schritte?
Also wir schauen uns schon.
Es wird ja immer gesagt, wo komme ich her?
Es wird ja immer gesagt und ich merke das auch gerade, dass immer weniger über so Use Cases gesprochen wird, immer mehr eigentlich über die Ende-zu-Ende-Prozesse und wie kann man diesen Prozess neu denken?
Das ist dann die Frage.
Und das aber zu tun, ist ja oft gar nicht so trivial, weil wir haben ja jetzt nur mal 100 Jahre gelernt, diesen Prozess so zu machen und jetzt zu sagen, wir verändern den komplett, sodass er möglichst für KI optimiert ist und KI nativ aufgebaut werden kann, ist ja gar nicht so leicht.
Also tatsächlich ist das sehr schwer und ich verstehe, dass viele sagen, okay, ja gut, aber wenn jetzt AR kommt, dann kann ich ja alles neu denken.
Ja, kann ich.
Aber es ist gar nicht so ganz einfach, ein System eigentlich neu zu denken und zu bauen, während ich ein altes System noch irgendwie am Laufen habe.
Und ich glaube, man muss da aufpassen.
Manchmal kann das Sinn machen, aber häufig macht das keinen Sinn und man tut vielleicht gut erst mal dran, den Prozess.
Ich weiß, dass dieses irgendwie ein shitty Process zu automatisieren, macht nicht unfassbar viel Sinn.
Und die Komplexität, das direkt noch wieder neu zu bauen, dann habe ich eigentlich analog wie ein IT-Projekt, dann baue ich auf einmal alles neu.
Da gibt es viele andere Fehlerquellen, die dann in dieser ganzen Änderung auftreten können, weswegen das dann auf einmal dann doch nicht funktioniert.
Zu deiner Frage, wir kommen immer eigentlich aus zwei Perspektiven.
Die eine Perspektive ist, wir wollen verstehen, was ist...
Die Vision, wo soll die Reise hingehen?
Also wie baue ich ein AI-Native-System?
Und mit unseren Kunden gehen wir auch hin und sagen, pass mal auf, das ist unsere gemeinsame Vision, da wollen wir uns hin entwickeln.
Und dann müssen wir aber auch manchmal das irgendwie einmal kurz zur Seite legen und sagen, na okay, jetzt heute, was ist unser erster Beachhead?
Wo geht es jetzt los?
Und darauf fokussieren wir uns und da gehen wir hart rein.
versuchen immer beide Perspektiven zu sehen, aber die teilweise auch klar zu trennen.
Ja, um zu sagen, okay, wir verstehen die Vision.
Wir verstehen, dass ihr am besten alles in einem Dashboard haben wollt und ihr wollt am Ende 70 Agents, die alles automatisch irgendwie beantworten und berechnen.
Die Realität ist, wenn wir den Agent Nummer 1 nicht hinbekommen und wenn wir es nicht schaffen, hier spezifisch den Value zu zeigen, werden wir zu den anderen nicht hinkommen.
Ja, und dementsprechend müssen wir sehr stark hier reingehen und das erstmal lösen.
Und ich glaube, so beide Sichtweisen zu mischen und dazwischen aber auch immer wieder springen zu können, ist das, was sehr schade ist.
auch ein gewisses Management erfordert von unserer Seite oder auch auf der Kundenseite.
Und man darf sich da nicht zu weit weg bewegen.
Konkretes Beispiel, gestern haben wir für einen größeren Kunden, das machen wir mit einem Partner, weil es so groß ist.
Und dann gehen wir da rein und dann haben die einen kompletten, also es ist eigentlich nicht ein Prozess, sondern es sind quasi neun Prozesse hintereinander geschaltet.
Und in jedem Prozess gibt es nochmal irgendwie so knapp zehn Subprozesse.
Grob ist das so im Payment-Bereich.
Also ich habe bestimmte Order, die rausgehen und die werden dann gezahlt.
Und dann haben sie schon alles definiert.
Hier brauche ich einen Agent, hier brauche ich einen Agent und dann mache ich zehn Agent in diesem Subprozess.
Und dann kommen wir an und sagen, okay Leute, das ist cool, aber lasst uns bitte jetzt erstmal das hier ganz reduzieren.
Und wir fangen hier an und dann bauen wir erstmal das.
Wir verstehen die Vision, haken dran, aber wir fangen erstmal hier an und bauen ganz spezifisch diesen einen Agent.
wir werden sowieso zehnmal alles umschieben und nochmal irgendwie ändern.
Und das ist vielleicht dann noch ein letzter Kommentar.
Wir sehen auch häufig, also der Prozess für uns, einen Agent zu bauen, endet nicht, wenn nicht den Agent live geht, sondern wir haben verschiedene Schritte und können vielleicht gleich daraus bekommen, was ist unser Live-Circle im Agent.
Aber das endet nicht, wenn ich einen Agent live schalte und dann ist irgendwie alles okay, danke, hands off und wir kommen und schauen uns das nicht mehr an, sondern geht's wieder von vorne los.
Okay, jetzt sind wir ein bisschen abgebogen und kommen da gleich nochmal drauf zurück, aber wir waren beim Problem, das muss sich erstmal lohnen, also ich brauche eine gewisse Frequenz, da muss ein gewisser Wert dahinter stehen, wahrscheinlich auch eine Skalierbarkeit gegeben sein, verstanden.
Also Agent Bound ist halt nicht ganz so einfach und es ist sehr komplex und sehr viele verschiedene Schritte, die man über Zeit lernen muss und verstehen muss, das ist gar nicht ganz so trivial.
Ja, genau.
Aber wir hatten über den gesamten, also guckt ihr euch, Gesamtprozess, Teilprozess.
Du hast gesagt, also Vision im Blick haben, wie sieht dieser Prozess Ende zu Ende komplett KI-nativ gebaut aus, aber dann einen Punkt rausnehmen.
Und damals starten, den Wert beweisen, von da aus dann weiter bauen und immer wieder gucken, arbeiten wir richtig auf diese Vision hin.
Ich glaube, das ist ja immer dieses Suchen und Finden.
Nicht zu wenig ambitioniert zu sein, weil dann endet man in kleinteiligen Lösungen, die am Ende keinen großen Wert erzeugen.
Ich glaube, auch das passiert gerade sehr, sehr viel.
Auf der anderen Seite aber auch nicht dieses Riesen...
Vor allem auch IT- und Integrationspaket da vor sich zu haben, wo fünf unterschiedliche Abteilungen, 17 unterschiedliche Menschen mitsprechen und Approvals geben müssen und man das nie durch die Tür bekommt, weil es zu überkomplex wird.
Ja, plötzlich.
Okay, also dann haben wir...
Haben wir das?
Wir haben also, das Problem lohnt sich und wir haben jetzt eine erste Opportunity identifiziert, wo wir sagen, lohnt sich durch, also wir brauchen die agentischen Fähigkeiten und das Problem lohnt sich.
Wie macht ihr dann weiter?
Wir haben bei unseren Forward Deployed Engineers oder auch Solution Engineers, wir haben, was wir Agent Lifecycle nennen, also eigentlich ein Prozess.
den wir Stück für Stück befolgen, um diese Agents zu bauen.
Der durchläuft fünf Phasen.
Das geht von Discovery, also ich verstehe wirklich erstmal den Prozess.
Das beinhaltet auch häufig, dass vielleicht der Kunde den Prozess selber gar nicht versteht oder die Leute in der Firma den Prozess gar nicht richtig verstehen.
Wir müssen erstmal Informationen sammeln, was passiert eigentlich.
Dann zweitens bauen wir den Agent.
Das ist, denkt man irgendwie, das ist die größte Phase, aber eigentlich ist es tatsächlich ein Teil davon.
Dann teste ich diesen Agent.
Was heißt das?
Lass da mal Doppelklick reinmachen.
Agent bauen.
Also Agent bauen oder das ergänzische System zu bauen, ist erstmal, ich setze mich hin, ich baue den Flow, ich baue die verschiedenen Prompts, ich baue verschiedene Human-in-the-Loop-Hinter-Steps.
Ich definiere, wann muss der Agent...
wie irgendwie an den Menschen zurückgehen.
Ich definiere die Trigger, ich definiere die oder ich baue die Integration, ich connecte die ganzen Systeme.
Ich fange auch an mit den Evaluations.
Das heißt, ich muss überlegen, okay, was sind irgendwie Kriterien in den einzelnen Schritten?
Wann sage ich, dass jetzt dieser Schritt gut war?
Etc.
Etc.
Und ...
Ja genau, fange ich das an, Stück für Stück alles zu bauen, alles, was so dazu gehört.
Also wirklich vom ersten Schritt, wo fließt die Information in den Agent rein, was passiert dann, was sind die verschiedenen Schritte oder was sind die verschiedenen Bausteine, die ich zusammenpacken muss, bis hin zu, wie evaluiere ich den Agent, ob der jetzt gute Arbeit gemacht hat und was ist dann der finale Output.
Und dann kommen gegebenenfalls nochmal Interfaces da drauf.
Ist das jetzt einfach nur ein JSON, was irgendwie zurückgegeben wird?
Wird das in System zurückgespielt?
Oder haben wir vielleicht sogar ein eigenes Dashboard nochmal, was jetzt das anzeigt, was der Agent dann gemacht hat?
Also da sieht man schon, das ist jetzt nicht, ich baue einen Prompt und dann ist irgendwie alles ganz gut, sondern es ist eigentlich der ganze Prozess dahinter, auch anfangen, die Loops zu definieren.
Also wann kann der Agent retries machen?
Gehen wir direkt ein bisschen tiefer, aber genau.
Also wann wird der Output verifiziert?
Wie wird der Output?
verifiziert, wann darf der Agent in den Loop gehen, wie viele Retries macht der Agent, um einen bestimmten Schritt auszuführen.
All solche Fragestellungen, die ich dann anfangen kann, erst mal zu designen.
Und dann aber, und das ist bei uns Phase 3, und da sieht man dann auch, dass das ein Loop ist, das heißt, ich baue und dann fange ich an zu testen, um wirklich dann alle ...
Test Cases, so ein Datenset oder ein Golden Dataset zu machen, um bestimmte Cases zu sammeln und dann das durchlaufen zu lassen und zu überlegen und zu schauen, wie gut funktioniert der Agent jetzt und dann Stück für Stück evaluieren und verbessern.
Ich glaube, das ist aber total wichtig, da mal da wirklich mal reinzugehen.
In was heißt es, ein Agent zu bauen?
Weil wahrscheinlich viele auch einfach darunter noch verstehen, ich habe in meinem Co-Pilot 365 das Anweisungsfeld, da schreibe ich den Prompt rein, connecte SharePoint und dann habe ich den Agent, der etwas macht.
Wir haben am Anfang darüber gesprochen, was alles Agents sein könnten und das ist eine Ausprägung davon.
Aber hier reden wir jetzt davon, dass ein Agent wie viele Aktionen in einem Prozess ausführt?
Tausende?
Zehntausende?
Ja, 10.000 wäre jetzt ein bisschen übertrieben, aber wahrscheinlich hunderte von verschiedenen Schritten und Retries und Evals etc., die alle gemacht werden.
Genau, aber es sind ja am Ende, also wie oft laufen da eine Rechnung oder ein Dokument zum Beispiel?
Ach so, 10.000 von Mal.
10.000 bis 100.000 Mal.
Und jedes Mal werden x Schritte ausgeführt und am Ende muss das Ergebnis ja stimmen.
Also ihr wollt ja da wahrscheinlich auf 100% kommen und nicht irgendwie, ja, acht von zehn Mal ist es dann richtig und sonst muss sich das halt jemand angucken.
Ja, okay.
Also, dass die Dimension klar wird.
Und ich glaube, da liegt auch der Unterschied dann.
Also, beispielsweise so etwas wie Evaluation ist ja total wichtig, dass, also mein Verständnis davon ist, dass die Ergebnisse, die ein Agent ausspielt, gegen verschiedene Kriterien gespielt werden und der Agent darüber prüfen kann, wie nah ist das Ergebnis an diesen Kriterien schon dran.
Und dann wird oft so ein Score vergeben und wenn der eine bestimmte Grenze überschreitet, geht das Ergebnis in den nächsten Schritt.
Genau, so kann man das zusammenfassen.
Und diese E-Valves können relativ komplex sein und verschiedene Aspekte abdecken.
Also wenn ich jetzt einfach nur eine Extraktion mache, dann kann ich natürlich überprüfen, hat der zum Beispiel die Adresse richtig ausgelesen?
Eine einfache Eval wäre jetzt, hat die Postleitzahl in Deutschland, wie viele Zahlen hat die jetzt?
Und wenn sie drei hat, dann weiß ich, dass irgendwas schiefgelaufen.
Wenn sie fünf hat, most likely irgendwie richtig.
Wenn das dann auch noch zum Ort passt, dann habe ich das richtig gemacht.
Das könnte jetzt zum Beispiel ein Eval sein, der relativ einfach ist.
Aber das kann ich natürlich dann auch komplexer denken.
Habe ich jetzt die Kriterien, die bei mir im Vertrag drin stehen, richtig erfüllt und alle richtig zu meiner Berechnung?
an rangezogen oder zu meiner Bewertung herangezogen und habe ich beachtet, dass das Land, über das wir hier gerade in der Invoice reden, aus der Schweiz ist, die leider irgendwie zollrechtlich andere Fragestellungen haben, beispielsweise.
Und dann sieht man auf einmal die Komplexität, die da kommen kann, weil wir müssen es ja jetzt dann auch bei den Edge-Cases, wo was irgendwie aus der Schweiz nach, keine Ahnung, irgendwo hingeliefert wird, Österreich geliefert wird, trotzdem richtig machen und das erkennen, dass das ein Edge-Case ist.
Genau.
Erklär mal mit dem Testdatenset.
Wie macht ihr das und was ist ein Golden Dataset?
Also wir haben das ursprünglich immer so gemacht, dass wir, und das hat sich auch ein bisschen verändert, dass wir vom Kunden quasi Datasets angefragt haben.
Also das heißt, wir hatten, je nach Komplexität des Use Cases, wussten wir, okay, wenn wir jetzt 100 Cases bekommen, dann haben wir eine gewisse Varianz da drin.
Das heißt, wir können gut erkennen, was die Edge Cases sind und können uns auf die vorbereiten.
Dann haben wir gesehen, okay, wir kriegen die Zahl runter und ganz häufig brauchen wir dann vielleicht irgendwie nur noch 20 Cases.
Haben aber gleichzeitig gesehen, selbst das ist häufig noch ein Problem, was wir mit unseren Kunden haben.
Dann sind wir dahin gegangen, eigentlich synthetische Datensätze zu erstellen.
Das heißt, wir haben bestimmt einen Anwendungsfall und erstellen diese Daten synthetisch und bauen halt möglichst viel Varianz in diese Datasets ein.
Kann man jetzt...
Ja, mal was das heißt, synthetische Datensätze zu erstellen.
Also...
Bleiben wir bei dem Beispiel, ich habe eine Rechnung oder eine Sales Order.
Jetzt kann ich natürlich, vielleicht eine Sales Order kann ein bisschen komplexer sein, ich habe ein Produkt, was ich bestellen möchte.
So und jetzt kann ich hingehen und ich habe eigentlich nur eine, aber ich kann mir jetzt ja 10.000 Varianten überlegen, was alles schief gehen könnte und was irgendjemand mal falsch machen könnte.
Und dann unterscheiden wir in verschiedene Cluster.
Also beispielsweise kann ich jetzt bei einer Sales Order, sagen wir mal dies.
gefaxt in Deutschland oder gescannt, da kann ich irgendwie Fehler darin haben, dass die Daten nicht richtig erkannt wurden.
Oder ich kann aber einen anderen Fehlertyp haben, dass jemand was bestellt hat, was es gar nicht gibt.
Und weil ich jetzt einfach die Kosten günstig erstellen kann, kann ich das zehntausende Mal machen, durch meinen Agent jagen und schauen, was passiert.
Und dann, was wir dann wieder machen, ist, die automatisch zu clustern, die Fehler zu analysieren und uns anzuschauen, okay, welche verschiedenen Fehlercluster gibt es und warum denkt der Agent, über die E-Werts, dass er bestimmte Sachen nicht richtig gemacht hat.
Das cluster ich wieder und dann überlege ich, wie kann ich jetzt die Cluster optimieren im Agent.
Beispielsweise jetzt Data Extraction ist irgendwie ein Problem.
Und das haben wir mittlerweile so aufgebaut, dass wir auf der einen Seite die ganzen Daten gut erstellen können.
dann automatisch testen können, dann die Auswertungen clustern können und dann aus den Auswertungen wieder rauslesen können, okay, was muss ich jetzt eigentlich im Agent verbessern oder was ist vielleicht auch tatsächlich einfach eine Varianz in dem Input, der nicht richtig sein kann.
Und dann braucht man ein bisschen Modelle, also ja, dann mathematische Auswertungen, um dann zu sagen, okay, das war jetzt richtig, das war falsch.
Dann bin ich in der Komplexität des Agent-Bildings angekommen, was ich brauche, um das jetzt Millionen Mal dann korrekt zu machen.
Ja, okay.
Gut, also da KI nutzen, um dann wieder KI zu trainieren und besser zu machen.
Genau.
Und vielleicht mal ein ganz einfaches Beispiel, weil wir da letzte Woche mit unserem Solution-Team drüber geredet haben, weil wir auch am Anfang über bessere Modelle gesprochen haben.
Nehmen wir einen Agent oder einen Prompt, was 70 Prozent Genauigkeit hat.
Und jetzt ist die Frage, was passiert, wenn ich jetzt irgendwie auf die neue Modellgeneration wechsle und sage, okay, ich nehme das bessere Modell.
Und das ist jetzt exemplarisch.
ungefähr komme ich dann, sagen wir mal, auf 74 oder 75 Prozent.
Das heißt, ich sehe schon eine marginale Verbesserung, aber das Modell alleine löst das häufig nicht.
Was viel besser ist, ist so ein Verification-Loop zu machen, wo ich diese Grader baue, auch mit günstigen Models und dann das wieder versuchen lasse.
Das heißt, es ist besser, statt Fable, oder ich ersetze, sagen wir mal, Sonnet durch Fable, das ergibt mir irgendwie einen Boost von ein paar Prozentpunkten.
Wenn ich jetzt aber sage, na okay, Scheiß drauf, ich nehme einfach Sonnet und lasse das Sonnet nochmal graden und mache dann ein Retry, dann komme ich auf einmal auf so 95 Prozent.
Das heißt, der Impact von diesen Retrys und diesen Loops ist viel, viel höher als die bessere Modellgeneration.
Und dann kann ich noch ein bisschen weiter drum spielen, dann kann ich Event-Driven das machen oder so Learn from Traces, das heißt, das Modell schaut sich die Traces an und analysiert dann daraus und so stacke ich dann eigentlich meine Genauigkeit.
Gute Modell ist nicht zwangsläufig der wichtigste Faktor dann.
Woher wisst ihr für einen bestimmten Case, welches Modell das dafür richtige ist?
Also mittlerweile haben wir es ein paar Mal gemacht, dann haben wir einen ganz guten Tag da drauf, was wir da nutzen können.
Es ist jetzt auch nicht immer die Frage, ob das Modell jetzt irgendwie da drin ist.
Es gibt bestimmte noch Modellunterschiede.
Das, ehrlicherweise muss ich jetzt mal nachfragen, aber das war zumindest noch vor sechs Monaten so, dass bestimmte Gemini war irgendwie in bestimmten Data Extraction besser als OpenAI.
Ich weiß nicht, ob das noch so ganz richtig ist.
Da kann man auch mittlerweile die Benchmark-Sicht dann anschauen.
Ich glaube, für uns ist es eher eigentlich immer die Kombination aus, wie teuer ist das Modell?
Wie schnell ist das Modell?
Das kommt auf den Anwendungsfall auch an.
Es gibt bestimmte Anwendungskelle, da muss man dann schauen, dass man jetzt nicht die teuersten Modelle verwendet oder die langsamsten Modelle verwendet, die drei Minuten brauchen, sondern ich möchte das dann wirklich schnell machen, weil ich sage mal, wenn ich in 60 Sekunden eine Antwort habe, dann kann ich nicht ein Modell haben, was erstmal 90 Prozent nachdenkt, sondern dann muss ich das ein bisschen auf Zeit optimieren.
Und dann das Wichtigste sind die Kosten.
Und dann gibt es noch ein paar andere Faktoren, wie stark driften die Modelle und so weiter und so fort, beziehungsweise auch, unter welcher Governance stehen wir, darf ich das Modell überhaupt verwenden in dem Setting.
Und so habe ich dann verschiedene Kriterien, auf die ich schauen muss, um das Modell auszuwählen.
Und dann nutze ich das für fünf Monate und dann stellen wir fest, okay, wir könnten jetzt irgendwie die Kosten sicherlich ganz reduzieren, wenn wir das Modell wechseln würden.
Und dann muss ich eigentlich den ganzen Test nochmal fahren, um zu schauen, welches das Modell austauscht, ob das immer noch genauso gut funktioniert.
Welches ist das am meisten eingesetzte?
aktuell.
Das ist wahrscheinlich schwer zu, also genau, aber ich würde einfach gerne mal wissen, was ihr am meisten nutzt gerade für Agenten.
Die Modelle, die wir tatsächlich am häufigsten nutzen, sind die bisschen älteren OpenAI-Modelle.
Also eher so 5 als jetzt 5.6 zu nutzen.
Jetzt gerade aber dadurch, dass die Preise bei Terra und so runtergegangen sind, müssen wir das jetzt auch mal wieder updaten, weil jetzt sind die neuerigen Modelle günstiger als die alten bei besserer Performance.
Aber für viele Cases nutzen wir nicht immer die letzten Modelle.
Wir hatten jetzt nicht mehr, aber wir hatten immer noch vier Mini, viel in manchen Sub-Items drin.
Das würde ich sagen, ist immer noch das Meiste.
Und wir nutzen relativ viel Gemini tatsächlich in Produktion.
Interessant.
Also sehr anderer Weg eigentlich als das, was gerade so durch die KI-Bubble geistert.
Das ist halt sehr unterschiedlich.
Ich glaube, daran merkt man es halt.
Nutze ich KI zur Erweiterung von mir selbst im Arbeitsalltag?
Dann nutze ich vielleicht eher so ein Opus oder sowas, um irgendwelche Sachen zu bauen oder zu entwickeln oder so?
Oder baue ich das in einen Prozess, wo ganz kleinteilige Aufgaben erledigt werden müssen?
Dann brauche ich das halt überhaupt nicht und dann erzeugt das viel zu hohe Kosten oder macht irgendwelche Sachen, die ich überhaupt nicht haben will.
Genau, Kosten ist ein Riesenpunkt.
Also wenn ich alles mit Fable abschieße, ich glaube, wir hatten da vorhin drüber gesprochen, wenn ich irgendwie 10.000 E-Mails sortiere mit Fable, kostet mich das 100 Dollar.
Wenn ich das mit DeepSeek mache, kostet mich das irgendwie 3.
Und dazwischen gibt es dann auch einige Modelle, die ich nutzen kann, die nicht von den Chinesen sind, wo die Kosten dann eher bei 5, 6, 7 Dollar sind.
Gut, wir sind beim Umsetzungsprozess und ihr habt das Datenset erstellt und seid jetzt in dem Testen und Verbessern von dem Agent.
Genau.
Dann testen wir den Agent.
Wir testen die ganzen Durchgänge.
Wir testen die Integration.
Wir legen auch tatsächlich fest, was passiert im Fehlerfall.
Weil jetzt ist ja immer der Happy Path ist immer schön.
Denkt man immer am Anfang dran.
Okay, es läuft alles super.
Aber was passiert denn jetzt eigentlich, wenn es nicht so läuft?
Wer ist verantwortlich?
Wie eskaliere ich?
An wen wird das eskaliert?
Was sind meine Thresholds?
Zu welchem Zeitpunkt rufe ich irgendjemand an?
Das macht der Agent jetzt nicht, aber übertragend.
Und schaue mir eigentlich das an und teste das durch.
Und dann iteriere ich, bis ich eigentlich eine bestimmte Genauigkeit erreicht habe.
mit der ich jetzt zufrieden bin.
Du hattest vorhin 100% gesagt, 100% kriegen wir statistisch nicht hin, sondern es ist nie 100%, es passieren immer Fehler.
Und da ist es dann auch interessant, was ist eigentlich mein Benchmark für die Accuracy?
Wann bin ich damit zufrieden?
Und da muss man dann auch wieder unterscheiden.
Es gibt bestimmte, in einem Prozess habe ich bestimmte Fehlerquellen, wovon manche nicht so schlimm sind und manche schlimmer sind.
wenn ich GDPR-relevante Daten habe, darf ich zum Beispiel nicht die Kunden vertauschen und dem einen Kunden die falschen Informationen schicken.
Das wäre dann ein GDPR, also theoretisch wäre es ein GDPR-Breach.
Kann auch jetzt eigentlich per Konstruktion nicht passieren, aber ...
Und nichtsdestotrotz, das wäre ein Fehler, da brauche ich eigentlich 100% Genauigkeit.
Und dann gibt es andere.
Im Zweifelsfall habe ich halt die falsche Order rausgeschickt.
Das ist zwar blöd, wenn mich das jetzt 100.000 kostet, dann ist es ziemlich nervig.
Dann ist das ein Fehler, den ich vermeiden muss.
Wenn ich jetzt eine Order habe, die vielleicht nur 500 oder 1.000 Euro kostet, dann kann ich das verkraften und dann passiert das mal.
Das ist auch vorher auch schon passiert.
Und so muss ich mir dann eigentlich über den Prozess auch noch anschauen, okay, wie dürfen eigentlich meine Fehler passieren?
Und mit welchen kann ich leben und mit welchen darf ich auf keinen Fall leben?
Das ist immer eine interessante Approximation auch, weil gerade wenn ich jetzt noch nie so viele KI-Systeme im Einsatz habe, KI-Systeme machen Fehler.
Das kriegen wir auch.
Wir können nicht garantieren, dass es keinen Fehler macht.
Das geht einfach durch die Bauart der LLMs nicht.
Und dadurch passiert mal ab und zu was.
Die Frage ist halt, wie schlimm ist das und wie gut hab ich da vorher was drum gebaut, dass das nicht so dramatisch ist.
Aber kriegst du das nicht auf ein absolutes Minimum reduziert durch immer mehr, also du kannst ja theoretisch immer mehr Kontrollschritte draufwerfen.
Wenn die jetzt immer günstiger werden, dann braucht die Verarbeitung wahrscheinlich ein bisschen länger, aber das ist ja dann auch egal, wenn das sowieso automatisiert läuft.
Und ja, du hast natürlich immer noch so eine kleine Wahrscheinlichkeit, aber die lässt sich doch fast gegen null bringen oder nicht.
Sonst müsste ja ein Mensch eben auch drauf schauen und der guckt halt auch mal drauf und übersieht etwas.
Ja.
Prinzipiell ja, praktisch ist die Welt komplexer.
Ein konkretes Beispiel von einem Kunden.
Es werden bestimmte Cases evaluiert und das wird, sagen wir mal, einfach vom Level 1 Mitarbeiter gemacht.
Und dagegen wird erstmal unser Agent gebenchmarkt und trainiert.
Und jetzt stellen wir dann fest, okay, der Mitarbeiter 1 und der Agent sind sich in, sagen wir mal, irgendwie 5,6 Prozent der Fälle nicht einig.
Und der Agent sagt, ich habe was anderes entschieden als der Mitarbeiter.
Jetzt heißt das nicht, dass der Mitarbeiter richtig liegt, leider.
Sondern was wir dann machen, ist jetzt, das ist dann ein Sample, dann gibt es einen Supervisor, Level 2 oder Level 3, der überprüft alle nochmal, die kritisch sind.
Und dann stellt er fest, naja, okay, jetzt hat er aber in 80% der Agent recht gehabt und in 20% der Mitarbeiter recht gehabt.
Das heißt eigentlich, die reale Fehlerquote des Agents lag vielleicht nur bei 1,3%.
Die Fehlerquote des Mitarbeiters lag aber eigentlich viel höher.
So, und dann merkst du das halt, gerade wenn ich jetzt Judgment da drin habe, das nicht so einfach ist, weil meine Source of Truth ist gar nicht so klar.
Es ist ja Judgment drin.
Wenn es jetzt wieder zurückgehen würde und ich hätte ein deterministisches System, dann könnte ich immer sagen, klar, du hast einen Fehler gemacht.
Aber in dem Fall ...
Wer hat denn jetzt, was ist jetzt die Wahrheit?
Und dann gibt es noch die Cases, wo alle drei verschiedene Aussagen getroffen haben oder zu verschiedenen Schlüssen gekommen sind.
Und das ist genau das Thema in diesen Prozessen, wenn ich eine Ambiguity drin habe oder ein Judgment, there is no single source of truth.
Ich wünschte, sie wäre da, aber es gibt diese Fälle, wo das nicht so ist, wo ich halt entscheiden kann, auch als Mitarbeiter.
Man kennt das aus dem Kundenservice, ich kenne das vom Amt oder wo auch immer oder von der Polizei, wenn die einen anhalt.
Manchmal können die auch sagen, sie dürfen weiterfahren, obwohl sie zu schnell gefahren sind.
Und genau da habe ich halt was drin, was ich nicht zwangsläufig rausbekommen kann.
Aber da ist es dann wichtig darüber, dass wir genau diese Evaluations und die Tests haben, um das überprüfen zu können und dann auch sagen zu können, okay, ja, richtig, der Agent lag.
Falsch, aber der Mitarbeiter lag vielleicht auch falsch.
Ja, okay.
Alright, wie lange dauert so ein Prozess?
Vom ersten Setup dann bis zum Testen und Optimieren, bis ihr live gehen könnt?
Ungefähr im Schnitt.
Mittlerweile so sechs Wochen.
Früher hat das deutlich länger gedauert.
Wenn das gut vorbereitet ist, dann geht es auch mittlerweile viel schneller.
Wir können die Agents extrem schnell mittlerweile bauen, weil wir die ganzen E-Welt etc.
alles drumherum eigentlich ...
Das sind Systemen gebaut haben und Agents, die das bis zu einem gewissen Grad automatisieren.
Und dann hängt es natürlich ab von Integration, dann musst du ins Governance, IT-Board, ins AI, hier, dort, da, was dann immer noch Zeit kostet.
Und dann ist auch wieder in manchen Prozessen auch sechs oder acht Wochen komplett utopisch und es dauert halt deutlich länger, weil ich halt noch viele Freigaben brauche.
Aber so der typische Agent-Building-Prozess, dass es gut funktioniert, durch eigentlich meine Baseline-Hitte.
Sechs Wochen.
Es kann aber auch sein, dass wir tatsächlich mal in ein paar Tagen hin zaubern, aber dann ist das gut vorbereitet von beiden Seiten.
Jetzt hast du vorhin schon gesagt, das ist ein Lifecycle, der auch gemanagt werden muss.
Also wir sind jetzt nicht fertig und drücken auf den grünen Knopf und dann läuft das Ding, sondern was passiert danach noch?
Wir haben den Agent gebaut, wir haben das Testen gemacht.
Dann kommt erst mal der Schritt, wo ich den Agent live schalte.
Und da habe ich eigentlich verschiedene Grade der Autonomie.
Es gibt auch Cases, wo live schalten einfach nur heißt, er läuft erst mal nur parallel und macht quasi die Vorschläge.
Und erst dann schalte ich den Stück für Stück scharf, dass er tatsächlich dann die Entscheidung trifft oder die Aufgaben abarbeitet und dann x Prozent der Fälle übernimmt.
Und bis hin zu...
Jeder Case, also dann gibt es die verschiedenen Autonomie gerade, jeder Case wird vom Mitarbeiter überprüft, ich habe Samples, die ich vom Mitarbeiter überprüfe oder der Agent macht einfach, weil ich dem Agent vertraue und wir machen nochmal am Ende des Monats einmal einen Report.
Das heißt, ich habe eigentlich in GoLive verschiedene Stages auch wieder, wo ich sagen kann, Easy läuft bis hin zu, okay, der Agent ist 100% autonom unterwegs und da muss ich eigentlich, je nach Kunden, je nach Use Case, wie komplex ist der, welche Fehlertoleranz habe ich, arbeite ich mich davor.
Und dann, wenn der Agent dann live ist, habe ich natürlich nichtsdestotrotz eigentlich noch eine Operations-Phase, wo wir den Agent monitoren müssen, wo wir überprüfen müssen, was ist eigentlich auf dem Business Case, also wie entwickelt sich jetzt der ROI, den wir irgendwie am Anfang mal besprochen haben.
Wer macht das?
Monitoring.
Was passiert, wenn jetzt ein neues Modell beispielsweise rauskommt?
Was ist, wenn die Regulatorik sich, also sagen wir mal, ich habe einen Case, wo welche Regulatorik relevant ist.
Was passiert, wenn sich das ändert?
Wer updatet das?
Etc.
Und das muss überprüfen.
Das ist aber auch dann bei uns mittlerweile relativ standardisiert und erstmal läuft das.
Aber es ist wichtig, dass man dann nicht sagt, okay, jetzt läuft der Agent bis in alle Ewigkeiten, sondern ich habe einen gewissen Aufwand dahinter.
Bei wem liegt sowas im Unternehmen in der Regel?
Wer ist dafür dann verantwortlich?
Also häufig machen tatsächlich wir das dann, was die technische Pflege des Unternehmens angeht, also gegebenenfalls Updates.
Du willst ja doch, wenn du jetzt durch das Ganze einmal durchgegangen bist, dann siehst du, dass viele Sachen relativ komplex sind.
Wir sehen auf der Unternehmensseite ist es weniger, denn der Business Owner ist sehr wichtig am Anfang im Prozess, um diesen Prozess zu definieren und eigentlich das zu unterstützen.
Und dann sind es im Idealfall eher IT-Teams oder die Leute, die sehr nah da dran sind.
Es sind nicht zwangsläufig die IT, sondern eher neue Teams, die dafür zuständig sind und dann mit uns arbeiten, um das zu überprüfen und zu machen.
Okay.
Und dann ist das jemand aus der IT oder ist das der Prozessverantwortliche aus dem Fachbereich?
Also der Prozessverantwortliche, ja, es ist ein bisschen beides.
Der Prozessverantwortliche wird später dann eigentlich weniger relevant, meistens, es sei denn, der Prozess ändert sich.
Also insofern, man kann sich nicht ganz rausnehmen, aber da ist dann nicht mehr so viel zu tun, sondern es ist dann eher von beiden Seiten geringer Aufwand, das zu operieren.
Okay.
Okay.
Alright.
Gibt es sonst noch Schritte in dem Prozess, die ihr da standardmäßig ausführt?
Ich glaube, das sind erstmal die Phasen.
Jetzt kommen wir zu horizontal.
Nein, jetzt kommen wir zu diesen verschiedenen, also wie haben wir das dann nochmal unterteilt?
Wir haben dann verschiedene Layer in dem System.
um das zu tun.
Aber genau, das ist dann einfach, da haben wir jetzt im Prinzip schon drüber gesprochen.
Also die Layer ist, wir haben einen Layer, das ist der Use Case, der je nach Phase unterschiedlich wichtig ist und relevant ist.
Am Anfang muss ich ihn definieren, am Ende muss ich ihn überprüfen, aber zwischendurch ist ja jetzt nicht wahnsinnig viel zu tun.
Und dann habe ich...
unsere Architektur, also wie ist der Agent aufgebaut, das System, was dahinter liegt und dann den Evidence- und Quality-Layer.
Und dieser Evidence- und Quality-Layer ist dann eher hinten wichtig, wo am Anfang der Business, wenn ich jetzt über den Business-Prozess rede, dann ist das erfolgreich und hinten raus übersetzen wir das dann in die verschiedenen E-Werts etc.
Und so schauen wir quasi auf der einen Seite durch die Phasen und auf der anderen Seite durch die verschiedenen Layer.
Und haben dann für jede Phase und für jeden Schritt so eine Matrix, wo wir dann verschiedene Tools etc.
haben, um das zu machen.
Okay, also, ich glaube, die Nachricht ist angekommen.
Das ist ein bisschen komplizierter, als sich mal eben so ein ...
Agent in Copilot zusammen zu klicken, aber dann auch am Ende ein System, was eben Tausende oder Zehntausende bis Hunderttausende Transaktionen durchführen kann.
Ich will jetzt abschließend noch ein kurzes Update von dir bekommen und zwar Du hast ja im letzten Mal über dein CEO-Office gesprochen und ich wollte ja so ein bisschen verstehen, wie nutzt ihr eigentlich selbst agentische Systeme bei euch und arbeitet damit.
Du hast gesagt, du hast ja ein CEO-Office mit diversen Personas gebaut.
Da kommen unterschiedliche Daten rein aus deinen E-Mails, aus deinen Meetings, aus Projekten.
Die werden dann schon mal vorsortiert, verwaltet und dann hast du verschiedene Panels, die du befragen kannst mit Personas, die dir dazu Feedback geben, dir bei Entscheidungen helfen, Dinge vorbereiten, Präsentationen vorbereiten.
Was ist im letzten halben Jahr in diesem Setup passiert?
Wie habt ihr das weiterentwickelt?
Viel.
Also, das haben wir gemacht.
Wir haben eigentlich Stück für Stück die ganze Firma umgebaut, was unser Kontext angeht.
Also erst mal.
Vor neun Monaten war immer noch, oh, Kontext ist schwierig.
Dann haben wir irgendwann gesagt, okay, wir müssen das irgendwie ein für alle Mal lösen.
Das haben wir noch nicht, aber wir haben zumindest eine deutlich bessere Architektur, wie wir Kontext in der Firma managen und somit auch für mein CEO-Office.
Bei uns lebt das alles in GitHub.
Wir haben unsere verschiedenen Repos, jeder Kunde hat ein Repo.
Wir haben für Go-to-Market eins, wir haben für Marketing eins, etc.
Und dann in diesen ...
Repos haben wir das so strukturiert, dass ein Coding-Agent immer Informationen finden muss.
Das ist eigentlich, was ich typischerweise, ob das aus der Beratung ist oder irgendwo anders her, wo liegt die Datei, wo hast du das abgelegt?
Das muss halt für den Agent verständlich sein.
Und das machen wir über ganz viele Readme-Files, ganz viele Instruktionen etc., die da drin liegen.
Und das fängt an wirklich geil zu funktionieren, weil wir so ein bisschen, wir haben intern den Leitspruch, also erzählst nicht mir, sondern erzählst Oder strukturier es so und erzähl es deiner AI so, dass meine AI das findet.
Das heißt, wenn jemand an irgendetwas arbeitet, musst du das so ablegen, dass mein Coding Agent das verstehen kann, was da getan wurde und was der letzte Stand ist.
Und dann wird es ganz interessant, jetzt zum Beispiel auch in Vorbereitung.
für diesen Podcast, habe ich meinen Agent losgeschickt und ist mittlerweile so gut alles organisiert.
Er hat mir diese ganzen Informationen.
Ich habe jetzt noch zehn Präsentationen, die ich lesen kann, wo er sagt, hier, guck mal, das ist relevant, das haben wir bei dem Kunden gemacht, das haben wir bei dem Kunden gemacht.
Und das ist richtig nice, weil ich glaube, das ist so ein bisschen das Problem, was niemand so richtig lösen konnte, ist Kontext strukturieren in einer Firma und am Ende macht die AI das jetzt selber.
Und das ist wirklich geil.
Und dann die nächste große Änderung ist jetzt speziell auf dem CEO-Office.
Also was ich vorher schon hatte, ist, dass ich eigentlich...
reaktiv zum Beispiel beim Board auf was losschicken konnte und dann sagen konnte, hey, guck mal, ich hatte jetzt den Sales Call, wie war das jetzt?
Oder ich habe das gemacht, wie war das jetzt?
Oder ich habe die Präsentation morgen, kannst du mir das mal vorbereiten?
Bis hin jetzt zu eigentlich einem proaktiven System.
Und das ist gerade so die Änderung, die gerade stattfindet, die aber super geil ist, weil jetzt muss ich nicht mehr so viel nachdenken, sondern das System denkt mehr für mich nach und bereitet dann vor.
Ob das jetzt ein Briefing ist, klar, das ist die einfachste Form.
Ich habe jetzt ein Briefing erstellt für X, aber jetzt auch zum Beispiel ich gehe aus dem Meeting raus, es analysiert das ganze Meeting.
Jetzt hat es ja den Kontext über all das, was in der Firma passiert.
Und jetzt kannst du nachdenken, naja, okay, jetzt kombiniere ich das mit dem Projekt, das du hast, mit dem Task, das du hast.
Und hier hast du noch ein Goal, was daran arbeitet.
Und jetzt schiebe ich das schon mal zusammen und bereite das vor.
Und das fängt jetzt so an, das ist noch ein bisschen Early Days, aber es fängt an zu funktionieren.
Das ist wirklich geil, weil dann will ich nicht mehr so weit davon weg.
Das ist eigentlich um mich herum immer alles funktionieren.
Das ist eigentlich das Beste, wenn du halt...
nicht mehr jetzt immer derjenige sein muss, der alles nachtragen muss, sondern das System kommst du dir und sagst, guck mal Jonas, heute machst du mal A, B, C, D und das ist, ich habe so ein Command Center mir jetzt gebaut, das muss ich dann mal, wo dann jeden Morgen reinkommt, okay, das sind die Top 3 Sachen, die du heute lösen musst.
Ich habe dir das schon mal vorbereitet, dafür glaube ich, brauchst du 10 Minuten, ist immer ein bisschen ambitious, dauert dann doch manchmal länger und das sind die Informationen, die ich schon mal alle zusammengesucht habe.
Und da bin ich jetzt mal gespannt.
Ich glaube, das wird jetzt nochmal schön weitergehen in den nächsten drei Monaten und dann kann ich an den Strand.
Das glaube ich nicht, dass das eintreten würde, aber vielleicht kommen wir da hin.
Ich fand es lustig, letzte Woche hast du es ja auch bei uns im AI-Collective mal gezeigt und irgendjemand hatte dann gefragt, ja, ist lustig, weil du wirst ja jetzt damit die ausführende Kraft von KI.
die dir dann die Aufgaben geben und priorisieren und dir sagen, was du machen sollst.
Es ist so ein bisschen so, ja.
So dreht sich das.
Das ist aber auch so, manchmal liest du ja dann so in den News, ja, was passiert da jetzt mit AI in den USA und hier und dort und da.
Und ich glaube, deswegen ist es wichtig, dass man das auch selber baut, weil dann sieht man die Grenzen davon und wo führt das hin?
Und dann ist es halt, es sagen ja immer noch, ja, okay, aber AI kann das nicht oder AI kann hier das auch nicht.
Und da hat es einen Fehler gemacht.
Ja, okay, aber.
Eigentlich ist es schon so gut, dass es meinen Job wirklich zum Großteil machen kann.
Und das einzige Problem, warum es das noch nicht machen kann, ist es halt, vielleicht weil es nicht meinen Körper hat und sich nicht überall einloggen kann, aber das stimmt auch nicht mehr, weil es kann sich ja mittlerweile überall einloggen.
Also ich glaube, es ist sehr wichtig, um diese Grenzen auszuprobieren und dann zu sehen, wie sich die eigene Rolle auch ändert.
Und das wird ja jetzt nur noch weitergehen.
Jonas, vielen Dank für diesen Agent Deep Dive.
Hat Spaß gemacht, ganze Menge gelernt und wir machen das nochmal Anfang nächsten Jahres.
Bin ich gespannt, wo das Setup dann steht und ob du dann am Strand hier, musst du nur ein Mic dabei haben für die Aufnahme.
Neh mich dann davon.
Danke, danke.