Jedes Team, das KI-Agenten baut, stößt an dieselbe Grenze.
Man beginnt mit einem Prompt und ein paar Tools.
Es funktioniert.
Dann steigen die Anforderungen. Mehr Randfälle. Mehr Teams. Mehr Risiko.
Plötzlich ist dein „Agent“ ein 3000-Wörter-System-Prompt, der versucht, fünf Aufgaben gleichzeitig zu erledigen.
Die Lösung ist nicht mehr Prompt-Engineering.
Es ist die Wahl des richtigen Musters.
Hier sind die 15 Muster, aus denen jedes produktionsreife agentische System besteht – und wann genau du welches einsetzen solltest.
Bevor du ein Muster wählst
Nicht jede Aufgabe braucht einen Agenten.
Eine Aufgabe rechtfertigt einen Agenten, wenn:
→ Ein einzelner Modellaufruf kein zuverlässiges Ergebnis liefern kann
→ Das Modell zur Laufzeit zwischen Tools oder Datenquellen wählen muss
→ Die Aufgabe Planung, Validierung oder iterative Verfeinerung erfordert
→ Der Workflow echte Unsicherheit beinhaltet, die nicht fest codiert werden kann
Eine Aufgabe braucht in der Regel KEINEN Agenten, wenn der Weg von der Eingabe zur Ausgabe vorhersehbar ist.
Zusammenfassung. Klassifikation. Einfache Extraktion. Vorlagenbasierte Generierung.
Diese sind als direkte Modellaufrufe schneller, günstiger und zuverlässiger.
Sie in einen Agenten zu verpacken, fügt lediglich Latenz und Fehlerquellen hinzu, ohne Nutzen.
MUSTER 1 – Einzelner Agent
Der einfachste und häufigste Ausgangspunkt.
Ein Modell. Ein System-Prompt. Ein begrenzter Satz an Tools.
Das Modell entscheidet, welches Tool es aufruft, beobachtet das Ergebnis und fährt fort, bis es genug Informationen für eine Antwort hat.
Praktisches Beispiel: Ein Kundensupport-Agent, der den Bestellstatus prüft, den Versand verfolgt und ein Ticket erstellt, wenn er das Problem nicht lösen kann – mit nur 2-3 Tools und einer klaren Aufgabe.
Verwende es, wenn: die Aufgabe klar definiert ist, der Tool-Satz klein ist und ein einziger Agent den gesamten Kontext halten kann, ohne verwirrt zu werden.
Es scheitert, wenn: du ständig weitere Tools hinzufügst und der System-Prompt länger als eine Seite wird. Das ist das Zeichen, dass du ein anderes Muster brauchst – keinen längeren Prompt.
MUSTER 2 – Multi-Agent Sequentiell
Spezialisierte Agenten arbeiten in einer festgelegten Reihenfolge. Die Ausgabe jedes Agenten dient als Eingabe für den nächsten.
Praktisches Beispiel: Eine Vertragsprüfungspipeline – ein Agent extrahiert Verpflichtungen, der nächste identifiziert Risiken, ein dritter erstellt die Zusammenfassung für die Beschaffung. Die Reihenfolge ändert sich nie.
Verwende es, wenn: der Workflow klare, wiederholbare Phasen hat und jede Phase genau das liefert, was die nächste benötigt.
Es scheitert, wenn: die Reihenfolge tatsächlich variieren muss, basierend auf Zwischenergebnissen. Sequentielle Pipelines gehen von einem festen Pfad aus – ist das nicht der Fall, brauchst du etwas Dynamischeres.
MUSTER 3 – Multi-Agent Parallel
Unabhängige Teilaufgaben werden gleichzeitig ausgeführt und dann zu einer Gesamtansicht zusammengeführt.
Praktisches Beispiel: Ein Produktionsvorfall um 2 Uhr morgens. Drei Agenten untersuchen gleichzeitig Logs, Metriken und aktuelle Bereitstellungen – nicht nacheinander – denn bei einem Ausfall zählt jede Minute.
Verwende es, wenn: die Teilaufgaben wirklich unabhängig sind und Geschwindigkeit wichtig ist.
Es scheitert, wenn: Aufgaben tatsächlich von den Ergebnissen anderer abhängen. Die gleichzeitige Ausführung abhängiger Aufgaben erzeugt Wettlaufsituationen und unvollständigen Kontext.
MUSTER 4 – Schleife
Wiederhole eine Abfolge von Schritten, bis eine Abbruchbedingung erfüllt ist.
Praktisches Beispiel: Ein Datenbereinigungs-Agent, der eine chaotische CSV-Datei analysiert, einen Bereinigungsplan vorschlägt, prüft, ob die Qualitätsstandards erfüllt sind, und es bei Nichtbestehen erneut versucht – bis zu einer festgelegten maximalen Anzahl von Durchläufen.
Verwende es, wenn: die Aufgabe mehrere Versuche erfordert und du eine klare, prüfbare Stoppbedingung definieren kannst.
Es scheitert, wenn: es keine zuverlässige Abbruchbedingung gibt. Ohne eine solche riskierst du explodierende Kosten und ein System, das möglicherweise nie terminiert.
MUSTER 5 – Überprüfung und Kritik
Ein Bewertungs-Agent überprüft die Ausgabe eines anderen Agenten, kritisiert sie und gibt spezifisches, umsetzbares Feedback.
Praktisches Beispiel: Ein generierter Bericht wird von einem separaten „Kritiker“-Agenten überprüft, der schwache Behauptungen, fehlende Belege oder unklare Abschnitte markiert, bevor der Bericht jemals einen Menschen erreicht.
Verwende es, wenn: Qualität wichtiger ist als Geschwindigkeit und du eine zweite Meinung direkt ins System integrieren möchtest, nicht erst nachträglich.
Es scheitert, wenn: der Kritik-Agent dieselben blinden Flecken hat wie der Generator. Ein Prüfer, der auf ähnlichen Annahmen trainiert wurde, wird dieselben Fehler nicht erkennen.
MUSTER 6 – Iterative Verfeinerung
Eine Feedbackschleife mit einer Qualitätsschwelle. Der Generator verfeinert die Ausgabe, bis die Schwelle überschritten wird.
Praktisches Beispiel: Ein Generator für Marketingtexte, der seinen eigenen Entwurf anhand von Markenrichtlinien bewertet und solange umschreibt, bis eine Mindestqualität erreicht ist – nicht nur eine einzelne Bestehen/Nichtbestehen-Prüfung, sondern eine abgestufte Verbesserung.
Verwende es, wenn: die Ausgabequalität wirklich variabel ist und „gut genug“ einen messbaren Schwellenwert hat.
Es scheitert, wenn: die Bewertungsfunktion vage oder manipulierbar ist. Wenn das Modell seine eigene Punktzahl aufblähen kann, ohne echte Verbesserung, verschwendet die Schleife nur Tokens.
MUSTER 7 – Koordinator
Ein zentraler Routing-Agent leitet Anfragen basierend auf dem, was tatsächlich gefragt wird, an spezialisierte Agenten weiter.
Praktisches Beispiel: Support-Tickets werden an Spezialisten für Abrechnung, Technik, Konto, Versand oder Betrug weitergeleitet – jeder mit einem engen Kontext, anstatt dass ein Agent alles wissen muss.
Verwende es, wenn: du wirklich unterschiedliche Anfragetypen hast, die unterschiedlichen Kontext, unterschiedliche Tools oder unterschiedliche Entscheidungslogik benötigen.
Es scheitert, wenn: das Routing selbst mehrdeutig wird. Wenn Anfragen nicht klar in eine Kategorie fallen, wird der Koordinator zu einem neuen Engpass und einer Quelle von Fehlleitungen.
MUSTER 8 – Hierarchische Aufgabenzerlegung
Ein Wurzel-Agent zerlegt ein komplexes Ziel in kleinere Unterziele, delegiert sie an spezialisierte Arbeiter und synthetisiert dann alles zu einer Antwort.
Praktisches Beispiel: „In welche 3 Länder sollten wir nächstes Jahr expandieren?“ wird aufgeteilt in Wettbewerbsanalyse, Regulierungsrecherche, Logistik-Machbarkeit und Marktgrößenbestimmung – jedes von einem anderen Spezialisten bearbeitet und dann zusammengeführt.
Verwende es, wenn: das Problem für einen einzigen Reasoning-Durchgang zu breit ist, sich aber sauber in unabhängige Fachbereiche unterteilen lässt.
Es scheitert, wenn: die Unterziele nicht wirklich unabhängig sind. Wenn Arbeitsströme sich gegenseitig in Echtzeit beeinflussen müssen, geht durch die vorherige Zerlegung diese Interaktion verloren.
MUSTER 9 – Schwarm
Mehrere spezialisierte Agenten tragen zu einer gemeinsamen Diskussion bei, hinterfragen die Annahmen der anderen, und ein Moderator synthetisiert eine endgültige Empfehlung.
Praktisches Beispiel: Soll das Unternehmen ein Abonnement-Modell einführen? Forschungs-, Engineering-, Finanz- und Support-Agenten vertreten über mehrere Runden hinweg ihre jeweilige Perspektive, bevor ein Moderator die Kompromisse abwägt.
Verwende es, wenn: es keine einzige „richtige“ Antwort gibt – du brauchst eine fundierte Entscheidung, die durch echte, konkurrierende Standpunkte geformt wird.
Es scheitert, wenn: du eine schnelle, deterministische Antwort brauchst. Schwärme sind bewusst langsam und explorativ – das falsche Werkzeug, wenn Geschwindigkeit gefragt ist.
MUSTER 10 – ReAct (Reason and Act / Denken und Handeln)
Der Agent wechselt zwischen Denken und Handeln: entscheiden, was untersucht werden soll, ein Tool aufrufen, das Ergebnis beobachten, entscheiden, ob genug Beweise vorliegen.
Praktisches Beispiel: „Die Warteschlangenverarbeitung scheint festzustecken“ – der Agent durchsucht die Dokumentation, prüft die Dienstintegrität, korreliert die Ergebnisse und schlägt erst dann eine Lösung vor. Der Untersuchungspfad ist nicht vordefiniert; er hängt davon ab, was er unterwegs findet.
Verwende es, wenn: der Weg zur Antwort wirklich nicht im Voraus geplant werden kann – er hängt davon ab, was jeder Schritt offenbart.
Es scheitert, wenn: Untersuchungen lange laufen, ohne zu einem Ergebnis zu kommen. Begrenze immer die Anzahl der Denk-Handlungs-Zyklen, sonst riskierst du eine unendliche Erkundung.
MUSTER 11 – Mensch-in-der-Schleife
Der Agent untersucht und empfiehlt, aber ein Mensch trifft die endgültige Entscheidung bei allem, was riskant oder mehrdeutig ist.
Praktisches Beispiel: Rückerstattungsgenehmigungen – risikoarme, eindeutige Fälle werden automatisiert. Hohe Beträge, Betrugssignale oder Ausnahmen von der Richtlinie werden zur Überprüfung durch einen Menschen angehalten, bevor etwas abgeschlossen wird.
Verwende es, wenn: die Entscheidung ein echtes finanzielles, rechtliches oder reputationsbezogenes Risiko birgt und eine vollständige Automatisierung noch nicht akzeptabel ist.
Es scheitert, wenn: du dies nur als UI-Funktion behandelst, nicht als architektonisches Merkmal. Du brauchst einen dauerhaften Zustand, eine Zuweisung von Prüfern, Timeout-Behandlung und Eskalationspfade – nicht nur einen „Pause“-Knopf.
MUSTER 12 – Planen-und-Ausführen
Ein Planungs-Agent erstellt vorab einen vollständigen, strukturierten Plan – überprüfbar und änderbar – bevor Maßnahmen ergriffen werden. Ein Ausführungs-Agent arbeitet dann die Schritte ab.
Praktisches Beispiel: „Vergrößere den Worker-Pool von 10 auf 20 Instanzen, überprüfe, ob die Warteschlange abgebaut wird, aktualisiere das Runbook.“ Der vollständige Plan ist sichtbar, bevor die Ausführung beginnt – im Gegensatz zu ReAct, wo der Pfad schrittweise entsteht.
Verwende es, wenn: du möchtest, dass der Plan vor jeglicher Aktion überprüfbar oder genehmigbar ist – wichtig für Operationen mit echten Konsequenzen.
Es scheitert, wenn: sich die Umgebung schneller ändert, als der Plan ausgeführt werden kann. Ein veralteter Plan, der blind ausgeführt wird, ist schlimmer als gar kein Plan.
MUSTER 13 – Reflexion
Der Agent bewertet seine eigenen Fehler, reflektiert, was schiefgelaufen ist, und behält diese Erinnerung für den nächsten Versuch.
Praktisches Beispiel: Ein Code-Generierungs-Agent schreibt ein Skript, es schlägt zur Laufzeit fehl, der Agent analysiert den tatsächlichen Fehler, notiert, was zu beheben ist, und versucht es erneut – wird mit jedem Versuch klüger, anstatt denselben Fehler zu wiederholen.
Verwende es, wenn: Fehler lehrreich sind und Selbstkorrektur den nächsten Versuch tatsächlich verbessert.
Es scheitert, wenn: die Fehlermodi zufällig oder nicht miteinander verwandt sind. Reflexion hilft nur, wenn es ein echtes Muster gibt, aus dem man lernen kann.
MUSTER 14 – Benutzerdefinierte Logik
Ein Hybrid: Deterministischer Code übernimmt die Regeln, die niemals falsch sein dürfen, während das Modell für Urteilsvermögen, Entwürfe und Ausnahmebehandlung zuständig ist.
Praktisches Beispiel: Ein Rückerstattungs-Workflow, bei dem Kaufprüfung und Betrugserkennung als harte deterministische Regeln laufen – niemals an das Modell delegiert – während das Verfassen der Kundenantwort und Routing-Empfehlungen agentisch bleiben.
Verwende es, wenn: der Workflow echte Verzweigungslogik mit rechtlichen oder finanziellen Konsequenzen hat und du präzise sein musst, was deterministisch ist und was flexibel.
Es scheitert, wenn: Teams die Grenze verschwimmen lassen und das Modell Entscheidungen treffen lassen, die fest codierte Regeln sein sollten. Berechtigung, Genehmigungen und Geldbewegungen sollten niemals allein dem Modell überlassen werden.
MUSTER 15 – Ereignisgesteuerter Agent
Der Agent wartet nicht darauf, gefragt zu werden. Er abonniert einen Ereignisstrom und handelt, sobald eine Bedingung ausgelöst wird.
Praktisches Beispiel: Ein Betrugserkennungs-Agent, der reagiert, sobald ein verdächtiges Transaktionsereignis ausgelöst wird – nicht erst, wenn ein Support-Ticket es ans Licht bringt, zu welchem Zeitpunkt der Schaden bereits eingetreten ist.
Verwende es, wenn: Zeit wichtiger ist als alles andere und das Warten auf eine menschliche Anfrage bedeutet, das Handlungsfenster zu verpassen.
Es scheitert, wenn: die Auslösebedingungen schlecht definiert sind. Ein verrauschter Ereignisstrom mit vagen Triggern verwandelt sich in ein System, das ständig „Wolf“ schreit – oder schlimmer noch, das eigentliche Signal übersieht.
Musterauswahl – Wähle nach der Unsicherheit, nicht nach dem Hype
Das richtige Muster passt zur Form der Unsicherheit in deiner Arbeit:
→ Unsicher, welches Tool zu verwenden ist → Einzelner Agent oder ReAct
→ Unsicher, wohin geleitet werden soll → Koordinator
→ Unsicher bezüglich der Qualität → Überprüfung & Kritik oder Iterative Verfeinerung
→ Unsicher über den Ausführungspfad → Planen-und-Ausführen oder ReAct
→ Unsicher, wie man sich selbst korrigiert → Reflexion oder Schleife
→ Unsicher bezüglich des Geschäftsrisikos → Mensch-in-der-Schleife oder Benutzerdefinierte Logik
→ Unsicher über die Problemstruktur → Hierarchische Zerlegung oder Schwarm
→ Kann nicht auf eine Anfrage warten → Ereignisgesteuerter Agent
Ein Schwarm ist nicht fortschrittlicher als ein einzelner Agent, wenn die Aufgabe nur einen zuverlässigen Tool-Aufruf benötigt.
Planen-und-Ausführen ist kein Upgrade von ReAct, wenn dein Plan bis zum dritten Schritt veraltet ist.
Die zuverlässigsten Produktionssysteme sind nicht die autonomsten.
Sie setzen Autonomie genau dort ein, wo sie Werte schafft – und beschränken sie überall sonst.
10 Regeln für agentische Produktionssysteme
- Beginne mit dem kleinsten Muster, das funktioniert. Ein einzelner Agent mit sauberen Tool-Verträgen schlägt ein Multi-Agent-System mit schwachen.
- Schreibe Tool-Beschreibungen wie Verträge. Das Modell kennt die Funktion eines Tools nur aus der Beschreibung – nicht aus deiner Absicht.
- Begrenze Iterationen, Tool-Aufrufe und Ausgaben pro Anfrage. Ein Agent ohne Ausgabenlimits ist eine tickende Kostenbombe in der nächsten Rechnung.
- Protokolliere die vollständige Aktionshistorie. Tool-Aufrufe, Argumente, Ausgaben, endgültige Entscheidung. Ohne diese ist die Fehleranalyse reine Glaskugelleserei.
- Halte irreversible Aktionen hinter deterministischen Prüfungen oder menschlicher Genehmigung zurück. Lasse ein Modell niemals die einzige Hürde vor einer Geldbewegung oder Produktionsänderung sein.
- Bewerte mit echten Fehlerfällen, nicht nur mit Glückspfaden. Korrektheit im Glückspfad ist ein Prototyp. Korrektheit in Randfällen ist ein Produkt.
- Trenne Prompts nach Verantwortung, bevor der System-Prompt unlesbar wird. „Aber tu nicht X, wenn Y“ in deinem Prompt bedeutet, dass der Agent zwei Jobs erledigt.
- Behandle Multi-Agent-Systeme als verteilte Systeme. Teilausfälle, Timeouts, Wiederholungen und Beobachtbarkeit sind nicht optional.
- Modellprüfung ist kein Ersatz für deterministische Validierung. Verwende Bewerter zur Verbesserung der Qualität. Verwende Tests und Berechtigungsprüfungen zur Durchsetzung der Korrektheit.
- Bevorzuge das einfachere Muster – nicht weil einfach immer besser ist, sondern weil das gesparte Komplexitätsbudget in bessere Tools, bessere Prompts und bessere Bewertungen investiert werden kann.
Das sind alle 15.
Die meisten Teams scheitern nicht, weil sie das falsche Muster gewählt haben.
Sie scheitern, weil sie nie gefragt haben, für welche Unsicherheit sie eigentlich eine Lösung suchten.
Wähle das Muster. Passe es an die Form des Problems an. Füge keine Autonomie hinzu, wo sie sich ihren Platz nicht verdient.
Falls das nützlich war:
→ Teile den Beitrag, um ihn mit jedem Engineer in deinem Team zu teilen, der Agenten baut
→ Folge @sairahul1 für weitere vergleichbare Analysen
→ Setze ein Lesezeichen – du wirst jedes Mal darauf zurückkommen, wenn du ein neues Agentenprojekt startest
Ich schreibe über KI, Produktentwicklung und Systeme, die auch ohne dich funktionieren.
