Agenten orchestrieren (CrewAI, LangGraph – Konzept)

Lernziele

Sie können erklären, warum ein einzelner Allzweck-Agent für komplexe Aufgaben strukturell scheitert und wie Orchestrierung durch Aufgabenteilung Abhilfe schafft.

Sie sind in der Lage, die Drei Architektur-Muster für KI-Agenten (OS-Agent, Pipeline-Agent, Standalone-Agent) zu beschreiben und für konkrete Anwendungsfälle das passende Muster zu wählen.

Sie können die konzeptionellen Grundprinzipien von CrewAI (Rollen + Ziele + Koordination) und LangGraph (gerichteter Graph mit Pausen-Knoten) erläutern und auf eigene Agenten-Architekturen übertragen.

Sie sind in der Lage, ein dreistufiges Agentensystem konzeptionell zu skizzieren, die Agenten-Inventarliste auszufüllen und eine Datenflussdiagramm-Skizze zu erstellen.

Sie verstehen die vier operativen Herausforderungen orchestrierter Systeme (Debugging-Komplexität, Latenz-Akkumulation, Kosten-Kaskade, zirkuläre Abhängigkeiten) und können für jede mindestens eine Gegenmaßnahme benennen.

Sie können die Architekturempfehlung „Intelligenz ins System, nicht in den einzelnen Agenten” auf eine konkrete Architekturfrage anwenden und das Prinzip mit einem eigenen Beispiel erläutern.

Sie kennen die Unterschiede zwischen sequentieller und paralleler Agenten-Ausführung und können begründen, wann welcher Ansatz vorzuziehen ist.

Auf einen Blick

Worum geht es? — Der didaktische Einstieg

Stellen Sie sich eine Organisation vor, die 25 verschiedene KI-Assistenten konfiguriert hat: einen für Angebote, einen für Berichte, einen für Recruiting, einen für Kundenkommunikation, einen für Qualitätsprüfungen, einen für Meeting-Protokolle. Jeder hat seine eigene Systemanweisung, sein eigenes Firmenwissen, seine eigenen Regeln, seine eigenen Tool-Verbindungen. Wenn sich die Unternehmens-Preisliste ändert, müssen alle 25 aktualisiert werden. Wenn sich die Tonalitäts-Richtlinien ändern, müssen alle 25 angepasst werden. Wenn ein Mitarbeiter die Bezeichnung einer Produktkategorie ändert, müssen 17 der 25 Agenten angepasst werden. Die Pflege wird zur Vollzeitaufgabe — und schleichende Inkonsistenzen zwischen den Agenten werden unvermeidlich.

Das ist nicht Skalierung — das ist technische Schuld im Voraus aufbauen.

Die bessere Architektur sieht anders aus: Ein zentraler Koordinator, der den Unternehmenskontext kennt und Aufgaben delegiert. Spezialisierte Agenten, die ihre Teilaufgabe hochpräzise ausführen. Eine gemeinsame Wissensbasis, die alle Agenten nutzen. Änderungen an einer Stelle — wirken sich auf das gesamte System aus, ohne jeden Agenten einzeln anpassen zu müssen.

Diese UE erklärt die Drei Architektur-Muster für KI-Agenten, die dieses Prinzip strukturieren: den OS-Agenten als Koordinator, den Pipeline-Agenten als Spezialist und den Standalone-Agenten als autonomen Hintergrundprozessor. Sie lernen die konzeptionellen Prinzipien von CrewAI und LangGraph kennen — nicht als Programmieraufgabe, sondern als Denkwerkzeuge für das Design von Agentensystemen. Gleichzeitig erfahren Sie, warum Orchestrierung keine Allheilmittel ist: Sie löst manche Probleme und schafft neue. Das Ziel dieser UE ist nicht, Entwickler-Kompetenz aufzubauen, sondern die Architektur-Sprache zu erwerben, die nötig ist, um mit Entwicklungsteams auf Augenhöhe zu sprechen und sinnvolle Anforderungen zu definieren — Anforderungen, die sowohl technisch umsetzbar als auch organisatorisch sinnvoll sind.

Lerntext — Theorie und Konzepte

Warum Orchestrierung notwendig ist

Ein einzelner Allzweck-Agent, der alle Aufgaben einer Organisation erledigt, klingt attraktiv. In der Praxis scheitert er an drei strukturellen Problemen, die nicht durch bessere Konfiguration gelöst werden können — sondern nur durch Architektur-Entscheidungen:

Kontextüberlastung: Je komplexer die Aufgabe, desto mehr Kontext muss geladen werden. Ein Agent, der Angebote erstellt, Projektberichte schreibt und Bewerbungen screent, braucht für jede Aufgabe völlig verschiedenes Hintergrundwissen. Das Kontextfenster — die Menge an Informationen, die ein Sprachmodell gleichzeitig verarbeiten kann — ist begrenzt. Wenn zu viele Informationen eingeladen werden, sinkt die Qualität: Das Modell verliert den Überblick über die Details, die für die aktuelle Aufgabe entscheidend sind. Orchestrierung löst das, indem jeder Agent nur den Kontext lädt, den er für seine spezifische Aufgabe braucht.

Qualitätsdilution: Einen Agenten auf Exzellenz in einem Bereich zu trimmen und gleichzeitig auf Exzellenz in zehn anderen Bereichen ist systematisch unmöglich. Die Systemanweisung kann nicht gleichzeitig die perfekte Angebots-Sprache, den idealen Berichts-Tonfall und das richtige Niveau für HR-Kommunikation definieren — nicht ohne so allgemein zu werden, dass die Qualität in allen Bereichen mittelmäßig bleibt. Spezialisierung ist der Schlüssel zu hoher Qualität: Der Angebots-Agent ist auf Angebote optimiert. Sonst nichts.

Wartungsaufwand bei verteiltem Wissen: 25 separate Agenten mit separatem Firmenwissen erzeugen einen massiven Wartungsaufwand. Jeder Firmenwissen-Datei muss bei Änderungen in jedem betroffenen Agenten aktualisiert werden. Orchestrierung zentralisiert die Intelligenz in einer gemeinsamen Wissensbasis und verteilt die Ausführung auf schlanke, spezialisierte Executor-Agenten. Änderungen an der Wissensbasis wirken sofort auf das gesamte System.

Merksatz

Orchestrierung löst das Problem, dass eine Aufgabe für einen einzelnen Agenten zu komplex oder zu weitreichend ist. Sie erzeugt aber neue Probleme (Debugging-Komplexität, höhere Latenz, Token-Kosten, Betriebsaufwand). Beginnen Sie immer mit dem einfachsten Ansatz und steigern Sie die Komplexität nur, wenn der einfachere Ansatz nachweislich nicht ausreicht. Orchestrierung ist kein Fortschrittszeichen an sich — sie ist ein Mittel zum Zweck. Wenn ein einzelner Custom GPT den Job erledigt, ist das die richtige Lösung.

Die Drei Architektur-Muster für KI-Agenten

Das Konzept der Drei Architektur-Muster für KI-Agenten strukturiert, wie verschiedene Agenten-Typen in einem Gesamtsystem zusammenwirken und welche Aufgabentypen sich für welches Muster eignen:

OS-Agent (interaktiver General Purpose Agent):

Der OS-Agent ist der „Chief of Staff” des KI-Systems. Er kennt den gesamten Unternehmenskontext, alle verfügbaren Skills, die Prioritäten der Nutzenden und die Organisationsstruktur. Er interagiert täglich, priorisiert Aufgaben und delegiert an spezialisierte Agenten. Er ist der einzige Agenten-Typ, dem die Nutzenden unmittelbar begegnen — alle anderen Agenten laufen im Hintergrund.

Stärke: Breite, Kontextwissen, Koordinationsfähigkeit, adaptives Verhalten

Schwäche: Kein Spezialist für einzelne Aufgaben; hoher Konfigurationsaufwand für initiale Einrichtung

Metapher: Der persönliche Assistent, der alles koordiniert, aber für die Steuererklärung den Steuerberater, für die Rechtsfrage den Anwalt und für den Bericht den Analysten hinzuzieht

Typisches Tool: Claude Desktop, ChatGPT Teams-Integration mit zentralem System-Prompt, Microsoft 365 Copilot

Pipeline-Agent (spezialisierter Ausführungsagent):

Der Pipeline-Agent führt eine klar definierte Aufgabe hochpräzise aus — ohne Kontext zu anderen Aufgaben. Er erhält einen strukturierten Input, verarbeitet ihn nach engen Vorgaben und liefert einen definierten Output. Er hat keine Initiative — er wartet auf Aufträge. Diese Passivität ist keine Schwäche, sondern eine Designentscheidung: Sie macht ihn vorhersagbar, debuggbar und günstig zu betreiben.

Stärke: Präzision, Vorhersagbarkeit, einfaches Debugging, schnell zu konfigurieren, niedrige Token-Kosten

Schwäche: Keine Flexibilität außerhalb seines definierten Rahmens; jeder unerwartete Input-Typ erzeugt einen Fehler

Beispiel: Angebots-Drafting-Agent — erhält strukturierte Kundendaten + Projektbeschreibung, erstellt Angebotsentwurf nach Vorlage mit korrekt berechneten Preisen, übergibt zur Human-Review (Gelb-Klassifikation)

Typisches Tool: Custom GPT mit enger Systemanweisung, n8n-Workflow mit LLM-Node, Power Automate + AI Builder

Standalone-Agent (event-getriggerter autonomer Spezialist):

Der Standalone-Agent läuft vollständig im Hintergrund und wird durch ein definiertes Ereignis ausgelöst — ohne interaktive Eingabe. Er führt seine Aufgabe aus und liefert das Ergebnis asynchron. Er hat keinerlei Interaktion mit den Nutzenden während der Ausführung. Wenn er fertig ist, hinterlegt er das Ergebnis an einem definierten Ort.

Stärke: Vollautomatismus, keine menschliche Intervention im Normalbetrieb, skaliert ohne zusätzlichen Personalaufwand

Schwäche: Schwieriger zu debuggen, wenn unerwartete Inputs auftreten; Fehler fallen oft erst spät auf

Beispiel: Lead-Dossier-Agent — sobald ein neuer Kundentermin im Kalender erscheint, recherchiert er automatisch das Unternehmen, die Gesprächspartner und relevante Branchennews — als vollständiges Briefing-Dokument, fertig für den Vertriebler, wenn er ins Meeting geht

Typisches Tool: n8n-Workflow mit LLM-Nodes und zeitbasiertem oder event-basiertem Trigger, Power Automate mit AI Builder und automatisiertem Ablauftrigger

Abb. 79.1 — Drei Architektur-Muster für KI-Agenten: OS-Agent koordiniert, Pipeline-Agenten führen aus, Standalone-Agenten laufen autonom

Einführungsreihenfolge: Warum Standalone zuerst

Eine häufig übersehene Empfehlung betrifft die Einführungsreihenfolge der drei Muster. Die intuitive Reihenfolge wäre: erst der einfachste Agent (Pipeline), dann der Standalone, zuletzt der komplexe OS-Agent. Aber die strategisch klügere Reihenfolge ist eine andere:

Standalone-Agent zuerst — weil er den höchsten Sichtbarkeitseffekt mit dem niedrigsten Koordinationsaufwand verbindet. Er läuft ohne Nutzer-Interaktion, kann in der Nacht ausgeführt werden, und wenn er am Morgen ein fertig aufbereitetes Dokument hinterlegt hat, ist der Mehrwert sofort und unmittelbar erfahrbar. Die Erfolgserlebnisse sind schnell und überzeugend.

Pipeline-Agent danach — wenn ein klarer, gut definierter Prozess identifiziert wurde, für den ein spezialisierter Agent sinnvoll ist. Der Aufwand für Konfiguration und Testen ist überschaubar, der Nutzen ist messbar.

OS-Agent zuletzt — wenn die Organisation bereits Erfahrung mit Agenten gesammelt hat und bereit ist, in eine komplexe, wartungsintensive Konfiguration zu investieren. Der OS-Agent erfordert die meisten Vorinvestitionen: eine sorgfältig gepflegte zentrale Wissensbasis, eine präzise abgestimmte Systemanweisung und ein klares Mental Model bei den Nutzenden darüber, was der Agent kann und was er nicht kann.

CrewAI — Das Crew-Metapher-Konzept

CrewAI ist ein Python-Framework, das Multi-Agenten-Orchestrierung mit einer eingängigen Metapher umsetzt: eine „Crew” aus spezialisierten Agenten arbeitet auf ein gemeinsames Ziel hin, koordiniert durch einen Manager-Agenten.

Für Nicht-Entwicklerinnen und -Entwickler ist CrewAI als konzeptionelles Modell wertvoll, auch wenn die technische Umsetzung Programmierkenntnisse erfordert. Die Kernprinzipien sind direkt auf jede Agenten-Architektur übertragbar:

Jeder Agent hat eine klar definierte Rolle (Senior Researcher, Content Analyst, Report Writer, Quality Reviewer)

Jeder Agent hat explizite Ziele (zuverlässige Quellen finden, Fakten validieren, strukturierten Bericht erstellen, Qualitätskriterien prüfen)

Jeder Agent hat erlaubte Tools (Websuche, Datenbank, Code-Interpreter, Dateizugriff) — und nur diese Tools

Ein Manager-Agent koordiniert die Aufgabenverteilung, überprüft die Ergebnisse und entscheidet über die nächsten Schritte

Das Skalierungsprinzip: Statt jeden Agenten mit viel Firmenwissen auszustatten, wird das Firmenwissen an einem zentralen Ort gespeichert — typischerweise ein Vektorstore oder ein RAG-System (UE 77) — und von Agenten bei Bedarf abgerufen. Der einzelne Agent bleibt schlank. Wenn sich das Firmenprofil ändert, wird nur die zentrale Wissensbasis aktualisiert, nicht jeder Agent. Das ist der strukturelle Vorteil gegenüber 25 separat konfigurierten Agenten.

Konzeptionelle Übertragung auf No-Code: Auch ohne CrewAI-Programmierung lässt sich das Crew-Prinzip umsetzen. In n8n: ein Orchestrierungs-Node delegiert Aufgaben an spezialisierte LLM-Nodes, die jeweils eine eigene Systemanweisung und eigene Tools haben. In Power Automate: ein Haupt-Flow ruft Unter-Flows auf, die als Pipeline-Agenten fungieren. Das Prinzip ist dasselbe — nur die Implementierungsschicht ändert sich.

LangGraph — Agenten als gerichtete Graphen

LangGraph (von LangChain) modelliert Agenten-Workflows als gerichtete Graphen (Directed Acyclic Graphs für strikt sequentielle Workflows und zyklische Graphen für iterative Schleifen). Knoten sind Agenten oder Funktionen, Kanten sind Übergänge zwischen Schritten mit optionalen Bedingungen.

Der entscheidende Vorteil für das Human-in-the-Loop-Design (UE 81): LangGraph unterstützt nativ Pausen-Knoten (Interrupt-Knoten). An bestimmten Stellen im Graph kann der Workflow explizit pausieren und auf menschliche Freigabe warten. Diese Pause ist technisch erzwungen — nicht nur dokumentiert oder organisatorisch vereinbart. Das ist der fundamentale Unterschied zwischen einem Prozess, der „eigentlich” reviewt werden sollte, und einem, der technisch nicht ohne Review fortfahren kann.

Zustandsmanagement: LangGraph speichert den vollständigen Zustand des Workflows zwischen Ausführungsschritten. Das bedeutet: Wenn ein Mensch an einem Pausen-Knoten eingreift, kann er den Kontext des bisherigen Verlaufs einsehen, bearbeiten und dann den Workflow an genau dem Punkt fortsetzen lassen, an dem er unterbrochen wurde. Für menschliche Reviewerinnen und Reviewer ist das deutlich komfortabler als ein System, das von vorne beginnen muss.

Parallelisierung: LangGraph ermöglicht parallele Zweige im Graph. Wenn Agent A und Agent B unabhängige Aufgaben bearbeiten (z. B. Recherche in zwei verschiedenen Datenquellen), können sie parallel ausgeführt werden — was die Gesamtlaufzeit erheblich reduziert.

Merksatz

Intelligenz gehört ins System, nicht in den einzelnen Agenten. Ein generischer Executor-Agent mit zentraler Wissensbasis ist wartungseffizienter als 25 voll konfigurierte Einzel-Agenten. Der Executor lädt den passenden Kontext, wenn er aufgerufen wird — ähnlich wie ein Betriebssystem ein Programm lädt, wenn es gebraucht wird, und es danach wieder freigibt. Dieses Prinzip reduziert Wartungsaufwand, verbessert Konsistenz und ermöglicht horizontale Skalierung ohne proportional steigende Konfigurationsarbeit.

Orchestrierung: Vier operative Herausforderungen

Orchestrierung löst reale Probleme — aber sie schafft auch neue. Wer Orchestrierung einsetzt, muss vier operative Herausforderungen im Griff haben:

1. Debugging-Komplexität: In einem mehrstufigen System ist schwerer nachzuvollziehen, warum eine Antwort falsch ist. Ist der Fehler beim Datenabruf entstanden? Beim ersten Verarbeitungsschritt? Beim zweiten? Am Ende? Ohne strukturiertes Logging ist die Fehlersuche extrem aufwändig. Jeder Agenten-Schritt muss mit Input, Output, Zeitstempel und Statuscode geloggt werden (detailliert dazu in UE 82).

2. Latenz-Akkumulation: Jeder Agenten-Aufruf kostet Zeit. Fünf sequentielle Agenten à drei Sekunden Verarbeitungszeit = 15 Sekunden Gesamtlaufzeit, bevor der Nutzende eine Antwort erhält. Für zeitkritische interaktive Prozesse kann das ein Showstopper sein. Gegenmaßnahmen: Parallelisierung wo möglich, Streaming-Antworten für den sichtbaren Teil, Vorab-Berechnungen für vorhersagbare Anfragen.

3. Kosten-Kaskade: Token-Kosten multiplizieren sich mit jedem Agenten-Schritt. Ein Workflow-Schritt mit 1.000 Token × 5 Agenten = 5.000 Token pro Ausführung. Bei 100 Ausführungen pro Tag: 500.000 Token täglich. Das können bei gehobenen Modellen 20–50 Euro pro Tag sein — 600–1.500 Euro pro Monat für einen einzigen Workflow. Ohne Token-Budget und Kosten-Monitoring entstehen unerwartete und schwer begründbare Ausgaben.

4. Zirkuläre Abhängigkeiten: Bei Peer-to-Peer-Netzwerken können Agenten sich gegenseitig aufrufen und endlose Schleifen erzeugen — jeder wartet auf den anderen, niemand kommt zum Ergebnis. LangGraph verhindert das durch gerichtete Graphen, in denen keine unkontrollierten Rückwärtskanten erlaubt sind. In einfacheren No-Code-Setups: maximale Iterations-Zahl pro Workflow als Sicherheitsmechanismus konfigurieren.

Sequentielle vs. parallele Ausführung

Ein häufig unterschätzter Designaspekt bei orchestrierten Systemen ist die Frage, ob Agenten-Schritte sequentiell oder parallel ausgeführt werden.

Sequentielle Ausführung bedeutet: Schritt A muss abgeschlossen sein, bevor Schritt B beginnen kann. Das ist sinnvoll, wenn B die Ergebnisse von A als Input braucht — und oft die einfachste Implementierungsvariante. Nachteil: Die Gesamtlaufzeit ist die Summe aller Einzellaufzeiten.

Parallele Ausführung bedeutet: Schritte A und B starten gleichzeitig und liefern beide ihre Ergebnisse unabhängig voneinander. Ein abschließender Schritt C sammelt die Ergebnisse und verarbeitet sie weiter. Das ist sinnvoll, wenn A und B wirklich unabhängige Aufgaben erledigen — z. B. Recherche in zwei verschiedenen Datenquellen. Die Gesamtlaufzeit ist dann max(A, B) statt A + B, was bei gleichlangen Schritten die Hälfte der Zeit spart.

Faustregel: Immer mit sequentieller Ausführung beginnen. Nur auf parallele Ausführung wechseln, wenn Latenz ein nachgewiesenes Problem ist und die Unabhängigkeit der parallelen Schritte klar dokumentiert wurde.

Vertiefung — Orchestrierung in der Praxis: Stabilität, Fehlertoleranz und Dokumentation

Die konzeptionellen Frameworks CrewAI und LangGraph lösen die technische Herausforderung der Orchestrierung — aber die operativen Herausforderungen bleiben bestehen und müssen beim Entwurf explizit adressiert werden.

Ausfallsicherheit durch explizite Fehlerbehandlung:

In einem Multi-Agenten-System kann jeder Teilagent fehlschlagen — durch API-Timeout, Modell-Fehler, Tool-Fehler oder unerwartete Input-Formate. Ein robustes Orchestrierungssystem behandelt Fehler nicht als Ausnahme, sondern als erwartbares Ereignis mit definierter Reaktion:

Retry-Logik für transiente Fehler: Netzwerkprobleme oder temporäre API-Überlastung. Standard: 3 Versuche mit exponentiellem Backoff (1s, 2s, 4s).

Fallback-Pfade für persistente Fehler: Wenn der bevorzugte Agent nach 3 Versuchen fehlschlägt, gibt es einen einfacheren Fallback — z. B. ein statisches Template statt dynamisch generiertem Inhalt.

Eskalation an menschliche Aufsicht bei kritischen Fehlern: Bei Fehlern, die weder durch Retry noch durch Fallback gelöst werden können, sendet das System automatisch eine Benachrichtigung an die zuständige Person.

Diese drei Ebenen — Retry, Fallback, Eskalation — bilden zusammen ein vollständiges Fehlerbehandlungskonzept.

Kosten-Tracking als Betriebsstandard:

Jeder Agenten-Aufruf kostet Token. In einem mehrstufigen System mit fünf Agenten, die jeweils drei Tool-Calls machen, können pro Workflow-Ausführung 50.000 oder mehr Token anfallen. Professionelle Orchestrierung enthält immer:

Ein Token-Budget pro Workflow-Ausführung (Hard Limit — der Workflow bricht ab, wenn das Budget überschritten wird)

Ein tägliches Reporting über tatsächliche Token-Verbräuche pro Workflow

Eine wöchentliche Kosten-Review mit automatischer Benachrichtigung bei Überschreitung definierter Schwellenwerte

Architekturdokumentation als Pflichtbestandteil:

Jedes orchestrierte Agentensystem erhält eine Architekturdokumentation mit mindestens fünf Bestandteilen:

Agenten-Inventar: Name, Rolle, eingesetztes Modell, erlaubte Tools, Human-in-the-Loop-Klassifikation (Grün/Gelb/Rot)

Datenflussdiagramm: Wer übergibt was an wen? In welchem Format? Mit welcher Validierung?

Fehlerbehandlungs-Protokoll: Was passiert bei jedem möglichen Fehlertyp?

Kosten-Budget: Token-Limit pro Ausführung, erwarteter Monatsaufwand

Human-in-the-Loop-Touchpoints: An welchen Stellen kann und muss ein Mensch eingreifen?

Diese Dokumentation ist nicht optional — sie ist Voraussetzung für die Inbetriebnahme und für jede externe Prüfung (Datenschutz, AI Act, interne Revision).

Drei Architektur-Ansätze im strukturierten Vergleich:

Der einfache Einzelagent reicht für 70–80 % der realen Anwendungsfälle. Der Supervisor-Multi-Agent-Ansatz (entspricht dem CrewAI-Modell) ist geeignet für strukturierte Workflows mit klar definierten Teilaufgaben. Peer-to-Peer-Netzwerke sind für die meisten Unternehmensanwendungen überdimensioniert und schwer zu kontrollieren — sie bleiben Speziallösungen für hochkomplexe, gut finanzierte Projekte.

Vertiefung II — Konkrete Implementierungsschritte: Vom Konzept zum ersten Orchestrierungs-Setup

Der Weg vom konzeptionellen Verständnis der Orchestrierung zur ersten konkreten Implementierung lässt sich in sechs operative Schritte unterteilen:

Schritt 1 — Agenten-Inventar erstellen: Bevor die erste Zeile Konfiguration entsteht, wird ein vollständiges Agenten-Inventar dokumentiert. Für jeden geplanten Agenten: Name, Rolle, Modell, erlaubte Tools, Input-Format, Output-Format, Freigabe-Klassifikation (Grün/Gelb/Rot), Owner-Rolle (wer ist für diesen Agenten verantwortlich?). Dieses Inventar ist das zentrale Referenzdokument für alle Folgegespräche mit IT, Compliance und Führungsebene.

Schritt 2 — Datenfluss modellieren: Zeichnen Sie einen einfachen Pfeil-Diagramm: Wer gibt welche Daten an wen? In welchem Format werden Daten übergeben? Wo gibt es Transformationsschritte? Wo warten Daten auf menschliche Freigabe? Dieser Datenfluss-Plan verhindert die häufigste Implementierungsfalle: Agenten, die Ausgaben in Formaten produzieren, die der nächste Agent nicht verarbeiten kann.

Schritt 3 — Mit dem einfachsten Agenten beginnen: Immer mit dem Standalone-Agenten mit dem klarsten Trigger beginnen. Konfigurieren, testen, stabilisieren — erst dann den nächsten Agenten hinzufügen. In orchestrierten Systemen ist es entscheidend, dass jeder Teilagent für sich alleine funktioniert, bevor die Verbindung hergestellt wird. Ein System, das aus fünf instabilen Teilagenten besteht, wird nie stabil sein.

Schritt 4 — Fehlerbehandlung zuerst designen: Für jeden Agenten: Was passiert bei Timeout? Was passiert bei unerwartetem Input? Was passiert bei Modell-Fehler? Diese Fragen vor dem Bau klären, nicht nachher. Ein Agent ohne Fehlerbehandlung ist kein produktionsbereiter Agent.

Schritt 5 — Kosten budgetieren und monitoren: Token-Budget pro Workflow definieren. Monitoring-Tool aktivieren (LangSmith, Helicone, oder einfaches Logging in Google Sheets). Wöchentliche Kosten-Review einplanen für die ersten drei Monate.

Schritt 6 — Pilot-Review nach vier Wochen: Nach vier Wochen Betrieb: Akzeptanzrate, Fehlerrate, Kosten, Nutzerzufriedenheit. Auf Basis dieser Daten: Systemanweisung anpassen, Fehlerbehandlung verbessern, ggf. Architektur überdenken. Dieser Review-Zyklus ist nicht optional — er ist der Mechanismus, durch den die Agenten-Architektur reift.

Merksatz

Orchestrierung ist eine Kompetenz, die in der Organisation aufgebaut werden muss — nicht eine Technologie, die installiert wird. Der erste orchestrierte Agent ist ein Lernprojekt: Er lehrt, wie man Fehler debuggt, wie man Kosten kontrolliert und wie man Nutzende in eine neue Arbeitsweise einführt. Die technische Konfiguration ist oft der einfachste Teil — die organisatorische Einbettung ist die eigentliche Herausforderung.

Abgrenzung: Orchestrierung vs. Automatisierung

Eine wichtige konzeptionelle Unterscheidung, die in der Praxis oft verwechselt wird: Orchestrierung ist nicht dasselbe wie Automatisierung.

Automatisierung (UE 73–74): Definierte Trigger führen zu definierten Aktionen — vollständig ohne KI-Intelligenz. Wenn E-Mail mit Betreff X eingeht → Datei in Ordner Y ablegen → Benachrichtigung senden. Keine Flexibilität, keine Interpretation, keine Ausnahmebehandlung durch ein KI-Modell.

KI-Agenten ohne Orchestrierung (UE 75–78): Ein einzelner KI-Agent, der mit einem Sprachmodell arbeitet, Werkzeuge nutzt und flexibel auf verschiedene Inputs reagiert. Flexibel, aber begrenzt durch Kontextfenster und Qualitätsdilution bei zu breitem Aufgabenspektrum.

KI-Agenten-Orchestrierung (UE 79): Mehrere KI-Agenten arbeiten koordiniert zusammen. Jeder ist auf seinen Aufgabenbereich optimiert. Ein Koordinator-Mechanismus (manuell, durch einen OS-Agenten oder durch ein Framework wie LangGraph) steuert den Gesamtprozess.

Hybride Systeme: In der Praxis sind die erfolgreichsten Architekturen Hybride: deterministische Automatisierung für die strukturierten Schritte (Daten abrufen, Ergebnisse ablegen, Benachrichtigungen senden) kombiniert mit KI-Verarbeitung für die intelligenten Schritte (Text generieren, klassifizieren, analysieren). n8n und Power Automate ermöglichen genau diese Hybridarchitektur: No-Code-Workflow-Logik für die Orchestrierung, LLM-Nodes für die KI-Verarbeitung.

Organisatorische Voraussetzungen für produktive Orchestrierung

Neben den technischen Voraussetzungen gibt es organisatorische Reifegrades, die erfüllt sein müssen, bevor orchestrierte Systeme produktiv eingesetzt werden:

Agent-Owner-Struktur: Jeder produktive Agent hat eine Verantwortliche Person — nicht ein Team, eine konkrete Person. Diese Person ist zuständig für Monitoring, Systemanweisungs-Pflege, Wissensbasis-Aktualisierung und Eskalation bei Problemen. Ohne klare Ownership verschwimmt die Verantwortung, und Qualitätsprobleme werden nicht behoben.

Interne Schulung der Nutzenden: Agenten, die in Workflows eingebettet sind, müssen den Nutzenden erklärt werden: Was macht der Agent? Was macht er nicht? Wie erkenne ich, wenn er falsch liegt? Was tue ich dann? Ohne diese Schulung entstehen unrealistische Erwartungen und falsche Verwendungsweisen.

Change-Management-Prozess: Die Einführung orchestrierter Agenten verändert Arbeitsprozesse. Wer hat vorher die Tickets manuell klassifiziert? Was passiert mit der freiwerdenden Zeit? Wie wird die Systemanweisung angepasst, wenn sich die Anforderungen ändern? Diese Fragen müssen beantwortet sein, bevor der erste Agent live geht — nicht danach.

Review-Zyklus-Planung: Wann findet der monatliche Monitoring-Review statt? Wer ist dabei? Was wird entschieden? Ohne geplante Review-Zyklen werden Probleme erst erkannt, wenn sie sich zu Krisen entwickelt haben.

Diese organisatorischen Voraussetzungen sind keine bürokratischen Zusatzanforderungen — sie sind die Bedingung dafür, dass die Investition in KI-Agenten-Orchestrierung tatsächlich die erwarteten Ergebnisse liefert.

Vertiefung II — Strategische Ebene — Fehlerkultur und Resilienz in orchestrierten Agentensystemen

Orchestrierte Agentensysteme versagen auf andere Weise als einzelne Automatisierungen. Ein isoliertes Skript schlägt fehl und hält an — der Fehler ist sofort sichtbar. Ein Netzwerk aus spezialisierten Agenten kann hingegen in Schleifen geraten, widersprüchliche Teilziele verfolgen oder scheinbar erfolgreich abschließen, während ein Zwischenschritt stillschweigend fehlerhafte Daten produziert hat. Nachgelagerte Agenten verarbeiten diese Fehlinformation weiter, ohne es zu merken. Das Endergebnis wirkt plausibel — ist aber falsch. Wer Orchestrierung produktiv betreiben will, muss deshalb Fehlerkultur systematisch in die Architektur einbauen, lange bevor der erste Produktionsfehler auftritt.

Drei Klassen von Fehlern im Agentennetzwerk

Die strukturierte Auseinandersetzung mit Fehlern beginnt mit ihrer Klassifikation. Nicht jeder Fehler hat dieselbe Ursache, dieselbe Sichtbarkeit und dieselbe Behandlungslogik.

Klasse 1 — Deterministische Fehler entstehen, wenn ein Agent ein klar definiertes technisches Kriterium nicht erfüllt: Ein Tool-Call schlägt fehl, eine externe API antwortet mit einem HTTP-Fehlercode, ein Pflichtfeld im erwarteten Ausgabeformat fehlt, oder eine Datenbankverbindung bricht ab. Diese Fehler sind am einfachsten zu behandeln, weil sie erkannt werden können, sobald sie auftreten. Ein konfiguierter Retry-Mechanismus, ein Fallback-Pfad oder eine Fehler-Nachricht an den Human-Supervisor löst die Situation auf. Deterministische Fehler sind störend, aber kontrollierbar.

Klasse 2 — Semantische Fehler entstehen, wenn der Agent technisch erfolgreich antwortet, aber inhaltlich falsch liegt. Ein Recherche-Agent zitiert eine veraltete oder falsch interpretierte Quelle; ein Analyse-Agent klassifiziert einen Sachverhalt aufgrund unvollständiger Kontextinformation falsch; ein Schreib-Agent produziert eine Formulierung, die in einem bestimmten regulatorischen Kontext problematisch ist. Diese Klasse ist gefährlicher als Klasse 1, weil der Fehler keine technische Fehlermeldung auslöst. Nachgelagerte Agenten empfangen die fehlerhafte Information und verarbeiten sie als korrekt. Der Fehler akkumuliert sich über mehrere Verarbeitungsschritte, bis er im Endergebnis erscheint — oft ohne erkennbaren Bezug zu seiner eigentlichen Ursache.

Klasse 3 — Systemische Fehler entstehen aus dem Zusammenspiel mehrerer Agenten und sind die komplexeste Kategorie. Zwei Agenten arbeiten parallel an denselben Daten und überschreiben gegenseitig ihre Zwischenergebnisse. Ein Routing-Agent sendet denselben Task wiederholt in dieselbe Queue, weil eine Abbruchbedingung nicht korrekt definiert wurde. Ein Koordinator-Agent verliert die Übersicht über Teilaufgaben, die nie abgeschlossen wurden, und gibt dennoch ein Gesamtergebnis als fertig aus. Diese Klasse erfordert keine Code-Fixes, sondern Systemdesign-Entscheidungen: bessere Zustandsverwaltung, klarere Abbruchbedingungen, explizite Verantwortlichkeitszuweisungen zwischen Agenten.

Merksatz

Semantische und systemische Fehler in Agentennetzwerken bleiben ohne explizite Validierungsschritte unsichtbar — sie erscheinen erst im Downstream-Ergebnis oder in der Nutzerbeschwerde. Jede Produktionsarchitektur benötigt daher mindestens einen Validierungs-Agenten oder einen strukturierten Human-Checkpoint nach semantisch kritischen Schritten. Klasse-1-Fehler durch Retry zu behandeln ist notwendig; Klasse-2- und Klasse-3-Fehler durch Design zu verhindern ist entscheidend.

Resilienz-Muster für orchestrierte Systeme

Resilienz ist keine Eigenschaft, die nachträglich hinzugefügt werden kann. Sie muss von Anfang an in die Architektur eingebaut sein. Vier bewährte Muster decken die häufigsten Schwachstellen ab.

Idempotente Tasks: Jede Teilaufgabe in einem Agentennetzwerk sollte so gestaltet sein, dass ein zweimaliges Ausführen exakt dasselbe Ergebnis liefert wie einmaliges. Das ermöglicht sicheres Retry ohne Doppeleinträge, inkonsistente Zustände oder aufaddierte Nebenwirkungen. In der Praxis bedeutet das: Agenten schreiben Ergebnisse nicht direkt in Produktionssysteme, sondern in eine dedizierte Staging-Schicht. Erst nach expliziter Validierung — entweder durch einen nachgelagerten Qualitäts-Agenten oder durch einen Human-Checkpoint — erfolgt der endgültige Commit in das Produktionssystem.

Dead-Letter-Queue: Tasks, die nach einer definierten Anzahl von Retry-Versuchen (typischerweise drei) weiterhin scheitern, landen nicht still in einem undefinierten Fehlerzustand, sondern in einer dedizierten Warteschlange für manuelle Bearbeitung — der sogenannten Dead-Letter-Queue. Zuständige Mitarbeiter sichten diese Queue täglich und entscheiden: Handelt es sich um ein temporäres Problem (API-Ausfall), das nach Behebung erneut verarbeitet werden kann? Oder liegt ein systematisches Design-Problem vor, das eine Architekturanpassung erfordert? Dieses Muster ist das Pendant zur klassischen Message-Queue-Architektur in verteilten Softwaresystemen und verhindert, dass Fehler unkontrolliert versickern.

Circuit-Breaker-Pattern: Wenn ein externer Dienst — etwa eine API für Marktdaten, ein Klassifikations-Endpunkt oder ein Datenbank-Service — wiederholt mit Fehlern antwortet, eskaliert das Problem: Der Agent wiederholt seine Anfragen in immer kürzeren Abständen und überlastet damit möglicherweise einen ohnehin beeinträchtigten Dienst. Das Circuit-Breaker-Pattern unterbricht diesen Kreislauf: Nach einer definierten Fehlerschwelle wird der „Schaltkreis geöffnet” — der Agent wechselt automatisch auf einen Fallback-Datensatz oder pausiert den gesamten Workflow, bis der Dienst wieder verfügbar ist. Dieses Muster verhindert Kaskadenausfälle, bei denen ein einzelner Dienstausfall das gesamte Agentennetzwerk zum Stillstand bringt.

State-Checkpointing: LangGraph implementiert dieses Muster nativ: Nach jedem Knoten im Ausführungsgraphen wird der aktuelle Zustand des Systems persistiert — in einer Datenbank oder einem anderen dauerhaften Speicher. Im Fehlerfall kann die Ausführung vom letzten erfolgreichen Checkpoint fortgesetzt werden, ohne alle vorherigen Schritte zu wiederholen. Für Workflows, die 20 bis 60 Minuten Laufzeit haben und viele externe API-Aufrufe umfassen, ist State-Checkpointing praktisch unverzichtbar. Ohne dieses Muster bedeutet jeder Fehler den Neustart der gesamten Prozesskette — mit entsprechendem Zeit- und Kostenaufwand.

Fehlerkultur im Team — nicht nur in der Architektur

Technische Resilienz-Muster sind notwendig, aber nicht ausreichend. Teams, die mit Agentensystemen arbeiten, benötigen eine organisatorische Fehlerkultur, die Vorfälle als wertvolles Lernmaterial bewertet — und nicht als individuelles Versagen, das vertuscht oder minimiert werden sollte.

Konkret bedeutet das: Jeder Fehler im Produktionsbetrieb, der ein definiertes Schwellenkriterium erfüllt (zum Beispiel: Auswirkung auf mehr als zehn Prozesse oder Dauer von mehr als 30 Minuten), wird in einem kurzen standardisierten Incident-Log dokumentiert. Dieses Log enthält: Was ist genau passiert? Welcher Agent oder welche Komponente war beteiligt? Welcher Fehlerklasse (1, 2 oder 3) ist der Vorfall zuzuordnen? Welche Maßnahme wurde ergriffen, und in welchem Zeitraum? Das Incident-Log ist keine Strafe und kein bürokratisches Artefakt — es ist die kollektive Wissensbasis für bessere Architekturentscheidungen in der Zukunft.

Reviews nach Incidents sollten keine Schuldigen identifizieren, sondern Lücken im System: Wo fehlte ein Validierungsschritt, der den Fehler hätte abfangen können? Wo war der Retry-Mechanismus nicht konfiguriert, obwohl er hätte sein müssen? Wo hätte ein Human-Checkpoint einen semantischen Fehler aufgefangen, bevor er sich in der Prozesskette ausgebreitet hat? Diese Fragen führen zu Architekturverbesserungen — nicht zu Schuldzuweisungen.

Die reifsten Teams behandeln Agentensysteme wie verteilte Software-Systeme der Unternehmens-IT: mit schriftlichen Runbooks für die häufigsten Vorfälle, klar definierten Eskalationspfaden und verantwortlichen Personen für jeden Systembestandteil. Dieser Reifegrad wird nicht am ersten Betriebstag erreicht, aber er ist das explizite Ziel — und der Weg dorthin beginnt mit der Bereitschaft, Fehler offen zu benennen und systematisch zu analysieren.

Dokumentations-Minimum für resiliente Agentensysteme

Unabhängig von der gewählten Orchestrierungsplattform sollte jedes System, das in Produktion geht, drei Kerndokumente besitzen. Das Architektur-Diagramm zeigt alle Agenten, ihre funktionalen Verantwortlichkeiten, die Datenflüsse zwischen ihnen und die externen Dienste, von denen sie abhängen. Der Fehler-Katalog listet die bekannten Fehlerklassen, ihre Erkennungsmerkmale und die definierten Behandlungsregeln auf — von Retry-Konfiguration über Dead-Letter-Routing bis zu Human-Eskalation. Das Runbook beschreibt für die häufigsten Vorfälle Schritt für Schritt, was wer tut — und zwar so, dass auch Personen, die am System nicht mitgebaut haben, es verstehen und anwenden können.

Ohne diese Dokumentation ist Wissensverlust beim Personalwechsel praktisch garantiert. Mit ihr bleibt das Systemverständnis in der Organisation verankert — unabhängig davon, welche Personen das System ursprünglich konzipiert haben.

Vertiefung IV — Wissensmanagement und Kontinuität in Agenten-Teams

Wissen über orchestrierte Agentensysteme konzentriert sich erfahrungsgemäß bei wenigen Personen, die am Aufbau beteiligt waren. Diese Konzentration ist ein latentes Risiko: Bei Personalwechsel oder längerer Abwesenheit fehlt das Systemverständnis, das für Betrieb, Fehlerdiagnose und Weiterentwicklung unerlässlich ist.

Drei Maßnahmen bauen diesem Risiko systematisch vor. Erstens die bereits genannte Dokumentations-Trias aus Architektur-Diagramm, Fehler-Katalog und Runbook. Zweitens regelmäßige interne Wissens-Sessions: Alle vier bis sechs Wochen erläutert ein Mitglied des Agenten-Teams einem breiteren Kreis, was das System macht, wie es gebaut ist und was die letzten Wochen gezeigt haben. Diese Sessions sind keine Schulungen, sondern Wissenstransfer in beide Richtungen — die Zuhörenden bringen Perspektiven von außen ein, die für Verbesserungen wertvoll sein können. Drittens ein strukturiertes Onboarding-Dokument für neue Teammitglieder: Was muss jemand wissen, um dieses System zu verstehen und im Notfall zu bedienen? Dieses Dokument schreibt sich am besten in den ersten Betriebswochen, wenn die Lernkurve noch frisch ist und die Fragen noch bekannt sind.

Vertiefung V — Agentic Patterns: Reasoning-Architekturen für KI-Agenten

Hinter jedem KI-Agenten steht nicht nur eine Auswahl an Tools, sondern ein Denkprozess — eine Strategie, wie das Sprachmodell von einem Ziel zu einer Handlung gelangt. Diese Strategien haben sich in der Forschung und Praxis als eigenständige Architektur-Muster herausgebildet. Sie bestimmen, wie ein Agent plant, überprüft und korrigiert. Für nicht-technische Fach- und Führungskräfte sind diese Muster keine Programmieraufgaben, sondern Denkwerkzeuge: Sie helfen zu verstehen, warum ein Agent manchmal mehrere Schritte benötigt, warum er seine eigenen Ausgaben hinterfragt — und wann er menschliche Unterstützung einfordert.

Fünf Muster sind für den Unternehmenseinsatz besonders relevant: ReAct, Reflexion / Self-Critique, Planner-Executor, Orchestrator-Worker und Tool-Use mit Function Calling (letzteres wurde in UE 76 technisch eingeführt und wird hier in seinen Mustern vertieft).

Muster 1 — ReAct: Reasoning + Acting

Das ReAct-Pattern (Yao et al., 2022) ist das am weitesten verbreitete Reasoning-Muster für KI-Agenten. Es verbindet Denken (Thought) und Handeln (Action) in einem iterativen Zyklus: Der Agent denkt laut, führt eine Aktion aus, beobachtet das Ergebnis und wiederholt den Zyklus, bis er eine Antwort liefern kann.

Grundstruktur:

Thought: Was ist das Ziel? Was weiß ich bereits? Was muss ich herausfinden?

Action: [Tool-Aufruf oder Teilantwort]

Observation: [Ergebnis des Tool-Aufrufs]

Thought: Was sagt das Ergebnis? Bin ich meinem Ziel näher?

Action: [nächster Tool-Aufruf oder Schlussfolgerung]

Observation: [Ergebnis]

...

Answer: [finale Antwort]

Beispiel — Kundenrecherche vor einem Vertriebstermin:

Thought: Ich soll ein Briefing für den Kundentermin mit Firma Müller GmbH erstellen.

Ich benötige: aktuelle Unternehmensnews, Gesprächspartner-Profil,

interne Projekthistorie.



Action: search_web(query="Müller GmbH aktuell 2025 Neuigkeiten")

Observation: Müller GmbH hat im März 2025 eine neue Fertigungslinie in Bayern eröffnet.



Thought: Relevanter Kontext für das Gespräch. Jetzt das Gesprächspartner-Profil.

Action: crm_read(contact="Klaus Müller", company="Müller GmbH")

Observation: Hauptansprechpartner: Klaus Müller (Einkaufsleiter), seit 2019 Kunde,

letzte Interaktion: Angebot Oktober 2024 (nicht beauftragt).



Thought: Ich habe News und CRM-Daten. Jetzt interne Projekthistorie prüfen.

Action: knowledge_base_search(query="Müller GmbH Projekte Referenzen")

Observation: Zwei abgeschlossene Projekte 2021 und 2022, positive Bewertungen.



Thought: Alle Informationen vorhanden. Ich kann das Briefing erstellen.

Answer: [strukturiertes Briefing-Dokument]

Warum ReAct funktioniert: Der Agent trifft keine voreiligen Schlüsse. Er prüft nach jedem Schritt, ob die gewonnene Information ausreicht — und holt sich nur dann weiteres Wissen, wenn es wirklich nötig ist. Dieses schrittweise Vorgehen reduziert Halluzinationen erheblich, weil das Modell seine Behauptungen gegen tatsächlich abgerufene Daten abgleicht.

Wann ReAct einsetzen: Bei Recherche-intensiven Aufgaben mit unbekanntem Informationsbedarf, bei mehrschrittigen Analysen mit Tool-Zugriff, bei Aufgaben, bei denen der Pfad von Frage zu Antwort nicht vollständig vorhersagbar ist.

Frameworks: LangChain Agents, LangGraph (ReAct als vorgefertigter Graph), OpenAI Assistants API mit Tool-Calls.

Promptbaustein — ReAct-Template für eigene Agenten

Systemanweisung für einen ReAct-Agenten:

Sie sind ein strukturierter Recherche-Assistent. Sie lösen Aufgaben in einem

iterativen Thought-Action-Observation-Zyklus.



Regeln:

1. Beginnen Sie IMMER mit einem Thought-Schritt: Was ist das Ziel?

Was wissen Sie bereits? Was müssen Sie herausfinden?

2. Führen Sie GENAU EINEN Tool-Aufruf pro Action-Schritt durch.

3. Lesen Sie jede Observation sorgfältig: Bringt sie Sie dem Ziel näher?

4. Schreiben Sie eine Answer ERST, wenn Sie alle notwendigen Informationen

gesammelt haben.

5. Wenn ein Tool keine nützlichen Ergebnisse liefert: Formulieren Sie

eine alternative Suchanfrage und versuchen Sie es erneut — maximal

zweimal pro Teilziel.

6. Wenn Sie nach fünf Zyklen kein ausreichendes Ergebnis haben:

Eskalieren Sie mit einer strukturierten Fehlermeldung.



Verfügbare Tools: [TOOL-LISTE EINFÜGEN]



Aufgabe: [AUFGABE EINFÜGEN]

Erwartetes Ergebnis: Ein KI-Agent, der seine Gedankenkette explizit macht, Tool-Ergebnisse vor der nächsten Aktion auswertet und keine vorschnellen Antworten liefert.

Verwendung: Diesen Prompt als Systemanweisung in LangChain, dem OpenAI Assistants-API-Setup oder in n8n-Agenten-Nodes einfügen. Die Struktur Thought: / Action: / Observation: / Answer: ist menschenlesbar und eignet sich direkt als Log-Format.

Muster 2 — Reflexion / Self-Critique

Das Reflexion-Pattern (Shinn et al., 2023) erweitert ReAct um eine kritische Selbstbewertungsebene. Nach der Erstellung einer Antwort prüft der Agent seine eigene Ausgabe gegen definierte Qualitätskriterien — und verbessert sie iterativ, bevor sie nach außen gegeben wird.

Grundstruktur:

[Agent erstellt erste Antwort oder Handlungsplan]



Critique: Erfüllt diese Antwort das Ziel vollständig?

Fehlen Informationen? Gibt es logische Widersprüche?

Entspricht der Tonfall den Anforderungen?



Revision: [Überarbeitete, verbesserte Version]



[Optional: zweiter Reflexionsschritt, wenn Qualitätsschwelle noch nicht erreicht]

Beispiel — Angebotstext-Qualitätsprüfung:

[Erster Entwurf des Angebots: Standardtext mit Preis und Leistungsübersicht]



Critique:

- Bezug auf das letzte Gespräch vom Oktober 2024 fehlt → Personalisierung unzureichend

- Keine Nennung der neuen Fertigungslinie (aus der Unternehmensrecherche bekannt) → Opportunity verpasst

- Pricing-Abschnitt enthält keine Begründung → Kunde könnte Preis ohne Kontext als hoch empfinden

- Tonfall: zu formal, CRM-Note sagt: bevorzugt direkte Kommunikation



Revision: [Überarbeiteter Angebotstext mit Personalisierung, Bezug auf Fertigungslinie,

Pricing-Begründung und direkterem Tonfall]

Konfiguration für Unternehmenseinsatz: Definieren Sie explizit, gegen welche Qualitätskriterien der Agent prüft. Vage Anweisungen wie „prüfe die Qualität” führen zu oberflächlichen Selbstbewertungen. Konkrete Kriterien wie „Ist der Kundenname korrekt? Sind alle Preise aus der aktuellen Preisliste? Enthält der Text einen klaren nächsten Schritt?” erzeugen präzise und verwertbare Selbstkorrekturen.

Iterationslimit: Setzen Sie immer ein Maximum von zwei bis drei Reflexions-Zyklen. Ohne Limit kann ein Agent in eine Verbesserungsschleife geraten, die nicht konvergiert und erhebliche Token-Kosten verursacht.

Frameworks: LangGraph (Reflexion als Zyklus im Graphen), AutoGen (Self-Reflection-Agent-Muster), CrewAI (Quality-Reviewer-Agent als separater Spezialist).

Promptbaustein — Self-Critique-Schritt einbauen

Prompt für Reflexions-Schritt (als separater Agenten-Aufruf oder als Folgeschritt):

Sie erhalten eine KI-generierte Ausgabe und prüfen diese gegen folgende

Qualitätskriterien:



Ausgabe zur Prüfung:

[AUSGABE EINFÜGEN]



Qualitätskriterien:

1. Vollständigkeit: Sind alle in der Aufgabe geforderten Bestandteile vorhanden?

2. Faktentreue: Stimmen alle konkreten Angaben (Namen, Zahlen, Daten) mit den

gegebenen Quellinformationen überein?

3. Tonfall: Entspricht die Sprache der vereinbarten Kommunikationsrichtlinie

[z. B. „professionell, direkt, kundenorientiert"]?

4. Handlungsklarheit: Ist für den Empfänger klar, was als nächstes zu tun ist?

5. Compliance: Enthält die Ausgabe keine Aussagen, die rechtlich problematisch

sein könnten [z. B. Garantieversprechen, ungeprüfte Behauptungen]?



Bewertungsformat:

- Kriterium: [Erfüllt / Teilweise erfüllt / Nicht erfüllt]

- Begründung: [Konkrete Stelle in der Ausgabe]

- Verbesserungsvorschlag: [Konkrete Korrektur]



Abschlussbewertung: Empfehlung zur Weitergabe (Ja / Überarbeitung erforderlich)

Verwendung: Diesen Prompt in einem zweiten Agenten-Schritt oder als separaten Review-Knoten in LangGraph einsetzen. Die strukturierte Bewertung ist direkt als Human-in-the-Loop-Dokument verwendbar — Sachbearbeiter sehen sofort, welche Punkte der Agent bereits kritisch bewertet hat.

Muster 3 — Planner-Executor

Das Planner-Executor-Muster trennt die Planungsphase explizit von der Ausführungsphase. Ein spezialisierter Planner-Agent zerlegt ein komplexes Ziel in sequentielle oder parallele Teilaufgaben (Subgoal-Dekomposition). Diese Teilaufgaben werden dann durch einen oder mehrere Executor-Agenten ausgeführt.

Grundstruktur:

[Planner-Agent]

Input: Übergeordnetes Ziel

Output: Strukturierter Ausführungsplan mit Subgoals



[Executor-Agent(en)]

Input: Einzelne Subgoals aus dem Plan

Output: Ergebnisse je Subgoal



[Aggregator]

Input: Alle Subgoal-Ergebnisse

Output: Konsolidiertes Gesamtergebnis

Beispiel — Marktanalyse-Bericht:

[Planner-Agent erhält Aufgabe]

Ziel: Erstellen Sie einen 5-seitigen Marktanalyse-Bericht für den deutschen

HR-Software-Markt für das Geschäftsführungs-Meeting am Freitag.



Plan:

Subgoal 1: Marktgröße und Wachstumsrate recherchieren (Executor A — Recherche-Agent)

Subgoal 2: Top-5-Anbieter und deren Marktpositionierung analysieren (Executor A)

Subgoal 3: Regulatorische Rahmenbedingungen (EU AI Act, Arbeitnehmer-Datenschutz)

zusammenfassen (Executor B — Compliance-Agent)

Subgoal 4: Trend-Analyse: KI-Funktionen in HR-Software (Executor A)

Subgoal 5: Bericht-Struktur aufbauen und alle Teilkapitel integrieren (Aggregator)



[Executor-Agenten führen Subgoals 1–4 aus]

[Aggregator kombiniert Ergebnisse zu finalem Bericht]

Vorteile gegenüber ReAct: Bei langen, komplexen Aufgaben verhindert die explizite Planungsphase, dass der Agent in Teilschritte verzweigt, die nicht zum Gesamtziel beitragen. Der Plan macht das Vorgehen transparent — er ist direkt als Fortschritts-Dokument nutzbar und ermöglicht Human-in-the-Loop an einer definierten Stelle (nach dem Plan, vor der Ausführung).

Kritischer Schritt — Plan-Review als Human-in-the-Loop: Bevor die Executor-Agenten starten, sollte der Plan von einer verantwortlichen Person reviewt werden. Dies ist die effektivste und günstigste Form des Human-in-the-Loop in einem Planner-Executor-System: Ein kurzer Review des Plans (nicht des finalen Ergebnisses) verhindert, dass alle nachfolgenden Ausführungsschritte in die falsche Richtung gehen.

Frameworks: LangGraph (Plan-and-Execute als vorgefertigter Graph), LangChain Plan-and-Execute Agent, CrewAI (Manager-Agent als Planner, Task-Agenten als Executors).

Promptbaustein — Planner-Prompt für Subgoal-Dekomposition

Systemanweisung für den Planner-Agenten:

Sie sind ein präziser Aufgaben-Planer. Sie erhalten ein komplexes Ziel und

zerlegen es in einen strukturierten, ausführbaren Plan.



Regeln für die Planung:

1. Zerlegen Sie das Ziel in 3–7 konkrete Subgoals. Mehr als 7 Subgoals

deuten auf eine zu feingranulare Zerlegung hin — fassen Sie zusammen.

2. Jedes Subgoal hat: (a) eine klare Eingabe, (b) eine klare erwartete Ausgabe,

(c) das Tool oder den Agenten-Typ, der es ausführt.

3. Kennzeichnen Sie Abhängigkeiten: Welches Subgoal kann erst nach einem

anderen starten? (sequentiell) Welche können parallel starten?

4. Identifizieren Sie den kritischen Pfad: Welche Subgoals bestimmen die

Gesamtlaufzeit?

5. Benennen Sie einen optionalen Human-Review-Punkt nach der Planung.



Ausgabeformat:

Plan für: [Zielbeschreibung]

Subgoal 1: [Beschreibung] | Input: [...] | Output: [...] | Tool: [...] |

Abhängigkeit: [keiner / Subgoal X]

Subgoal 2: ...

Kritischer Pfad: [Subgoal X → Y → Z]

Empfohlener Human-Review-Punkt: [nach Subgoal X, vor Beginn Y]



Ziel: [AUFGABE EINFÜGEN]

Erwartetes Ergebnis: Ein klarer, reviewbarer Plan, der als Grundlage für die Executor-Agenten dient. Der Plan ist gleichzeitig das Transparenz-Dokument für Human-in-the-Loop-Entscheidungen.

Muster 4 — Orchestrator-Worker (Multi-Agent-System)

Das Orchestrator-Worker-Muster ist die strukturierteste Form des Multi-Agent-Systems. Ein zentraler Orchestrator-Agent übernimmt die Koordination und delegiert klar abgegrenzte Teilaufgaben an spezialisierte Worker-Agenten. Worker-Agenten sind hochspezialisiert, kennen nur ihren eigenen Aufgabenbereich und haben keinen Zugriff auf die Gesamtarchitektur. Der Orchestrator ist die einzige Komponente, die den Gesamtüberblick hat.

Grundstruktur:

[Orchestrator]

- Empfängt Gesamtaufgabe von Mensch oder OS-Agent

- Hält den Zustand des Gesamtprozesses

- Entscheidet, welcher Worker wann welche Teilaufgabe erhält

- Aggregiert Ergebnisse und prüft Vollständigkeit

- Eskaliert bei Fehlern oder Unsicherheiten



[Worker A — Recherche-Spezialist]

- Empfängt: Recherche-Auftrag (strukturierter Input)

- Gibt zurück: strukturierte Rechercheergebnisse

- Hat Zugriff auf: Websuche, interne Wissensbasis



[Worker B — Analyse-Spezialist]

- Empfängt: Rohdaten-Paket

- Gibt zurück: Analyse-Ergebnis mit Bewertung

- Hat Zugriff auf: Berechnungstools, strukturierte Daten



[Worker C — Ausgabe-Spezialist]

- Empfängt: Analyse-Ergebnis + Kontext

- Gibt zurück: finales Dokument

- Hat Zugriff auf: Dokumentenvorlagen, PDF-Generator

Beispiel — Nachhaltigkeitsbericht-Erstellung:

Ein produzierendes Unternehmen erstellt quartalsweise einen internen Nachhaltigkeitsbericht. Mit dem Orchestrator-Worker-Muster:

Orchestrator erhält den Auftrag: „Erstelle Q1-2025-Nachhaltigkeitsbericht nach GRI-Standard”

Worker A (Daten-Aggregator): Ruft CO₂-Verbrauchsdaten aus dem ERP-System ab, aggregiert nach Standort und Produktlinie

Worker B (Benchmark-Analyst): Vergleicht Daten mit Q1-2024 und Branchenbenchmarks, erstellt Abweichungsanalyse

Worker C (Compliance-Prüfer): Prüft, ob alle GRI-Pflichtindikatoren abgedeckt sind, markiert Lücken

Worker D (Redakteur): Schreibt Fließtextabschnitte basierend auf Daten und Analyse-Ergebnissen

Orchestrator aggregiert alle Ergebnisse, prüft Konsistenz, erstellt finales Dokument und legt es zur menschlichen Freigabe vor

Abgrenzung zum Planner-Executor-Muster: Im Planner-Executor-Muster entsteht der Plan dynamisch für jede Aufgabe neu. Im Orchestrator-Worker-Muster sind die Workers dauerhaft konfigurierte Spezialisten — die Architektur ist stabiler, aber weniger flexibel.

Geeignet für: Regelmäßig wiederkehrende, strukturierte Aufgaben mit klarer Aufgabenteilung (Berichte, Auswertungen, Qualitätsprüfungen). Nicht geeignet für: einmalige, stark variierende Aufgaben — dort ist der konfigurationsaufwand zu hoch.

Frameworks: CrewAI (nativste Unterstützung des Orchestrator-Worker-Musters durch Manager-Agent + Task-Agents), AutoGen (GroupChat mit Manager), LangGraph (Graph mit zentralem Coordinator-Knoten).

Promptbaustein — Orchestrator-Systemanweisung

Systemanweisung für den Orchestrator-Agenten:

Sie sind der Koordinations-Agent für das folgende Multi-Agenten-System:



Verfügbare Worker-Agenten:

- WORKER_RECHERCHE: Führt Datenrecherche durch (Websuche, interne Wissensbasis)

- WORKER_ANALYSE: Analysiert strukturierte Daten und erstellt Bewertungen

- WORKER_DOKUMENT: Erstellt finale Dokumente nach Vorlagen

- WORKER_COMPLIANCE: Prüft Outputs auf Compliance-Anforderungen



Ihre Aufgaben als Orchestrator:

1. Zerlegen Sie die erhaltene Gesamtaufgabe in Worker-spezifische Teilaufträge.

2. Delegieren Sie jeden Teilauftrag an den passenden Worker.

3. Prüfen Sie jeden Worker-Output auf Vollständigkeit und Plausibilität,

bevor Sie ihn an den nächsten Worker weitergeben.

4. Wenn ein Worker ein fehlerhaftes oder unvollständiges Ergebnis liefert:

Senden Sie den Auftrag mit präzisierter Anweisung einmalig zurück.

5. Wenn nach einer Wiederholung das Ergebnis immer noch unzureichend ist:

Eskalieren Sie mit einer strukturierten Fehlermeldung.

6. Geben Sie das Gesamtergebnis erst frei, wenn alle Teilaufgaben erfolgreich

abgeschlossen und konsistent sind.



Kommunikationsformat an Workers:

WORKER: [WORKER-NAME]

AUFGABE: [Konkrete Teilaufgabe]

INPUT: [Übergabedaten aus vorherigem Schritt oder Originalauftrag]

ERWARTETER OUTPUT: [Exaktes Format des erwarteten Ergebnisses]

QUALITÄTSKRITERIUM: [Woran erkennen Sie, dass der Output korrekt ist?]



Gesamtaufgabe: [AUFGABE EINFÜGEN]

Erwartetes Ergebnis: Ein Orchestrator, der klare Delegation-Nachrichten an Workers sendet und Gesamtergebnisse konsistent aggregiert. Die strukturierten Delegation-Nachrichten sind gleichzeitig das Log-Format für Debugging und Monitoring.

Muster 5 — Tool-Use mit Function Calling: Strukturierte JSON-Toolaufrufe

Tool-Use wurde in UE 76 technisch eingeführt. Als Muster betrachtet, ist Function Calling der Mechanismus, durch den alle anderen agentic Patterns mit der realen Welt interagieren. Hier werden die Muster für professionelle, produktionsbereite JSON-Schemata vertieft.

Vollständiges Function-Calling-Beispiel (OpenAI-Format):

import openai

import json



client = openai.OpenAI()



# Tool-Definitionen: Was der Agent aufrufen darf

tools = [

{

"type": "function",

"function": {

"name": "crm_get_customer",

"description": "Ruft Kundendaten aus dem CRM-System ab. "

"Nur für Lesezugriff. Keine Schreiboperationen.",

"parameters": {

"type": "object",

"properties": {

"customer_id": {

"type": "string",

"description": "Die CRM-Kunden-ID (Format: KD-XXXXX)"

},

"fields": {

"type": "array",

"items": {"type": "string"},

"description": "Gewünschte Felder: z.B. ['name', 'email', "

"'last_contact', 'open_projects']"

}

},

"required": ["customer_id"]

}

}

},

{

"type": "function",

"function": {

"name": "knowledge_base_search",

"description": "Durchsucht die interne Wissensbasis nach relevanten "

"Dokumenten und Vorlagen.",

"parameters": {

"type": "object",

"properties": {

"query": {

"type": "string",

"description": "Suchanfrage in natürlicher Sprache"

},

"doc_type": {

"type": "string",

"enum": ["template", "policy", "faq", "project"],

"description": "Dokumententyp-Filter (optional)"

},

"max_results": {

"type": "integer",

"description": "Maximale Anzahl zurückgegebener Ergebnisse",

"default": 5

}

},

"required": ["query"]

}

}

}

]



# Agenten-Aufruf mit Tool-Definitions

response = client.chat.completions.create(

model="gpt-4o",

messages=[

{

"role": "system",

"content": "Sie sind ein Angebots-Assistent. Nutzen Sie die "

"verfügbaren Tools, um personalisierte Angebotsentwürfe "

"zu erstellen."

},

{

"role": "user",

"content": "Erstelle einen Angebotsentwurf für Kunden KD-00712."

}

],

tools=tools,

tool_choice="auto"

)



# Tool-Calls verarbeiten

if response.choices[0].message.tool_calls:

for tool_call in response.choices[0].message.tool_calls:

function_name = tool_call.function.name

arguments = json.loads(tool_call.function.arguments)

print(f"Agent ruft auf: {function_name}({arguments})")

# Hier: echte Tool-Ausführung und Ergebnis zurückgeben

Anthropic Function-Calling-Format (Claude):

import anthropic



client = anthropic.Anthropic()



tools = [

{

"name": "crm_get_customer",

"description": "Ruft Kundendaten aus dem CRM-System ab (nur Lesezugriff).",

"input_schema": {

"type": "object",

"properties": {

"customer_id": {

"type": "string",

"description": "Die CRM-Kunden-ID (Format: KD-XXXXX)"

}

},

"required": ["customer_id"]

}

}

]



response = client.messages.create(

model="claude-opus-4-5",

max_tokens=1024,

tools=tools,

messages=[

{

"role": "user",

"content": "Erstelle ein Briefing für Kunden KD-00712."

}

]

)

Best Practices für professionelle Tool-Definitionen:

Präzise Beschreibungen: Die description-Felder sind das, was das Modell liest, um zu entscheiden, ob und wann es ein Tool aufruft. Vage Beschreibungen führen zu falschen Tool-Auswahlen.

Constraint-Hinweise in der Beschreibung: Sicherheitsregeln gehören in die Description — nicht nur in eine externe Policy. Z. B.: „Nur Lesezugriff. Keine Schreiboperationen.”

Enum-Felder für begrenzte Wertemengen: Statt "type": "string" für Felder mit bekannten Werten immer "enum": [...] verwenden — das verhindert ungültige Parameter-Werte.

required-Feld konservativ nutzen: Nur wirklich pflichtpflichtige Parameter als required markieren — optionale Parameter mit default-Werten ausstatten.

Nicht mehr als 8–10 Tools gleichzeitig definieren: Zu viele Tool-Definitionen belasten das Kontextfenster und reduzieren die Präzision der Tool-Auswahl.

Vergleich OpenAI vs. Anthropic Function-Calling:

Beide Anbieter unterstützen denselben JSON-Schema-Standard für die Parameter-Definition — der Unterschied liegt in der Wrapper-Struktur.

Merksatz

Die fünf Agentic Patterns sind keine Entweder-oder-Wahl — sie können kombiniert werden. Ein typisches Produktionssystem nutzt Orchestrator-Worker für die Gesamtarchitektur, Planner-Executor für komplexe Einzelaufgaben, ReAct für Recherche-intensive Worker, Reflexion für Qualitätsprüfungen und Function Calling als technischen Mechanismus für alle Tool-Interaktionen. Beginnen Sie immer mit dem einfachsten Muster (ReAct für Einzelagenten, Planner-Executor wenn Komplexität zunimmt) und fügen Sie nur dann ein komplexeres Muster hinzu, wenn das einfachere nachweislich nicht ausreicht.

Übersichtstabelle — Agentic Patterns im Vergleich:

Empfohlene Lernressourcen zu Agentic Patterns:

Yao et al. (2022): ReAct: Synergizing Reasoning and Acting in Language Models — arxiv.org/abs/2210.03629

Shinn et al. (2023): Reflexion: Language Agents with Verbal Reinforcement Learning — arxiv.org/abs/2303.11366

Anthropic (2024): Building Effective Agents — anthropic.com/research/building-effective-agents

LangGraph Dokumentation: Plan-and-Execute, ReAct, Reflexion als vorgefertigte Graphen — langchain-ai.github.io/langgraph

Branchen-Anwendungen

IT-Dienstleistung & Beratung

Ein IT-Beratungsunternehmen mit mehreren Standorten und rund 200 Mitarbeitenden setzt die Drei Architektur-Muster systematisch ein. Der OS-Agent — konfiguriert als zentraler Arbeitskoordinator — kennt alle laufenden Projekte, Kundenkontakte, internen Ressourcen und offenen Deliverables. Jeden Morgen priorisiert er anstehende Aufgaben, sendet eine strukturierte Tages-Zusammenfassung an die Projektleitung und koordiniert Pipeline-Agenten. Der Angebots-Drafting-Agent — ein Pipeline-Agent — erhält strukturierte Kundenbriefings und erstellt Angebotsentwürfe nach dem bewährten Leistungsverzeichnis-Schema; jeder Entwurf geht zur menschlichen Review, bevor er den Kunden erreicht (Gelb-Klassifikation im Drei-Stufen-Freigabemodell). Ein Lead-Dossier-Standalone-Agent läuft vollständig im Hintergrund: Sobald ein neuer Kundentermin im Kalender erscheint, recherchiert er das Unternehmen, die Gesprächspartner und relevante Branchennews — als Briefing-Dokument in Teams abgelegt, fertig für den Berater beim Meeting-Einstieg. Die Einführungsreihenfolge folgt dem Empfehlung: Standalone zuerst (geringste Komplexität, schnellster Mehrwert), dann Pipeline, dann OS-Agent. Nach drei Monaten ist der Standalone-Agent vollständig akzeptiert; dann erst wird der Pipeline-Agent konfiguriert.

Industrie & Fertigung

Ein mittelgroßes Fertigungsunternehmen nutzt orchestrierte Agenten für die Qualitätssicherungs-Dokumentation entlang dreier Produktionslinien. Ein Standalone-Agent liest täglich automatisiert strukturierte Sensordaten aus dem MES (Manufacturing Execution System), vergleicht sie mit Soll-Werten und erstellt für jede Linie einen standardisierten Qualitätsbericht im SharePoint — ohne menschlichen Eingriff im Normalbetrieb (Grün-Klassifikation). Bei Abweichungen über einem konfigurierbaren Schwellenwert wechselt das System automatisch in einen anderen Modus: Ein Pipeline-Agent wird aktiviert, der eine Fehleranalyse-Vorlage befüllt und das Dokument zur Review durch den Qualitätsverantwortlichen weiterleitet (Gelb-Klassifikation). Bei schwerwiegenden Abweichungen wird zusätzlich ein automatisches Eskalations-Ticket erstellt (Rot-Klassifikation). Ein OS-Agent für die Produktionsleitung koordiniert morgens die Prioritäten auf Basis der Nacht-Berichte: Welche Linien brauchen heute besondere Aufmerksamkeit? Welche Wartungstickets sind überfällig? Dieser dreistufige Aufbau — Standalone für Routine, Pipeline für Ausnahmen, OS für Koordination — ist das klassische Orchestrierungsmuster in industriellen Anwendungen.

Finanzdienstleistung & Versicherung

Eine mittelgroße Versicherungsgesellschaft orchestriert die Bearbeitung eingehender Schadenmeldungen nach einem klar definierten Drei-Ebenen-Schema. Ein Standalone-Klassifikations-Agent klassifiziert jede neue Schadenmeldung nach Typ (Kfz, Haftpflicht, Sach), Schwere (Bagatelle, Standard, Komplex) und Zuständigkeitsbereich — vollautomatisch, rund um die Uhr, auch an Wochenenden. Für komplexere Fälle erstellt ein Pipeline-Agent eine strukturierte Erstauswertung: Deckungsumfang prüfen, Vollständigkeit der Unterlagen checken, Bearbeitungspfad vorschlagen, erforderliche Rückfragen identifizieren. Der Sachbearbeiter erhält einen vollständig aufbereiteten, nach Informationsdichte sortierten Fall — und trifft die Entscheidung. Kein Agent trifft Leistungsentscheidungen (Rot-Klassifikation für alle ausgabewirksamen Entscheidungen). Ein OS-Agent unterstützt die Sachbearbeitungsleitung bei der täglichen Ressourcenplanung: Wie viele Fälle pro Sachbearbeiter? Welche Komplexitätsstufen dominieren heute? Wo entstehen Rückstände? Durch die Orchestrierung wird die Bearbeitungszeit für Standardfälle um durchschnittlich 40 % reduziert — ohne dass ein Agent eine einzige Leistungsentscheidung trifft.

Öffentliche Verwaltung

Eine Kommunalverwaltung setzt orchestrierte Agenten für die Bürgeranfragen-Bearbeitung ein — mit besonderer Sorgfalt bei Datenschutz und Rechtmäßigkeit. Ein Klassifikations-Standalone-Agent sortiert eingehende E-Mails und Online-Formularanfragen nach Zuständigkeit (welche Abteilung?) und Dringlichkeit (Standard / dringend / Fristablauf) — ohne inhaltliche Entscheidungen zu treffen, nur auf Basis von Betreff, Formulierungsmustern und erkannten Schlüsselbegriffen. Ein Pipeline-Agent prüft Standardanfragen (Adressänderungen, Ummeldungen, Formularbestellungen) gegen vorhandene Datenbanken und erstellt einen strukturierten Antwort-Entwurf, der der zuständigen Sachbearbeiterin zur Freigabe vorgelegt wird (Gelb-Klassifikation — kein Text geht ohne Freigabe raus). Rechtsrelevante Anfragen (Widersprüche, Anträge mit Ermessensspielraum, komplexe Sozialleistungsanfragen) werden direkt an den Fachbearbeiter weitergeleitet — die KI bereitet ausschließlich die Unterlagen auf (Rot-Klassifikation für Entscheidungen). Vor Inbetriebnahme wurde für alle personenbezogenen Datenverarbeitungsschritte eine Datenschutz-Folgenabschätzung nach Art. 35 DSGVO durchgeführt. Die Ergebnisse sind in der Architekturdokumentation verankert.

Übung 1 — Architektur-Muster zuordnen und begründen

Aufgabe: Fünf beschriebene Agenten-Konzepte müssen dem richtigen Architektur-Muster (OS-Agent / Pipeline-Agent / Standalone-Agent) zugeordnet werden. Die Zuordnung wird mit einer Begründung versehen, die auf das Schlüsselmerkmal des jeweiligen Musters eingeht.

Schritt-für-Schritt: 1. Lesen Sie alle fünf Konzepte vollständig. 2. Identifizieren Sie das Schlüsselmerkmal jedes Konzepts: Ist es interaktiv mit breitem Kontext (OS)? Wartet es auf Aufträge und führt präzise nach Schema aus (Pipeline)? Läuft es autonom im Hintergrund ohne Nutzerinteraktion (Standalone)? 3. Ordnen Sie zu und begründen Sie in einem Satz. 4. Diskutieren Sie in Paaren: Gibt es Konzepte, bei denen die Zuordnung schwierig war — und warum?

Konzepte: - K1: Ein Agent, der jeden Montag automatisch die Projektdaten aus Jira lädt und einen Status-Report-Entwurf in SharePoint ablegt, ohne dass jemand etwas dafür tun muss - K2: Ein Agent, dem Sie morgens Ihre Aufgabenliste mitteilen und der dann selbstständig priorisiert, Erinnerungen setzt und bei Bedarf spezialisierte Agenten beauftragt - K3: Ein Agent, dem Sie strukturierte Kundendaten übergeben und der daraus immer nach demselben Angebotsschema einen Entwurf erstellt - K4: Ein Agent, der bei jeder neuen Bewerbungs-E-Mail automatisch die Qualifikationen mit dem Stellenprofil abgleicht und eine strukturierte Kurzauswertung im Bewerbermanagementsystem ablegt - K5: Ein Agent, den Sie nach Projektinformationen fragen, der alle laufenden Projekte kennt und Ihnen hilft, Entscheidungen über Priorisierungen zu treffen

Musterlösung:

Erläuterung zu K2 vs. K5: Beide sind OS-Agenten, aber unterschiedlich ausgerichtet. K2 hat einen starken Koordinationsaspekt (er beauftragt andere Agenten), K5 ist stärker auf Informationsbereitstellung ausgerichtet. In der Praxis wären das möglicherweise dieselbe Konfiguration mit unterschiedlichen Nutzungsszenarien.

Abgrenzungsregel OS vs. Pipeline: Die entscheidende Frage ist nicht „Wie komplex ist die Aufgabe?“, sondern: „Hat der Agent Kontext über die unmittelbare Aufgabe hinaus — kennt er die Gesamtsituation?” Ein Pipeline-Agent weiß nur, was ihm direkt übergeben wird — und das ist seine Stärke: Vorhersagbarkeit. Ein OS-Agent weiß mehr: Er kennt Prioritäten, Projekte, Organisationsstruktur.

Musterlösung Übung 1 — Vertiefung:

Die Abgrenzung zwischen OS-Agent und Pipeline-Agent ist in der Praxis die häufigste Unsicherheit. Die entscheidende Frage ist nicht „Wie komplex ist die Aufgabe?” sondern „Nimmt der Agent Kontext über die unmittelbare Aufgabe hinaus wahr?” Ein Pipeline-Agent weiß nur, was ihm direkt übergeben wird — und das ist seine Stärke. K3 ist trotz komplexer Ergebnis-Dokumente ein Pipeline-Agent, weil er ausschließlich auf strukturierten Input reagiert. K2 ist trotz einer möglicherweise einfachen Tagesplanung ein OS-Agent, weil er den Gesamtkontext kennt und Koordinationsentscheidungen trifft.

Übung 2 — Agentensystem skizzieren und begründen

Aufgabe: Sie skizzieren ein dreistufiges Agentensystem für einen Unternehmensbereich Ihrer Wahl (Vertrieb, Projektmanagement, HR oder Marketing). Das Ergebnis ist eine beschriftete Architekturskizze mit Begründungen.

Schritt-für-Schritt: 1. Wählen Sie einen Unternehmensbereich. 2. Definieren Sie den OS-Agenten: Welche Koordinationsaufgaben hat er? Welchen Kontext braucht er? 3. Definieren Sie zwei Pipeline-Agenten: Welche Spezialisierungsaufgaben haben sie? Was sind Input und Output? 4. Definieren Sie einen Standalone-Agenten: Welches Ereignis löst ihn aus? Was liefert er? Wo legt er das Ergebnis ab? 5. Zeichnen Sie die Architektur als Pfeildiagramm. 6. Notieren Sie für jeden Agenten: Empfohlener Tool-Stack, Ampelklassifikation (Grün/Gelb/Rot) mit Begründung, größtes Risiko. 7. Bestimmen Sie die Einführungsreihenfolge: Welcher Agent wird zuerst gebaut?

Musterlösung — Vertriebsbereich:

OS-Agent — Tages-Vertriebsassistent - Koordinationsaufgaben: Tagespriorisierung der offenen Deals, Koordination der Pipeline-Agenten, Beantwortung von Fragen zu Kunden und Projekten - Kontext: Alle laufenden Deals im CRM, Preisliste, Produktkatalog, Kundenkommunikations-Archiv - Tool-Stack: Custom GPT mit breitem System-Prompt oder Claude Desktop - Ampel: Gelb — erstellt Vorschläge, keine autonomen Ausgaben nach außen - Größtes Risiko: Veraltete Daten im zentralen Kontext führen zu falschen Empfehlungen

Pipeline-Agent 1 — Angebots-Drafting - Aufgabe: Strukturierte Kundendaten + Anforderungsbeschreibung → Angebotsentwurf nach Vorlage - Input: Kundenprofil (Name, Branche, Anforderung), gewünschte Leistungen - Output: Vollständiger Angebotsentwurf mit kalkulierten Preisen im Standard-Template - Tool-Stack: Custom GPT mit Preislisten-Wissen und Angebotsvorlage - Ampel: Gelb — jeder Entwurf zur menschlichen Review bevor er den Kunden erreicht - Größtes Risiko: Falsche Preiskalkulation bei Sonderkonfigurationen

Pipeline-Agent 2 — CRM-Update-Agent - Aufgabe: Strukturierter Gesprächsbericht → CRM-Datensatz-Update - Input: Gesprächsprotokoll (strukturiertes Format nach Meeting) - Output: Aktualisierter CRM-Eintrag mit allen Feldern - Tool-Stack: n8n-Workflow mit LLM-Node und CRM-API-Integration - Ampel: Gelb — CRM-Update-Vorschlag zur Bestätigung vorlegen - Größtes Risiko: Falsche Zuordnung zu Kundendatensatz

Standalone-Agent — Meeting-Vorbereiter - Auslöser: Neuer Kundentermin erscheint im Kalender (>24h im Voraus) - Aufgabe: Unternehmen recherchieren, Gesprächspartner-Profile, relevante News der letzten 30 Tage - Output: Strukturiertes Briefing-Dokument in Teams-Kanal des Vertrieblers - Tool-Stack: Power Automate mit AI Builder + Websuche-Tool - Ampel: Grün — reine Informationsbereitstellung, keine Ausgaben nach außen - Größtes Risiko: Veraltete oder falsche Quellinformationen

Einführungsreihenfolge: 1. Meeting-Vorbereiter (Standalone — sofortiger sichtbarer Nutzen, kein Risiko) 2. Angebots-Drafting (Pipeline — klarer Prozess, messbarer Zeitgewinn) 3. CRM-Update-Agent (Pipeline — höhere Integrationsanforderungen) 4. Tages-Vertriebsassistent (OS — setzt Akzeptanz der anderen Agenten voraus)

PromptBox — Orchestrierungskonzept formulieren

Prompt: Dreistufiges Agentensystem konzeptionell spezifizieren

Ich möchte ein dreistufiges KI-Agentensystem für den Bereich

[BEREICH, z. B. Vertrieb / HR / Projektmanagement / Qualitätssicherung]

in einem Unternehmen der Branche [BRANCHE, z. B. IT-Dienstleistung / Fertigung]

mit [GRÖSSE, z. B. 200 Mitarbeitenden] konzeptionell spezifizieren.



Beschreibe bitte für jedes der drei Architektur-Muster:



1. OS-Agent:

- Koordinationsaufgaben

- Benötigter Kontext (welche Datenquellen, welches Firmenwissen)

- Empfohlener Tool-Stack

- Ampelklassifikation (Grün/Gelb/Rot) mit Begründung



2. Zwei Pipeline-Agenten (jeweils):

- Klar abgegrenzte Aufgabe

- Input-Format und Output-Format

- Empfohlener Tool-Stack

- Human-in-the-Loop-Mechanismus



3. Einen Standalone-Agenten:

- Auslösendes Ereignis (Trigger)

- Aufgabe und Output

- Ablageort des Ergebnisses

- Monitoring-Mechanismus (wie merke ich, wenn er fehlschlägt?)



Für das Gesamtsystem:

- Empfohlene Einführungsreihenfolge (welcher Agent zuerst?)

- Größtes Risiko und wie es adressiert wird

- Token-Budget-Schätzung für den Standalone-Agenten



Beginne mit einer kurzen Beurteilung, ob das dreistufige System gerechtfertigt ist

oder ob ein einfacherer Ansatz ausreicht.

Erwartetes Ergebnis: Eine vollständige Architekturspezifikation, die als Grundlage für ein IT-Briefing, ein internes Projektgespräch oder eine Entscheidungsvorlage für die Führungsebene genutzt werden kann.

Cheat-Sheet — Orchestrierung kompakt

Reflexionsfragen

Welches der drei Architektur-Muster wäre für Ihre Organisation der realistischste Einstieg im nächsten Jahr — und warum beginnen Sie nicht sofort damit?

Was sind die Risiken eines OS-Agenten, der zu viel Entscheidungsfreiheit hat und zu wenig Human-in-the-Loop-Design aufweist?

Wie würden Sie einem Kunden oder einer Führungskraft den Unterschied zwischen einem gut konfigurierten Custom GPT (Pipeline-Agent) und einem OS-Agenten mit Orchestrierung erklären — in maximal drei Sätzen?

Welche Aufgaben in Ihrem Arbeitsumfeld könnten durch einen Standalone-Agenten vollständig automatisiert werden, ohne dass ein Mensch jeden Einzelfall prüfen muss — und welche Voraussetzungen fehlen noch?

Wenn Sie einem Projektteam ein orchestriertes Multi-Agenten-System empfehlen würden: Welche drei Fragen stellen Sie zuerst, bevor Sie die Architektur definieren?

Welche organisatorischen Voraussetzungen müssen erfüllt sein, bevor ein orchestriertes Agentensystem in Produktion gehen kann — und was passiert konkret, wenn diese Voraussetzungen fehlen?

Die Empfehlung lautet: „Beginnen Sie mit dem einfachsten Ansatz.” Wann ist ein einfacher Custom GPT genug — und ab wann ist Orchestrierung gerechtfertigt? Formulieren Sie eine persönliche Entscheidungsregel.

Quellen & Weiterlesen

Hinweise für AI Champions — So vermitteln Sie das Thema

Timing (45 Min): 5 Min Einstieg (Analogie: 25 separate Agenten vs. zentrales System — visuell an der Tafel skizzieren; Frage: „Was wäre Ihr erster Gedanke, wenn IT Ihnen sagt: Wir haben 25 KI-Agenten, alle mit eigenem Firmenwissen?“), 15 Min Input (Drei Architektur-Muster in Detail + CrewAI/LangGraph Konzepte + Vier Herausforderungen), 5 Min Mini-Übung (Muster zuordnen — K1 bis K5 in der Gruppe oder allein besprechen), 15 Min Gruppenübung (Agentensystem skizzieren, Übung 2 in Zweier-/Dreiergruppen), 5 Min Präsentation je Gruppe (Ergebnis in 60 Sekunden vorstellen) und Übergangsdiskussion.

Methodische Empfehlung: Das Einstiegsbild — 25 Agenten mit separatem Firmenwissen auf der linken Tafelseite vs. 1 zentrale Wissensbasis mit drei spezialisierten Executor-Agenten auf der rechten Seite — sollte als erstes gezeichnet werden, bevor irgendein Text präsentiert wird. Dieses visuelle Kontrastbild bleibt hängen und erklärt das „Warum” der Orchestrierung besser als jeder Folienvortrag. Erst wenn das Bild diskutiert und verstanden ist, die Drei Architektur-Muster einführen.

Häufige Stolpersteine:

(a) Verwechslung OS-Agent und Pipeline-Agent: Die häufigste Unsicherheit. Klärungsfrage: „Hat er Initiative und Kontext über die aktuelle Aufgabe hinaus — oder wartet er auf Aufträge und führt präzise aus?” Wer Initiative hat und Kontext kennt = OS. Wer wartet und präzise ausführt = Pipeline. Hilfreiche Metapher: OS-Agent = persönlicher Assistent, der selbst entscheidet, wen er hinzuzieht. Pipeline-Agent = spezialisierter Handwerker, der sehr gut macht, was bestellt wurde — aber nichts darüber hinaus.

(b) Sofortiger Wunsch nach OS-Agent-Implementierung: Gegensteuern mit klarer Zeitperspektive: „Der OS-Agent ist das Zwölf- bis Vierundzwanzig-Monats-Ziel. Fangen Sie mit einem Standalone-Agenten an — der ist in einer Woche gebaut und zeigt sofort Ergebnisse.”

(c) CrewAI und LangGraph als Lernziel missverstanden: Explizit klarstellen zu Beginn: „Wir lernen die Konzepte als Denkwerkzeuge, nicht den Python-Code. Das konzeptionelle Verständnis reicht, um Architekturen zu spezifizieren und mit Entwicklungsteams zu sprechen.”

(d) Unterschätzung der Betriebskomplexität: Teilnehmende fokussieren auf die Bauphase, nicht auf den Betrieb. Die Tabelle „Drei Architektur-Ansätze im Vergleich” explizit besprechen: Implementierungsaufwand und Betriebsaufwand steigen mit Komplexität überproportional.

Diskussionsfragen für Gruppenarbeitsphase:

„Welcher Standalone-Agent wäre in Ihrem Arbeitsumfeld in zwei Wochen realisierbar — und was bremst Sie konkret? Ist es ein technisches Hindernis, ein Genehmigungshindernis oder ein Wissenslücke?”

„Wann lohnt sich Orchestrierung nicht? Nennen Sie ein Beispiel aus Ihrem Kontext, wo ein einfacher gut konfigurierter Custom GPT besser wäre als ein dreistufiges orchestriertes System.”

Tafelbild-Vorschlag:

Links: 25 Agenten-Symbole (Kreise) mit je einem eigenen Firmenwissen-Symbol (Bücherstapel). Verbindungsaufwand bei Änderungen durch viele rote Pfeile visualisieren. Rechts: 1 zentrales Wissensbasis-Symbol, darunter 3 Agenten-Typen (OS oben, Pipeline und Standalone jeweils seitlich und unten) mit Delegationspfeilen. Beide Seiten beschriften: „Wartungsaufwand durch Dezentralisierung” (links) vs. „Skalierbarkeit durch Zentralisierung” (rechts).

Differenzierung Power-User ↔ Einsteiger:

Einsteiger: Übung 1 (Zuordnung) vollständig durcharbeiten und begründen können. Übung 2 für einen Bereich beginnen — Standalone-Agent und mindestens einen Pipeline-Agenten definieren.

Power-User: Übung 2 vollständig abschließen inkl. Ampelklassifikation und Einführungsreihenfolge. Zusatzaufgabe: Für den geplanten Agenten aus UE 84 die Orchestrierungsfrage stellen — Standalone genug, oder Pipeline-Agenten-Logik nötig? Wie würde LangGraph das als Graph darstellen?

Branchenspezifische Einstiegsfragen:

IT-Beratungsgruppen: „Wie viele verschiedene Assistenten oder Bots hat Ihre Organisation aktuell — und wie viele verschiedene Systemanweisungen existieren parallel?”

Industriegruppen: „Welche Reporting-Aufgaben werden täglich manuell erstellt, obwohl alle Daten strukturiert in Systemen vorliegen?”

Finanzgruppen: „Wie viele Schritte hat die Bearbeitung einer Standardschadenmeldung, und welche davon brauchen wirklich menschliches Urteil?”

Verwaltungsgruppen: „Welche Bürgeranfragen werden täglich beantwortet, deren Antwort sich zu 80 % deckt?”

Materialliste: Whiteboard/Flipchart für Tafelskizze; ausgedruckte Übungsblätter für Übung 1 (K1–K5 ohne Musterlösung); Architektur-Canvas-Vorlage für Übung 2 (strukturiertes Raster mit den vier Agenten-Feldern + Tool-Stack + Ampel + Risiko); PromptBox-Ausdruck als Referenz.

Übergang zur nächsten UE: „Sie verstehen jetzt, wie Agenten zusammenarbeiten können und welche Architektur-Muster es gibt. In UE 80 stellen wir die vorgelagerte Frage: Welche Prozesse sind überhaupt geeignet für Agenten — und wie bewerten Sie das systematisch, bevor Sie mit dem Bauen beginnen?”

Quelle: KI-Wissensbasis von MindsMachines, Edition Juni 2026. Vollständige Fassung mit Anhängen und Musterlösungen: als PDF anfordern.