Start/Praxis/Tipps/Der Single-Agent Sweet Spot, den niemand zugeben will
3. April 2026

Der Single-Agent Sweet Spot, den niemand zugeben will

Die AI-Community hat ein Overengineering-Problem. Teams planen Multi-Agent-Systeme mit einem Dutzend spezialisierter Agenten, bevor sie ueberhaupt geprueft haben, ob ein einzelner Agent mit den richtigen Tools die Aufgabe loesen kann. Paul Iusztin bringt es in seinem Architektur-Guide auf den Punkt: 95 Prozent aller Agenten schaffen es nie in Produktion -- und der haeufigste Grund ist, dass die falsche Architektur gewaehlt wurde.

Das Komplexitaetsspektrum

Iusztin beschreibt ein dreistufiges Spektrum fuer Architekturentscheidungen:

Stufe 1 -- Workflows. Du kontrollierst jeden Schritt in einer festgelegten Reihenfolge. Das Modell entscheidet nicht, was als naechstes passiert. Beispiel: Ein Support-Ticket-System, das eingehende Anfragen klassifiziert, routet, eine Antwort entwirft, validiert und versendet. Jeder Schritt kann ein LLM nutzen, aber die Abfolge steht fest. Workflows sind vorhersagbar, testbar und guenstig.

Stufe 2 -- Einzelner Agent mit Tools. Das Modell entscheidet autonom, welchen naechsten Schritt es geht. Ein Entscheider, mehrere Faehigkeiten. Das ist der Sweet Spot fuer die meisten dynamischen Probleme, bei denen der Ablauf nicht vorab festgelegt werden kann.

Stufe 3 -- Multi-Agent-Systeme. Mehrere Entscheider koordinieren sich untereinander. Hoehere Komplexitaet, hoehere Kosten, laengere Latenzen, schwierigeres Debugging.

Die Kernregel: So weit links auf dem Spektrum bleiben wie moeglich. Erst nach rechts gehen, wenn es nicht anders geht.

Warum ein Agent meistens reicht

Die Argumente fuer den Single-Agent-Ansatz sind pragmatisch:

Globaler Kontext. Ein einzelner Agent behaelt den gesamten Kontext einer Aufgabe. Wenn Schritt eins das Ergebnis von Schritt fuenf beeinflusst, muss kein Kontext ueber Agent-Grenzen hinweg transferiert werden. Multi-Agent-Systeme erzeugen Informationssilos und Handoff-Fehler.

Thin Agents, Heavy Tools. Tools koennen beliebig ausgereift sein, ohne die Architektur zu verkomplizieren. Ein Validierungstool kann intern ein eigenes LLM mit spezialisierten Anweisungen nutzen. Ein Textgenerierungstool kann Zeichenlimits als technische Constraint durchsetzen statt als Prompt-Problem. Spezialisierung entsteht auf Tool-Ebene, nicht durch Agenten-Vermehrung.

Kosten und Debugging. Weniger LLM-Aufrufe bedeuten weniger Token-Kosten, weniger Traces, weniger Fehlerquellen. Ein Workflow laesst sich Schritt fuer Schritt testen. Ein Multi-Agent-System erzeugt emergente Fehler, die sich durch Koordinationslogik ziehen.

Die vier Gruende, doch zu splitten

Iusztin benennt vier legitime Szenarien fuer den Wechsel zu Multi-Agent:

  1. Echte Parallelitaet. Genuein unabhaengige Aufgaben, die gleichzeitig laufen koennen -- nicht sequenzielle Schritte, die kuenstlich parallelisiert werden.
  2. Kontextueberladung. Ab circa 10 bis 20 Tools degradiert die Tool-Auswahl messbar. Das Modell leidet unter dem "Loss in the Middle"-Effekt und gewichtet Informationen in der Mitte des Kontexts systematisch unter.
  3. Modularitaet. Integration mit Drittsystemen oder Agenten, die man nicht kontrolliert.
  4. Harte Trennungsanforderungen. Sicherheitsgrenzen, sensible Daten, regulatorische Vorgaben.

Alles andere ist kein technischer Grund, sondern organisatorisches Cargo-Cult-Engineering.

Forschung bestaetigt den Befund

Eine aktuelle Studie von Xu et al. ("Rethinking the Value of Multi-Agent Workflow: A Strong Single Agent Baseline") liefert empirische Evidenz: Ein einzelner Agent, der mehrere Konversationsrunden ausfuehrt, erreicht die gleiche Leistung wie homogene Multi-Agent-Workflows -- bei niedrigeren Inferenzkosten durch KV-Cache-Wiederverwendung. Die Forscher stellen ihren OneFlow-Algorithmus vor, der Multi-Agent-Workflows automatisch in Single-Agent-Ausfuehrungen transformiert, ohne Genauigkeit einzubuessen. Das Ergebnis gilt ueber Coding-, Mathematik-, QA- und Planungsaufgaben hinweg.

Fallbeispiel: Von 12 Agenten auf einen

Iusztin beschreibt den Fall einer Marketing-Content-Plattform. Der urspruengliche Entwurf sah ueber ein Dutzend spezialisierter Agenten vor: Anfrage-Analyse, Content-Generierung, Strukturerzeugung, syntaktische und semantische Validierung, Spam-Erkennung, Optimierung, Sicherheit, Scoring, HTML-Normalisierung, Vergleich. Das klassische Ueberdesign.

Die Loesung war ein einzelner Agent mit spezialisierten Tools. Die Aufgaben waren eng gekoppelt und weitgehend sequenziell. Die Template-Wahl beeinflusste den nachgelagerten Content und die Personalisierung. Jede Aufteilung in separate Agenten haette Informationssilos und Handoff-Fehler erzeugt. Das Ergebnis: schneller gebaut, guenstiger im Betrieb, einfacher zu debuggen -- bei gleichen Faehigkeiten.

Einordnung in die laufende Debatte

Dieser Befund deckt sich mit dem Realitaetscheck zur Multi-Agent-Orchestrierung, der die Kostenfalle und den Koordinationsoverhead von Frameworks wie Gas Town und Claude Flow dokumentiert. Waehrend der Realitaetscheck fragt, ob Multi-Agent ueberhaupt funktioniert, liefert die Single-Agent-Perspektive die konstruktive Antwort: In den meisten Faellen reicht ein gut konfigurierter Agent mit durchdachten Tools.

Die Faustregel lautet: Wenn die Aufgabe weniger als 20 Tools braucht, kein echtes Parallelisierungspotenzial hat und keine harten Sicherheitsgrenzen erfordert, ist ein einzelner Agent die bessere Architektur. Das einfachste System, das das Problem zuverlaessig loest, ist immer das beste System.

Quellen

Nach oben