Agent-Kommunikation & State

Wenn mehrere Agents zusammenarbeiten, wird Kommunikation zur größten Herausforderung. Wie übergeben Agents Daten? Wo wird der gemeinsame Zustand gespeichert? Wie werden Konflikte gelöst? Dieses Kapitel zeigt die bewährten Muster für n8n Multi-Agent-Systeme.

Message Passing zwischen Sub-Workflows

Direktes Message Passing

Der einfachste Ansatz: Der Orchestrator übergibt Daten als Parameter an Sub-Workflows.

{
  "execute_workflow": {
    "workflowId": "researcher-agent",
    "input": {
      "task": "Recherchiere aktuelle Trends in Edge AI",
      "context": { "previous_findings": [], "iteration": 1 },
      "config": { "max_sources": 5, "language": "de" }
    }
  }
}

Message Queue Pattern

Für komplexere Systeme nutzen Sie eine Message Queue zwischen Agents:

Producer Agent → Redis Queue → Consumer Agent
                    ↓
              Dead Letter Queue (bei Fehlern)

Pattern	Vorteile	Nachteile
Direkt	Einfach, synchron, sofortige Ergebnisse	Keine Entkopplung, Blocking
Queue	Entkoppelt, skalierbar, retry-fähig	Komplexer, eventuelle Konsistenz
Pub/Sub	Mehrere Consumer, event-driven	Reihenfolge nicht garantiert

Shared Databases für persistenten State

Für State, der über einzelne Executions hinaus bestehen muss, nutzen Sie eine Datenbank:

Schema-Design für Multi-Agent State

CREATE TABLE agent_sessions (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  pipeline_id UUID NOT NULL,
  agent_name TEXT NOT NULL,
  status TEXT DEFAULT 'pending', -- pending, running, completed, failed
  input_data JSONB,
  output_data JSONB,
  started_at TIMESTAMPTZ,
  completed_at TIMESTAMPTZ,
  error_message TEXT
);

CREATE TABLE agent_state (
  pipeline_id UUID NOT NULL,
  key TEXT NOT NULL,
  value JSONB NOT NULL,
  updated_by TEXT NOT NULL,
  updated_at TIMESTAMPTZ DEFAULT now(),
  PRIMARY KEY (pipeline_id, key)
);

State-Zugriff in n8n

-- Researcher schreibt Ergebnisse
INSERT INTO agent_state (pipeline_id, key, value, updated_by)
VALUES ($1, 'research_findings', $2::jsonb, 'researcher')
ON CONFLICT (pipeline_id, key) DO UPDATE SET value = $2::jsonb, updated_by = 'researcher';

-- Writer liest Ergebnisse
SELECT value FROM agent_state
WHERE pipeline_id = $1 AND key = 'research_findings';

Redis für Echtzeit-State

Für schnellen, flüchtigen State zwischen Agents eignet sich Redis:

Use Case	Redis-Struktur	TTL
Agent-Status	`Hash: pipeline:{id}:status`	1 Stunde
Zwischenergebnisse	`String: pipeline:{id}:agent:{name}:result`	30 Min
Locks	`String: pipeline:{id}:lock:{resource}`	60 Sek
Zähler	`Incr: pipeline:{id}:iteration`	1 Stunde

Distributed Locking

Wenn mehrere Agents auf dieselbe Ressource zugreifen, vermeiden Sie Race Conditions mit Redis Locks:

SET pipeline:abc:lock:database LOCKED NX EX 60
-- NX = nur setzen wenn nicht existiert
-- EX 60 = automatisch nach 60 Sekunden freigeben

Conflict Resolution

Was passiert, wenn zwei Agents widersprüchliche Ergebnisse liefern?

Strategien

Last Writer Wins: Einfach, aber riskant — der letzte Agent überschreibt
Voting: Mehrere Agents bewerten, Mehrheit gewinnt
Orchestrator-Entscheidung: Der Orchestrator wählt basierend auf Confidence-Scores
Human-in-the-Loop: Bei niedrigem Confidence wird ein Mensch einbezogen

Voting-Beispiel in n8n

{
  "function": "const results = items.map(i => i.json);\nconst approved = results.filter(r => r.decision === 'APPROVE').length;\nconst total = results.length;\nreturn [{ json: { decision: approved > total/2 ? 'APPROVE' : 'REVISE', votes: { approved, total } } }];"
}

Praxis-Tipp: Starten Sie mit direktem Message Passing und PostgreSQL für State. Fügen Sie Redis nur hinzu, wenn Sie Echtzeit-Koordination brauchen (z. B. parallele Agents, die denselben State lesen/schreiben). Für 90 % der Use Cases reicht die einfache Variante.