ki-buch/teil-03-praxis/kapitel-08-multi-agenten-teams.md

Kapitel 8: Multi-Agenten-Teams für komplette Softwareprojekte

Teil III · Agentenbasierte Softwareentwicklung in der Praxis – MCP & Context Engineering im Fokus

---

„Lasst uns ein Multi-Agent-Team bauen“ ist der schnellste Weg zu Koordinationssteuer: fünf Rollen, die dieselben Dateien anfassen, endloser Agent-Chat ohne Deliverables, und niemand weiß, welche Version der Spec gilt. Ein starker Single-Agent mit gutem Harness und Context Engineering bleibt der Default. Multi-Agent lohnt erst, wenn die Arbeit strukturell mehrere Working Sets, Qualitätsbrillen oder echte Parallelität braucht – Querschnitt, Risiko, entkoppelbare Pakete.

These: Mehr Agenten sind kein Intelligenz-Multiplikator. Die gemeinsame Wahrheit liegt in MCP, Shared Context Stores und Handoff-Contracts, nicht im Gespräch der Agenten untereinander.

Leitfrage: Wann schlägt ein Agenten-Team einen starken Single-Agent – und wie orchestrierst du, ohne Chaos und Budgetexplosion?

Dieses Kapitel skaliert von Kapitel 5 und 7 zur Agenten-Organisation: Rollenmodell, Work Breakdown, Orchestrierung, Kosten, Konflikte und ein schlankes Referenzteam. Achte auf disjunkte Arbeitspfade, Budgets pro Rolle und Least-Privilege – Parallelität ohne Locks und ohne Shared Truth erzeugt teure Merge- und Spec-Konflikte. Es ist Checkliste bevor „Agenten-Orgs“ in die Roadmap wandern: erst Verträge und Shared Context, dann mehr Rollen. Integration in reale Tools folgt in Kapitel 9.

Lernziele

Nach diesem Kapitel kannst du:

• entscheiden, wann ein Multi-Agenten-Team einem starken Single-Agent überlegen ist – und wann nicht,
• Rollen, Verträge und Deliverables für projektweite Agenten-Orgs definieren,
• einen Issue→PR-Durchlauf mit Rollen und MCP-Servern skizzieren sowie größere Epics orchestrieren,
• Kosten-Nutzen von Multi-Agent-Setups realistisch einschätzen und steuern,
• Konflikt-, Qualitäts- und Budgetrisiken im Team-Maßstab beherrschen,
• MCP als zentrale Kontext- und Tool-Schicht für Multi-Agenten-Teams einsetzen,
• ein schlankes Referenzteam für euer Produkt skizzieren und schrittweise ausbauen.

---

Schicht	In diesem Kapitel	Stand
Stabil	Rollen, Handoff-Contracts, Shared Context	Prinzipien
Mittelstabil	Orchestrierungsmuster, Locks, Budgets pro Rolle	Muster
Volatil	konkrete Framework-Graph-Syntax	Juli 2026

{ width=100% }

8.1 Vom einzelnen Coding Agent zur Agenten-Org

Kapitel 5 und 7 haben die Bausteine geliefert. Hier geht es um Projekte – Wochenhorizont, mehrere Module, mehrere Qualitätsdimensionen. Die Frage ist nicht mehr „Kann ein Agent diesen Diff schreiben?“, sondern: Wie orchestrieren wir ein Vorhaben, ohne dass Parallelität in Chaos umschlägt?

Wann Multi-Agent?

Ein starker Single-Agent mit gutem Context Engineering bleibt der Default. Multi-Agent lohnt erst, wenn die Arbeit strukturell mehr als einen Working Set oder eine Qualitätsbrille braucht:

Signal	Single-Agent oft genug	Multi-Agent sinnvoll
Scope	ein Service, ein PR	Querschnitt, viele PRs
Skills	homogen (nur Code)	Spec, Code, Sec, Docs, QA
Risiko	niedrig	Compliance, Migration, Money Path
Parallelität	selten nötig	entkoppelbare Arbeitspakete
Kontext	ein Working Set	mehrere Working Sets + Shared Truth

Die Tabelle ist eine Heuristik, kein Automatismus. Entscheidend ist die Kopplung: Wenn zwei Arbeitspakete dieselben Dateien, denselben Vertrag oder dieselbe Produktionsentscheidung berühren, erzeugt Parallelität zuerst Reibung – und erst danach Speed.

Analogie: Ein starker Generalist baut das Gartenhaus. Ein Haus mit Statik, Elektrik und Abnahme braucht Gewerke, Pläne und eine Bauleitung – nicht fünf Leute, die gleichzeitig dieselben Wände tapezieren.

Anti-Hype: Mehr Agenten ≠ mehr Intelligenz. Mehr Agenten = mehr Koordinationssteuer. Die Steuer muss sich in Lead Time, Fehlerkosten oder Auditierbarkeit rentieren – sonst ist ein gut geführter Single-Agent (ggf. mit einem getrennten Verifier-Pass) die wirtschaftlichere Architektur.

---

8.2 Rollenmodell eines Software-Agenten-Teams

Rollen existieren nicht, um Organigramme zu füllen. Sie existieren, um Interessen zu trennen: wer schreibt, wer prüft objektiv, wer priorisiert, wer blockiert bei Security. Ohne diese Trennung optimiert ein Generalist auf „Diff fertig“ – und übersieht systematisch Vertragsrisiken, Threats oder DoD-Lücken.

Warum diese Schnitte?

• Supervisor hält den Plan und die Gates – ohne selbst den Code zu besitzen. Sonst wird er zum God-Agent und Flaschenhals.
• Implementer dürfen schreiben, aber nicht mergen und nicht die eigene DoD „wegnicken“.
• Verifier misst (Tests, Types, CI), Reviewer urteilt (Standards, Risiko). Vermischen erzeugt Bestätigungsbias.
• Security / Docs / Release sind optional aktivierbare Spezialbrillen – teuer, wenn permanent parallel, wertvoll, wenn der Pfad es verlangt.

Referenz-Rollen (minimal lebensfähig)

Rolle	Mission	Typische Outputs
Tech Lead / Supervisor	Ziele, Prioritäten, Gates	Plan, Status, Eskalationen
Analyst / PM-Agent	Scope schärfen	agent-ready Epics/Issues
Architect	Optionen, ADRs	ADR-Drafts, Constraints
Implementer(n)	Code ändern	Diffs, Unit-Tests
Verifier	objektive Prüfung	Test-/CI-Reports
Reviewer	Risiko & Standards	Review Notes
Security	Threats, Findings	Sec-Report (blocking/non)
Docs	Nutzer- & Dev-Docs	Doc Diffs
SRE/Release	Rollout-Readiness	Checklist, Feature flags

Nicht jede Rolle braucht ein eigenes Modell 24/7. In der Praxis dominiert: eine Runtime, viele Skills/Prompts, aktiviert nach Phase und Policy. Das spart Token und hält die Org-Logik im Orchestrator statt in neun langlaufenden Chat-Sessions.

{ width=100% }

RACI light für Agenten

Für jedes Deliverable explizit machen: wer Responsible (erzeugt), Accountable (Supervisor/Human), Consulted (liest Shared Artifacts), Informed (Status-Event). Unklare Accountability ist die häufigste Ursache für Review-Ping-Pong und „alle haben es gesehen, niemand hat entschieden“.

---

8.3 Work Breakdown: vom Epic zu agentenfähigen Paketen

Multi-Agent scheitert selten am Modell – und oft am Schnitt. Schlechte Pakete erzwingen geteilte Dateien, implizite Verträge und ständige Replans. Gute Pakete machen Parallelität langweilig: klare Inputs, klare Outputs, wenige Überraschungen an den Grenzen.

Schnittprinzipien

1. Vertikale Scheiben, wo möglich – ein User-Value inkl. Tests, nicht „alle Models zuerst, alle APIs später“. Vertikale Schnitte reduzieren Vertragsdrift zwischen Schichten.
2. Interfaces zuerst – API-Verträge, Event-Schemas, Feature-Flags freischalten, bevor zwei Implementer gegeneinander laufen.
3. Begrenzte Dateimengen pro Implementer – Lock- und Review-Freundlichkeit schlägt theoretische Maximalparallelität.
4. Explizite Abhängigkeiten im Plan-Graph – was nicht im Graph steht, wird zur Laufzeit verhandelt, und Verhandlungen sind teuer.

{ width=100% }

Definition of Ready (DoR) pro Paket

• Ziel & Non-Goals
• Akzeptanzkriterien
• erlaubte Pfade / Services
• Teststrategie
• abhängige ADRs
• Max Budget (Steps, Tokens, Zeit)

Definition of Done (DoD) pro Paket

• Tests/Types/Lint grün
• Review Notes adressiert
• Memory aktualisiert (falls Entscheidung)
• keine offenen blocking Security Findings

DoR und DoD sind die Verträge zwischen Agenten. Was hier fehlt, wird später als Chat, Replan oder Human-Escape nachgeholt – jeweils teurer als die fünf Minuten Schärfung am Anfang.

---

8.4 Orchestrierung eines Projekt-Laufs

Orchestrierung ist keine Workflow-Dekoration. Sie beantwortet fortlaufend drei Fragen: Was darf parallel laufen? Was muss wahr sein, bevor die nächste Phase startet? Wann eskaliert der Supervisor statt „noch ein Worker“ zu starten?

Phasen-Pipeline

{ width=100% } Intake macht das Epic agent-ready (Scope, Human-Fragen, Paket-Hypothese) – sonst multipliziert Multi-Agent Unklarheit. Design friert teure Entscheidungen ein (ADR, Threat Notes, Non-Goals); ohne dieses Gate wird die falsche Architektur elegant implementiert. Build ist die Phase, in der Parallelität systematisch lohnt: entkoppelte Pakete, disjunkte Pfade, Verifier pro Push – hier zählt Partition, nicht Agenten-Anzahl. Integrate bleibt eng (Merge-Fenster, Integrationstests, serielle Reihenfolge); wer hier weiter parallelisiert, verschiebt Konflikte nur in den Mainline. Hardening bündelt Review, Security und Docs als blockierende Gates, ohne den Build-Fluss ständig zu unterbrechen. Release bleibt human-sichtbar: Checkliste, Flags, Sign-off.

Parallelität steuern

Parallelität ist ein Budget, kein Default:

• starte mit max. 2–3 Implementern, solange Pfade disjunkt sind;
• partitioniere nach Package/Directory, nicht nach „wer gerade idle ist“;
• mergen seriell im Integration Window („merge train“);
• blockiere neue Worker, wenn der Plan-Graph oder die Budgets rot sind.

@dataclass
class Package:
    id: str
    paths: tuple[str, ...]
    depends_on: tuple[str, ...]
    status: str = "todo"  # todo|running|blocked|done


def ready_packages(packages: list[Package]) -> list[Package]:
    done = {p.id for p in packages if p.status == "done"}
    return [
        p for p in packages
        if p.status == "todo" and set(p.depends_on) <= done
    ]

Der Scheduler oben ist trivial – und genau das ist der Punkt. Die Intelligenz steckt in DoR, Pfadschnitten und Budgets, nicht in einem cleveren Multi-Agent-Chat.

---

8.5 Qualität und Konflikte im Team-Maßstab

Qualitätsnetz

Qualität im Multi-Agent-Setup ist ein Netz, kein finaler Prüfer:

1. Verifier nach jedem Implementer-Push – frühes Feedback ist billiger als Integrations-Rot.
2. Periodischer Integration-Run – fängt Vertrags- und Env-Drift, den Unit-Tests nicht sehen.
3. Security-Pass vor Release – blocking Findings stoppen den Zug, Non-Blocking wandern in Tickets.
4. Human Gate an Architektur- und Prod-Schwellen – Agenten dürfen vorbereiten, nicht die Haftung tragen.

Konfliktmuster – und wie man entscheidet

Konflikte sind keine Betriebsunfälle; sie sind die Steuer, die Parallelität erhebt. Vier Muster decken den Großteil der Praxis ab:

Datei-Kollision. Zwei Implementer schreiben in dieselben Pfade. Symptom: gegenseitiges Überschreiben, sinnlose Rebases. Gegenmittel: Pfad-Partition und Locks vor dem Start – nicht „mergt euch irgendwie“. Wenn zwei Pakete dieselben Dateien brauchen, waren es keine zwei Pakete.

Vertragsdrift. Frontend und Backend (oder Producer und Consumer) entwickeln sich auseinander, weil der Contract nur in den Köpfen der Agenten existierte. Gegenmittel: Contract-first Artifact im Shared Context, Freeze vor parallelem Build, Verifier gegen das Artifact – nicht gegen die letzte Chat-Zusammenfassung.

Review-Ping-Pong. Mehr als zwei bis drei Runden bedeuten meist unklare DoD, schwache DoR oder fehlende Supervisor-Entscheidung. Gegenmittel: max_review_rounds, danach explizite Entscheidung (accept with debt / rework scope / abort) – nicht „noch ein Reviewer“.

Memory- und Priority-Widerspruch. Zwei ADRs parallel, ständige Replans, thrashender Scope. Gegenmittel: single writer für Entscheidungen, Status-Maschine für ADRs, frozen sprint scope für die Dauer eines Epic-Laufs. Replans sind erlaubt – aber sie sind Events mit Kosten, keine Daueratmosphäre.

Human Team Interface

Menschen brauchen in Agenten-Orgs dasselbe wie in menschlichen Orgs – nur expliziter:

• Dashboard (Paketstatus, Blocker, Budgetverbrauch),
• verständliche PR-Serien statt Chat-Transkripten,
• eine Ansprech-Persona (Supervisor-Zusammenfassung),
• Opt-out / Pause.

Agenten-Orgs ohne UX erzeugen Schatten-IT und Misstrauen.

---

8.6 Kosten-Nutzen-Relation von Multi-Agenten-Setups

Multi-Agent wird häufig als Qualitäts- oder Speed-Feature verkauft. Wirtschaftlich ist es vor allem ein Multiplikator auf Token, Koordination und Fehlermodi. Wer die Steuer nicht misst, skaliert Kosten schneller als Nutzen.

Was wirklich kostet

Fünf Hebel erklären den Großteil der Mehrkosten:

1. Token-Multiplikation. Jeder Agent lädt eigenen System-Prompt, Working Set und relevante Shared Artifacts. N Agenten skalieren näher an N × Baseline als an Baseline / N. Parallelität spart Wall-Clock – nicht automatisch Token.
2. Review- und Verify-Runden. Jeder Round-Trip lädt Diff und Kontext neu. Zwei zusätzliche Review-Schleifen können teurer sein als die Erstimplementierung.
3. Konfliktlösung. Locks, Rebases, Contract-Repair und Hotfixes nach Integration sind oft teurer als die serielle Single-Agent-Variante desselben Scopes.
4. Context-Synchronisation. Status schreiben, Handoffs lesen, Supervisor-Replans: „nur Metadaten“ summiert sich, besonders wenn Artifacts aufgebläht sind.
5. Human Coordination Tax. Dashboards, Sign-offs, Eskalationen – oft unterschätzt und vertrauenskritisch, sobald sie Dauerzustand werden.

Größenordnungen als Faustregeln

Die folgenden Faktoren sind Orientierungsgrößen [E4] – keine Labormessung und kein Vendor-Versprechen (Ableitung: Token-Multiplikation + Koordinationslogik; Scorecard: Anhang F.4):

Setup	Rel. Kosten	Typischer Nutzen
1 Implementer + Verifier (seriell)	1,3–1,8×	weniger stille Qualitätslücken; kaum Parallelitätsgewinn
Supervisor + 2 Implementer + Verifier	2–3,5×	kürzere Lead Time, wenn Pakete parallel und merge-arm
Volles Orchester (viele Rollen parallel)	4–8×+	hohes Risiko / Querschnitt / Audit – nicht für Routine-PRs

Die Faktoren sind relativ zu einem starken Single-Agent mit vergleichbarem Context Engineering.

Faustregel: 2–3 parallele Implementer sind häufig der Sweet Spot, solange Pfade disjunkt und Merge-Fenster seriell sind. Ab 4+ Write-Agenten ohne harte Partition dominiert der Koordinationsoverhead. Fließen dauerhaft mehr als etwa 30–40 % der Tokens in Review, Replan und Konfliktarbeit statt in Implementierung, ist das Setup überdimensioniert oder die DoR zu schwach. [E4]

Was die öffentliche Evidenz (nicht) sagt

Zu Multi-Agent-Coding in realen Teams fehlen große, vergleichbare Feld-RCTs (Stand 2026-07). Die Tabelle oben und die 2–3,5×-Bandbreite bleiben Orientierung [E4] – nicht Ergebnis eines Branchen-Meta-Reviews.

Was existiert, stützt eher die Vorsicht:

• Completions-Feld-RCTs (Cui et al., 2025 ≈+26 % Tasks/Woche) [E1] und Lab-Studien (Peng et al., 2023 ≈+56 % Speed) [E1] messen keine Multi-Agent-Orchester.
• METR / Becker et al. (2025): Single-Tooling kann erfahrene Maintainer auf reifen Repos verlangsamen (≈+19 % Zeit) [E1] – mehr Agenten multiplizieren dann Verifikation, nicht nur Output.
• DORA 2025: AI als Amplifier von Systemqualität [E2]; mehr parallele Erzeugung ohne Review-Kapazität erhöht Fragilität.

Scorecard Single vs. Multi vs. Human-only und TCO-Formel: Anhang F.4. Praktisch: Wall-Clock, Tokens/Paket, Review-Runden und Revert-Rate im selben Zeitraum tracken – sonst optimierst du nur den Token-Term.

Multi-Agent lohnt wirtschaftlich vor allem dann, wenn entweder der kritische Pfad (Wall-Clock bis Release) spürbar kürzer wird oder die vermiedenen Fehlerkosten (Prod, Security, Compliance) die Token-Mehrkosten klar übersteigen. „Wir haben mehr Agenten“ ist keine Rendite. [E4]

Was öffentlich noch fehlt – und warum du trotzdem steuerst:

Was wir (noch) nicht wissen: Ob Multi-Agent-Orchester (2+ Write-Agenten + Verify) in realen Teams den Netto-TCO (Tokens × Review × Defects × Lead Time) gegenüber einem starken Single-Agent systematisch verbessern.

• Offene Fragen: 1) Effektgröße Wall-Clock und Revert-Rate bei disjunkten vs. überlappenden Pfaden? 2) Ab welchem Review-Token-Anteil (>~40 %) lohnt Shrink statt Scale?
• Widersprüchliche Evidenz: Completions-Gewinne [E1] und METR-Verlangsamung auf reifen Repos [E1] messen andere Welten als Multi-Agent; Token-Faktoren ~2–3,5× sind Architektur-Heuristik [E4] (Anhang F.4/F.8).
• Was die Aussage widerlegen würde: Preregistrierter Vergleich Multi vs. Single über ≥8 Wochen: kürzere Lead Time und gleiche/niedrigere Edit/Revert-Rate bei Tokens ≤2×.
• Überprüfung: Proxies in 8.6 + Scorecard F.4 nach jedem Epic; bei Modell-Upgrade Full coding sample.
• Was wir trotzdem tun [E4]: Single-Agent-Default; Multi nur bei entkoppelbaren Paketen; Budgets, Kill-Switch, Tokens/Paket und Review-Anteil messen.

Entscheidungslogik

Multi-Agent einsetzen, wenn mindestens zwei gelten:

1. Arbeitspakete sind echt entkoppelbar (klare Interfaces, disjunkte Pfade).
2. Qualitätsdimensionen sind heterogen (Code + Security + Docs + Contract) und ein Generalist übersieht systematisch welche.
3. Lead Time ist knapper als Token-Budget (Deadline, Incident-Window, Migration).
4. Shared Context / MCP ist bereits stabil genug – sonst zahlst du Integrationskosten und Koordinationssteuer.

Single-Agent (oder Implementer + Verifier) behalten, wenn:

• ein Working Set, ein PR, homogenes Skill-Profil,
• Repo und Conventions noch unklar (Multi-Agent multipliziert dann Chaos),
• das Team noch keine brauchbare Human-UX für Agent-Orgs hat,
• du keine Budgets und Proxies messen kannst – dann steuerst du blind.

Messbare Proxies und harte Budgets

Was du nicht misst, steuerst du nicht. Sinnvolle Proxies (ergänzend zu Kap. 7 und 11):

Proxy	Gesundes Signal	Warnsignal
Tokens / abgeschlossenes Paket	stabil im Budgetband	steigt ohne Scope-Wachstum
Anteil Tokens Verify/Review vs. Implement	Review klar unter ~40 %	Review-Domäne dominiert
Review-Runden / Paket	≤ 2–3	häufig am Cap oder darüber
Wall-clock Lead Time Epic	unter Single-Agent-Baseline bei vergleichbarer Qualität	länger und teurer
Merge-Konflikte / parallele Runs	selten	häufig → N oder Partition zu aggressiv
Human Escapes / Woche	wenige, klar begründet	Dauerfeuer → DoR/Policy defekt

Budgets gehören in die Orchestrierung, nicht in die Retrospektive:

budgets:
  epic_tokens: 5_000_000
  package_tokens: 800_000
  max_review_rounds: 3
  max_parallel_implementers: 3

Der Supervisor bricht ab und eskaliert – statt „noch ein Worker“. Ein Multi-Agent-Setup ohne Kill-Switch ist kein Team; es ist ein offener Kostenkreis.

---

8.7 MCP als zentrale Kontext- und Tool-Schicht in Multi-Agenten-Teams

Warum gerade hier MCP?

In Multi-Agent-Setups explodiert die Integrationskomplexität: mehrere Rollen × mehrere Tools × ggf. mehrere Hosts (IDE, CI, Nightly Batch). Ohne gemeinsame Capability-Schicht entstehen vier Teilintegrationen und vier Wahrheiten. MCP liefert eine Schicht für Tools, Resources und Prompts; die Org-Logik bleibt im Orchestrator (vgl. Kap. 5).

{ width=100% }

Server-Zuschnitt: Kern vor Katalog

Für projektweite Teams brauchst du kein Museum an Servern. Der Kern, ohne den Multi-Agent driftet:

• shared-context – Pläne, Handoffs, Locks, Artifact-Catalog (Single Source of Truth für den Lauf),
• project-memory – ADRs, Conventions, Owner, langlebige Entscheidungen,
• git / Repo – Diffs, Branches, PRs,
• ci / Tests – objektive Verifier-Signale,
• issues – Epic- und Paket-Tickets als Eingangsartefakte.

Darum herum verdichten sich je nach Risiko codebase-memory (Impact), security und docs. Der vollständige Server-Überblick gehört in den Anhang bzw. in die Tool-Landschaft eures Hosts – nicht in jedes Kapitel. Entscheidend ist: Shared Truth vor Tool-Vielfalt.

Rollen → erlaubte Capabilities

Least Privilege ist hier kein Compliance-Ritual, sondern Konfliktprävention: wer nicht mergen darf, kann keinen Mainline-Unfall bauen; wer nicht patchen darf, kann Review und Security nicht „mal eben selbst fixen“.

ROLE_POLICY = {
    "analyst": {
        "servers": ["issues", "project-memory", "shared-context"],
        "tools_allow": ["get_issue_context", "upsert_artifact", "record_decision"],
        "tools_deny": ["apply_patch", "merge_pr"],
    },
    "implementer": {
        "servers": ["git", "codebase-memory", "ci", "shared-context", "project-memory"],
        "tools_allow": ["apply_patch", "run_unit_tests", "code_search", "impact_analysis"],
        "tools_deny": ["merge_pr", "prod_restart"],
    },
    "reviewer": {
        "servers": ["git", "project-memory", "ci", "shared-context"],
        "tools_allow": ["get_diff", "upsert_artifact"],
        "tools_deny": ["apply_patch"],
    },
    "security": {
        "servers": ["git", "security", "project-memory", "shared-context"],
        "tools_allow": ["run_secret_scan", "run_sast", "upsert_artifact"],
        "tools_deny": ["apply_patch"],
    },
}

Shared Context als Projektakte

Empfohlenes URI-Schema – revisioniert, adressierbar, auditierbar:

context://epics/{epic_id}/plan
context://epics/{epic_id}/packages/{package_id}
context://epics/{epic_id}/handoffs/{from}-to-{to}/{n}
context://epics/{epic_id}/artifacts/diff/{package_id}/{rev}
context://epics/{epic_id}/status
context://locks/{encoded_path}

{
  "package_id": "pkg-api-contract",
  "status": "running",
  "owner_agent": "implementer-2",
  "paths": ["src/api/billing/**", "openapi/billing.yaml"],
  "depends_on": [],
  "artifacts": {
    "diff": "context://epics/E-17/artifacts/diff/pkg-api-contract/2",
    "tests": "context://epics/E-17/artifacts/test-report/pkg-api-contract/2"
  },
  "budgets": {"tokens_used": 120000, "tokens_max": 800000}
}

Publish-Gate: In shared-context nur mit Summary, URI, Revision, Producer, Trust-Level. Hypothesen, Roh-Logs und CoT bleiben rollenprivat; geteilt werden Diffs, Claims, Reports, Locks, Plan und Status.

Handoff-Protokoll über MCP

Handoffs sind typisierte Verträge, keine Höflichkeitschats (Kap. 5):

{ width=100% }

Publiziert wird derselbe Handoff-Contract wie in Kap. 5 (z. B. über upsert_artifact mit Zielrolle, Diff-URI und done_when) – nicht ein freier Chat-Übergabe-Text.

Dieselbe Schicht bedient IDE, Nightly Orchestrator, CI und ChatOps – eine Wahrheit über Host-Grenzen, nicht vier Teilintegrationen.

Referenzarchitektur „Feature Factory“

{ width=100% }

---

8.8 End-to-End: Issue → PR (ein Durchlauf)

Mini-Szenario statt Organigramm-Theorie: ein ticketbares Change-Set von der Issue bis zum Draft-PR, Rollen an MCP-Server gekoppelt. (Größere Epics mit Parallelität: Fallstudie darunter.)

Issue PROJ-442: „Retry für Payment Captures – Idempotency + Backoff, ohne doppelte Buchung.“

Schritt	Rolle	MCP-Server (Kern)	Deliverable
1 Spec	Analyst	issues, project-memory, shared-context	agent-ready Issue + AC in context://…/plan
2 Design light	Architect (optional)	project-memory, shared-context	ADR-Draft / Constraints (Idempotency Keys)
3 Implement	Implementer	git/repo, codebase-memory, ci, shared-context	Branch agent/PROJ-442-…, Diff, Unit-Tests
4 Verify	Verifier	ci/tests, shared-context	Test-/CI-Report grün oder block
5 Review	Reviewer (+ Security bei Money Path)	git, security (opt.), shared-context	Review Notes; kein apply_patch, kein merge_pr
6 PR	Implementer / Supervisor	git, issues	Draft-PR + Context Trace; Human merged

Vertrag im Handoff: done_when = AC erfüllt + Tests grün + keine blocking Sec-Findings; Shared Truth nur über shared-context/project-memory, nicht über Agent-Chat. Privilege: Implementer max. L2 (Branch/Draft-PR); Merge bleibt Human/L3-Gate (Kap. 7, 11).

So liest sich der Lauf im Trace: welche URIs, welche Tools, welches Budget – nicht „die Agenten haben gesprochen“.

Fallstudie (kompakt): dasselbe Thema als kleines Multi-Agent-Epic

Wenn Scope und Parallelität wachsen (domain + API + docs):

1. Analyst macht Epic E-17 agent-ready, Fragen an Human.
2. Architect ADR: Idempotency Keys + Backoff; Security commented.
3. Pakete: domain, API, metrics, docs – Contract Freeze vor parallelem Build.
4. Zwei Implementer parallel (domain + docs); API wartet auf Freeze.
5. Verifier nach jedem Paket; Integration rot → domain hotfix (geplanter Rücksprung).
6. Reviewer + Security hardening; Docs merged.
7. Release-Checkliste; Human sign-off; Memory: Decision + Incident-Link-Template.

Wirtschaftlich typisch: Wall-Clock oft unter einem seriellen Generalisten, Token eher ~2–3× (zwei Write-Pfade + Verify/Review) [E4]; ein Teil des Parallelitätsgewinns geht in die Integrationsrunde. Der Trade-off lohnt bei Money Path + Auditierbarkeit – nicht weil „zwei Implementer cool sind“. Alle Artefakte über MCP – rekonstruierbar für Audit und Postmortem.

---

Best Practices

1. Starte mit Supervisor + Implementer + Verifier; Rollen wachsen mit Bedarf, nicht mit Begeisterung.
2. Schneide Pakete entlang Pfaden und Dependencies, nicht entlang Ego-Rollen.
3. Nutze MCP-Shared-Context als Single Source of Truth für Status/Handoffs.
4. Policy pro Rolle: Least Privilege auf Server/Tools.
5. Budgetiere parallel laufende Agenten hart – und miss Tokens/Paket sowie Review-Anteil.
6. Maximiere ausführbare DoD, minimiere Meinungs-Handoffs.
7. Halte Menschen in Ownership- und Release-Gates sichtbar.
8. Behandle Parallelität als Budget: lieber 2 saubere Implementer als 5 konkurrierende Writer.

---

Pitfalls

Pitfall	Folge	Gegenmaßnahme	Kapitel-Querverweis
10 Agenten ab Tag 1	Koordinationskollaps	MVP-Team	Kap. 8
Chat zwischen Agenten als SoT	Drift	context:// Artifacts	Kap. 8
Gleiche Write-Tools für alle	Sicherheits- und Konfliktchaos	Rollenpolicies	Kap. 8
Unbegrenzte Review-Loops	Kostenexplosion	max rounds + Supervisor decision	Kap. 8
Kein Integrationstop	ewige Feature-Branches	merge windows	Kap. 8
Multi-Agent ohne Kostenproxies	stille Budgetexplosion	Tokens/Paket, Review-Anteil, Escapes	Kap. 8
Ignorieren von Human UX	Schattenprozesse	Status-API + Summaries	Kap. 8

---

Key Takeaways

• Multi-Agent lohnt bei Querschnitt, Risiko und echter Parallelität – nicht als Default; mehr Agenten heißen vor allem mehr Koordinationssteuer.
• Klare Rollen, DoR/DoD und Paket-Schnitte schlagen zusätzliche LLMs; der Scheduler darf simpel sein.
• Issue→PR lässt sich mit wenigen Rollen und einem MCP-Kern (issues, git, ci, shared-context, memory) end-to-end orchestrieren (8.8) – Merge bleibt Human/L3.
• 2–3 parallele Implementer mit disjunkten Pfaden sind oft effizient [E4]; darüber dominiert häufig der Overhead.
• MCP + Shared Context + Handoff-Contracts sind die gemeinsame Wahrheit über Rollen und Hosts – nicht Agent-Chat.
• CA-MCP-Policies sichern Least Privilege; Erfolg misst sich in Outcomes und Proxies, nicht in Agenten-Anzahl.

---

Was als Nächstes kommt

Kapitel 9 holt die Architektur in den Alltag: Integration in moderne Entwickler-Tools und Workflows, MCP-Server in AI-IDEs (Cursor, Claude Code, Windsurf, Continue & Co.) sowie lokale vs. remote MCP-Server.

---

Übungsanregungen

1. Definiert euer MVP-Agenten-Team (max. 4 Rollen) für das nächste Epic.
2. Entwerft URI-Schemas für context://epics/... in eurem Namensraum.
3. Schreibt ROLE_POLICY für Implementer und Reviewer.
4. Simuliert einen Handoff Implementer→Verifier mit JSON-Contract auf dem Papier.
5. Schätzt für ein reales Epic: Single-Agent vs. 2 Implementer + Verifier – erwartete Token-Faktoren, Lead-Time-Gewinn und die zwei Proxies, die ihr nach dem Lauf prüft.