Kurz gesagt: Nicht jede KI-Anwendung muss planen, Tools auswählen und selbstständig handeln. Oft reicht ein gutes LLM, eine RAG-Suche, ein direkter API-Aufruf oder ein klassischer Workflow. In diesem Artikel schauen wir uns an, wann welche Architektur sinnvoll ist – vom einfachen Prompt bis zum begrenzten autonomen Agenten. Und am Ende geht es technisch ans Eingemachte.

Wenn du dich für KI, Automatisierung und die neuesten Entwicklungen rund um Agenten interessierst, findest du auf dem YouTube-Kanal von Nerdoase zahlreiche Videos, Experimente und Praxisbeispiele.

Der Agenten-Reflex: „Wir bauen einen Agenten!“

Kaum fällt heute in einem Meeting der Satz „Das sollten wir mit KI lösen“, folgt oft reflexartig die nächste Aussage:

„Dann bauen wir einen KI-Agenten.“

Das klingt modern, zukunftssicher und natürlich beeindruckend. Ein Agent wirkt schließlich wie die nächste Evolutionsstufe nach dem Chatbot: Er denkt mit, verwendet Werkzeuge, plant Aufgaben und erledigt Dinge selbstständig.

Das Problem: Ein Agent ist nicht automatisch die bessere Lösung.

Wer einen Agenten baut, obwohl ein einzelner Modellaufruf oder ein fester Workflow ausreichen würde, kauft sich zusätzliche Komplexität ein:

• mehrere LLM-Aufrufe statt nur eines Aufrufs,
• höhere Kosten und längere Antwortzeiten,
• mehr Fehlerquellen,
• schwierigeres Testen,
• zusätzliche Sicherheitsrisiken,
• kompliziertere Wartung,
• schlechtere Nachvollziehbarkeit.

Die wichtigste Frage lautet deshalb nicht:

„Wie bauen wir einen Agenten?“

Sondern:

„Was muss das System wissen, worauf muss es zugreifen und was muss es tun?“

Erst danach entscheidet sich, welche Architektur wirklich notwendig ist.

Abbildung: Ein KI-System lebt von Wissen, sicheren Verbindungen und klar angebundenen Werkzeugen.

Die KI-Eskalationsleiter

Stufe 1: Ein LLM

Ein einfaches Large Language Model reicht, wenn die Aufgabe hauptsächlich aus Sprache oder unstrukturierten Informationen besteht.

Typische Beispiele:

• E-Mails zusammenfassen,
• Texte umformulieren,
• Übersetzungen erstellen,
• Inhalte klassifizieren,
• Stichpunkte in einen Artikel verwandeln,
• eine Antwort auf Basis des mitgelieferten Textes formulieren.

Das Modell erhält eine Eingabe, verarbeitet sie und liefert eine Ausgabe. Kein Tool-Aufruf, keine Datenbank, kein langfristiger Zustand und keine autonome Planung.

Kosten: niedrig
Geschwindigkeit: hoch
Risiko: meist begrenzt, solange keine externen Aktionen ausgelöst werden
Typischer Fehler bei Überdimensionierung: Ein Agent plant mehrere Schritte für eine Aufgabe, die mit einem Prompt erledigt wäre.

Stufe 2: LLM plus Retrieval oder RAG

Ein LLM kennt nicht automatisch deine aktuelle Dokumentation, internen Richtlinien oder Produktinformationen. Wenn Antworten auf Unternehmenswissen basieren sollen, kommt Retrieval-Augmented Generation – kurz RAG – ins Spiel.

Dabei wird zunächst nach passenden Informationen gesucht. Nur die relevanten Textstellen werden anschließend als Kontext an das Modell übergeben.

RAG eignet sich beispielsweise für:

• interne FAQs,
• Handbücher,
• Richtlinien,
• Produktdokumentation,
• Schulungsunterlagen,
• Wissensdatenbanken.

Kosten: moderat
Geschwindigkeit: abhängig von Suche und Datenmenge
Risiko: falsche oder veraltete Dokumente können zu falschen Antworten führen
Typischer Fehler bei Überdimensionierung: Ein autonomer Agent wird gebaut, obwohl nur verlässliche Antworten aus Dokumenten benötigt werden.

Wichtig: RAG ist kein Live-System. Wenn die Dokumente nicht regelmäßig aktualisiert und synchronisiert werden, bleibt auch die Antwort auf einem alten Wissensstand.

Stufe 3: Direkter API- oder Tool-Aufruf

Sobald aktuelle, strukturierte Daten benötigt werden, ist eine direkte API meistens besser als RAG.

Beispiele:

• aktueller Lieferstatus,
• Kontostand,
• Lagerbestand,
• CRM-Datensatz,
• Wetterdaten,
• Aktienkurs,
• Bestellstatus,
• Ticketstatus.

Eine Wissensdatenbank kann zwar einen Text enthalten, in dem ein Bestellstatus von gestern beschrieben wird. Sie ist aber nicht die autoritative Quelle für den aktuellen Status. Dafür sollte das System direkt das Shopsystem, ERP, CRM oder eine andere API abfragen.

Kosten: meist niedrig bis moderat
Geschwindigkeit: vorhersehbar
Risiko: Berechtigungen, fehlerhafte Parameter und API-Ausfälle
Typischer Fehler bei Überdimensionierung: Das LLM darf selbst herausfinden, wie es eine Datenbank durchsucht, obwohl ein klar definierter API-Endpunkt existiert.

In vielen Fällen reicht ein LLM als Übersetzer:

1. Nutzer stellt eine freie Frage.
2. LLM erkennt die Absicht und extrahiert Parameter.
3. Backend ruft die API mit validierten Parametern auf.
4. LLM formuliert das Ergebnis verständlich.

Das ist noch kein Agent. Und das ist völlig in Ordnung.

Stufe 4: MCP oder ein standardisierter Connector

Das Model Context Protocol, kurz MCP, kann man sich als standardisierten Anschluss zwischen KI-Anwendungen und externen Werkzeugen vorstellen.

Über eine gemeinsame Schnittstelle können Anwendungen auf folgende Ressourcen zugreifen:

• APIs,
• Datenbanken,
• Dateien,
• Suchsysteme,
• Kalender,
• Services,
• Entwicklungswerkzeuge.

Der Vorteil: Tools müssen nicht für jede einzelne KI-Anwendung völlig neu integriert werden.

MCP ist jedoch kein Gehirn und kein Agent. Es stellt Verbindungen und Tool-Beschreibungen bereit. Es entscheidet nicht selbst, welches Ziel verfolgt wird, welche Priorität gilt oder wann eine Aktion ausgeführt werden soll.

Kosten: zusätzlicher Infrastruktur- und Sicherheitsaufwand
Nutzen: hoch, wenn mehrere KI-Anwendungen dieselben Tools standardisiert nutzen sollen
Typischer Fehler bei Überdimensionierung: MCP wird eingesetzt, obwohl eine einzige direkte API-Integration genügt.

Stufe 5: Ein KI-Agent

Ein Agent wird dann interessant, wenn eine Aufgabe nicht vollständig vorab als feste Abfolge definiert werden kann.

Ein Agent kann innerhalb eines begrenzten Aktionsraums:

• ein Ziel in mehrere Schritte zerlegen,
• zwischen verschiedenen Vorgehensweisen wählen,
• mehrere Tools koordinieren,
• Ergebnisse aus Zwischenschritten bewerten,
• auf Ausnahmen reagieren,
• Rückfragen stellen,
• Freigaben einholen,
• an einen Menschen übergeben.

Der entscheidende Punkt ist nicht, dass ein Agent Tools verwenden kann. Auch ein gewöhnlicher Workflow kann Tools aufrufen. Agentisch wird ein System vor allem dort, wo die Reihenfolge und Auswahl der Schritte dynamisch von den Ergebnissen abhängen.

Die menschliche Analogie: Gehirn, Bücher, Anschlüsse und Hände

Abbildung: Im Support wird aus einer Anfrage oft erst durch Wissenssuche, Prüfungen und Übergaben ein robuster Prozess.

Eine einfache Analogie hilft, die Begriffe auseinanderzuhalten:

• LLM = Gehirn: Es versteht Sprache, erkennt Muster und erzeugt Inhalte. Es kennt aber nicht automatisch aktuelle Daten und kann ohne angeschlossene Systeme nichts in der Außenwelt verändern.
• RAG = Gehirn plus Bücher: Das Modell bekommt relevante Dokumente zur Hilfe. Technisch werden Texte in Abschnitte, sogenannte Chunks, zerlegt. Embeddings bilden deren Bedeutung als Zahlenvektoren ab. Eine Vektorsuche findet ähnliche Inhalte. Metadatenfilter können beispielsweise nur Dokumente einer bestimmten Abteilung oder Version berücksichtigen. Ein Reranker sortiert Treffer anschließend genauer. Idealerweise zeigt die Antwort Quellen an.
• MCP = standardisierter Anschluss: MCP verbindet eine KI-Anwendung mit Daten und Werkzeugen. Es sorgt für eine gemeinsame Sprache zwischen Anwendung und Tool.
• KI-Agent = Gehirn plus Hände: Der Agent kann Informationen abrufen und Aktionen ausführen. Er verfolgt ein Ziel und entscheidet, welche Schritte als Nächstes notwendig sind.

Aber auch ein Agent wird nicht durch Magie intelligent. Ohne gute Daten, klare Tool-Verträge, passende Berechtigungen, Sicherheitsregeln und saubere Fehlerbehandlung ist er nur ein Sprachmodell mit zu vielen Möglichkeiten.

Beispiele aus dem Alltag

Aufgabe	Sinnvoller Startpunkt	Wann ein Agent später helfen könnte
E-Mail zusammenfassen	LLM	Wenn anschließend unterschiedliche Folgeaktionen nötig sind
Frage aus stabiler Dokumentation	LLM + RAG	Wenn Konten geprüft, Tickets aktualisiert und Freigaben eingeholt werden müssen
Lieferstatus nennen	Direkter API-Aufruf	Wenn mehrere Systeme abgefragt und Ausnahmen behandelt werden müssen
CRM-Kontakt finden	Strukturierte Suche oder API, LLM zur Interpretation	Wenn mehrere Suchstrategien kombiniert werden müssen
Rechnungsdaten extrahieren	Document AI/LLM plus Schema und Validierung	Wenn Rechnungen geprüft, Rückfragen gestellt und Buchungen vorbereitet werden
Social-Media-Post erstellen	LLM plus Guidelines und Freigabe	Wenn Briefings bewertet, Kanäle ausgewählt und Veröffentlichungen koordiniert werden
Wetter oder Aktienkurs	API oder Websuche	Wenn Daten aus mehreren Quellen verglichen und Aktionen ausgelöst werden
Standard-Onboarding	Fester Workflow oder Automation	Wenn jeder Mitarbeiter einen individuell dynamischen Prozess durchläuft

Gerade beim Onboarding zeigt sich ein häufiger Denkfehler: Wenn zwölf Schritte immer in derselben Reihenfolge stattfinden, braucht es keinen Agenten. Ein Workflow ist hier günstiger, schneller und leichter zu testen.

Wann ein Agent tatsächlich Sinn ergibt

Ein Agent kann sinnvoll sein, wenn mehrere dieser Kriterien zutreffen:

1. Es gibt mehrere valide Wege zum Ziel.
2. Die Reihenfolge der Schritte hängt von Zwischenergebnissen ab.
3. Mehrere Systeme und Tools müssen koordiniert werden.
4. Unvorhersehbare Ausnahmen treten regelmäßig auf.
5. Das System muss Zwischenentscheidungen treffen.
6. Eine begrenzte eigenständige Planung ist erforderlich.
7. Rückfragen, Freigaben oder Handoffs gehören zum Prozess.
8. Der Ablauf ist wiederholbar, aber nicht vollständig deterministisch.

Ein Supportsystem verdeutlicht den Unterschied:

Eine Frage wie „Wie ändere ich meine Lieferadresse?“ benötigt wahrscheinlich nur LLM plus RAG.

Ein komplexerer Vorgang könnte dagegen so aussehen:

1. Konto identifizieren,
2. Bestellstatus prüfen,
3. passende Richtlinie abrufen,
4. Erstattungsbedingungen bewerten,
5. Ticket aktualisieren,
6. Freigabe anfordern,
7. Kunden informieren,
8. später nachfassen.

Hier kann agentische Orchestrierung sinnvoll werden. Trotzdem muss ein völlig freier Agent nicht die beste Lösung sein. Häufig ist ein fester Support-Workflow mit einzelnen LLM-Schritten robuster: Das Modell klassifiziert die Anfrage, der Workflow ruft definierte APIs auf und nur bei komplizierten Ausnahmen wird ein begrenzter Agent aktiviert.

Abbildung: Für den technischen Deep-Dive ist vor allem das saubere Zusammenspiel von Wissen, Tools, Regeln und Monitoring entscheidend.

Workflow plus LLM: Der unterschätzte Mittelweg

Kriterium	Deterministischer Workflow	Agent
Steuerung	Feste Regeln und Übergänge	Modell entscheidet innerhalb von Grenzen
Reihenfolge	Vorab definiert	Dynamisch
Ausnahmen	Explizite Bedingungen	Modell bewertet Situation
Tool-Aufrufe	Vorhersehbar	Dynamische Toolwahl
Nachvollziehbarkeit	Sehr hoch	Aufwendiger
Kosten	Stabiler	Schwankender und meist höher
Geschwindigkeit	Schnell	Abhängig von Schleifen und Tools
Testbarkeit	Einfacher	Komplexer
Sicherheitsrisiko	Begrenzter	Höher durch Handlungsspielraum
Geeignete Aufgaben	Standardprozesse	Dynamische, mehrstufige Prozesse

Workflow plus LLM ist oft die beste Architektur. Die Prozesslogik bleibt fest, während das LLM dort eingesetzt wird, wo Sprache, Klassifikation oder unstrukturierte Daten notwendig sind.

Der Agent sollte nur den Teil übernehmen, der wirklich dynamische Entscheidungen erfordert.

Technischer Deep Dive: Die robuste KI-Anwendung

Eine produktive KI-Anwendung besteht aus deutlich mehr als einem Prompt:

• Modell/LLM: übernimmt Sprachverarbeitung und Schlussfolgerungen.
• Systemprompt und Rollenlogik: definieren Aufgabe, Stil und Grenzen.
• Kontextbudget: verhindert, dass zu viele irrelevante Informationen in das Kontextfenster gelangen.
• RAG-Schicht: verarbeitet Chunking, Embeddings, Vektorsuche, Metadatenfilter, Reranking und Quellen.
• API- und Tool-Schicht: kapselt externe Systeme mit klaren Parametern und Rückgabewerten.
• MCP: kann diese Tool-Schicht standardisieren.
• Strukturierte Ausgaben: JSON Schema sorgt dafür, dass das Modell ein erwartetes Format liefert.
• Validierung und Typprüfung: verhindern, dass ungeprüfte Modellwerte ins Backend gelangen.
• State und Memory: kurzfristiger Zustand gehört zur laufenden Aufgabe; langfristiges Gedächtnis muss versioniert, löschbar und zugriffskontrolliert sein.
• Workflow-Orchestrator: steuert feste Abläufe, Wiederholungen und Übergänge.
• Agent Loop: folgt typischerweise dem Muster Plan → Tool-Aufruf → Beobachtung → nächster Schritt.
• Guardrails und Policy Engine: prüfen Aktionen gegen Regeln und Berechtigungen.
• Human-in-the-Loop: Menschen geben riskante Aktionen frei oder übernehmen Fälle.
• Tracing und Monitoring: protokollieren Prompts, Tool-Aufrufe, Zustandsänderungen, Kosten und Fehler.
• Retries, Timeouts und Idempotenz: sorgen dafür, dass Ausfälle nicht zu doppelten Buchungen oder Endlosschleifen führen.
• Rollback: macht Änderungen rückgängig, wenn ein späterer Schritt scheitert.

Ein robuster Ablauf könnte so aussehen:

1. Anfrage klassifizieren.
2. Prüfen, ob statisches Wissen, Live-Daten oder eine Aktion benötigt wird.
3. Bei Dokumentwissen Retrieval ausführen.
4. Bei Live-Daten die autorisierte API aufrufen.
5. Nur bei mehreren abhängigen Entscheidungen in einen begrenzten Agentenmodus wechseln.
6. Schreibende oder riskante Aktionen validieren und gegebenenfalls freigeben lassen.
7. Ergebnis, Tool-Aufrufe und Entscheidungen protokollieren.
8. Dem Nutzer transparent mitteilen, was erledigt wurde und was nicht.

Wer sich für zustandsbehaftete Agenten-Workflows interessiert, findet im LangGraph-Deep-Dive von Nerdoase weitere technische Details. Einen praxisnahen Vergleich von Plattformen wie Google AI Studio, Copilot Studio und n8n gibt es außerdem im Artikel Google AI Studio vs. Copilot Studio vs. n8n.

Kosten und Performance: Agenten rechnen sich nicht automatisch

Eine Zusammenfassung kann mit einem einzigen Modellaufruf erledigt werden. Ein Agent könnte dagegen:

1. einen Plan erzeugen,
2. eine Recherche durchführen,
3. drei Tools aufrufen,
4. Zwischenergebnisse bewerten,
5. eine Antwort formulieren,
6. die Antwort selbstkritisch prüfen,
7. einen Korrekturlauf starten.

Jeder zusätzliche Schritt kann Kosten und Latenz erzeugen. Dazu kommen größere Kontextfenster, Toolbeschreibungen, Retrieval, Reranking, Speicher, Monitoring und mögliche Fehlversuche.

Die entscheidende Kennzahl ist deshalb nicht nur:

„Wie viel kostet ein Token?“

Sondern:

„Was kostet ein erfolgreich erledigter Vorgang inklusive Fehlversuchen und menschlicher Nacharbeit?“

Ein etwas teurerer Workflow kann günstiger sein, wenn er zuverlässig arbeitet. Ein scheinbar günstiger Agent wird teuer, wenn er regelmäßig falsche Tools verwendet oder Menschen seine Ergebnisse korrigieren müssen.

Sicherheit: Je mehr Handlungsspielraum, desto mehr Governance

Ein System, das nur Text zusammenfasst, hat ein anderes Risikoprofil als ein Agent, der E-Mails versendet, Geld bewegt oder Kundendaten verändert.

Wichtige Schutzmaßnahmen sind:

• Least-Privilege-Berechtigungen,
• klare Trennung von Lese- und Schreibzugriffen,
• Tool-Allowlists,
• maximale Aktionsgrenzen,
• Freigaben für Geld, Löschung, Veröffentlichung und Kundenkontakt,
• Schutz vor Prompt Injection in Dokumenten, Webseiten und E-Mails,
• Audit-Trails für jeden Tool-Aufruf,
• keine API-Keys oder Geheimnisse im Modellkontext,
• Sandboxen für riskante Ausführung,
• Rate Limits, Timeouts und maximale Schrittzahl,
• Not-Aus und jederzeitige menschliche Übernahme,
• definierte Datenschutz- und Aufbewahrungsfristen.

Besonders wichtig: Dokumente und Webseiten können Anweisungen enthalten, die nicht für das Modell bestimmt sind. Ein Agent darf solchen Inhalten nicht automatisch höhere Priorität geben als seinen Systemregeln.

Häufige Missverständnisse

• RAG macht KI nicht automatisch aktuell. Die Quelle muss synchronisiert werden.
• RAG ersetzt keine Live-API. Kontostände, Bestellstatus und Lagerbestände gehören in autoritative Systeme.
• MCP ist kein Gehirn. Es verbindet Anwendungen mit Tools.
• Mehr Tools machen Agenten nicht automatisch besser. Eine zu große Auswahl erhöht Auswahlfehler und Kontextkosten.
• Memory ist nicht automatisch korrekt. Erinnerungen müssen kontrollierbar, löschbar und versioniert sein.
• Ein langer Prompt ist keine Architektur. Sicherheit, Validierung, Berechtigungen und Monitoring gehören in eigene Systemschichten.

Entscheidungs-Checkliste

Bevor du einen Agenten baust, beantworte diese Fragen:

1. Muss das System nur verstehen, formulieren oder klassifizieren?
2. Braucht es Unternehmenswissen aus Dokumenten?
3. Werden aktuelle Daten benötigt?
4. Gibt es bereits eine API oder einen festen Workflow?
5. Muss das System mehrere Schritte dynamisch planen?
6. Wie viele Tools braucht es wirklich?
7. Welche Aktionen sind lesend, welche schreibend?
8. Welche Aktionen benötigen eine Freigabe?
9. Wie wird ein Fehler erkannt und zurückgerollt?
10. Wie messen wir Qualität, Kosten und Erfolgsquote?
11. Was passiert, wenn das Modell nicht antwortet?
12. Kann ein Mensch jederzeit übernehmen?

Der Entscheidungsbaum in Kurzform:

• Nur Sprache oder Transformation? → LLM.
• Dokumentwissen? → LLM plus RAG.
• Live-Daten oder feste Aktion? → API oder Workflow.
• Mehrere Systeme, aber feste Reihenfolge? → orchestrierter Workflow.
• Dynamische Planung, Toolwahl und Ausnahmen? → begrenzter Agent.
• Hohes Risiko? → Agent nur mit Freigaben, Guardrails und Handoff.

Migrationsstrategie: Klein anfangen, gezielt erweitern

Eine gute KI-Architektur entsteht selten in einem großen Sprung:

1. Use Case und Erfolgskriterium definieren.
2. Manuelle Baseline messen.
3. Mit einem einfachen LLM-Prototyp starten.
4. RAG oder API nur bei nachgewiesenem Bedarf ergänzen.
5. Wiederholbare Schritte als festen Workflow abbilden.
6. Nur den dynamischen Teil agentisch gestalten.
7. Toolrechte minimieren.
8. Tracing und Evals von Anfang an einplanen.
9. Mit einem begrenzten Pilot starten.
10. Fehlerfälle und menschliche Übergaben testen.
11. Erst danach skalieren.

Ein Supportsystem in drei Ausbaustufen

A) FAQ-Assistent

LLM plus RAG, Quellenanzeige und keine Schreibrechte. Das System beantwortet Fragen aus der Dokumentation.

Komplexität: niedrig
Kosten: niedrig bis moderat
Risiko: begrenzt

B) Support-Workflow

Das LLM klassifiziert die Anfrage. Direkte APIs lesen Kundendaten aus, ein Ticket wird nach festen Regeln angelegt und bei bestimmten Fällen an einen Menschen eskaliert.

Komplexität: mittel
Kosten: moderat
Risiko: kontrollierbar durch feste Regeln und Freigaben

C) Begrenzter Support-Agent

Der Agent darf innerhalb einer Allowlist selbst entscheiden, ob er Dokumentation durchsucht, einen Kontostatus liest, ein Ticket aktualisiert oder eine Freigabe anfordert.

Er darf jedoch keine Rückerstattung auslösen, kein Konto löschen und keine endgültige Zusage machen, ohne dass ein Mensch zustimmt.

Komplexität: hoch
Kosten: höher
Risiko: deutlich höher, deshalb sind Guardrails, Tracing und Handoffs Pflicht

Fazit: Die kleinste funktionierende Architektur gewinnt

Die beste KI-Lösung ist nicht die autonomste. Sie ist die kleinste Architektur, die den Job zuverlässig erledigt.

Für viele Aufgaben reichen ein LLM, RAG, eine API oder eine klassische Automation. Diese Lösungen sind häufig einfacher, günstiger, schneller und besser kontrollierbar.

Agenten sind stark, wenn echte Dynamik, Toolkoordination, Zwischenentscheidungen und Ausnahmebehandlung erforderlich sind. Aber ein Agent sollte nicht der Startpunkt eines Projekts sein, sondern das Ergebnis einer sauberen Analyse.

Also: Nicht zuerst den Agenten bauen.

Erst klären, was das System wissen, worauf es zugreifen und was es tun muss. Dann entsteht vielleicht ein Agent. Vielleicht aber auch einfach ein sehr guter Prompt – und das ist manchmal die deutlich bessere Lösung.