Multi-Agent Systeme mit Claude: Architektur-Entscheidungen, die über Erfolg oder Scheitern bestimmen

Warum Multi-Agent? Die ehrliche Antwort.

Bevor wir Architektur diskutieren, müssen wir die Frage beantworten: Wann braucht man überhaupt mehrere Agenten?

Die Antwort ist nüchterner als die Hype-Literatur vermuten lässt:

Multi-Agent-Systeme sind sinnvoll wenn:

• Die Aufgabe zu komplex für ein einziges Kontext-Fenster ist
• Parallele, unabhängige Subtasks die Gesamtlaufzeit dominieren
• Spezialisierung (verschiedene Tools, Prompts, Modelle) echten Qualitätsvorteil bringt
• Checkpoints und Verifikation zwischen Schritten kritisch sind

Multi-Agent-Systeme sind übertrieben wenn:

• Ein gut strukturierter Single-Agent-Prompt reicht
• Die Koordinations-Komplexität den Nutzen übersteigt
• Das Team nicht die Observability-Infrastruktur hat, Fehler zu debuggen

Mit dieser Grundlage: Hier sind die drei Architektur-Entscheidungen, die alles andere bestimmen.

Entscheidung 1: Orchestrator-Muster vs. Peer-to-Peer

Das Orchestrator-Muster

Ein zentraler Agent koordiniert alle anderen. Er kennt das Gesamtziel, delegiert Subtasks, aggregiert Ergebnisse.

import anthropic
from typing import Any

client = anthropic.Anthropic()

class OrchestratorAgent:
    """
    Zentraler Koordinator. Kennt das Ziel, nicht die Details.
    Subagenten kennen die Details, nicht das Ziel.
    """

    def __init__(self, subagents: dict[str, "SubAgent"]):
        self.subagents = subagents
        self.memory: list[dict] = []

    def run(self, task: str) -> str:
        # Schritt 1: Plan erstellen
        plan = self._create_plan(task)

        # Schritt 2: Schritte delegieren
        results = {}
        for step in plan["steps"]:
            agent_name = step["agent"]
            if agent_name in self.subagents:
                result = self.subagents[agent_name].execute(
                    task=step["task"],
                    context=results  # Vorherige Ergebnisse als Kontext
                )
                results[step["id"]] = result

        # Schritt 3: Synthese
        return self._synthesize(task, results)

    def _create_plan(self, task: str) -> dict:
        response = client.messages.create(
            model="claude-opus-4-6",
            max_tokens=1000,
            system="""Du bist ein Planungs-Assistent. Zerlege Aufgaben in
            Subtasks für spezialisierte Agenten. Antworte als JSON.""",
            messages=[{"role": "user", "content": task}]
        )
        import json
        return json.loads(response.content[0].text)

Stärken des Orchestrator-Musters:

• Klare Accountability — ein Agent "weiß" was passiert
• Einfacheres Debugging (zentrale Logs)
• Natürliche Checkpoints nach jedem Subtask

Schwächen:

• Single Point of Failure
• Orchestrator-Kontext wird schnell groß
• Bottleneck bei parallelen Tasks

Peer-to-Peer / Swarm

Agenten kommunizieren direkt miteinander, kein zentraler Koordinator.

Dieses Muster ist mächtiger, aber deutlich schwieriger zu debuggen. Für die meisten Enterprise-Anwendungen empfehle ich es nicht als Einstieg.

Meine Empfehlung: Starte mit Orchestrator. Wechsle nur zu Peer-to-Peer wenn du einen klaren, messbaren Engpass am Orchestrator hast.

Entscheidung 2: Wann bekommt ein Subagent sein eigenes Modell?

Nicht jeder Subagent braucht Claude Opus. Die Modellwahl ist eine Kosten-Qualitäts-Entscheidung:

class SubAgent:
    def __init__(self, name: str, model: str, system_prompt: str):
        self.name = name
        self.model = model
        self.system_prompt = system_prompt
        self.client = anthropic.Anthropic()

    def execute(self, task: str, context: dict = {}) -> str:
        context_str = "\n".join([f"{k}: {v}" for k, v in context.items()])

        response = self.client.messages.create(
            model=self.model,
            max_tokens=2000,
            system=self.system_prompt,
            messages=[{
                "role": "user",
                "content": f"Kontext aus vorherigen Schritten:\n{context_str}\n\nAufgabe: {task}"
            }]
        )
        return response.content[0].text

# Konfiguration
researcher = SubAgent(
    name="researcher",
    model="claude-sonnet-4-6",  # Nicht Opus für Recherche
    system_prompt="Du bist ein Recherche-Assistent..."
)

extractor = SubAgent(
    name="extractor",
    model="claude-haiku-4-5-20251001",  # Haiku reicht für strukturierte Extraktion
    system_prompt="Extrahiere strukturierte Daten aus Text..."
)

Entscheidung 3: Zustandsmanagement zwischen Agenten

Wie teilen Agenten Informationen? Das ist die Entscheidung, die am häufigsten unterschätzt wird.

Option A: Shared Context (einfach, begrenzt)

Alle Agenten bekommen den vollständigen bisherigen Kontext. Funktioniert bis ~20.000 Token.

Option B: Structured Handoff (empfohlen für Produktion)

Jeder Agent gibt einen definierten Output-Typ weiter:

from dataclasses import dataclass
from typing import Optional

@dataclass
class AgentHandoff:
    """Standardisierter Übergabe-Typ zwischen Agenten."""
    step_id: str
    agent_name: str
    output: str
    structured_data: Optional[dict]  # Für Downstream-Agenten die Struktur brauchen
    confidence: float  # 0.0 - 1.0
    requires_review: bool  # Flag für Human-in-the-Loop

# Orchestrator aggregiert:
results: list[AgentHandoff] = []

Option C: External Memory (für long-running Agents)

Bei Tasks die länger als ein paar Minuten laufen: Redis, SQLite oder Vector Store als externes Gedächtnis.

Das Anti-Pattern: Agent-Soup

Das häufigste Scheitern von Multi-Agent-Systemen: Zu viele Agenten, zu unklare Grenzen.

Symptome:

• Kein klarer "Owner" einer Information
• Agenten wiederholen Arbeit des anderen
• Debugging erfordert das Nachverfolgen von 10+ Log-Streams
• Kosten explodieren, Output verbessert sich kaum

Die Regel: Jeder Agent hat genau eine klar definierte Aufgabe. Wenn du die Aufgabe nicht in einem Satz beschreiben kannst, ist der Agent zu breit.

Observability: Nicht optional

In Produktion ohne Observability zu deployen ist fahrlässig. Minimum-Setup:

import time
import logging
from functools import wraps

def trace_agent(func):
    """Decorator für Agent-Tracing."""
    @wraps(func)
    def wrapper(self, *args, **kwargs):
        start = time.time()
        logger = logging.getLogger(f"agent.{self.name}")

        logger.info(f"START | task_length={len(str(args[0]))}")

        try:
            result = func(self, *args, **kwargs)
            duration = time.time() - start
            logger.info(f"SUCCESS | duration={duration:.2f}s | output_length={len(result)}")
            return result
        except Exception as e:
            duration = time.time() - start
            logger.error(f"FAILED | duration={duration:.2f}s | error={str(e)}")
            raise

    return wrapper

Fazit: Wann man Multi-Agent wirklich braucht

Multi-Agent-Systeme sind kein Fortschrittszeichen — sie sind ein Werkzeug für ein spezifisches Problem.

Faustregel: Wenn dein Single-Agent-System mit einem gut strukturierten Prompt + Tools funktioniert, spar dir die Komplexität. Wenn du echte Parallelisierung, Spezialisierung oder Context-Grenzen brauchst — dann ist Multi-Agent die richtige Antwort.

Und dann: Fang mit Orchestrator an. Halte Agenten-Grenzen scharf. Baue Observability von Tag 1 ein.