Agentic Company Experience - Part 2: Einbindung von Slack

Nachdem ich im ersten Teil beschrieben habe, warum wir bei OpenClaw auf ein Multi-Agent-System setzen, geht es nun um Slack. Die Aufgabe klang zunächst überschaubar: OpenClaw-Agents sollten über Slack erreichbar sein. Was dabei herauskam, war deutlich komplexer als "Bot erstellen, Token eintragen, fertig".

Die eigentliche Herausforderung lag nicht in der technischen Anbindung, sondern in der sauberen Trennung mehrerer spezialisierter Agents mit jeweils eigener Slack-Identität. Kein Demo-Setup, sondern ein System, das im Dauerbetrieb stabil läuft.

Die Architektur: Fünf Agents, fünf Identitäten

Das finale System bestand aus fünf spezialisierten Agents:

Morpheuxx (main): Supervisor, Routing, Meta-Koordination
Tank: Utilities, pragmatische Tech- und Ops-Aufgaben
Trinity: Mail, Kontakte, externe Kommunikation
Oracle: Editorial, Blog, News, Social Media
Neo: Development, Code, technische Implementierung

Der entscheidende Punkt: Slack war nur die Kommunikationsoberfläche. Die eigentliche Rollenarchitektur lebte in Agent-IDs, Workspaces, Bindings und der internen Agent-zu-Agent-Kommunikation.

Warum ein Bot für alle nicht funktioniert

Ein einzelner Slack-Bot mag für simple Use Cases reichen. Bei mehreren Agents verschwimmen schnell die Grenzen:

Welcher Agent antwortet gerade?
Wer ist wofür zuständig?
Wie trennt man Kontexte sauber?
Wie verhindert man, dass ein Agent unter falscher Identität antwortet?

Die Lösung: Ein Bot pro Agent. Das erhöht den initialen Setup-Aufwand erheblich, reduziert aber spätere Debugging-Sessions drastisch.

Die technische Umsetzung in OpenClaw

OpenClaw unterstützt mehrere Slack-Accounts innerhalb einer Channel-Konfiguration:

{
  "channels": {
    "slack": {
      "mode": "socket",
      "webhookPath": "/slack/events",
      "enabled": true,
      "userTokenReadOnly": true,
      "groupPolicy": "allowlist",
      "streaming": "partial",
      "nativeStreaming": true,
      "accounts": {
        "morpheuxx": {
          "appToken": "xapp-...",
          "botToken": "xoxb-...",
          "signingSecret": "..."
        },
        "trinity": {
          "appToken": "xapp-...",
          "botToken": "xoxb-...",
          "signingSecret": "..."
        },
        "neo": {
          "...": "..."
        },
        "oracle": {
          "...": "..."
        },
        "tank": {
          "...": "..."
        }
      }
    }
  }
}

Jeder Account-Eintrag repräsentiert einen eigenen Bot mit eigenem `botToken` und `appToken`. Die Identitäten sind nicht nur verhaltensbasiert getrennt, sondern strukturell.

Der Knackpunkt: Routing über Bindings

Die robusteste Lösung für das Message-Routing:

{
  "bindings": [
    {
      "agentId": "main",
      "match": {
        "channel": "slack",
        "accountId": "morpheuxx"
      }
    },
    {
      "agentId": "trinity",
      "match": {
        "channel": "slack",
        "accountId": "trinity"
      }
    }

    // ... weitere Bindings
  ]
}

Jede eingehende Nachricht wird nicht nur als "Slack-Nachricht" behandelt, sondern deterministisch einem spezifischen Agent zugeordnet. Ohne `accountId`-Matching wäre das Routing zu grob. Mit `accountId` ist die Zuordnung eindeutig – stabiler als jede heuristische Bot-Erkennung oder Mention-Magie.

Die größten Fallen im Live-Betrieb

Implizite Defaults

Die Versuchung, einen `default`-Account für Rückfall-Szenarien zu definieren, ist groß. In der Praxis führt das zu Chaos:

Welche Messages landen im Default statt beim richtigen Agent?
Welcher Agent nutzt plötzlich den falschen Slack-Kontext?
Warum funktioniert nach einem Restart plötzlich nichts mehr wie erwartet?

Regel: Im Multi-Agent-Setup alles explizit benennen. Keine impliziten Defaults.

Der Doctor-Fix-Reflex

`openclaw doctor` ist ein nützliches Diagnose-Tool. `openclaw doctor --fix` kann jedoch gefährlich werden. Ein konkretes Beispiel: Doctor wollte Slack-Konfigurationen in ein neues Schema migrieren und dabei Top-Level-Werte nach `channels.slack.accounts.default` verschieben.

Was harmlos klingt, kann ein sorgfältig konfiguriertes Multi-Agent-Setup zerstören. Es gibt keinen sauberen Weg, einzelne Doctor-Migrationen zu ignorieren. Die Optionen:

Doctor nur zur Diagnose nutzen
Migrationen im Code anpassen
Änderungen manuell durchführen

Inter-Agent-Kommunikation

Die anfängliche Idee, Agents sichtbar über Slack miteinander kommunizieren zu lassen, erwies sich als problematisch:

Unnötiger Slack-Traffic
Erhöhte Routing-Komplexität
Schwierigere Trennung zwischen interner Orchestrierung und Human-Kommunikation

Bessere Lösung: Agent-zu-Agent-Kommunikation läuft intern. Slack bleibt primär für die Kommunikation mit Menschen reserviert.

Was sich im Dauerbetrieb bewährt hat

Klare Rollendefinition

Jeder Agent muss das komplette Roster kennen und verstehen, wer für was zuständig ist. Das ermöglicht saubere interne Handoffs ohne sichtbare Slack-Nachrichten.

Explizite Permissions

```json "groupPolicy": "allowlist", "userTokenReadOnly": true ```

Diese Einstellungen verhindern, dass Bots automatisch überall Zugriff haben und begrenzen den Scope auf das Notwendige.

Durchdachte Gateway-Restarts

Ein Gateway-Restart mag technisch "nur kurz" sein, kann aber laufende Agent-Arbeiten unterbrechen. Regel: Keine strukturellen Restarts während aktiver Agent-Tasks.

Die wichtigsten Learnings

Ein Bot pro Agent lohnt sich: Der Mehraufwand beim Setup zahlt sich durch klare Identitäten und weniger Debugging aus.

Bindings sind zentral: Nicht die Slack-Apps selbst, sondern das explizite Routing macht das System stabil.

Defaults sind Gift: Was in Single-Agent-Setups praktisch ist, wird im Multi-Agent-Betrieb zur Fehlerquelle.

Doctor ist nicht immer richtig: Automatische Fixes können spezialisierte Setups zerstören.

Interne Kommunikation bevorzugen: Sichtbare Agent-Gespräche in Slack sind selten die richtige Lösung.

Fazit

Die technische Lösung war weniger "cleverer Slack-Hack" als vielmehr konsequente Architektur: Mehrere echte Bot-Identitäten, explizites Binding-Routing, interne Agent-Orchestrierung und gesundes Misstrauen gegenüber impliziten Defaults.

Das Setup ist aufwändiger als ein einzelner Bot für alles. Aber sobald mehrere spezialisierte Agents im Spiel sind, ist es die einzig saubere Lösung. Die Alternative wäre ein System, das zwar schnell aufgesetzt ist, aber im Dauerbetrieb ständig Überraschungen produziert.