#AI Agents 20.02.2026 — 6 MIN READ

EpicClaws — Warum ich meine eigene Multi-Agent-Plattform gebaut habe

Ich arbeite seit über einem Jahr intensiv mit KI-Agenten zusammen. Erst lokal, mit selbstgebauten Setups — ein Agent, der Code schreibt, einer der testet, einer der deployed. Das funktionierte. Aber irgendwann stieß ich an eine Grenze: Was, wenn die Agenten nicht nur nacheinander arbeiten, sondern als echtes Team? Was, wenn mehrere Nutzer gleichzeitig eigene Agent-Teams brauchen? Was, wenn man die Tools, die ein Agent nutzen kann, dynamisch zusammenstellen will — ohne für jeden Use Case eine neue Pipeline zu bauen?

Die Antwort auf diese Fragen ist EpicClaws — eine Multi-Tenant, Multi-Agent-Plattform, die ich von Grund auf selbst entwickelt habe.

EpicClaws Agent Network — EPICCLAWS · MULTI-TENANT · MULTI-AGENT

Die Inspiration — und warum es nicht reichte

Bevor ich EpicClaws gebaut habe, war OpenClaw mein Ausgangspunkt. Open Source, Agent-Framework, vielversprechend. Es brachte eine CLI, diverse Interfaces und sogar eine Echtzeit-UI mit. Aber nach intensiver Nutzung wurden die Limitierungen klar:

Keine echte Mandantenfähigkeit. Es gab kein Konzept von isolierten Tenants oder Workspaces. Alles lief in einem globalen Kontext.
Keine Tool-Komposition. Tools mussten manuell installiert und konfiguriert werden. Wollte man einem Agenten ein anderes Toolset geben, musste man von Hand umbauen — kein dynamisches Zusammenstecken pro Workspace.
Keine Container-Isolation. Agenten liefen im selben Prozess, mit Zugriff auf das gleiche Dateisystem. Für ein Einzelnutzer-Setup OK — für eine Plattform mit mehreren Nutzern ein No-Go.

Ich habe mir auch OpenAI Swarm, LangChain, CrewAI und AutoGen angeschaut. Alle machen Dinge richtig. Aber keines löst das Kernproblem: echte Isolation auf Plattform-Level. Dass User A seine eigenen Agenten-Teams hat, mit eigenen API-Keys, eigenen Tools, einem eigenen Filesystem — komplett getrennt von User B. Und das nicht als nachträgliche Erweiterung, sondern als Kernarchitektur.

Die Architektur

EpicClaws läuft auf NestJS + TypeScript, mit PostgreSQL (inkl. pgvector für Embeddings), Redis für Caching und Pub/Sub, und einem eigenen Agent-Runtime namens pi-ai.

graph TD
    APP["Apps"] --> API["API"]
    API --> TN["Tenants"]
    API --> WS["Workspaces"]
    WS --> RT["Runtime"]
    WS --> TL["Tools"]
    WS --> FS["FS"]
    RT --> LLM["LLM"]
    RT --> BUS["Bus"]
    BUS --> RT
    API --> PG["Postgres"]
    API --> RD["Redis"]
    style API fill:#FF3D00,stroke:#fff,stroke-width:2px,color:#fff
    style RT fill:#FF3D00,stroke:#fff,stroke-width:2px,color:#fff
    style WS fill:#1A1A1A,stroke:#C8FF00,stroke-width:2px,color:#fff
    style TL fill:#1A1A1A,stroke:#C8FF00,stroke-width:2px,color:#fff
    style BUS fill:#1A1A1A,stroke:#C8FF00,stroke-width:2px,color:#fff

Der Server exponiert eine REST + WebSocket API. Die nativen Apps (SwiftUI für macOS/iOS) und das Web-Frontend (React + Vite) verbinden sich darüber. Echtzeit-Updates — wenn ein Agent eine Nachricht schreibt oder ein Tool aufruft — kommen über WebSockets.

PostgreSQL speichert alles: Tenants, Users, Workspaces, Agents, Messages, Tool-Definitionen, Canvas-Dokumente. pgvector ermöglicht semantische Suche über vergangene Konversationen — ein Agent kann also "erinnern", was in früheren Sessions besprochen wurde. Redis übernimmt LLM-Response-Caching und den Pub/Sub-Bus für Agent-zu-Agent-Kommunikation.

Die drei Grundprinzipien

1. Workspace-Isolation

Jeder Tenant hat seine eigenen Workspaces. Jeder Workspace ist eine abgeschlossene Sandbox mit eigenem Dateisystem und eigener Tool-Konfiguration. Und hier kommt der entscheidende Punkt: Jeder Agent innerhalb eines Workspaces läuft in einem eigenen dedizierten Docker-Container. Die Agenten teilen sich das Workspace-Dateisystem, aber sie sind auf Prozess-Ebene komplett isoliert.

graph TD
    T["Tenant"] --> W1["WS A"]
    T --> W2["WS B"]
    W1 --> A1["Agent 1"]
    W1 --> A2["Agent 2"]
    W2 --> A3["Agent 3"]
    W2 --> A4["Agent 4"]
    A1 --> F1["FS A"]
    A2 --> F1
    A3 --> F2["FS B"]
    A4 --> F2
    style T fill:#1A1A1A,stroke:#fff,stroke-width:2px,color:#fff
    style W1 fill:#1A1A1A,stroke:#C8FF00,stroke-width:2px,color:#fff
    style W2 fill:#1A1A1A,stroke:#C8FF00,stroke-width:2px,color:#fff
    style F1 fill:#1A1A1A,stroke:#C8FF00,stroke-width:2px,color:#fff
    style F2 fill:#1A1A1A,stroke:#C8FF00,stroke-width:2px,color:#fff
    style A1 fill:#FF3D00,stroke:#fff,stroke-width:2px,color:#fff
    style A2 fill:#FF3D00,stroke:#fff,stroke-width:2px,color:#fff
    style A3 fill:#FF3D00,stroke:#fff,stroke-width:2px,color:#fff
    style A4 fill:#FF3D00,stroke:#fff,stroke-width:2px,color:#fff

Workspace Isolation Blueprint — WORKSPACE ISOLATION · TENANT → WORKSPACE → AGENT CONTAINERS

API-Keys werden pro Workspace gespeichert und verschlüsselt. Agenten können nur Tools verwenden, die in ihrem Workspace registriert sind. Das Dateisystem ist pro Workspace gemountet. Selbst der Message-Bus ist workspace-scoped. Und weil jeder Agent in einem eigenen Container läuft, kann ein fehlerhafter Agent nicht die anderen Agenten im selben Workspace crashen.

2. Tool-Composability

EpicClaws hat ein Plugin-System für Tools. Ein "Tool" ist alles, was ein Agent aufrufen kann — Web-Suche, Code-Ausführung, Datei-Operationen, externe APIs, sogar andere Agenten. Tools werden nicht hardcoded, sondern pro Workspace konfiguriert und kombiniert. Ein Researcher-Agent bekommt Web-Suche und Arxiv. Ein Coder-Agent bekommt Filesystem und Code-Runner. Neues Tool? Einfach reinstecken.

3. Emergent Teamwork

Agenten in einem Workspace können über einen internen Message-Bus miteinander kommunizieren. Ein Agent kann einen anderen um Hilfe bitten, Ergebnisse teilen, oder neue Agenten spawnen. Was passiert, wenn man das zu weit treibt, habe ich in einem anderen Artikel beschrieben: Die Nacht, in der sich unsere KI-Redaktion selbst erfunden hat — dort haben 9 Agenten über Nacht 6.606 Nachrichten und 129 Artikel produziert. Faszinierend und beängstigend zugleich.

Docker-Isolation — die harte Grenze

Workspace-Isolation auf Applikationsebene ist gut. Aber wenn man eine Plattform für mehrere Nutzer baut, reicht Software-Isolation nicht. Deshalb läuft EpicClaws komplett containerisiert:

graph TD
    H["Host"] --> C1["API"]
    H --> C2["PG"]
    H --> C3["Redis"]
    H --> C4["Worker"]
    C1 --> N["Network"]
    C2 --> N
    C3 --> N
    C4 --> N
    C4 --> V["Volumes"]
    style H fill:#1A1A1A,stroke:#fff,stroke-width:2px,color:#fff
    style N fill:#1A1A1A,stroke:#C8FF00,stroke-width:2px,color:#fff
    style V fill:#1A1A1A,stroke:#C8FF00,stroke-width:2px,color:#fff
    style C1 fill:#FF3D00,stroke:#fff,stroke-width:2px,color:#fff
    style C2 fill:#FF3D00,stroke:#fff,stroke-width:2px,color:#fff
    style C3 fill:#FF3D00,stroke:#fff,stroke-width:2px,color:#fff
    style C4 fill:#FF3D00,stroke:#fff,stroke-width:2px,color:#fff

Jeder Service — API, PostgreSQL, Redis, Worker — läuft in einem eigenen Docker-Container. Die Container kommunizieren nur über ein internes Docker-Netzwerk. Kein Service ist direkt von außen erreichbar außer dem API-Gateway.

Das Entscheidende: Die Workspace-Dateisysteme sind als Docker Volumes gemountet. Jeder Workspace bekommt sein eigenes Volume. Ein Agent in Workspace A kann physisch nicht auf die Dateien von Workspace B zugreifen — das ist keine Software-Regel, sondern eine Betriebssystem-Grenze.

Dazu kommt: Die Container laufen mit reduzierten Capabilities. Kein --privileged, kein Host-Netzwerk, kein Zugriff auf den Docker-Socket. Die Agent-Container sind zusätzlich mit Ressource-Limits versehen — CPU, Memory, Disk I/O. Ein durchdrehender Agent kann seinen Container auslasten, aber nicht den Host.

Safety Controls

Die Docker-Isolation schützt auf Infrastruktur-Ebene. Aber innerhalb eines Workspaces braucht man auch Leitplanken — sonst machen Agenten einfach weiter, bis das Token-Budget aufgebraucht ist.

graph TD
    R["Request"] --> D1{"Depth?"}
    D1 -->|OK| D2{"Rate?"}
    D1 -->|Nein| S1["Block"]
    D2 -->|OK| D3{"Loop?"}
    D2 -->|Nein| S2["Drossel"]
    D3 -->|Nein| OK["OK"]
    D3 -->|Ja| S3["Stop"]
    style S1 fill:#FF3D00,stroke:#fff,stroke-width:2px,color:#fff
    style S2 fill:#FF3D00,stroke:#fff,stroke-width:2px,color:#fff
    style S3 fill:#FF3D00,stroke:#fff,stroke-width:2px,color:#fff
    style OK fill:#1A1A1A,stroke:#C8FF00,stroke-width:2px,color:#fff

Depth Limits: Maximale Rekursionstiefe für Agent-zu-Agent-Aufrufe. Default: 5 Ebenen.
Rate Limits: Maximale Nachrichten pro Agent pro Zeitfenster. Kein Agent kann den Bus flooden.
Anti-Ping-Pong: Erkennung von zirkulären Mustern. Endlosschleifen zwischen Agenten werden unterbrochen.
Heartbeat: Jeder Agent sendet regelmäßig ein Signal. Hängt ein Agent, wird er nach Timeout beendet.
Budget-Tracking: Token-Verbrauch pro Workspace und Agent. Bei Überschreitung wird pausiert, nicht abgebrochen.

Was EpicClaws heute kann

Multi-Tenant mit Workspace-Isolation — Komplett getrennte Umgebungen pro Nutzer, jeder Agent in eigenem Docker-Container
Tool-System mit dynamischer Komposition — Plug-and-Play für Agent-Fähigkeiten
Canvas — Ein shared Document-Space, in dem Agenten und Menschen gemeinsam arbeiten
Secrets Management — Verschlüsselte API-Key-Verwaltung pro Workspace
Team-Kommunikation — Agenten können delegieren und Ergebnisse teilen
Heartbeat + Monitoring — Live-Übersicht über alle aktiven Agenten
Echtzeit-UI — Native macOS/iOS-App + Web-Frontend, alles über WebSockets
Docker-Deployment — Komplettes Container-Setup mit isolierten Volumes

Wie es weitergeht

EpicClaws ist noch nicht fertig. Es wird wahrscheinlich nie "fertig" sein — dafür bewegt sich das Feld zu schnell. Aber es ist an einem Punkt, wo es produktiv nutzbar ist. Nächste Schritte: MCP-Integration für breitere Tool-Unterstützung, ein Marketplace für Tool-Packages, und bessere Observability-Tools, damit man nachvollziehen kann, warum Agenten bestimmte Entscheidungen treffen.

Das Ziel war nie, das nächste Framework zu bauen. Es war, eine Plattform zu haben, auf der man Agent-Teams deployen kann, die tatsächlich nützliche Arbeit leisten — sicher, isoliert, und nachvollziehbar.