Kategorie: Einblicke

Ein Modell wird angebunden, die Antwortzeiten sinken, die Trefferquote steigt. Ein halbes Jahr später steht davon kaum etwas in der Ergebnisrechnung. Das ist kein Technikfehler, sondern ein Muster. PowerGate Software hat zusammengetragen, an welchen Stellen KI-Projekte hinter den eigenen Erwartungen zurückbleiben.

Die Modelle selbst sind selten das Problem. Sie werden schneller, günstiger und vielseitiger. Das verleitet zu der Annahme, die Einführung sei vor allem eine Frage der richtigen Auswahl. Der Aufwand steckt woanders: bei der Frage, welches Problem überhaupt gelöst werden soll, bei den Daten, bei der Einbettung in bestehende Abläufe und bei der Definition von Erfolg. Ein Bild aus dem Bauwesen hilft. Eine hocheffiziente Heizungsanlage in einem Haus mit undichten Rohren und ungedämmten Wänden heizt am Ende die Straße. Die Anlage ist gut, das Gebäude passt nicht zu ihr.

Ein Chatbot ist noch kein Geschäftsproblem

Oft steht die Technologie am Anfang. Ein Unternehmen beschließt, dass es einen Chatbot, einen KI-Assistenten oder einen Agenten braucht, weil diese Systeme gerade überall auftauchen. Dann wird ein Anwendungsfall gesucht. Umgekehrt wäre besser: erst das Problem, dann das Werkzeug. So entstehen Projekte, die technisch laufen und geschäftlich wenig bewegen.

Ein Assistent, der Fragen von Mitarbeitenden sauber beantwortet, klingt nach einem Erfolg. Nutzt ihn kaum jemand oder hängen die Antworten nicht an der täglichen Arbeit, bleibt der Nutzen klein. Zurück zum Bild: Erst klären, welche Räume kalt sind und wo Wärme verloren geht. Dann entscheiden, ob eine neue Anlage die richtige Antwort ist. Praktisch heißt das, den Punkt zu suchen, an dem Zeit, Geld oder Chancen verloren gehen, und dann zu prüfen, ob KI dort hilft.

Datenqualität entscheidet mehr als die Modellwahl

KI-Systeme hängen von Qualität, Zugänglichkeit und Governance der Daten ab, mit denen sie arbeiten. In vielen Organisationen liegen diese Daten über verschiedene Systeme verteilt, in unterschiedlichen Formaten, mit Dubletten, an Stellen, die sich nur schwer erschließen lassen. IBM nennt Datenqualität und Datenreife, fragmentierte Datenlandschaften, Governance und Sicherheit als zentrale Hürden, sobald Unternehmen über das Experimentierstadium hinausgehen.

Deutlich wird das bei Systemen, die auf internem Wissen aufbauen. Ein leistungsfähigeres Modell gleicht unvollständige, widersprüchliche oder schlecht verwaltete Daten nicht aus, so wie ein stärkerer Brenner kein Leck in der Leitung schließt. Die Daten vorzubereiten, klare Zugriffsregeln zu setzen und die relevanten Quellen anzubinden, ist deshalb keine Vorarbeit für später, sondern die Arbeit selbst. Wer hier spart, zahlt mit Fehlern, Nacharbeit und Vertrauensverlust.

KI in bestehende Arbeitsabläufe integrieren

Zwischen einem funktionierenden Werkzeug und der tatsächlichen Arbeitsweise von Mitarbeitenden liegt oft eine Lücke. Eine Anwendung erledigt eine Aufgabe für sich genommen gut, während Informationen weiterhin manuell zwischen dem KI-Tool und dem CRM, dem ERP oder der Dokumentenablage hin- und hergeschoben werden. Jeder dieser Schritte kostet Zeit und erzeugt Fehlerquellen, die den ursprünglichen Nutzen auffressen.

Eine gute Workflow-Integration verbindet die Fähigkeiten des Modells mit den vorhandenen Prozessen und Systemen und entfernt überflüssige Handgriffe. Häufig reicht es nicht, das bestehende Verfahren unverändert zu lassen und KI daneben zu stellen. Der Prozess selbst muss angepasst werden, sonst kommt der unterstützende Beitrag an der falschen Stelle an. McKinsey verweist in diesem Zusammenhang auf das Redesign von Workflows, um aus der Einführung generativer KI tatsächliche Geschäftswirkung zu machen.

Realistische Erwartungen an KI-Projekte

Die Fähigkeiten der Systeme haben sich schnell verbessert, und mit ihnen die Erwartungen. Manche Organisationen glauben, ein neues Werkzeug übernehme einen kompletten Prozess von Anfang bis Ende, obwohl sich nur einzelne Schritte zuverlässig abdecken lassen. Andere erwarten unmittelbare Kosteneinsparungen und blenden Implementierung, Integration, Überwachung und laufenden Betrieb aus.

Das heißt nicht, dass KI wirkungslos wäre. Es heißt, dass der Zuschnitt eines Projekts zum Problem und zum Reifegrad der Technik passen muss. Die Heizungsanalogie trägt auch hier: Wer ein ganzes Gebäude auf einmal umrüstet, trägt hohes Risiko und merkt erst spät, ob die Auslegung stimmt. Ein einzelner Raum, sauber geplant und gemessen, liefert schneller belastbare Erkenntnisse. Ein kleinerer, messbarer Anwendungsfall ist deshalb oft der realistischere Weg zu einer breiteren Nutzung.

Erfolg von KI-Projekten messen

Ein weiteres Problem entsteht vor dem Start: Es wird selten festgelegt, woran Erfolg gemessen werden soll. Technische Kennzahlen wie Antwortzeit, Genauigkeit oder Anzahl der Nutzenden sind leicht zu erheben, sagen aber wenig darüber aus, ob das Projekt dem Geschäft hilft.

Ein Kundenservice-Chatbot kann eine hohe Trefferquote haben und trotzdem die Supportlast nicht senken. Ein KI-Assistent für die Softwareentwicklung kann breit genutzt werden und kaum Wirkung auf Entwicklungskosten oder Lieferzeiten haben. Aussagekräftig sind betriebswirtschaftliche Größen: kürzere Durchlaufzeiten, geringere Betriebskosten, schnellere Reaktionszeiten, höhere Abschlussquoten, weniger manuelle Fehler. Welche davon bei dir zählen, hängt vom Anwendungsfall ab. Sie müssen vor dem Start definiert werden, nicht nachträglich aus dem, was sich ohnehin messen ließ.

Was einen pragmatischen Ansatz auszeichnet

Ein Patentrezept gibt es nicht, aber ein paar Prinzipien senken das Risiko. Erstens: ein Geschäftsproblem wählen, dessen Nutzen sich benennen lässt. Zweitens: vor der Entwicklung prüfen, wie es um Qualität und Zugänglichkeit der Daten steht. Drittens: von Anfang an mitdenken, wie sich die Lösung in bestehende Systeme und Abläufe einfügt, statt sie als isoliertes Werkzeug zu behandeln.

Nach dem Start ist das Projekt nicht beendet. Anforderungen, Datenbestände, Nutzerverhalten und Modelle verändern sich, weshalb fortlaufende Beobachtung und Nachbesserung die Regel sind. Aus Sicht der Softwareentwicklung geht es deshalb selten um das beste Modell. Es geht darum, ob die Technik zum Geschäftskontext passt.

Chung Tran, Technologieexperte bei PowerGate Software, sagt: KI-Projekte schaffen mehr Wert, wenn sie an ein klares Geschäftsziel und einen bestehenden Arbeitsablauf angebunden sind. Unternehmen müssen nicht mit einer groß angelegten Implementierung beginnen. Ein fokussierter Anwendungsfall, verlässliche Daten und klare Erfolgskriterien sind ein praktikablerer Ausgangspunkt. Das deckt sich mit einer Verschiebung im Markt: Unternehmen gehen zunehmend über kleine Experimente hinaus, doch Skalierung verlangt Aufmerksamkeit für Daten, Prozesse, Infrastruktur, Governance und die Akzeptanz der Nutzenden, nicht nur für das Modell. IBM beobachtet bei Organisationen auf dem Weg zu breiterer KI-Nutzung ähnliche Herausforderungen rund um Daten, Governance, Wirtschaftlichkeit, Fachkräfte und die Einbindung in Workflows.

Damit verschiebt sich die Frage. Sie lautet nicht mehr, ob KI eingesetzt wird, sondern an welcher Stelle sie ein echtes Problem löst und wie sich ihre Wirkung belegen lässt. Das braucht kein großes Strategiepapier und keine komplexe Architektur. Oft genügt ein überschaubarer Anwendungsfall, an dem sich prüfen lässt, ob ein konkreter Prozess besser läuft. Aus Nutzerfeedback und gemessenen Ergebnissen lässt sich dann entscheiden, ob sich der Ansatz ausweiten lässt.

KI kann Unternehmen realen Nutzen bringen. Nur entsteht er selten durch das bloße Hinzufügen eines Werkzeugs. Er entsteht, wenn am Anfang ein praktisches Problem steht, die Daten tragen, die Erwartungen zur Technik passen und der Erfolg an Größen gemessen wird, die im Geschäft zählen. Die Heizung bleibt das passende Bild: Entscheidend ist nicht die Leistung auf dem Datenblatt, sondern ob das Gebäude am Ende warm wird.

Quelle: designbeep.com

07:33 Uhr UTC, 13. September: Ein interner Datenbereinigungsjob bei GitHub beginnt, in einen geteilten Datenbank-Cluster zu schreiben. Drei Stunden und elf Minuten später, um 10:44 Uhr UTC, laufen alle Dienste wieder. Dazwischen liegt ein Ausfall, der große Teile der Plattform erfasst hat. Der Incident Report von GitHub trägt den Titel „Incident with several GitHub Services“ und beschreibt den Ablauf. Der Blog surfingcomplexity hat ihn nachgezeichnet und mehrere bekannte Risikomuster herausgearbeitet.

Der Bericht ist kurz und benennt den Fehlermechanismus in wenigen Absätzen. Die Kette lässt sich Schritt für Schritt nachvollziehen, ohne Spekulation. Spannend ist weniger der einzelne Fehler als das Zusammenspiel: eine unvollständige Gesundheitsmetrik, zu großzügige Timeouts und ein Retry-Verhalten, das die Lage verschärft statt entspannt. Betroffen ist am Ende jeder, der ein System mit zentraler Datenbank betreibt.

Der Ablauf am 13. September: vom Aufräumjob zur Sättigung

GitHub betreibt einen Datenbank-Cluster in klassischer SQL-Bauweise: ein Primärknoten, der alle Schreiboperationen verarbeitet, plus mehrere Lesereplikate. Dieser Cluster trägt Online-Verkehr. Er speichert Berechtigungsdaten, die fast jede authentifizierte Anfrage liest. Parallel schrieb ein Offline-Job, also ein Prozess ohne Nutzerverkehr, in dieselbe Datenbank, um nicht mehr benötigte Daten zu entfernen. Gesteuert wurde seine Schreibrate von einer Schutzvorrichtung, die ein einziges Signal beobachtete: den Rückstand der Replikate gegenüber dem Primärknoten. Das Signal blieb während der gesamten Dauer unauffällig.

Was der Mechanismus nicht sah: Der Primärknoten selbst lief auf seine Belastungsgrenze zu. Als er die maximal zulässigen Client-Verbindungen erreichte, konnten neue Datenbankaufrufe nicht mehr bedient werden. In MySQL sind das der Parameter max_connections und der Fehler ER_CON_COUNT_ERROR mit der Meldung „Too many connections“. Die betroffenen Anfragen scheiterten aber nicht schnell. Sie blieben hängen, weil die Timeouts zu lang konfiguriert waren. So sammelten sich laufende Anfragen in den Webservern an und verbrauchten Ressourcen, bis auch diese Server gesättigt waren und die Fehler flächendeckend auftraten. Ein Retry-Loop rund um die Token-Erstellung schickte die fehlschlagenden Schreibvorgänge immer wieder los und hielt die Datenbank in der Sättigung, statt ihr Erholung zu lassen.

Um 08:50 Uhr UTC erklärte das Monitoring den Vorfall. Weil die Wirkung breit war und die Token-Erstellung die Lage verstärkte, dauerte es eine Weile, bis die Lastquelle identifiziert war. Die Ersthelfer drosselten interne Last und pausierten den Bereinigungsjob. Um 10:44 Uhr UTC hatten sich alle Dienste erholt. Zwischen Auslöser und Wiederherstellung liegen gut drei Stunden, und der größte Teil davon entfiel nicht auf die Behebung, sondern auf das Verstehen.

Replica Lag als blindes Auge: gemessen wurde das Falsche

Für diese Art Fehler gibt es in der Resilienz-Engineering-Literatur einen Begriff: Gray Failure, ein Fehler, der für das Monitoring unsichtbar bleibt, während die Nutzer ihn längst spüren. Die internen Metriken sehen gut aus, die Anwender sind unzufrieden. Der Autor beschreibt das als Fehleinschätzung der Sicherheitsgrenze. Man weiß nie genau, wo sie liegt, bis man sie überschreitet — und das Überschreiten ist teuer. Also schätzt man sie, hält Abstand und übersieht dabei zwangsläufig einige der vielen Grenzen, die ein System gleichzeitig hat.

Man kann sich das wie ein Straßennetz vorstellen, dessen Messstelle an einer Nebenstraße hängt, während der Engpass an der Hauptzufahrt entsteht. Solange die Nebenstraße flüssig läuft, meldet die Anlage Entwarnung, auch wenn sich vor der Hauptzufahrt längst ein Stau aufbaut. Genau so war es hier: Die Replikate waren gesund, der Rückstand blieb unter der Schwelle. Die Sättigung saß am Primärknoten, und dort schaute niemand hin. Eine Metrik kann technisch korrekt sein und trotzdem die falsche Frage beantworten. Das ist keine Nachlässigkeit, sondern eine strukturelle Eigenschaft verteilter Systeme.

Der Blogbeitrag lässt an dieser Stelle Fragen offen. Wie genau führten die erschöpften Verbindungen zu Timeouts auf den Webservern? Der Autor vermutet Connection-Pooling: Ein Teil der Pool-Verbindungen war belegt, Clients warteten auf eine freie Verbindung, die nicht mehr kam. Und wie konnte ein einzelner Bereinigungsjob den Primärknoten über die Verbindungsgrenze treiben? Wie nah war die Datenbank schon vorher am Limit? Diese Lücken sind selbst ein Hinweis darauf, wie schwer sich solche Vorfälle im Rückblick rekonstruieren lassen.

Maximale Verbindungen, Timeouts und der Retry-Loop

Timeouts gehören zum Werkzeugkasten verteilter Systeme, aber sie sind asymmetrisch. Zu kurze Timeouts fallen im Normalbetrieb sofort auf: Man sieht die Abbrüche und verlängert sie. Zu lange Timeouts erzeugen kaum ein Signal. Vielleicht bemerkt man eine träge Oberfläche und sucht an der falschen Stelle. Oft gibt es bis zum ersten Vorfall keinen Hinweis darauf, dass irgendwo großzügig gerundet wurde. Lange Timeouts erhöhen die Zahl gleichzeitig laufender Anfragen und damit den Ressourcenverbrauch. Sie sind ein Sättigungsrisiko, das still im System liegt.

Mit Retries ist es ähnlich zwiespältig. Sie sind unverzichtbar, weil vorübergehende Fehler alltäglich sind, und sie verbergen diese Fehler vor den Nutzern. In einer Sättigungslage kippt die Wirkung ins Gegenteil: Wenn ein Dienst immer wieder dieselben fehlschlagenden Schreibvorgänge sendet, hält er die Datenbank unter Dauerlast und verhindert genau die Erholung, die er herbeiführen will. Für dieses Muster gibt es den Begriff Retry Storm. Timeouts wie Retries sind in der Theorie bewährte Schutzmaßnahmen und in der Praxis zwei Einstellungen, die kaum jemand überprüft, solange nichts brennt.

Aufräumen ist ein wiederkehrendes Risiko

Wer genug Incident Reports gelesen hat, erkennt ein Muster: Bereinigungsarbeiten tauchen überproportional häufig als Auslöser auf. Mal misslingt ein Aufräumjob, weil das zu entfernende Objekt noch in Gebrauch ist. Mal verhält sich eine längst ungenutzte Komponente gegenüber einem anderen Teil des Systems unerwartet. Und manchmal trägt umgekehrt das Ausbleiben von Aufräumarbeiten zum Vorfall bei, weil Altlasten weiterwirken. Beide Richtungen sind real und beide kosten.

Idealerweise stammt alle Abfragelast auf Produktionsdatenbanken aus Produktionsverkehr. Deshalb laufen Analyseabfragen üblicherweise auf getrennten Systemen. Es gibt aber Fälle, in denen das nicht geht: Wenn ein Job die Onlinedaten selbst verändern soll, muss er gegen die Onlinedatenbank laufen. Genau das war hier der Fall. Ein Datenbereinigungsjob, der ungenutzte Datensätze entfernt, ist eine gewollte Änderung am Bestand — und damit unvermeidlich eine Lastquelle im selben System, das gerade Nutzerverkehr bedient. Nicht aufzuräumen ist ein Risiko, aufzuräumen ebenfalls. Es bleibt eine Abwägung.

Was Ersthelfer brauchen, wenn die Lastquelle unklar ist

Bei einem Vorfall zählt zuerst die Wiederherstellung, nicht die Ursachenforschung. Lässt sich das Problem schnell einer fehlerhaften Auslieferung zuordnen, wird sie zurückgerollt und die Sache ist erledigt. In einer Sättigungslage ist das selten so einfach. Man erkennt meist schnell, welcher Dienst überlastet ist — oft eine Datenbank —, aber nicht, wer die Last erzeugt. Diese Unterscheidung war auch bei GitHub der zeitintensive Teil.

Für solche Situationen brauchen Responder zwei Fähigkeiten, und zwar sofort: Lastquellen schnell identifizieren, also sehen, welche Abfragen von wem kommen, und Last manuell abwerfen, indem einzelne Abfragen oder Quellen blockiert werden. Beides lässt sich nicht improvisieren. Wer diese Werkzeuge während des Vorfalls zum ersten Mal sucht, hat sie nicht. Sie müssen vorher gebaut, getestet und dokumentiert sein. Dieser Teil der Incident-Vorsorge entscheidet über die Dauer eines Ausfalls.

Dass die Ersthelfer interne Last abwarfen und den Job pausierten, war folgerichtig. Das behebt nicht die Ursache, stellt aber die Dienstfähigkeit wieder her und schafft Raum für die eigentliche Analyse. Der Abstand zwischen Auslöser und Wiederherstellung zeigt, wie viel Zeit allein das Verstehen kostet.

Was GitHub ändert — und was das konkret bedeutet

GitHub kündigt im Bericht mehrere Maßnahmen an. Hintergrundjobs gegen kundennahe Datenbanken werden künftig standardmäßig gedrosselt. Automatisches Pausieren und Alarmieren soll sich nicht mehr nur an Replica Lag orientieren, sondern an der Last des Primärservers. Laufende Hintergrundarbeit wird neben den Datenbank-Gesundheitssignalen sichtbar, sodass Responder sie aus demselben Dashboard pausieren können. Zusätzlich werden Retries im Pfad der Token-Ausgabe begrenzt, Timeouts auf Anfrageebene eingeführt und der Cluster aufgeteilt, um den Single Point of Failure zu beseitigen.

Fast alle diese Punkte erhöhen die Komplexität. Mehr Signale, mehr Automatik, mehr Drosselung, mehr Aufteilung. Das ist keine Überkonstruktion, sondern die ehrliche Antwort auf einen Fehler, der aus einer zu schmalen Beobachtung entstanden ist. Jede zusätzliche Sicherung ist zugleich ein neuer beweglicher Teil, der selbst ausfallen kann. Das Thema bleibt deshalb ein fortlaufender Prozess.

Für jedes Team mit einer zentralen Datenbank heißt das: Prüfe, welche Gesundheitsmetrik dein Backoff tatsächlich steuert, und ob sie den Engpass erfassen kann. Prüfe die Timeouts, die niemand angefasst hat, seit der Dienst gebaut wurde. Prüfe, ob ein Retry-Pfad bei anhaltender Sättigung aufhört oder weiterhämmert. Und prüfe, ob du während eines Vorfalls Last abwerfen kannst, ohne vorher Code zu schreiben. Die Grenze, an der ein System kippt, kennt man erst, wenn man sie überschritten hat. Vorher bleibt die Entscheidung, wie viel Abstand man hält — und wie viele der möglichen Grenzen man dabei im Blick hat.

Quelle: surfingcomplexity.blog

Ein Diagramm auf einem Bildschirm zeigt eine Kurve, die erst flach verläuft und dann in deutlichen Stufen nach oben steigt. Aufgetragen ist der Durchsatz eines Inferenzdienstes, gemessen über die Wochen seit dem ersten erfolgreichen Probelauf auf neuer Hardware. Die Ingenieure davor haben einen großen Teil der Änderungen, die zu dieser Kurve geführt haben, nicht selbst geschrieben. Ein Teil der Arbeit kam von einem Agenten, der auf genau jenem Modell läuft, das dieser Dienst später ausliefern soll. Darum geht es in einem Bericht, den das GLM-Team über den Start von GLM-5.3-Flash veröffentlicht hat.

Darin beschreiben die Entwickler etwas, das mehr ist als Werkzeuggebrauch. Ein Modell hilft, die Infrastruktur zu bauen, auf der das nächste Modell trainiert und betrieben wird. Der Text ist offen: Er spricht von Momenten, die das eigene Team überrascht und verunsichert haben, und von einer Entwicklung, die es selbst als schrittweise Ersetzung beschreibt. Wer wissen will, was hinter dem Schlagwort rekursive Selbstverbesserung steckt, findet hier einen konkreten Zwischenstand.

Von der Codeanalyse zur KI-gestützten Cybersicherheit

Im Oktober 2025 begann das Team, die Sicherheitsfähigkeiten von GLM gezielt zu stärken. Die Überlegung dahinter war nüchtern: Wer komplexen Code versteht, sollte auch dessen Schwachstellen verstehen. Cybersicherheit erschien den Entwicklern als Verlängerung des Programmierens, nicht als eigenes Forschungsfeld. Was dann passierte, hatte niemand geplant.

Nach Angaben des Teams fanden Sicherheitspartner in weniger als einem Jahr Tausende Schwachstellen in real genutzten Codebasen. Das verändert die Praxis der KI-gestützten Cybersicherheit. Zugleich entstehen Gefahren, die es vorher in dieser Form nicht gab, weil dieselbe Fähigkeit auch Angreifern offensteht. Um den Zugang zu kontrollieren, mussten die Entwickler ein Programm für vertrauenswürdige Nutzer entwerfen.

Die Zahl der Funde ist das eine. Interessanter ist, wie sich die Rolle verschiebt: Aus einem Modell, das Text erzeugte, wird ein Prüfwerkzeug für fremde Systeme. Sobald eine Fähigkeit dieser Art existiert, lässt sie sich nicht mehr zurücknehmen. Sie lässt sich nur einhegen. Darum geht es im zweiten Teil des Berichts.

Ein Agent erledigt, wofür früher ein ganzes Team Wochen brauchte

Die größere Überraschung kam aus einer anderen Richtung. GLM hilft zunehmend dabei, KI selbst zu bauen. Die Entwickler beschreiben eine Infrastrukturaufgabe, die ein Team erfahrener Ingenieure früher mehrere Wochen gekostet hätte; das Modell erledigte sie deutlich schneller. Als klar wurde, dass diese Arbeit beeinflusst, wie die nächste Modellgeneration trainiert wird, wurde eine Einsicht greifbar: Die eigenen Nachfolger sind die Systeme, die man selbst baut.

Der Bericht ist auch in diesem Punkt offen. Vor GLM-4.7, räumen die Autoren ein, war der interne Einsatz des Modells beim Programmieren eine Pflichtübung. Es war das eigene Produkt, und der Markt für Coding-Assistenten war noch nicht so weit. Heute nennt das Team GLM-5.3 einen täglichen Partner und stellt fest, dass es sich beständig auf die Ablösung der eigenen Rolle zubewegt.

Dieser Endpunkt hat einen Namen. Wenn ein System mit genügend Rechenleistung und Zeit seine eigene Nachfolgeversion entwerfen und trainieren kann, nennt man das Recursive Self-Improvement, kurz RSI. So weit sei es noch nicht, schreiben die Entwickler, aber frühe Formen zeichneten sich ab. Der restliche Artikel dokumentiert eine solche frühe Form.

Produktionsbetrieb auf über 100.000 chinesischen KI-Beschleunigern

Ein Modell vom ersten erfolgreichen Lauf auf neuer Hardware bis zu einem Dienst zu bringen, der echten Produktionsverkehr zuverlässig trägt, ist schwere Systemarbeit. Für GLM-5.3-Flash bedeutete das, eine vollständige Inferenz-Infrastruktur auf einem Cluster aus mehr als 100.000 chinesischen KI-Beschleunigern aufzubauen. Der gesamte Produktionsbetrieb des Modells läuft auf diesem System.

Einfach war das nicht. Niemand hatte zuvor einen Cluster dieser Größenordnung mit chinesischen Beschleunigern in Betrieb genommen. Die Speicherkapazität und die Bandbreite der Chips waren begrenzt, während gleichzeitig eine neue Modellarchitektur, ein Kontextfenster von einer Million Token und multimodale Anfragen unterstützt werden mussten. Das Ökosystem war unreif, die Kernel-Unterstützung lückenhaft, und vieles, was dokumentiert sein sollte, musste erraten werden.

Ein großer Teil dieser Arbeit wurde nicht von einem Team aus Infrastruktur-Ingenieuren erledigt, sondern von einem Infra Agent, der auf GLM-5.3 läuft. Anschließend wurde GLM-5.3-Flash unter dem anonymen Namen Ox-Alpha auf OpenCode und OpenRouter getestet. Innerhalb einer Woche war es auf beiden Plattformen das meistgenutzte Modell und verarbeitete in sechs Tagen mehr als 62 Billionen Token.

Warum End-to-End-Metriken den Agenten im Dunkeln lassen

Hier lohnt ein Bild aus der Medizin. Eine Waage zeigt, dass jemand an Gewicht verloren hat, aber sie sagt nicht, warum. Genauso verhält es sich mit den klassischen Kennzahlen eines Inferenzsystems. Wenn nach einer Änderung die Zeit bis zum ersten Token um 30 Prozent steigt oder der Durchsatz um 20 Prozent fällt, weiß der Agent zwar, dass etwas schlechter geworden ist. Er weiß aber nicht, welche Schicht dafür verantwortlich ist.

Inference-Optimierung bringt reichlich Tests, Logs, Profiler und Microbenchmarks mit sich. Nur sind diese Werkzeuge meist über verschiedene Arbeitsphasen verstreut. Erfahrene Ingenieure nutzen das Ergebnis eines Lasttests, um zu entscheiden, was sie als Nächstes ansehen, und verknüpfen dabei Kernel-Ausgaben, Ausführungs-Zeitachsen, Kommunikationsereignisse und Thread-Zustände. Für einen Agenten bleibt dieser Zusammenhang unsichtbar, solange er nicht in direkt aufrufbare, wiederholbare Abläufe gegossen wird.

Ein Codebestand liefert nur statischen Kontext. Numerische Abweichungen und Leistungseinbrüche eines Inferenzsystems entstehen dagegen aus dem Zusammenspiel mehrerer Ebenen: Kernel-Implementierungen, Parallelisierungsstrategien, Kommunikationsverhalten, Speicherverwaltung und Serving-Orchestrierung. Selbst wenn ein Agent den gesamten Code versteht, sagt ihm die Rückmeldung „Genauigkeitstest fehlgeschlagen“ nicht, warum seine Hypothese falsch war und was er als Nächstes prüfen sollte. Das ist der Kern des Berichts.

Dichtes Feedback: lokal, günstig, überprüfbar

Die Antwort der Entwickler heißt dense feedback, also dichtes Feedback. Damit ist nicht gemeint, dem Agenten möglichst viele Logs und Kennzahlen um die Ohren zu schlagen. Gemeint sind drei Eigenschaften. Erstens muss die Rückmeldung lokal genug sein: Sie sollte an konkrete Startparameter, Codeänderungen, Kernel, Eingabeformen, Threads oder Codepfade gebunden sein, damit der Agent den Suchraum eingrenzen kann.

Zweitens muss sie günstig und schnell zu bekommen sein. Wer eine Hypothese aufstellt oder eine Änderung vornimmt, sollte sie mit einem Kernel-Test oder einem lokalen Microbenchmark prüfen können, ohne jedes Mal einen vollständigen Dienst auszurollen und einen Lasttest zu fahren. Kürzere Prüfschleifen erlauben es, frühzeitig zu korrigieren und weniger Zeit in aussichtslose Annahmen zu stecken.

Drittens muss sie objektiv nachprüfbar sein. Ob eine Änderung korrekt ist und ob sie schneller läuft, entscheiden Referenzimplementierungen, Testergebnisse und vergleichbare Messwerte. Laufzeitsignale können Hinweise geben, aber eine Korrelation ist noch keine Ursache. Kontrollierte Experimente bleiben nötig, um zu belegen, dass eine Änderung an einem bestimmten Pfad den erwarteten Effekt hat. Dazu gehört auch, den Unterschied zwischen lokaler Prüfung und End-to-End-Test klar zu halten: Die lokale Prüfung sortiert früh aus und findet Kandidaten, der Gesamttest bestätigt, ob daraus echter Gewinn wird.

Tensor Parallelismus, EPD und der dreifache Durchsatz

Auf dieser Grundlage entstand eine Optimierungsschleife aus Ingenieuren, Infra Agent und Versuchsumgebung. Die Ingenieure setzten Ziele und Systemgrenzen, der Agent übernahm Analyse, Hypothesen und Codeänderungen, die Umgebung lieferte geschichtetes und prüfbares Feedback. So wurde ein Diagnoseprozess, den früher die Erfahrung einzelner Personen zusammenhielt, zu einem Ablauf, den der Agent durchgehend ausführen konnte.

Technisch kamen mehrere Maßnahmen zusammen. Der Stack nutzte Tensor Parallelismus innerhalb eines Knotens für lineare Attention und den LM Head, dazu ReplaySSM, W8A8-Quantisierung, gemischte Cache-Quantisierung mit INT8, FP8 und BF16 sowie einen Layer Split. Darauf setzte eine disaggregierte Encode-Prefill-Decode-Architektur, kurz EPD, die die drei Phasen der Verarbeitung voneinander trennt und getrennt skaliert.

Die Entwickler beschreiben aggressive Speicheroptimierungen, bei denen Rechenleistung gegen Bandbreite und Kommunikation gegen Gerätespeicher getauscht wurde. Unterm Strich verbesserte sich die Ende-zu-Ende-Leistung des Dienstes um etwa das Dreifache. Hardware-Auslastung und Kosten pro Token erreichten nach Angaben des Teams ein Niveau, das mit gängigen NVIDIA-GPUs vergleichbar ist. Vom ersten Anpassen des Modells bis zur Produktionsreife vergingen weniger als zwei Wochen.

Was das konkret bedeutet

Man kann diesen Bericht als Marketing lesen, und ein Teil davon ist er sicher auch. Interessanter ist die technische Aussage in der Mitte. Der Engpass beim Einsatz von KI-Agenten in komplexen Systemen liegt nicht allein in der Fähigkeit, Code zu schreiben. Er liegt darin, ob die Umgebung Rückmeldungen liefert, die sich auf konkrete Ursachen zurückführen lassen. Ein Agent ohne dichtes Feedback stochert im Nebel, egal wie gut er formuliert.

Für die weitere Entwicklung heißt das: Wer KI-Agenten in Infrastruktur einsetzen will, muss in Beobachtbarkeit investieren, nicht nur in Modellgröße. Dieser Punkt lässt sich auf andere Felder übertragen, von der KI-gestützten Cybersicherheit bis zur klassischen Softwarewartung. Die Frage ist überall dieselbe: Bekommt das System genug verwertbare Signale, um seine nächste Handlung zu begründen?

Vollständige rekursive Selbstverbesserung ist weiter entfernt, als die Schlagzeilen nahelegen. Was hier beschrieben wird, ist ein Zwischenschritt: ein Agent, der unter Aufsicht von Menschen einen Produktionsdienst mitgebaut hat, auf Hardware, für die es kaum Erfahrungswerte gab. Das ist weniger als eine sich selbst verbessernde Maschine und mehr als ein Autovervollständiger.

Quelle: z.ai

Auf einem Desktop-Rechner mit i7-Prozessor und 64 GB Arbeitsspeicher läuft ein Zähler hoch, der die Zahl der gleichzeitig arbeitenden Software-Agenten anzeigt. Bei 218 bleibt er stehen. Niemand greift in diesem Moment ein, niemand nickt Änderungsvorschläge ab, niemand ruft einen der Arbeiter zur Seite.

Was in der Nacht zum 2. September ablief, hat Teknium, der Entwickler hinter Hermes Agent, später selbst als eine der ungewöhnlichsten Aufräumaktionen beschrieben, die er je angestoßen hat. Hermes Agent ist der quelloffene Agent des Forschungsteams Nous Research. Sein Repository war über Jahre gewachsen wie ein Altbau, in dem immer wieder neue Wände eingezogen wurden, bis niemand mehr sicher sagen konnte, welcher Raum wozu gehört: mehr als eine Million Zeilen Python ohne Tests, eine einzelne Datei mit 34.847 Zeilen. Solche Gebäude funktionieren, aber jede Reparatur dauert länger als nötig, weil man zuerst den Grundriss suchen muss. Interessant ist am Ende weniger die Zahl 218 als die Rechnung, die dabei herauskommt.

Warum das Aufräumen jahrelang liegen blieb

Ein Refactoring dieser Größenordnung steht in Konkurrenz zu dem, was Nutzer sofort spüren. Teknium rechnet vor, dass ein kleines Team für dieselbe Arbeit zwei Monate bis zwei Jahre gebraucht hätte, mit geschätzten Personalkosten zwischen 150.000 und 1,8 Millionen Dollar. Solche Zahlen lassen sich schwer rechtfertigen, solange im selben Zeitraum Features und Bugfixes ausgeliefert werden sollen. Also blieb der Altbau stehen, und alle Beteiligten lernten, sich darin einzurichten.

Entscheidend war etwas anderes, und das gilt für jeden, der KI-Agenten für Code-Refactoring einsetzt. Teknium nutzt Hermes Agent täglich, um Hermes Agent weiterzuentwickeln. Dabei entsteht ein Kreislauf: Wenn ein Vorgehen funktioniert oder er den Agenten korrigiert, notiert dieser die Lektion und schreibt sie in seine Skills – lesbare Markdown-Dokumente mit Referenzdateien und Skripten, die er bei späteren Aufgaben wieder lädt. Der Agent merkt sich mit der Zeit, wie dieser eine Auftraggeber seine Arbeit haben will. Als der große Auftrag formuliert wurde, waren seine Standards längst hinterlegt, bis hin zu der Regel, einen fehlschlagenden Test erst auf unverändertem Code zu wiederholen, um zu prüfen, ob der Fehler schon vorher existierte.

Ein einziger Auftrag statt hundert Einzelbriefings

Die Anweisung fiel erstaunlich knapp aus und wurde über den Befehl /goal abgesetzt, der dem Agenten ein dauerhaftes Ziel gibt und ihn zum Weiterarbeiten auffordert, wenn er sonst anhalten würde. Teknium verlangte eine radikale Vereinfachung: mindestens 30 Prozent weniger Code, aufgeteilte Riesendateien, vereinheitlichte Hilfsfunktionen, weniger verschachtelte if/elif-Ketten, mehr Lesbarkeit. Ausdrücklich verbot er, auf Entscheidungen des Menschen zu warten – der Agent sollte liefern, nicht fragen.

Eine Aufgabenliste sagt genau, wo geschraubt werden soll, und scheitert, sobald die Lage vor Ort anders aussieht als geplant. Eine Zielvorgabe beschreibt einen Zustand, und der Ausführende entscheidet selbst, wie er dorthin kommt. Der gesamte Auftrag lag in einem Prompt, ergänzt um gespeichertes Wissen aus Monaten gemeinsamer Arbeit. Der Agent musste also nicht herausfinden, was guter Code für dieses Projekt bedeutet – er wusste es bereits.

Wie 1.393 Subagenten sich selbst organisiert haben

Der Hauptlauf dauerte etwa neunzehn aktive Stunden und schickte 1.393 Subagenten los, von denen bis zu 218 gleichzeitig arbeiteten. Der übergeordnete Agent bearbeitete keine Quelldatei selbst, sondern vermaß die Codebasis, teilte sie in 36 überschneidungsfreie Gruppen und schrieb für jede eine Arbeitsanweisung, die genau benannte, was zu vereinfachen war und welche Schnittstellen erhalten bleiben mussten. Einige Arbeiter delegierten Teile ihres Auftrags weiter, sodass der Baum drei Ebenen unter den ursprünglichen Agenten reichte.

Technisch lief das Ganze in einem einzigen Python-Prozess auf einem Arbeitsplatzrechner; nur die Werkzeuge starteten als lokale Subprozesse, während die Inferenz über ein externes Modell kam. Jeder Arbeiter bekam über git worktrees eine eigene Auskopplung des Repositories, damit sich die Änderungen nicht gegenseitig überschrieben. Vergleiche mit dem Original hielten die Qualität: Ein JSON-Schema eines Werkzeugs musste identisch bleiben, die Hilfe-Ausgabe eines Kommandozeilenbefehls ließ sich Byte für Byte prüfen. Nach jedem verifizierten Schritt wurde committet. Das sollte später wichtig werden.

Wo der Lauf beinahe gescheitert wäre

Nach etwa fünfzig Minuten lief das Authentifizierungstoken des Anbieters ab, und die daraus entstehenden Fehler beendeten den Lauf. Die bereits geschriebenen Commits und Arbeitsanweisungen überlebten, sodass keine Arbeit verloren ging. Teknium startete eine separate Hermes-Sitzung, ließ den Fehler diagnostizieren, packte das Ergebnis in eine Übergabe und reichte sie an die fortgesetzte Sitzung weiter. Die Arbeiter gingen daraufhin zurück in ihre gespeicherten Änderungen, reparierten unfertige Auslagerungen und machten weiter.

Beim Zusammenführen zeigte sich, warum automatisierte Code-Optimierung mit KI-Agenten ohne Kontrolle nicht funktioniert. Zwei Runden Community-Review fingen Regressionen, die die vorhandenen Tests übersehen hatten: Arbeiter hatten öffentliche Namen entfernt, weil innerhalb des Repositories niemand sie mehr aufrief – externe Plugins importierten sie jedoch. Eine automatische Umschreibung von suppress()-Aufrufen veränderte zudem die Fehlerbehandlung an rund 65 Stellen. Solche Funde zeigen vor allem, dass Tests nicht alles abdecken. Nach dem Merge folgten weitere Korrekturen.

Was die Zahlen zeigen – und wo neue Kosten entstehen

Der Vergleich vorher und nachher ist deutlich. Der Python-Code ohne Tests schrumpfte von 1.063.826 auf 698.363 Zeilen, also um 34,4 Prozent. Die Zahl der Dateien über 5.000 Zeilen sank von 37 auf 6, die Zahl der Funktionen über 300 Zeilen von 192 auf 2. Die längste if/elif-Kette kam von 92 auf 9 Zweige, und gateway/run.py, das größte Einzelstück, fiel von 34.847 auf 5.512 Zeilen.

Ob ein leichter lesbarer Bauplan auch für Agenten günstiger ist, prüfte das Team, indem es dieselben 4.000 Symbole in beiden Versionen nachschlagen ließ. Der durchschnittliche Token-Aufwand pro Nachschlagen fiel von 2.218 auf 993, und die Fälle, die ein zweites Lesefenster brauchten, gingen von 628 auf 184 zurück. Ein kurioser Nebenbefund: Der Median stieg, weil in einem festen Zeilenfenster nun dichterer Code steht – weniger Kommentare, weniger Dokumentationszeilen. Der Durchschnitt sank nur, weil die sehr großen Definitionen verschwanden. Nebenbei entstanden neue Kosten: mehr Module, mehr Importabhängigkeiten, längere Startzeiten einzelner Einstiegspunkte. Sechs Dateien liegen weiterhin über 5.000 Zeilen, und die Kopplung zwischen den Teilen hat der Umbau nicht aufgelöst. Aufräumen verschiebt Aufwand, es beendet ihn nicht.

Was das für Teams bedeutet

Die Kosten des Hauptlaufs lagen bei rund 19.300 Dollar an Modellaufrufen, inklusive der Folgesitzungen bei etwa 25.000 Dollar – ohne die Zeit für menschliches Review. Der geschätzte Aufwand für Handarbeit lag zwischen 150.000 und 1,8 Millionen Dollar. Das entspricht grob einem Prozent der Kosten und der Zeit, die sonst nötig gewesen wären. Gleichzeitig brachte der Lauf Verbesserungen an Hermes selbst hervor: Rund dreißig parallel gestartete Kopien des Sprachservers Pyright hatten 8,7 GB belegt, bis ein geteilter Server mit laufender Prüfung eingerichtet wurde. Doppelte HTTP-Transporte wurden entfernt, Referenzen auf beendete Agenten gelöscht.

Das Repository erhielt Regeln zu Dateigröße und Funktionskomplexität, aufgeteilt nach Bereichen, damit neue Arbeiter nur die relevanten Vorgaben laden. Ein zusätzlicher Test markiert entfernte öffentliche Namen, damit künftig keine Plugin-Schnittstelle mehr unbemerkt verschwindet. Die Skills des Entwicklers wurden während des Laufs automatisch um die gesammelten Lehren ergänzt, und er gibt sie an sein Team weiter; deren Agenten erben die Prozeduren, ohne die Sitzungen wiederholen zu müssen.

Was hier beschrieben wird, ist kein Werkzeug, das man einmal einschaltet. Es ist ein Gedächtnis, das man über Monate füttert. Der Agent war nur deshalb in der Lage, 1.393 Subagenten sinnvoll zu steuern, weil er den Auftraggeber, dessen Standards und die Fallstricke dieses einen Projekts bereits kannte. Wer Softwareentwicklung mit KI-Agenten beschleunigen will, sollte deshalb zuerst in diese Gewohnheit investieren: Fehler benennen, Vorgehen bestätigen, Lektionen festhalten. Dann beginnt der nächste Umbau mit dem Wissen des vorigen.

Quelle: nousresearch.com

Ein persönliches Notizsystem stößt mit wachsendem Umfang irgendwann an seine Grenzen, heißt es. Dann brauche es eine Datenbank oder ein klassisches Wiki. Der Beitrag, um den es hier geht, dreht die Reihenfolge um: Er nimmt einen Obsidian-Vault aus einfachen Markdown-Dateien als Ausgangspunkt und beschreibt, welche Mechanismen daraus ein Unternehmens-Gehirn machen. Interessant ist weniger die Technik als die Reihenfolge der Probleme. Nicht die Zahl der Notizen ist der Engpass, sondern die Frage, wer wann was schreiben darf und wie eine Änderung geprüft wird.

Der Autor des Originalbeitrags, der den Text nach eigener Angabe im Rahmen seiner Beratungstätigkeit geschrieben hat, nutzt seit vielen Jahren ein persönliches Zweitgehirn. Er begann mit OneNote und wechselte wegen der Verlinkungsfunktion zu Obsidian; heute verwaltet er darin private Notizen, aber auch sein Einzelunternehmen samt CRM. Sein Rat: Setz auf ein offenes Dateiformat wie Markdown, damit dein Wissen nicht an ein einzelnes Werkzeug gebunden bleibt. Als Einzelperson bekommst du so ein System, das Jahrzehnte überdauern kann.

Was ein persönlicher Obsidian-Vault leistet und wo seine Grenzen liegen

Ein solches System erfüllt mehrere Aufgaben gleichzeitig. Es sammelt Wissen zum langfristigen Behalten, dient als Ort für Ideen und Texte, verbindet Notizen untereinander, um Zusammenhänge sichtbar zu machen, und liefert Vorlagen für wiederkehrende Notizstrukturen. Dazu kommen Anbindungen an Erfassungswerkzeuge wie den Obsidian Web Clipper, mit dem Inhalte aus dem Netz direkt im Vault landen. All das lässt sich mit verlinkten Notizen abbilden, egal ob mit Obsidian, Logseq oder einem anderen Werkzeug. Der Graph ist nur der sichtbare Teil dieser Arbeit.

Die Grenzen zeigen sich erst, wenn man genau hinsieht. Mehrbenutzerfähigkeit gibt es praktisch nicht, weil lose Markdown-Dateien nicht für gleichzeitiges Schreiben gebaut sind – dafür bräuchte man Mechanismen wie CRDTs oder einen anderen Weg zur Synchronisation. Der Graph kennt außerdem keine Typen, es gibt also keine Garantie, dass ein Datum ein Datum bleibt und eine Telefonnummer nicht irgendwann als freier Text endet. Die Inhalte sind Freitext, und die Beziehungen zwischen Notizen tragen nur wenig Semantik. Der Autor verweist hier auf Sergei Simonovi, der von Reibungspunkten spricht, sobald sehr viele Notizen zusammenkommen.

Bei tausenden Notizen geht das noch. Bei Millionen braucht es einen Index für schnelle Abfragen, dazu Embeddings und Clustering, um Ähnliches zu finden. Und einen Umgang mit Daten aller Art: Text, CSV, JSON, Schnittstellen. An diesem Punkt endet das persönliche System und beginnt Unternehmenswissensmanagement.

Warum Unternehmenswissensmanagement dieselben Fragen in größerem Maßstab stellt

Die Anforderungen wiederholen sich. Ein Unternehmen will die Umsatzzahlen des letzten Monats abrufen, aus einem sich ständig ändernden Umfeld lernen – neue Gesetze, neue Datenquellen – und dieses Wissen intern wie extern teilen. Das sind dieselben Aufgaben wie bei einem persönlichen Gehirn, nur in anderer Größenordnung. Der Unterschied liegt in der Zahl der Beteiligten und in der Komplexität der Daten. Aus Copy-and-Paste werden Datenpipelines und ein Data Warehouse.

Hinzu kommen zwei Forderungen, die im Einzelbetrieb kaum eine Rolle spielen: Automatisierung und Governance. Ein gutes Beispiel ist das CRM. Dort sammeln sich Kundeninformationen, Angaben aus Verkaufsgesprächen, der letzte Kontakt, die aktuelle Einschätzung, ob ein Interessent heiß, warm oder kalt ist. Solche Zustände ließen sich automatisch pflegen, wenn Notizen von Vertriebsmitarbeitern, freigegebene Telefonprotokolle oder Dokumente kontinuierlich ausgewertet werden. Dafür braucht es Agenten.

Der Autor erwähnt in diesem Zusammenhang einen kurzen Beitrag von Andrej Karpathy über ein selbstkuratierendes LLM-Wiki, das viral ging. Es zeigt, was für eine kleine, automatisch aktualisierte Wissenssammlung möglich ist. Für Unternehmen reicht es nicht, weil weder ein Prüfprozess noch eine Versionierung vorgesehen ist. Ohne diese beiden Elemente bleibt ein automatisch wachsendes Wiki ein Experiment.

KI-Agenten schreiben auf eigenen Branches

Agenten sind gut darin, Informationen in beliebigen Formaten zu erfassen. Sie können definierte Orte lesen, Kundenstämme täglich aktualisieren, Anrufe und Dokumente einlesen und Verträge den passenden Kunden zuordnen. Das ist der Zulieferteil der Arbeit, und er läuft autonom. Spannender ist die Frage, wie Agenten neue Inhalte in das Gehirn schreiben, ohne es zu beschädigen.

Die Antwort des Autors: mit Branches. Wenn hunderte Agenten gleichzeitig Wissen hinzufügen, laufen sie sich sonst gegenseitig über den Weg. Jeder Agent bekommt deshalb seine eigene Kopie, schreibt dort und schlägt seine Änderung anschließend zur Übernahme in den Hauptzweig vor – im Prinzip wie ein Pull Request bei GitHub. Nichts landet in der echten Version, bevor es freigegeben wurde. Menschen können Merges ablehnen oder später zurücknehmen, und es bleibt eine vollständige Historie darüber, wer was geändert hat.

Der zweite Grund für Branches ist genauso wichtig wie der erste. Ohne Prüfung driftet ein von Agenten gefüttertes Unternehmens-Gehirn innerhalb weniger Wochen in Rauschen ab. Eine falsch geänderte Telefonnummer oder ein halluzinierter Deal-Status genügen, damit niemand dem System noch traut. Mit Branches lässt sich gleichzeitig parallel arbeiten, auch an lang laufenden Aufgaben, und trotzdem bleibt der Hauptzweig konsistent. Versionierung und Nebenläufigkeit kommen so in einem Mechanismus zusammen.

Objekt-Storage, typisierte Graphen und die Frage nach Ontologien

Unter alldem braucht es einen Speicherort, an dem Daten geschrieben, versioniert und gelesen werden können. Der Autor empfiehlt Objekt-Storage, weil er günstig und schnell eingerichtet ist und weil er offene Formate wie Apache Parquet erlaubt, bei Bedarf ergänzt um offene Tabellenformate mit Datenbankfunktionen darüber. Jeder mit den passenden Rechten kann lesen, und es gibt keinen Datenbankserver, der laufen muss. Das gesamte Gehirn ist im Kern eine Sammlung von Dateien.

Damit Agenten konsistent schreiben, kommt ein typisierter Graph ins Spiel. Verlinkt wird wie in Obsidian, aber jeder Knoten und jede Kante hat einen definierten Typ. Diese Typen wirken wie Datenverträge: Sie sagen dem Agenten, wie er speichern und wie er wieder abrufen soll. In der Vorstellung des Autors sind Dots die Dinge – eine Person, ein Unternehmen, ein Deal – und Lines die Verbindungen dazwischen, etwa dass jemand eine Firma gegründet hat. Typisiert bedeutet, dass es Regeln gibt, vergleichbar mit einem Formular mit Pflichtfeldern statt eines leeren Notizbuchs, in das jeder schreibt, was ihm gerade einfällt.

Der Unterschied zwischen einem deklarierten Graph-Link und einem Embedding ist zentral: Der Link ist eine Aussage, die jemand bewusst gesetzt hat, das Embedding eine Ähnlichkeit, die das Modell vermutet. Ein Unternehmens-Gehirn, das beides hält, kann nach Bedeutung und nach typisierten Beziehungen suchen, nicht nur nach Vektorähnlichkeit. Der Autor sieht darin eine Fortsetzung dessen, was früher Master Data Management leisten sollte, damals mit Excel und menschlicher Pflege – und mit Domänenexperten als Flaschenhals, die ohnehin ausgelastet waren. Agenten können diesen Prozess beschleunigen, wenn die Dokumentation gepflegt und aktuell ist. Wahrheit bleibt dabei relativ: Widersprüche zwischen einer Notiz und einem Protokolleintrag dürfen sichtbar werden, und Menschen können jederzeit eingreifen. Über Ontologien lässt sich zusätzlich Weltwissen modellieren und mit den Unternehmensdaten verbinden, was die Qualität der Antworten erhöht.

CRM mit mehreren Agenten: Kontext lesen, zurückschreiben, Konflikte lösen

Am Ende vergleicht der Beitrag zwei Welten anhand von zwei Beispielen. Auf der einen Seite das persönliche Gehirn mit Obsidian, in dem eine Person ihre Kunden, Notizen und Dokumente verwaltet. Auf der anderen Seite ein Company Brain mit einem System wie OmniGraph, in dem mehrere Agenten und mehrere Menschen gleichzeitig arbeiten. Der Autor zeigt, wie Agenten und Nutzer Kontext herauslesen, wie Ergebnisse zurück ins CRM geschrieben werden, wie automatische Merges ablaufen und wie Konflikte behandelt werden, wenn zwei Quellen unterschiedliche Aussagen treffen.

Die Beispiele teilen dieselbe Denkweise und unterscheiden sich nur im Maßstab. Was im Einzelbetrieb eine Notiz mit zwei Wikilinks ist, wird im Unternehmen zu einem typisierten Knoten mit Beziehungen, Versionen und Prüfschritten. Der Autor betont, dass ein solches System kein statisches Produkt ist. Es ist ein fortlaufender gemeinsamer Verständnisprozess, an dem Agenten und Belegschaft gleichermaßen beteiligt sind.

Was das für Unternehmen konkret bedeutet

Die praktische Konsequenz ist ernüchternd und befreiend zugleich. Es geht nicht darum, Obsidian einzukaufen oder ein Werkzeug auszutauschen, sondern drei Fähigkeiten nachzurüsten: gleichzeitiges Schreiben mit Versionierung, typisierte Datenverträge und eine offene, günstige Speicherschicht. Wer nur die erste Fähigkeit umsetzt, bekommt Chaos in Zeitlupe. Wer nur auf Typen setzt, verliert die Prüfinstanz. Erst im Zusammenspiel bleibt ein automatisch aktualisiertes Unternehmens-Gehirn über Monate vertrauenswürdig.

Für dich als Verantwortliche heißt das, den Aufwand nicht bei der Erfassung zu veranschlagen, sondern beim Prüfen und beim Speicherformat. Der Mensch verschwindet nicht aus dem Prozess, er wandert nur an eine andere Stelle: Er entscheidet, welche Änderungen in den Hauptzweig dürfen. Das ist weniger glamourös als ein autonomer Agent, der alles selbst regelt, aber es ist der Unterschied zwischen einem System, dem man nach einem Jahr noch glaubt, und einem, das man dann abschaltet.

Quelle: ssp.sh