Management-Theorie in einer KI-Umgebung

1 Comment

1. Milos Wikarski 1 week ago
   Zwischen dem klassischen Delegationsproblem der Managementtheorie und der Agenten-Orchestrierung fast eine Isomorphie besteht: Sobald man Arbeit an eine Instanz abgibt, deren Ziele, Wissen und Zuverlässigkeit man nicht vollständig kontrolliert, stellen sich exakt dieselben Fragen wie in einer Organisation. Ich gehe die drei Teile deiner Frage nacheinander durch. ## Die theoretische Abbildung Am schärfsten passen zwei Rahmenwerke. **Mintzbergs Koordinationsmechanismen** bilden das Repertoire fast eins zu eins ab. Er unterscheidet direkte Aufsicht, Standardisierung von Arbeitsprozessen (das *Wie* vorschreiben), Standardisierung von Ergebnissen (das *Was* vorschreiben), Standardisierung von Fähigkeiten (dem Ausführenden vertrauen, weil er "ausgebildet" ist) und wechselseitige Abstimmung. In einem Claude-Setup entspricht: - *direkte Aufsicht* dem Orchestrator-Thread, der Subagenten zugweise beauftragt, mit Freigabe-Prompts an dich (Human-in-the-Loop); - *Prozessstandardisierung* dem detaillierten Ausbuchstabieren von Schritten in Prompt, CLAUDE.md oder Skills — die SOP; - *Ergebnisstandardisierung* dem Muster "gib nur eine Zusammenfassung in diesem Format zurück" — du legst das Deliverable fest, nicht den Weg; - *Fähigkeitsstandardisierung* dem Systemprompt bzw. der `description` eines Subagenten, die seinen "Beruf" definiert (code-reviewer, optimizer); - *wechselseitige Abstimmung* den Agent Teams, die untereinander kommunizieren. **Agency-Theorie** ist sogar namentlich präsent. Du bist der Prinzipal, der Subagent der Agent mit eigener Informationslage und potenziell abweichendem Verhalten. Die klassischen Probleme — Informationsasymmetrie, Moral Hazard, Monitoring-Kosten — kehren als Halluzination, Instruktions-statt-Intentions-Befolgung (das LLM-Analogon zum Reward-Hacking) und als Überwachungsaufwand wieder. Das "return a summary"-Muster ist im Kern ein Umgang mit Informationsasymmetrie: Du kannst nicht alles prüfen, also vertraust du einem komprimierten Bericht — und bezahlst das mit Kontrollverlust. Ergänzend greifen Spannweite der Kontrolle (Fayol) in Form harter Struktur-Limits, Taylorismus in der Trennung von Planung und Ausführung (der "understand–change–verify"-Zyklus ist genau das), Webers Bürokratie in Gestalt der Regel- und Rollendateien (`settings.json`, Subagenten-Configs, Permissions als Zuständigkeit), und McGregors Theorie X/Y als die konfigurierbare Frage, wie viel Autonomie du dem Ausführenden zutraust. Der eigentliche Meta-Rahmen ist die Kontingenztheorie: Es gibt keine beste Struktur, sondern die Aufgabe bestimmt sie — und genau das ist die Designphilosophie hinter den Orchestrierungs-Primitiven. ## Standardeinstellung Die Defaults sind bewusst konservativ, also am Theorie-X-nahen, eng geführten Ende: - Claude Code läuft standardmäßig als **ein Agent in einer Schleife** und ist bei Parallelität von Haus aus zurückhaltend — echtes Fan-out muss man explizit anfordern, am besten mit konkreter Zahl. - Einige **eingebaute Subagenten** (u. a. Explore) sind registriert und werden automatisch delegiert; Claude entscheidet anhand von Aufgabenbeschreibung und `description`-Feld, wann. - Strukturgrenzen sind gesetzt: standardmäßig maximal 200 Subagenten pro Session und ein fixes, nicht konfigurierbares Tiefenlimit — ein Subagent in Tiefe fünf erhält das Agent-Tool nicht mehr und kann nichts weiter starten. Subagenten können ohnehin keine Subagenten spawnen, die Orchestrierung lebt im Hauptthread (der Dirigent, nicht eine Kette von Ketten). - **Agent Teams**, das eigentliche Mehr-Agenten-Modell mit je eigenem Kontext, ist experimentell und per Default aus, bis man CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 setzt. - Automatische Workflow-Orchestrierung ist Opt-in: erst ein hoher Effort-Level ("ultracode") aktiviert sie, woraufhin Claude selbst pro Anfrage entscheidet, ob ein Workflow lohnt, und einen Cluster zum Kartografieren, einen zum Ausführen und einen zum Verifizieren plant. - Aufsichtsdichte hängt am Ausführungsmodus: ein Foreground-Subagent blockiert und reicht jeden Berechtigungs-Prompt an dich durch, ein Background-Subagent läuft mit den bereits erteilten Rechten und verweigert automatisch alles, was sonst nachfragen würde. Übersetzt: Der Default ist eine flache Zwei-Ebenen-Hierarchie mit direkter Aufsicht und expliziter Freigabe — kein selbstorganisierendes Team. ## Was sich wie konfigurieren lässt Die Stellschrauben entsprechen ziemlich genau den Hebeln eines Organisationsdesigners: - **Rollen und Fähigkeiten** über Subagenten-Configs und ihre `description` (Stellenbeschreibung plus Auslöser — "use proactively" macht die Delegation aggressiver). - **Autorität/Zuständigkeit** über `permissions` (allow/deny) und über die `Agent()`-Allowlist im `tools`-Feld, die festlegt, *welche* Subagenten ein Koordinator überhaupt einstellen darf — die Governance-Frage "wer darf wen beauftragen". - **Politik und Kultur** über CLAUDE.md als dauerhaftes Regelwerk. - **Aufsichtsdichte** über Foreground/Background und Effort-Level. - **Delegation nach Kompetenz** über modellweise Auswahl pro Agent — anspruchsvolles Reasoning auf ein starkes Modell, hochvolumige billige Aufgaben auf ein günstiges. Das ist wörtlich das Zuweisen von Aufgaben nach Qualifikation und Kosten. Die Designentscheidung ist laut Doku bewusst eine Kontingenz-Wahl: Dynamic Workflows (Aufteilung im Voraus unbekannt, Qualität vor Tokenkosten), Subagenten (wenige delegierte Aufgaben in einer Session) und Teams (anhaltende, große oder session-übergreifende Parallelität) lösen verschiedene Strukturprobleme, und die falsche Wahl kostet Tokens, Zeit und Vertrauen. ## Abhängigkeit vom verwendeten LLM Hier steckt der eigentliche Hebel, und Mintzberg liefert das Prinzip: **Die Modellfähigkeit entscheidet, auf welchen Koordinationsmechanismus du dich überhaupt verlassen kannst.** Ein Frontier-Modell (Opus-Klasse) verträgt lange Autonomie-Horizonte, Selbst-Dekomposition und flache Hierarchien. Du kannst über *Ergebnisse* und *Fähigkeiten* koordinieren — Ziel nennen, Weg dem Agenten überlassen — also Theorie Y fahren. Je schwächer das Modell, desto stärker fällst du auf *Prozessstandardisierung* und *direkte Aufsicht* zurück: kleinere Aufgabengranularität, jeder Schritt ausbuchstabiert, engere Tool-Rechte, mehr Verifikationsdurchläufe. Der Management-Aufwand wandert vom Modell zurück in dein Scaffolding. Konkret variiert mit dem Modell: - **Zuverlässiger Handlungshorizont** — wie viele Schritte am Stück ohne Abdriften. Kurz heißt: mehr Zwischenkontrollen, kleinere Teilaufträge. - **Instruktions- und Format-Treue** — nur ein Modell, das strukturierte Ausgaben verlässlich einhält, erlaubt Koordination über Ergebnisstandardisierung; sonst brauchst du Prozesskontrolle plus Validierung. - **Kontextfenster als Organisationsgedächtnis** — kleiner Kontext trägt die "Firmenpolitik" nicht, also kompensierst du mit Retrieval, häufigerer Zusammenfassung und enger gefassten Rollen. Für deinen Kontext ist das relevant, wenn du Rollen auf kleinere oder lokale Modelle routest: Dann verschiebt sich die sinnvolle Architektur deutlich Richtung tayloristisches Ende — explizitere Workflows, adversariale Verifikation, feinere Task-Zerlegung, weniger Vertrauen in das Langzeiturteil eines einzelnen Agenten. Modell-pro-Rolle wird dann besonders interessant: ein starker Planer/Orchestrator, günstigere oder lokale Worker. Sobald aber eine Datenschutz-Randbedingung *alles* lokal erzwingt, kann man diese Arbeitsteilung nicht mehr über einen starken API-Orchestrator abfedern — und die Kompensation muss vollständig aus engerer Prozessführung und mehr Prüf-Ebenen kommen. Das ist kein Nachteil im engeren Sinn, sondern eine andere Stelle auf demselben Kontingenz-Kontinuum. Wenn du magst, kann ich das an einem konkreten Beispiel durchspielen — etwa wie eine "understand–change–verify"-Pipeline mit einem starken Orchestrator gegenüber einer rein lokalen, kleinteiligeren Variante konkret aussähe.
   +2 Reply Upvote post