KI-Agent erstellen: ehrliche Plattform-Vergleiche, Architektur-Patterns und wann Sie keinen brauchen

„KI-Agent“ ist das überstrapazierteste Wort der Tech-Branche im Jahr 2026. Jede SaaS-Firma hat plötzlich „Agent-Funktionalität“. Jeder Vortrag auf jeder Konferenz erwähnt „autonomous agents“. Die meisten dieser Agenten sind in Wirklichkeit dünn verkleidete Workflow-Engines mit einem GPT-4-Aufruf irgendwo dazwischen. Das ist nicht falsch — aber es ist nicht das, was die Werbe-Versprechen suggerieren.

Diese Notiz ist eine ehrliche Anleitung für Geschäftsführungen und Operations-Verantwortliche, die im Mittelstand 2026 KI-Agenten einsetzen wollen. Was ein Agent wirklich ist, welche Plattformen sich tatsächlich unterscheiden, wie eine produktionstaugliche Architektur aussieht — und in welchen Fällen Sie besser keinen Agenten bauen, sondern einen klassischen Workflow nehmen.

Was ein KI-Agent wirklich ist

Aus der akademischen Definition: Ein Agent ist ein autonomes System, das (1) seine Umgebung wahrnimmt, (2) Entscheidungen trifft und (3) Aktionen ausführt, um Ziele zu erreichen. Im Kontext von LLMs heißt „Agent“ konkret: ein System, in dem ein Sprachmodell selbst entscheidet, welche Werkzeuge (Tools) in welcher Reihenfolge verwendet werden, um eine Aufgabe zu lösen.

Der entscheidende Unterschied zu einem Workflow:

Wer das versteht, sieht sofort: ein Agent ist nicht „besser“ als ein Workflow. Er ist anders. Und er ist die richtige Wahl nur dann, wenn Sie tatsächlich nicht im Voraus wissen, welche Schritte gebraucht werden — sondern das vom LLM herausgefunden werden muss.

Die Wahrheit: 80 % der Anwendungsfälle, die heute als „Agent“ verkauft werden, wären als Workflow stabiler, billiger und besser zu betreiben.

Drei Patterns, die Sie unterscheiden müssen

Bevor Sie ein Tool wählen, müssen Sie wissen, welches der drei Patterns Sie eigentlich brauchen.

Pattern 1: Workflow mit LLM-Step

Das ist die einfachste und stabilste Form. Ihr klassischer Workflow läuft, an einer (oder wenigen) Stellen wird ein LLM aufgerufen — typisch zur Klassifikation, Zusammenfassung oder Textgenerierung.

01 · Start

Email an support@

02 · KI

Klassifizieren

GPT-4o-mini

03 · Entscheidung

Kategorie?

04 · System

Ticket im Helpdesk

Standard

05 · Task

Eskalation Service-Lead

Eilig

06 · Ende

Antwort raus

Wann passend: wenn Sie wissen, welche Schritte nötig sind, und das LLM nur eine spezifische Teilaufgabe übernimmt. Klassischer Use-Case: Ticket-Klassifikation, Email-Zusammenfassung, Daten-Extraktion aus PDFs.

Tools: n8n, Make, Power Automate — alle haben mittlerweile saubere LLM-Integrationen. Kein „Agent-Framework“ nötig.

Kosten: ein LLM-Call kostet 0.0001-0.01 €. Bei 10.000 Tickets im Monat: 1-100 € LLM-Kosten. Vernachlässigbar.

Pattern 2: Agent mit Tools

Hier wird das LLM zum eigentlichen Orchestrator. Es bekommt eine Aufgabe und eine Liste von Tools (z. B. „Datenbank abfragen“, „Email senden“, „Termin buchen“). Es entscheidet selbst, in welcher Reihenfolge welches Tool genutzt wird.

01 · Start

User-Anfrage

02 · KI

Agent-Reasoning

Claude / GPT-4

03 · Entscheidung

Welches Tool?

04 · System

Tool 1 ausführen

DB-Query

05 · KI

Reasoning erneut

Output prüfen

06 · Entscheidung

Genug Info?

07 · System

Tool 2 ausführen

Nein

08 · KI

Antwort generieren

Ja

09 · Ende

Antwort an User

Wann passend: wenn die Schritte tatsächlich nicht im Voraus klar sind. Klassischer Use-Case: konversationelle Recherche („beantworte mir eine Frage zu unserer Produktlinie“), wo der Agent selbst entscheiden muss, welche Datenbanken/Quellen er konsultiert.

Tools: OpenAI Assistants API, Claude Tools (Anthropic), LangGraph, CrewAI, Microsoft Semantic Kernel. n8n und Make haben rudimentäre Agent-Knoten, sind aber für komplexe Reasoning-Schleifen nicht gemacht.

Kosten: ein Agent-Run kostet 0.05-2.00 € — typisch 5-15 LLM-Calls pro Run. Bei 1.000 Runs/Monat: 50-2.000 €. Beachtbar.

Pattern 3: Multi-Agent-System

Mehrere Agenten arbeiten zusammen, jeder mit eigener Rolle und eigenen Tools. Ein „Manager-Agent“ delegiert an Sub-Agenten, die ihre Teilaufgaben erfüllen und Ergebnisse zurückreporten.

01 · Start

Komplexe Anfrage

02 · KI

Manager: Aufgaben planen

Claude Opus

03 · KI

Worker 1: Web-Recherche

GPT-4 + Tools

04 · KI

Worker 2: DB-Analyse

GPT-4 + SQL

05 · KI

Worker 3: Summary

Claude Sonnet

06 · KI

Manager: synthese

Claude Opus

07 · Ende

Konsolidierte Antwort

Wann passend: wirklich komplexe Recherche- oder Analyse-Aufgaben, bei denen unterschiedliche Spezialisten-Agenten parallel arbeiten. Im B2B-Mittelstand selten. Selbst dann meist erstmal mit Pattern 2 versuchen.

Tools: LangGraph, CrewAI, AutoGen (Microsoft), Anthropic Multi-Agent-Patterns.

Kosten: 1-10 € pro Run. Schnell teuer.

Plattform-Vergleich: was unterscheidet sich wirklich

Die Marketing-Versprechen aller Plattformen klingen gleich. Im realen Betrieb sehen die Unterschiede so aus:

n8n und Make für Pattern 1

Wenn Sie ein punktuelles LLM in einem ansonsten klassischen Workflow brauchen, nehmen Sie n8n oder Make. n8n hat einen „AI Agent“-Knoten, der intern Pattern 2 (mit Tools) macht — gut genug für 80 % der Anwendungsfälle. Make's „OpenAI“-Module sind etwas einfacher gestrickt, aber für Pattern 1 ausreichend.

Vorteil: Sie haben einen visuellen Workflow, Sie können Logs sehen, Sie können die Schritte einzeln testen. Wenn der Agent halluziniert, sehen Sie genau wo.

Detaillierter Tool-Vergleich in unserer n8n-Alternative-Notiz.

OpenAI Assistants und Claude Tools für Pattern 2

Wenn Sie wirklich einen Agent brauchen — also dynamisches Tool-Calling über mehrere Schritte — sind die nativen Plattformen der LLM-Anbieter erste Wahl. Sie haben:

• OpenAI Assistants API: gutes Threading, eingebautes Code Interpreter, File-Search. Teuer bei Skalierung.
• Claude Tools (Anthropic): bessere Reasoning-Qualität (subjektiv aus unserer Praxis), Tool-Use-Modell ist sauber dokumentiert, weniger „Magie“ als OpenAI Assistants — was für Production-Setups ein Vorteil ist.

Beide haben das DSGVO-Problem: Daten landen auf US-Servern. Anthropic hat seit 2025 EU-Hosting für Enterprise-Kunden. OpenAI bietet Azure-Hosting via Microsoft an, was bei strengen DSBs akzeptabel ist.

LangGraph für komplexe Production-Setups

Wenn Pattern 2 nicht reicht und Sie echte Multi-Step-Reasoning-Schleifen brauchen, ist LangGraph (von LangChain) der derzeitige Standard. Code-First, viel Flexibilität, gut produktionstauglich. Aber: hohe Lernkurve. Sie brauchen ein Engineering-Team, das Python beherrscht und versteht, wie LLM-State-Machines funktionieren.

Wir verwenden LangGraph in Engagements, wenn der Use-Case komplex genug ist — das ist im Mittelstand vielleicht in jedem 5. Engagement der Fall.

Custom Code: wenn Sie eigentlich nichts anderes wollen

Manchmal ist die beste Plattform gar keine Plattform. Wenn Sie ein klares Pattern haben, ein gutes Engineering-Team und keine Lust auf Framework-Lock-in, ist „direkt gegen die Anthropic/OpenAI-API entwickeln“ die robusteste Lösung. Drei Funktionen, eine Loop, fertig.

Die meisten Production-Agents, die wir betreut haben, sind 200-800 Zeilen TypeScript oder Python. Kein Framework. Maximale Kontrolle.

Ein konkretes Beispiel: KI-Agent für Vertriebs-Recherche

Stellen wir uns vor, Sie wollen einen Agent bauen, der bei eingehenden Lead-Anfragen automatisch Recherche betreibt: Wer ist die Firma? Welche Größe? Welche Branche? Gibt es Hinweise auf Buying-Signal? — und das Ganze als Briefing für den Vertrieb in 60 Sekunden.

Schritt 1: Pattern entscheiden

Wir wissen die Schritte im Voraus: (1) LinkedIn-Suche, (2) Firmenwebseite scannen, (3) Crunchbase/Northdata abfragen, (4) zusammenfassen. Das ist Pattern 1 — Workflow mit LLM-Steps. Kein Agent nötig.

Schritt 2: Architektur

01 · Start

Form-Submit Website

02 · System

Firma & E-Mail extrahieren

n8n

03 · System

LinkedIn-Suche via API

Apify Actor

04 · System

Firmen-Daten ziehen

Northdata API

05 · KI

Briefing zusammenfassen

Claude Sonnet

06 · System

In CRM als Notiz

HubSpot

07 · Ende

Slack ans Sales-Team

Das ist ein robustes, debugbares System. Wenn ein Schritt fehlschlägt, sieht man genau welcher. LLM-Halluzination ist auf den letzten Schritt begrenzt — wenn die Zusammenfassung schlecht ist, sind die Quelldaten da, um sie zu prüfen.

Schritt 3: was passiert, wenn man es als Agent baut

Würden Sie dasselbe als Pattern-2-Agent bauen, sähe es so aus:

01 · Start

Form-Submit

02 · KI

Agent: 'recherchiere Firma X'

GPT-4

03 · KI

Agent ruft LinkedIn-Tool

Maybe...

04 · Entscheidung

Tool gibt Fehler?

05 · KI

Agent versucht andere Strategie

Ja

06 · KI

Agent verwirrt sich

Halluzination

07 · Ende

Gemischte Qualität

Lehre: nur weil etwas „Agent“ heißen kann, muss es kein Agent sein. Wenn die Schritte klar sind, modellieren Sie sie als Workflow.

Wann ein echter Agent (Pattern 2) Sinn ergibt

Aus Engagement-Praxis: Pattern 2 lohnt sich in genau drei Anwendungsklassen:

Klasse A — Konversationelle Recherche. Ein User stellt eine Frage, deren Beantwortung mehrere unterschiedliche Datenquellen erfordern könnte. Klassisch: ein „Sales Engineer Bot“, der Kundenfragen zur Produktlinie beantwortet, indem er aus PIM, FAQ, technischer Doku und CRM zusammenführt. Hier kann ein Agent dynamisch entscheiden, welche Quellen relevant sind.

Klasse B — Schwach strukturierte Daten-Extraktion. Sie bekommen Dokumente in 50 verschiedenen Formaten und wollen daraus standardisierte Felder extrahieren. Klassisch: Eingangsrechnungen, bei denen Layout, Sprache und Begriffe stark variieren. Ein Agent kann besser als ein starrer Workflow „herausfinden“, welcher Wert das Lieferdatum ist.

Klasse C — Dynamische Code-Generierung. Der Agent soll selbst SQL oder Python schreiben, ausführen, Fehler debuggen. Klassisch: ein Data-Analyst-Bot, der Ad-hoc-Analysen aus einer Datenbank macht.

Außerhalb dieser drei Klassen ist Pattern 2 fast immer Übertechnologie. Wenn Sie sich in einer dieser drei wiederfinden, lohnt es sich, in LangGraph oder Claude Tools zu investieren.

Drei Failure Modes, die wir immer wieder sehen

Failure Mode 1: Endlose Schleifen. Der Agent soll eine Aufgabe in 5 Schritten erledigen. Stattdessen ruft er sich 47 Mal auf, jeden Schritt mit „lass mich noch eine Quelle prüfen“. Pro Run kostet das 5 € statt 0.30 €. Lösung: hartes Schritt-Limit, Cost-Budget pro Request, ggf. Step-Recovery-Logik.

Failure Mode 2: Tool-Halluzination. Der Agent „glaubt“, er hat ein Tool aufgerufen und das Ergebnis bekommen — hat es aber nicht. Er gibt eine plausibel klingende Antwort, die aber komplett erfunden ist. Tritt häufig bei GPT-3.5 und alten Modellen auf, deutlich seltener bei GPT-4 und Claude Sonnet/Opus. Lösung: aktuelle Modelle nutzen, jeden Tool-Call validieren, Antworten gegen Quellen prüfen.

Failure Mode 3: Drift im Produktivbetrieb. Der Agent läuft 6 Wochen perfekt. Dann ändert OpenAI sein Modell-Update, oder eine Datenquelle ändert ihr Format, und plötzlich scheitert jeder fünfte Run. Niemand merkt es eine Woche lang, weil keine Alerts eingerichtet sind. Lösung: Monitoring von Erfolgsraten, automatische Tests gegen ein Set von Referenz-Eingaben, regelmäßige Re-Validation.

Echte Kosten: was kostet ein produktiver KI-Agent?

Vereinfacht für 1.000 Agent-Runs/Monat in einem Mittelstand-Setup:

Pattern 1 ist um eine Größenordnung billiger. Wer „KI-Agent“ baut, wo „LLM-Workflow“ reicht, zahlt 10× zu viel — bei schlechterer Qualität.

Hinzu kommt: die laufenden Kosten skalieren mit Volumen. Bei 100.000 Runs/Monat liegt Pattern 2 schnell im 5-stelligen Eurobereich. Pattern 1 bleibt im niedrigen 3-stelligen Bereich.

Latenz: warum „Agent“ für Echtzeit oft nicht passt

Ein Pattern-2-Agent mit 10 internen LLM-Calls braucht zwischen 30 und 120 Sekunden. Das ist akzeptabel für asynchrone Aufgaben (Recherche, die nachts läuft). Es ist inakzeptabel für synchrone User-Interaktion (Chatbot, der eine Antwort braucht).

Wenn Sie Echtzeit-Agenten brauchen, gibt es zwei Hebel:

1. Streamen der Ausgabe — auch wenn die ganze Antwort 60s braucht, sieht der User die ersten Tokens nach 2s. Reduziert die wahrgenommene Latenz.
2. Hybrid-Modell — schnelle Antwort von einem kleinen Modell (Haiku, GPT-4o-mini), parallel langsamere Vertiefung von einem großen Modell, die ggf. die erste Antwort erweitert.

Beide Patterns sind technisch anspruchsvoll. Für den Mittelstand meist nicht im ersten Wurf.

Wo Sie KEINEN Agent bauen sollten

Eine Liste von Anwendungsfällen, bei denen wir in Engagements regelmäßig „nehmt etwas anderes“ empfehlen:

Berechnungen. Ein LLM ist eine schlechte Rechenmaschine. Wenn Sie zuverlässig multiplizieren oder Summen bilden müssen, schreiben Sie Code. Verwenden Sie das LLM, um den Code zu generieren — aber rechnen Sie nicht im LLM.

Geschäftsprozess-Workflow mit Genehmigungen. Wenn der Prozess heißt „Antrag → Vorgesetzte prüft → Approver entscheidet → Buchhaltung erfasst“, ist das BPMN, kein Agent. Verwenden Sie Camunda oder eine andere Workflow-Engine. Mehr dazu in unserer BPMN-Best-Practices-Notiz.

Datenextraktion mit klarem Format. Wenn alle Eingangsrechnungen vom selben Anbieter kommen und immer dasselbe Layout haben, ist ein klassischer Parser robuster, schneller und billiger.

Kritische Entscheidungen mit hoher Verantwortung. Wenn ein Agent autonom Geld überweisen, Kündigungen aussprechen oder medizinische Empfehlungen geben soll — bauen Sie es nicht. Egal wie gut das Modell ist, das Restrisiko ist zu hoch. Halten Sie einen Menschen im Loop.

„Wir haben gerade Budget übrig und wollen was mit KI machen." Das ist die häufigste Motivation. Es ist keine. Bauen Sie keinen Agent ohne klaren Use-Case.

Schritt-für-Schritt: ihren ersten produktiven KI-Agent

Wenn Sie nach all den Warnungen immer noch sicher sind, dass Sie einen Agent (Pattern 2) brauchen, hier das pragmatische Vorgehen aus Engagements:

Phase 1 — Klarheit (Woche 1)

• Use-Case auf eine Zeile reduzieren: „User stellt Frage X, Agent antwortet aus Quellen Y und Z innerhalb 60s.“
• Erfolgs-Metrik definieren: Antwortqualität (1-5), Latenz, Erfolgsrate ohne Eskalation
• Worst-Case-Schaden definieren: was passiert, wenn der Agent halluziniert?
• Rollback-Plan: was tun, wenn der Agent in Production schlecht performt?

Phase 2 — Prototyp (Woche 2-3)

• 1-2 Tools definieren (z. B. „search_kb“, „get_customer“)
• Mit Anthropic Claude Sonnet oder OpenAI GPT-4o starten — gute Qualität, vertretbarer Preis
• Code direkt gegen die API, kein Framework, ~100 Zeilen
• Mit 20-30 Test-Eingaben testen, manuell bewerten

Phase 3 — Härtung (Woche 4-6)

• Logging einrichten (Langfuse, LangSmith oder eigene DB)
• Failure-Cases sammeln und automatisch evaluieren
• Cost- und Step-Limits einbauen
• Feedback-Loop für User („war die Antwort hilfreich?“)

Phase 4 — Production (Woche 7-8)

• Schrittweiser Rollout (10 % der Anfragen, dann 50 %, dann 100 %)
• Monitoring von Erfolgsraten und Kosten in Echtzeit
• Eskalations-Pfad definiert (was passiert, wenn der Agent scheitert?)
• Quartalsweise Re-Validation gegen Test-Set

Dieses Vorgehen klingt aufwendig — ist es auch. Wer das nicht ernst nimmt, baut hübsche Prototypen, die im Production sterben. Wer es ernst nimmt, hat Agenten, die im Hintergrund stabil laufen und tatsächlich Wert liefern.

Die Disziplin dahinter: Operating Architecture und KI

Hier wird es ehrlich. Ein einzelner KI-Agent in Ihrer Organisation ist ein Werkzeug. Drei sind ein Trend. Zwanzig sind ein Architekturproblem.

In der Praxis sehen wir bei Mittelständlern genau diesen Verlauf: erst ein Pilot, dann zwei, dann fünf, dann zwanzig. Und niemand hat einen Überblick, welche Agenten existieren, welche Daten sie nutzen, welche Tools sie aufrufen, wo sie hängen, wer sie pflegt.

Operating Architecture ist die Disziplin, die diese Frage beantwortet. Sie ordnet:

• Welche Agents existieren in welcher Domäne (Sales, Service, Operations, HR)
• Welche Daten verarbeiten sie (Datenschutz-Mapping)
• Welche Tools rufen sie auf (Abhängigkeits-Tracking)
• Wer ist Eigentümer (namentlich, mit Mandat)
• Wie messen wir ihren Erfolg (KPIs pro Agent)
• Wann ersetzt ein Agent einen menschlichen Schritt — und wann nicht

Diese Fragen werden im Mittelstand 2026 zur Architektur-Disziplin. Wer sie nicht stellt, hat in 18 Monaten einen Wildwuchs aus 30 KI-Agenten, von denen die Hälfte tot ist und die andere Hälfte sich gegenseitig stört.

Mehr zu dieser Disziplin in unserer Standortbestimmung.

Fazit

KI-Agenten sind 2026 ein wichtiges Werkzeug — wenn sie richtig eingesetzt werden. Die ehrlichste Empfehlung:

• Beginnen Sie mit Pattern 1 (Workflow + LLM-Step). 80 % der Anwendungsfälle erfüllen das.
• Wählen Sie n8n oder Make als Plattform für Pattern 1. Stabil, billig, debugbar.
• Springen Sie zu Pattern 2 nur, wenn die Schritte wirklich nicht im Voraus klar sind.
• Verwenden Sie Claude Tools oder OpenAI Assistants für Pattern 2 als ersten Wurf. LangGraph wenn es komplex wird.
• Multi-Agent (Pattern 3) ist im Mittelstand selten nötig — versuchen Sie immer Pattern 2 zuerst.
• Setzen Sie Cost- und Step-Limits, sonst werden Agents teuer und unzuverlässig.
• Bauen Sie keinen Agent ohne klaren Use-Case — das ist der Hauptgrund, warum 80 % der KI-Agent-Projekte versanden.

Und vor allem: stellen Sie sicher, dass Ihre KI-Initiative in eine Architektur eingebettet ist. Ein einzelner Agent ist ein Spielzeug. Eine geordnete Operating Architecture ist eine strategische Fähigkeit.

Wenn Sie unsicher sind, ob in Ihrer Organisation der erste KI-Agent oder der dreißigste das richtige Thema ist: 30 Min Erstgespräch, kostenlos, in dem wir das ehrlich einordnen — Termin vereinbaren.

Wir bauen KI-Agenten. Wir verkaufen sie aber nur, wenn sie wirklich der richtige Weg sind. In den meisten Engagements sagen wir „nehmt einen Workflow“ — was ehrlicher ist als die meisten Stimmen im Markt.