Brigade: Agentencrew mit eigenem Org-Chart, Tideline-Gedächtnis und selbst gehostetem Convex

Ein Owner, viele Agenten: das Problem hinter Brigade

Ein einzelner Chat-Assistent stößt schnell an Grenzen, sobald Aufgaben unterschiedliche Werkzeuge, eigene Zugangsdaten und getrennte Arbeitsverzeichnisse brauchen. Brigade setzt genau dort an. Das README beschreibt eine Crew aus KI-Agenten auf einem echten Org-Chart, die sich ein Langzeitgedächtnis namens Tideline teilen, sodass Wissen eines Agenten den anderen zur Verfügung steht. Jeder Agent bekommt laut README eigene Workspaces und Credentials, also getrennte Rechte statt eines gemeinsamen Kontos für alles.

Die Zielgruppe ist im Material klar umrissen: Einzelpersonen und kleine Teams, die den Dienst selbst hosten und keinen SaaS-Anbieter dazwischen wollen. Das README formuliert es als einen Owner, eine ganze Crew, auf Hardware und Storage, die man selbst kontrolliert. Wer dagegen einen fertig betriebenen Cloud-Dienst sucht, findet hier bewusst keinen. Der Preis für diese Kontrolle ist Betriebsarbeit am eigenen Rechner oder Server.

Org-Chart, Tideline und Modellwechsel: der Mechanismus

Die Architektur lässt sich aus dem README in drei beweglichen Teilen lesen. Erstens die Hierarchie: Agenten werden in ein Org-Chart eingewoben, das laut README regelt, wer wem delegieren darf. Zweitens das Gedächtnis: Tideline speichert Fakten über Sitzungen hinweg mit Origin-Scoping, Decay und hybridem Recall aus Keyword- und Vektorsuche. Origin-Scoping heißt, dass ein Fakt an seine Herkunft gebunden bleibt; Decay heißt, dass Erinnerungen an Gewicht verlieren können. Beides ist eine Designentscheidung mit Folgen, denn wer erwartet, dass jede Notiz dauerhaft gleich stark abrufbar bleibt, wird sich über das Verhalten von Tideline wundern.

Drittens die Modellschicht: Laut README lässt sich das Modell mitten in einer Aufgabe wechseln, ohne den Faden zu verlieren. Unterstützt werden Claude, GPT, Gemini, Llama und ein lokales Ollama. Dazu kommt Sub-Agent-Fan-out, also das Aufteilen einer Aufgabe auf mehrere Agenten, sowie ein Cron-Scheduler für zeitgesteuerte Läufe und ein Skill-System für Erweiterungen. Der Datenfluss bleibt dabei in einem Verzeichnis: alles liegt unter ~/.brigade/. Das ist der eigentliche Kern des Projekts, ein einziger Wurzelpfad, den man sichern, kopieren oder löschen kann.

Installation ohne sudo und der Start in der TUI

Der Installationsweg ist im README als Einzeiler dokumentiert. Unter macOS und Linux installiert das Skript bei Bedarf Node nach und danach Brigade, ohne sudo:

curl -fsSL https://brigade.spinabot.com/install.sh | sh brigade

Nach dem Start öffnet sich laut README eine Chat-TUI ohne Browser und ohne Electron. Das Paket liegt auf npm unter @spinabot/brigade, das Node-Engine-Badge verweist auf nodejs.org. Wer nicht über das Skript installieren will, kann den npm-Pfad nutzen; das README nennt ihn als Badge, nicht als Befehl, also sollte man die Paketseite prüfen, bevor man sich auf eine bestimmte Aufrufform festlegt.

Interessant ist der Umgang mit Zugangsdaten. Laut README muss man keine API-Keys kopieren: Man kann sich mit einem Claude-, ChatGPT- oder Copilot-Abo anmelden, oder eine bestehende Anmeldung der Claude-Code- bzw. Codex-CLI wiederverwenden, ohne Browser und ohne erneute Authentifizierung. Die Keys bleiben laut README auf der eigenen Maschine und werden nicht an einen Mittler geschickt. Das ist ein konkretes Versprechen über den Datenfluss, kein allgemeines Datenschutzversprechen, und es ist der Punkt, an dem man vor dem Einsatz nachmessen sollte, welche Verbindungen das Programm tatsächlich öffnet.

Dateisystem oder selbst gehostetes Convex: die Storage-Entscheidung

Brigade kennt laut README zwei Storage-Modi. Standard ist eine kleine Installation auf dem Dateisystem. Wer mehr braucht, schaltet auf eine selbst gehostete Convex-Datenbank um. Diese Wahl ist die wichtigste Betriebsentscheidung des Projekts, weil sie bestimmt, ob man nur ein Verzeichnis sichert oder zusätzlich einen Datenbankdienst betreiben, aktualisieren und absichern muss. Das README nennt Convex ausdrücklich als optional und selbst gehostet, es ist also kein verwalteter Backend-Dienst des Anbieters.

Dass Brigade auf einer Raspberry Pi oder auf einem Server laufen soll, steht im README als Aussage zur Portabilität, nicht als Leistungsversprechen. Wer viele Agenten parallel laufen lässt, sollte die Grenzen der eigenen Hardware selbst ermitteln, denn belastbare Zahlen liefert das Material nicht. Auch die Konfigurationsschlüssel sind im vorliegenden Auszug nur als Abschnitt Configuration & storage vorhanden, ohne konkrete Keys. Wer Brigade produktiv aufsetzt, muss diese Werte aus der Dokumentation im Repository selbst nachschlagen, statt sie aus diesem Text zu übernehmen.

B³, expose und der Tunnel nach draußen

Ein eigener Bestandteil ist B³, die Brigade Bloody Benchmark, eingeführt laut README in v1.9.0. Der Befehl brigade bloody benchmark gibt die Crew über einen Tunnel nach außen frei. Der Transport läuft laut README standardmäßig über Cloudflare, alternativ über einen eigenen Relay mit bore, frp oder sish. Ein geheimer Schlüssel wird mitgeführt, unsichtbar für den Nutzer, und nicht eingeladene Zugriffe laufen laut README auf einen 401. Der gleiche Mechanismus heißt auch brigade expose, gestoppt wird er mit brigade expose stop.

Hier ist Vorsicht angebracht. Ein Agent, der nach außen erreichbar ist, ist eine andere Risikoklasse als ein lokaler Chat. Das README beschreibt den Schutz als einen Schlüssel in der URL und einen 401 für Unbefugte. Ob dieser Schutz für die eigenen Daten ausreicht, hängt davon ab, welche Werkzeuge der freigegebene Agent aufrufen darf, und genau das sagt das Material nicht. Wer B³ nur als Benchmark versteht und darüber die Freigabe vergisst, betreibt am Ende einen offenen Endpunkt. brigade expose stop gehört deshalb zum Standardablauf, nicht zur Fußnote.

Isolation, Freigaben und die Grenzen des Versprechens

Das README verspricht isolierte Agenten mit eigenen Workspaces und Credentials sowie eine Freigabe durch den Nutzer bei privilegierten Aktionen. Das ist eine sinnvolle Voreinstellung, aber sie verschiebt Arbeit: Je mehr Agenten laufen, desto mehr Freigabeanfragen entstehen. Wer die Freigaben abschaltet, um Durchsatz zu gewinnen, hebt genau die Kontrolle auf, die das Projekt als Verkaufsargument nennt. Diese Spannung löst das Material nicht auf.

Eine weitere offene Stelle ist die Anbindung an über 1.000 Apps sowie an WhatsApp, Telegram, Slack, Discord, iMessage und BlueBubbles, dazu Watch, Meta-Brillen und Meta Quest. Das README nennt sie als vorhandene Kanäle, ohne pro Kanal den Reifegrad zu benennen. Wer einen dieser Kanäle als kritischen Pfad einplant, sollte ihn einzeln prüfen. Und wer einen Agenten mit Schreibzugriff auf ein Firmensystem verbindet, sollte bedenken, dass Brigade keine im Material beschriebene Mandantentrennung für mehrere Personen mitbringt. Das Modell ist ausdrücklich ein Owner mit einer Crew, kein Mehrbenutzerbetrieb.

Wartung, Lizenz und der Vergleich mit einem Coding-Agenten

Brigade steht unter MIT-Lizenz. Das erlaubt kommerzielle Nutzung und Änderungen, verpflichtet aber dazu, den Lizenztext und den Urheberrechtshinweis bei Weitergabe beizubehalten. Das Material enthält keine Angaben zu Markenrechten oder zu Bedingungen der angebundenen Provider, und die Nutzung eines Claude-, ChatGPT- oder Copilot-Abos über Brigade ist eine Frage der jeweiligen Anbieterbedingungen. Das ist keine Rechtsberatung, sondern ein Hinweis darauf, was vor einem kommerziellen Einsatz zu klären ist.

Die Release-Kadenz ist im Material sichtbar: v1.37.1 vom 9. September 2026, davor v1.37.0 vom 2. September und v1.36.1 vom 31. August. Das sind drei Releases in rund zehn Tagen. Für Betreiber bedeutet diese Frequenz, dass ein Update-Pfad und ein Rückweg eingeplant werden müssen, zumal alles unter ~/.brigade/ liegt und Schemaänderungen an Tideline oder am Storage-Modus dort ankommen. Wer Brigade auf einer Maschine mit Produktivdaten laufen lässt, sollte vor jedem Update das Verzeichnis sichern.

Als Alternative bietet sich ein einzelner Coding-Agent wie die Claude-Code- oder Codex-CLI an, deren Anmeldung Brigade laut README sogar wiederverwendet. Der Unterschied liegt im Umfang: Diese CLIs arbeiten in einer Sitzung an einem Repository, ohne gemeinsames Langzeitgedächtnis über Agenten hinweg, ohne Org-Chart und ohne Cron-Scheduler. Wer nur Code in einem Verzeichnis ändern will, fährt mit einer solchen CLI einfacher. Brigade lohnt sich erst, wenn mehrere Agenten koordinieren, sich erinnern und über Kanäle wie Telegram oder Slack erreichbar sein sollen.

Für wen sich der Betrieb lohnt und was zuerst zu prüfen ist

Wer eine Agentencrew auf eigener Hardware betreiben will und die Daten im eigenen ~/.brigade/-Verzeichnis behalten möchte, findet hier einen kohärenten Aufbau: ein Installationsskript ohne sudo, eine TUI als Einstieg, Tideline als gemeinsames Gedächtnis und zwei klar benannte Storage-Modi. Wer dagegen einen betreuten Dienst, eine Mehrbenutzerverwaltung mit Rollen oder reproduzierbare Leistungszahlen sucht, wird im Material nicht fündig, und das ist keine Lücke dieses Textes, sondern eine Grenze des Projekts.

Die erste Prüfung betrifft den Storage-Modus, weil davon Betriebsaufwand und Skalierung abhängen. Die zweite betrifft die Provider-Anmeldung, also ob die Wiederverwendung einer Claude-Code- oder Codex-Sitzung in der eigenen Umgebung tatsächlich funktioniert. Die dritte betrifft die Reichweite: Bevor ein Agent über brigade bloody benchmark oder brigade expose nach außen geht, sollte klar sein, welche Werkzeuge er aufrufen darf. Solange diese drei Punkte nicht geklärt sind, bleibt Brigade ein vielversprechender Selbstbau, kein fertiges Produkt.

Redaktionelles Fazit

Brigade passt zu Einzelpersonen und kleinen Teams, die eine Agentencrew auf eigener Hardware betreiben und Keys sowie Daten im eigenen ~/.brigade/-Verzeichnis behalten wollen. Wer einen verwalteten Dienst mit Support-Zusage, Betrieb ohne Node-Laufzeit oder reproduzierbare Benchmark-Zahlen sucht, ist hier falsch. Vor dem Einsatz zuerst die Storage-Entscheidung treffen: Dateisystem als Standard oder selbst gehostetes Convex, denn davon hängen Skalierung und Betriebsaufwand ab. Danach brigade doctor prüfen und die Provider-Anmeldung testen, bevor Agenten mit privilegierten Aktionen laufen.

Offizielle Quellen

1. License: MIT
2. Project website
3. README
4. Releases
5. spinabot/brigade on GitHub