Clawith: Multi-Agenten-Plattform mit persistenten Identitäten und selbst gesetzten Triggern

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

Ein Sprachmodell über eine API aufzurufen ist einfach. Ein Agent, der über Wochen dieselbe Rolle ausfüllt, ist es nicht. Zwischen zwei Sitzungen verliert ein zustandsloser Aufruf alles: die Persönlichkeit, den Arbeitsstand, die Beziehungen zu anderen Beteiligten. Clawith setzt genau dort an. Die README beschreibt das Projekt als offene Multi-Agenten-Kollaborationsplattform, die jedem Agenten eine persistente Identität, ein Langzeitgedächtnis und einen eigenen Arbeitsbereich gibt. Konkret heißt das: eine Datei `soul.md` für die Persönlichkeit, eine Datei `memory.md` für das Gedächtnis und ein privates Dateisystem mit sandboxed Code-Ausführung. Diese Bestandteile bleiben über jede Konversation hinweg erhalten.

Die Zielgruppe ist enger, als der Slogan vermuten lässt. Clawith richtet sich an Organisationen, die mehrere Agenten gleichzeitig betreiben und dabei Rollen, Rechte und Kosten kontrollieren wollen. Die README nennt Multi-Tenant-RBAC mit organisationsbasierter Isolation, Nutzungskontingente pro Nutzer, Freigabeworkflows für gefährliche Operationen und Audit-Logs. Wer einen einzelnen Chatbot für gelegentliche Fragen sucht, findet hier deutlich mehr Maschinerie als nötig. Wer dagegen ein Team aus Agenten aufbauen will, das sich gegenseitig Nachrichten schickt und Aufgaben delegiert, bekommt eine fertige Organisationsstruktur statt eines leeren Frameworks.

Aware: Trigger, die der Agent selbst verwaltet

Der interessanteste Teil von Clawith ist das System namens Aware. Es dreht die übliche Richtung um: Nicht der Mensch legt fest, wann ein Agent läuft, sondern der Agent verwaltet seinen eigenen Zeitplan. Die README beschreibt sechs Triggertypen. `cron` für wiederkehrende Termine, `once` für einen einmaligen Zeitpunkt, `interval` für ein festes Minutenintervall, `poll` für die Überwachung eines HTTP-Endpunkts, `on_message` zum Aufwachen, wenn ein bestimmter Agent oder Mensch antwortet, und `webhook` für eingehende HTTP-POST-Ereignisse etwa von GitHub, Grafana oder einer CI-Pipeline.

Entscheidend ist die Kopplung an sogenannte Focus Items. Jeder aufgabenbezogene Trigger muss laut README ein entsprechendes Focus Item besitzen. Der Agent legt zuerst das Focus Item an und setzt dann den Trigger, der über `focus_ref` darauf verweist. Focus Items tragen Statusmarker: `[ ]` für ausstehend, `[/]` für in Arbeit, `[x]` für erledigt. Wird ein Focus Item abgeschlossen, annulliert der Agent seine zugehörigen Trigger. Diese Regel verhindert das klassische Problem selbstgebauter Agentenschleifen: Trigger, die weiter feuern, obwohl die Aufgabe längst erledigt ist. Die README formuliert die Arbeitsteilung so, dass der Mensch das Ziel vorgibt und der Agent den Zeitplan verwaltet.

Ob diese Selbstverwaltung in der Praxis diszipliniert bleibt, lässt sich aus dem Material nicht beurteilen. Die Statusmarker sind eine Konvention, kein erzwungener Zustandsautomat. Ein Agent, der ein Focus Item nie auf `[x]` setzt, wird seine Trigger nicht los. Die Reflections-Ansicht, die laut README das autonome Reasoning während triggerausgelöster Sitzungen mit aufklappbaren Tool-Aufrufen zeigt, ist damit weniger ein Komfortmerkmal als das eigentliche Kontrollinstrument.

Installation: was setup.sh tatsächlich anfasst

Der Einstieg ist als Einzeiler angelegt. Nach dem Klonen und Wechsel in das Verzeichnis stehen zwei Varianten bereit: `bash setup.sh` für die Produktion, die laut README nur die Laufzeitabhängigkeiten installiert und etwa eine Minute braucht, sowie `bash setup.sh --dev`, die zusätzlich pytest und Testwerkzeuge einrichtet und rund drei Minuten dauert. Das Skript erledigt fünf Dinge: es erzeugt `.env` aus `.env.example`, richtet PostgreSQL ein, installiert die Backend-Abhängigkeiten in einer Python-venv, installiert die Frontend-Abhängigkeiten über npm und legt Datenbanktabellen samt Startdaten an (Standardfirma, Templates, Skills).

Bemerkenswert ist der PostgreSQL-Schritt. Das Skript nutzt eine vorhandene Instanz, wenn eine erreichbar ist, andernfalls lädt es laut README automatisch eine lokale herunter und startet sie. Wer eine bestimmte Instanz verwenden will, legt vorher eine `.env` an und setzt `DATABASE_URL` im Format `postgresql+asyncpg://user:pass@localhost:5432/clawith?ssl=disable`. Gestartet wird die Anwendung anschließend mit `bash restart.sh`.

Die Voraussetzungen sind nicht trivial: Python 3.12 oder neuer, Node.js 20 oder neuer, PostgreSQL 15 oder neuer (SQLite wird für schnelle Tests akzeptiert), mindestens 2 Kerne, 4 GB RAM und 30 GB Speicher. Die README stellt klar, dass Clawith keine Modelle lokal ausführt. Die gesamte Inferenz läuft über externe Anbieter wie OpenAI oder Anthropic, und die lokale Bereitstellung ist eine gewöhnliche Webanwendung mit Docker-Orchestrierung. Wer also gehofft hat, mit Clawith Rechenlast auf die eigene Hardware zu verlagern, wird enttäuscht. Es verlagert nur den Zustand.

Die Plaza und die Frage, was Agenten voneinander wissen

Die Plaza wird in der README als lebendiger Wissensfeed der Organisation beschrieben. Agenten veröffentlichen Updates, teilen Funde und kommentieren die Arbeit der anderen. Der Anspruch dahinter ist, dass jeder Agent kontinuierlich organisatorisches Wissen aufnimmt und kontextbewusst bleibt. Das ist ein anderer Mechanismus als ein gemeinsamer Vektorspeicher, der bei Bedarf abgefragt wird. Bei Clawith läuft der Kontext ständig mit, als Strom statt als Abfrage.

Das hat eine offensichtliche Kehrseite, die die README nicht ausräumt. Ein dauerhafter Feed wächst, und jeder Beitrag potenziell in jeder Sitzung gelesen zu werden bedeutet Kontextfenster, das irgendwann gefüllt ist. Die README nennt keine Verdichtung, kein Archivierungsintervall und keine Obergrenze für die Anzahl der Beiträge, die ein Agent mitliest. Ob die Plaza bei zwanzig Agenten über Monate hinweg noch nützlich oder nur noch teuer ist, lässt sich aus dem Material nicht beantworten. Das ist eine offene Flanke des Designs, keine Kleinigkeit.

Daneben steht die Knowledge Base, die laut README als geteilter Unternehmenskontext automatisch injiziert wird. Zusammen mit der Plaza ergibt das zwei Wege, auf denen Kontext in einen Agenten gelangt, ohne dass der Nutzer ihn explizit mitgibt. Wer Kostentransparenz braucht, sollte beide Wege getrennt messen, bevor er die Kontingente festlegt.

Grenzen: wo Clawith die falsche Wahl ist

Der deutlichste Vorbehalt steht in der README selbst, wenn auch beiläufig. Die Live-Demo unter try.clawith.ai wird als offene Funktionsvorschau bezeichnet, als geteilte Demo-Umgebung ohne Stabilitätsgarantie. Wer die Plattform vor dem eigenen Aufbau einschätzen will, kann das also nur eingeschränkt tun. Für einen belastbaren Test bleibt nur die lokale Installation.

Der zweite Vorbehalt betrifft die Abhängigkeiten. Clawith bringt PostgreSQL, einen Python-Dienst, ein Node-Frontend und Docker für die Agenten-Container mit. Die README empfiehlt für die volle Erfahrung mit ein bis zwei Agenten 2 Kerne und 4 GB RAM, für ein kleines Team mit drei bis fünf Agenten 2 bis 4 Kerne und 4 bis 8 GB. Ein Einzelentwickler, der einen Agenten für die eigene Notizenverwaltung will, betreibt dafür einen kompletten Web-Stack. Das Verhältnis stimmt nicht.

Drittens die Selbstmodifikation. Agenten können laut README zur Laufzeit neue Werkzeuge entdecken und installieren, über Smithery und ModelScope, und eigene Skills anlegen, für sich oder für Kollegen. Das ist eine Funktion, die jede Freigabe- und Audit-Struktur unterläuft, wenn sie nicht sauber an die Approval-Workflows angebunden ist. Die README beschreibt beide Mechanismen, aber nicht ihr Zusammenspiel. Wer Clawith produktiv einsetzt, muss diese Verbindung selbst prüfen, und zwar bevor Agenten das erste Mal unbeaufsichtigt laufen.

Was Clawith von einem Orchestrierungs-Framework unterscheidet

Die naheliegende Alternative ist ein Graph- oder Workflow-Framework, in dem ein Entwickler Knoten und Kanten definiert und der Ablauf zur Entwicklungszeit feststeht. Der Unterschied liegt nicht im Funktionsumfang, sondern in der Richtung der Kontrolle. Bei einem Workflow-Framework entscheidet der Entwickler, wann welcher Schritt läuft, und der Agent füllt nur die Lücken. Bei Clawith entscheidet der Agent über seine Trigger, und der Mensch gibt das Ziel vor.

Das verschiebt auch die Fehlerbehebung. In einem festen Graphen ist ein Fehler reproduzierbar, weil der Pfad bekannt ist. Bei Clawith entsteht der Pfad zur Laufzeit, und die README liefert mit den Reflections und den Audit-Logs zwei Werkzeuge, um ihn nachträglich zu rekonstruieren. Nachvollziehbarkeit ist hier also eine Frage der Protokollierung, nicht der Konstruktion. Wer Fehlerfreiheit über Wiederholbarkeit definiert, wird mit Clawith unzufrieden. Wer einen Agenten will, der sich an veränderte Bedingungen anpasst, zahlt dafür mit schwerer vorhersagbaren Läufen.

Ein zweiter Unterschied betrifft die Identität. In den meisten Frameworks ist der Agent eine Funktion, die einen Prompt entgegennimmt. Bei Clawith ist er ein Objekt mit Dateien, Rechten und einer Rolle im Organigramm. Das ist der eigentliche Kern des Projekts, und alles andere, die Trigger, die Plaza, die Kontingente, hängt daran.

Betrieb, Lizenzen und Upgrade-Aufwand

Clawith steht unter Apache-2.0. Diese Lizenz erlaubt kommerzielle Nutzung, Veränderung und Weitergabe, verlangt aber, dass Lizenz- und Urheberrechtshinweise erhalten bleiben und Änderungen an Dateien kenntlich gemacht werden. Sie enthält eine ausdrückliche Patentgewährung und, anders als manche Copyleft-Lizenz, keine Pflicht, eigene Änderungen offenzulegen. Das ist für den internen Betrieb die unkomplizierte Variante. Ob die Nutzung der gehosteten Dienste unter cloud.clawith.ai zusätzlichen Bedingungen unterliegt, geht aus dem vorliegenden Material nicht hervor, und die README trennt die selbst betriebene Software nicht ausdrücklich von diesen Diensten. Wer den Cloud-Dienst statt der eigenen Installation erwägt, muss das separat klären. Diese Einschätzung ist keine Rechtsberatung.

Zum Wartungsaufwand lässt sich aus dem Material nur wenig Belastbares sagen. Die Release-Historie zeigt für August 2026 die Versionen v1.11.4 und v1.11.4-fix.1, wobei letztere als Hotfix für Runtime-Onboarding und Verifikation ausgewiesen ist. Ein Hotfix unmittelbar nach einem Funktionsrelease deutet auf einen zügigen, aber auch unruhigen Veröffentlichungsrhythmus hin. Für Betreiber heißt das: Updates sind häufig, und ein Blick in die Release Notes vor jedem Sprung ist sinnvoll, weil Korrekturen am Onboarding-Pfad die Einrichtung betreffen können und nicht nur Randfunktionen.

Die Kosten entstehen ohnehin woanders. Da die gesamte Inferenz über externe Anbieter läuft, ist das Modellbudget der dominierende Posten, nicht die Infrastruktur. Die README nennt pro Nutzer Kontingente für Nachrichten, Obergrenzen für LLM-Aufrufe und eine TTL für Agenten. Diese drei Werte sind die eigentlichen Stellschrauben im Betrieb, und sie sollten vor dem ersten unbeaufsichtigten Lauf gesetzt sein, nicht danach.

Redaktionelles Fazit

Clawith passt zu Teams, die mehrere Agenten über Wochen hinweg mit Rollen, eigenem Dateisystem und Audit-Logs betreiben wollen und bereit sind, PostgreSQL, Python 3.12 und Node 20 selbst zu betreiben. Wer nur einen einzelnen Assistenten für gelegentliche Fragen braucht, ist mit einem Stateless-Aufruf gegen eine Modell-API besser bedient, weil Clawiths Identitätsschicht dann nur Overhead erzeugt. Vor dem produktiven Einsatz zu prüfen: ob die Approval-Workflows tatsächlich vor jeder als gefährlich markierten Operation greifen, ob `soul.md` und `memory.md` bei mehreren Agenten pro Organisation isoliert bleiben, und ob die Quota-Einstellungen pro Nutzer auch LLM-Aufrufe begrenzen und nicht nur Nachrichten. Erst danach lohnt der Wechsel von SQLite auf eine eigene PostgreSQL-Instanz über DATABASE_URL.

Offizielle Quellen

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