Agentlas OS: Spezialagenten im Hub, ein temporärer Orchestrator pro Aufgabe

Welches Problem der Hub-Orchestrator-Schnitt adressiert

Die meisten Multi-Agenten-Setups kranken an derselben Stelle. Ein fest verdrahtetes Team aus Rollen wird für jede Aufgabe hochgefahren, obwohl nur zwei oder drei Rollen tatsächlich gebraucht werden. Die übrigen Kontexte kosten Tokens, erzeugen Rauschen und machen das Ergebnis schwerer nachvollziehbar. Agentlas OS zieht die Grenze anders: Spezialisten liegen dauerhaft in einem Hub, und für eine konkrete Aufgabe entsteht ein temporärer Orchestrator, der nur die benötigten Spezialisten heranzieht. Das README beschreibt den Ablauf als Klassifikation der Anfrage, Interview- und Recherche-Gate, Paketgenerierung und anschließende Verifikation. Zielgruppe sind nach der Selbstbeschreibung Nutzer, die Agenten nicht als Programm, sondern als Asset behandeln wollen, also als etwas, das nach der Erstellung weiter existiert und nicht an einen bestimmten Modell-Workspace gebunden ist. Wer Agenten nur einmalig für eine Chat-Sitzung braucht, gewinnt durch dieses Modell wenig.

Wie ein Agentenpaket entsteht und wo es landet

Der Erstellungsweg ist als Pipeline dokumentiert, nicht als freies Prompting. Eine natürlichsprachliche Beschreibung wird klassifiziert, danach folgen ein Interview und ein Recherche-Gate, erst dann wird das Paket generiert und verifiziert. Am Ende steht laut README eine explizite Frage: nur auf diesem Rechner behalten oder privat in der Agent Cloud speichern, um es auf einem anderen angemeldeten Desktop wiederherzustellen. Das ist der eigentliche architektonische Kern. Das Paket ist die Einheit, die wandert, nicht die Sitzung. Die Agent Cloud ist dabei als besitzerspezifisch beschrieben, also an ein Konto gebunden. Wer diesen Schritt überspringt, bleibt lokal. Der Preis für die Portabilität ist ein Konto bei einem externen Dienst, und das ist eine Entscheidung, die vor dem ersten Speichern getroffen werden sollte, nicht danach.

Modellwahl als Konfigurationsfrage, nicht als Produktentscheidung

Die README nennt eine breite Host-Liste: Claude Code, Codex, Gemini, Antigravity, Cursor, DeepSeek, GLM und Ollama. Das Muster ist erkennbar. Agentlas OS bringt kein eigenes Modell mit, sondern setzt auf die Hosts, die der Nutzer ohnehin verwendet. Hephaestus wird als die Open-Source-Engine darunter bezeichnet. Für Teams bedeutet das, dass die Modellwahl nicht mit dem Agentenpaket verheiratet ist. Ein Spezialist, der gegen ein lokales Ollama-Modell läuft, kann auf einem anderen Host mit einem anderen Anbieter gestartet werden, ohne neu gebaut zu werden. Diese Entkopplung ist der praktischste Teil des Designs. Sie hat aber eine Grenze: Die Qualität eines Agenten hängt dann an dem Host, in dem er gerade läuft, und die README liefert keine Aussage darüber, wie sich Verhalten zwischen Hosts unterscheidet.

Installation über ein Skript mit explizitem Vertrauensschritt

Der Installationsweg ist ungewöhnlich gestaltet: Das README liefert einen Prompt-Block, der an das gerade verwendete LLM gerichtet ist. Das Modell soll zuerst das Installationsskript unter https://raw.githubusercontent.com/agentlas-ai/Agentlas-OS/main/scripts/install-all-runtimes.sh abrufen und lesen, dann ausführen. Der direkte Shell-Befehl lautet curl -fsSL https://raw.githubusercontent.com/agentlas-ai/Agentlas-OS/main/scripts/install-all-runtimes.sh | HEPHAESTUS_INSTALL_GLOBAL_ROUTER=1 bash. Laut README schreibt das Skript Dateien ausschließlich unter ~/.agentlas, ~/.local/bin und in die Plugin- bzw. Command-Adapter-Verzeichnisse des jeweiligen Hosts, beispielsweise ~/.claude für Claude Code. Die Umgebungsvariable HEPHAESTUS_INSTALL_GLOBAL_ROUTER=1 setzt zusätzlich einen Routing-Block in die globale Instruktionsdatei des Hosts, etwa ~/.claude/CLAUDE.md. Das ist der Punkt, an dem ich am deutlichsten widerspreche: Ein globaler Routing-Block verändert das Verhalten jedes künftigen Tasks in diesem Host, nicht nur der Agentlas-Aufrufe. Wer das nicht will, lässt die Variable weg und ergänzt sie später über hephaestus global install. Nach der Installation verlangt der Prompt-Block ausdrücklich die Verifikationsausgabe des Installers und eine klare Aussage, ob /agentlas build einsatzbereit ist oder ob der Host neu gestartet werden muss.

Grenzen: was die Materialbasis nicht hergibt

Die Release-Kadenz ist auffällig. Drei Versionen innerhalb von rund 25 Stunden, v1.2.42, v1.2.43 und v1.2.44. Für Nutzer heißt das, dass die Versionsnummer kein Stabilitätsversprechen ist. Wer Agentenpakete in einer Produktionspipeline einsetzt, sollte Releases pinnen und nicht dem latest-Tag folgen. Ein zweiter Punkt betrifft die Dokumentationslage. Das README ist stark auf Einstieg und Desktop-Erlebnis ausgerichtet, mit Bildmaterial und Installationsanleitungen für Windows und macOS. Es beschreibt dagegen nicht, wie der temporäre Orchestrator intern Spezialisten auswählt, wie Fehler in einem Spezialisten weitergereicht werden oder was passiert, wenn ein Hub-Agent nach einem Modellwechsel nicht mehr dasselbe Ergebnis liefert. Auch zur Lizenz steht nur die Kennung Apache-2.0, ohne Hinweis darauf, ob die Agent Cloud oder der Hub eigenen Bedingungen unterliegen. Das ist die offene Flanke des Projekts. Wer die Orchestrierung als Black Box akzeptiert, kommt durch. Wer sie auditieren muss, findet im vorliegenden Material keine Grundlage.

Alternative: CrewAI und der Unterschied im Ansatz

Der naheliegende Vergleich ist CrewAI. Dort definiert man Agenten und Tasks im Code, weist Rollen und Ziele zu und startet die Crew als zusammenhängende Ausführung. Die Zusammensetzung ist damit ein Artefakt im Repository, versionierbar und im Code-Review sichtbar. Agentlas OS dreht das um: Die Zusammensetzung entsteht zur Laufzeit aus der Aufgabenbeschreibung, und der Orchestrator ist nicht das, was man versioniert. Man versioniert die Spezialisten im Hub. Für reproduzierbare Pipelines ist CrewAI der passendere Weg, weil die Teamstruktur explizit im Code steht. Für eine Werkbank, in der sich Aufgaben täglich ändern und Spezialisten über Monate wiederverwendet werden, ist das Agentlas-Modell die passendere Form. Der Unterschied liegt nicht in der Fähigkeit der Agenten, sondern darin, welches Artefakt man unter Versionskontrolle hält.

Wartung, Upgrades und die Lizenzfrage

Upgrades laufen über die GitHub Releases des Repositorys, aus denen das Installationsskript laut README ein Tarball bezieht. Daraus folgt eine konkrete Wartungspflicht: Wer install-all-runtimes.sh einmal ausgeführt hat, hat keinen automatischen Update-Pfad beschrieben bekommen. Das Skript muss erneut ausgeführt werden, und der globale Routing-Block in der Host-Instruktionsdatei muss danach erneut geprüft werden, weil er bei jedem Lauf neu geschrieben wird. Das ist ein manueller Schritt pro Upgrade, kein Hintergrunddienst. Bei der Lizenz ist die Lage teilweise klar: Der Code steht unter Apache-2.0, was kommerzielle Nutzung und Modifikation erlaubt, solange Lizenz- und Urheberrechtshinweise erhalten bleiben und geänderte Dateien gekennzeichnet werden. Unklar bleibt, ob für Agent Cloud und den öffentlichen Hub zusätzliche Nutzungsbedingungen gelten. Das README benennt dazu nichts. Wer Agentenpakete in einem kommerziellen Produkt weitergeben will, sollte diesen Punkt vor dem Speichern in der Cloud klären, nicht danach. Rechtsberatung ersetzt das nicht.

Redaktionelles Fazit

Wer viele wiederkehrende Spezialaufgaben hat und die Agentenpakete selbst besitzen will, findet hier ein nachvollziehbares Modell: Spezialisten bleiben im Hub, der Orchestrator ist Wegwerfware. Wer keine Konten bei einem Cloud-Dienst anlegen darf oder eine stabile, eingefrorene API für Produktionspipelines braucht, sollte zuerst prüfen, ob der lokale Modus ohne Agent Cloud ausreicht. Vor dem Rollout: install-all-runtimes.sh lesen, die Pfade ~/.agentlas, ~/.local/bin und das Host-Plugin-Verzeichnis gegen die eigene Policy abgleichen und mit HEPHAESTUS_INSTALL_GLOBAL_ROUTER=0 beginnen.

Offizielle Quellen

1. agentlas-ai/Agentlas-OS on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases