Agent ist das neue Buzzword. Auf LinkedIn baut jeder dritte Beitrag einen "Agent", in Vendor-Decks heißt jede zweite Lösung "agentic". Wer wirklich einen Agent braucht, weiß meistens nicht warum — und wer denkt, er bräuchte einen, baut häufig ein massiv über-engineertes System für einen Use Case, den ein simpler Chatbot in zwei Wochen erschlagen hätte. Die folgenden Zeilen sind die nüchterne Trennung: was ist ein Agent, was ist ein Chatbot, und wann braucht man tatsächlich was.
1. Wie unterscheiden sie sich wirklich
Beide nutzen LLMs, beide sprechen mit Usern, beide können RAG nutzen. Was unterscheidet sie also? Die saubere Definition:
Chatbot ist ein System mit einem definierten Eingabe-Ausgabe-Pattern: User fragt, System antwortet. Optional darf das System auf eine Wissensquelle (RAG) zugreifen, aber innerhalb einer Anfrage gibt es einen Modell-Call und eine fertige Antwort. Beispiel: "Was kostet Produkt X?" → System sucht in Produkt-Datenbank, antwortet "€499". Fertig.
Agent ist ein System, das eigenständig entscheidet, welche Schritte für eine Aufgabe nötig sind, diese Schritte ausführt (oft durch Tool-Calls), den Zwischenstand bewertet und gegebenenfalls iteriert. Mehrere Modell-Calls pro User-Anfrage, oft 5–30 Schritte für eine komplexere Aufgabe. Beispiel: "Plane mir einen Kundentermin nächste Woche, schick die Vorbereitungsunterlagen vorab und blocke den Tag davor für Reise" → System schaut in Kalender, sucht Zeitslot, ruft CRM auf, generiert Unterlagen, sendet E-Mail, blockt Slot, bestätigt.
Der zentrale Unterschied ist nicht "wie schlau das Modell ist" — beide nutzen meistens die gleichen Foundation-Modelle. Der Unterschied ist die Kontroll-Logik: Chatbot folgt einem festen Pfad, Agent entscheidet seinen Pfad selbst.
2. Die drei Architektur-Unterschiede im Detail
Unterschied 1: Reasoning-Layer
Ein Chatbot ruft das LLM einmal auf, mit dem User-Prompt plus optional RAG-Kontext. Antwort kommt zurück, fertig.
Ein Agent hat eine zusätzliche Reasoning-Schicht, die vor und während der Ausführung entscheidet: "Welche Schritte sind nötig, um das Ziel zu erreichen?" Diese Schicht kann mit Pattern wie ReAct (Reasoning + Acting), Chain-of-Thought oder strukturiertem Plan-and-Execute implementiert sein. Frameworks wie LangGraph oder Anthropic Agent SDK liefern dafür die Bausteine.
Konsequenz: Agents haben höhere Latenz (mehrere Modell-Calls), höhere Kosten (4–10× mehr Tokens als ein vergleichbarer Chatbot), aber können komplexere Aufgaben erledigen.
Unterschied 2: Tool-Use
Chatbots können RAG (eine Form von Tool-Use: "such in der Datenbank"), aber das ist meistens ein einziger, vorgegebener Tool-Call.
Agents haben Zugriff auf eine Tool-Library und entscheiden bei jedem Schritt selbständig, welches Tool sie aufrufen. Tools können sein: Datenbank-Queries, API-Calls (CRM, ERP, Calendar, Email), Code-Ausführung, andere Agents. Das Tool-Schema (welches Tool kann was, mit welchen Parametern) ist Teil des Prompt-Setups.
MCP (Model Context Protocol), von Anthropic 2024 etabliert und 2026 De-facto-Standard, hat Tool-Integration radikal vereinfacht. Ein gut gepflegtes MCP-Setup macht den Agent in Wochen produktionsreif, was vor 2 Jahren noch Monate Glue-Code war.
Unterschied 3: Memory und State
Ein Chatbot ist typisch stateless oder hat höchstens Session-Memory (was wurde in dieser Konversation gesagt). Sobald die Session endet, ist alles weg.
Ein Agent kann persistente Memory haben: was hat der User in den letzten 30 Tagen gefragt, welche Präferenzen wurden geäußert, welche Aufgaben sind noch offen. Memory-Architektur ist 2026 ein eigenes Feld: kurzzeitig (Session-Buffer), mittelfristig (Konversations-Summary), langfristig (Vector-Store mit semantischem Recall). Wer "Agent" sagt, sollte sagen können, welche Memory-Schicht im System ist.
3. Wann braucht man wirklich einen Agent?
mehr Zeitersparnis bei agentischen Workflows als bei simplen Chatbots in B2B-Operations (McKinsey 2026)
Die McKinsey-Zahl liest sich beeindruckend, ist aber irreführend, wenn man sie ohne Kontext nimmt. 4× mehr Zeitersparnis stimmt — bei Use Cases, die wirklich für Agents geeignet sind. Bei Use Cases, die ein Chatbot erschlagen hätte, sind Agents oft teurer als der Mehrwert.
Wann Agent sinnvoll ist (klare Indikatoren):
- Multi-Step-Aufgaben, die mindestens 3–5 verschiedene Systeme oder Datenquellen berühren
- Aufgaben, bei denen die Schritte vorab nicht bekannt sind und vom Zwischenstand abhängen
- Längere Workflows mit Wartezeiten (z.B. "warte auf Kundenantwort, dann mach Schritt 2")
- Workflows mit persistent State über Tage oder Wochen
- Klar messbare Outcomes (verkaufte Stunden ersetzt, Tickets gelöst, Leads qualifiziert)
Wann Chatbot ausreicht (mindestens so häufig):
- Wissens-Abfrage (FAQ, interne Dokumentation, Produkt-Specs)
- Einzelne Daten-Lookups ("Was ist der Status meiner Bestellung?")
- Generierungs-Aufgaben in einem Schritt (Email-Entwurf, Zusammenfassung, Übersetzung)
- Strukturierte Eingabe-Erfassung ("Trag mir mal den neuen Kunden ins CRM ein")
In den 12 Production-Setups, die wir 2024–2026 begleitet haben, waren 9 Chatbots und 3 echte Agents. Das ist kein Versehen — das ist die natürliche Verteilung.
4. Welche Frameworks für 2026 — Realistische Tool-Landschaft
Drei Frameworks dominieren 2026 die ernsthafte Agent-Entwicklung:
- Anthropic Agent SDK (offizielles Anthropic-Toolkit). Sweet Spot: schnelle, robuste Agents mit Claude-Modellen, Tool-Use nativ, MCP-Integration eingebaut. Beste Wahl für Production-Setups mit Claude als Foundation-Modell.
- LangGraph (Open Source, von LangChain-Team). Sweet Spot: komplexe Multi-Agent-Workflows mit klar definiertem State-Graph, gut für ernsthaftes Multi-Step-Reasoning. Steile Lernkurve, aber mächtig. Production-tauglich seit 2025.
- AutoGen / Microsoft Agent Framework. Sweet Spot: Microsoft-Ökosystem, Multi-Agent-Patterns, gut für interne Tooling-Setups. Eher experimentell für externe Produkt-Anwendungen.
Was ihr 2026 nicht mehr braucht: Custom-Glue-Code zwischen LLM und Tools. MCP hat das gelöst. Wer 2026 noch eine eigene Tool-Abstraktionsschicht baut, baut etwas, das es schon gibt — und meistens nicht besser.
Klare Empfehlung für österreichische Mittelstand-Setups: Anthropic Agent SDK mit MCP-Tools, weil die Lernkurve flach ist, die Production-Tauglichkeit hoch und die Compliance-Lage (EU-Routing über Anthropic) sauber.
5. Die drei wichtigsten Risiken bei Agenten
Risiko 1: Halluzinations-Cascade
Wenn ein Agent in Schritt 2 halluziniert (z.B. einen falschen Kunden-Datensatz aus der DB rät), nimmt Schritt 3 diese Halluzination als Wahrheit und baut darauf auf. Schritt 5 ist dann ein Email-Entwurf an den falschen Kunden mit falschem Inhalt. Bei einem Chatbot würde der User die Halluzination sofort sehen — bei einem Agent läuft sie still durch 10 Schritte.
Gegenmaßnahmen: explizite Validierungs-Steps zwischen Schritten, deterministic Tool-Calls statt LLM-Generierung wo möglich, Human-in-the-Loop bei kritischen Pfaden (E-Mail-Versand, Zahlungen, Vertrags-Generierung).
Risiko 2: Token-Kosten-Explosion
Ein Agent kann pro User-Anfrage 20–100 Modell-Calls machen, mit jeweils dem kompletten Kontext (Tools, Memory, Historie). Wir haben Setups gesehen, die pro Anfrage 50.000 Tokens verbrauchen — bei Claude Opus sind das €0.40 pro Anfrage. Bei 5.000 Anfragen pro Tag sind das €2.000 pro Tag oder €60.000 pro Monat.
Gegenmaßnahmen: Prompt-Caching aggressiv nutzen, billigere Modelle für einfache Sub-Tasks (Haiku statt Opus), Memory komprimieren statt komplett mitschleppen, Tool-Calls bündeln.
Risiko 3: Schwierige Evaluation
Einen Chatbot evaluiert man mit "war die Antwort korrekt?". Einen Agent evaluiert man mit "war jeder Schritt korrekt, war die Reihenfolge sinnvoll, war das Endergebnis brauchbar, war der Token-Verbrauch im Rahmen?". Das ist 5× komplexer und braucht eigene Eval-Frameworks.
2026 sind Promptfoo, Braintrust und LangSmith die etablierten Eval-Tools. Wer einen Agent baut ohne Eval-Setup, baut blind — und merkt Regressions erst, wenn Kunden sich beschweren.
6. Konkrete Beispiele aus der Praxis
Beispiel 1 — Chatbot (B2B-Versicherungsmakler). RAG-Chatbot über interne Versicherungstarife und Vertragsbedingungen. 5.000 Anfragen pro Monat, durchschnittliche Antwort-Latenz unter 3 Sekunden, Token-Kosten unter €200 pro Monat. Implementation: 4 Wochen, €18k. ROI: 12 Stunden pro Woche im Innendienst gespart.
Beispiel 2 — Agent (Wiener Steuerberatung). Multi-Step-Agent für die Aufbereitung von Mandantenakten. Liest E-Mail mit Belegen → klassifiziert → matcht gegen Buchhaltungs-Schema → erstellt Buchungsvorschläge → wartet auf Steuerberater-Freigabe → bucht in DATEV. 25 Modell-Calls pro Akte, €0.85 Token-Kosten pro Akte. Implementation: 14 Wochen, €68k. ROI: 15 Stunden pro Woche pro Steuerberater gespart.
Beispiel 3 — Falsche Wahl (Anonymisiert). Industriebetrieb, 100 MA, wollte einen "Sales-Agent" für die Generierung von Angeboten. Tatsächlicher Use Case: Mitarbeiter wählt Produkte aus Katalog, Agent generiert Angebot. Hätte ein Chatbot mit Templating in 5 Wochen gelöst. Wurde stattdessen als Agent gebaut: 14 Wochen, €72k, Token-Kosten €1.800/Monat. Im Audit-Review nach 6 Monaten: hätte man als Chatbot gebaut für €25k Sprint plus €150/Monat Hosting. Das ist die Art von Geldverbrennung, die das "Agent"-Buzzword anrichtet, wenn niemand das Architektur-Reviewing macht.
Häufige Fragen
Agent oder Chatbot — was Geschäftsführer fragen.
Brauche ich ein Multi-Agent-System statt eines einzelnen Agents?
Was kostet ein Agent vs Chatbot in Implementation und Operations?
Welche Frameworks empfehlt ihr für 2026?
Wie testet man Agents systematisch?
Wie minimiere ich das Risiko einer Halluzinations-Cascade?
Was als Nächstes?
Wer 2026 vor der Frage "Agent oder Chatbot?" steht, sollte zuerst den Use Case sauber definieren — und erst dann die Architektur wählen. Im Audit M (€9.500–18.000) schauen wir uns euren konkreten Use Case an und sagen euch ehrlich, ob ein €25k-Chatbot-Sprint das Thema löst oder ob es ein €70k-Agent-Build braucht. In 70 Prozent der Audits ist die Antwort Chatbot, in 25 Prozent Agent, in 5 Prozent Multi-Agent. Wer den ersten Schritt machen will, bucht den 30-Minuten-Discovery-Call. Wir sagen euch in den 30 Minuten, in welche Schublade euer Use Case fällt — und vor allem, in welche er nicht fällt.