OpenExecutive: ein Executive-Orchestrator mit acht Spezialagenten

Acht Rollen, eine Stimme: das Problem hinter dem Aufbau

Ein Unternehmen, das einen LLM-Assistenten für Finanzfragen, Vertragsprüfung und Personalthemen gleichzeitig einsetzt, bekommt ohne weitere Vorkehrung drei verschiedene Stimmen, drei Temperamente und drei widersprüchliche Empfehlungen. OpenExecutive setzt genau dort an. Das System gibt sich als ein einzelner Executive aus, der intern auf acht Spezialisten zurückgreift: Chief Strategy Officer, CFO, CHRO, General Counsel, COO, CMO, CPO und Board Communications Director. Die Aufteilung ist nicht kosmetisch. Der CFO bekommt ein anderes Modell als der CMO, und die interne Agentenarchitektur wird dem Nutzer laut README nie offengelegt.

Die Zielgruppe ist damit enger, als der Begriff virtuelle Führungsetage vermuten lässt. Angesprochen sind kleine Teams und Einzelgründer, die sich mehrere Fachperspektiven wünschen, aber keine acht getrennten Werkzeuge pflegen wollen. Für eine Organisation mit eigener Rechtsabteilung und eigenem Finanzcontrolling ist die Bündelung in einer Persona eher ein Nachteil, weil dort gerade die getrennte Zuständigkeit und die Nachvollziehbarkeit pro Rolle zählen.

Der Orchestrierungsweg vom Nutzertext zur Antwort

Das README zeigt den Datenfluss als Kette: Nutzernachricht, Executive Orchestrator auf Basis von claude-sonnet-5, dann Tool-Use mit parallelen Spezialistenaufrufen, dann eine synthetisierte Antwort. Jeder Spezialist holt sich seinen Kontext selbst aus ChromaDB, bevor er antwortet. Das ist der Kern: Die Spezialisten sind keine Unterhaltungen, sondern Werkzeugaufrufe, deren Ergebnisse der Orchestrator einsammelt und zu einer Antwort verdichtet.

Die Wissensbasis besteht aus zwei getrennten Ablagen. Die erste ist eingebautes MBA-Material als Markdown unter knowledge/builtin/, git-versioniert und beim Start in ChromaDB eingespielt. Die zweite ist eine Sammlung company_docs für hochgeladene Firmendokumente, gechunkt und separat gespeichert. Beide Ebenen werden pro Spezialistenaufruf abgefragt. Bemerkenswert ist, wohin der RAG-Kontext wandert: laut README in den User-Turn, nie in den gecachten System-Prompt. Das ist eine bewusste Entscheidung, weil dynamischer Inhalt einen Cache-Block ungültig machen würde.

Für die vier Rollen CSO, CFO, GC und Board sieht die Tabelle claude-opus-5 mit Extended Thinking vor. Das erhöht Latenz und Tokenkosten genau bei den Anfragen, die ohnehin am längsten dauern. Ob der Qualitätsgewinn das rechtfertigt, lässt sich aus dem Material nicht ableiten, das Repo liefert dazu keine Zahlen.

Episodisches Gedächtnis und der Preis dafür

Nach jeder Antwort läuft ein Hintergrunddurchgang mit claude-haiku-4-5, der Entscheidungen, Initiativen und Empfehlungen extrahiert und in SQLite ablegt. Die nächste Sitzung beginnt mit einem past_decisions-Block, sodass der Executive weiß, was er im Vormonat geraten hat. Das ist der Mechanismus, der aus einem Frage-Antwort-Werkzeug so etwas wie Kontinuität macht.

Der Haken liegt in der Extraktion. Ein kleineres Modell entscheidet, was als erinnerungswürdig gilt. Wird eine Empfehlung falsch zusammengefasst oder eine Bedingung weggelassen, taucht dieser Fehler in jeder Folgesitzung wieder auf, ohne dass der Nutzer ihn als Extraktionsfehler erkennt. Das README beschreibt keine Korrekturmöglichkeit für falsch gespeicherte Einträge. Wer das System produktiv nutzt, sollte sich überlegen, wie er an die SQLite-Datei herankommt, bevor falsche Einträge sich ansammeln.

Positiv fällt auf, dass der Speicher getrennt vom Vektorspeicher liegt. ChromaDB hält Dokumente, SQLite hält Entscheidungen. Zwei Speicher mit zwei Lebenszyklen bedeuten allerdings auch zwei Dinge, die gesichert und migriert werden müssen. Das Repo-Layout nennt für beide keinen Backup-Pfad.

Inbetriebnahme: was make dev tatsächlich auslöst

Der Einstieg ist knapp beschrieben. Nach dem Klonen wird .env.example nach .env kopiert, dort wird ANTHROPIC_API_KEY gesetzt, und für die Google-Anmeldung der Web-Oberfläche zusätzlich AUTH_SECRET, AUTH_GOOGLE_ID und AUTH_GOOGLE_SECRET. Danach startet make dev alles zusammen. Die API läuft auf Port 8000, die UI auf 3000.

Zwei Details sind leicht zu übersehen. Erstens liest nicht nur die API die Konfiguration aus dem Wurzelverzeichnis, sondern auch die UI, weil Auth.js diese Werte zur Laufzeit braucht. Eine packages/ui/.env.local wird zwar ebenfalls gelesen, aber bei Schlüsseln, die in beiden Dateien stehen, gewinnt die Wurzel-.env. Wer einen UI-Schlüssel dort einträgt und sich über die Wirkung wundert, sucht an der falschen Stelle.

Zweitens der erste Start. Er verlangt Python 3.11+ und Node 22+, zieht über uv sync ChromaDB sowie sentence-transformers mit PyTorch, und lädt beim ersten Boot ein Embedding-Modell von rund 90 MB herunter, um den lokalen Vektorindex aufzubauen. Das dauert laut README einige Minuten. Für CI-Umgebungen ist das der Punkt, an dem man einen vorbereiteten Cache einplanen muss, sonst zahlt jeder Lauf diese Wartezeit.

Wer make nicht verwendet, startet die API direkt aus packages/core mit uv sync, aktiviertem virtuellen Environment und uvicorn openexecutive.api.main:app --reload --port 8000, die UI separat mit npm install und npm run dev.

Der Scheduler als harte Betriebsgrenze

Der eingebaute Job-Runner beansprucht fällige Aktionen über UPDATE mit RETURNING, um Doppelausführung zu verhindern. Dieses Muster funktioniert innerhalb einer Datenbank, solange genau ein Prozess die Zeilen beansprucht. Das README zieht daraus eine ungewöhnlich direkte Konsequenz: Die API muss als einzelne Instanz laufen, und horizontales Skalieren ist untersagt, solange der Scheduler nicht zuvor abgesichert wurde.

Das ist die wichtigste Einschränkung im ganzen Projekt, und sie steht in einem Satz mitten in der Architekturbeschreibung. Wer später auf zwei API-Instanzen hinter einem Load Balancer geht, ohne den Scheduler zu trennen, bekommt doppelte Erinnerungen, doppelte Follow-ups und im schlimmsten Fall doppelte Aktionen. Der Hinweis auf ein optionales Honcho-Memory-Deployment in fly.honcho.toml deutet an, dass es Erweiterungspfade gibt. Ob einer davon den Scheduler entkoppelt, sagt das Material nicht.

Für den Betrieb heißt das: Verfügbarkeit lässt sich nicht durch zusätzliche Instanzen erhöhen. Ein Neustart der einen Instanz ist ein Ausfall des Dienstes. Das ist der Preis für einen Scheduler, der ohne verteilte Sperre auskommt, und es ist eine bewusste Vereinfachung, keine Nachlässigkeit.

Prompt-Caching und die Grenze der Wiederverwendung

Der System-Prompt ist so aufgeteilt, dass Persona, Firmenprofil und Wissensindex getrennt gecacht werden. Das README nennt bis zu 85 Prozent Cache-Trefferquote nach den ersten Umdrehungen. Diese Zahl stammt aus der Projektdokumentation, nicht aus einer unabhängigen Messung, und sie gilt nur, solange kein dynamischer Inhalt in einen gecachten Block gerät.

Genau diese Bedingung erklärt, warum der RAG-Kontext in den User-Turn wandert. Es ist keine Stilfrage, sondern eine Kostenentscheidung mit architektonischen Folgen. Sobald jemand später Firmendaten in den System-Prompt verschiebt, weil es bequemer erscheint, bricht die Trefferquote ein und die Kosten steigen, ohne dass ein Test das meldet.

Die Kehrseite betrifft Änderungen am Firmenprofil. Wird das Profil häufig angepasst, muss der zugehörige Cache-Block jedes Mal neu geschrieben werden. Das System ist auf Stabilität ausgelegt, nicht auf laufende Neukonfiguration. Wer das Onboarding-Verzeichnis packages/core/openexecutive/onboarding/ so erweitert, dass Nutzer ihr Profil ständig ändern, arbeitet gegen die Cache-Struktur.

Was OpenExecutive nicht ist

Der Vergleich mit einem reinen Chat-Frontend auf einem großen Modell zeigt den Unterschied am deutlichsten. Ein solches Frontend beantwortet eine Finanzfrage und eine Vertragsfrage mit demselben Prompt und demselben Wissensstand. OpenExecutive trennt beides: Der General Counsel bekommt seine eigene Wissensabfrage, der CFO eine andere, und beide Ergebnisse fließen in eine Antwort. Der Preis ist ein Orchestrierungsaufruf plus mehrere Spezialistenaufrufe plus zwei Abfragen pro Spezialist. Latenz und Tokenverbrauch pro Antwort liegen damit deutlich über einem einzelnen Modellaufruf.

Für schnelle Einzelfragen ist das die falsche Wahl. Wer nur eine Zusammenfassung eines Dokuments braucht, bezahlt hier für Routing, Retrieval und Synthese, ohne einen der acht Spezialisten zu benötigen. Auch für Aufgaben mit klarer Einzeldomäne, etwa eine reine Umsatzprognose, ist der Umweg über den Orchestrator unnötig.

Ein weiterer Punkt betrifft die Wissensbasis. Das eingebaute MBA-Material ist git-versioniert und damit für alle Installationen identisch. Es lässt sich anpassen, aber jede Anpassung ist eine Abweichung vom Upstream und muss bei jedem Pull neu zusammengeführt werden. Wer eigene Inhalte braucht, sollte sie als company_docs hochladen, nicht in knowledge/builtin/ ablegen.

Wartung, Abhängigkeiten und die Lizenzfrage

Der letzte Push liegt laut Repository-Metadaten im September 2026, Releases wurden keine abgerufen. Es gibt also keinen versionierten Stand, an dem man sich festhalten könnte. Wer das Projekt einsetzt, arbeitet gegen den main-Branch und trägt damit jede Änderung selbst mit. Das CI-Workflow ist vorhanden, sagt aber nichts über die Qualität der Abdeckung.

Die Abhängigkeitslast ist erheblich. PyTorch und sentence-transformers über uv sync bedeuten große Images und lange Builds. Für Docker-Betrieb lohnt ein Blick in docker/, bevor man die Standardkonfiguration übernimmt. Der Wechsel des Embedding-Modells ist kein Konfigurationsschritt, sondern ein Neuaufbau des Vektorindex, weil alle Vektoren neu berechnet werden müssen.

Zur Lizenz gibt es einen Widerspruch, der vor dem Einsatz geklärt werden sollte. Die Repository-Metadaten melden NOASSERTION, das README zeigt ein Apache-2.0-Badge und die Tech-Stack-Tabelle nennt Apache 2.0, und eine LICENSE-Datei existiert. Ob die Metadaten schlicht nicht gepflegt sind oder ob es einen Grund für die Abweichung gibt, lässt sich aus dem Material nicht entscheiden. Das ist keine Rechtsberatung, aber wer OpenExecutive in einem kommerziellen Produkt einsetzen will, sollte die LICENSE-Datei im Repository selbst öffnen, statt sich auf Badge oder Metadaten zu verlassen.

Redaktionelles Fazit

Wer eine einzelne, konsistente Antwortstimme über mehrere Fachdomänen braucht und die API als genau eine Instanz betreiben kann, findet hier eine nachvollziehbare Struktur. Wer horizontale Skalierung oder Mandantenfähigkeit einplant, sollte zuerst den Scheduler-Pfad in packages/core/openexecutive/scheduler/ lesen, bevor irgendetwas deployt wird. Und wer die Lizenz prüfen muss, klärt zuerst, warum die Repository-Metadaten NOASSERTION melden, während das README Apache 2.0 beansprucht.

Offizielle Quellen

1. Issues
2. Project website
3. README
4. SenteLabsAI/OpenExecutive on GitHub