Was ist ZeroClaw?#
ZeroClaw ist ein leichtgewichtiger Daemon, geschrieben in Rust, der auf jeder Abteilungs-VM einen eigenen KI-Agenten bereitstellt. Statt eines schwerfälligen zentralen Services entsteht so ein Geflecht spezialisierter Agenten, die eng mit den Werkzeugen ihrer jeweiligen Domäne verzahnt sind — Buchhaltung, IT, Vertrieb, HR.
Entscheidend: jeder Agent läuft isoliert in seiner eigenen VM. Das schafft klare Sicherheitsgrenzen und erlaubt eine Zuständigkeitstrennung, die mit einem monolithischen Service kaum erreichbar ist.
Die M9TZ-Architektur#
Die Architektur folgt einem einfachen, aber wirkungsvollen Muster:
- Eine VM pro Abteilung, jeweils mit eigenem ZeroClaw-Agenten
- Isolierte Konfiguration pro Domäne — Werkzeuge, Prompts, Berechtigungen
- Kommunikation über geteilte Speicherorte, nicht über direkte RPC-Aufrufe
Jeder Agent kennt seine Werkzeuge und seine Daten — aber nur seine. Die Querschnittskommunikation läuft über einen bewusst simpel gehaltenen Kanal.
Stage 1: JSON-over-SMB#
Die erste Ausbaustufe nutzt das, was ohnehin vorhanden ist: SMB-Shares. Ein Agent legt eine JSON-Datei auf einem Share ab, ein anderer Agent nimmt sie per File-Watcher auf.
{
"from": "buchhaltung",
"to": "it",
"type": "ticket_create",
"subject": "Lizenzlaufzeit CRM abgelaufen",
"priority": "high",
"created_at": "2026-07-24T08:12:00Z"
}Praktisches Beispiel: Der Buchhaltungs-Agent erkennt in den eingespielten Rechnungen, dass eine Software-Lizenz kurz vor dem Ablauf steht. Er generiert ein strukturiertes Ticket als JSON und legt es auf dem SMB-Share ab. Der IT-Agent nimmt die Datei auf, erstellt im Ticketsystem den passenden Vorgang und bestätigt den Empfang — ebenfalls über eine JSON-Antwortdatei.
Warum Rust und SMB?#
Die Wahl von Rust ist kein Selbstzweck. Im Mittelstandsumfeld bedeutet jeder Ressourcen-Overhead mehr Betriebskosten und mehr Angriffsfläche. Konkret:
- Geringer Speicherbedarf — eine Rust-Binary startet in Millisekunden, keine JVM, kein Container-Bloat
- Sicherheitsgarantien — Ownership-Modell verhindert ganze Klassen von Speicherfehlern
- Einfache Verteilung — eine einzelne ausführbare Datei pro VM
- SMB als Low-Tech-Brücke — nutzt die vorhandene Infrastruktur, kein zusätzliches Messaging-System, keine offenen TCP-Ports zwischen Abteilungs-Netzen
SMB ist hier kein Performanz-Sieger, sondern ein Enabler: es funktioniert dort, wo eine Message-Queue oder ein gRPC-Bus nicht ohne Weiteres deploybar wären.
Der Ausblick: von File-Watcher zu Event-Streaming#
Die Architektur ist bewusst in Stufen gedacht.
- Stage 1 (heute): JSON-over-SMB mit File-Watchern — einfach, robust, sofort einsetzbar
- Stage 2 (mid-term): Ablösung durch Event-Streaming — NATS oder Redpanda für höhere Durchsatzraten und echte Backpressure-Kontrolle
- Stage 3 (Ziel): Migration auf das A2A-Protokoll (Agent-to-Agent) — standardisierte, semantisch reichere Agenten-Kommunikation
Damit bleibt jede Investition in Stage 1 erhalten: die JSON-Schemas werden zu Event-Payloads, die Agenten selbst müssen nicht neu geschrieben werden.
Fazit#
ZeroClaw zeigt, dass Multi-Agenten-Architekturen nicht zwingend komplexe Orchestrierungsplattformen erfordern. Mit Rust als Runtime, einer VM pro Abteilung und SMB als initialer Kopplung lässt sich ein produktionsnaher Betrieb aufbauen, der in typischen Mittelstands-Netzwerken funktioniert — und sich später schrittweise zu einer Event-basierten Architektur weiterentwickeln kann.
Sie möchten mehr über die praktische Umsetzung erfahren oder ZeroClaw in Ihrem Unternehmen evaluieren? Ich berate Sie gerne zur Architektur, zum Deployment und zur schrittweisen Migration.