Webinar – Daten, erforscht #6 – Das Agentic Mesh: Überdenken der KI-Architektur für Autonomie und Ausrichtung

Okay, legen wir los. Ähm, das heutige Thema ist, ähm, die Zukunft von Agen im Unternehmensbereich, basierend auf eurem Buch, ähm, von Eric und Davis, ähm, mit dem Titel „Agen Mesh“. Ich habe eine lange Liste von Fragen, die ich euch stellen möchte.

Zunächst einmal herzlich willkommen. Es ist mir eine Freude, Sie und Davis hier zu haben. Ich denke, die erste Frage ist eine, die ich gerne stellen möchte, äh, an Sie und Eric gerichtet – Sie können natürlich gerne einsteigen, wenn Sie möchten –, aber wir sprechen über die Zukunft von, äh, dem Unternehmen.

Warum fangen wir also nicht mit einer kurzen Definition davon an, was ein Agent ist? Wie funktioniert das? Was ist das, mit deinen Worten, Davis?

In Ordnung. Nun, ein Agent ist ein Software-Akteur, der Kontexte interpretieren, ein Ziel verfolgen, Aktionen auswählen, Aufgaben mithilfe von Tools und APIs ausführen, mit Daten interagieren sowie mit Menschen und anderen Agenten interagieren kann. Das zentrale Merkmal hierbei ist die Handlungsfähigkeit.

Es generiert nicht nur eine Antwort, sondern entscheidet auch, wie es weitergeht. Es überträgt den Status von einem Schritt zum nächsten und passt sich anhand der Ergebnisse früherer Schritte sowie der Nutzung im Unternehmen an. Ein Agent sollte als operative Einheit mit Identitätsberechtigungen, Richtlinien und beobachtbarem Verhalten behandelt werden.

Das macht es eher zu einem Modellaufruf oder, äh, einem Chatbot. Und es wird zu einem geregelten Software-Akteur, der innerhalb einer Unternehmensumgebung begrenzte Aufgaben ausführen kann. Oh, cool.

Ja. Äh, lass mich das noch kurz ergänzen. Äh, tolle Antwort, Davis.

Ähm, es gibt, es gibt zwei, ich, ich, es gibt zwei Arten von Agenten, die ich gerne in die Diskussion einbringen möchte. Die eine sind Programmier-Agenten, und ich bin mir sicher, dass, wenn Leute Claude Code oder Codex verwendet haben, sie wahrscheinlich erkennen, dass diese die Softwareentwicklung verändert haben und dass sie sowohl in den Bereich der Datenverarbeitung als auch in den Bereich der Geschäftsanwendungen vordringen. Und wir sehen Dinge wie Open Claw, enorme Innovationen.

Aber hier liegt der Unterschied – und damit kommen wir zu unserer Diskussion über Unternehmensanwendungen –, denn es handelt sich hierbei um persönliche Agenten. Diese laufen unter Ihrer ID, Ihrer Rolle und Ihren Berechtigungen. Sie gewähren ihnen Zugriff auf Ihre Umgebung.

Sie gewähren ihnen Zugriff auf Ihre Ressourcen. Enterprise-Agenten, auf die wir noch etwas näher eingehen werden, sind etwas anderes. Sie sind operative Einheiten.

Wie Davis bereits angedeutet hat, verfügen sie über Identitätsberechtigungen, Richtlinien und beobachtbares Verhalten. Die Sache ist nun die: Diese Agenten sind nun gesteuerte Software-Teilnehmer im Unternehmen, genau wie jede andere Unternehmensanwendung. Und das ist der entscheidende, der entscheidende Unterschied, denke ich, um einfach die Grundlagen dafür zu schaffen, wie die Leute vielleicht Dinge über Cloud und Agenten und dergleichen gehört haben und wohin, wohin wir wollen, wohin wir die Umgebung tatsächlich gehen sehen.

Ja. Danke, Eric. Danke, dass du das so deutlich gemacht hast.

Und ich nehme natürlich an, dass die Teilnehmer hier bereits ein gewisses Maß an Wissen zu diesem Thema mitbringen oder zumindest interessiert sind, oder? Also, also, also können wir hier natürlich etwas ins Technische gehen, aber einige der Fragen, die ich vorbereitet habe, sind auch eher, ähm, naja, allgemeinerer Natur, damit wir insgesamt ein gründliches Verständnis des Themas bekommen. Und ich möchte eigentlich mit der Prämisse Ihres Buches beginnen.

Ähm, nun, da wir, wie du geschrieben hast, ins Detail gehen – du hast ja ein Buch geschrieben –, richtet sich die Frage natürlich an euch beide. Ihr könnt also gerne beide einsteigen, wenn ihr möchtet. Aber ich möchte mit einer kleinen Herausforderung beginnen, und ich denke, vielleicht ist es eine einfache.

Sie haben sich entschieden, ein Buch über das zu schreiben, was Sie als „Ag-Netz“ bezeichnen. Warum haben Sie sich nicht dafür entschieden, ein Buch über das zu schreiben, was man provokativ als „Monolith“ bezeichnen könnte? Warum ist es ein Netz?

Warum ist es ein Monolith? Klar. Das ist eine gute Frage.

Ähm, ich werde, äh, ein paar Zitate von Branchenführern anführen. Ähm, Andy Jassy, CEO von Amazon, sagte, dass es in jedem Unternehmen eine Million Agenten geben werde. Satya Nadella von Microsoft hat erklärt, dass Agenten Software-as-a-Service ersetzen werden.

Ähm, Jensen Wong, der CEO von Nvidia, hat gesagt, dass es in jedem einzelnen Unternehmen Tausende, wenn nicht sogar Zehn- oder Hunderttausende von Agenten geben wird. Was wir also wissen, ist: Selbst wenn sie völlig falsch liegen und es nur tausend oder vielleicht 10.000, äh, Agenten in einem Unternehmen gibt, gibt es in kaum einem Unternehmen Software-Komponenten, die 10.000 von irgendetwas umfassen. Wir haben also vielleicht etwas Ähnliches bei der Verwaltung von Microservices gesehen.

Und der Grund, warum, ähm, ein Mesh ins Spiel kommt, ist, dass man, wenn man verwalten , tausend, 10.000 oder vielleicht eine Million von irgendetwas verwalten muss, sich eine andere Architektur überlegen muss. Ein Monolith wäre da einfach nicht praktikabel. Oder die Verwaltung von einer Million Agenten in einem Monolithen.

Das wäre heute wahrscheinlich in keiner sinnvollen, äh, modernen Architektur einsetzbar. Aber wenn ich sie verteilte, äh, hätte ich eine Chance. Und ganz ehrlich, die verteilte Architektur ist das, was wir jeden Tag sehen, egal ob man Cloud nutzt Cloud sogar innerhalb von Rechenzentren – man sieht dort draußen Tausende von Knoten.

Wir glauben also, dass die logischste Architektur für Agenten ein föderiertes Modell ist und das Mesh – also ein Modell, bei dem per Definition jeder Agent mit jedem anderen Agenten zusammenarbeiten kann –, was zwangsläufig zu einer meshbasierten Architektur führt. Einfach aus praktischer Notwendigkeit heraus, äh, ja, das ist sehr einleuchtend. Ähm, ich denke, äh, das ist nur eine persönliche Beobachtung, aber in den allerersten Tagen von, äh, Jet GPT-3 0.5 gab es meiner Meinung nach diese Vorstellung, dass, dass, dass die Zukunft der KI darin bestehen würde, manche würden, und, und, und das klingt jetzt furchtbar untechnisch, aber, aber dass die Zukunft der KI irgendwie aus sehr großen Softwareblöcken bestehen würde, die etwas ausführen, einfach wegen des Begriffs „großes Sprachmodell“, und der Vorstellung, dass sich das irgendwie in, äh, eine Art monolithische Architektur übersetzen würde.

Aber ich stimme zu, dass, äh, wir derzeit ein, äh, sehr weit verbreitetes Verständnis dafür beobachten, dass KI-Architekturen in einer Art „Netzwerk“ existieren müssen, äh, in dem Sinne, dass es eine sehr, sehr große Anzahl von Agenten gibt, die, äh, in einem solchen Netzwerk zusammenarbeiten. Ähm, in Ihrem Buch „Ingen Mesh“ unterscheiden Sie zwischen, ähm, freien Arten von, ähm, Agenten, wenn man so will, äh, von freien Arbeitsweisen mit KI im Unternehmen. Ähm, das sind das, was Sie KI-Workflows, autonome Agenten und Enterprise-Grade-Agenten nennen.

Eigentlich hast du, Davis, zu Beginn des Gesprächs bereits ein wenig auf deine Definition angespielt. Wenn du Lust hast, würde ich gerne etwas näher auf deine Definition eingehen und fragen: Okay, was ist der Unterschied zwischen KI-Workflows, autonomen Agenten und Agenten auf Unternehmensebene? In Ordnung. Das ist eine großartige Frage, und sie trifft wirklich einige der Unterschiede, die die KI in den letzten Jahren durchlaufen hat.

Ein KI-Workflow ist also ein System, bei dem das Sprachmodell und seine Tools einem vordefinierten Ablauf folgen. Das bedeutet, dass ein KI-Workflow jeden einzelnen Schritt enthalten muss. Er könnte jeden Entscheidungspunkt berücksichtigen, der im Voraus von demjenigen festgelegt wurde, der ihn erstellt.

So wie jemand vielleicht in Schritt vier oder Schritt drei eine LM nutzt, um etwas zusammenzufassen, eine Information zu extrahieren oder etwas zu klassifizieren. Aber im Grunde genommen ist jeder Schritt in diesem Prozess, mm-hmm, im Voraus festgelegt. Die KI kann beispielsweise nur zusammenfassen oder Informationen extrahieren, wenn man diesen Schritt bereits erreicht hat; sie kann die nächsten Schritte nicht sonderlich beeinflussen.

Im Grunde ist das System fest vorgegeben, und wenn irgendetwas Unerwartetes auftritt, das der Entwickler des Workflows nicht im Voraus gesehen hat, erhält man einfach eine Fehlermeldung. Selbst in Fällen, in denen es für einen Menschen offensichtlich sein mag, welcher der richtige Weg ist, steht dem ein autonomer Agent gegenüber, der seinen eigenen Ausführungspfad dynamisch bestimmen kann. Wenn ihm die entsprechenden Werkzeuge zur Verfügung stehen, kann er diese selbst in einer unerwarteten Situation anwenden und das Unerwartete überwinden, um einen neuen Weg zu finden, wie es weitergehen soll.

Es kann neue Lösungen On Demand erkennen und umsetzen On Demand auf sich ändernde Bedingungen On Demand reagieren. Die Anpassungsfähigkeit und die dynamische Planung sind es, die es wirklich auszeichnen. Und darüber hinaus, was Agenten auf Unternehmensebene betrifft, ist es die Art und Weise, wie man einen autonomen Agenten in das Unternehmen integriert, um sicherzustellen, dass er auffindbar, sicher und vertrauenswürdig ist – sowie all die anderen Aspekte, die erforderlich sind, damit ein Unternehmen Agenten wirklich akzeptiert.

Ach ja. Okay. Also, ich, ich, ich sehe den Unterschied, ähm, deutlicher, ganz klar.

Ich, ich, äh, ich habe das Buch im Vorfeld gelesen, um mich auf dieses Webinar vorzubereiten. Außerdem war ich als technischer Gutachter tätig. Ähm, das habe ich am Anfang nicht erwähnt.

Ich glaube nicht, dass ich das am Anfang gesagt habe. Aber ich bin überzeugt, dass diese Denkweise und die Art und Weise, wie Sie das beschreiben, zu einer Art Standardwerk werden wird, um zu verstehen, welche gentechnologischen Architekturen man in Unternehmen schaffen kann. Genau. Gerade wegen dieser Art von Unterscheidungen.

Und vielleicht möchte ich das Wort kurz an dich weitergeben, Eric, was die organisatorische Realität und das Unternehmen angeht. Wir neigen dazu, Agenten so zu betrachten, dass ein Mensch einen Agenten repräsentiert. Du zeigst nun ganz klar, dass man in einem organisatorischen Umfeld nicht wirklich so denken kann. Der Unterschied ist, bzw. der Vergleich muss ein wenig anders ausfallen.

Und so haben wir also einige, ähm, Metaphern, die Sie verwenden, äh, um die Unternehmensrealität zu übersetzen. Sie übersetzen also, äh, lassen Sie mich einfach die Frage vorlesen, damit es für die Zuhörer hier nicht zu kompliziert wird. Wie übersetzt man ein Team und eine Organisation in Gruppen von Agenten?

Worum geht es bei der Flotten-Metapher und worum geht es bei der Ökosystem-Metapher? Kannst du das ein wenig näher erläutern, Eric? Ja, natürlich.

Also, ähm, wir verwenden in dem Buch diese Analogie, bei der wir davon ausgehen, dass eine Person so etwas wie ein Agent ist. Und wie Davis bereits erwähnt hat, ähm, kann ein Agent, äh, einen Aufgabe erstellen und Entscheidungen treffen, genau wie eine Person. Diese Analogie übertragen wir auf Teams.

Genauso wie Menschen in Teams arbeiten und miteinander zusammenarbeiten und dabei Werkzeuge nutzen, die wir als „Agententeams“ bezeichnen, nennen wir diese „Flotten“. Nun, genau wie bei Menschen und wie in jeder Organisation, äh, jeder Organisation von bescheidener Größe oder sogar großen Organisation, gibt es viele Teams und viele Organisationsebenen, und diese können auf vielfältige Weise organisiert sein. Grob gesagt nennen wir das, äh, ein Unternehmen, eine Firma, wenn man so will.

Ähm, in unserer Agent-Terminologie nennen wir das ein Ökosystem oder ein „Eugen Mesh“. Das Interessante daran ist, dass wir diese Analogie tatsächlich auf Lieferketten ausweiten, zum Beispiel dort, wo mehrere Organisationen spezifische Verträge haben, die festlegen, wie sie interagieren, mit wem sie zusammenarbeiten können, welche Erwartungen an das Serviceniveau oder sogar an die Qualität bestehen. Die Analogie lässt sich also tatsächlich bis in moderne Fertigungslieferketten hinein übertragen, die all die Dinge aufweisen, die ich erwähnt habe.

Aber genau diese Dinge könnten wir auch auf Agenten anwenden, und wir glauben tatsächlich, dass sie auf – ähm – das angewendet werden könnten; das ist vielleicht ein neuer Begriff: „Agentic Process Automation“, um sie von der regulären Geschäftsprozessautomatisierung oder der robotergestützten Prozessautomatisierung abzugrenzen. Ähm, wir glauben, dass die Analogie von Person zu Agent, Team zu Flotte, Organisation zu Ökosystem und dann Prozessautomatisierung tatsächlich die richtige Analogie ist. Ähm, und wahrscheinlich die intuitivste, denn genau wie Sie, wie wir alle, interagieren wir alle mit anderen Menschen, arbeiten in Teams.

Normalerweise arbeiten wir innerhalb einer Unternehmensorganisation. Und manchmal haben wir sogar mit mehreren Unternehmen zu tun. Diese Analogie ist äußerst einleuchtend, und genau deshalb haben wir sie in dem Buch so häufig verwendet.

Ja, stimmt. Ich denke auch, dass, ähm, ähm, der Koordinationsaufwand natürlich zunimmt, je mehr Agenten man hat, oder? Eine Flotte ist etwas, dem man relativ leicht eine Richtung vorgeben kann und sagen kann: „Ihr fliegt unter diesen Bedingungen in diese Richtung“, oder?

Während ein Ökosystem natürlich mit zunehmender Größe immer schwieriger zu koordinieren und zu lenken ist, und es, und es, und es sollte ja auch nicht alle in dieselbe Richtung gehen, oder? Wenn man ein Ökosystem von Akteuren hat, ist das Ziel offensichtlich eine Vielzahl unterschiedlicher Prozesse, die, äh, nicht miteinander verbunden sind oder nur sehr lose miteinander verbunden sind, oder? Das führt zu einer völlig anderen Komplexitätsebene, äh, mit der man arbeiten muss.

Und ich glaube, was in der Diskussion über Agenten dringend fehlt, ist, dass sie sich meist auf den Vergleich mit menschlichen Agenten beschränkt, während man eigentlich etwas anderes als einen Menschen braucht, um eine Gruppe von Agenten zu vergleichen, oder? Äh, mm-hmm. Also, diese Frage gefällt mir, mir gefällt diese, äh, diese, ähm, diese Unterscheidung, die du in dem Buch machst, äh, sehr gut.

Okay. Also, ich habe mich auch darauf vorbereitet – das ist ein großes Thema, und es gibt viele verschiedene Aspekte, und ich denke, ihr könnt beide darauf antworten. Ihr habt beide bereits Teile der Antwort angesprochen, aber ich hoffe, wir können noch tiefer darauf eingehen.

Aber das ist eine große Frage, also werde ich sie vorlesen und dann in kleinere Teile aufteilen, denn niemand wird sich das sowieso merken können. Ähm, ja. Also, äh, Agenten der Enterprise-Klasse weisen sieben Merkmale auf.

Das sind also die Agenten der Enterprise-Klasse. Wir bewegen uns hier also jenseits der autonomen Agenten. Wir nutzen einen Agenten der Enterprise-Klasse, richtig?

Die, die ausgereiftesten ihrer Art – Enterprise-Grade-Agenten – weisen sieben Merkmale auf: Sicherheit, Zuverlässigkeit, Erklärbarkeit, Scalability, Auffindbarkeit, Beobachtbarkeit und Bedienbarkeit. Und niemand kann sich diese laute Wiederholung merken. Aber kannst du beschreiben, was diese sieben Merkmale insgesamt ausmachen, äh, bei einem Enterprise-Grade-Agenten, Blac, und ich denke, wir sollten sie nacheinander durchgehen.

Wie sieht es also mit der Sicherheit eines Agenten für den Unternehmensbereich aus? Ja, Davis, ich weiß, dass du das Kapitel über Sicherheit in dem Buch geschrieben hast. Warum fängst du nicht einfach mit deiner Sichtweise auf das Thema Sicherheit an?

Okay, damit ein Unternehmen einen Agenten in seine Abläufe integrieren kann, muss es sicher sein, dass dieser Agent sicher ist. Es spielt keine Rolle, wie gut der Agent arbeitet, wenn irgendeine beliebige Person im Internet einfach so hineingehen und Ihre Datenbank löschen kann. Er muss also im Grunde genommen über Berechtigungen verfügen, er muss identifiziert sein, er muss in Ihrem OAuth-System registriert sein, damit Sie festlegen können, worauf er Zugriff hat und worauf nicht.

Die Kommunikation muss über sichere Protokolle erfolgen. Sie müssen sicherstellen, dass die gesamte Kommunikation verschlüsselt ist. Sie müssen sicherstellen, dass niemand, der dazu nicht berechtigt ist, einfach sehen kann, was der Agent tut, dass niemand, der dazu nicht berechtigt ist, dem Agenten Anweisungen erteilen kann und dass der Agent keine Daten einsehen oder darauf zugreifen kann.

Das sollte eigentlich nicht möglich sein, damit es seine Aufgabe erfüllen kann, wenn man das alles könnte. Nun, das ist, ja, irgendwie interessant. Davis, für mich klingt es so, und darauf werden wir wahrscheinlich noch zurückkommen, dass, äh, und das haben wir auch im Buch oder an anderer Stelle gesagt, ein Enterprise-Agent äh, genau wie jede andere Unternehmensanwendung ist, die eine Identität hat, Rollen und Berechtigungen, und bei der die Kommunikation sicher ist.

Also, das ist also die andere Sache, die ich angesprochen habe. Wir sprechen hier von etwas, das in mancher Hinsicht sehr neu klingt, aber eigentlich gar nicht neu ist. Tatsächlich geht das Modell, das wir in dem Buch verwendet haben, davon aus, dass die Sicherheit für einen Agenten dasselbe Sicherheitsniveau widerspiegeln sollte.

Es gibt zwar offensichtlich einige Unterschiede, aber sie sollte dieselben Prinzipien und dieselben Ideen widerspiegeln wie jede andere wichtige Unternehmensanwendung. Okay. Ja, nein, das leuchtet mir vollkommen ein.

Ähm, und das macht die Sache natürlich auch ziemlich kompliziert. Ähm, okay. Aber, äh, aber ja, natürlich braucht man das, aber man bräuchte wohl auch, denke ich, jedenfalls … lass uns vielleicht darauf zurückkommen, denn man bräuchte ja auch eine Art, ähm, automatisierte Architektur, die um diese Sicherheit herum aufgebaut ist, oder?

Denn die Sicherheit in dieser Größenordnung zu verwalten, wird extrem, extrem kompliziert sein. Ähm, ja, auf jeden Fall. Wenn wir darüber nachdenken – nehmen wir mal das Beispiel aus dem Unternehmensbereich, das mir sehr vertraut ist und das wahrscheinlich den meisten bekannt ist: Wenn wir die Analogie eines Agenten mit einer Person fortsetzen – was ich für durchaus passend halte –, muss ein Agent genauso wie eine Person eingearbeitet werden.

Und wenn du eingestellt wirst, wirst du überprüft: Bist du der Aufgabe gewachsen? Verfügest du über die erforderlichen Fähigkeiten und Kompetenzen für diese Stelle? Ähm, sobald du eingestellt bist, erhältst du eine Identitätsnummer.

Und sobald man als Mitarbeiter eine Identität hat, erhält man eine Mitarbeiter-ID. Je nach Position erhält man die entsprechenden Berechtigungen, um seine Arbeit tatsächlich ausführen zu können. Ähm, also, die Analogie dazu ist eigentlich, äh, eine andere, die wir gerne anführen, ist, ähm, genau wie, wie Sie Begriffe rund um, äh, HR oder Personalmanagement gehört haben, denken wir, dass dieselben Disziplinen, dieselben Praktiken, wiederum im Rahmen des Möglichen, auf Agenten angewendet werden können.

Agenten können eingearbeitet werden. Wie Davis bereits erwähnt hat, haben Agenten eine Identität und eine Rolle – wir glauben, äh, um hier mal einen neuen Begriff zu prägen, äh, und ich weiß nicht, ob das zu weit geht, aber genauso wie wir HR- oder Personalmanagementpraktiken haben, sollten wir zumindest über AR- oder Agentenressourcenpraktiken nachdenken. Das ist eine gute Analogie, aber wir glauben, dass sie tatsächlich ziemlich weit geht, was die Frage betrifft, wie man über den Schutz und die Sicherheit im Zusammenhang mit Agenten nachdenken sollte.

Ja. Ähm, nein, aber das ergibt, äh, ja, noch mal, es ist, es ist, es ist ziemlich, äh, es ist, es ist, es ist Neuland, oder? Aber es macht Sinn.

Ähm, aber schauen wir uns doch mal den nächsten Aspekt an. Ähm, die Zuverlässigkeit. Das hängt natürlich mit der Sicherheit zusammen, aber wie sieht es mit der Zuverlässigkeit eines Agenten der Enterprise-Klasse aus?

Ja, klar. Ich übernehme das mal, ähm, was die Zuverlässigkeit angeht. Es gibt, es gibt eine ganze Reihe verschiedener Definitionen.

Ähm, und ich werde Themen wie Vertrauen erst mal beiseite lassen, denn darüber werden wir wahrscheinlich später sprechen. Also, lassen Sie uns über Zuverlässigkeit in einem ganz konkreten Zusammenhang sprechen.

Wenn wir sagen, dass etwas zuverlässig ist, wissen wir, was es tut, was es tun soll, äh, wir können beobachten, ob es seine Aufgabe erfüllt hat, und dann können wir es beheben, wenn es seine Aufgabe nicht erfüllt hat. Ähm, das ist also ein Aspekt davon, und wir denken, dass das besonders wichtig für Agenten ist. Sie sind also nicht nur auffindbar und wir können ihren Zweck verstehen, äh, und sie können Aufgabe erstellen, sondern wir können tatsächlich sehen, was sie getan haben.

Und wenn sie nichts unternommen haben, können wir uns daran machen, das Problem zu beheben. Ein weiterer Aspekt der Zuverlässigkeit ist die Frage: Ist das System verfügbar, wenn ich es erwarte? In diesem Zusammenhang gelten dieselben Grundsätze, die wir auch bei einigen unserer Anwendungen anwenden, die sich möglicherweise in der Cloud befinden, Cloud bei einigen der SaaS-Anwendungen, die wir in unserem Unternehmen nutzen.

Ähm, es wird Service-Level-Anforderungen hinsichtlich der Verfügbarkeit, der Reaktionszeit oder der Latenz geben. Ähm, all diese Dinge sollten unserer Meinung nach auf die Mitarbeiter angewendet werden. Das Interessante daran ist, dass wir versuchen, so weit wie möglich Analogien zu Dingen herzustellen, die die Leute tatsächlich verstehen.

Der Grund dafür ist zum einen, dass sie durchaus passend sind, aber es entmystifiziert auch das gesamte Konzept rund um Agenten. Und wir stellen fest: Wenn man die Architekturbrille aufsetzt, sieht man, dass diese Konzepte schon seit langem existieren. Also, zum Beispiel die Herausforderungen des verteilten Rechnens – wenn viele Agenten in der Cloud anderswo laufen –, die Probleme der Verteilung, die Herausforderungen rund um das verteilte Rechnen – sie sind nicht einfach zu lösen, aber sie sind lösbar.

Das ist gängige Praxis. Das heißt nicht, dass es einfach ist, aber es ist gängige Praxis. Was also die Zuverlässigkeit angeht, handelt es sich um bewährte Verfahren, und wir sind der festen Überzeugung, dass Sie diese Verfahren direkt auf die Agenten anwenden sollten.

Das ist ja auch nicht anders als bei jeder anderen, äh, Unternehmensanwendung. Ja, nein, das leuchtet mir total ein. Aber es ist eben, ja, dieser Übergang ist schwierig, oder?

Weil es bisher nur bei einigen wenigen ausgewählten Mitarbeitern bekannt war. Und wenn man nun etwas skaliert, als, äh, als Agentennetzwerk, muss man im Grunde genommen das vervielfachen und dieses Wissen über solche, ähm, Maßnahmen auf mehr Mitarbeiter übertragen oder zumindest die Architektur so aufbauen, dass skalierbar.

Das ist, äh, super, super schwierig. Ähm, aber wir sind noch nicht einmal, äh, auf halbem Weg. Aber, äh, vielleicht nehmen wir ja nicht alle.

Ähm, ich möchte auch Zeit für Fragen einplanen, falls jemand aus dem Publikum Fragen hat. Aber lassen Sie uns, ähm, lassen Sie uns zum nächsten Punkt übergehen, denn das ist ja ein naheliegendes Thema, oder? Erklärbarkeit – was ist das, und wie können wir Agenten, ähm, wie können wir sie im Grunde genommen erklären?

Ja, ich kann anfangen. Und dann, Davis, ich weiß, dass du dazu ziemlich klare Ansichten hast. Ähm, wenn man sich heute ansieht – ich werde das mit dem vergleichen, was die Leute heute vielleicht nutzen, zum Beispiel Claude Code, oder Codex oder sogar ChatGPT –, dann sieht man, dass dort „Denken“ steht.

Und was das eigentlich ist: Es ist zwar nicht ganz ein Aufgabe , aber es ist so etwas wie eine Schleife. Ähm, aber es erklärt, was es tut. Man kann das also tatsächlich sehen, wenn man eines der modernen Programmierwerkzeuge oder Programmieragenten nutzt, die es heute gibt. Wir glauben, wenn man in den Unternehmensbereich wechselt, wo Agenten vollwertige Teilnehmer an Geschäftsprozessen sind, braucht man nicht nur Beobachtbarkeit sie getan haben, sondern muss auch wissen, ob sie das Richtige getan haben.

Wenn also ein Agent in unserem System einen Aufgabe erstellt, empfehlen wir tatsächlich, dass dieser Aufgabe , also, im Bereich der Beobachtbarkeit eine zentrale Rolle spielt. Mm-hmm. Er spielt insofern eine zentrale Rolle, als er protokolliert werden sollte.

Und sobald der Agent seine Aufgabe abgeschlossen Aufgabe sollten die Ergebnisse irgendwie an diesen Aufgabe angehängt oder mit ihm verknüpft werden. Wenn wir uns dann die Beobachtbarkeit ansehen – die Latenz oder ob die Aufgabe erfolgreich abgeschlossen wurde oder nicht –, wird dies wiederum mit diesem Aufgabe verknüpft. Was also letztendlich passiert: Wenn ein Agent seine Arbeit erledigt, können wir den Aufgabe einsehen, was er zu tun glaubte, wir können uns die Ergebnisse ansehen, um zu beurteilen, wie gut er abgeschnitten hat, und wir können anhand der Beobachtbarkeit nachsehen, mit wem er kommuniziert hat, um diese Aufgabe tatsächlich zu erledigen.

Ein solches Maß an Erklärbarkeit gibt es heute noch nicht. Wir verfügen zwar über gewisse Möglichkeiten und arbeiten mit einigen Kunden zusammen, bei denen wir beginnen, diesen Weg einzuschlagen. Aber die Codierungsagenten, die Sie heute sehen, verfügen nicht über diese Fähigkeit.

Die Agenten-Frameworks verfügen derzeit nicht über diese Fähigkeit. Sie können zwar Teile davon umsetzen, aber die Erklärbarkeit umfasst das durchgängige Verständnis: Was hat der Agent gedacht, wie sah der Aufgabe aus, wie hat er die mit dem Aufgabe verbundenen Ergebnisse erzielt und wie sieht es mit der Beobachtbarkeit aus? Mit wem hat er kommuniziert – seien es Tools oder andere Agenten –, um diesen Aufgabe tatsächlich zu erfüllen?

Das bedeutet es, als erster eingetragen zu werden – als erster, der protokolliert wird. So kann jeder, der für die Betriebsbereitschaft zuständig ist und ein Problem entdeckt, das er diagnostizieren muss, diese Informationen – die Ergebnisse und die Liste der Beteiligten – tatsächlich in seinem Aufgabe nutzen, um das Problem zu diagnostizieren. Als Entwickler erhält man diese Informationen, um sicherzustellen, dass der eigene Agent tatsächlich getestet und von Fehlern befreit wurde.

Diese Erklärbarkeit bietet also so viele Anwendungsmöglichkeiten, weshalb wir glauben, dass sie tatsächlich eine der – nun ja, sie ist etwas, das heute noch nicht ohne Weiteres verfügbar ist, aber wahrscheinlich eine der wichtigsten Anforderungen in der heutigen Unternehmenswelt darstellt. Und sie spielt in unserem Buch eine herausragende Rolle. Ja, auf jeden Fall.

Davis, möchtest du dazu etwas sagen, oder sollen wir weitermachen? Ähm, ich finde, Erics Antwort war ziemlich gut. Er hat hier viele Aspekte abgedeckt.

Ähm, eine Sache, die ich noch hinzufügen möchte, ist, dass man nicht nur den Plan selbst nachverfolgen muss. Was Sie wollen, ist, dass der Agent Erklärungen dazu liefert, warum er etwas tut – Sie möchten sehen können, warum der Agent tut, was er tut, und dies zusammen mit der eigentlichen Ausführung Aufgabe anzeigen. Sie sehen also nicht nur: „Ich plane Schritt 1, 2, 3“, sondern Sie möchten sehen: „Ich führe Schritt 1, 2, 3 aus den Gründen X, Y, Z aus.“

Auf jeden Fall. Guter Punkt, Davis. Auf jeden Fall.

Guter Punkt.

Ähm, und ich bin den Teilnehmern sehr dankbar, die im Frage-und-Antwort-Bereich einige Fragen gestellt haben. Ähm, ich denke, wir sollten gleich dazu übergehen. Ähm, ich wollte hier nur noch einmal zusammenfassen: Wir haben über Sicherheit, Zuverlässigkeit und Erklärbarkeit gesprochen.

Ähm, was die Agenten für den Unternehmensbereich angeht: Wir haben nach wie vor Scalability, Auffindbarkeit, Beobachtbarkeit und weitere Funktionen, die es zu entdecken gilt. Aber ich denke, wir sollten uns nun den Fragen zuwenden, die im Chat gestellt wurden.

Ähm, ich denke, die Teilnehmer sollen die Möglichkeit haben, Antworten auf ihre Fragen zu erhalten. Und dann, ähm, könnten wir vielleicht ein oder zwei Blogbeiträge dazu veröffentlichen – über die Daten- und Analyseplattform „Substack“, die wir haben, oder sogar auf unserer Website, wenn ihr Lust dazu habt. Aber, ähm, aber lasst uns, äh, lasst uns auf jeden Fall zu den Fragen im Chat übergehen, äh, oder im Q&A, entschuldigt bitte.

Äh, ich sehe beide Fragen hier, äh, im Frage-und-Antwort-Bereich und in, ähm, okay, ich habe sie hier. Äh, einen Moment bitte. Also, äh, Ronald, Ronald von, ähm, Ronald Ban, ich glaube aus den Niederlanden.

Es ist toll, dass Sie bei diesem Webinar dabei sind. Und er fragt: „Ich interessiere mich dafür, wie man Mitarbeiter testet und trainieren , damit trainieren den Anforderungen der jeweiligen Stelle gewachsen sind – wer sollte das übernehmen und wie geht man dabei vor, damit man für bestimmte Aufgaben zertifizierte Mitarbeiter hat?“ Ich denke, das ist eher eine übergeordnete Frage, die einige der Dinge anspricht, die wir gerade besprochen haben, äh, oder bereits ausführlich besprochen haben, ähm, in den vorherigen Fragen.

Aber, aber vielleicht ist es gut, mal einen Schritt zurückzutreten und so, hast du das Gefühl, kannst du das spüren, äh, ich habe meine eigene Definition davon, aber ich bin mir nicht sicher, ob ich eine kurze Antwort auf diese Frage geben kann, aber, okay, versuchen wir es noch einmal. Wer sollte, also, ich interessiere mich dafür, wie man Agenten testet und weiterbildet oder trainieren , damit trainieren der Aufgabe gewachsen sind. Wer sollte das tun und wie geht das?

Na ja, na ja, lass mich mal anfangen, und dann, Davis, äh, ich bin mir sicher, du hast da ein paar Ideen. Ähm, ja, auf den ersten Blick würde man sagen, das Testen eines Agenten sei dasselbe wie das Testen von Software. Es ist aber tatsächlich eine ganz andere Sache.

Und der entscheidende Grund dafür ist, äh, dass man, wenn man Software testet, die deterministisch ist – mit anderen Worten, die bei gleichen Eingaben immer die gleiche Reaktion liefert –, einfache Dinge wie Ungleichheitsoperatoren, ähm, ganz selbstverständlich beim Testen mit Agenten einsetzt. Das ist nicht unbedingt der Fall. Ein Agent verfügt natürlich über ein LLM als Gehirn, äh, um diesen Begriff zu verwenden.

Ähm, aber diese LMS sind nicht deterministisch. Im Klartext bedeutet das: Wenn ich dieselben Eingaben zweimal mache, erhalte ich ein leicht unterschiedliches Ergebnis. Das heißt, dass der herkömmliche Gleichheitsoperator beim Testen nicht mehr funktioniert.

Was Sie tun müssen, ist, verschiedene Methoden zur Bewertung eines Agenten zu entwickeln. Ähm, also betrachten wir das eher als eine Art Leistungsmanagement oder Agentenbewertung und weniger als reines Testen. Deshalb erstellen wir beispielsweise Bewertungsraster, die sich nach dem Grad der Autonomie und dem Grad der Kritikalität richten.

Es liegt auf der Hand: Wenn man sehr hohe Anforderungen stellt und ein hohes Maß an Autonomie hat, braucht man eine extrem strenge Test- und Bewertungsfähigkeit. Und es gibt vielleicht sechs oder sieben Dimensionen, die bestimmen, was man tun kann oder nicht tun kann, tun muss oder nicht tun muss. Wenn man etwas hat, das eine geringe Kritikalität und geringe Autonomie aufweist, kommt das vielleicht eher einem Chatbot nahe, nehme ich an.

Vielleicht brauchst du gar nicht so viele Tests. Es kommt also darauf an, wo du dich auf diesem Kontinuum befindest. Der zweite Punkt, den ich ansprechen möchte, ist: Wenn du einen Wirkstoff testest, was wir denken – und ich glaube, dafür gibt es eine spezielle Terminologie.

Man hat einen, einen, einen Agenten, einen „Judge-Agenten“, der die Antwort eines anderen Agenten oder eines „Judge“-LLM bewerten kann. Das sind Dinge, die wir tatsächlich in der Praxis beobachten. Wenn man also ein LLM einsetzt, um ein anderes LLM zu testen – ist diese Antwort, ist diese Reaktion vielleicht nicht unbedingt genau dieselbe oder wiederholbar, aber ist die Absicht hinter der Antwort dieselbe?

An dieser Stelle kommt dann die eigentliche Prüfung ins Spiel. Wir nennen das „Bewertung“. Jetzt werde ich Davis ein wenig zum Training befragen.

„Weil ich glaube, Davis, ähm, da gibt es, da gibt es, äh, eine ganze Menge. Ich weiß, dass du vor einiger Zeit Erfahrungen mit einem unserer großen Einzelhandelskunden gemacht hast, was die Frage angeht, ähm, wie sie eigentlich damit anfangen würden, das Modell neu zu trainieren. Und dabei gibt es einige Herausforderungen.“

Und damals haben wir uns Lösungen ausgedacht, die wahrscheinlich ziemlich naiv waren. Vielleicht geht es also nicht so sehr darum, Training Modell Training , sondern vielmehr darum, das Modell mit Informationen über Ihr Unternehmen auszustatten. Können Sie uns dazu vielleicht ein wenig mehr erzählen?

Natürlich ohne den Kunden zu erwähnen. Ja. Es gibt also verschiedene Möglichkeiten, wie man trainieren Agenten sozusagen trainieren und seine Fähigkeiten verbessern kann.

Eine Möglichkeit besteht natürlich darin, das zugrunde liegende Modell Training , aber das ist eine sehr ressourcenintensive Lösung. Man benötigt eine Menge Beispiele, und man muss dies für jeden einzelnen Agenten tun, den man einsetzen will. Das ist einfach nicht skalierbar. Die Möglichkeiten, einen Agenten zu verbessern oder ihm neue Fähigkeiten zu verleihen, die etwas besser skalierbar sind, bestehen darin, ihm mehr Daten zur Verfügung zu stellen oder ihm mehr Werkzeuge oder Mitarbeiter zur Bewältigung der Aufgabe zur Seite zu stellen.

Man kann ihm ein neues Werkzeug zur Verfügung stellen, das ihm die Fähigkeit verleiht, mit der Welt zu interagieren. Indem man diese Fähigkeit des Werkzeugs programmiert und den Agenten sie einfach in den Aufgabe aufnehmen lässt, kann man ihm zusätzliche Partner zur Seite stellen – andere Agenten, mit denen er Kontakt aufnehmen kann und die über Fähigkeiten verfügen, Fähigkeiten Hauptagent nicht besitzt –, und er kann diese Agenten einfach anrufen und sie dazu bringen, die Aufgabe zu erledigen. Oder man kann dem Agenten effektiv mehr Daten zur Verfügung stellen.

Man könnte einen relativ einfachen Algorithmus verwenden, oder man könnte fortgeschrittenere Lösungen wie Wissensgraphen und Ähnliches nutzen, um mehr Informationen zu erhalten. Dadurch kann die KI bessere Entscheidungen treffen, da ihr mehr Informationen zur Verfügung stehen. Und das sind die wichtigsten Methoden, mit denen man einen Agenten trainieren weiterentwickeln kann, der sich auf die Tausenden und Abertausenden von Agenten skalieren lässt, die wir letztendlich erwarten.

Ja, nein, ich möchte auf den letzten Teil von Ronalds Frage zur Zertifizierung eingehen. Denn wir widmen diesem Thema tatsächlich ein ganzes Kapitel. Es ist Teil unseres Framework.

Also, noch einmal, äh, entschuldigen Sie bitte, ich werde noch eine weitere Analogie anführen, ähm, in Kanada – und ich vermute, in Europa ist es genauso –, aber wenn ich in Kanada meinen Toaster kaufe, äh, dann ist unten drauf ein kleines Logo, das von der Canadian Standards Association. Das bedeutet: Mein Toaster wird mein Haus nicht abbrennen, wenn ich ihn benutze. Es bedeutet, dass diese Marke ein gewisses Maß an Serviceerwartung und Qualität verspricht; dieses Label bedeutet, dass dieser Toaster zertifiziert ist.

Ähm, in den Vereinigten Staaten gibt es das Underwriters Laboratory, das genau das Gleiche macht. Ähm, in Europa bin ich mir nicht sicher, aber in Kanada sehe ich, wenn ich mir eine Steckdose anschaue, ein kleines Logo, das besagt, dass diese Steckdose sicher in der Anwendung ist. Wir glauben, dass dasselbe Prinzip auch für Agenten gilt, und wir sehen darin die oberste Ebene dieses Governance-Stacks.

Der Trust-Stack beginnt eigentlich mit Identität und Rollen und erstreckt sich bis hin zur Erklärbarkeit, doch ganz oben stehen letztlich Zertifizierung und Governance. Wir sind fest davon überzeugt, dass es heute Modelle gibt, wie die Canadian Standards Association oder Underwriters Lab, deren föderierte Governance-Modelle und föderierte Zertifizierungsmodelle jeden Tag in der Lage sind, zu bestätigen, dass buchstäblich Millionen, ja Hunderte von Millionen von Produkten sicher in der Anwendung sind. Wir glauben, dass sich dasselbe Konzept auch auf Agenten anwenden lässt.

Wir sind also der Meinung, dass das Modell, wie gesagt, bereits für uns vorgegeben ist. Es umfasst unter anderem einen vollständig delegierten Framework besagt Framework „Ich habe Richtlinien auf Makroebene, Framework ich mich halten muss“, und diese werden dann weiter heruntergebrochen in elektrische Spezifikationen für einen Toaster bis hin zu Spezifikationen für die Heizung und das Metall für den Gehäuse des Toasters. All diese Dinge verfügen über ein föderiertes Framework ein föderiertes Framework akkreditierte Institutionen.

Das klingt jetzt sehr, sehr kompliziert, oder? Und wenn man Hunderte Millionen von Produkten verwaltet, sollte es das vielleicht auch sein, aber innerhalb des Unternehmens funktioniert dieses Modell ebenfalls. Auf der obersten Ebene könnten wir also zum Beispiel sagen, dass ein Agent die DSGVO einhalten muss.

Dieser delegiert dann an, äh, einen Identitätsprüfer. Und man muss sich überlegen, wie dieser Identitätsprüfer die DSGVO-Vorschriften einhalten würde. Das würde man dann auch auf alle anderen Agenten anwenden.

Vielleicht sollten wir also über eine Reihe von Spezifikationen verfügen, die wiederum detailliert, wahrscheinlich nach Geschäftsbereichen, auf einer sehr granularen Ebene aufgeschlüsselt sind. Und dann haben wir für diese Spezifikationen Experten, die diese Spezifikationen tatsächlich validieren können und die mithilfe des zuvor erwähnten Erklärbarkeitsansatzes sicherstellen, dass der Agent diese Spezifikationen auch tatsächlich einhält. Wir glauben, dass dieses Modell – bildlich gesprochen – sicherstellt, dass Ihr Agent Ihr Rechenzentrum nicht in Brand setzt.

Also, wir sehen viele, ähm, Beispiele und Analogien, die Migration agentische Migration eines Unternehmens vereinfachen. Äh, und sie liegen direkt vor unseren Augen. Ole: Ja, nein, das leuchtet ein.

Ich meine, es geht eigentlich darum, einige überraschend konkrete, äh, Perspektiven aus der realen Welt zu übernehmen und sie einfach, äh, ganz unkompliziert auf die Agrarwirtschaft anzuwenden. Ähm, und ich sehe auch, äh, Ronald, äh, danke, dass du uns geantwortet hast und, und, und, und dass die Antwort, äh, vollständig war. Ähm, wir haben auch Fragen von Michael und von, äh, Sabrina.

Hallo, ihr beiden. Es ist toll, euch beim Webinar dabei zu haben. Ähm, Michael, ich fange mal an.

Ich sehe, dass du zuerst gepostet hast, aber ich habe deine Frage auch gesehen, Sabrina. Ähm, Michael Wright möchte also gerne wissen, wie die Teilnehmer die Auswirkungen einer geschäftsdefinierten semantischen Ebene auf KI-Dienstleister einschätzen – insbesondere im Gegensatz zu Systemen wie Epic eHR oder der Sub-EP-Plattform, die ihre Kunden in der Regel dazu zwingen, einen Großteil ihrer Arbeitsabläufe, Nutzer usw. und das mit den Auswirkungen zu vergleichen, die eine geschäftsdefinierte Gentech-Architektur mit sich bringt, sowie zu erörtern, wie KI-Dienstleister wie OpenAI und andere ihr Geschäft skalieren können, wenn ihre Kunden eine eigene, individuell definierte semantische Ebene benötigen. Ja, ich verstehe die Frage.

Verstehst du das? Äh, oder ist es zu lang? Nein, nein, ich lese es gerade.

Eigentlich habe ich es, äh, ich habe es gerade hier vor mir auf dem Bildschirm. Zunächst einmal, ähm, Michael, das ist, äh, eine fantastische Frage, und ich finde, der Zeitpunkt ist aus verschiedenen Gründen wirklich perfekt. Nun, äh, ich bin kein Experte für den Datenkatalog den semantischen Raum, Ole ist es wahrscheinlich, aber lass mich, lass mich dir sagen, ich, ich stoße darauf und ich habe eine Perspektive dazu, weil wir das bei fast jedem Kundenprojekt sehen, an dem wir arbeiten.

Also, lassen Sie mich mal einen Schritt zurücktreten und bei einigen ganz einfachen Grundlagen beginnen. Wenn ein Agent versucht, auf eine Anfrage zu antworten, laden wir, wie Davis bereits erwähnt hat, Informationen über das jeweilige Unternehmen oder Thema so nah wie möglich an diese Anfrage heran, damit dem Agenten alle verfügbaren Informationen zur Verfügung stehen. Das nennt man Context Engineering: Wir wollen den richtigen Kontext zur richtigen Zeit für das richtige Token-Budget finden und diesen in das Kontextfenster des Agenten einfügen, damit er seine Aufgabe möglichst effektiv erfüllen kann.

Die Herausforderung besteht darin, dass in einem Unternehmen, das über Hunderte von Terabytes oder Petabytes an Daten verfügt – einen Datenbestand, sei es strukturierte oder unstrukturierte Daten, Bilder oder Videos –, es Petabytes an solchen Daten gibt. Wie bekomme ich die richtigen Informationen aus diesen Petabytes heraus? Und ich reduziere sie auf effektiv irgendwo zwischen 200.000 und einer Million Token, wobei ein Token in etwa einem Wort entspricht, nur um, um, um, um es, äh, greifbar zu machen.

Ähm, also, also, also, wie mache ich das? Nun, wir haben festgestellt, dass man dafür – nun, das nennen wir – ein „agentisches Wissen“ benötigt, ein „Fabric“ – ein schickes Wort dafür, dass ich in der Lage sein muss, zu identifizieren, dass ich einen virtuellen Kontextmanager brauche, der das Minimum schafft. Ich betone „Minimum“, weil es ein token-budget-taugliches System ist, was bedeutet, dass es Konzepte und Richtlinien sowie Entscheidungsgrenzen hat, und ich kann das in die Agenten oder das Kontextfenster der LLMs einbringen.

Dazu gibt es eine Reihe verschiedener Ansätze. Technisch gesehen könnte man, wie Dave bereits erwähnt hat, eine einfache Registrierung vornehmen, was aber wahrscheinlich nicht unbedingt gut funktioniert. Man könnte dies durch Wissensgraphen ergänzen.

Ähm, da gibt es eine ganze Reihe verschiedener Dinge. Wir haben mit einigen Kunden gesprochen, die Dinge wie den PageRank nutzen, um die Konzepte in einem sehr großen, weitläufigen Graphen grundsätzlich zu verstehen und miteinander zu verknüpfen. Ähm, das ist ein Mechanismus, über den man nachdenken muss, aber man erschließt sich ihn mithilfe von Taxonomien und Ontologien.

Welche Konzepte sollte ich erfassen? Wie stelle ich eine Richtlinie eigentlich in einem Wissensgraphen dar? Wie kann ich die Beziehungen zwischen diesen Richtlinien, die für einen Kunden gelten könnten – im Sinne von Geldwäschebekämpfung, was sich von einem Kunden aus Vertriebssicht unterscheidet –, konkret abbilden? Die Merkmale sind sehr, sehr unterschiedlich.

Das sind also alles Dinge, über die man nachdenken muss, und wir bezeichnen dies als „Agentic Knowledge Fabric“, das, wie ich bereits sagte, auf einem Wissensgraphen, einer Ontologie und einigen taxonomischen Fähigkeiten basiert. Letztendlich braucht man jedoch semantische Beständigkeit und Kohärenz, damit man dem Agenten die richtigen Informationen zur richtigen Zeit und mit dem richtigen Token-Budget bereitstellen kann. Wir sehen das LLM, semantisches Verständnis, Taxonomien, Ontologien – all das sitzt auf diesem Wissensgefüge als die nächste, äh, Innovation innerhalb der Agentenlandschaft.

Das ist sicherlich auch etwas, das ich sehr, sehr genau verfolge und worüber ich nachdenke. Ähm, und, ähm, natürlich geht es in diesem Webinar nicht um Maßnahmen als Unternehmen. Also, aus Respekt vor den Teilnehmern halte ich es nicht für angebracht, hier darauf einzugehen, aber das ist, glaube ich, äh, sehr genau definiert und eine der Herausforderungen, die wir, die gelöst werden müssen, ähm, äh, in der, in der gemeinsamen Zeit.

Richtig. Äh, wir haben auch eine Frage von Sabrina, und ich habe deine Frage gesehen, Sabrina, also möchte ich sie einfach stellen. Ähm, oh, na ja, eigentlich geht es auch ein bisschen um das Testen, äh, also insofern, äh, lass mich sie einfach stellen, aber ich glaube eigentlich, dass du sie, äh, äh, schon beantwortet hast.

Äh, siehst du es auch, äh, Eric und Davis im … Ja, ich, ich sehe es, Lee. Ja, ich habe es im Webinar-Chat gesehen. Ja, ich kann es sehen.

Was, was meinst du? Vielleicht sollten wir DA Davis fragen. Äh, hattest du noch etwas zu dieser Frage beizutragen? Äh, ich glaube, vieles davon wurde bereits in der vorherigen Antwort angesprochen, aber es könnte sich lohnen, einige Punkte noch einmal durchzugehen.

Ähm, eine der ersten Fragen, die aufkommt, ist: Wer sollte die Tests schreiben? Sollten diese von Agenten, von Menschen oder von beiden geschrieben werden? Und das hängt weitgehend davon ab, wie ausgereift Ihr Iden-Netzwerk in der Anfangsphase ist. Wenn Sie Ihren ersten Agenten oder sogar Ihre ersten paar Dutzend Agenten entwickeln, ist es sinnvoll, dass der Großteil Ihrer Tests von Menschen durchgeführt wird.

Du bist noch dabei, den Dreh mit den Agenten herauszubekommen, also wirst du auf manuelle Bewertungen angewiesen sein. Aber wenn das ENT-Netzwerk wächst und du Tausende oder Zehntausende oder noch mehr Agenten hast, wirst du dich zunehmend auf automatisierte Tests der Agenten verlassen müssen, um verwalten dem erforderlichen Umfang verwalten – denn du hast nicht genug Personal, um jede einzelne Ausgabe jedes Mal manuell zu überprüfen. Sie werden auf menschliche Tests nicht vollständig verzichten können.

Man wird weiterhin Menschen brauchen, die sich darum kümmern und überprüfen, ob die Tests tatsächlich korrekt sind, Stichproben durchführen und sicherstellen, dass nichts schiefgelaufen ist, aber wie viel davon auf den Menschen oder das Alter zurückzuführen ist, hängt davon ab, wie weit ihr bei der Entwicklung eures eigenen Project Mesh fortgeschritten seid. Ja, Davis, eines der Dinge, über die wir gesprochen haben, ist, ähm, und ich weiß, wir hatten heftige Debatten mit, äh, einigen anderen Leuten in unserem Unternehmen und einigen Kunden, aber, äh, wenn man an die Autonomie denkt, die hohe Autonomie und hohe Kritikalität, ähm, gibt es eine Diskussion, die besagt, dass es für einige dieser sehr hochautonomen und hochkritischen, ich meine, mit anderen Worten, Szenarien mit hohem Risiko gilt, dass zumindest heute – vielleicht ändert sich das in Zukunft –, aber in absehbarer Zukunft denken wir, dass es eine Untergruppe gibt, die menschliche Interaktion erfordert und menschliche Verifizierung in Bezug auf Sicherheit, zum Beispiel bei Zahlungen mit hohem Wert, wo es möglicherweise ein gewisses Betrugsrisiko oder Geldwäscheprobleme gibt. Es gibt eine Untergruppe der Tests, von der wir glauben, dass sie auf absehbare Zeit bestehen bleiben muss oder zumindest ausdrücklich einen Menschen im Regelkreis oder über dem Regelkreis haben muss.

Ja.

Ähm, ich denke, ich werde, ähm, da wir uns dem Ende nähern, ich, ich glaube, ich würde gerne, ähm, die letzte Frage stellen, die ich vorbereitet hatte, und wir können dann auf die verbleibenden, äh, Diskussionsthemen, äh, in den Beiträgen zurückkommen. Aber ich möchte Sie fragen, ähm, wie, wie war es, wie war es, dieses Buch zu schreiben? Äh, denn ich nehme an, bei allen Büchern hat man ein bestimmtes Gefühl.

Das kommt vor, sie können zu früh sein, äh, sie können genau richtig sein, sie können zu spät sein, das kann unterschiedliche Reaktionen hervorrufen. Wie war denn bisher das Feedback? Sind Sie zu früh dran?

Du auch? Ich glaube, du bist noch nicht zu spät. Na ja, also, lass mich mal anfangen, und dann lasse ich wohl Davis erzählen, wie es war, mit seinem Vater zusammenzuarbeiten.

Aber, äh, aber, aber ich würde sagen, als Davis und ich auf die Idee für dieses Buch kamen, war es so: Ole weiß das, er hat schon ein paar Bücher bei O'Reilly veröffentlicht. Das ist ein langer Prozess. Das war also vor etwa 14 bis 16 Monaten, als wir noch nicht wussten, wie sich die Agentenszene entwickeln würde.

Ähm, wir… so etwas wie „Claude Code“ oder „Codex and Chat“ gab es damals noch gar nicht. GPT war noch bei Version 3.5 oder so. Nicht besonders, äh, effektiv, um ehrlich zu sein, zumindest nicht im Vergleich zu heute.

Es war, es war damals wunderbar, aber im Vergleich zu heute war es, ähm, war es nicht wirklich so, wie es sein sollte. Ähm, interessanterweise haben wir uns noch einmal mit Analogien beschäftigt. Was ist denn in Unternehmen passiert, als man von einem auf viele umgestellt hat?

Also, damals habe ich viel mit APIs gearbeitet, und wenn man nur ein, zwei oder drei APIs hat – was schon sehr, sehr lange her ist –, ist es einfach, verwalten zu verwalten . Aber wenn man 10, 100 oder 1.000 APIs hat, muss man ganz anders denken. Das Gleiche gilt für Datenprodukte.

Wenn man ein oder zwei Datenprodukte hat, ist das interessant, aber wenn man zehn, hundert, äh, mehr als hundert hat, wie es bei einigen meiner Kunden der Fall ist, muss man das Ganze ganz anders angehen. Man muss über andere Verwaltungsmethoden nachdenken. Als Davis und ich also die Idee für dieses Buch hatten und sie O’Reilly vorstellten, war das unser Argument: Wir wollen es nicht bei einem einzigen Agenten belassen.

Wir werden, na ja, Zehntausende, Hunderttausende haben. Und die Branchenführer haben das bestätigt. Also, um es kurz zu machen: Bei Olay glauben wir, dass wir zur richtigen Zeit am richtigen Ort sind, was wir vor 16, 14, 16 Monaten noch nicht wussten, aber wir haben das Glück, gerade jetzt dort zu sein.

Ja, das sehe ich auch so. Äh, Davis, möchtest du etwas dazu sagen? Ich würde gerne mehr darüber erfahren, wie es war, mit deinem Vater zu schreiben.

Ja, mit Nori an dem Buch meines Vaters zu arbeiten, war eine tolle Erfahrung. Wir kennen uns natürlich schon sehr gut, und wir sind einfach auf einer Wellenlänge, wenn wir über unsere Ideen sprechen. Ähm, es war allerdings ganz anders als die übliche Beratungsarbeit, die wir gemeinsam leisten, vor allem, weil mein Vater viel mehr Erfahrung mit dem Schreiben von Büchern hat, als ich zu Beginn dieses Projekts hatte.

Und ich bin wirklich froh, dass ich das Buch gemeinsam mit jemandem geschrieben habe, der diese Erfahrung hatte, denn das hat uns sehr dabei geholfen, das Buch auf das hohe Niveau zu bringen, das wir uns selbst gesetzt hatten. Ja, nein, das leuchtet mir total ein. Ich meine, es ist auch – und, na ja, wirklich, wirklich, es ist einfach eine ganz, ganz andere Erfahrung, mit jemand anderem zu schreiben und zum ersten Mal ein Buch zu schreiben.

Aber ich habe auch das Gefühl, dass – wenn ich etwas zum Zeitpunkt der Veröffentlichung deines Buches sagen soll – es genau zum richtigen Zeitpunkt erscheint, denn es ist ja nicht so, dass das jetzt schon jeder erkennt. Die Leute sehen, dass wir darüber nachdenken müssen, wie wir die Strukturen in unserem Unternehmen aufbauen, und wir können auch verstehen, dass das nichts ist, was man auf die leichte Schulter nehmen kann. Das wird kompliziert zu bewerkstelligen sein, oder?

Ich finde also, das Buch kommt genau zum richtigen Zeitpunkt und ist eine äußerst interessante Lektüre. Also, ähm, ich möchte mich mit diesen Worten bei euch dafür bedanken, dass ihr heute an diesem Webinar teilgenommen habt. Und wir melden uns bald wieder mit weiteren Einblicken in Form von Beiträgen und Artikeln.

Ich kann Ihnen versichern, dass Sie auf jeden Fall herzlich eingeladen sind, für uns zu schreiben. Und ich würde mich freuen, gemeinsam mit Ihnen zu schreiben. Außerdem möchte ich mich bei allen Teilnehmern für ihre Geduld bedanken.

Das war, ähm, wohl ein etwas fachspezifisches Webinar, aber auch sehr wichtig. Vielen Dank also an alle fürs Zuhören und, ähm, vielen Dank an Eric und Davis. Und Ole, vielen herzlichen Dank an dich und das gesamte Acton-Team, dass wir dabei sein durften.

Vielen Dank. Und ich bedanke mich ebenfalls. Es war toll, dabei zu sein.

Danke.