holaOS: ein Electron-Workspace, in dem Agent und App nebeneinander laufen

Welches Problem holaOS adressiert und für wen es gedacht ist

Der Ausgangspunkt ist eine Beobachtung über Arbeitskontext. Entscheidungen fallen in Slack-Threads, Feishu-Gruppen oder DingTalk-Nachrichten und bleiben dort. Die README formuliert das so, dass Arbeitskontext selten in einem Dokument landet. Ein Agent, der nur auf Dateien und Prompts zugreift, arbeitet deshalb an einer Zusammenfassung statt am Original. holaOS setzt an dieser Stelle an und verbindet die Chat-Werkzeuge, die ein Team ohnehin benutzt, mit dem Agenten.

Die zweite Zielgruppe sind Teams, die bereits einen Agenten einsetzen und ihn nicht aufgeben wollen. Die README nennt Claude Code, Codex und einen eigenen holaOS-Agenten, die im selben Workspace über dieselben Werkzeuge, Dateien und Erinnerungen laufen sollen. Das ist ein Integrationsversprechen, kein Modellversprechen. Wer heute zwei Agenten mit getrennten Konfigurationen, getrennten Zugangsdaten und getrenntem Kontext betreibt, kennt den Aufwand, den diese Aussage adressiert.

Die dritte Gruppe sind Unternehmen, die aus Compliance-Gründen keine Daten in eine fremde Cloud geben wollen. Die README wiederholt an mehreren Stellen, dass alles lokal läuft und die Daten die eigenen Rechner nicht verlassen. Das ist die zentrale Zusage des Projekts und gleichzeitig die Angabe, die man vor einer Adoption selbst nachprüfen muss, weil sie sich aus einer README nicht belegen lässt.

HolaApps: der Agent bedient eine Oberfläche statt eines Chats

Das architektonisch interessanteste Element ist die HolaApp. Die README beschreibt sie als echte, interaktive Oberfläche neben dem Agenten, nicht als Transkript. Eine HolaApp lässt sich laut README auf eine beliebige URL und einen MCP-Server zeigen. Damit ist die App keine Neuentwicklung, sondern eine Einbettung: Die bestehende Weboberfläche eines Systems wird zur Fläche, auf der der Agent arbeitet.

Der Kontextfluss ist beidseitig. Wer die App von Hand bedient, erzeugt laut README Kontext, den der Agent bereits hat. Das ist der eigentliche Mechanismus hinter dem Versprechen, dass man nicht erklären muss, was man gerade getan hat. Ein Agent, der nur einen Screenshot sieht, kann diesen Zustand nicht rekonstruieren. Wenn die Beschreibung zutrifft, wird hier der UI-Zustand selbst zur Eingabe.

Das Modell hat eine klare Grenze. Es setzt voraus, dass die Zielsysteme eine einbettbare Weboberfläche haben und dass diese Oberfläche stabil genug ist, um von einem Agenten bedient zu werden. Für Systeme ohne Weboberfläche oder mit starkem Schutz gegen Automatisierung trägt der Ansatz nicht. Die README geht auf diesen Fall nicht ein.

MCP, Skills und Combos als Erweiterungspfad

holaOS erweitert sich über drei getrennte Konstrukte. MCP-Server liefern neue Werkzeuge, wobei die README sowohl eigene Server als auch Community-Server mit einem Klick nennt. Skills paketieren einen Workflow einmalig, danach kann jeder Agent ihn ausführen. Combos bündeln Skills und Integrationen zu einer einzigen Installation.

Die Trennung ist praktisch relevant. Ein Skill beschreibt eine Prozedur, eine Integration beschreibt einen Zugang, und ein MCP-Server beschreibt eine Werkzeugschnittstelle. Wer diese drei Ebenen vermischt, bekommt ein Bündel, das sich nicht mehr einzeln aktualisieren lässt. Die README behandelt Combos als Installationskomfort, nicht als Versionierungseinheit. Ob eine Combo aktualisiert werden kann, ohne die enthaltenen Skills zu überschreiben, geht aus dem Material nicht hervor.

Für Integrationen nennt die README Gmail, Notion, Slack, GitHub und Linear sowie 50+ weitere, verbunden über OAuth mit einem Klick. An einer anderen Stelle des Repository-Materials ist von 100+ Integrationen die Rede. Diese beiden Zahlen stehen unverbunden nebeneinander. Wer die Abdeckung für ein konkretes System prüfen will, muss die Integrationsliste selbst durchsehen, weil die README keine vollständige Aufstellung liefert.

Modelle und Agenten als austauschbare Schichten

holaOS behandelt Modell und Agent als zwei unabhängige Entscheidungen. Bei den Modellen nennt die README einen Standardzugang ohne eigene Schlüssel sowie die Möglichkeit, eigene Schlüssel für OpenAI, Anthropic oder kompatible Endpunkte zu hinterlegen. Die Schlüssel laufen dann laut README über das eigene Konto und nicht über den holaOS-Tarif.

Bei den Agenten ist die Aussage deutlicher: Claude Code, Codex und der eigene Agent teilen sich Erinnerung, Werkzeuge, Skills und Apps. Das ist eine Architekturaussage, die sich in der Praxis bewähren muss. Ein gemeinsamer Speicher über mehrere Agenten hinweg ist nur dann nützlich, wenn die Agenten dieselben Konventionen für Werkzeugaufrufe und Kontextfenster akzeptieren. Die README beschreibt das Ergebnis, nicht den Mechanismus, der die Unterschiede zwischen den Agenten ausgleicht.

Bemerkenswert ist, was die README nicht beschreibt. Es gibt keine Angabe dazu, wie Erinnerungen zwischen Agenten aufgelöst werden, wenn zwei Agenten widersprüchliche Einträge erzeugen. Für einen einzelnen Agenten ist das ein Randfall. Für den beworbenen Betrieb mit mehreren Agenten im selben Workspace ist es die zentrale offene Frage.

Installation und Betrieb: was die README tatsächlich hergibt

Die README verlinkt einen Abschnitt Quick Start, gibt aber im vorliegenden Text keine Installationsbefehle wieder. Das Repository-Material enthält damit keine belegbare Kommandozeile, mit der man holaOS aufsetzen könnte. Wer die Anleitung braucht, muss die Dokumentationsseite unter holaos.ai/docs/getting-started aufrufen, auf die die README verweist.

Gesichert ist die Plattformangabe aus den Badges: macOS auf Apple Silicon und Intel, Windows und Linux. Der Desktop-Client basiert auf Electron, die Laufzeit auf TypeScript. Ein CI-Workflow ist über ein Badge verlinkt, sein Inhalt ist im Material nicht sichtbar.

Für die Konfiguration nennt die README genau eine Regel, nämlich dass Zugriff pro Werkzeug und pro Scope erteilt wird und der Agent nichts liest, bevor man es freigibt. Konkrete Konfigurationsschlüssel oder Dateipfade tauchen nicht auf. Das ist eine dünne Betriebsdokumentation für ein Werkzeug, das Zugriff auf Chat-Verläufe, Dateien und Unternehmenssysteme erhält. Wer holaOS einführt, sollte damit rechnen, die Berechtigungsmodelle aus der Produktoberfläche heraus zu erarbeiten statt aus der README.

Lizenz und Wartung: die zwei offenen Punkte

Die Lizenzangabe des Repositories lautet NOASSERTION. Die README zeigt ein Badge mit der Bezeichnung Modified Apache 2.0. Das sind zwei verschiedene Aussagen. NOASSERTION bedeutet, dass die automatische Erkennung keine standardisierte Lizenz identifizieren konnte. Eine modifizierte Apache-2.0-Lizenz kann Bedingungen enthalten, die von der Standardlizenz abweichen. Welche das sind, steht nicht im vorliegenden Material. Wer holaOS kommerziell einsetzen oder weiterverbreiten will, muss die LICENSE-Datei im Repository selbst lesen und im Zweifel rechtlichen Rat einholen. Eine Einordnung als Open Source lässt sich aus diesen Angaben nicht ableiten.

Zur Wartung gibt das Material wenig her. Der letzte Push liegt datiert auf August 2026, das Release mit der Bezeichnung latest auf Anfang August 2026. Beide Angaben stammen aus den Repository-Metadaten und sagen nichts über Release-Kadenz oder Unterstützungszeiträume. Die README enthält keine Aussage zu Upgradepfaden, zu Datenmigration zwischen Versionen oder dazu, was bei einem Major-Upgrade mit dem lokalen Speicher geschieht.

Das ist bei einem Werkzeug mit lokalem Datenbestand der wichtigste fehlende Abschnitt. Wer Erinnerungen, Skills und Integrationszugänge über Monate aufbaut, braucht eine Aussage darüber, wie dieser Bestand ein Upgrade übersteht. Die README liefert sie nicht.

Wo holaOS das falsche Werkzeug ist

Der deutlichste Fehlfall ist der Server. holaOS ist als Electron-Desktop-Anwendung beschrieben, mit Builds für macOS, Windows und Linux. Für einen headless Dienst, der in einer Pipeline oder auf einer geteilten Maschine läuft, ist das die falsche Bauform. Ein Team, das Agenten in CI-Jobs oder als Backend-Prozess betreiben will, braucht eine Laufzeit ohne grafische Oberfläche. Die README beschreibt keine solche.

Der zweite Fehlfall ist die Erwartung an fertige Integrationen. Die README verspricht Verbindungen zu Gmail, Notion, Slack, GitHub und Linear sowie weiteren Systemen, ohne die vollständige Liste zu nennen. Wer ein Nischenwerkzeug anbinden muss, kann nicht vorab einschätzen, ob es abgedeckt ist. Der Ausweg über MCP existiert, verlangt aber, einen Server selbst bereitzustellen oder einen Community-Server zu prüfen, dessen Herkunft und Wartung man nicht kennt.

Der dritte Fehlfall ist die Annahme, lokale Ausführung sei gleichbedeutend mit Kontrolle. Auch ein lokaler Client sendet Anfragen an Modellanbieter, sobald ein gehostetes Modell verwendet wird. Die README unterscheidet hier nicht zwischen dem Standardzugang über ein holaOS-Konto und dem Betrieb mit eigenen Schlüsseln. Wer die Datenhoheit als Auswahlkriterium heranzieht, muss diesen Unterschied selbst klären.

Alternative: ein Agent-Harness im Terminal statt eines Workspace

Die naheliegende Alternative ist der direkte Betrieb eines Agenten über seine Kommandozeilenschnittstelle, also Claude Code oder Codex ohne holaOS dazwischen. Der Unterschied liegt nicht in der Modellqualität, sondern im Ort der Integration. Ein Terminal-Agent arbeitet in einem Verzeichnis, liest Dateien und führt Befehle aus. Er hat keine eingebettete Weboberfläche, keinen Marktplatz und keine gemeinsame Erinnerungsschicht über mehrere Agenten hinweg.

Dafür hat er Eigenschaften, die holaOS laut eigener Beschreibung nicht bietet. Er läuft auf einem Server, lässt sich in Skripte einbetten und ist reproduzierbar konfigurierbar. Für Entwickler, deren Arbeitskontext ohnehin im Repository liegt, ist der Terminal-Agent die schlankere Wahl. Der Kontext, den holaOS aus Slack oder Feishu holt, existiert in diesem Arbeitsmodell schlicht nicht.

Die Entscheidung hängt damit an einer einzigen Frage: Liegt der Kontext, aus dem gearbeitet wird, überwiegend in Chat-Werkzeugen und Weboberflächen oder überwiegend im Dateisystem. Für den ersten Fall ist der Workspace-Ansatz von holaOS begründet. Für den zweiten Fall fügt er eine Oberfläche hinzu, die man bezahlen und pflegen muss, ohne dass sie etwas abdeckt, was der Terminal-Agent nicht schon tut.

Redaktionelles Fazit

Sinnvoll ist holaOS für Teams, die einen lokalen Desktop-Workspace wollen, in dem Agent und App-Oberfläche gleichzeitig sichtbar sind, und die bereit sind, ihre Arbeitsweise um dieses Modell herum zu bauen. Wer einen headless Dienst für Server oder CI braucht, ist hier falsch, weil das Projekt ausdrücklich als Electron-Desktop-Anwendung für macOS, Windows und Linux beschrieben wird. Vor einer Adoption zuerst die LICENSE-Datei lesen, weil die Repository-Angabe NOASSERTION lautet und die README nur von einer Modified Apache 2.0 License spricht, ohne den geänderten Text wiederzugeben. Danach die Integrationsliste gegen die eigenen Systeme abgleichen, denn die README nennt 50+ Integrationen an einer Stelle und 100+ im Repository-Beschreibungstext.

Offizielle Quellen

1. holaboss-ai/holaOS on GitHub
2. Issues
3. Project website
4. README
5. Releases