Agent, Chatbot oder Workflow? Wo sich ein KI-Agent im Mittelstand lohnt, wo er scheitert, welche Guardrails Sie brauchen und ein 6-wöchiger Pilot mit Kostenschätzung.
6-wöchiger Agent-Pilot
Ein abgeschlossener, über API erreichbarer Prozess. Ein Eval-Set mit 30–50 echten Beispielen und einem numerischen Erfolgskriterium.
Dieselbe Aufgabe als deterministischer Workflow (n8n). Das ist der Vergleichsmaßstab, nicht die manuelle Arbeit.
Tool use, Schritt- und Kostenlimit, menschliche Freigabe für unwiderrufliche Aktionen.
Task Success Rate, Kosten pro Aufgabe, Eingriffsquote. Go: ≥85 % Erfolg und günstiger als der Workflow.
2026 ist „KI-Agent" der am häufigsten missverstandene Begriff in mittelständischen Ausschreibungen. Drei verschiedene Dinge werden so genannt: der Chatbot, der antwortet; der Workflow, der zufällig einen LLM-Schritt enthält; und der eigentliche Agent, der selbst entscheidet, welches Werkzeug er aufruft und wann er anhält. Zwischen den dreien liegt eine Größenordnung an Kosten, Risiko und daran, was sich damit erreichen lässt.
Dieser Artikel handelt von der dritten Kategorie, zieht dabei aber eine klare Grenze zu den anderen beiden. Die Frage ist nicht, „ob wir einen Agenten brauchen", sondern bei welchem Prozess sich der Mehraufwand und das Risiko einer offenen Entscheidungsfindung lohnen und bei welchem ein deterministischer Workflow mit einem einzigen LLM-Aufruf die bessere Wahl ist.
Was wir hier beschreiben, stammt aus unseren eigenen Projekten und aus der Erfahrung unseres Partnernetzwerks: Agenten für Kundenservice, Back-Office und Datenerhebung, die produktiv laufen, sowie solche, die wir nach dem Pilot abgeschaltet haben, weil ein Workflow günstiger und zuverlässiger war. Die Zahlen sind Größenordnungen, keine Benchmark-Ergebnisse; der auf Ihrem eigenen Eval-Set gemessene Wert ist der einzige, der zählt.
Am Ende des Artikels finden Sie einen 6-wöchigen Pilotplan und eine Kostenschätzung, mit denen Sie die Go/No-Go-Entscheidung für Ihren eigenen Prozess treffen können. Wenn Sie die allgemeinen Fragen der KI-Einführung interessieren (Reifegrad, Use Cases, ROI), haben wir diese im Artikel KI-Implementierung im ungarischen Mittelstand 2026 beschrieben; dieser Beitrag setzt dort an, wo jener aufgehört hat.
Die drei Konzepte sind keine Stufen voneinander, sondern jeweils eine andere Architektur. Die Wahl richtet sich nicht danach, „wie modern" etwas ist, sondern danach, „wie viele Entscheidungen wir dem Modell überlassen".
| Aspekt | Chatbot | Workflow + LLM-Schritt | Agent |
|---|---|---|---|
| Wer entscheidet den nächsten Schritt? | Es gibt keinen nächsten Schritt | Der Entwickler, im Voraus | Das Modell, zur Laufzeit |
| Tool use | Keins oder 1 festes | In fester Reihenfolge | Modell wählt, wiederholt |
| Anzahl der Schritte | 1 | Fest (z. B. 4) | Variabel (2–30) |
| Deterministisch? | Teilweise | Ja, die Struktur | Nein |
| Typische Kosten pro Aufgabe | 1–5 HUF | 5–30 HUF | 30–500 HUF |
| Fehlerbehandlung | Fragt erneut | Retry / Fallback-Zweig | Selbstkorrektur, aber Fehler summieren sich |
Eine Eingabe, eine Ausgabe. Auch der RAG-Chatbot gehört hierher: Er sucht, dann antwortet er, setzt aber nichts in der Welt in Gang. Sein Risiko ist gering, weil er nicht handelt.
Den Graphen des Prozesses zeichnet der Entwickler: Ein Formular geht ein → das LLM kategorisiert → Eintrag ins CRM → E-Mail-Entwurf. Das LLM ist ein oder zwei Knoten im Graphen, der Rest ist deterministisch. n8n, Zapier und Make unterstützen alle dieses Modell, und 2026 sehen etwa 70–80 % der mittelständischen KI-Projekte so aus. Auch die Fallstudie zum Lead-Assistenten ist ein Workflow, kein Agent.
Das Modell erhält ein Ziel und eine Werkzeugsammlung und entscheidet dann in einer Schleife: welches Werkzeug es aufruft, was es mit dem Ergebnis anfängt, ob die Aufgabe abgeschlossen ist. Die Schleife läuft, bis das Modell „fertig" meldet oder das Schrittlimit erreicht. Der Wert liegt darin, dass man nicht jeden Zweig im Voraus zeichnen muss; das Risiko liegt darin, dass das Modell auch den falschen Zweig wählen kann.
Hinweis: Wenn sich die Schritte des Prozesses im Voraus auflisten lassen, bauen Sie einen Workflow. Ein Agent ist gerechtfertigt, wenn Reihenfolge oder Anzahl der Schritte von der Eingabe abhängen und es sich nicht lohnt, das vorab auszucodieren.
Der technische Kern eines Agenten ist Tool use (Function Calling): Das Modell schreibt keinen Text, sondern gibt einen strukturierten Aufruf zurück, den Ihr Code ausführt und dessen Ergebnis er dem Modell zurückgibt. Das ist die Schleife.
# Vereinfachte Agent-Schleife (Anthropic Messages API, Python)
tools = [
{
"name": "get_order",
"description": "Bestellung anhand der Bestellnummer aus dem ERP abrufen.",
"input_schema": {
"type": "object",
"properties": {"order_id": {"type": "string"}},
"required": ["order_id"],
},
},
{
"name": "create_credit_note",
"description": "Gutschrift erstellen. UNWIDERRUFLICH — nur nach Freigabe.",
"input_schema": {
"type": "object",
"properties": {
"order_id": {"type": "string"},
"amount_huf": {"type": "integer"},
"reason": {"type": "string"},
},
"required": ["order_id", "amount_huf", "reason"],
},
},
]
messages = [{"role": "user", "content": ticket_text}]
for step in range(MAX_STEPS): # Schrittlimit: Guardrail #1
response = client.messages.create(
model=MODEL, max_tokens=1024, system=SYSTEM_PROMPT,
tools=tools, messages=messages,
)
if response.stop_reason != "tool_use":
break # das Modell ist fertig
for block in response.content:
if block.type == "tool_use":
result = dispatch(block.name, block.input) # Ihr Code, mit eigener Validierung
messages.append({"role": "assistant", "content": response.content})
messages.append({"role": "user", "content": [
{"type": "tool_result", "tool_use_id": block.id, "content": result}
]})
Die Funktion dispatch gehört Ihnen. Hier wird alles entschieden: Hier validieren Sie, hier fordern Sie eine menschliche Freigabe an, hier protokollieren Sie. Das Modell schlägt nur einen Aufruf vor; ob Sie ihn ausführen, ist Ihre Entscheidung.
Das Model Context Protocol (MCP) löst das Problem, dass man die Anbindung an CRM, ERP oder Dateisystem nicht für jeden Agenten neu schreiben muss. Ein MCP-Server beschreibt die Werkzeuge einmal (Name, Beschreibung, Schema), und jeder MCP-fähige Client kann sie nutzen. 2026 unterstützen die Clients der großen Modellanbieter und die verbreiteten Agent-Frameworks es allesamt.
Der praktische Nutzen von MCP im Mittelstand: Wenn Sie bereits einen internen MCP-Server für Bestellungen haben, nutzt der nächste Agent (oder der eigene Assistent eines Entwicklers) denselben — keine erneute Integration. Der Nachteil: Ein MCP-Server ist genauso eine Angriffsfläche wie jede REST-API, und die Zugriffssteuerung müssen Sie selbst lösen.
Drei Bereiche, in denen 2026 produktiv laufende Agenten messbare Einsparungen bringen. Allen dreien gemein sind dieselben Bedingungen: Die Werkzeuge sind über API erreichbar, das Ende der Aufgabe ist eindeutig erkennbar, und ein fehlerhafter Schritt ist entweder umkehrbar oder an eine Freigabe gebunden.
Der klassische Chatbot antwortet; der Agent löst das Ticket. „Wo ist meine Bestellung?" → Er ruft die Bestellung ab, holt den Status aus der API des Versanddienstleisters, verfasst die Antwort, und wenn das Paket seit 3 Tagen feststeckt, legt er einen Entschädigungsvorschlag zur Freigabe vor.
Typisches Ergebnis: 35–50 % der Tickets schließen ohne menschliches Zutun, bei den übrigen erhält die Sachbearbeitung eine fertige Zusammenfassung und einen Antwortvorschlag. Unsere Fallstudie zum E-Commerce-KI-Chatbot ist die erste Phase davon; die Agent-Schicht ist die zweite.
Voraussetzung: Bestell-, Versand- und Rechnungsdaten sind über API erreichbar. Liegen sie in Excel, kommt zuerst die Integration, dann der Agent.
Beispiel: Eine Lieferantenrechnung geht ein, der Agent sucht die zugehörige Bestellung, gleicht die Positionen ab, verfasst bei Abweichung eine E-Mail an den Lieferanten und leitet sie bei Übereinstimmung an die Buchhaltung weiter. Die Anzahl der Schritte hängt von der Komplexität der Rechnung ab, weshalb hier ein Agent-Modell besser funktioniert als ein fester Workflow.
Typisches Ergebnis: 1–3 Stunden Zeitersparnis pro Tag und Back-Office-Mitarbeiter sowie ein Rückgang der Fehlzuordnungen um 60–80 %. Zur Dokumentenverarbeitungsschicht erscheint ein eigener Artikel; die Grundlagen haben wir bei unserer KI-Automatisierungs-Leistung beschrieben.
Das Zusammentragen von Wettbewerberpreisen, Ausschreibungen und Lieferanten-Datenblättern in eine strukturierte Form. Der Agent browst, extrahiert, prüft, schreibt in eine Tabelle. Der Wert liegt nicht in der einzelnen Abfrage, sondern darin, dass aus 4–6 Stunden manueller Erhebung pro Woche 20 Minuten Überprüfung werden.
Voraussetzung: Ein Mensch prüft das Ergebnis vor der Nutzung. Ein Datenerhebungs-Agent kann Fehler machen, aber der Fehler ist günstig, solange er nicht direkt in eine Entscheidung einfließt.
Die Fehlschläge in unseren Piloten lassen sich auf vier Ursachen zurückführen. Das sind keine Fehler des Modells, sondern eine schlechte Paarung von Aufgabe und Agent-Modell.
„Entscheide, ob wir diesem Kunden einen Rabatt geben." Dafür gibt es kein Eval-Set, keine eindeutig richtige Antwort, und das Modell wird selbstbewusst falsch entscheiden. Ein Agent ist gut in der Ausführung, nicht im geschäftlichen Ermessen. Die Entscheidung trifft der Mensch, der Agent erledigt die 8 Schritte danach.
Ist das Werkzeug eine Website, die man „anklicken muss", oder eine Excel-Datei, die per E-Mail verschickt wird, wird der Agent langsam, teuer und fragil. Ein Browser-Agent von 2026 braucht 20–40 Schritte, um ein Formular auszufüllen, das ein API-Aufruf in einem Schritt erledigt. Zuerst die Integration, dann der Agent.
Ist ein einzelner Schritt zu 95 % korrekt, wird ein Agent-Lauf mit 10 Schritten nur zu 60 % vollständig korrekt sein (0,95¹⁰ ≈ 0,60). Deshalb muss jeder Schritt überprüfbar sein, und ein fehlerhafter Schritt darf den nächsten nicht verderben. Die im Artikel Abwehr von LLM-Halluzinationen beschriebenen Eval-Methoden sind hier Schritt für Schritt anzuwenden.
Ein Agent, der keine Antwort findet, neigt dazu, es immer wieder zu versuchen. Ohne Schrittlimit kann ein Ticket statt 200–400 HUF auf 5.000 HUF anwachsen, und tritt das bei täglich 300 Tickets auf, steigt die Monatsrechnung um eine Größenordnung. Das Limit ist keine Option, sondern eine Grundanforderung.
Achtung: Wenn ein Anbieter einen „autonomen Agenten" für unwiderrufliche Aktionen (Zahlung, Löschung, Vertragsabschluss) ohne menschliche Freigabe anbietet, fordern Sie das Eval-Set und die Eingriffsquote an. Fehlen diese, ist das System nicht für den produktiven Einsatz bereit.
Ein Guardrail ist keine Zeile im Prompt („sei vorsichtig"), sondern der Code und der Prozess rund um die dispatch-Schicht. Fünf Schichten, die wir in jedem produktiven Agenten von uns umsetzen:
| Schicht | Was sie schützt | Wie |
|---|---|---|
| Schritt- und Token-Limit | Kosten, Endlosschleifen | MAX_STEPS 10–25, ein aufgabenbezogenes Token-Budget |
| Werkzeug-Berechtigungen | Unbefugte Aktionen | Der Agent erhält nur die für die Aufgabe nötigen Werkzeuge; Lesen und Schreiben getrennt |
| Human-in-the-Loop | Unwiderrufliche Aktionen | Freigabewarteschlange: Zahlung, Löschung, externe Kommunikation |
| Eingabefilterung | Prompt Injection aus Ticket oder E-Mail | Wir behandeln Tool-Ergebnisse als Daten, nicht als Anweisungen; injizierte Anweisungsmuster werden gefiltert |
| Protokoll und Wiedergabe | Audit, Fehlersuche | Jeder Schritt (Prompt, Tool-Aufruf, Ergebnis, Kosten) im Trace; jeder Lauf ist wiederholbar |
// Human-in-the-Loop-Guardrail in der dispatch-Schicht (TypeScript)
const IRREVERSIBLE = new Set(['create_credit_note', 'send_email', 'delete_record']);
async function dispatch(name: string, input: unknown, ctx: RunContext) {
ctx.steps += 1;
if (ctx.steps > ctx.maxSteps) throw new AgentHalt('step-limit');
if (ctx.costHuf > ctx.budgetHuf) throw new AgentHalt('budget');
const tool = registry.get(name);
const args = tool.schema.parse(input); // Schema-Validierung, wir vertrauen dem Modell nicht
if (IRREVERSIBLE.has(name)) {
const approval = await approvals.request({ runId: ctx.runId, tool: name, args });
if (approval.status !== 'approved') return { status: 'pending-approval' };
}
const result = await tool.execute(args, ctx);
await trace.record({ runId: ctx.runId, step: ctx.steps, name, args, result });
return result;
}
In der Praxis ist die Freigabewarteschlange eine Slack-Nachricht oder ein internes Admin-Interface mit einem Button „Freigeben / Ablehnen". Das Ziel ist nicht, dass ein Mensch jeden Schritt prüft, sondern dass die 3–5 % unwiderruflichen Schritte nie ungeprüft durchlaufen.
Das Ziel des Piloten ist nicht „funktioniert es", sondern „lohnt es sich gegenüber einem Workflow". Deshalb ist der Vergleichsmaßstab nicht die manuelle Arbeit, sondern ein deterministischer Workflow für dieselbe Aufgabe.
| Woche | Aufgabe | Ergebnis |
|---|---|---|
| 1 | Aufgabenauswahl, Eval-Set | 30–50 echte Fälle mit erwarteter Ausgabe; Erfolgskriterium als Zahl |
| 2 | Workflow-Baseline | Ein n8n- oder codebasierter Workflow, ausgeführt auf dem Eval-Set; Success Rate + Kosten pro Aufgabe |
| 3 | Agent v1 | Werkzeuge, System-Prompt, Schrittlimit; erster Lauf auf dem Eval-Set |
| 4 | Guardrails + HITL | Freigabewarteschlange, Berechtigungen, Trace; Fehleranalyse Schritt für Schritt |
| 5 | Shadow Mode | Läuft auf Live-Eingaben, handelt aber nicht; ein Mensch vergleicht den Vorschlag mit der Realität |
| 6 | Entscheidung | Success Rate, Kosten pro Aufgabe, Eingriffsquote; Go / No-Go / zurück zum Workflow |
Liefert der Workflow 90 % und der Agent 88 % zum dreifachen Preis, lautet die Antwort: der Workflow. Das ist kein Fehlschlag, sondern das wertvollste Ergebnis des Piloten: Es zeigte sich in 6 Wochen, nicht in 6 Monaten.
Es gibt zwei Kosten: den Aufbau und den Betrieb. Bei beiden zählt die Größenordnung, nicht die exakte Zahl; die Daten Ihres eigenen Prozesses setzen diese außer Kraft.
| Posten | Größenordnung (netto HUF) | Anmerkung |
|---|---|---|
| 6-wöchiger Pilot (der obige Plan) | 1,2–2,5 Mio. | Enthält auch die Workflow-Baseline |
| Produktiv-Rollout nach dem Piloten | 1,5–4 Mio. | Die Anzahl der Integrationen entscheidet |
| Integration für eine fehlende API | 0,3–1 Mio. / System | Wenn ERP/CRM keine API bietet |
| Freigabe-Interface | 0,3–0,8 Mio. | Slack-basiert günstiger, ein Admin-UI teurer |
Beispiel: Kundenservice-Agent, 200 Tickets pro Tag
LLM-Kosten pro Ticket (Größenordnung 2026 Q3, mittleres Modell):
im Schnitt 6 Schritte × ~4.000 Token = ~24.000 Token → 40–120 HUF pro Ticket
200 Tickets × 22 Tage × 80 HUF = ~350.000 HUF / Monat
Infrastruktur (Trace, Queue, Hosting): 30–60.000 HUF / Monat
Aufsicht, Prompt- und Eval-Wartung: 100–200.000 HUF / Monat
Gesamt: ~500–600.000 HUF / Monat
Einsparung:
200 Tickets × 40 % Auto-Schließung × 6 Min. = 480 Min. = 8 Stunden / Tag
8 Stunden × 22 Tage × 6.000 HUF (belasteter Stundensatz) = ~1.050.000 HUF / Monat
Netto: ~450–550.000 HUF / Monat; der Rollout von 3 Mio. HUF amortisiert sich in 6–7 Monaten.
Die Rechnung ist empfindlich gegenüber zwei Faktoren: der Auto-Schließungsquote und der Schrittzahl. Liegt die Auto-Schließung bei 25 %, streckt sich die Amortisation auf ein Jahr; steigt die Schrittzahl ohne Limit auf 15, verdoppeln sich die LLM-Kosten. Deshalb misst der Pilot beides, bevor jemand über einen Rollout entscheidet.
Tipp: Messen Sie die Agent-Kosten stets auf Aufgabenebene (HUF pro geschlossenem Ticket), nicht auf Token-Ebene. Der Token-Preis sinkt jährlich, die Schrittzahl hängt jedoch von Ihrem Prompt und Ihren Guardrails ab; Letzteres können Sie beeinflussen.
Dann, wenn die Anzahl oder Reihenfolge der Prozessschritte von der Eingabe abhängt, die Werkzeuge über API erreichbar sind und ein fehlerhafter Schritt umkehrbar oder an eine Freigabe koppelbar ist. Lassen sich die Schritte im Voraus auflisten, ist ein deterministischer Workflow günstiger und zuverlässiger.
Ein gut aufgebauter Pilot liefert in 6 Wochen eine zahlenmäßige Antwort: Success Rate auf dem Eval-Set, Kosten pro Aufgabe und Eingriffsquote während der Shadow-Woche. Für die Entscheidung braucht es diese drei Zahlen, nicht die Demo.
Ja, sofern der Agent nur die für die Aufgabe nötigen Werkzeuge erhält, Lesen und Schreiben getrennte Berechtigungen sind, unwiderrufliche Aktionen an eine menschliche Freigabe gebunden sind und jeder Schritt protokolliert wird. Ohne Berechtigungsbeschränkung und Freigabewarteschlange raten wir davon ab.
Ein Kundenservice-Agent, der täglich 200 Tickets bearbeitet, liegt in der Größenordnung von 2026 bei 500–600 Tausend HUF pro Monat (LLM-Kosten, Infrastruktur und Aufsicht zusammen) und amortisiert sich in 6–7 Monaten, wenn 40 % der Tickets ohne menschliches Zutun schließen. Ihre eigene Zahl hängt von der im Piloten gemessenen Auto-Schließungsquote und Schrittzahl ab.
Der KI-Agent ist 2026 weder Hype noch Wundermittel: Er ist eine Architektur, die bei bestimmten Prozessen günstiger und flexibler ist als ein fester Workflow und bei anderen teurer und fragiler. Den Unterschied entscheidet nicht die Technologie, sondern die Natur der Aufgabe: über API erreichbare Werkzeuge, ein abgeschlossenes Ziel, umkehrbare oder freigebbare Schritte.
Die Fehlschläge kommen fast immer aus derselben Ecke: Eine offene geschäftliche Entscheidung wird dem Modell überlassen, eine fehlende API soll mit einem Agenten überbrückt werden, oder es fehlt ein Schritt- und Kostenlimit. All das zeigt sich in den ersten beiden Wochen des Piloten, sofern das Eval-Set und die Workflow-Baseline vorhanden sind.
Die praktische Reihenfolge: Wählen Sie einen Prozess, bauen Sie ihn als Workflow, messen Sie ihn und probieren Sie ihn dann als Agent auf demselben Eval-Set. Ist der Agent besser oder günstiger, gibt es etwas einzuführen. Wenn nicht, haben Sie sich in 6 Wochen ein halbjähriges Projekt gespart.
Verwandte Artikel: KI-Implementierung im ungarischen Mittelstand 2026, Abwehr von LLM-Halluzinationen, n8n vs Zapier vs Make.
Wenn Sie einen Prozess haben, bei dem Sie zwischen Workflow und Agent entscheiden möchten, buchen Sie einen 30-minütigen Call: Wir gehen die Werkzeuge, die Daten und die Risiken durch und sagen Ihnen, in welche Richtung es sich zu gehen lohnt. Ist es ein Agent, ist der obige 6-wöchige Pilot der Ausgangspunkt.
Über den Autor
Corevanix Kft.
Technologiepartner
Technologiepartner aus Budapest — SAP/ERP-Integration, Webentwicklung, KI-Automatisierung und Mobile-App-Entwicklung. Wir arbeiten in der eigenen Umgebung des Kunden, und der ausgelieferte Code gehört vollständig dem Kunden.
Rechtsgrundlage, Auftragsverarbeitungsvertrag mit dem KI-Anbieter, EU-Datenresidenz, Pseudonymisierung, Trainings-Opt-out, Interessenabwägung und AI Act.
Prompts sind Code: Repo, Versionierung, Review, Vorlagenstruktur, Few-Shot-Beispiele, Eval-Sets, Regressionstests, Injection-Schutz, Kosten und Observability.
OCR + LLM-Pipeline, JSON-Schema-Extraktion, Validierung mit Human-in-the-Loop, SAP/ERP-Integration und ROI: So automatisieren Sie Rechnungen und Verträge.