Technischer Kontext
Ich schätze solche Fallstudien nicht wegen des Wow-Effekts, sondern wegen der bodenständigen Ingenieurskunst. Hier hat jemand tatsächlich ein Multi-Agenten-System in Claude Code aufgebaut: Es gibt einen zentralen Orchestrator, Projekt-Agenten, direkte Kommunikation mit jedem einzelnen und sogar die Möglichkeit, dynamisch neue Agenten zu erstellen oder zu löschen.
Für die KI-Automatisierung ist das kein Spielzeug mehr. Es ist fast ein lebendiges Betriebssystem für Aufgaben wie Recherche, Korrespondenz, Buchhaltung, das Entwerfen von E-Mails und Projektmanagement – alles in einem einheitlichen Speicher- und Protokollierungskreislauf.
Was meine Aufmerksamkeit erregt hat: Dies wurde hauptsächlich über ein Claude-Code-Abonnement realisiert, mit einer Begrenzung auf etwa 10 Iterationen, nicht über eine API. Die Validierung wird teilweise von Codex übernommen, während Claude Code und Gemini als Sub-Agenten fungieren. Das Setup funktioniert, deutet aber sofort auf eine Obergrenze durch die Limits hin. Wenn jemand versucht, eine Pseudo-API aus dem Abonnement zu extrahieren, ist ein Verstoß gegen die Nutzungsbedingungen nicht mehr weit.
Aber etwas anderes ist noch wichtiger. In der Diskussion kam eine sehr relevante Frage nach Qualitätsmetriken auf, und hier endet die Magie schnell. Wenn 20, 30 oder 50 Agenten miteinander reden, bedeutet das nicht automatisch, dass Sie eine gute Implementierung künstlicher Intelligenz haben. Ohne Abbruchkriterien, Token-Budgets und klare Qualitätsprüfungen verbrennen Sie den Kontext einfach nur elegant und mit Begeisterung.
Ein aufschlussreicher Auszug aus den Benchmarks: Der „Decision-Making“-Skill verbrauchte anderthalbmal so viele Tokens und lieferte ein schlechteres Ergebnis als ein Agent ohne Skills. Der „Architecture-Review“-Skill hingegen lieferte bei gleichem Token-Verbrauch eine etwa doppelt so hohe Qualität. Ich würde das so übersetzen: Nicht jeder Skill verbessert das System; manche fügen nur Zeremonien und Rauschen hinzu.
Und ja, das deckt sich perfekt mit meinen Praxiserfahrungen. Wenn ein Agent schlecht darin ist, Aufgaben zu zerlegen, Prioritäten zu setzen und zu wissen, wann er aufhören muss, beginnt die Multi-Agenten-Struktur, das Budget linear aufzufressen. Eine Review-Ebene vor der Ausführung zahlt sich jedoch oft sehr schnell aus, denn es ist billiger, einen schlechten Plan abzufangen, als später schlechten Code oder eine fehlerhafte Automatisierung zu bereinigen.
Auswirkungen auf Unternehmen und Automatisierung
Teams mit vielen parallelen kognitiven Aufgaben gewinnen: Recherche, Reviews, Kommunikation und Projektunterstützung. Hier spart die KI-Integration mit einem Orchestrator wirklich Stunden und reduziert den manuellen Kontextwechsel.
Verlierer sind diejenigen, die glauben, dass mehr Agenten automatisch bessere Ergebnisse bedeuten. Bei Routineaufgaben ist ein einziger, gut abgestimmter Agent fast immer günstiger und stabiler als ein ganzes „Dorf“ von Bots.
Ich würde drei Regeln festlegen: ein Iterationslimit, „Kill“-Kriterien für festgefahrene Agenten und eine separate Architekturprüfung vor der Ausführung. Genau solche Engpässe analysieren wir bei Nahornyi AI Lab für unsere Kunden, wenn wir KI-Lösungen für Unternehmen ohne das Feuerwerk verschwendeter Tokens entwickeln.
Wenn bei Ihnen bereits ein Chaos aus Chats, Aufgaben und manuellen Prüfungen herrscht, können wir eine saubere KI-Automatisierung für Ihren Prozess aufbauen, ohne diesen Zoo. Melden Sie sich, und Vadym Nahornyi und ich bei Nahornyi AI Lab werden prüfen, wo Sie einen starken Agenten benötigen und wo es wirklich sinnvoll ist, einen Orchestrator zu bauen.