---
title: "Die meisten KI-Agenten sollten keine Agenten sein"
description: "In den letzten Monaten habe ich die Anzahl der Agenten in meinen Produktions-Workflows um etwa fünf reduziert. Was sie ersetzte: ein winziges Modell für das Routing, explizit definierte Schritte statt Laufzeit-Entscheidungen und ein manuell geladenes sowie gespeichertes Gesprächsgedächtnis. Hier ist das Beispiel."
date: 2025-10-29
language: de
canonical: https://gduv.club/de/articles/ai-workflows-instead-of-agents
source: gduv.club
---
Als Agenten in n8n eingeführt wurden, habe ich viele davon gebaut. Man zieht einen Agenten-Knoten hinein, hängt drei Tools an, und das System findet selbst heraus, welches aufgerufen werden muss. Es fühlte sich so an, als wäre alles plötzlich ganz einfach geworden.

In den folgenden Monaten habe ich die meisten davon wieder entfernt. In den Workflows, die skalieren und tatsächlich produktiv laufen müssen, bin ich auf etwa ein Fünftel der ursprünglichen Agenten heruntergekommen.

Nicht weil Agenten schlecht sind. Sondern weil der Agent bei den meisten meiner Aufgaben Dinge zur Laufzeit entschied, die ich bereits zum Zeitpunkt der Erstellung wusste, und mir für dieses Privileg bei jedem einzelnen Durchgang bezahlt werden musste.

[99% AI Agents Shouldn’t Exist. Do This Instead (+ reliable, faster, cheaper)!](https://www.youtube.com/watch?v=BHdJFnx2wrc)

## Das Beispiel, an dem ich mich orientiere

Ein Support-Chatbot. Chat-Trigger, ein Agent auf einem großen Modell und ein Tool: eine HTTP-Anfrage an einen Retrieval-Endpunkt, der Fragen basierend auf meinen Dokumenten beantwortet. Jemand fragt nach dem Produkt, der Agent ruft das Tool auf, liest die Antwort und schreibt die Antwort an den Nutzer.

**KI-Wissensagent**

**Wenn Chat-Nachricht empfangen** → **KI-Wissensagent** (gpt-4.1, Chat-Modell: OpenAI Chat-Modell (gpt-4.1); Gedächtnis: Einfaches Gedächtnis; Tool: Wissensdatenbank abfragen (HTTP-Request. Der Agent schreibt die Abfrage und entscheidet, wann er sie aufruft))

_Vier Knoten. Es ist extrem schnell aufgebaut, weshalb diese Struktur so weit verbreitet ist._

## Jemand sagt Hallo und es kostet Sie ein Frontier-Modell

Senden Sie ein "Hallo" an diesen Agenten. Sie erhalten in etwa 1,3 Sekunden eine freundliche Antwort, geschrieben von einem der größten verfügbaren Modelle.

Es wurde kein Tool aufgerufen. Nichts wurde abgerufen. Der gesamte System-Prompt wurde als Input-Token übermittelt, einschließlich jeder Zeile, die Tools beschreibt, die nie genutzt wurden.

| Step | What happens | Cost |
| :--- | :--- | ---: |
| Die Nachricht kommt an | "Hallo" | 1 Token |
| Der vollständige System-Prompt wird gesendet | Jede Tool-Beschreibung, jede Regel zum Aufruf | alles davon |
| Das große Modell entscheidet | Es entscheidet, nichts aufzurufen |  |
| Das große Modell antwortet | "Hallo, wie kann ich Ihnen heute helfen?" |  |

_Mein Prompt war hier noch kurz. Bei fünf angehängten Tools und einer detaillierten Aufrufreihenfolge macht die mittlere Zeile den Großteil der Rechnung aus._

Die Begrüßung ist das einfachste Beispiel, aber keineswegs ein seltenes. Bei einem Chatbot benötigt ein großer Teil der Nachrichten weder einen Abruf noch eine Suche.

## Das Gleiche, aber explizit definiert

Hier ist der Ersatz. Es sind mehr Knoten, aber jeder einzelne ist eine Entscheidung, die ich einmal getroffen habe, statt einer Entscheidung, die ein Modell bei jeder Nachricht treffen muss.

**Intelligenter und effizienter RAG-Chatbot**

**Wenn Chat-Nachricht empfangen** → **Vergangene Nachrichten finden** (Memory-Manager, Load-Modus, Memory: Einfaches Memory) → **Intent-Router** (Text-Klassifikator, zwei Kategorien, Chat-Modell: Sehr kleines Modell (gpt-4.1-nano))

- _kein Knowledge-Retrieval nötig_ → **Einfache Antwort** (Basis-LLM-Chain auf demselben winzigen Modell)

- _Knowledge-Retrieval wird benötigt_ → **Retrieval-Query vorbereiten** (Basis-LLM-Chain, gpt-4.1-mini) → **RAG via Lookio** (Einfache HTTP-Anfrage. In diesem Schritt gar kein Modell) → **Finale Antwort schreiben** (Basis-LLM-Chain, gpt-4.1. Das einzige große Modell auf dem Canvas)

**Auf Chat antworten** → **Nachrichten speichern** (Memory-Manager, Insert-Modus)

_Drei Modelle auf dem Canvas, jeweils an den entsprechenden Schritt angepasst. Das große Modell läuft auf genau einem Node und nur bei den Nachrichten, die es erreichen._

### Erst routen, mit einem Modell, das fast nichts kostet

Die einzige Aufgabe des Text-Klassifizierers ist es, zu entscheiden, welchen Pfad die Nachricht nimmt. Zwei Kategorien, jeweils mit einer Beschreibung:

- **Kein Wissensabruf nötig.** Begrüßungen, Bestätigungen, Smalltalk. Alles, was ohne externe Konsultation beantwortbar ist.
- **Wissensabruf ist nötig.** Die Nachricht benötigt Informationen aus den Dokumenten, bevor sie beantwortet werden kann.

Klassifizierung ist eine leichte Aufgabe, bei der ein kleines Modell sehr gute Arbeit leistet. Es ist schnell genug, dass der Schritt kaum in der Gesamtlatenz ins Gewicht fällt, und günstig genug, dass ich mir darüber keine Gedanken mehr mache.

Der kostengünstige Pfad ist eine einfache LLM-Chain auf demselben winzigen Modell mit einem kurzen System-Prompt. Ein "Hi" kommt nun in etwa zwei Sekunden zurück, liest sich exakt gleich, läuft aber auf einem Modell, das pro Token nur einen Bruchteil dessen kostet, was es ersetzt hat.

**Der Router benötigt den Gesprächsverlauf, sonst werden Folgefragen falsch eingeordnet**

"Und zum zweiten Punkt?" erfordert eine Suche und wirkt für sich genommen wie Smalltalk. Daher werden dem Prompt des Klassifizierers die vergangenen Nachrichten angehängt, formatiert als `human:` und `ai:` Zeilen, mit der Anweisung, sich auf die neue Nachricht zu konzentrieren und den Rest als Kontext zu behandeln. Ohne dies würden Folgefragen auf den günstigen Pfad geleitet und der Bot würde ins Leere antworten.

Ein Modell-Knoten speist sowohl den Router als auch die einfache Antwort. Es sind unterschiedliche Aufgaben, aber von gleichem Umfang. Da ich das Modell nur an einer Stelle ändern muss, probiere ich gelegentlich tatsächlich ein anderes aus, anstatt zwei Knoten zu bearbeiten und den zweiten zu vergessen.

### Trigger so einstellen, dass die Antwort von einem Knoten erfolgt

Eine Kleinigkeit, die das gesamte Design blockiert, wenn man sie übersieht. Ein Chat-Trigger antwortet standardmäßig aus dem letzten Knoten, aber dieser Workflow hat zwei Pfade, die beide eine Antwort liefern müssen.

Stellen Sie den Antwortmodus des Triggers auf "von einem Knoten antworten" und setzen Sie dann einen **Respond to Chat** Knoten dort ein, wo die Zweige zusammenlaufen. Ohne diesen gibt es keine Möglichkeit, einen günstigen und einen teuren Pfad zu haben, die beide antworten, was ja der eigentliche Sinn des Routings ist.

### Der Retrieval-Pfad als drei Knoten

Schauen wir uns an, was der Agent bei einer echten Frage getan hat. Das große Modell wurde aufgerufen, benötigte 600ms und entschied sich, das Tool aufzurufen. Eine gute Entscheidung. Aber das Ergebnis all dieser Intelligenz ist ein einziger kurzer Query-String, im Grunde eine bereinigte Version dessen, was der Nutzer gerade getippt hat. Und um diesen zu schreiben, wurde der gesamte System-Prompt erneut übertragen.

**Aufgaben im Durchgang** (Alle auf dem großen Modell)

- Entscheiden, dass Retrieval nötig ist
- Kurze Suchabfrage schreiben
- Finale Antwort aus den Ergebnissen schreiben

**Was jede Aufgabe benötigt** (Bei Wahl pro Schritt)

- Ein Klassifizierer, winziges Modell
- Ein Rewrite, kleines Modell
- Ein großes Modell, hier ist es gerechtfertigt

_Nur der letzte Schritt profitiert vom teuren Modell, in der Agent-Struktur laufen jedoch alle drei darüber._

Der Pfad besteht also aus drei Knoten statt einem Agenten.

**Prepare retrieval query** ist eine einfache LLM-Chain auf einem Mini-Modell. Ihr System-Prompt: Formuliere aus der Nutzernachricht eine kurze und prägnante Abfrage für das Knowledge-Retrieval-Tool und gib sie direkt als Frage aus. In meinen Tests schrieb das kleine Modell dieselbe Abfrage wie das große.

**RAG via Lookio** ist eine einfache HTTP-Anfrage. Die Abfrage steht im Body, die Assistant-ID und der Modus sind feste Werte, die ich gewählt habe, statt Parameter, bei denen ein Modell schwanken kann. Die meisten Tools, die man an einen Agenten bindet, sind im Kern eine API, und die Plattform liefert meist den fertigen Knoten zum Einfügen.

**Write the final response** erhält die Originalnachricht und die markierten Retrieval-Inhalte und schreibt die Antwort. Dieser Schritt bleibt auf dem großen Modell, da sich die Qualität in der Formulierung der finalen Antwort zeigt.

### Das Gedächtnis liegt nun in Ihrer Hand

Das ist der Teil, den der Agent bisher für Sie erledigt hat, und der Teil, den Sie nun selbst einbauen müssen.

Ein Agent-Knoten nimmt einen Memory-Sub-Knoten und verwaltet ihn. Wenn man den Agenten in Schritte aufteilt, passiert das nicht mehr. Daher wird die Konversation einmal oben geladen und einmal unten gespeichert.

| Step | What happens | Cost |
| :--- | :--- | ---: |
| Vergangene Nachrichten finden | Memory Manager im Load-Modus, direkt nach dem Trigger | einmalig |
| Jeder Prompt hängt sie an | Router, einfache Antwort und beide Retrieval-Schritte erhalten den Verlauf | ×4 |
| Respond to Chat | Die Antwort geht zurück an den Nutzer |  |
| Nachrichten speichern | Memory Manager im Insert-Modus: Nutzernachricht und Antwort | einmalig |

_Mehr Verkabelung als bei einem Memory-Sub-Knoten, aber derselbe Puffer darunter. Der Vorteil ist, dass Sie pro Schritt genau sehen können, wie viel Verlauf übergeben wurde._

Es ist mehr Arbeit. Es ist aber auch der Moment, in dem man bemerkt, dass ein Agent die gesamte Konversation in jeden einzelnen Durchgang gepresst hat, obwohl ein Query-Rewrite-Schritt nur die letzten zwei Nachrichten benötigt und nicht die letzten zwanzig.

## Was Sie davon haben

**Agent** (Entscheidet zur Laufzeit)

- Großes Modell bei jedem Zug, egal ob Begrüßung oder nicht
- System-Prompt und Tool-Beschreibungen bei jedem Aufruf
- Kann ein Tool überspringen und aus dem Gedächtnis antworten
- Kann die Reihenfolge ändern, was man erst in der Produktion bemerkt

**Explizite Schritte** (Entschieden zur Build-Zeit)

- Großes Modell nur in einem von fünf Knoten
- Keine Tool-Beschreibungen an einer beliebigen Stelle
- Die Suche läuft immer, da sie ein definierter Schritt ist
- Die Reihenfolge entspricht genau dem Entwurf

_Die Vorhersehbarkeit würde ich vor einem Jahr auf den letzten Platz gesetzt haben, heute auf den ersten._

Die dritte Zeile ist für mich die wichtigste. Wenn ein Agent ein Tool überspringt und aus seinem zufälligen Wissen antwortet, ist das ein Fehler, den man weder reproduzieren noch testen kann. Ein Workflow kann das nicht. Der Knoten ist da, er wird ausgeführt.

## Wann ich trotzdem zum Agenten greife

Wenn ich die Reihenfolge wirklich nicht kenne. Bei offener Recherche, wo die zweite Abfrage davon abhängt, was die erste gefunden hat. Bei allem, wo die Anzahl der Schritte im Voraus nicht feststeht.

Das ist der Test, den ich jetzt anwende: Kann ich das auf Papier zeichnen, bevor es läuft? Wenn ja, bezahle ich für einen Agenten, der meine Zeichnung bei jeder Anfrage neu entdecken muss.

## Die gleiche Frage eine Ebene höher

Diese Gewohnheit lässt sich übertragen. Wenn ich in Claude Code oder Codex arbeite, haben viele meiner Abläufe die gleiche Struktur wie dieser Support-Bot, und die teuren Teile sind dieselben: der gesamte Kontext wird erneut für einen Schritt übergeben, der nur einen Bruchteil davon benötigt, oder ein Modell entdeckt etwas neu, das ich bereits wusste.

Wenn man weiß, was ein Tool-Aufruf kostet, weil man ihn einmal manuell verkabelt und den Token-Verbrauch beobachtet hat, kann man das Geschehen auch in einem Framework erkennen, das einem fast nichts anzeigt.

Öffnen Sie Ihre eigenen Agenten und schauen Sie sich die Ausführungen an. Fragen Sie sich bei jedem einzelnen, ob Sie die Schritte vorab selbst hätten zeichnen können. Bei den meisten meiner Agenten wäre das möglich gewesen.

## Quellen

- [n8n: Text Classifier node](https://docs.n8n.io/integrations/builtin/cluster-nodes/root-nodes/n8n-nodes-langchain.text-classifier/)
- [n8n: Basic LLM Chain node](https://docs.n8n.io/integrations/builtin/cluster-nodes/root-nodes/n8n-nodes-langchain.chainllm/)
- [n8n: Chat Memory Manager node](https://docs.n8n.io/integrations/builtin/cluster-nodes/root-nodes/n8n-nodes-langchain.memorymanager/)
- [OpenAI: model pricing](https://openai.com/api/pricing/)