Matrix als Kommunikationsschicht für Agenten-Loops

Die meisten Tutorials zu Agenten-Loops zeigen Telegram-Bots. Das ist verständlich: Telegram hat eine gute Bot-API, ist weit verbreitet und der Einstieg ist niedrigschwellig. Aber für ernsthaften produktiven Einsatz – insbesondere für Agenten, die miteinander kommunizieren sollen – hat Telegram ein fundamentales Problem: Es ist zentralisiert, proprietär und unter der Kontrolle eines einzigen Unternehmens.

Das Matrix-Protokoll bietet eine technisch interessante Alternative. Nicht nur als Messenger für Menschen, sondern als Kommunikationsschicht für Agenten-Infrastruktur.

Was ist Matrix überhaupt?

Matrix ist ein offenes, dezentrales Kommunikationsprotokoll. Nicht ein Produkt, nicht eine App – ein Protokoll. Vergleichbar mit E-Mail: Es gibt viele Anbieter, viele Clients, aber alle sprechen dieselbe Sprache.

Die wichtigsten Eigenschaften:

Föderiert: Jeder kann einen eigenen Homeserver betreiben. Nachrichten werden zwischen Servern synchronisiert.
Ende-zu-Ende-Verschlüsselt: Optional per Olm/Megolm, dem gleichen Kryptografieprotokoll wie bei Signal.
Persistent: Rooms haben einen unveränderlichen History-State. Neue Teilnehmer können die gesamte Vorgeschichte sehen.
Event-basiert: Alles in Matrix ist ein Event – Nachrichten, Reaktionen, Statusänderungen, Custom Events.

Die bekannteste Client-Implementierung ist Element, aber es gibt Dutzende weitere. Für Agenten-Kommunikation ist der Client irrelevant – relevant ist die API.

Warum nicht einfach Telegram oder WhatsApp?

Die kurze Antwort: Plattformrisiko, Rate Limits, Terms of Service.

Telegrams Bot-API ist gut dokumentiert und schnell zu integrieren. Aber:

Zentralisiert: Alle Nachrichten laufen über Telegrams Server. Kein Self-Hosting möglich.
ToS-Risiko: Agenten-Traffic widerspricht potenziell Telegrams Nutzungsbedingungen, insbesondere bei hohem automatisiertem Volumen.
Rate Limits: Aggressive Limits für Bots (30 Nachrichten pro Sekunde global, 1 Nachricht pro Sekunde pro Chat). Für Agenten-Loops, die schnell kommunizieren müssen, ein echtes Problem.
Kein Custom Protocol: Man kann nur das senden, was Telegram erlaubt: Text, Medien, Inline-Buttons. Keine strukturierten Custom Events.

WhatsApp ist für automatisierten Agenten-Traffic schlicht ungeeignet:

Offizielle Business-API ist teuer und auf menschliche Kommunikation ausgerichtet.
Inoffizielle Clients (Baileys, WWebJS) riskieren Account-Bans.
Keine persistente History ohne eigene Datenbank.
Meta-Abhängigkeit.

Matrix

Matrix hat keines dieser Probleme – aber bringt eigene Komplexität mit.

Die Matrix Client-Server API

Der Einstiegspunkt für Agenten-Integration ist die Client-Server API. Matrix-Homeserver exponieren eine REST-API, über die man Rooms erstellen, betreten, verlassen und Nachrichten senden kann.

# Auf eigenem Homeserver einloggen (Synapse, Dendrite, Conduit...)
curl -X POST https://matrix.example.com/_matrix/client/v3/login \
  -H "Content-Type: application/json" \
  -d '{
    "type": "m.login.password",
    "user": "agent-orchestrator",
    "password": "supersecret"
  }'

# Response: { "access_token": "syt_...", "user_id": "@agent-orchestrator:example.com" }

Mit dem Access Token kann der Agent dann auf Rooms zugreifen:

# Room erstellen für Agent-Kommunikation
curl -X POST https://matrix.example.com/_matrix/client/v3/createRoom \
  -H "Authorization: Bearer syt_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "agent-coordination",
    "topic": "Internal coordination channel for agent swarm",
    "preset": "private_chat",
    "initial_state": []
  }'

Custom Events: Mehr als Nachrichten

Das wirklich interessante Feature für Agenten-Kommunikation sind Custom Events. Matrix erlaubt es, beliebige Event-Typen zu definieren:

// Task-Delegation als Matrix Custom Event
await matrixClient.sendEvent(roomId, "com.example.agent.task", {
  task_id: "task-7f3a9b",
  type: "research",
  priority: "high",
  payload: {
    query: "Aktuelle Entwicklungen bei Matrix-Homeservern",
    max_results: 10,
    deadline_ms: Date.now() + 30000
  },
  requester: "@orchestrator:example.com",
  assigned_to: "@researcher-agent:example.com"
});

// Status-Update vom ausführenden Agenten
await matrixClient.sendEvent(roomId, "com.example.agent.status", {
  task_id: "task-7f3a9b",
  status: "in_progress",
  progress_pct: 40,
  intermediate_result: null,
  agent: "@researcher-agent:example.com"
});

// Ergebnis als strukturiertes Event
await matrixClient.sendEvent(roomId, "com.example.agent.result", {
  task_id: "task-7f3a9b",
  status: "completed",
  result: { /* strukturierte Daten */ },
  tokens_used: 1240,
  duration_ms: 18430
});

Custom Events sind persistiert, auditierbar und für alle Room-Mitglieder (auch nachträglich beigetretene) sichtbar. Das ist fundamentaler Unterschied zu einem einfachen Message-Queue.

Architekturmodell: Matrix als Agent-Bus

Ein typisches Modell für eine Agenten-Infrastruktur auf Basis von Matrix:

┌─────────────────────────────────────────────────────┐
│                  Matrix Homeserver                    │
│                  (Self-hosted: Synapse)               │
│                                                       │
│  #orchestration:example.com  (Hauptkoordination)     │
│  #research:example.com       (Research-Agenten)      │
│  #execution:example.com      (Execution-Agenten)     │
│  #monitoring:example.com     (Logs, Metriken)        │
│  #human-review:example.com   (Human-in-the-Loop)     │
└─────────────────────────────────────────────────────┘
         │              │              │
         ▼              ▼              ▼
  Orchestrator    Research-        Execution-
     Agent        Agent Pool       Agent Pool
  (@orch:ex.com) (@r1:ex.com)    (@e1:ex.com)
                 (@r2:ex.com)    (@e2:ex.com)

Jeder Agent ist ein Matrix-User auf dem Self-Hosted Homeserver. Rooms strukturieren die Kommunikation nach Funktion, nicht nach Technologie. Der Orchestrator postet Tasks in den entsprechenden Channel, Agenten pollen über die Sync-API auf neue Events.

Syncing: Wie Agenten neue Events empfangen

Matrix nutzt Long-Polling für Echtzeit-Updates:

import asyncio
import httpx

class MatrixAgent:
    def __init__(self, homeserver: str, access_token: str):
        self.homeserver = homeserver
        self.headers = {"Authorization": f"Bearer {access_token}"}
        self.next_batch = None

    async def sync(self):
        """Long-Poll für neue Events."""
        params = {
            "timeout": 30000,  # 30 Sekunden warten
            "filter": json.dumps({
                "room": {
                    "timeline": {
                        "types": [
                            "com.example.agent.task",
                            "com.example.agent.status",
                            "m.room.message"
                        ]
                    }
                }
            })
        }
        if self.next_batch:
            params["since"] = self.next_batch

        async with httpx.AsyncClient() as client:
            resp = await client.get(
                f"{self.homeserver}/_matrix/client/v3/sync",
                headers=self.headers,
                params=params,
                timeout=35.0
            )
            data = resp.json()
            self.next_batch = data["next_batch"]
            return data

    async def run(self):
        """Event-Loop für den Agenten."""
        while True:
            sync_data = await self.sync()
            for room_id, room_data in sync_data.get("rooms", {}).get("join", {}).items():
                for event in room_data.get("timeline", {}).get("events", []):
                    await self.handle_event(room_id, event)

    async def handle_event(self, room_id: str, event: dict):
        event_type = event.get("type")
        if event_type == "com.example.agent.task":
            await self.process_task(room_id, event["content"])
        # weitere Event-Handler...

Skalierung und Isolation

Einer der größten Vorteile des föderalen Modells: Man kann mehrere Homeserver betreiben und Agenten-Swarms isolieren.

# docker-compose.yml für Synapse Homeserver

services:
  synapse:
    image: matrixdotorg/synapse:latest
    environment:
      - SYNAPSE_CONFIG_PATH=/data/homeserver.yaml
    volumes:
      - ./synapse-data:/data
    ports:
      - "8448:8448"  # Federation
      - "8008:8008"  # Client API

  # Agenten können direkt mit dem Homeserver kommunizieren
  # ohne externe Abhängigkeiten

Die Homeserver-Konfiguration erlaubt granulare Kontrolle:

# homeserver.yaml (Ausschnitt)

# Registrierung auf bestimmte Domains beschränken
registration_requires_token: true
enable_registration: false

# Rate Limits anpassen für Agenten-Traffic
rc_message:
  per_second: 50    # Standard: 0.2 – für Agenten viel zu niedrig
  burst_count: 200

rc_joins:
  per_second: 10
  burst_count: 100

# Retention für Agent-Rooms konfigurieren
retention:
  enabled: true
  default_policy:
    min_lifetime: 1d
    max_lifetime: 30d

Matrix vs. Message Queues (Redis, RabbitMQ)

Eine berechtigte Frage: Warum nicht einfach Redis Pub/Sub oder RabbitMQ verwenden?

Feature	Matrix	Redis Pub/Sub	RabbitMQ
Persistence	Ja, vollständig	Nein (optional AOF)	Ja
Human-readable	Ja	Nein	Nein
Human-in-the-Loop	Nativ	Nicht vorgesehen	Nicht vorgesehen
Verschlüsselt	E2E möglich	TLS only	TLS only
Föderiert	Ja	Nein	Clustering
Audit-Log	Eingebaut	Extra Tooling	Extra Tooling
Auth/ACL	Room-basiert	Einfach	AMQP-basiert

Matrix ist kein Ersatz für einen Message Broker – es ist eine andere Kategorie. Der entscheidende Unterschied: Matrix-Rooms sind für Menschen lesbar und zugänglich. Das macht Human-in-the-Loop-Workflows trivial: Ein Mensch betritt einfach den Room und liest mit (oder greift ein).

# Human-in-the-Loop: Agent wartet auf menschliche Freigabe
async def request_human_approval(self, room_id: str, action: dict) -> bool:
    """
    Postet eine Anfrage im Room und wartet auf m.reaction mit Thumbs-up.
    Menschen können via Element oder anderen Matrix-Clients antworten.
    """
    event_id = await self.send_message(
        room_id,
        f"Approval required for action:\n```json\n{json.dumps(action, indent=2)}\n```\n"
        f"React with 👍 to approve or 👎 to reject."
    )

    # Warte auf Reaction-Event vom autorisierten User
    timeout = asyncio.create_task(asyncio.sleep(300))  # 5 min Timeout
    approval = asyncio.create_task(self.wait_for_reaction(event_id))

    done, pending = await asyncio.wait(
        [timeout, approval], return_when=asyncio.FIRST_COMPLETED
    )
    for task in pending:
        task.cancel()

    if approval in done:
        reaction = await approval
        return reaction["key"] == "👍"
    return False  # Timeout = abgelehnt

Element als Monitoring-Interface

Da Element (oder jeder andere Matrix-Client) nativ die gleichen Räume zeigt, bekommt man ein kostenloses Monitoring-Interface. Kein extra Dashboard, kein Grafana-Plugin – einfach den Room betreten und alle Agent-Events live sehen.

Das ist besonders wertvoll in der Debugging-Phase: Man sieht exakt, welcher Agent welches Event zu welchem Zeitpunkt gesendet hat, mit vollem Kontext. Das Audit-Log ist das Protokoll selbst.

SDK-Unterstützung

Für die Integration stehen gut gepflegte SDKs zur Verfügung:

# JavaScript/TypeScript
npm install matrix-js-sdk

# Python
pip install matrix-nio  # oder matrix-bot-sdk

# Go
go get maunium.net/go/mautrix

# Rust
cargo add ruma

Das matrix-js-sdk ist das umfassendste und wird von Element direkt genutzt:

import sdk from "matrix-js-sdk";

const client = sdk.createClient({
  baseUrl: "https://matrix.example.com",
  accessToken: process.env.MATRIX_ACCESS_TOKEN,
  userId: "@agent-orchestrator:example.com",
});

client.on(sdk.RoomEvent.Timeline, (event, room) => {
  if (event.getType() === "com.example.agent.task") {
    const content = event.getContent();
    handleIncomingTask(content);
  }
});

await client.startClient({ initialSyncLimit: 10 });

Bridging: Das Beste aus beiden Welten

Matrix hat ein ausgereiftes Bridge-Ökosystem. Wenn Agenten trotzdem mit Telegram- oder WhatsApp-Nutzern kommunizieren müssen, können Matrix-Bridges das abbilden:

mautrix-telegram: Bridges Matrix-Rooms zu Telegram-Chats
mautrix-whatsapp: WhatsApp-Integration
mautrix-signal: Signal-Anbindung

Agent → Matrix Room ←→ mautrix-telegram Bridge ←→ Telegram Chat (Mensch)

Der Agent kommuniziert immer über Matrix. Die Bridge übernimmt die Übersetzung in die jeweilige Plattform. Plattformwechsel sind dann eine Konfigurationsänderung, keine Code-Änderung.

Wann Matrix sinnvoll ist – und wann nicht

Matrix ist nicht immer die richtige Wahl. Eine ehrliche Einschätzung:

Sinnvoll, wenn:

Multi-Agenten-Systeme mit vielen kommunizierenden Entitäten
Human-in-the-Loop-Workflows notwendig sind
Audit-Log und Persistenz wichtig sind
Datensouveränität (Self-Hosting) gefordert ist
Langfristig gebaut wird (kein Plattformrisiko)

Weniger sinnvoll, wenn:

Einfache Single-Agent-Setups mit einem Telegram-Bot ausreichen
Team bereits intensive RabbitMQ/Redis-Expertise hat
Minimaler Infrastruktur-Overhead gewünscht wird
Prototype-Phase, wo Schnelligkeit wichtiger ist als Architektur

Fazit

Das Matrix-Protokoll ist unterbewertet in der Agenten-Infrastruktur-Diskussion. Es bietet etwas, das klassische Message Queues nicht haben: eine persistente, menschenlesbare, föderierte Kommunikationsschicht, die Human-in-the-Loop-Workflows nativ unterstützt.

Die Komplexität ist real – ein Self-Hosted Synapse-Server ist kein trivialer Betrieb. Aber die Vorteile sind es wert: Kein Vendor-Lock-in, keine ToS-Risiken, keine Rate-Limit-Überraschungen, ein eingebautes Audit-Log und ein echtes Multi-Agent-Koordinationsmodell.

Für Teams, die ernsthaft in Agenten-Infrastruktur investieren, lohnt es sich, Matrix nicht nur als Messenger für Menschen zu betrachten, sondern als Kommunikationsprotokoll für Systeme.

Feedback, Erfahrungen oder andere Architekturen? Gerne auf Twitter/X oder LinkedIn.