Dieses Projekt gehört zu den älteren der Multi-Agenten-Welle, entstanden in der Forschungsabteilung eines großen Softwareherstellers, und es war unter den ersten, die eine schlichte Idee auf die Bühne brachten: eine Gruppe von Agenten unterhält sich, bis die Arbeit fertig ist. Der heutige Zustand bringt eine Bedingung mit, die vor allem anderen stehen muss — das Projekt ist im Wartungsmodus, nimmt keine neuen Funktionen mehr auf und wird von der Community geführt. Dieser Test teilt sich deshalb in zwei Hälften: was es ist und wie es funktioniert, und dann, ob es noch die richtige Wahl ist.

Vier Teile, nach Tiefe getrennt

Die Dokumentation schneidet das Projekt in vier Teile, jeder mit eigenem Einstieg. Die Studio-Oberfläche ist eine Weboberfläche, in der ein Agentenprototyp ohne Code entsteht: ein Paket, ein Befehl, ein Port und ein Arbeitsverzeichnis. Sie sitzt auf der Dialogebene, gilt als erster Anlaufpunkt für Neueinsteiger und wird zugleich als gut zum Prüfen einer Idee markiert, nicht für den Produktivbetrieb. Die Dialogebene ist die, gegen die man schreibt: Anwendungen mit einem oder mehreren Agenten rund um ein Gespräch, Python 3.10 oder neuer vorausgesetzt, mit Beispielen von einem Dutzend Zeilen — einen Assistenten anlegen, ihm einen Modellclient geben, eine Aufgabe starten, die Antwort ausgeben. Der Kern liegt tiefer und ist ein ereignisgesteuertes Programmierframework, gedacht für deterministische Abläufe in Geschäftsprozessen, für Forschung zu Multi-Agenten-Zusammenarbeit und für verteilte Agenten über Sprachgrenzen hinweg. Die Erweiterungen holen die Außenwelt herein: Komponenten für Server des Modellkontextprotokolls, Agenten für Assistentenschnittstellen, einen Executor, der modellgenerierten Code in einem Container ausführt, und eine Laufzeit für verteilte Agenten.

Vom Gespräch zum Gruppenchat

Der rote Faden der Dokumentation läuft Modell, Nachricht, Agent, Team, menschliche Beteiligung, Abbruchbedingungen, Zustandsverwaltung — und diese Reihenfolge ist selbst eine Aussage. Sie unterstellt, dass die Arbeit eine Weile läuft, weshalb Abbruch und Zustand eigene Kapitel bekommen statt eines Anhangs. Eine Ebene höher bieten die Orchestrierungsmuster echte Alternativen. Ein Selektor-Gruppenchat nutzt einen zentralen, anpassbaren Selektor, der entscheidet, wer als Nächstes spricht, koordiniert über gemeinsamen Kontext. Ein Schwarm gibt diese Entscheidung nach unten ab und lässt Agenten über lokale Werkzeugselektoren direkt übergeben. Ein Graph-Workflow organisiert den Multi-Agenten-Ablauf als gerichteten Graphen, was zu Fällen mit klaren Grenzen passt. Drumherum steht die technische Ausstattung — Gedächtnis und Retrieval-Anreicherung, Protokollierung, Serialisierung von Komponenten, Verfolgung und Beobachtbarkeit — dazu ein offizielles Beispielteam aus Dialogebene und Erweiterungen, gebaut für kombinierte Arbeit wie Browsen, Codeausführung und Dateiverarbeitung. Wer Tempo braucht, beginnt in der Oberfläche und skizziert einen Prototyp; wer Details braucht, steigt in den Kern und schreibt die Ereignisschleife selbst.

Der Wartungsmodus wiegt schwerer als die Funktionsliste

Der Hinweis oben im Repository ist deutlich: Das Projekt ist im Wartungsmodus, erhält keine neuen Funktionen und Verbesserungen und wird von der Community geführt; Neueinsteiger sollen mit dem benannten Nachfolger beginnen, für Bestandsnutzer gibt es eine Migrationsanleitung. Derselbe Hinweis erklärt, der Nachfolger sei der unternehmensgerechte Ersatz, bereits in einer produktionsreifen Version mit stabilen Schnittstellen und Langzeit-Support-Zusage verfügbar, vom einzelnen Assistenten bis zum Verbund mehrerer Agenten, mit unternehmensweiter Orchestrierung, mehreren Modellanbietern und Interoperabilität über die beiden aufkommenden Agentenprotokolle. Der Beitragsleitfaden ist entsprechend enger geworden: angenommen werden nur Fehlerbehebungen, Sicherheitspatches und Doku-Verbesserungen, Funktionsarbeit wird an den Nachfolger verwiesen.

Die Dreischichtigkeit selbst bleibt klar. Der Kern übernimmt Nachrichtenübermittlung, ereignisgesteuerte Agenten sowie lokale und verteilte Laufzeiten, in Python und in C#. Die Dialogebene bietet darüber eine einfachere, aber meinungsstarke Schnittstelle für die vertrauten Formen Zwiegespräch und Gruppenchat. Die Erweiterungen liefern Modellclients und Codeausführung. Als Werkzeuge kommen die Oberfläche ohne Code und eine Benchmark-Suite dazu. Die Lizenz läuft zweigleisig: Code unter MIT, Dokumentation unter einer Creative-Commons-Namensnennung. Die Repository-Zahlen nennen etwa 61k Sterne, 9,2k Forks, 98 Veröffentlichungen und 556 Beitragende, genutzt in 4,3K Projekten, überwiegend in Python, daneben C# und TypeScript.

Für wen es noch taugt

Drei Gruppen werden weiter gut bedient. Teams mit bestehenden Projekten, in denen Code läuft und Modelle abgestimmt sind: Im Wartungsmodus laufen Fehler- und Sicherheitspatches weiter, die Migration lässt sich also im eigenen Tempo planen statt von einer neuen Version erzwungen. Entwickler, die untersuchen wollen, wie Multi-Agenten-Zusammenarbeit aufgebaut ist: Die drei Muster treffen jeweils eine klare Abwägung und taugen mit der Benchmark-Suite daneben für kontrollierte Vergleiche, Dokumentation und Beispiele bleiben stehen. Und alle, die eine Idee schnell prüfen wollen, denn die Oberfläche ist nach der Installation Drag-and-drop und deutlich weniger Arbeit als Orchestrierung von null aufzubauen.

Zwei Lagen sollten direkt zum Nachfolger gehen. Neue Produktivsysteme, besonders dort, wo eine Langzeit-Support-Zusage verlangt wird — das Framework hat klar gesagt, dass nichts mehr dazukommt, und eine neue Architektur auf einem eingefrorenen Framework kann sich danach nur noch auf die Community stützen. Und Teams, die unternehmensweite Orchestrierung, Wechsel zwischen Modellanbietern und Interoperabilität über Laufzeiten hinweg brauchen, was der Hersteller ausdrücklich im Nachfolger verortet. Einfach gesagt: Was hier bleibt, ist ein brauchbarer Bestand und gutes Lehrmaterial, kein Startpunkt mit Zukunft.

Bei der Framework-Wahl ist die Funktionsliste nur die Eintrittskarte. Die eigentliche Trennung verläuft dort, ob man in drei Jahren noch im Supportfenster liegt.