Hexabot v3: Workflows, Actions und MCP in einer TypeScript-Laufzeit
Hexabot v3 is an AI workflow automation platform, combining workflows, actions, agents, and conversational channels in one runtime.
Auf einen Blick
- Was ist das?
- Hexabot v3 bündelt YAML-Workflows, schema-validierte Actions, MCP-Anbindung und mehrere Gesprächskanäle in einer Laufzeit. Das Repository liefert dazu ein CLI, TypeORM als Datenschicht und zwei Datenbankpfade. Wer das Projekt einsetzen will, muss vor allem zwei Dinge prüfen: die Lizenz FCL-1.0-ALv2 und die Node-Version.
- Für wen ist es gedacht?
- Für Teams, die Gesprächskanäle und agentische Abläufe in einer selbst gehosteten TypeScript-Laufzeit zusammenführen wollen und Node 24 sowie die Lizenz FCL-1.0-ALv2 akzeptieren, ist Hexabot v3 einen Testlauf wert. Wer eine reine Python-LLM-Kette braucht oder keine Ressourcen für ein monorepo-basiertes Upgrade hat, sollte Abstand nehmen.
- Darf ich es kommerziell nutzen?
- Erst prüfen. Die Lizenz dieses Repositorys ordnen wir nicht automatisch ein; lesen Sie vor jeder kommerziellen Nutzung die LICENSE-Datei.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 23 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich TypeScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem Hexabot v3 adressiert und für wen
Viele Teams bauen Chatbots und Automatisierungen als Sammlung von Skripten: ein Webhook hier, ein Prompt dort, dazu ein eigener Speicher für den Gesprächsverlauf. Hexabot v3 setzt dagegen auf eine einzige Laufzeit, in der Workflows, Actions und Kanäle zusammen definiert werden. Die README beschreibt das als Plattform mit erstklassigen AI-Fähigkeiten, in der Workflows, Actions und konversationelle Kanäle in einer Runtime zusammenlaufen.
Die Zielgruppe lässt sich aus dem Repository-Aufbau ablesen. Der Quick Start richtet sich an Projekte, die mit dem CLI erzeugt wurden, also an Anwender und nicht an Mitwirkende am Monorepo. Der Kontributionspfad verlangt dagegen ausdrücklich PNPM und verweist auf CONTRIBUTING.md mit Architektur, Paketkarte, PNPM-Workspace, Turbo-Tasks und CI-Prüfungen. Wer also nur Anwendungen bauen will, nutzt das CLI; wer am Kern arbeitet, braucht den Workspace.
Die Themenliste des Repositories nennt unter anderem agent, agentic, chatbot, bot-framework, llm und workflow. Das deckt sowohl klassische Bot-Frameworks als auch die aktuelle Agentenwelle ab. Wer eine reine Prompt-Bibliothek sucht, ist hier falsch; wer dagegen Kanäle, Werkzeuge und Speicher in einem Modell zusammenhalten will, findet dafür eine Struktur.
Wie die Laufzeit aufgebaut ist: YAML, Actions, Bindings, Memory
Der Kern liegt in vier Bausteinen. Erstens die Workflows: laut README YAML-Definitionen mit typisierten Laufzeitverträgen. Zweitens die Actions, die das Verhalten eines Workflows festlegen und deren Ein- und Ausgaben sowie Einstellungen schema-validiert sind. Drittens ein Binding-System, das wiederverwendbare Fähigkeits- und Konfigurationsbindungen von der Aufgabenlogik trennt. Viertens Memory, das explizit definiert und zur Laufzeit eingebunden wird.
Für die Validierung setzt das Projekt breit auf Zod. Die README nennt das eine schema-first architecture mit gemeinsamen Verträgen. Das ist mehr als ein Implementierungsdetail: Wenn Actions ihre Ein- und Ausgaben über Schemas beschreiben, verschiebt sich die Fehlerprüfung von der Laufzeit in die Definition. Ein falsch verdrahteter Workflow fällt dann beim Validieren auf und nicht erst im Gespräch mit einem Nutzer.
Dazu kommt MCP, das Model Context Protocol, als Integrationspunkt für Werkzeug- und Kontext-Interoperabilität. Die README spricht von Integrationspunkten, nicht von einem vollständigen MCP-Server. Wer konkrete MCP-Rollen erwartet, sollte das in der Dokumentation unter docs.hexabot.ai nachlesen, statt es aus dem Schlagwort abzuleiten.
Die Bindings verdienen einen zweiten Blick. Die Trennung von Fähigkeit und Aufgabe klingt nach Konfigurationsverwaltung, und genau das ist sie: Ein Workflow referenziert eine Bindung, statt Zugangsdaten oder Parameter direkt im Ablauf zu duplizieren. Wer mehrere Kanäle und Umgebungen parallel betreibt, spart damit Änderungen an vielen Stellen. Wer nur einen einzigen Ablauf hat, zahlt den Preis einer zusätzlichen Indirektion.
Datenschicht: TypeORM, SQLite lokal, Postgres für Produktion
Als Datenschicht gibt die README TypeORM als Standard an. SQLite ist die lokale Voreinstellung, Postgres wird als erstklassig für Produktionsumgebungen bezeichnet. Konfiguriert wird das über die Umgebungsvariablen DB_TYPE und weitere DB_*-Variablen.
Das ist ein bewusst unspektakulärer Entwurf. TypeORM bedeutet, dass Entitäten und Migrationen im TypeScript-Code liegen; das CLI stellt dafür den Befehl hexabot migrate bereit, der Argumente durchreicht. In der Praxis heißt das: Schemaänderungen laufen nicht automatisch beim Start, sondern über einen expliziten Migrationsschritt. Wer SQLite lokal nutzt und später auf Postgres wechselt, muss diesen Schritt einplanen, weil sich Datentypen und Verhalten zwischen beiden Systemen unterscheiden.
Auffällig ist, dass die README keinen Hinweis auf eine Verbindungspool-Konfiguration oder auf Read-Replicas gibt. Für kleine bis mittlere Installationen reicht das, für Hochlastszenarien fehlen in dem Material belastbare Angaben. Wer horizontale Skalierung plant, sollte das vor der Architekturentscheidung mit der Dokumentation abgleichen.
Installation und erster Start: die konkreten Befehle
Die Voraussetzungen sind eng gefasst. Die README nennt Node.js ^24.17.0, einen Paketmanager (npm, pnpm, yarn oder bun) und optional Docker für Docker-basierte Dienste. Die Node-Version ist der erste Stolperstein: Wer auf einer älteren LTS-Version arbeitet, muss zuerst aktualisieren.
Das CLI wird global installiert:
npm install -g @hexabot-ai/cli
Wer keine globale Installation will, nutzt npx @hexabot-ai/cli --help. Danach folgt der Projektaufbau:
hexabot create my-project cd my-project hexabot dev
Das CLI erkennt den Paketmanager automatisch; mit --pm lässt sich einer erzwingen, etwa hexabot create my-project --pm npm. Wichtig ist eine Einschränkung aus der README: hexabot create fragt nach den ersten Admin-Zugangsdaten und benötigt ein interaktives Terminal (TTY). In CI- oder nicht-interaktiven Shells muss der Befehl zuerst aus einem lokalen Terminal ausgeführt werden. Das ist ein realer Bruch in automatisierten Setups und kein Nebensatz.
Die Standardendpunkte nach dem Start sind die Admin-Oberfläche unter http://localhost:3000, die API unter http://localhost:3000/api und die API-Dokumentation unter http://localhost:3000/docs, letztere ausdrücklich nicht in Produktion. Weitere Befehle sind hexabot start (mit --docker, --services, --build, -d), hexabot stop (mit --docker, --services, -v, --remove-orphans), hexabot env init oder list, hexabot check, hexabot config show oder set sowie hexabot migrate. Details stehen laut README in packages/cli/README.md.
Grenzen: TTY-Pflicht, Node 24 und die dünne MCP-Beschreibung
Die erste Einschränkung ist bereits genannt: hexabot create braucht ein interaktives Terminal. Wer Projekte in einem Container oder in einer Pipeline erzeugen will, muss den Umweg über ein lokales Terminal gehen oder das erzeugte Projekt anderweitig bereitstellen. Die README beschreibt keinen nicht-interaktiven Modus.
Die zweite Einschränkung ist die Node-Version. ^24.17.0 ist keine breite Unterstützung, sondern eine Festlegung auf eine konkrete Hauptversion. In Umgebungen, in denen die Laufzeit zentral verwaltet wird, ist das eine Abstimmung mit dem Plattformteam, nicht eine Zeile in einer Konfigurationsdatei.
Die dritte betrifft MCP. Die README nennt Integrationspunkte für Werkzeug- und Kontext-Interoperabilität, ohne zu sagen, ob Hexabot als Client, als Server oder beides auftritt. Wer MCP als Auswahlkriterium hat, kann das aus dem vorliegenden Material nicht klären und muss die Dokumentation prüfen.
Die vierte betrifft die Reifegrade. Das Repository ist nicht archiviert, der letzte Push liegt laut Metadaten im August 2026. Die jüngste aufgeführte Veröffentlichung ist jedoch v2.2.2 vom 24. Januar 2025, davor v2.1.5 und v2.0.2. Zwischen der v3-Beschreibung in der README und den gelisteten Releases klafft eine Lücke. Das kann an der Release-Praxis liegen, es kann aber auch bedeuten, dass v3 noch nicht als Paket veröffentlicht ist. Wer auf stabile Versionen angewiesen ist, muss das vor dem Einstieg klären.
Alternativen: LangChain, Flowise und der Unterschied im Ansatz
Die naheliegende Alternative für agentische Abläufe ist LangChain in der Python-Variante. Der Unterschied liegt nicht in den Funktionen, sondern im Zentrum der Definition. LangChain stellt Bibliotheken bereit, die man in eine eigene Anwendung einbettet; die Ablaufstruktur entsteht im Python-Code des Anwendungsentwicklers. Hexabot dreht das um: Der Workflow ist eine YAML-Datei mit typisierten Verträgen, Actions liefern schema-validierte Ein- und Ausgaben, und die Laufzeit führt das aus. Wer ohnehin eine TypeScript-Anwendung besitzt, bleibt im selben Sprach- und Typsystem. Wer ein Python-Ökosystem mit eigenen Modellen und Auswertungen pflegt, müsste dagegen eine zweite Laufzeit betreiben.
Für den visuellen Ansatz steht Flowise. Dort werden Abläufe überwiegend im Browser zusammengesteckt. Hexabot verlangt dagegen eine YAML-Datei im Repository, was Reviews, Diffs und Versionierung erleichtert, aber die Einstiegshürde für Personen ohne Versionskontrolle erhöht. Das ist eine bewusste Entscheidung für Entwicklerwerkzeuge und gegen einen reinen No-Code-Workflow.
Für einfache Bots ohne Agentenlogik ist ein klassisches Bot-Framework mit Zustandsautomaten oft ausreichend und deutlich schlanker. Hexabot bringt Memory, Bindings, Zod-Schemas und MCP mit; wer nur auf Schlagwörter antwortet, bezahlt für Fähigkeiten, die er nicht nutzt.
Wartung, Upgrades und die Lizenz FCL-1.0-ALv2
Der Wartungsaufwand hängt an drei Punkten. Erstens die Node-Version: ^24.17.0 bedeutet, dass ein Sprung auf die nächste Hauptversion ein geplanter Vorgang ist und nicht beiläufig passiert. Zweitens die Migrationen: hexabot migrate ist ein eigener Befehl, Schemaänderungen müssen also bewusst ausgeführt werden. Wer das in einer Pipeline vergisst, startet gegen ein veraltetes Schema. Drittens der Monorepo-Aufbau mit PNPM-Workspace und Turbo: Wer nicht nur Anwendungen baut, sondern am Kern mitwirkt, übernimmt diese Werkzeugkette zusätzlich.
Das CLI hilft beim Einordnen: hexabot check prüft die Umgebung, hexabot env list zeigt die Umgebungsvariablen, hexabot config show die aktuelle Konfiguration. Das sind Diagnosebefehle, die vor einem Upgrade sinnvoll sind, weil sie den Ist-Zustand sichtbar machen.
Zur Lizenz: Die README nennt FCL-1.0-ALv2, Copyright (c) 2025 Hexastack, und verweist für die vollständigen Bedingungen auf LICENSE.md. Die Metadaten des Repositories melden dagegen NOASSERTION, also keine automatisch erkannte Standardkennung. FCL-1.0-ALv2 ist keine der gängigen Open-Source-Kennungen, und die README beschreibt weder Nutzungsrechte noch Weitergabe- oder Hosting-Bedingungen. Wer Hexabot kommerziell einsetzen oder als Dienst anbieten will, muss LICENSE.md selbst lesen und die Bedingungen mit der eigenen Rechtsabteilung klären. Aus der Repository-Beschreibung lässt sich keine Aussage darüber ableiten, ob ein gehosteter Betrieb zulässig ist.
Redaktionelles Fazit
Für Teams, die Gesprächskanäle und agentische Abläufe in einer selbst gehosteten TypeScript-Laufzeit zusammenführen wollen und Node 24 sowie die Lizenz FCL-1.0-ALv2 akzeptieren, ist Hexabot v3 einen Testlauf wert. Wer eine reine Python-LLM-Kette braucht oder keine Ressourcen für ein monorepo-basiertes Upgrade hat, sollte Abstand nehmen. Prüft zuerst LICENSE.md, ob euer Use Case unter FCL-1.0-ALv2 fällt, und führt danach hexabot check aus.
Community-Notizen