Kategorie: Erklärer

Eine Suchmaschine findet ein Buch, wenn du Titel oder Stichwort kennst. Aber um zu verstehen, welche Ideen sich durch alle Bücher ziehen, welche Autoren sich beeinflusst haben und welche Themen an Bedeutung gewannen, reicht die Stichwortsuche nicht aus. Du brauchst jemanden, der die Verbindungen zwischen den Werken sieht und dir eine Landkarte des Wissens zeichnet.

In der KI-Welt heißt das Retrieval-Augmented Generation (RAG). Seit etwa zwei Jahren ist RAG der Standard, um Sprachmodellen wie GPT-4 oder Claude Zugriff auf eigene Dokumente zu geben. Dokumente werden in kleine Textstücke zerschnitten, in Zahlen umgewandelt („embedden“) und in einer Vektordatenbank gespeichert. Bei einer Frage sucht das System die ähnlichsten Textstücke heraus und reicht sie dem Modell als Kontext weiter. Für einfache Faktenfragen funktioniert das gut. Aber bei Fragen, die über mehrere Dokumente hinweg eine zusammenhängende Antwort erfordern, stößt das System an seine Grenzen.

Die Lösung heißt GraphRAG. Statt isolierter Textstücke wird vorab ein Wissensgraph aufgebaut: ein Netzwerk aus Entitäten (Personen, Orten, Begriffen) und ihren Beziehungen. Dieses Netzwerk dient dem Sprachmodell als Kontext. Das klingt verlockend, aber man sollte es genau prüfen. Der Artikel von Dattaraj Rao, R&D-Architekt bei Persistent Systems, analysiert die ursprüngliche Microsoft-Studie zu GraphRAG sowie vier unabhängige Benchmark-Untersuchungen. Das Ergebnis: GraphRAG schlägt klassisches Vektor-RAG deutlich – aber nur bei bestimmten Fragetypen, und nicht ohne Kosten.

Warum Textstücke an ihre Grenzen stoßen

Standard-RAG sucht die k relevantesten Passagen per Kosinus-Ähnlichkeit. Das führt zu drei strukturellen Schwächen. Erstens: Es kann keine Punkte verbinden, die in verschiedenen Dokumenten liegen. Wenn die Antwort erfordert, dass man Fakten aus Passage A und Passage B über eine gemeinsame Entität verknüpft – etwa „Welche Produkte von Firma X wurden in den Kundenbeschwerden des letzten Quartals erwähnt?“ – dann bleiben die Textstücke isoliert. Zweitens: Es ist blind für globale Fragen. „Was sind die Hauptthemen in zwei Jahren Kundenfeedback?“ – diese Frage verlangt eine Sicht auf den gesamten Korpus. Die Ähnlichkeitssuche liefert aber nur ein paar oberflächlich ähnliche Schnipsel. Drittens: Es zerreißt den Kontext an den Grenzen der Chunks. Gerade die Hierarchie und die Beziehungen, die für komplexes Denken nötig sind, gehen beim Zerschneiden verloren.

Microsoft Research hat genau diese Schwächen in ihrer GraphRAG-Veröffentlichung benannt: Herkömmliches RAG „kämpft darum, die Punkte zu verbinden“ und schneidet schlecht ab, wenn es darum geht, „semantische Konzepte über große Datenmengen hinweg ganzheitlich zu verstehen“. Die Kernidee von GraphRAG ist daher, vor der eigentlichen Frage den Kontext zu strukturieren – und nicht erst bei der Abfrage zu suchen.

Was ein Kontextgraph anders macht

GraphRAG geht das Problem an, bevor überhaupt eine Frage gestellt wird. Während der Indexierung liest ein Sprachmodell jedes Textstück und extrahiert daraus Entitäten, Beziehungen und Behauptungen. Diese werden zu einem gewichteten Wissensgraphen zusammengesetzt. Dann kommt ein Algorithmus namens Leiden ins Spiel, der die Gemeinschaftsstruktur im Graphen erkennt. Er findet Cluster von zusammenhängenden Themen und baut daraus eine Hierarchie. Für jede dieser Gemeinschaften wird vorab eine Zusammenfassung in natürlicher Sprache erstellt.

Zur Abfragezeit übernehmen diese Zusammenfassungen die Arbeit. Jede relevante Gemeinschaft formuliert eine Teilantwort – das ist der sogenannte „Map“-Schritt. Die Teilantworten werden bewertet und zusammengeführt – der „Reduce“-Schritt. Am Ende synthetisiert das Modell eine finale Antwort, die auf der Struktur des Wissensgraphen basiert und nicht auf ein paar zufällig ähnlichen Snippets. Es gibt auch Varianten wie HippoRAG, die einen anderen Weg gehen: Sie nutzen den Graphen plus einen Personalisiert-PageRank-Algorithmus, um die relevanten Passagen zu finden. Aber das Prinzip ist dasselbe: Beziehungen – nicht nur Kosinus-Ähnlichkeit – bestimmen, welchen Kontext das Modell sieht.

Dieses Vorgehen löst die drei Schwächen des Vektor-RAG. Es verbindet die Punkte, weil der Graph die Beziehungen explizit abbildet. Es versteht globale Zusammenhänge, weil die Gemeinschafts-Hierarchie eine Vogelperspektive bietet. Und es zerstört keinen Kontext, weil die Zusammenfassungen die semantische Struktur bewahren. Ob das in der Praxis tatsächlich bessere Antworten liefert, entscheiden die Benchmarks.

Die Belege: Vier Studien, ein Muster

Die erste und wichtigste Studie stammt von Microsoft selbst. Sie verglichen GraphRAG mit naivem RAG bei Fragen, die ein „Sinnverständnis über den gesamten Korpus“ verlangen – also globale, themenübergreifende Fragen. Über Datensätze mit einer Million Token ließen sie ein Sprachmodell als Jury fungieren und bewerteten drei Aspekte: Vollständigkeit, Vielfalt und Ermächtigung (also ob die Antwort dem Nutzer hilft, weiterzudenken). Das Ergebnis: GraphRAG gewann bei der Vollständigkeit in 72 bis 83 Prozent der Vergleiche, bei der Vielfalt in 62 bis 82 Prozent. Die höchsten Zusammenfassungen sparten bis zu 97 Prozent der Token ein, verglichen mit der direkten Verarbeitung des Quelltextes. Das ist eine erhebliche Differenz. Bei genau der Art von Frage, die klassisches RAG nicht beantworten kann, gewinnt der Graph in zwei von drei Fällen oder öfter.

Die zweite Studie betrachtet die Retrieval-Qualität selbst. Kommt die richtige unterstützende Passage überhaupt in die Top-Ergebnisse? Auf den Standard-Benchmarks für mehrstufiges Fragen – MuSiQue, HotpotQA, 2WikiMultiHopQA – steigert graphgestütztes Retrieval den Recall@5 (also den Anteil der richtigen Passagen unter den Top 5) von durchschnittlich 73,4 Prozent bei naivem RAG auf 87,8 Prozent. Das ist ein Plus von 19,6 Prozentpunkten. Die größten Sprünge gibt es bei den schwierigsten, dokumentübergreifenden Sets: plus 31 Punkte bei MuSiQue, plus 28 Punkte bei 2Wiki. HippoRAG meldet bis zu 20 Prozent Verbesserung bei mehrstufigen Fragen – und das bei 10- bis 20-fach geringeren Kosten und 6- bis 13-fach höherer Geschwindigkeit als iterative Retrieval-Methoden.

Die dritte Studie bringt die Ernüchterung. Eine Untersuchung von Michigan State und Meta aus dem Jahr 2025 hat RAG gegen vier GraphRAG-Familien unter einem einheitlichen Protokoll getestet – identische Chunking-, Embedding- und Generierungsparameter. Das Ergebnis: Es gibt keinen klaren Sieger. Die beiden Ansätze sind komplementär. Bei einstufigen Faktenfragen (Natural Questions) war klassisches RAG minimal besser (F1-Score 64,8 gegenüber 63,0 für die beste Graph-Methode). Bei mehrstufigem Denken (MultiHop-RAG) gewann graphgestütztes Retrieval: 70,3 gegenüber 67,0 Prozent Gesamtgenauigkeit. Das bedeutet: Ein Kontextgraph ist kein universelles Upgrade. Er ist ein spezialisiertes Werkzeug, das sich genau dann auszahlt, wenn Fragen das Denken über mehrere Teile hinweg erfordern.

Die vierte Studie, GraphRAG-Bench (ICLR 2026), hat sich explizit der Frage gewidmet, in welchen Szenarien Graphen messbare Vorteile bringen. Die Genauigkeit nach Aufgabentyp zeigt die Grenzen klar: Bei einfacher Faktenabfrage liegt Textchunk-RAG bei 60,9, der Graph bei 60,1 – praktisch ein Gleichstand. Die Graph-Struktur ist hier nur unnötiger Overhead. Bei komplexem Denken gewinnt der Graph mit 53,4 gegenüber 42,9 – ein Plus von 10 Punkten. Und bei kontextueller Zusammenfassung sogar mit 64,4 gegenüber 51,3 – ein Plus von 13 Punkten.

Wo GraphRAG verliert: Kosten und Bewertungsprobleme

So klar die Vorteile bei komplexen Fragen sind, so deutlich sind auch die Einschränkungen. Zwei Fallstricke sind wichtig. Erstens: Der Aufbau des Graphen ist teuer. Ein Sprachmodell muss Entitäten und Beziehungen aus dem gesamten Korpus extrahieren. Eine Analyse beziffert die Indexerstellung auf etwa 48 Dollar gegen GPT-4o für einen mittelgroßen Korpus – deutlich mehr als ein einfacher Vektorindex. Microsofts eigenes Folgeprojekt, LazyGraphRAG, verschiebt die Extraktion auf die Abfragezeit und reduziert die Kosten auf etwa 0,1 Prozent – ein stilles Eingeständnis, dass das ursprüngliche Budget für viele Anwendungen unpraktikabel ist.

Zweitens: Viele Erfolge werden von einem anderen Sprachmodell bewertet, und diese LLM-Jurys haben systematische Verzerrungen. Eine unabhängige Untersuchung fand Positionsbias – je nachdem, welche Antwort zuerst erscheint, kann sich die Siegquote um mehr als 30 Prozentpunkte verschieben – sowie Längenbias und Wiederholungsbias. Nach Korrektur fiel die gemeldete Siegquote einer populären Methode von 66,7 auf etwa 39 Prozent – unter die 50-Prozent-Schwelle. Das bedeutet nicht, dass die Forschung falsch ist. Es bedeutet, dass die großen Gewinne – die +20 Prozent bei mehrstufiger Genauigkeit, die +15 bis +30 Punkte beim Recall – robust sind, während schmale Vollständigkeitsmargen mit referenzbasierten Metriken skeptisch geprüft werden sollten.

Wann Sie zum Graphen greifen sollten (und wann nicht)

Die Entscheidung ist praktisch. Ein Kontextgraph lohnt sich, wenn Ihre Fragen mehrstufig, global oder sinnverstehend sind, wenn Sie umfassende, multiperspektivische Antworten benötigen und wenn Ihr Korpus reich an Verbindungen ist – etwa Forschungsliteratur, Fallakten, Vorfallshistorien oder Wissensdatenbanken. Bleiben Sie bei Textchunks, wenn Ihre Anfragen meist einzelne Fakten abrufen, der Korpus klein oder flach ist und wenn Indexierungskosten, Latenz oder operative Einfachheit wichtiger sind als ein marginaler Qualitätsgewinn.

Am besten fahren Sie mit einem Hybridansatz. Die systematischen Studien kommen zu demselben Ergebnis: Leiten Sie jede Anfrage an die passende Methode weiter oder kombinieren Sie die Evidenz aus beiden. Die Kombination aus Graph- und Chunk-Retrieval schlägt in den Benchmarks durchgängig jede einzelne Methode. Sie müssen sich nicht für eine Religion entscheiden; Sie müssen einen Router bauen. Das ist kein technischer Luxus, sondern eine Notwendigkeit, wenn Sie die Kosten im Griff behalten und die Qualität maximieren wollen.

Das Fazit: Kein Allheilmittel, sondern ein Werkzeug

Ein Kontextgraph ist keine Magie, aber auch kein Schlangenöl. Es ist ein gezieltes Instrument. Geben Sie ihm eine Frage, die das Verbinden verstreuter Fakten oder die Synthese eines ganzen Korpus erfordert, und er wird Textchunks deutlich schlagen. Geben Sie ihm „Wie lautet die Telefonnummer auf Seite 3?“ und Sie haben für das Indexieren bezahlt, das Sie nicht brauchten. Die Teams, die mit GraphRAG im Jahr 2026 Erfolg haben, werden nicht die sein, die alles in Graphen verwandeln. Es werden die sein, die wissen, welche Fragen einen Graphen verdienen – und die ihre Pipelines intelligent genug bauen, um den Unterschied zu erkennen.

Für Sie als Entwickler oder Tech-Entscheider bedeutet das: Schauen Sie genau auf Ihre Anwendungsfälle. Analysieren Sie Ihre typischen Anfragen. Wie oft sind sie mehrstufig? Wie stark ist Ihr Korpus vernetzt? Wenn die Antworten klar sind, haben Sie einen fundierten Kompass. Und wenn nicht, dann starten Sie mit einem Hybrid-Router – so bleiben Sie flexibel und zahlen nur für den Mehrwert, den Sie tatsächlich nutzen. Die Zukunft gehört nicht dem einen oder anderen Ansatz, sondern der klugen Kombination.

Quelle: venturebeat.com

Stell dir vor, du erklärst deinem Lieblings-Chatbot jeden Tag aufs Neue, dass du deine E-Mails lieber kompakt und ohne Floskeln bekommst. Und jeden Tag vergisst er es wieder. Kein Lerneffekt, kein Fortschritt. Du hast das Gefühl, mit einem sehr höflichen, aber vergesslichen Gegenüber zu sprechen, das nur den Moment kennt, aber keine Entwicklung. Genau dieses Problem greift ein junges Startup aus China auf. Es heißt Mind Lab und will KI-Modelle nicht nur einmal trainieren, sondern sie ein Leben lang lernen lassen.

Der Name klingt nach Zukunft, und das Konzept dahinter ist es auch: Continual Learning, also kontinuierliches Lernen. Statt ein Modell ein für alle Mal fertig zu trainieren, soll es sich durch die Interaktion mit Nutzern ständig verbessern. Mind Lab hat mit dem Modell Macaron-V1 gezeigt, dass dieser Ansatz nicht nur in der Theorie funktioniert, sondern auch wirtschaftlich trägt. Zwei Wochen nach der Kommerzialisierung der Preview-Version lag der annualisierte Umsatz bereits bei zehn Millionen US-Dollar. Das klingt nach Hype, aber ein genauerer Blick zeigt: Dahinter steckt harte Ingenieursarbeit.

Warum feste Parameter an ihre Grenzen stoßen

Die meisten großen Sprachmodelle haben ein grundsätzliches Problem: Ihre Parameter sind nach dem Training eingefroren. Das heißt, ein Modell wie GPT-4 oder Claude kennt nur das, was es beim Training gesehen hat. Es kann sich nicht an die Vorlieben eines bestimmten Nutzers anpassen, es sei denn, man bettet diese Vorlieben in den Prompt ein. Und selbst dann sind sie nur für diesen einen Dialog relevant. Retraining von Grund auf ist dagegen so teuer, dass es sich kaum ein Unternehmen leisten kann.

Denk an einen Koch, der die beste Küche der Welt gelernt hat, aber trotzdem jedes Mal gefragt werden muss, ob er Salz mag. Er kann nicht einfach lernen, dass du es gerne etwas milder magst – außer du schreibst es ihm jedes Mal auf einen Zettel. Genau so funktionieren klassische KI-Modelle. Mind Lab sagt: Das muss nicht sein. Es gibt einen schlankeren Weg, ein Modell anzupassen, ohne alles neu zu trainieren.

LoRA: kleine Bausteine, große Wirkung

Der Schlüssel heißt LoRA, was für Low-Rank Adaptation steht. Die Idee ist elegant: Statt alle Milliarden Parameter eines Modells zu verändern, fügt man ein kleines, trainierbares Modul hinzu. Dieses Modul ist viel kleiner als das Original, aber es kann auf die spezifischen Anforderungen einer Aufgabe trainiert werden. Das große Grundmodell bleibt dabei eingefroren. Man stelle sich vor, das Grundmodell ist ein sehr kompetenter Generalist. Um ihn zum Spezialisten zu machen, muss man ihn nicht komplett umschulen, sondern nur ein kleines Zusatzbuch in sein Regal stellen, das er im richtigen Moment zur Hand nimmt.

Mind Lab geht einen Schritt weiter: Das Unternehmen setzt nicht nur ein LoRA-Modul ein, sondern gleich mehrere. Diese Expertenmodule werden je nach Aufgabe dynamisch aktiviert. Das nennt sich Mixture of LoRA Adapters, kurz MoL. Eine Art Team von Spezialisten, das sich im Bruchteil einer Sekunde abspricht, wer gerade zuständig ist. Wenn ein Nutzer eine Aufgabe stellt, erkennt das System, welches Modul am besten passt – ob Chat, Coding, Agent oder UI-Generierung. Und während der Nutzer weiterarbeitet, kann aus seinen Interaktionen ein neues, individuelles LoRA-Modul entstehen, das genau auf seine Bedürfnisse zugeschnitten ist.

Macaron-V1: ein Modell mit vier Spezialisten

Im Juli 2025 veröffentlichte Mind Lab die Vollversion von Macaron-V1. Das Flagship-Modell Venti besitzt 748 Milliarden Parameter, aber nur vier Milliarden davon sind tatsächlich trainierbar. Der Rest stammt vom Basismodell GLM-5.2 und bleibt unverändert. Die vier Milliarden verteilen sich auf vier LoRA-Adapter, die für die Bereiche Chat, Agenten, Programmierung und Benutzeroberflächen zuständig sind. Damit hat das Team dem großen Grundmodell eine deutliche Leistungssteigerung entlockt – ohne das teure Volltraining.

Die von Mind Lab veröffentlichten Benchmarks zeigen, dass Macaron-V1 in sechs von zwölf Tests den Stand der Technik erreicht. In den übrigen Tests liegt das Modell nahe an den besten Modellen der Konkurrenz. Natürlich sind solche Zahlen mit Vorsicht zu genießen, schließlich stammen sie vom Unternehmen selbst. Aber die Marktreaktion spricht für sich: Nur zwei Wochen nach der Kommerzialisierung der Preview-Version erreichte das Unternehmen zehn Millionen US-Dollar Jahresumsatz. Das ist bemerkenswert für ein Startup, das erst im Oktober 2025 gegründet wurde.

Die technische Herkulesaufgabe dahinter

So einfach die Idee klingt, so anspruchsvoll ist die Umsetzung. Mind Lab hat Ende 2025 auf dem trillionenparametrigen Modell Kimi K2 LoRA-basiertes Reinforcement Learning durchgeführt. Das ist kein Selbstläufer. Bei dieser Größenordnung reicht schon eine minimale Abweichung zwischen Trainings- und Inferenzpräzision, um das Ergebnis zu verfälschen. Ein Bias-Drift entsteht, das Modell konvergiert nicht mehr. Mind Lab löste das mit einer hybriden parallelen Trainings-Engine, die Tensor-, Pipeline-, Experten- und Sequenzparallelität kombiniert. Zusätzlich kam truncated Importance Sampling zum Einsatz, um die Verteilungsunterschiede zu korrigieren.

Das Ergebnis: Mit 64 Nvidia H800 GPUs erzielte das Team Ergebnisse, die nahe an ein Volltraining heranreichen – bei nur etwa zehn Prozent des GPU-Verbrauchs. In China soll Mind Lab damit das einzige Team sein, das LoRA-basiertes Reinforcement Learning auf einem Trillionen-Parametern-Modell erfolgreich umgesetzt hat. Im Ausland wird lediglich Thinking Machines Lab, das von Mira Murati gegründete Unternehmen, ähnliche Fähigkeiten nachgesagt. Diese technische Meisterleistung ist mehr als ein akademischer Punkt. Sie zeigt, dass Continual Learning auf großem Maßstab praktikabel ist.

MinT: Die Infrastruktur wird zur Mauer

Für Andrew Chen, den Gründer von Mind Lab und ehemaligen Mitautor des FireAct-Papers, liegt der eigentliche technische Vorsprung nicht im Modell, sondern in der Infrastruktur. Im Januar hat das Unternehmen deshalb MinT abgeschlossen, eine Plattform für LoRA-Training und -Inferenz. Kunden können darüer ihre eigenen LoRA-Adapter trainieren und einsetzen. Die Plattform verwaltet über eine Million solcher Adapter. Durch die schlanke Bauweise werden beim Training, Evaluieren und Deployment nur die sehr kompakten LoRA-Module übertragen. Das beschleunigt die Ladezeiten um das Zehnfache.

Chen betont, dass sich das Verhältnis von Post-Training- zu Pretraining-Daten fundamental verschoben hat. Vor einem Jahr lag die Datenmenge für das Nachtraining noch bei einem Zehntel. Heute ist sie bei vielen Modellen höher als die Datenmenge des ursprünglichen Trainings. Und Post-Training ist technisch anspruchsvoller, weil es auf einem bereits trainierten Modell aufbaut. Für Chen ist klar: Wer diese Infrastruktur beherrscht, besitzt einen echten Wettbewerbsvorteil.

Vier Wege, ein Ziel

Continual Learning lässt sich auf unterschiedliche Weise umsetzen. Chen unterscheidet vier Ansätze. Der erste ist der Kontext im Gespräch: Das Modell interpretiert die Absicht des Nutzers innerhalb des Konversationsfensters. Der zweite ist externes Gedächtnis: Eine Datenbank wächst mit dem Wissen, das das Modell abrufen kann. Doch je größer die Datenbank, desto wichtiger wird die Qualität der Suche. Der dritte Ansatz besteht aus komplexen Abläufen und Schleifen – Harnesses, die das Modell mit vielen Werkzeugen verbinden. Das kostet Token und Zeit. Der vierte Ansatz schließlich verändert die Parameter des Modells selbst. Genau an diesem Punkt setzt LoRA an.

Für Chen ist der vierte Weg der vielversprechendste. Wenn ein Modell mit einem LoRA-Adapter erweitert wird, verändert das seine grundlegende Leistungsfähigkeit für eine bestimmte Aufgabe. Es wird zu einem echten Spezialisten. Chen illustriert das mit einer einfachen Rechnung: In manchen Anwendungen teilen sich verschiedene Modelle 99 Prozent ihrer Parameter. Das letzte Prozent entscheidet über den Unterschied. Genau dieses Prozent will Mind Lab trainieren.

Erfahrungsintelligenz als Leitidee

Hinter Macaron-V1 steckt mehr als eine technische Spielerei. Chen spricht von „experiential intelligence“ – Intelligenz, die aus Erfahrung entsteht. Ein Modell soll aus eigenen Interaktionen lernen, diese Erfahrungen in neue Fähigkeiten verwandeln und dadurch schwierigere Probleme lösen. Diese schwierigeren Probleme wiederum erzeugen neue, reichhaltigere Erfahrungen. So entsteht ein Kreislauf, der an das Lernen von Menschen erinnert. Das Modell wird nicht fertig ausgeliefert, es entwickelt sich weiter.

Damit trifft sich Mind Lab mit einer Bewegung, die gerade in der KI-Forschung an Fahrt gewinnt. Richard Sutton, Turing-Preisträger und Vater des Reinforcement Learning, hat im Juli 2025 selbst ein Startup gegründet. Oak Lab soll einen Agenten bauen, der kontinuierlich aus seinen eigenen Erfahrungen lernt. Auch Mira Muratis Thinking Machines Lab verfolgt ähnliche Ideen. Und Jie Tang, Gründer von Z.ai, hat in einem internen Brief angekündigt, dass sein Unternehmen vor allem an Gedächtnis, kontinuierlichem Lernen und Selbstbewertung arbeiten wird. Die Branche hat erkannt: Der nächste große Sprung in der KI wird nicht beim Training, sondern beim Nachlernen passieren.

Was das für dich bedeutet

Wenn sich Continual Learning durchsetzt, wird sich dein Verhältnis zu KI grundlegend ändern. Der Chatbot von morgen wird sich merken, wie du arbeitest, welche Antworten du bevorzugst und in welchem Stil du kommunizierst. Er wird nicht bei jeder Sitzung bei null anfangen. Stattdessen entsteht eine Art digitales Gedächtnis, das sich mit jeder Nutzung aktualisiert. Das ist die Vision, die Mind Lab mit Macaron-V1 andeutet.

Noch ist es eine Vision. Die technischen Hürden sind hoch, und die Benchmarks stammen vom Unternehmen selbst. Aber die Markttests zeigen, dass für diesen Ansatz echtes Interesse besteht. Investoren haben mindestens 60 Millionen US-Dollar in Mind Labs Muttergesellschaft gesteckt, und die Reihe A wurde von Meituan angeführt. Das ist ein Signal: Die Branche wittert das große Geschäft mit den kleinen Adaptern. Am Ende könnte es so sein wie mit dem Koch, der sich endlich deine Lieblingsgerichte merkt – nicht weil du es ihm jedes Mal sagst, sondern weil er gelernt hat.

Quelle: kr-asia.com

Stell dir vor, du arbeitest seit Stunden an einem größeren Next.js-Projekt. Der Dev-Server läuft, du wechselst zwischen Dateien, speicherst, schaust im Browser nach. Irgendwann fängt dein Laptop an zu röcheln. Die Lüfter drehen hoch, der Arbeitsspeicher ist voll, jeder Tastendruck fühlt sich an, als müsste sich der Rechner erst durch einen Berg unerledigter Aufgaben kämpfen. Dieses Szenario kennt fast jede Entwicklerin und jeder Entwickler, die regelmäßig mit React-Frameworks arbeiten. Genau hier setzt die neue Version an, die das Next.js-Team gerade veröffentlicht hat: Next.js 16.3. Sie verspricht nicht weniger, als den Entwicklungsalltag spürbar angenehmer zu machen – mit weniger Speicherverbrauch, schnelleren Builds und einem deutlichen Schritt in Richtung einer reaktiveren Nutzererfahrung.

Was auf den ersten Blick wie eine weitere Punktversion im Versionszyklus aussieht, entpuppt sich bei genauerem Hinsehen als eines der umfangreichsten Updates seit dem großen 16.0-Release im November. Der offizielle Blogbeitrag spricht von der größten Aktualisierung seitdem – und meint das nicht nur marketingmäßig. Die Änderungen betreffen sowohl die tägliche Arbeit am Code als auch die Performance, die Endnutzer am Ende zu spüren bekommen. Wer Next.js bereits nutzt, kann mit einem simplen Update auf 16.3 wechseln und profitiert in den meisten Fällen sofort von den Verbesserungen, ohne den eigenen Anwendungscode anfassen zu müssen. Das ist eine Ansage, die man nicht unterschätzen sollte.

Der Dev-Server wird zum Leichtgewicht

Der vielleicht greifbarste Gewinn liegt im Speicherverbrauch des Development-Servers. Das Team hat es geschafft, den RAM-Bedarf von Turbopack beim Ausführen von next dev um bis zu 90 Prozent zu senken. Zwei Mechanismen machen das möglich: Zum einen gibt es seit Version 16.1 ein Disk-Caching, das auch im Entwicklungsmodus greift, zum anderen kommt jetzt eine Art Gedächtnis-Auslagerung hinzu, die nicht mehr benötigte Daten aus dem Arbeitsspeicher verdrängt. Man kann sich das wie eine gut organisierte Küche vorstellen: Statt alle Zutaten und Werkzeuge gleichzeitig auf der Arbeitsplatte liegen zu haben, werden sie bei Nichtgebrauch zurück in den Schrank geräumt. Alles bleibt verfügbar, aber die Fläche bleibt frei.

Die Zahlen, die das Team nennt, sind beachtlich. Bei der Entwicklung des Vercel-Dashboards sank der Speicherverbrauch nach dem Kompilieren von 50 Routen von 21,5 Gigabyte auf 2 Gigabyte. Für die nextjs.org-Website ging es von 4.600 Megabyte auf 840 Megabyte herunter. Natürlich sind das Messwerte aus der eigenen Firma, aber sie zeigen eine klare Richtung: Wer lange an einem Projekt arbeitet, wird den Unterschied wahrscheinlich direkt merken. Gerade für Menschen mit weniger üppig ausgestatteten Laptops ist das ein Segen. Der Dev-Server wird damit insgesamt zu einem Werkzeug, das weniger im Weg steht und mehr beim Entwickeln hilft.

Schnellere Builds durch kluge Wiederverwendung

Auch beim Bauen für die Produktion hat sich einiges getan. Das Disk-Caching, das bisher nur dem Dev-Server zugutekam, funktioniert jetzt ebenso mit next build und ist standardmäßig aktiv. Das bedeutet: Wenn du einen Build ausführst, merkt sich Next.js, welche Teile des Projekts sich seit dem letzten Mal nicht verändert haben. Diese unveränderten Artefakte kann es direkt aus dem Cache lesen, anstatt sie komplett neu zu kompilieren. Beim CI-Einsatz, also in automatisierten Build-Pipelines, lassen sich so laut Vercel in manchen Projekten 5,5-mal schnellere Build-Zeiten erreichen. Das spart nicht nur Zeit, sondern auch Geld, gerade wer Cloud-Ressourcen nach Zeitabrechnung nutzt.

Ein weiterer Baustein für schnellere Builds ist die Integration von TypeScript 7 in den Build-Prozess. TypeScript 7 ist ein vollständig in Rust neu geschriebener Compiler, der eine etwa zehnmal schnellere Typprüfung ermöglicht als der bisherige JavaScript-basierte. In Next.js 16.3 reicht es, eine lokale Dependency auf die neue Version anzuheben, um diesen Geschwindigkeitsvorteil bei next build zu nutzen. Das ist ein unkompliziertes Upgrade, das keine Codeänderungen erfordert. Für Projekte mit vielen Typen kann das den letzten Engpass beim Build deutlich entschärfen.

Server-Rendering mit weniger Overhead

Next.js verwendet im App Router standardmäßig Server Components. Bisher wurden die Datenströme während des Server-Side-Renderings über Web-Streams geschickt, dann aber in native Node.js-Streams umgewandelt, bevor sie an den Client gingen. Diese Umwandlung war unnötiger Overhead. Das Team hat die Rendering-Schicht deshalb so umgebaut, dass direkt native Node.js-Streams verwendet werden. Die Folge: Die Server können laut Benchmarks bis zu 22 Prozent mehr Requests unter Last bewältigen. Für eine Website mit hohem Traffic ist das ein relevantes Plus, ohne dass man als Entwicklerin oder Entwickler etwas dafür tun muss. Die Architektur wird schlanker, und davon profitieren alle.

Kleinere, aber feine Neuerungen für den Alltag

Neben den großen Performance-Themen enthält Next.js 16.3 einige Verbesserungen, die sich eher im Detail bemerkbar machen. Eine davon betrifft die Dokumentation für KI-Agenten. Wer Cursor, Copilot und Co. verwendet, weiß, wie mühsam es sein kann, wenn der Assistent veraltete Infos aus dem Internet zieht. Jetzt schreibt next dev einen versionsabgeglichenen AGENTS.md-Block in das Projekt, der direkt auf die Dokumentation in den lokalen node_modules verweist. Coding-Agenten bekommen damit automatisch die richtigen Informationen, ohne dass man sie manuell füttern muss. Das ist ein nettes Detail, das den Alltag mit generativen KI-Werkzeugen spürbar erleichtert.

Auch beim Prefetching gibt es eine Optimierung. Next.js war dafür bekannt, dass es beim Anklicken von Links oft viele einzelne Requests auslöst. Jetzt werden kleinere Prefetch-Payloads automatisch gebündelt, wodurch die Gesamtzahl der Requests sinkt. Größere Shared Segments bleiben separat, damit sie über mehrere Routen hinweg wiederverwendet werden können. Außerdem können immutable statische Assets nun über Deployments hinweg gecacht werden, weil sie sich ja nie ändern und es deshalb keine Inkonsistenzen geben kann. Das spart Bandbreite und beschleunigt den Seitenaufbau.

Zwei neue APIs runden das Update ab. Mit catchError können Entwickler individuelle Error Boundaries definieren, die nicht mehr in Konflikt mit notFound oder redirect geraten und sogar eine retry()-Funktion erhalten, um fehlgeschlagene Server Components neu zu rendern. Und mit den neuen Root Params lassen sich dynamische Parameter, die auf einer oberen Ebene wie [lang] definiert sind, direkt aus jedem Server Component heraus abrufen. Das erspart das lästige Prop-Drilling, insbesondere bei Internationalisierung. Dazu kommt noch die Unterstützung von Glob Imports über import.meta.glob, die es erlaubt, mehrere Dateien gleichzeitig zu laden und von Hot Module Replacement zu profitieren.

Instant Navigations: Der Blick nach vorn

Der größte inhaltliche Schwerpunkt von 16.3 ist jedoch eine Reihe von opt-in Features, die das Team unter dem Begriff Instant Navigations zusammengefasst hat. Das Ziel: die gefühlte Geschwindigkeit von klassischen Single-Page-Applications auf Next.js übertragen, ohne die Vorteile des serverseitigen Rendering-Modells aufzugeben. Bisher galt: Wenn ein Nutzer einen Link anklickt, muss der Server erst die Daten holen und die Seite rendern – das dauert. Mit Instant Navigations sollen bereits vorab gerenderte Teile der Zielseite im Client liegen. Das geschieht über eine Kombination aus Suspense, use cache und einem intelligenten Prefetching. Die Navigation fühlt sich dann an, als würde die Seite sofort wechseln, so wie man es von einer gut gebauten SPA gewohnt ist.

Ermöglicht wird das durch zwei neue Konzepte: Partial Prefetching und Instant Insights. Partial Prefetching gibt Entwicklerinnen und Entwicklern die Kontrolle darüber, wie viel Inhalt von einer verlinkten Seite bereits vorab geladen wird. Man kann sich das wie ein Theater vorstellen, bei dem schon einmal die Bühne aufgebaut ist, bevor das Publikum Platz nimmt. Nur die Sitzplatzzuweisung und das geteilte Bühnenbild werden beim Klick auf den Link aktualisiert. Instant Insights ist ein neues Werkzeug in den Next.js DevTools, das langsame Navigationen automatisch aufspürt. Es zeigt an, welche Seiten beim Klick auf einen Link zu lange brauchen, und gibt sogar Hinweise, wie man das beheben kann. Zusammen mit einem Playwright-Helfer für Regressionstests wird so verhindert, dass spätere Refactorings die Navigation wieder ausbremsen.

Ein weiterer Baustein ist die verbesserte Incremental Static Regeneration. Bei Seiten, die nicht beim Build vorgerendert wurden, bekommen erste Besucher bisher eine leere Hülle, bevor der Server die Seite nach und nach aufbaut. Mit den neuen Funktionen kann Next.js dem ersten Besucher stattdessen sofort eine Ladegerüst-Hülle zeigen, während im Hintergrund die echten Daten geladen werden. Das fühlt sich für den Nutzer an, als würde die Seite deutlich schneller reagieren. All diese Mechaniken werden in einer zukünftigen Hauptversion von Next.js zum Standard erklärt werden. Das Team betont, dass es damit zu den Wurzeln des Frameworks zurückkehren will: dynamisch von Haus aus, ohne versteckte Caching-Fallen.

Experimentelles: Rust-Compiler und Netzwerk-Resilienz

Neben den stabilen und den opt-in Features bietet 16.3 auch experimentelle Werkzeuge. Dazu gehört ein React Compiler, der in Rust geschrieben ist und damit deutlich schneller als die bisherige JavaScript-Variante sein soll. Außerdem arbeitet das Team an Netzwerk-Resilienz, also an Funktionen, die Anwendungen stabiler machen sollen, wenn die Serververbindung schwankt oder einzelne Requests fehlschlagen. Beides ist noch nicht für den Produktiveinsatz gedacht, zeigt aber, wohin die Reise geht: mehr Leistungsfähigkeit auf der unteren Ebene und mehr Robustheit im Alltag.

Was bedeutet das konkret?

Next.js 16.3 ist kein großes Release mit bahnbrechenden neuen APIs, die man sofort lernen muss. Es ist vielmehr ein Update, das die Fundamente stärkt. Wer heute mit Next.js arbeitet, sollte in Erwägung ziehen, das Upgrade zeitnah durchzuführen. Allein der geringere Speicherverbrauch im Dev-Modus und die schnelleren Builds rechtfertigen das. Die Instant-Navigations-Features sind noch opt-in, aber sie zeigen eine klare Entwicklungsrichtung. In einer zukünftigen Hauptversion werden diese Funktionen zum Standard erklärt – und Projekte, die sie bereits heute nutzen, sind dann schon einen Schritt voraus. Das Team hat mit 16.3 also nicht nur eine neue Version veröffentlicht, sondern auch einen Fahrplan vorgelegt. Und der sieht für das Framework, das bereits zu den beliebtesten React-Lösungen gehört, ziemlich vielversprechend aus.

Quelle: nextjs.org

Einen neuen Mitarbeiter stattet man nicht nur mit Stift und Zettel aus. Er bekommt einen Schreibtisch, einen Rechner, Zugang zu den richtigen Ordnern und die Werkzeuge für seine Arbeit. Erst dann kann er loslegen. Cloudflare überträgt das auf KI-Agenten. Die fähigsten Agenten haben eines gemeinsam: Sie bekommen einen eigenen Computer. Ein Container allein reicht nicht. Der Agent braucht eine Umgebung, in der er Dateien sieht, Befehle ausführt, Werkzeuge nutzt und das Ergebnis testet.

Cloudflare hat mit @cloudflare/computer eine erste Vorschau einer Laufzeitumgebung vorgestellt. Jeder Agent bekommt einen virtuellen Arbeitsplatz. Die Plattform übernimmt die Details, ob der Code in einem Isolate, einer Container-Sandbox oder im Browser läuft. Der Agent merkt davon nichts. Entwickler müssen sich nicht mehr um die Infrastruktur kümmern und können sich auf die Aufgabe konzentrieren. Das klingt unspektakulär, ist aber ein Denkwechsel.

Vom Container zum Sandbox-Werkzeug

Wer in den letzten Monaten KI-Agenten gebaut hat, kennt das Muster: Erst startete man einen Container und ließ den Agenten darin laufen. Inzwischen bekommen Agenten Sandboxen nur noch als Werkzeug. Das Gehirn des Agenten – die Schleife aus Denken, Handeln und Bewerten – läuft getrennt von den Händen, die im Sandbox-System arbeiten. Cloudflare nennt das eine Befreiung. Aber es bringt ein neues Problem mit sich.

Das Problem ist einfach: Es gibt nicht genug Compute. Wenn Hunderte Millionen oder Milliarden Agenten gleichzeitig arbeiten, kann nicht jeder einen eigenen Container mit kompletter Linux-Umgebung bekommen. Die Clouds und Hyperscaler haben dafür nicht genug Ressourcen. Diese Knappheit erklärt den Bedarf an CPU-Leistung, nicht nur an GPUs. Wer skalierbare Agenten bauen will, muss über Container hinausdenken.

Cloudflare hat das früh getan. Mit Cloudflare Workers setzte das Unternehmen vor fast zehn Jahren auf Isolates. Das ist eine leichtere Ausführungsform als Container. Isolates teilen sich den zugrunde liegenden Prozess, starten in Millisekunden und verbrauchen nur dann Speicher, wenn sie arbeiten. Vor fast sechs Jahren kam mit Durable Objects der nächste Schritt: Zustand und Logik in einem horizontal skalierbaren Objekt, das bei Bedarf aufwacht und wieder einschläft. Das zahlt sich jetzt aus.

Warum Isolates besser zu Agenten passen

Isolates haben Eigenschaften, die zu KI-Agenten passen. Sie skalieren horizontal nahezu unbegrenzt. Sie starten und stoppen schnell. Sie können in den Ruhezustand gehen, wenn der Agent nichts tut. Sie speichern ihren eigenen Zustand. Und sie können eigene Isolates starten, um nicht vertrauenswürdigen Code auszuführen. Agenten wechseln ständig zwischen Warten und Arbeiten – genau dafür sind sie gebaut.

Ein Container ist dagegen ein schweres Geschütz. Er fährt ein vollständiges Betriebssystem hoch und braucht Speicher und CPU, auch wenn nichts passiert. Manche Aufgaben brauchen einen Container: Linux-Befehle, npm-Pakete, native Binaries. Für sie ist ein Isolate überfordert. Deshalb können Isolates seit dem vergangenen Jahr bei Bedarf eigene Container-Sandboxes starten. Der Agent selbst läuft in einem Durable Object, also einem Isolate. Den Container ruft er nur auf, wenn er ihn braucht.

Die Kombination aus horizontaler Skalierung im Isolate und vertikaler Skalierung im Container ist stark. Aber sie zwingt Entwickler, die beiden Welten selbst zu verdrahten. Man muss wissen, wann man welches Primitive einsetzt, und die Synchronisation zwischen Dateisystem und Umgebung selbst organisieren. Cloudflare glaubt, dass es einfacher geht. Hier setzt @cloudflare/computer an.

Ein Computer für den Agenten

Die zentrale Idee von @cloudflare/computer ist ein vorbereitetes Dateisystem. Der Agent bekommt ein virtuelles Dateisystem, deklarativ definiert und mit allem, was er für seine Aufgabe braucht. Dazu kommen mehrere Ausführungsumgebungen, mit denen er auf diesen Dateien arbeitet. Jede Umgebung hat eigene Stärken und Schwächen – bei Geschwindigkeit, Fähigkeiten und Kosten. In den Tests von Cloudflare wählten die Modelle überraschend zuverlässig die richtige Umgebung.

Eine Aufgabe, die nur Dateien verschiebt, Daten verarbeitet oder ein Git-Repository verwaltet, läuft direkt im Isolate. Ein Befehl, der Linux, npm oder eine native Binary braucht, läuft im Container. Beide Umgebungen arbeiten auf denselben Dateien, die permanent synchronisiert werden. Der Agent sieht eine konsistente Welt, egal wo der Code ausgeführt wird. Das ist die Kernabstraktion: ein Computer mit einem Dateisystem und mehreren Ausführungsmodi.

Technisch ist das Werkzeug eine Open-Source-Bibliothek. Eine Workspace-Instanz läuft auf jedem Durable Object und stellt ein virtuelles Dateisystem plus Ausführungsruntime bereit. Das Dateisystem wird von SQLite gestützt und kann aus verschiedenen Quellen befüllt werden – aus Git-Repositories, Storage-Buckets oder eigenen Dateien. Dazu kommen Werkzeuge zum Lesen, Schreiben und Bearbeiten von Dateien, im Code-Modus oder über Bash-Befehle. Alle Operationen sind protokolliert und überwacht. Entwickler bekommen so feingranulare Kontrolle darüber, was der Agent ändern darf – und eine lückenlose Nachvollziehbarkeit.

Wie du es einsetzt

Die Installation läuft über npm: npm install @cloudflare/computer. Danach erstellst du eine Workspace auf einem Durable Object. Im Blogbeitrag wird ein Agent gebaut, der Bug-Reports sortiert. Der Agent bekommt die Workspace mit Dateisystem und Tools, dazu einen Container als Backend. Die Modell-Schleife nutzt die Tools, um Issues zu analysieren und zu beantworten. Du kannst die Workspace-API auch direkt verwenden, etwa um die Umgebung vorzubereiten, bevor der Agent startet.

Im Paket sind mehrere Execution Backends enthalten. Das erste ist ein Isolate-basiertes Runtime, das mit just-bash Shell-Code in JavaScript übersetzt und in einem dynamischen Worker ausführt. Das Dateisystem ist hier direkt über Worker-Bindings verfügbar. Das zweite Backend ist ein Container-Runtime, das Cloudflare Containers nutzt und eine vollständige Linux-Umgebung bereitstellt. Das Dateisystem wird über ein FUSE-Mount eingebunden. Änderungen im Container werden automatisch zurückgeschrieben. Wer will, kann eigene Backends schreiben.

Für Agenten gibt es ein AI-SDK-kompatibles Toolkit mit den üblichen Werkzeugen: read, write, edit, ls und exec. Das exec-Tool akzeptiert ein backend-Argument. Die Tool-Beschreibung führt das Modell dazu, selbst zu entscheiden, ob es den schnellen, günstigen Worker oder den vollwertigen Container braucht. In den Tests von Cloudflare treffen die aktuellen Frontier-Modelle diese Entscheidung zuverlässig. Sie greifen nur dann zum Container, wenn es nötig ist.

Was das für die Zukunft bedeutet

Cloudflare sieht heute Agenten, die ausschließlich Isolates nutzen, um JavaScript-Anwendungen zu bauen, zu test

Quelle: blog.cloudflare.com

Stell dir vor, du arbeitest in einem Team. Ihr nutzt einen gemeinsamen Chat, in dem ein KI-Agent sitzt. Du schreibst ihm eine persönliche Nachricht, und er erledigt Aufgaben für dich. Er kennt deine Vorlieben, deine Projekte, deine Art zu arbeiten. Der Agent ist nützlich, weil er dich versteht. Aber was passiert, wenn dieser Agent nicht nur dein Assistent sein soll, sondern für die ganze Firma arbeiten soll? Dann darf er nicht mehr nur dich kennen. Er muss verstehen, wer gerade spricht, in welchem Raum die Anfrage gestellt wurde, welche Informationen für wen gedacht sind und welche Rechte an welcher Stelle gelten. Genau dieses Problem versucht das neue Open-Source-Projekt QM zu lösen.

Der Unterschied zwischen persönlichem Agenten und Company-Agent

Ein persönlicher Agent wird nützlich, indem er eine einzige Person lernt. Er speichert Vorlieben, wiederkehrende Abläufe und Tools. Seine Kontinuität ist persönlich. Das macht ihn mit der Zeit so wertvoll. Ein Company-Agent hat eine schwierigere Aufgabe. Er muss genug wissen, damit Menschen effektiv zusammenarbeiten können – ohne das gesamte Unternehmen als eine einzige Person mit einer einzigen Berechtigung zu behandeln. Ein Firmen-Chat ist eben kein besonders langes Gespräch mit einem riesigen Verlauf. Es ist ein Geflecht aus verschiedenen Menschen, Teams, Projekten und Vertraulichkeitsstufen.

Der Tech-Blogger, der diesen Artikel verfasst hat, beschreibt genau diese Problematik. Er hat sich intensiv mit QM beschäftigt, dem neuesten Wurf von Y Combinator. Die bekannte Startup-Schmiede hat QM als Open-Source-Projekt veröffentlicht, nachdem sie wertvolle Erfahrungen gesammelt hat: Y Combinator hat mehr als 50 Hermes-Agenten als persönliche Assistenten für Mitarbeiter bereitgestellt. Und dabei festgestellt, dass allein die Verwaltung dieser Flotte eine Herausforderung ist. Eine charmante Erkenntnis: Selbst mit 50 gut funktionierenden persönlichen Agenten ist die Organisation des Ganzen komplex. Und jetzt stell dir mal vor, wie das erst bei einer Firma mit tausend Mitarbeitern aussieht.

Die Analogie des Hauses mit vielen Räumen

Um zu verstehen, was QM anders macht, hilft eine einfache Analogie. Stell dir ein großes Haus vor. In diesem Haus arbeitet ein Unternehmen. Es gibt Einzelbüros, in denen Mitarbeiter private Notizen machen. Es gibt Besprechungsräume für kleine Gruppen. Es gibt Abteilungsflure, Team-Bereiche und schließlich das Foyer, das alle betreten können. Jeder Raum hat eigene Regeln. Im Intranet-Schrank liegen andere Zugangsdaten als im Projektraum. Und wenn ein Mitarbeiter das Haus verlässt, verliert er automatisch seinen Schlüssel – aber die Erinnerungen an seine Projekte bleiben dort, wo sie entstanden sind.

Ein normaler KI-Agent, der alle diese Räume als einen einzigen Raum behandelt, würde bald entscheidende Grenzen übersehen. Wer darf die Antwort sehen? Gehört das Memo zum Projekt oder zur persönlichen Vorbereitung? QM führt dafür eine explizite Struktur ein. Die Software erkennt fünf verschiedene Bereiche: persönlich, Kanal, Gruppe, Team und Organisation. Das klingt banal, ist aber ein entscheidender Schritt. Damit gesteht die Architektur ein, dass ein Unternehmen keine einzige riesige Konversation ist. Es braucht einen Vokabular, um zu beschreiben, wo Arbeit hingehört und wer dort zuhause ist.

Eine Steuerungsebene statt einer monolithischen KI-Schleife

Die eigentliche architektonische Entscheidung von QM ist, die Organisationslogik aus der KI-Schleife herauszulösen. Ein Agent-Harness – also das System, das die KI-Abfrage ausführt – kann für einen einzelnen Schritt zuständig sein: Anfrage interpretieren, Tools aufrufen, Aufgabe bearbeiten, Ergebnis liefern. QM übernimmt als „Control Plane“ die Verantwortung für den Kontext: Es klärt, wer spricht, welcher Bereich betroffen ist, welcher gemeinsame Zustand existiert und welche Richtlinien und Genehmigungen gelten. Dann entscheidet es, wo die Arbeit laufen soll und welche Harness – etwa Pi, OpenCode, Codex oder Claude Code – verwendet wird.

Diese Trennung ist wichtiger als die konkrete Liste der unterstützten Systeme. Ein Unternehmen kann so eine genehmigte Harness und ein genehmigtes Modell wählen, ohne dass sie sich in die Chat-Historie der Werkzeuge ausweiten. Die KI-Schleife macht die Arbeit. Die Steuerungsebene merkt sich, was diese Arbeit im Kontext des Unternehmens bedeutet. Das ist keine magische Portabilität. Man kann nicht einfach ein laufendes System zwischen verschiedenen Harnesses hin- und herschieben, ohne dass sich Verhalten oder Abläufe ändern. Aber der gemeinsame Kontext hat einen festen Ort.

Warum diese Perspektive gerade für Hermes-Fans interessant ist

Der Autor des ursprünglichen Artikels liest QM aus der Perspektive eines Menschen, der den Hermes-Agenten gewohnt ist. Das ist kein objektiver Produktvergleich, sondern eine sehr ergiebige Kontrastübung. Hermes funktioniert intuitiv als persönlicher Agent. Sein Wert wächst mit den persönlichen Tools, Erinnerungen und Arbeitsabläufen einer einzelnen Person. Der Agent wird über die Zeit nützlicher, weil er genau diese eine Person abbildet. Kontinuität ist etwas sehr Individuelles. QM stellt nun die Frage, was passiert, wenn diese Kontinuität für eine Gruppe gelten soll.

Ein Team möchte ebenfalls, dass die Arbeit mit der Zeit leichter wird. Ein Projektraum sollte sich merken, wie der Release-Prozess funktioniert, ohne dabei private Gespräche aus dem ganzen Unternehmen aufzusaugen. Menschen sollen durch denselben Agenten zusammenarbeiten können, ohne zu einer anonymen Masse zu verschmelzen. Deshalb braucht es eine Vorstellung davon, wessen Absicht gerade ausgeführt wird, welcher Raum den Kontext liefert, wer Änderungen vornehmen darf und wo das Ergebnis sichtbar bleibt.

Sicherheit und Governance: keine rosarote Brille

Der Artikel macht sehr deutlich, dass QM ambitioniert und früh ist. Die Autoren warnen davor, die Isolationsziele als Garantie zu verstehen. Es gibt kein Zertifikat, keinen Beweis, dass keine Daten leaken. Das ist keine Kritik am Projekt, sondern eine vernünftige Ansage: Wer eine so mächtige Software betreibt, braucht eine eigene Sicherheitsüberprüfung. QM hat einen Modus namens „Auto“, der Inhalte nicht immer prüft, und einen Modus „Strict“, der bei jedem Tool-Aufruf eine menschliche Freigabe verlangt. Die Sandbox-Optionen haben unterschiedliche Eigenschaften. Die Autoren betonen, dass man die funktionierenden Komponenten nicht mit vollständiger Netzwerk-Isolation verwechseln sollte.

Ein weiterer wichtiger Punkt ist der gemeinsame Speicher. Ein System, das sich im Namen einer Gruppe erinnert, braucht klare Regeln für Aufbewahrung, Löschung, Audit-Zugriff und rechtliche Pflichten. Das ist eine Governance-Frage, kein Hinweis auf einen Datenleak. Wer einen Agenten in ein Unternehmen einlädt, muss wissen, wer für das Gelernte verantwortlich ist. Eine persönliche KI-Erinnerung ist eine Sache. Eine geteilte Erinnerung betrifft alle Mitarbeiter.

Der Kern: Ein Unternehmen ist keine Person

Die Idee hinter QM ist größer als diese erste Implementierung. Die Liste der Harnesses kann sich ändern, das Sicherheitsmodell kann reifen, manche Entscheidungen von heute werden verschwinden. Aber das Grundproblem bleibt: Ein geteilter Agent ist nicht einfach ein persönlicher Agent mit mehreren Benutzern im selben Chat. Er braucht eine explizite Theorie von Personen, Räumen, Autorität, Erinnerung und Verantwortung. QM hat dieses Problem in den Vordergrund gerückt.

Es trennt den Agenten, der einen Arbeitsschritt ausführt, von der organisatorischen Steuerungsebene, die diesem Schritt Kontext und Grenzen gibt. Damit bekommen wir etwas Konkretes zum Beobachten: Schafft QM es, dass Umfang, Autorität und Erinnerung im normalen Arbeitsalltag nutzbar werden – nicht nur in einem Architekturdiagramm? Wenn ja, dann sieht der Company-Agent nicht mehr aus wie ein riesiger Chat, sondern wie eine gemeinsame Infrastruktur. Selbst wenn diese konkrete Software nicht die endgültige Antwort ist, ist genau dieser Wechsel der Denkweise bemerkenswert.

Für alle, die sich mit KI-Technologie beschäftigen, ist QM ein spannendes Beispiel dafür, wie wir die nächste Stufe der Zusammenarbeit mit künstlicher Intelligenz gestalten. Es zeigt, dass es bei KI nicht nur um schlauere Modelle geht, sondern um die Frage, wie wir diese Modelle in soziale und organisatorische Strukturen einbetten. Wer verstehen will, was KI für Einsteiker bedeutet und wie KI-Anwendungen im Unternehmen konkret aussehen, findet in diesem Projekt viele Antworten. QM erklärt auf seine Art, was eine künstliche Intelligenz braucht, um nicht nur zu antworten, sondern wirklich zu verstehen – in welchem Raum sie sich gerade bewegt.

Quelle: magnus919.com