Multi-Agent-Systeme in Claude: Architektur-Entscheidungen, die tatsächlich zählen

Das Problem: Komplexität als falscher Trigger

Die meisten Entwickler greifen zu Multi-Agent-Architekturen, sobald eine Aufgabe komplex wirkt.

Das ist fast immer der falsche Reflex.

Die richtige Frage lautet nicht: 'Brauche ich mehrere Agents?' Sondern: Welche Art von Koordination braucht diese Aufgabe wirklich?

Die Antwort darauf determiniert deine gesamte Architektur.

Zwei Paradigmen, zwei Problemklassen

Claude bietet zwei distinkte Multi-Agent-Modelle. Oberflächlich ähnlich. Architektonisch lösen sie fundamental unterschiedliche Probleme.

Sub-Agents vs. Agent Teams im Überblick:
• Lebenszyklus: Kurzlebig (Fire-and-Forget) vs. Persistent (Long-Running)
• Kommunikation: Nur mit Parent vs. Peer-to-Peer + Lead
• State: Isoliert vs. Shared Task List
• Use Case: Parallelisierbare Recherche vs. Koordinierte Kollaboration
• Spawn-Tiefe: Flach (keine Sub-Sub-Agents) vs. Flach (Team-Struktur)

Sub-Agents: Parallelismus durch Isolation

Mental Model

Stell dir vor, du bist Research Lead. Du liest nicht jede Primärquelle selbst. Du delegierst fokussierte Fragen an Researcher. Die liefern verdichtete Findings. Du synthetisierst.

Genau das sind Sub-Agents.

Architektur-Eigenschaften

Jeder Sub-Agent erhält:

• Eigenen System Prompt (Spezialisierung)
• Eigenes Tool-Set (Zugriffskontrolle)
• Isoliertes Context Window (keine Kontamination)
• Eine Aufgabe (Single Responsibility)

Nach Completion: Nur das Ergebnis fließt zurück. Kein Reasoning-Chain. Keine Zwischenschritte. Nur das komprimierte Signal.

Der eigentliche Zweck

Sub-Agents sind nicht primär für Parallelismus da – sie sind für Kompression.

Du destillierst massive Exploration in ein sauberes Signal, ohne das Context Window des Parent mit Noise zu verschmutzen.

Hard Constraints (bewusst so designed)

• Sub-Agents können keine Sub-Sub-Agents spawnen
• Sub-Agents können nicht untereinander kommunizieren
• Alles fließt zurück zum Parent

Das ist kein Limitation – das ist ein Feature. Du weißt immer, wo Information fließt und wo Entscheidungen getroffen werden.

SDK-Beispiel

Das description-Feld ist das Routing-Signal. Der Parent entscheidet anhand dieser Beschreibung, welchen Sub-Agent er invoked. Keep it specific.

Beispiel-Code (Python):

from claude_agent_sdk import query, ClaudeAgentOptions, AgentDefinition

async def main():
async for message in query(
prompt="Review the authentication module for security vulnerabilities",
options=ClaudeAgentOptions(
allowed_tools=["Read", "Grep", "Glob", "Agent"],
agents={
"security-reviewer": AgentDefinition(
description="Security specialist. Use for vulnerability checks and security audits.",
prompt="You are a security specialist with expertise in identifying vulnerabilities.",
tools=["Read", "Grep", "Glob"],
model="sonnet",
),
},
),
):
print(message)

Agent Teams: Koordination durch Kommunikation

Mental Model

Der Unterschied zu Sub-Agents ist wie der zwischen Freelancern für isolierte Tasks vs. einem Team, das im selben Raum arbeitet.

Die drei Komponenten

• Team Lead: Koordiniert, delegiert, synthetisiert
• Teammates: Unabhängige Agent-Instanzen mit eigenem Context Window
• Shared Task List: Tracks Pending, In Progress, Done + Dependencies

Typischer Lifecycle

Phase 1 – Planning: Lead spawnt den Architekten (Plan Mode required)
Phase 2 – Implementation (parallel): Backend-Dev + Frontend-Dev + Test-Writer
Das blockedBy-Feld: Der Test-Writer startet erst, wenn der Backend-Dev fertig ist – ohne manuelles Orchestrieren durch den Lead.

Der fundamentale Unterschied

Peer-to-Peer-Kommunikation.

Teammates können:
• Direkt miteinander Messages senden
• Findings sharen
• Blocker surfacen
• Verhandeln – ohne dass alles durch den Lead routed wird

Du kannst auch direkt mit einzelnen Teammates interagieren, nicht nur über den Lead.

Die Entscheidungs-Heuristik

Sub-Agents wenn:

• Arbeit ist embarrassingly parallel
• Unabhängige Research-Streams
• Codebase Exploration
• Lookups, bei denen Parent nur Summary braucht

Agent Teams wenn:

• Arbeit erfordert ongoing negotiation
• Agents müssen Outputs reconcilen, bevor sie weitermachen
• Discovery in Thread A ändert, was Thread B tun sollte

Design First Principles: Context-Centric Decomposition

Das Anti-Pattern

Die meisten Multi-Agent-Designs scheitern, weil sie nach Rollen splitten statt nach Context.

Intuitiv: Planner → Implementer → Tester. Fühlt sich organisiert an.

Realität: Telephone Game. Information degradiert bei jedem Handoff. Implementer hat nicht, was Planner wusste. Qualität droppt an jeder Boundary.

Das richtige Mental Model

Frage: Welchen Context braucht dieser Subtask wirklich?

• Wenn zwei Subtasks deeply overlapping Information brauchen → selber Agent
• Wenn sie mit truly isolated Information und clean Interfaces operieren können → hier splitten

Praxis-Beispiel

Ein Agent, der ein Feature implementiert, sollte auch die Tests für dieses Feature schreiben.

Warum? Er hat bereits den Context. Splitting in separate Agents erzeugt ein Handoff-Problem, das mehr kostet als der Parallelism spart.

Nur separieren, wenn Context genuinely isoliert werden kann.

Die fünf Orchestration Patterns

1. Prompt Chaining: Sequentielle Steps, jeder Call processed Previous Output. Use Case: Order matters, Steps sind dependent.

2. Routing: Classifier entscheidet, welcher Handler den Task bekommt. Use Case: Cost Control – Easy → Cheap Model, Hard → Capable Model.

3. Parallelization: Unabhängige Subtasks laufen simultan (Voting oder Sectioning).

4. Orchestrator-Worker: Central Agent breaks down, delegates, synthesizes. Dominante Architektur für Production Systems.

5. Evaluator-Optimizer: Generator → Evaluator → Feedback Loop. Use Case: Quality > Speed.

Wann Multi-Agent-Systeme die falsche Wahl sind

Der Teil, den die meisten Artikel skippen.

Teams haben Monate in elaborierte Multi-Agent-Pipelines investiert – nur um zu discovern, dass besseres Prompting auf einem Single Agent äquivalente Ergebnisse lieferte.

Die Regel: Start simple. Add complexity only when measurably needed.

Wann Multi-Agent-Systeme ihren Cost earnen:

• Context Protection: Subtask generiert Information, die irrelevant für Main Task ist. Sub-Agent verhindert Context Bloat.
• True Parallelization: Unabhängige Research/Search Tasks, die von simultaner Coverage profitieren.
• Specialization: Task erfordert conflicting System Prompts, oder ein Agent juggled so viele Tools, dass Performance degradiert.

Wann sie die falsche Wahl sind:

• Agents müssen konstant Context miteinander sharen
• Inter-Agent-Dependencies erzeugen mehr Overhead als Execution Value
• Task ist simple genug, dass ein well-prompted Agent es handled

Spezifische Warnung für Coding

Parallele Agents, die Code schreiben, machen inkompatible Assumptions. Beim Merge conflicten diese impliziten Entscheidungen auf Weisen, die schwer zu debuggen sind.

Regel: Sub-Agents für Coding sollten Fragen beantworten und explorieren – nicht simultan mit dem Main Agent Code schreiben.

Die drei Failure Modes

1. Vague Task Descriptions

Agents duplizieren Work, weil sie nicht wissen, wo ihre Grenzen liegen.

Jeder Agent braucht:
• Clear Objective
• Expected Output Format
• Guidance on Tools/Sources
• Explicit Boundaries (was er nicht covern soll)

2. Verification Agents, die nicht verifizieren

Vage Approval-Kriterien produzieren False Positives.

Non-negotiable: Explizite, konkrete Instructions.
• Run full Test Suite
• Cover these specific Cases
• Do not mark as complete until each one passes

3. Token Costs compounderen

Die Lösung: Model Tiering.

• Most Capable Model: Wo es genuinely matters
• Fast/Cheap Models: Routine Work
• Budget Controls: Damit Costs nicht unkontrolliert laufen

Das eine Design-Prinzip, das wirklich zählt

Design around Context Boundaries – nicht um Roles oder Org Charts.

Der Workflow:

1. Start mit Single Agent
2. Push bis er bricht
3. Der Failure Point sagt dir exakt, was du hinzufügen musst
4. Add Complexity nur wo sie ein reales, gemessenes Problem löst

TL;DR – Decision Tree

Task ist komplex?

→ Kann ein Single Agent es mit besserem Prompting lösen? JA → Single Agent. Fertig.

→ Brauchen Subtasks isolierten Context? JA → Sub-Agents.

→ Müssen Agents während der Arbeit miteinander verhandeln? JA → Agent Teams.

→ Unsicher? Start Simple. Measure. Add Complexity only when needed.