Multi-Agent-Schleifenfehler sind Organisationsdesignfehler, keine Prompt-Fehler

Die meisten Multi-Agent-Setups stoßen irgendwann auf dasselbe Problem: Agenten, die sich gegenseitig Aufgaben zuwerfen, Prüfer, die endlos weitere Überarbeitungen fordern, Forschungskräfte, die unbegrenzt Unterthemen generieren, Tool-Aufrufe, die bis zum Erreichen des Rekursionslimits eskalieren. Framework-Dokumentationen nennen das „Schleifen" und bieten einen Max-Iterations-Regler. Eine zunehmend populäre These besagt, dass dieser Regler nur das Symptom behandelt – das eigentliche Problem liegt in der Organisation der Agenten.

Das immer wiederkehrende Muster: Wenn Agenten als gleichberechtigte Partner konzipiert sind (Forscher spricht mit Analytiker, Analytiker mit Autor, Autor reicht an Prüfer weiter), hat niemand klar die Verantwortung für das Ergebnis. Jeder Agent kann einen anderen Agenten um weitere Arbeit bitten. Das Diagramm enthält zwar theoretisch Stopp-Bedingungen, aber kein einzelner Agent hat die Befugnis zu erklären: „Das ist fertig, beende den Durchlauf." Diese Befugnis ist implizit und verliert sich im Peer-Netzwerk.

Die Lösung: Behandle das Agentennetzwerk wie ein Organigramm mit expliziten Berichtslinien, nicht wie einen Chatroom voller Gleichgestellter. Vorgeschlagene Ebenen:

• Vorsitz (höchste Autorität, kann beenden)
• Strategieabteilung
• Abteilungsleiter
• Teamleiter
• Spezialist
• Qualitätssicherung und Richtlinien als separate Stabsstellen, die ablehnen und eskalieren können, aber keine unbegrenzten neuen Arbeiten auslösen dürfen

Wichtige Mechanismen:

• Ein verantwortlicher Missionsinhaber pro Durchlauf
• Ein Inhaber pro Arbeitsstrom
• Begrenzte Delegationstiefe
• Typisierter Rückgabevertrag pro Arbeiter: Status, Nachweise, Ausgabe, Hindernisse, nächster Schritt
• Nur der Manager hat die Befugnis, wieder zu öffnen oder zu beenden
• Speicher befindet sich in den Autoritätsebenen; Spezialisten erhalten nur kontextbezogene Informationen

Insbesondere das Problem der Prüfer-Rekursion wird gelöst, wenn Verifikatoren strukturell nur einen Ablehnungsdurchlauf erhalten und dann eskalieren müssen.

Bestehende Frameworks bieten bereits die Grundbausteine:

• CrewAI – hierarchischer Prozess, bei dem ein Manager die Arbeit des Arbeiters validiert
• LangGraph – Vorgesetzte, Unteragenten und explizites Rekursionslimit
• OpenAI Agents SDK – manager-basierte Orchestrierung, getrennt von Peer-Handoffs
• AutoGen – GroupChatManager
• Anthropic – Orchestrator-Arbeiter-Forschungssystem

Die ungenutzte Idee: Behandle den Manager nicht als Moderator eines offenen Gruppenchats, sondern als formale Berichtslinie mit Befugnis zur Beendigung.

Zwei offene Bedenken:

1. Hierarchie kann selbst zum Engpass werden – wenn jede Entscheidung nach oben geht, wird der Vorsitz zur einzelnen Latenz- und Fehlerquelle.
2. Eskalation als Feature funktioniert nur, wenn die Spitze tatsächliche Stopp-Befugnis hat. Wenn der Vorsitz nur ein weiteres LLM aufruft, das weitere LLMs aufruft, ist die Schleife nur eine Etage nach oben verlagert.

Repository mit den vorgeschlagenen Organigramm-Ebenen: github.com/jeongmk522-netizen/agentlas_org_chart