Organisation: 50-100 Agenten als Ziel, "hoechstens 5" zurueckgezogen (#682-#688)

Die Regel im InstanceSetupGuide war in der Beobachtung richtig und in der
Folgerung falsch: quadratisch steigen die Verbindungen, nicht die Agenten.
Ein Agent, der drei Nachbarn und eine Leitung kennt, kostet gleich viel, ob
die Instanz zehn oder hundert Agenten hat.

docs/Organisation-Konzept.md haelt fest, was heute bei 50 Agenten bricht
(flaches Adressbuch, synchrones send_message, Delegationstiefe 3,
unbegrenzte Parallelitaet, Kappung bei 500, zwei Arbeitsbereiche, ein Brett,
zwei Budgetebenen, eine Freigabe-Warteschlange) und schlaegt die fehlende
Ebene vor: die Einheit.

Zwei davon sind schon heute Fehler und gehoeren sofort behoben (#682).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/InstanceSetupGuide.md

@@ -11,21 +11,43 @@ Bevor eine Instanz erstellt wird, muss klar definiert werden:
 | Frage | Beispiel |
 |-------|---------|
 | Welche Aufgabe(n) soll die Instanz als Ganzes erledigen? | "Social-Media-Monitoring mit automatischer Zusammenfassung" |
-| Wie viele Agenten werden benötigt? | 1–5 (mehr = höhere Koordinationskosten) |
+| Wie viele Agenten werden benötigt? | So viele, wie es Zuständigkeiten gibt — die Kosten stecken in den Verbindungen, nicht in der Zahl |
 | Welche externen Systeme sind beteiligt? | Telegram, E-Mail, Datenbank, APIs |
 | Wie hoch ist das Token-Budget pro Tag? | z.B. $1/Tag, $10/Tag |
 | Soll die Instanz autonom arbeiten oder manuell getriggert werden? | Cron-Jobs vs. manueller Start |
 
 ### Agentenanzahl richtig wählen
 
+> **Geändert am 2026-09-21.** Hier stand: „Mehr als 5 Agenten — kritisch hinterfragen,
+> Koordinationsoverhead steigt quadratisch." Die Beobachtung stimmt, die Folgerung war
+> falsch. Quadratisch steigen die **Verbindungen**, nicht die Agenten. Eine Instanz, die
+> einen Onlinehandel betreibt, braucht Einkauf, Buchhaltung, Marketing und Logistik mit je
+> mehreren Agenten — fünf reichen dafür nicht annähernd. Das Ziel von ClawdDotNet sind
+> 50 bis 100 Agenten, die geordnet zusammenarbeiten. Die Begründung und was dafür fehlt:
+> [Organisation-Konzept](Organisation-Konzept.md).
+
 | Szenario | Empfehlung |
 |----------|-----------|
 | Eine klar abgegrenzte Aufgabe | 1 Agent |
 | Aufgabe mit getrennten Zuständigkeiten (z.B. Recherche + Bericht) | 2–3 Agenten |
-| Komplexes System mit Koordination | 3–5 Agenten, davon 1 Koordinator |
-| Mehr als 5 Agenten | Kritisch hinterfragen — Koordinationsoverhead steigt quadratisch |
+| Ein Fachgebiet mit mehreren Teilaufgaben | So viele Agenten wie Teilaufgaben, plus eine Leitung |
+| Mehrere Fachgebiete | Je Gebiet eine Einheit mit eigener Leitung; die Leitungen reden miteinander, die Mitglieder nicht |
 
-**Faustregel:** Jeder Agent, der mit einem anderen kommuniziert, kostet Token auf beiden Seiten. Zwei Agenten, die jeweils 3 Nachrichten austauschen = 6 LLM-Runs.
+**Die Faustregel gilt weiter, aber sie zielt auf etwas anderes:** Jede Nachricht zwischen
+zwei Agenten kostet auf beiden Seiten einen Lauf. Zwei Agenten, die drei Nachrichten
+tauschen, sind sechs Läufe. Teuer wird also nicht der elfte Agent, sondern der elfte
+Agent, der **jeden** anderen ansprechen darf.
+
+Deshalb ist die eigentliche Entwurfsfrage nicht „wie viele Agenten?", sondern **„wer muss
+mit wem reden?"** Ein Agent, der drei Nachbarn und eine Leitung kennt, kostet gleich viel,
+ob die Instanz zehn oder hundert Agenten hat. Ein Agent, der eine Liste aller hundert
+bekommt, kostet bei jedem Blick in diese Liste.
+
+Bis die Strukturen aus dem [Organisation-Konzept](Organisation-Konzept.md) gebaut sind,
+ist das Adressbuch flach: `list_agents` zeigt jedem Agenten alle anderen. Bei mehr als
+etwa zehn Agenten heißt das, `AgentComm` nur den Agenten zu geben, die es wirklich
+brauchen — und den übrigen die Zusammenarbeit über das Taskboard zu geben, das keine
+Gegenseite wachhält.
 
 ---