KI-Agenten (AI Agents): Was sie können und wie Sie sie einsetzen

Ein Chatbot antwortet auf Fragen. Ein KI-Agent erledigt Aufgaben: er zerlegt ein Ziel in Schritte, ruft dafür Ihre Systeme auf, prüft das Ergebnis und korrigiert sich, wenn etwas schiefgeht. Das ist der Sprung, über den 2026 alle reden – und gleichzeitig der Bereich mit der höchsten Quote enttäuschter Projekte. Dieser Artikel erklärt, was Agenten technisch sind, wo sie heute tragfähig sind, was sie kosten und welche Risiken Sie vor dem Start kennen müssen.

Agent oder Chatbot: der Unterschied, der zählt

Die Abgrenzung lässt sich an drei Eigenschaften festmachen.

Eigenschaft	Klassischer Chatbot	KI-Agent
Auslöser	Nutzerfrage	Nutzerfrage, Zeitplan oder Systemereignis
Vorgehen	eine Antwort pro Eingabe	plant mehrere Schritte selbst
Werkzeuge	keine, nur Text	ruft APIs, Datenbanken, Dateien, Suche auf
Gedächtnis	der laufende Dialog	Dialog plus dauerhafter Zustand
Ergebnis	Text	Text und tatsächliche Änderungen in Systemen
Fehlerverhalten	antwortet trotzdem	kann erneut versuchen oder abbrechen

Der Kern ist die Werkzeugnutzung. Ein Sprachmodell kann nicht rechnen, nicht in Ihrer Datenbank nachsehen und keine Mail versenden. Ein Agent bekommt diese Fähigkeiten als Werkzeuge beigestellt und entscheidet selbst, welches er wann aufruft. Das Modell bleibt der Teil, der denkt – gehandelt wird von Code, den Sie kontrollieren.

Wie ein Agent arbeitet

Der Ablauf ist immer dieselbe Schleife.

• Ziel aufnehmen. Eine Aufgabe in natürlicher Sprache oder ein strukturierter Auslöser aus einem System.
• Planen. Das Modell zerlegt das Ziel in Schritte und entscheidet, welches Werkzeug der nächste Schritt braucht.
• Aufrufen. Der Agent liefert einen strukturierten Werkzeugaufruf, Ihr Code führt ihn aus und gibt das Ergebnis zurück.
• Bewerten. Das Modell liest das Ergebnis und entscheidet: Ziel erreicht, nächster Schritt, oder Korrektur.
• Abschließen. Ergebnis ausgeben, Zustand speichern, bei Bedarf einen Menschen einbeziehen.

Entscheidend ist der letzte Punkt. Produktionsreife Agenten haben definierte Haltepunkte, an denen ein Mensch bestätigt – vor jeder Buchung, jedem Versand nach außen, jeder Löschung. Dieses Muster heißt Human in the Loop und ist der Unterschied zwischen einer Demo und einem System, das man einem Kunden zeigen kann.

Die Qualität der Planungsschritte hängt dabei unmittelbar an der Formulierung der Anweisungen – die Grundlagen dazu stehen im Artikel Prompt Engineering.

MCP: der Stecker, der sich durchgesetzt hat

Bis 2024 musste jede Anbindung eines Werkzeugs an ein Modell einzeln gebaut werden – pro Modell, pro Framework, pro Tool. Das Model Context Protocol, von Anthropic Ende 2024 vorgestellt und im Dezember 2025 an die Agentic AI Foundation unter dem Dach der Linux Foundation übergeben, hat das standardisiert. Ein Werkzeug wird einmal als MCP-Server beschrieben und ist danach für jedes Modell und jedes Framework nutzbar, das das Protokoll spricht – und das tun inzwischen alle großen Anbieter.

Für Sie als Auftraggeber bedeutet das zwei Dinge. Erstens sinkt der Integrationsaufwand erheblich: für gängige Systeme – Ticketsysteme, Datenbanken, Dateiablagen, CRM – existieren fertige Anbindungen. Zweitens sinkt das Lock-in-Risiko: ein Wechsel des Modellanbieters berührt die Werkzeugebene nicht mehr.

Praxisbeispiele, die heute funktionieren

Agenten sind dort stark, wo Arbeit aus vielen kleinen, nachvollziehbaren Schritten besteht und das Ergebnis überprüfbar ist.

Recherche und Aufbereitung

Der unkomplizierteste Einstieg, weil nichts schreibend verändert wird. Ein Agent durchsucht interne Dokumente und öffentliche Quellen, fasst zusammen und belegt jede Aussage mit einer Quelle. Typisch: Wettbewerbsbeobachtung, Lieferantenprüfung, Vorbereitung von Kundengesprächen, Auswertung von Ausschreibungsunterlagen.

Dokumentenverarbeitung

Eingangsrechnungen, Lieferscheine, Verträge, Bewerbungen. Der Agent liest, extrahiert die Felder, prüft gegen Ihre Stammdaten, erkennt Abweichungen und legt nur die unklaren Fälle einem Menschen vor. Hier ist der Nutzen am leichtesten zu rechnen, weil die Bearbeitungszeit pro Dokument vorher bekannt ist.

Kundenservice der zweiten Stufe

Nicht der FAQ-Bot, sondern der Fall dahinter: Der Agent liest die Anfrage, sieht den Bestellstatus im Shop nach, prüft die Versandinformation beim Dienstleister, formuliert eine Antwort mit konkreten Daten und legt sie dem Service-Team zur Freigabe vor. Die Zeitersparnis entsteht nicht beim Formulieren, sondern beim Nachschauen.

Abläufe über Systemgrenzen

Der Übergang zur klassischen Prozessautomatisierung. Ein neuer Auftrag erzeugt ein Projekt im Projektwerkzeug, einen Ordner in der Dateiablage, einen Datensatz im Buchhaltungssystem und eine Begrüßungsmail. Für klar definierte Abläufe mit festen Regeln braucht es dafür keinen Agenten – da genügt eine Automatisierung mit n8n, und sie ist günstiger und besser vorhersehbar. Ein Agent lohnt erst, wenn die Entscheidung, was zu tun ist, von unstrukturierter Information abhängt.

Frameworks und Ansätze im Überblick

Ansatz	Passt für	Charakter
Direkte Tool-Use-API	ein bis drei Werkzeuge, klare Aufgabe	wenig Abstraktion, voller Überblick, eigener Code
LangGraph	mehrstufige Abläufe mit Zustand und Freigaben	Ablauf als Graph, Zustand in Postgres oder Redis, Wiederaufnahme nach Fehlern
n8n mit KI-Knoten	Automatisierung mit Fachabteilungs-Beteiligung	visuell, viele fertige Konnektoren, Grenzen bei komplexer Logik
Fertige Agenten-Plattformen	Standardfälle ohne eigene Entwicklung	schnell startklar, begrenzte Anpassbarkeit, Datenhaltung prüfen

Für die meisten Erstprojekte ist der direkte Weg über die Tool-Use-Schnittstelle des Modells der richtige: wenige Werkzeuge, nachvollziehbarer Code, keine zusätzliche Abstraktionsschicht, die man beim Debuggen mitverstehen muss. Ein Framework wird interessant, sobald Zustand über Tage hinweg erhalten bleiben muss, mehrere Freigabeschritte nötig sind oder ein abgebrochener Lauf an der Fehlerstelle fortsetzen soll.

Grenzen, Risiken und Kosten

Hier wird es unbequem – und das ist der wichtigste Teil dieses Artikels.

Zuverlässigkeit multipliziert sich nach unten

Ein Agent mit zehn Schritten, von denen jeder zu 97 Prozent korrekt ist, liefert in rund 74 Prozent der Fälle ein vollständig korrektes Ergebnis. Bei zwanzig Schritten sind es gut 54 Prozent. Diese Rechnung ist der Grund, warum Demos beeindrucken und Produktivbetrieb enttäuscht. Die Gegenmaßnahmen sind immer dieselben: Schritte reduzieren, Zwischenergebnisse maschinell validieren, Haltepunkte einbauen, Aufgaben schmal halten.

Kosten pro Ausführung

Ein Agent ruft das Modell nicht einmal auf, sondern pro Schritt – und jeder Aufruf trägt den gesamten bisherigen Verlauf als Kontext mit. Zehn Schritte können leicht das Zwanzigfache eines einzelnen Aufrufs kosten. Rechnen Sie vor dem Start mit realen Zahlen: Kosten pro Lauf mal erwartete Läufe pro Monat. Hebel zur Senkung sind kürzere Werkzeugantworten, ein kleineres Modell für einfache Schritte, Caching wiederkehrender Kontextteile und harte Obergrenzen für die Schrittanzahl.

Sicherheit ist der eigentliche Engpass

Ein Agent, der Werkzeuge aufruft und fremde Inhalte liest, vereint zwei Dinge, die Sicherheitsleute nervös machen. Eine vielzitierte Untersuchung von MCP-Implementierungen fand in 43 Prozent der getesteten Server Command-Injection-Lücken, in 30 Prozent Anfälligkeit für serverseitige Anfragefälschung und in 22 Prozent unkontrollierten Dateizugriff. Zwischen Januar und Februar 2026 wurden über 30 Sicherheitslücken für MCP-Server gemeldet, einige mit Bewertungen im Bereich Remote Code Execution.

Dazu kommt ein Risiko, das es vorher nicht gab: Prompt Injection über Inhalte. Wenn ein Agent eine fremde Website, eine eingehende Mail oder ein hochgeladenes PDF liest, kann dort eine Anweisung stehen, die er als Auftrag interpretiert. Die Gegenmaßnahmen sind architektonisch, nicht sprachlich:

• Werkzeugrechte so eng wie möglich – lesender Zugriff als Standard, schreibender nur wo nötig.
• Eigene Zugangsdaten mit minimalen Rechten für den Agenten, nie die eines Administrators.
• Jede Aktion nach außen – Mail, Zahlung, Veröffentlichung – hinter eine menschliche Freigabe.
• Fremde Inhalte als Daten behandeln, nicht als Anweisungen, und im Prompt klar abgrenzen.
• Vollständige Protokollierung jedes Werkzeugaufrufs, damit im Zweifel nachvollziehbar ist, was passiert ist. Zu den Grundlagen der Zugriffskontrolle siehe OAuth 2.0 und JWT.

Halluzination wird zur Handlung

Bei einem Chatbot ist eine erfundene Angabe ein falscher Satz. Bei einem Agenten kann sie ein falscher Datenbankeintrag oder eine falsche Mail an einen Kunden sein. Das verschiebt die Anforderung: Ausgaben müssen strukturiert und maschinell prüfbar sein, nicht nur plausibel lesbar.

Die Erwartungslücke

Analystenschätzungen gehen davon aus, dass mehr als die Hälfte der unternehmensweiten KI-Projekte sich verzögert oder scheitert – überwiegend nicht an der Technik, sondern an Datenqualität und daran, dass Modelle ohne Zugriff auf verlässliches Unternehmenswissen arbeiten sollen. Wer einen Agenten auf einen ungepflegten Datenbestand setzt, automatisiert ein bestehendes Problem.

Einstieg in drei Schritten

Schritt 1: Einen Fall wählen, der sich rechnet und nichts kaputt macht

Suchen Sie eine Aufgabe, die häufig anfällt, Zeit kostet, eine überprüfbare Ausgabe hat und zunächst nichts schreibend verändert. Recherche und Dokumentenauswertung erfüllen das fast immer. Kundenservice und Buchhaltung sind verlockend, aber als Erstprojekt die falsche Wahl – dort kostet jeder Fehler Vertrauen oder Geld. Eine Übersicht über Einsatzfelder mit belegbarem Nutzen gibt der Artikel KI im Mittelstand.

Schritt 2: Klein bauen, hart messen

Zwei bis drei Werkzeuge, eine klare Aufgabe, Haltepunkt vor jeder Wirkung nach außen. Legen Sie vor dem Bau fest, woran Sie Erfolg messen: Bearbeitungszeit pro Fall, Anteil der Fälle ohne menschlichen Eingriff, Fehlerquote. Ohne diese Zahlen entsteht am Ende eine Diskussion über Gefühle.

Schritt 3: Erst erweitern, wenn der kleine Fall trägt

Vier Wochen Parallelbetrieb mit echten Fällen zeigen mehr als jede Demo. Erst wenn Fehlerquote und Kosten pro Lauf stabil sind, lohnen weitere Werkzeuge, mehr Autonomie oder zusätzliche Anwendungsfälle.

Was Sie vorher klären sollten

• Wo liegt das Wissen? Ein Agent ist nur so gut wie die Daten, auf die er zugreifen darf. Ist Ihre Dokumentation aktuell und durchsuchbar?
• Wer trägt die Verantwortung für eine Entscheidung, die der Agent getroffen hat? Diese Frage braucht eine Antwort, bevor das System läuft.
• Welche Daten dürfen in welches Modell? Eine Datenschutzfrage, die vor dem Bau geklärt wird, nicht danach.
• Was passiert bei Ausfall? Wenn der Modellanbieter nicht erreichbar ist, muss der Ablauf sauber in einen manuellen Pfad fallen.
• Wer pflegt das System? Modelle, Schnittstellen und Prompts ändern sich. Ein Agent ohne Zuständigen verfällt.