Viele AI-Workflows scheitern nicht am Modell, sondern an einer falschen Aufgabenstruktur. Genau hier kommt Task Decomposition ins Spiel: Du zerlegst eine große Aufgabe in kleinere, klar prüfbare Schritte. Klingt banal, ist aber einer der wichtigsten Hebel für Qualität, Kosten und Zuverlässigkeit.
Die Grundfrage lautet: Ist die Aufgabe wirklich mehrstufig – oder nur schlecht formuliert?
Wenn ein Task linear und eindeutig ist (z. B. „extrahiere Rechnungsnummer und Datum aus dieser Rechnung“), dann ist ein einzelner, sauberer Durchlauf meistens besser. Wenn aber Unsicherheit, mehrere Quellen, Validierung oder Priorisierung enthalten sind, bringt Zerlegung massive Vorteile.
Ein gutes Decomposition-Schema hat drei Eigenschaften:
1. Jeder Schritt hat einen klaren Zweck.
Nicht „Schritt 1: denke nach“, sondern „Schritt 1: identifiziere fehlende Informationen“.
2. Jeder Schritt hat ein überprüfbares Output-Format.
Beispielsweise ein JSON-Objekt mit Pflichtfeldern statt freiem Fließtext.
3. Übergaben sind eindeutig.
Der nächste Schritt bekommt nur die relevanten Ergebnisse, nicht den kompletten Kontext-Müll.
In der Praxis funktionieren oft diese Decomposition-Muster:
Erst Daten sammeln, dann bewerten, dann Entscheidung ableiten, dann Antwort formulieren.
Besonders stark bei Tool-gestützten Flows: erst Plan, dann Ausführung, dann Prüfung gegen Kriterien, dann gezielte Korrektur.
Für Tickets/Inbox-Workflows: priorisieren, Kategorie bestimmen, dann passenden Lösungsweg fahren.
Wichtig fürs Exam: Decomposition ist kein Selbstzweck. Jeder zusätzliche Schritt kostet Tokens und Zeit und erhöht Koordinationsfehler. Ein klassischer Anti-Pattern ist „Over-splitting“: 10 Mini-Tasks, obwohl 3 gereicht hätten. Das führt zu Latenz, inkonsistenten Zwischenständen und unnötiger Komplexität.
Deshalb brauchst du Stop-Regeln:
Ein weiterer Profi-Move ist risikobasierte Zerlegung: Kritische Teile (z. B. Compliance-Entscheidung, Geldbewegung, Security-Konfig) bekommen eigene Validierungsschritte. Unkritische Teile (z. B. Textformatierung) bleiben schlank.
Du solltest außerdem zwischen funktionaler und organisatorischer Zerlegung unterscheiden:
Für Foundations reicht oft funktionale Zerlegung. Organisatorische Trennung wird wichtig, wenn Sicherheit/Isolation im Fokus steht.
Merksatz: Gute Decomposition minimiert Unsicherheit pro Schritt. Schlechte Decomposition verteilt Verwirrung auf mehr Schritte.
Wenn du bei einer Exam-Frage begründen kannst, warum du auf 3 statt 7 Schritte gehst (oder umgekehrt), zeigst du echtes Architekturverständnis statt reines Buzzword-Wissen.
Ein Workflow „Recherche zu drei Quellen + Empfehlung + E-Mail-Entwurf“ liefert inkonsistente Ergebnisse. Welche Decomposition würdest du wählen und warum?
Sinnvoll ist z. B. Gather → Compare → Decide → Draft mit klaren Zwischenoutputs (z. B. Vergleichsmatrix vor der Empfehlung). So wird die Entscheidung auf überprüfbare Fakten gestützt und Inkonsistenzen werden im Compare-Schritt sichtbar, bevor der Entwurf erzeugt wird.