KI-Architektur-Entscheidungsbaum

Die häufigste teure Fehlentscheidung bei KI-Projekten passiert ganz am Anfang: das falsche Setup wählen. Viele bauen ein komplexes Agenten-Framework, wo ein einziger API-Call gereicht hätte — oder basteln fragile Prompt-Ketten, wo ein No-Code-Tool in einer Stunde fertig gewesen wäre. Dieser Entscheidungsbaum bringt dich in wenigen Minuten zum richtigen Ansatz.

Erstellt von der FlowKI-Community. Der Baum ordnet nach Architektur-Prinzipien, nicht nach Tagesform einzelner Tools — die Kriterien bleiben stabil, auch wenn sich einzelne Frameworks schnell ändern. Orientierung, keine Vollständigkeitsgarantie.

---

Die goldene Regel: das einfachste Setup, das die Aufgabe löst

Jede Stufe nach oben kostet mehr Aufwand, mehr Fehlerquellen und mehr Betriebskosten. Fang immer unten an und steige nur auf, wenn dich eine konkrete Anforderung dazu zwingt.

Einfach ─────────────────────────────────────────────► Komplex
1. Prompt   2. Prompt-Kette   3. RAG   4. Workflow-Tool   5. Agent

Der Entscheidungsbaum

Beantworte die Fragen der Reihe nach. Die erste, bei der du „ja" sagst, zeigt dir den passenden Ansatz.

Frage 1 — Reicht eine einzige, gut formulierte Anfrage? Text zusammenfassen, klassifizieren, umformulieren, übersetzen, ein einzelnes Ergebnis erzeugen — ohne dass Zwischenschritte oder externe Daten nötig sind. → Ja: Reiner API-Call (Archetyp 1). Nicht weiterlesen, du bist fertig.

Frage 2 — Sind es mehrere feste, vorher bekannte Schritte in fester Reihenfolge? Z.B. erst extrahieren, dann bewerten, dann formatieren — der Ablauf steht fest, das Modell muss nicht selbst entscheiden, was als Nächstes kommt. → Ja: Prompt-Kette in eigenem Code (Archetyp 2).

Frage 3 — Muss die KI auf dein eigenes, aktuelles Wissen zugreifen? Antworten sollen aus deinen Dokumenten, deiner Datenbank, deinem Handbuch kommen — nicht aus dem allgemeinen Trainingswissen des Modells. → Ja: RAG (Archetyp 3). Oft kombiniert mit 2 oder 5.

Frage 4 — Willst du vor allem Apps verbinden und Abläufe automatisieren — möglichst ohne selbst zu programmieren? „Wenn neue E-Mail → Anhang auslesen → in Tabelle schreiben → Slack-Nachricht." Der Wert steckt in der Verkettung von Diensten, nicht in cleverem KI-Reasoning. → Ja: Workflow-/No-Code-Tool (Archetyp 4), z.B. n8n.

Frage 5 — Muss das System selbst entscheiden, welche Schritte/Werkzeuge es in welcher Reihenfolge nutzt? Die Aufgabe ist offen, die nötigen Schritte hängen vom Zwischenergebnis ab, das Modell soll Werkzeuge in einer Schleife aufrufen, bis das Ziel erreicht ist. → Ja: Agenten-Ansatz (Archetyp 5). Vorsicht: teuerste und fehleranfälligste Stufe.

Wenn du bei keiner Frage sicher „ja" sagen kannst, ist die Aufgabe wahrscheinlich noch nicht scharf genug definiert — dann erst das Problem schärfen, nicht das Framework wählen.

Die Entscheidungskriterien auf einen Blick

Kriterium	1 API-Call	2 Prompt-Kette	3 RAG	4 Workflow-Tool	5 Agent
Mehrere Schritte nötig	nein	ja, fest	oft	ja, fest	ja, dynamisch
Eigene/aktuelle Daten	nein	optional	ja	optional	oft
Externe Tools/APIs aufrufen	nein	selten	selten	ja	ja
Modell entscheidet Ablauf selbst	nein	nein	nein	nein	ja
Ohne Programmieren machbar	teils	nein	teils	ja	selten
Betriebskosten / Komplexität	niedrig	niedrig–mittel	mittel	niedrig–mittel	hoch
Vorhersagbarkeit des Ergebnisses	hoch	hoch	mittel	hoch	niedrig

Die fünf Archetypen im Detail

1. Reiner API-Call (Single Prompt)

Ein Prompt rein, ein Ergebnis raus. Das mit Abstand unterschätzte Setup — überraschend viele „KI-Features" brauchen nicht mehr.

• Nimm es, wenn: die Aufgabe in einem Schritt lösbar ist (Zusammenfassung, Klassifikation, Extraktion, Textgenerierung).
• Nimm es nicht, wenn: du externe Daten brauchst oder mehrere abhängige Schritte hast.
• Werkzeuge: die offiziellen SDKs (Anthropic, OpenAI, Google) oder ein einzelner HTTP-Request.
• Fallstrick: an der Prompt-Qualität sparen und stattdessen ein Framework draufsetzen — das löst das eigentliche Problem nicht.

2. Prompt-Kette (deterministischer Workflow in eigenem Code)

Mehrere API-Calls in fester Reihenfolge, verdrahtet in deinem eigenen Code (Python, TypeScript). Du behältst die volle Kontrolle über jeden Schritt.

• Nimm es, wenn: die Schritte feststehen (extrahieren → prüfen → formatieren) und du Vorhersagbarkeit brauchst.
• Nimm es nicht, wenn: die nötigen Schritte erst zur Laufzeit klar werden — dann Archetyp 5.
• Werkzeuge: oft reicht das nackte SDK plus normaler Code. Ein Framework ist hier optional, nicht Pflicht.
• Fallstrick: vorschnell zu einem Agenten greifen. Ein fester Ablauf, den du selbst verdrahtest, ist billiger, schneller und leichter zu debuggen als ein Agent, der „selbst denken" soll.

3. RAG (Retrieval-Augmented Generation)

Die KI zieht zur Laufzeit passende Ausschnitte aus deiner eigenen Wissensbasis in den Prompt. Der Standardweg, um über eigene/aktuelle Inhalte antworten zu lassen.

• Nimm es, wenn: Antworten aus deinen Dokumenten/Daten kommen sollen und sich diese häufig ändern.
• Nimm es nicht, wenn: die Wissensmenge winzig ist — dann passt sie oft direkt in den Prompt (Archetyp 1/2), kein Retrieval nötig.
• Werkzeuge: eine Vektor-Datenbank plus Retrieval-Logik; viele Agenten-Frameworks bringen RAG-Bausteine mit.
• Fallstrick: Sicherheit unterschätzen — abgerufene Inhalte sind Fremdeingaben. Siehe die RAG-Security-Checkliste.

4. Workflow-/No-Code-Tool (n8n, Make, Zapier)

Visuelle Automatisierung: Dienste per Knoten verketten, KI als einen Baustein unter vielen. Der Wert liegt in der Integration, nicht im KI-Reasoning.

• Nimm es, wenn: du vor allem Apps verbinden und Abläufe automatisieren willst — gern ohne viel Code — und schnell live sein möchtest.
• Nimm es nicht, wenn: du sehr feine Kontrolle über die Logik brauchst oder extreme Skalierung/Performance nötig ist.
• Werkzeuge: n8n ist im DACH-Raum besonders beliebt, weil es selbst gehostet werden kann (starker DSGVO-Hebel). Fertige Vorlagen im n8n-Vorlagen-Hub.
• Fallstrick: Datenschutz übersehen, wenn der Workflow personenbezogene Daten an externe (z.B. US-)Dienste schickt.

5. Agenten-Ansatz (dynamische Tool-Nutzung in der Schleife)

Das Modell entscheidet selbst, welche Werkzeuge es in welcher Reihenfolge aufruft, und arbeitet in einer Schleife, bis das Ziel erreicht ist. Mächtig — und die mit Abstand teuerste und am schwersten vorhersagbare Stufe.

• Nimm es, wenn: die Aufgabe wirklich offen ist und die Schritte vom Zwischenergebnis abhängen (Recherche-Assistent, autonome Bearbeitung, Coding-Agent).
• Nimm es nicht, wenn: ein fester Ablauf (Archetyp 2) die Aufgabe auch löst — was öfter der Fall ist, als es zunächst wirkt.
• Werkzeuge (Prinzip, nicht Empfehlung): eine einfache selbstgebaute Tool-Schleife mit dem nackten SDK, ein Orchestrierungs-Framework, oder ein Framework für Multi-Agenten-Zusammenspiel. Welches Framework „das beste" ist, ändert sich schnell — entscheide nach deinem Sprach-Ökosystem und danach, wie viel das Framework dir wirklich abnimmt.
• Fallstrick: unbegrenzte Schleifen, explodierende Token-Kosten und schwer reproduzierbare Fehler. Immer harte Grenzen (max. Schritte, Budget) und Logging pro Schritt einbauen.

MCP — der Querschnitt, kein eigener Archetyp

Das Model Context Protocol (MCP) ist kein weiterer Archetyp, sondern ein Standard, wie ein Modell Werkzeuge und Datenquellen anspricht. Es ist vor allem in den Archetypen 4 und 5 relevant: Statt jede Integration einzeln zu verdrahten, sprichst du Werkzeuge über eine einheitliche Schnittstelle an. Einstieg dazu: MCP-Server-Starter und MCP absichern & debuggen.

Drei häufige Fehlentscheidungen

1. Agent, wo eine Prompt-Kette reicht. Der teuerste Standardfehler. Wenn du den Ablauf vorher aufzeichnen kannst, verdrahte ihn selbst (Archetyp 2) statt ihn ein Modell „herausfinden" zu lassen.
2. Eigener Code, wo ein No-Code-Tool gereicht hätte. Reine App-zu-App-Automatisierung ist in n8n/Make oft in einer Stunde fertig — und leichter zu warten.
3. RAG als Reflex. Passt die Wissensmenge in den Kontext, brauchst du kein Retrieval. Erst die einfachste Variante testen, dann bei Bedarf auf RAG aufstocken.

Ehrlicher Hinweis

Die konkrete Framework-Landschaft (welche Bibliothek gerade führt, welche Features/Preise gelten) ändert sich im KI-Bereich schnell. Deshalb ordnet dieser Baum bewusst nach stabilen Entscheidungskriterien — Anzahl der Schritte, eigene Daten, Tool-Nutzung, wer den Ablauf bestimmt — und nennt bei den Werkzeugen Prinzipien statt Ranglisten. Prüfe die aktuelle Tool-Wahl kurz gegen den Stand von heute, bevor du dich festlegst.

Fragen zur Architektur-Wahl? In der FlowKI-Community kannst du dein konkretes Vorhaben zur Diskussion stellen, bevor du baust.