OpenAgents: eine Workspace-URL für Agenten, die auf verschiedenen Maschinen laufen

Das Problem: Agenten ohne gemeinsamen Ort

Das README beschreibt die Ausgangslage sehr konkret. Ein Agent pflegt eine Datenbank auf einem Server, ein zweiter beantwortet Nutzeranfragen auf Discord, weitere bauen in getrennten Terminals auf getrennten Maschinen an verschiedenen Projekten. Es gibt keine einzelne Ansicht, und es gibt keinen Mechanismus, der diese Agenten zusammenbringt. Das Beispiel im README ist ein Bugreport: Der Marketing-Bot soll die Details beim Nutzer einsammeln, danach soll der Infra-Agent in dieselbe Unterhaltung geholt werden, um Logs zu prüfen. Ohne gemeinsamen Kontext bleibt Copy-Paste zwischen Terminals und SSH-Sitzungen. Genau diese Lücke adressiert das Projekt mit zwei Bausteinen: einer einheitlichen Workspace-URL, unter der jeder Agent erscheint, unabhängig davon, wo er läuft, und einem gemeinsamen Satz von Threads, Dateien und Browser-Sitzung für alle Beteiligten. Zielgruppe sind damit Personen, die bereits mehrere Coding-Agenten parallel betreiben und den Überblick verloren haben, nicht Einsteiger mit einem einzigen Agenten in einem Terminal.

Workspace als persistenter Hub, nicht als Orchestrierungsschicht

Das README vergleicht den Workspace mit Slack, nur für Agenten. Diese Analogie beschreibt den Mechanismus recht genau: Ein Workspace ist ein persistenter Hub unter einer URL der Form workspace.openagents.org/abc123, die man bookmarken und teilen kann. Angeschlossene Agenten teilen sich dieselben Threads, dieselben Dateien und denselben Browser. Der Browser ist dabei kein Nebeneffekt, sondern eine geteilte Ressource: Agenten können Seiten öffnen, Elemente anklicken, Screenshots aufnehmen und Formulare ausfüllen, und alle im Workspace sehen das. Dasselbe gilt für Dateien, die ein Agent hochlädt und die jeder andere Agent oder Mensch lesen, bearbeiten oder herunterladen kann. Wichtig ist die Abgrenzung: Das ist eine Koordinations- und Sichtbarkeitsschicht, keine deterministische Orchestrierung mit festen Abhängigkeitsgraphen. Die Koordination läuft laut README über @mentions oder dadurch, dass Agenten Arbeit selbst aufgreifen. Wer einen Workflow braucht, bei dem Schritt B garantiert erst nach Schritt A startet, findet hier kein dafür gebautes Primitiv.

Installation über curl, irm oder Desktop-Binary

Der Einstieg läuft über den Launcher, ein Kommandozeilenwerkzeug namens agn. Unter macOS und Linux installiert man ihn mit curl -fsSL https://openagents.org/install.sh | bash, unter Windows mit irm https://openagents.org/install.ps1 | iex. Alternativ gibt es fertige Desktop-Binaries für macOS, Windows und Linux-AppImage über die Release-Seite. Der typische Ablauf nach der Installation sieht so aus: agn create <name> --type <type> --install legt einen Agenten an und installiert in einem Schritt die Laufzeit, agn env <type> --set LLM_API_KEY=sk-... hinterlegt Zugangsdaten, agn connect <name> <workspace-token> hängt den Agenten in einen Workspace ein, agn up startet den Daemon, der die Agenten im Hintergrund am Laufen hält, und ein bloßes agn öffnet das interaktive Dashboard. Eine Feinheit, die das README ausdrücklich hervorhebt: agn create allein schreibt nur die Agenten-Konfiguration. Wer die Laufzeit nicht separat mit agn install <type> nachzieht, muss beim Anlegen --install mitgeben. Diese Trennung ist sinnvoll, weil sie Konfiguration und Installation entkoppelt, aber sie ist auch eine Stolperfalle für alle, die den Befehl ohne Flag aus der Erinnerung tippen.

Unterstützte Agenten und ihre sehr unterschiedlichen Reifegrade

Die Tabelle im README listet eine breite Auswahl: OpenClaw, Claude Code, Codex CLI, Hermes Agent, Cursor, OpenCode, GitHub Copilot CLI, Gemini CLI, Cline (Beta), Amp, DeepSeek Harness (Preview), Aider (Beta) und Goose (Beta). Die Spannweite ist der wichtigste Punkt dieser Liste. Ein Teil gilt als unterstützt, ein Teil trägt Beta- oder Preview-Kennzeichnung mit entsprechenden Einschränkungen. Bei Aider formuliert das README die Grenze ungewöhnlich offen: Die vollständige Offline-Testsuite (Provider-Auflösung, Sessions, Git-Sicherheit, Installationserkennung) läuft durch, aber ein echter End-to-End-Lauf gegen einen Live-Modell-Provider wurde noch nicht abgeschlossen. Der Create/Connect-Flow sei verfügbar, damit man diese Verifikation selbst durchführen kann. Das ist eine ehrliche Angabe und zugleich ein Hinweis darauf, dass die Qualität der Integrationen nicht einheitlich ist. Wer Aider oder Goose produktiv einsetzen will, übernimmt einen Teil der Abnahme selbst.

Tunnels und der geteilte Browser als eigentliche Arbeitserleichterung

Zwei Funktionen stechen aus der Feature-Liste heraus, weil sie konkrete manuelle Arbeit ersetzen. Erstens der Tunnel: Ein lokaler Dev-Server lässt sich laut README mit einem Befehl als öffentliche URL exponieren, sodass man das Ergebnis eines Agenten von jedem Gerät aus ansehen kann. Zweitens der geteilte Browser, der zusammen mit den geteilten Dateien dafür sorgt, dass ein Agent nicht nur Text in einen Thread schreibt, sondern einen nachvollziehbaren Zustand hinterlässt. In der Praxis ist das der Unterschied zwischen einer Chat-Ansicht und einem Arbeitsbereich. Der Preis dafür ist Vertrauen: Wer einem Agenten Zugriff auf einen Browser gibt, den alle im Workspace sehen, und wer einen lokalen Server über einen Tunnel öffentlich erreichbar macht, muss diese Entscheidungen bewusst treffen. Das README beschreibt die Mechanismen, es beschreibt keine Zugriffsbeschränkungen oder Isolationsgrenzen zwischen Agenten innerhalb eines Workspace. Wer mehrere Agenten mit unterschiedlichen Berechtigungen betreiben will, findet in dem Material keine Aussage darüber, ob das vorgesehen ist.

Wo OpenAgents das falsche Werkzeug ist

Ein Workspace mit geteiltem Kontext ist dann die falsche Wahl, wenn Agenten sich gegenseitig nicht sehen sollen. Das gesamte Modell beruht darauf, dass Threads, Dateien und Browser für alle im Workspace sichtbar sind. Für Aufgaben mit getrennten Berechtigungsdomänen, etwa ein Agent mit Zugriff auf Produktionsdatenbanken und ein zweiter mit Zugriff auf Marketing-Kanäle, liefert das README keine Trennung. Auch für reproduzierbare Pipelines ist das Projekt nicht gedacht: Es gibt keine im Material beschriebene Möglichkeit, Abläufe zu versionieren oder Schritte deterministisch zu erzwingen. Und für Einzelanwender mit genau einem Agenten in einem Terminal ist der Aufwand, einen Launcher, einen Daemon und einen Workspace-Token zu verwalten, größer als der Nutzen, weil es nichts zu koordinieren gibt. Die Unterstützung für Aider und Goose ist zudem ausdrücklich als Beta markiert, mit offenem End-to-End-Test.

Alternative: ein einzelner Agent mit lokaler Sitzung

Der naheliegende Vergleich ist der direkte Weg: Claude Code, Codex CLI oder Gemini CLI ohne Launcher starten und die Sitzung lokal im Terminal führen. Der Unterschied liegt nicht in der Fähigkeit der Agenten, sondern im Ort des Zustands. Ohne OpenAgents lebt der Kontext in der lokalen Sitzung und in Dateien auf genau dieser Maschine. Es gibt keine URL, die man vom Telefon aus öffnet, keinen geteilten Browser, den ein zweiter Agent mitbenutzt, und keinen Thread, in den ein dritter Agent später einsteigt. Dafür entfällt jede Vermittlungsschicht: keine Workspace-Token, kein Daemon, keine Verbindung nach außen. Wer nur einen Agenten auf einer Maschine betreibt und dessen Terminalverlauf als Kontext ausreicht, fährt mit dem direkten Aufruf einfacher. OpenAgents lohnt sich ab dem Punkt, an dem der Kontext zwischen Maschinen oder zwischen mehreren Agenten wandern muss.

Wartung, Release-Takt und Lizenz

Die letzten Releases tragen Versionsnummern wie launcher-v0.9.27, launcher-v0.9.26 und launcher-v0.9.25, veröffentlicht im Abstand von Tagen bis Wochen im August und September 2026. Der Launcher wird also aktiv gepflegt, und das Versionsschema ist noch vor 1.0. Wer den Launcher einsetzt, sollte mit häufigen Updates rechnen und damit, dass sich CLI-Verhalten zwischen Minor-Versionen ändern kann. Das Projekt steht unter Apache-2.0, was kommerzielle Nutzung, Änderung und Weitergabe erlaubt und eine ausdrückliche Patentlizenz enthält. Das README bewirbt die Lizenz mit den Worten no vendor lock-in und no mandatory accounts. Zu beachten ist, dass die Lizenz das Repository betrifft, nicht die Agenten, die man anschließend anschließt: Claude Code, Codex CLI, Cursor und die übrigen Werkzeuge haben eigene Bedingungen und eigene Kosten. OpenAgents selbst verlangt laut README kein Konto, aber der Workspace läuft über openagents.org, und das Material sagt nichts darüber aus, wie ein Workspace ohne diesen Dienst betrieben wird. Wer Datenhoheit braucht, muss diese Frage vor der Adoption klären.

Redaktionelles Fazit

Wer mehrere Agenten auf verschiedenen Rechnern betreibt und einen gemeinsamen Kontext braucht, findet hier ein passendes Modell. Wer reproduzierbare, getestete Agenten-Anbindungen benötigt, sollte zuerst den Status der gewünschten Integration in der Tabelle prüfen. Vor dem Produktiveinsatz ist ein Testlauf mit einem Agenten im Beta-Status sinnvoll, weil das Projekt selbst angibt, dass ein echter End-to-End-Lauf gegen einen Live-Provider noch aussteht.

Offizielle Quellen

1. License: Apache-2.0
2. openagents-org/openagents on GitHub
3. Project website
4. README
5. Releases