KI-Agenten oder klassische Automatisierung? Drei Praxisbeispiele

Was ein „KI-Agent" wirklich ist

Der Begriff „KI-Agent" wird seit 2024 inflationär verwendet. In den Pitch-Decks der großen Anbieter und der Beratungs-Branche klingt es nach Magie: ein System, das selbstständig denkt, entscheidet, handelt, ein autonomer digitaler Mitarbeiter oder „Kollega", der ganze Prozesse übernimmt.

In der Realität, in der diese Agenten tatsächlich gebaut werden, auf Plattformen wie n8n, Make oder über eigene Python-Code-Basen, sieht die Sache deutlich nüchterner aus.

Ein „KI-Agent" ist in fast allen produktiven Implementierungen ein klassischer Automatisierungs-Workflow, in dem an einer Stelle eine Wenn-Dann-Regel durch einen Aufruf an ein Sprachmodell ersetzt wurde. Mehr steckt nicht dahinter. Manchmal sind es drei oder fünf solcher Stellen, manchmal nur eine. Die Architektur darunter bleibt klassische Prozess-Automatisierung: Trigger, Datenflüsse, Schnittstellen, Verzweigungen, Datenbank-Updates.

Das ist nicht negativ gemeint. Es ist eine Beschreibung dessen, was tatsächlich passiert.

Das Problem entsteht erst, wenn die Eigenschaften dieser LLM-Aufrufe übersehen werden: Sie sind nicht deterministisch, nicht auditierbar, und ihre laufenden Kosten skalieren mit jedem einzelnen Vorgang. In einem Demo-Setting fällt das nicht auf. In einem produktiven Prozess mit Tausenden Vorgängen pro Monat entscheidet genau das darüber, ob Sie ein stabiles System haben oder eine teure Wundertüte.

In diesem Beitrag schauen wir uns drei reale Templates aus der n8n-Workflow-Bibliothek an, alle frei verfügbar, alle vielfach geteilt und kopiert. Wir vergleichen jedes mit der Lösung, die ein erfahrener Entwickler in klassischem Python in wenigen Stunden bauen könnte. Und wir markieren präzise die Stellen, an denen der „KI-Agent" Determinismus aufgibt.

Beispiel 1: E-Mail-Triage mit fünf spezialisierten OpenAI-Agenten

Reales Template: „AI-Powered Email Triage & Auto-Response System with OpenAI Agents & Gmail" (n8n Workflow #9157).

Was es macht:

1. Gmail-Trigger überwacht den Posteingang
2. Ein Text-Classifier-Agent kategorisiert jede eingehende E-Mail in eine von fünf Klassen: Internal, Customer Support, Sales, Promotions oder Admin/Finance
3. Routing-Nodes leiten die E-Mail an einen von fünf weiteren OpenAI-Agenten
4. Jeder dieser fünf Agenten entwirft eine kategoriespezifische Antwort
5. Bei Internal und Support wird die Antwort automatisch verschickt; bei Sales, Finance und Promotions geht ein Entwurf an einen Menschen zur Freigabe

Macht insgesamt sechs LLM-Aufrufe pro eingegangener E-Mail (ein Classifier plus ein passender Agent).

Was klassischer Python in 200 Zeilen leistet:

def klassifiziere_email(absender: str, betreff: str, body: str) -> str:
    domain = absender.split("@")[1].lower()

    if domain in INTERNAL_DOMAINS:
        return "Internal"
    if any(k in body.lower() for k in ["support", "ticket", "problem", "fehler"]):
        return "Support"
    if re.match(r"^(re:|aw:)?\s*(rechnung|invoice|gutschrift)", betreff, re.I):
        return "Finance"
    if absender in BEKANNTE_PROMO_VERSENDER or domain in PROMO_DOMAINS:
        return "Promotions"
    if any(k in body.lower() for k in OUR_SALES_KEYWORDS):
        return "Sales"

    return "Manuell pruefen"

Dazu pro Kategorie eine Template-Antwort, in die per .format(...)-Aufruf der Absendername und ggf. eine Referenz-Nummer eingesetzt wird. Fertig.

Eigenschaften dieser Lösung:

• 100 % nachvollziehbar: jede Fehlentscheidung lässt sich genau einer Regel zuordnen und beheben
• Kosten pro E-Mail: null
• Geschwindigkeit: Millisekunden statt Sekunden
• Testbar: Unit-Tests decken jede Klassifizierungs-Regel ab

Wo der LLM-Agent Non-Determinismus einführt, ⚠️

• Klassifizierung schwankt. Dieselbe E-Mail von einem Bestandskunden, der nach einer Garantieverlängerung fragt, kann heute als „Sales", morgen als „Support" und übermorgen als „Promotions" eingestuft werden. Bei Hunderten E-Mails pro Tag bedeutet das: ein nicht zu vernachlässigender Anteil läuft in den falschen Prozess.
• Antwort-Entwürfe sind nicht reproduzierbar. Jeder Lauf produziert einen leicht anderen Text. Konsistenter Markenton wird zur Glückssache, A/B-Tests sind nicht sauber durchführbar.
• Audit nicht möglich. Warum wurde die Reklamation eines wichtigen Kunden als „Promotion" eingestuft und automatisch mit einer Werbe-Antwort beantwortet? Die ehrliche Antwort lautet: weil das Modell es so wollte. Das ist im B2B-Geschäft kein tragfähiges Argument.
• Latente Kosten. Jeder eingehende Newsletter, jede Spam-Mail, jede automatische Antwort durchläuft sechs LLM-Aufrufe. Bei 10.000 E-Mails pro Monat sind das 60.000 Token-bezahlte Modellaufrufe.

Beispiel 2: Rechnungsverarbeitung mit „AI Agent, der Rechnungen versteht"

Reales Template: „Invoice Processor & Validator with OCR, AI & Google Sheets" (n8n Workflow #4247).

Was es macht:

1. Liest eine PDF-Rechnung aus einem überwachten Ordner (deterministisch)
2. OCR extrahiert den Rohtext aus dem PDF (deterministisch)
3. Ein LLM-Agent strukturiert den OCR-Text in ein sauberes JSON-Objekt mit Rechnungsnummer, Datum, Beträgen, Positionen
4. Die JSON-Daten werden in Google Sheets eingetragen (deterministisch)
5. Stammdaten-Abgleich (Lieferant, Artikel) markiert jede Position als „Valid" oder „Invalid" (deterministisch)

Der LLM-Schritt steht mitten in einer ansonsten vollständig deterministischen Kette. Und ist gleichzeitig der finanziell sensibelste.

Was klassischer Python in 300 Zeilen leistet:

import pdfplumber
import re

text = pdfplumber.open("rechnung.pdf").pages[0].extract_text()
template = waehle_template_fuer_lieferant(extrahiere_absender(text))

daten = {
    "rechnungsnummer": re.search(template["nr_regex"], text).group(1),
    "datum": re.search(template["datum_regex"], text).group(1),
    "betrag_netto": parse_eurobetrag(re.search(template["netto_regex"], text).group(1)),
    "ust_20": parse_eurobetrag(re.search(template["ust_regex"], text).group(1)),
    "betrag_brutto": parse_eurobetrag(re.search(template["brutto_regex"], text).group(1)),
}

assert abs(daten["betrag_netto"] + daten["ust_20"] - daten["betrag_brutto"]) < 0.01, \
    "Konsistenzpruefung fehlgeschlagen, manueller Eingriff noetig"

Pro Lieferant wird einmalig ein Template definiert. Bei den meisten Mittelstands-Unternehmen sind das 30 bis 80 Stammlieferanten. Einmal investierte Zeit, danach läuft die Verarbeitung jahrelang stabil mit null Folgekosten pro Beleg.

Das assert-Statement am Ende ist entscheidend: Eine klassische Konsistenzprüfung (Netto + USt = Brutto) fängt Extraktionsfehler sofort und nachweisbar ab. Bei einem Treffer fließt der Beleg in die manuelle Klärung. Stillschweigend in die Buchhaltung wandert nichts.

Wo der LLM-Agent Non-Determinismus einführt, ⚠️

• Erfundene Beträge. Wenn der OCR-Text Lücken hat (verschmutzte Seite, schiefer Scan), erfindet das Modell stillschweigend plausibel aussehende Zahlen. Das passiert nicht oft. Aber es passiert. Und bei Beträgen, die in der Bilanz landen, ist „nicht oft" nicht akzeptabel.
• Verwechslung Brutto/Netto/USt. Tritt regelmäßig auf, vor allem bei ungewöhnlichen Rechnungsformaten. Eine klassische Regex-Lösung weiß genau, welches Feld welches ist, das LLM rät.
• Compliance-Risiko. Wer Beträge unter Haftung verbucht (Bilanz, Vorsteueranmeldung, Forderungsmanagement), kann ein LLM nicht als „Quelle der Wahrheit" für eine Zahl in der Buchhaltung verwenden. Bei einer Betriebsprüfung lautet die Frage: „Wie ist diese Zahl in Ihr System gekommen?", „Ein Sprachmodell hat sie dort eingetragen" ist keine tragfähige Antwort.
• Kosten skalieren linear. 10.000 Rechnungen pro Jahr bedeuten 10.000 LLM-Aufrufe. Ein klassisches Template-System verarbeitet dieselbe Menge zum Stromverbrauch eines Raspberry Pi.

Beispiel 3: BANT-Lead-Qualifizierung mit GPT-4 als „intelligentem SDR"

Reales Template: „Real-Time Lead Qualification, Scoring & CRM Integration System using Jotform" (n8n Workflow #9815).

Was es macht:

1. Formular-Eingabe via Jotform (deterministisch)
2. GPT-4 bewertet den Lead nach BANT, Budget, Authority, Need, Timeline, und vergibt 0 bis 25 Punkte pro Dimension
3. GPT-4 schätzt zusätzlich das voraussichtliche Deal-Volumen, identifiziert „Red Flags" und „Competitor Vulnerabilities" und generiert „Talking Points" für das Erstgespräch
4. Routing nach Gesamtscore: Hot (≥75) → Senior-AE, Warm (50 bis 74) → mittlere Vertriebsstufe, Cold (25 bis 49) → SDR
5. Anlage im CRM, Versand der „AI-generated brief" an den zugewiesenen Vertriebler

Was klassischer Python in 50 Zeilen leistet:

DECISION_ROLES = {"CEO", "CTO", "Geschaeftsfuehrer", "Inhaber", "Gesellschafter"}
INFLUENCER_ROLES = {"Leitung", "Head of", "Bereichsleiter", "Prokurist"}
OUR_PROBLEM_KEYWORDS = {"manuell", "uneinheitlich", "fehleranfaellig", "fragmentiert"}

def bant_score(lead) -> int:
    score = 0

    # Budget
    if lead.budget_eur >= 50_000:
        score += 25
    elif lead.budget_eur >= 20_000:
        score += 15

    # Authority
    if lead.rolle in DECISION_ROLES:
        score += 25
    elif lead.rolle in INFLUENCER_ROLES:
        score += 15

    # Need (Stichwort-Match in den Pain-Point-Feldern)
    if any(kw in lead.pain_points.lower() for kw in OUR_PROBLEM_KEYWORDS):
        score += 25

    # Timeline
    if lead.timeline_monate <= 3:
        score += 25
    elif lead.timeline_monate <= 6:
        score += 15

    return score

Die Schwellen, Rollen-Listen und Schlüsselwörter werden gemeinsam mit der Vertriebsleitung in 30 bis 60 Minuten festgelegt. Dann läuft das System.

Eigenschaften:

• Derselbe Lead bekommt immer denselben Score bei denselben Eingaben
• Die Logik ist im Code dokumentiert und jederzeit reviewbar
• Anpassungen (neue Branche, neuer Markt, anderes ICP) sind eine Code-Änderung von wenigen Zeilen, versionierbar, testbar, nachvollziehbar

Wo der LLM-Agent Non-Determinismus einführt, ⚠️

• Score-Schwankungen. Derselbe Lead bekommt heute 78 (Hot, Senior-AE), morgen 64 (Warm, mittlere Ebene), übermorgen vielleicht 71. Das Routing ist nicht stabil, Sie verteilen Ihre besten Leads abhängig vom Tagesform des Modells.
• Erfundene Deal-Volumina. Die „Deal-Value-Estimation" ist eine frei erfundene Eurozahl, die aus keinem konkreten Eingabewert ableitbar ist. Wer diese Zahlen in den Vertriebs-Forecast übernimmt, baut die Pipeline auf Würfeln.
• Black-Box-Red-Flags. Niemand kann sagen, welche Signale das Modell als Red Flag wertet. „Das Modell hat einen Red Flag gesehen" ist keine handlungsfähige Information für einen Vertriebsleiter.
• Reporting-Konsequenzen. Wenn Ihr Pipeline-Forecast und Ihre Bonus-Auszahlung auf LLM-Scores basieren, basiert beides auf einer Black Box, die quartalsweise ihr Verhalten ändern kann, ohne dass irgendjemand bei Ihnen davon weiß.

Was das für CEOs konkret bedeutet

Diese drei Beispiele sind keine Ausnahmen. Sie sind repräsentativ für etwa 90 % aller „KI-Agent"-Lösungen, die aktuell als Innovation verkauft werden.

Was im Demo glänzt, kollabiert in der Produktion an drei Stellen:

1. Audit. Sobald ein Prozess Compliance-relevant wird, Rechnungen, Verträge, Personaldaten, Kundenkommunikation mit rechtlicher Verbindlichkeit, muss er auditierbar sein. „Warum hat das System so entschieden?" ist eine Frage, die ein LLM nicht beantworten kann. Klassischer Code kann es.

2. Laufende Kosten. Token-Preise wirken im Demo lächerlich klein. Bei 10.000 Vorgängen pro Monat und 6 LLM-Aufrufen pro Vorgang summiert sich das schnell zu einem mittleren vierstelligen Betrag pro Monat. Bei einem klassischen Workflow ohne LLM-Komponente: null Cent pro Vorgang.

3. Reproduzierbarkeit. Geschäftsentscheidungen, Pipeline-Forecasts, Reportings, alles braucht eine stabile Eingangsdatenlage. Ein System, das morgen andere Antworten gibt als heute, taugt als Datenquelle für unternehmerische Steuerung nichts.

Drei Fragen vor der Unterschrift unter ein KI-Agent-Angebot

Wenn aktuell ein Angebot für einen „KI-Agenten" auf Ihrem Tisch liegt, sparen Ihnen drei Fragen oft fünfstellige Beträge:

1. An welchen exakten Stellen im Workflow steht ein LLM-Aufruf? Lassen Sie sich das Architektur-Diagramm zeigen. Jeder einzelne LLM-Aufruf gehört rot markiert. Wenn der Anbieter das nicht klar abgrenzen kann, ist das ein Warnsignal.

2. Welche dieser LLM-Schritte ließen sich durch klassische Regeln oder Templates ersetzen? Ehrliche Antwort eines erfahrenen Anbieters: „Wahrscheinlich 70 bis 90 Prozent, mit einem moderaten Mehraufwand in der initialen Definition." Wenn die Antwort lautet „keiner, KI ist hier unbedingt nötig", ist die Skepsis berechtigt.

3. Wie verhält sich das System, wenn das KI-Modul ausfällt, der Anbieter die Preise verdoppelt oder die Policy ändert? Ein belastbarer Workflow muss diese drei Fälle aushalten können. Wenn die Antwort lautet „dann funktioniert das Ganze nicht mehr", ist die Architektur falsch.

Wo KI in Workflows tatsächlich Sinn ergibt

Diese Analyse ist kein generelles Plädoyer gegen den Einsatz von Sprachmodellen in Automatisierungen. Es gibt Aufgaben, in denen ein LLM genau das richtige Werkzeug ist:

• Freitext verstehen, der durch keine Regel sauber strukturierbar ist, etwa die Zusammenfassung eines Meeting-Protokolls, die Stimmungsanalyse einer Kundennachricht, die Extraktion von Themen aus einem unstrukturierten Beratungsbericht.
• Erstentwürfe generieren, die ein Mensch noch prüft, Angebotstexte, Antwortvorschläge, Konzept-Skizzen.
• Klassifizierungen mit hoher semantischer Komplexität, bei denen ein Regelwerk in keinem vertretbaren Rahmen erstellt werden könnte, und auch dort idealerweise mit einer menschlichen Stichproben-Kontrolle.

In jedem dieser Fälle ist die KI-Schicht klein, gezielt, mit deterministischen Sicherheitsnetzen davor und dahinter. Sie ist nicht der Kern des Systems. Sie ist eine spezialisierte Komponente an einer präzise definierten Stelle.

Mein Appell an Entscheider:innen

„KI-Agent" ist 2026 das, was „Cloud" um 2014 oder „Big Data" um 2018 war: ein Marketing-Begriff, der über sehr unterschiedliche technische Substanz gestülpt wird. Hinter den meisten Angeboten verbirgt sich klassische Automatisierung, mit ein paar LLM-Aufrufen an den teuersten und fragilsten Stellen.

Wer als CEO oder Geschäftsführer ein solches Projekt unterschreibt, ohne genau zu wissen, wo die Determinismus-Lücken sitzen, kauft ein System, das im Demo glänzt und im Audit kollabiert. Wer hingegen die Frage stellt „könnte das auch ohne LLM-Komponente funktionieren?", und ehrlich beantwortet bekommt, kauft am Ende meist einen schlankeren, stabileren und über die Jahre dramatisch günstigeren Prozess.

Wenn Sie ein konkretes KI-Agent-Angebot auf dem Tisch haben und vor der Unterschrift eine nüchterne Zweitmeinung wollen, ist der Digital-Realitäts-Check der schnellste Weg dorthin. Wenn Sie generell sortieren möchten, wo in Ihrem Betrieb KI sinnvoll ist und wo klassische Automatisierung der bessere Hebel wäre, liefert der KI-Einführungsworkshop die strukturierte Grundlage. Und wer die Angebote im Überblick sehen will, findet dort den nüchternen Vergleich der Pakete, inklusive Festpreis und ohne Abo-Treadmill.

Was Sie nicht von mir hören werden: dass KI-Agenten generell schlecht sind. Was Sie hören werden: Die meisten produktiven Workflows laufen besser ohne sie. Und die wenigen, in denen sie wirklich gebraucht werden, verdienen eine bewusste Architektur-Entscheidung, kein Marketing-Etikett.