Was ist ein KI-Agent? Funktionsweise, Abgrenzung und Einsatzbeispiele

Ein KI-Agent ist ein Softwaresystem, das ein Ziel entgegennimmt, mit einem gewissen Grad an Eigenständigkeit entscheidet, welche Schritte dafür nötig sind, und diese Schritte ausführt, bis das Ziel erreicht ist oder er an eine vorher gesetzte Grenze stößt. Technisch ist das meist ein Sprachmodell, das in einer Schleife Werkzeuge aufruft, deren Ergebnisse auswertet und daraus den nächsten Schritt ableitet.

Anthropic beschreibt Agenten in seinem Beitrag „Building effective agents” als Systeme, in denen das Sprachmodell seine Abläufe und seinen Werkzeuggebrauch selbst steuert, und grenzt sie von Workflows ab, in denen Modell und Werkzeuge über vorher festgelegte Pfade verbunden sind. Diese Unterscheidung zieht sich durch den ganzen Artikel: Ein Agent bekommt ein Ziel statt einer Abfolge.

Wie ein KI-Agent technisch arbeitet

Ein Agent besteht aus wenigen Bausteinen. Wer sie kennt, kann ein Angebot einordnen, gleich unter welchem Produktnamen es verkauft wird.

• Sprachmodell: Es liest Ziel, Anweisungen und bisherige Ergebnisse und entscheidet, was als Nächstes passiert: einen Werkzeugaufruf oder eine abschließende Antwort.
• Werkzeuge: Funktionen, die Ihre Anwendung dem Modell zur Verfügung stellt, etwa „Bestellung im ERP suchen” oder „Dokument ablegen”. Die Umsetzung sieht das Modell nicht, sondern nur Name, Beschreibung und Eingabeformat des Werkzeugs sowie das Ergebnis, das zurückkommt.
• Anweisungen: Ziel, Regeln und Grenzen, in n8n etwa als System Message, in den APIs als Systemanweisung.
• Gedächtnis: was der Agent während eines Laufs und darüber hinaus weiß (dazu unten mehr).
• Stopp-Punkte: Iterationsgrenzen und menschliche Freigaben.

Die Arbeitsschleife in sechs Schritten

1. Ziel entgegennehmen. Der Agent startet mit einem Auftrag, etwa aus einer E-Mail, einem Formular oder einem Chat, zusammen mit seinen Anweisungen und der Liste verfügbarer Werkzeuge.
2. Nächsten Schritt planen. Das Modell entscheidet, ob es für das Ziel noch Informationen oder eine Aktion braucht. Bei der Einstellung tool_choice: auto entscheidet Claude laut Anthropic-Dokumentation in jeder Runde selbst, ob es ein Werkzeug aufruft oder direkt antwortet.
3. Werkzeug aufrufen. Das Modell gibt einen strukturierten Aufruf zurück: welches Werkzeug, mit welchen Eingaben. Ausgeführt wird er nicht vom Modell. Anthropic formuliert es in der Dokumentation „How tool use works” ausdrücklich: Das Modell führt nie selbst etwas aus, sondern Ihr Code oder die Server des Anbieters.
4. Ergebnis beobachten. Das Ergebnis des Werkzeugs geht als neue Nachricht zurück an das Modell. Anthropic nennt das die „ground truth” aus der Umgebung, an der der Agent in jedem Schritt seinen Fortschritt messen soll.
5. Wiederholen. Solange das Modell weitere Werkzeugaufrufe zurückgibt, läuft die Schleife weiter. Bei Anthropic ist das Kriterium technisch der Wert stop_reason: "tool_use", bei OpenAI beschreibt die Dokumentation zum Function Calling denselben Kreislauf aus Anfrage, Werkzeugaufruf, Ausführung in Ihrer Anwendung und erneuter Anfrage mit dem Ergebnis.
6. Abbrechen. Die Schleife endet, wenn das Modell eine Antwort ohne weiteren Werkzeugaufruf liefert, oder wenn eine gesetzte Grenze greift: eine Höchstzahl an Runden, eine menschliche Freigabe, die abgelehnt wird, oder ein anderer Abbruchgrund, den Ihre Anwendung behandeln muss.

Die Schleife ist technisch unspektakulär. Anthropic schreibt selbst, Agenten seien meist „nur” Sprachmodelle, die Werkzeuge auf Basis von Rückmeldungen aus ihrer Umgebung in einer Schleife nutzen, und leitet daraus ab, dass die Werkzeuge und ihre Beschreibungen sorgfältig gestaltet sein müssen. Für Sie als Auftraggeber heißt das: Was ein Agent tun kann, bestimmen die Werkzeuge, die Sie ihm geben, nicht das Modell.

Gedächtnis und Kontext

„Gedächtnis” meint bei Agenten drei verschiedene Dinge, die man auseinanderhalten sollte:

• Das Kontextfenster während eines Laufs. Anthropic bezeichnet es in der Dokumentation zu Kontextfenstern als „Arbeitsgedächtnis” des Modells: alles, worauf es beim Erzeugen einer Antwort zugreifen kann. Mehr ist dabei nicht automatisch besser; laut derselben Seite lassen Genauigkeit und Erinnerungsleistung mit wachsender Tokenzahl nach.
• Der Verlauf über mehrere Anfragen. Die Messages API von Anthropic ist laut Dokumentation zustandslos: Ihre Anwendung schickt bei jeder Anfrage den vollständigen bisherigen Verlauf mit. Was der Agent aus Runde eins in Runde fünf noch weiß, liegt also in dem, was Ihre Anwendung mitsendet. In n8n übernimmt das ein Memory-Sub-Node; der Simple Memory Node speichert den Chatverlauf unter einem Session Key und berücksichtigt eine einstellbare Zahl früherer Interaktionen. Laut n8n-Dokumentation funktioniert er in einem produktiven Workflow nicht, wenn die Instanz im Queue-Modus läuft.
• Dauerhaftes Wissen. Was über eine Sitzung hinaus erhalten bleiben soll, braucht einen Speicher außerhalb des Modells: eine Datenbank, eine Ablage oder ein eigenes Werkzeug. Anthropic bietet dafür ein Memory-Werkzeug an, dessen Dateien Ihre Anwendung selbst speichert.

Die Zustandslosigkeit hat eine praktische Folge: Bei der Messages API ist jede weitere Runde der Schleife eine neue Anfrage, die den bisherigen Verlauf erneut enthält. Unabhängig davon nennt Anthropic höhere Kosten und das Risiko sich fortpflanzender Fehler ausdrücklich als Folge der Eigenständigkeit von Agenten.

Drei Herstellerdokumentationen im Abgleich

Wir haben am 28. September 2026 nachgelesen, wie Anthropic, OpenAI und n8n die Schleife in ihrer Dokumentation beschreiben: wer das Werkzeug ausführt, wann die Schleife endet und wo ein Mensch eingreifen kann. Die Tabelle gibt den Stand dieses Tages wieder; Parameter und Standardwerte können sich mit neuen Versionen ändern.

	Anthropic (Claude API)	OpenAI (Function Calling, Agents SDK)	n8n (AI Agent Node)
Wer führt das Werkzeug aus?	Eigene Werkzeuge: Ihre Anwendung. Server-Werkzeuge wie Websuche: Anthropic.	Funktionen: Ihre Anwendung. Dazu stellt die OpenAI-Plattform eingebaute Werkzeuge bereit, etwa Websuche.	n8n führt die angeschlossenen Tool-Sub-Nodes aus; mindestens ein Werkzeug ist Pflicht.
Wann endet die Schleife?	Wenn stop_reason nicht mehr "tool_use" ist, etwa bei "end_turn" oder "max_tokens".	Agents SDK: wenn das Modell eine Ausgabe ohne Werkzeugaufruf liefert, die als Endergebnis gilt.	Wenn der Agent eine Antwort liefert oder die Iterationsgrenze erreicht.
Eingebaute Obergrenze	Die serverseitige Schleife hat eine Iterationsgrenze und gibt dann "pause_turn" zurück; die Schleife für eigene Werkzeuge steuert Ihre Anwendung.	Agents SDK: max_turns, im Quellcode Standardwert 10; bei Überschreitung wird die Ausnahme MaxTurnsExceeded ausgelöst. Bei reinem Function Calling steuert Ihre Anwendung die Schleife.	Option Max Iterations, Standardwert 10.
Freigabe durch einen Menschen	Der Beitrag „Building effective agents” beschreibt, dass Agenten an Checkpoints für menschliches Feedback pausieren können; da Ihre Anwendung eigene Werkzeuge selbst ausführt, bauen Sie die Freigabe dort ein.	Werkzeuge können eine Freigabe verlangen; der Lauf pausiert, bis jemand zustimmt oder ablehnt.	Human review je Werkzeug: Der Workflow pausiert, die Anfrage geht etwa per Chat, Slack, Microsoft Teams oder E-Mail an einen Menschen.

Für die Einkaufsentscheidung folgen aus dem Abgleich zwei Punkte. Erstens: Bei allen drei führt die umgebende Software die Werkzeuge aus; das Modell fordert Aktionen nur an. Genau dort, bei Ihren eigenen Werkzeugen in Ihrer Anwendung, sitzen deshalb Berechtigungen, Protokolle und Freigaben. Zweitens: Alle drei sehen eine Obergrenze, eine Pause oder eine Freigabe vor, aber jeweils an anderer Stelle und mit anderen Standardwerten. Fragen Sie bei jedem Angebot, welche Grenze gesetzt ist und was passiert, wenn sie greift.

Ein Beispiel Schritt für Schritt: Eingangsrechnung zuordnen mit n8n

Das folgende Beispiel ist ein Bauplan, kein Projektbericht. Es zeigt, wie die sechs Schritte der Schleife in einem n8n-Workflow aussehen, mit den Bezeichnungen aus der n8n-Dokumentation (Stand 28. September 2026). Ziel: Eine Eingangsrechnung wird dem richtigen Projekt zugeordnet und abgelegt, und bei Unsicherheit entscheidet ein Mensch.

1. Auslöser und Vorarbeit ohne KI. Ein E-Mail-Trigger reagiert auf eine neue Nachricht im Rechnungspostfach und lädt die Anhänge herunter. Der Node Extract From File liest mit der Operation „Extract From PDF” den Text aus dem Anhang. Alles, was immer gleich abläuft, bleibt gewöhnlicher Workflow.
2. AI Agent Node mit Ziel und Regeln. Der Rechnungstext geht als Prompt in den AI Agent Node. In die System Message schreiben Sie Ziel und Grenzen, etwa: „Ordne die Rechnung genau einem offenen Projekt zu. Findest du keine eindeutige Zuordnung, lege nichts ab und melde ‚unklar’ mit Begründung. Das Ablegen braucht eine Freigabe; wird sie abgelehnt, melde ebenfalls ‚unklar’.” Als Sprachmodell hängt ein Chat-Model-Sub-Node am Agenten, etwa für OpenAI oder Anthropic.
3. Werkzeuge anschließen. Zwei lesende Werkzeuge, zum Beispiel HTTP-Request-Nodes als Werkzeug gegen die Schnittstelle Ihres ERP: „Offene Projekte eines Lieferanten suchen” und „Bestellung zu einer Bestellnummer abrufen”. Ein schreibendes Werkzeug, „Rechnung ablegen”, als Call-n8n-Workflow-Tool, das einen eigenen Unter-Workflow für die Ablage startet. Parameter wie Lieferantenname oder Bestellnummer kann das Modell über $fromAI() selbst füllen.
4. Freigabe vor der Wirkung. Nur das Ablage-Werkzeug hängt an einem Human-review-Schritt, etwa über Microsoft Teams. Lesen darf der Agent frei, ablegen erst nach Zustimmung.
5. Grenzen und Ausgabeformat. Max Iterations setzen Sie bewusst, zum Beispiel auf 5 statt der voreingestellten 10, weil drei Werkzeugaufrufe für diesen Vorgang reichen sollten. Mit „Require Specific Output Format” und einem Structured Output Parser liefert der Agent ein festes JSON mit den Feldern Projekt, Sicherheit und Begründung. „Return Intermediate Steps” schreibt die Einzelschritte mit in die Ausgabe, damit Sie im Nachhinein sehen, welche Werkzeuge der Agent mit welchen Eingaben aufgerufen hat.
6. Nach dem Agenten wieder fester Workflow. Ein If-Node prüft das Feld Sicherheit. Steht dort „unklar”, geht der Fall mit Begründung an die Buchhaltung.

So kann ein Durchlauf aussehen: In Runde eins ruft das Modell „Offene Projekte suchen” mit dem Lieferantennamen auf und bekommt drei Treffer. In Runde zwei ruft es „Bestellung abrufen” mit der Bestellnummer aus der Rechnung auf; die Bestellung gehört zu einem der drei Projekte. In Runde drei fordert es „Rechnung ablegen” an, der Workflow pausiert, die Freigabeanfrage geht an die Buchhaltung. Nach der Zustimmung läuft die Ablage, und das Modell liefert das JSON als Endergebnis. Fehlt die Bestellnummer und passen mehrere Projekte, soll das Modell laut System Message „unklar” melden, statt zu raten. Ob es das zuverlässig tut, zeigt erst der Test mit echten Rechnungen.

Nicht in diesem Beispiel: ein Memory-Node. Jede Rechnung wird als eigener Lauf ohne Gesprächsverlauf verarbeitet, damit frühere Rechnungen die Zuordnung der aktuellen nicht beeinflussen.

Die Abgrenzung zu Chatbot und RPA

Die drei Begriffe werden vermischt. Die folgende Gegenüberstellung zeigt die typischen Ausprägungen. Die Kategorien überlappen sich und sind keine sauberen Schubladen.

	Chatbot	RPA-Roboter	KI-Agent
Bekommt typischerweise	eine Frage	eine feste Abfolge	ein Ziel
Bestimmt den Weg	in der Antwort	nein, fest vorgegeben	ja, weitgehend selbst
Bei Abweichung	antwortet trotzdem	Ausnahme an Mensch oder Abbruch	kann einen anderen Weg wählen oder übergeben
Typischer Nutzen	Auskunft rund um die Uhr	gleichförmige Massenvorgänge	Vorgänge mit Varianten

Ein Chatbot ist in erster Linie eine Gesprächsoberfläche. Das heißt heute nicht mehr, dass er nichts bewirken kann: Chat-Assistenten können über Tool Use Werkzeuge aufrufen, auf Systeme zugreifen und Vorgänge auslösen. Der Übergang zum Agenten ist fließend. Die Frage ist weniger „kann er handeln?” als „wie viel entscheidet er selbst?”.

Ein RPA-Roboter führt aus, was ihm jemand vorher exakt beschrieben hat: dieses Feld kopieren, dort einfügen, speichern. Er ist zuverlässig, solange sich nichts ändert. UiPath nennt in seiner Dokumentation Layout-Änderungen, wechselnde Element-IDs und geänderte Beschriftungen als Gründe, an denen Selektoren brechen. Klassisches RPA wendet vorher festgelegte Regeln an; UiPath etwa ergänzt seine Plattform inzwischen um KI-Funktionen wie semantische Selektoren (Stand 28. September 2026). Auch diese Grenze verschwimmt also.

Ein KI-Agent bekommt „ordne diese Eingangsrechnung dem richtigen Projekt zu und lege sie ab”, ermittelt selbst, welche Informationen ihm fehlen, holt sie über seine Werkzeuge und entscheidet dann. Weicht ein Fall vom Normalfall ab, muss er nicht abbrechen, sondern kann einen anderen Weg probieren oder den Fall einem Menschen vorlegen, wenn Sie ihn so eingerichtet haben.

Vier Fragen, mit denen Sie ein Angebot prüfen

Die folgenden vier Fragen sind keine wissenschaftliche Definition, sondern ein Einkaufstest: Sie klären, ob ein als „Agent” angebotenes System in Ihrem Betrieb tatsächlich Arbeit abnimmt.

1. Hat er Zugriff auf Ihre Systeme? Auch ohne Anbindung kann ein System planen oder Entscheidungen vorbereiten. Wirtschaftlich halten wir die Frage trotzdem für zentral: Ohne Werkzeuge für E-Mail, Ablage, ERP oder CRM bleibt das Ergebnis ein Vorschlag, den weiterhin jemand von Hand umsetzt.
2. Plant er mehrere Schritte? Zerlegt er das Ziel selbst in Teilschritte, statt einen einzelnen Aufruf zu beantworten?
3. Prüft er sein eigenes Ergebnis? Wertet er nach einem Schritt das Ergebnis aus und korrigiert er gegebenenfalls? Nicht jede Aufgabe braucht das; bei fehleranfälligen Vorgängen macht es den Unterschied.
4. Kennt er seine Grenzen? Ein produktionstauglicher Agent hat definierte Stopp-Punkte: eine Iterationsgrenze und festgelegte Fälle, ab welchem Betrag, welcher Unsicherheit oder welcher Art von Entscheidung er an einen Menschen übergibt.

Fällt die Antwort auf Frage 1 negativ aus, kaufen Sie einen Assistenten, keine Automatisierung. Das kann richtig sein, ist aber ein anderer Nutzen und rechnet sich anders. Fällt die Antwort auf Frage 4 negativ aus, ist es ein Risiko.

Einsatzbeispiele im Mittelstand

Sinnvoll wird ein Agent überall dort, wo ein Vorgang zwar regelmäßig anfällt, aber zu viele Varianten kennt, um ihn als starres Skript abzubilden:

• Eingangspost und Rechnungen: Dokument lesen, Absender und Vorgang zuordnen, Daten ins System übernehmen, bei Unklarheit nachfragen statt raten.
• Angebotsvorbereitung: Anfrage auswerten, passende Positionen und frühere vergleichbare Angebote heraussuchen, einen Entwurf vorlegen. Die Freigabe bleibt beim Vertrieb.
• Erstqualifizierung von Anfragen: Eingehende Anfragen einordnen, fehlende Angaben erfragen, an die richtige Person weiterleiten.
• Stammdatenpflege: Abweichungen zwischen Systemen erkennen, Vorschläge zur Bereinigung machen, nach Freigabe anwenden.
• Überwachung laufender Prozesse: Erkennen, dass ein Prozess seit gestern nicht mehr läuft, die Ursache eingrenzen und einen Vorschlag zur Behebung liefern.

Das gemeinsame Muster: Der Agent nimmt die Vorarbeit ab, die Entscheidung bleibt beim Menschen. Wie ein Agent von dort aus schrittweise mehr Verantwortung bekommt, beschreibt der Beitrag zum Einarbeiten von KI-Agenten. Genau in dieser Aufteilung liegt der Nutzen im Mittelstand, nicht in der Vorstellung, ein Agent würde ganze Rollen ersetzen. Wie solche Vorgänge als Workflow mit konkretem Node-Aufbau aussehen, zeigen die typischen KI-Workflows im Mittelstand.

Wo Agenten nicht hingehören

Ebenso wichtig wie die Einsatzfälle sind die Ausschlüsse. Ein Agent ist die falsche Wahl, wenn:

• der Vorgang völlig gleichförmig ist. Anthropic empfiehlt, mit der einfachsten Lösung zu beginnen, und beschreibt Workflows als vorhersehbarer und gleichbleibender bei klar umrissenen Aufgaben, während agentische Systeme oft Latenz und Kosten gegen bessere Ergebnisse tauschen. Ein Agent, der jedes Mal dasselbe tut, ist ein teurer Umweg.
• ein Fehler nicht auffällt. Agenten entscheiden eigenständig, und Fehler können sich über mehrere Schritte fortpflanzen. Ein Prozess, dessen Ergebnis niemand prüft, ist kein Kandidat.
• die Entscheidung rechtlich schwer wiegt. Kreditvergabe, Bewerberauswahl und vergleichbar sensible Bereiche unterliegen eigenen regulatorischen Anforderungen – dazu mehr in unserer Übersicht der AI-Act-Pflichten für Anwenderunternehmen.

Recht und Datenschutz

Spricht ein Agent direkt mit Kunden oder erzeugt er Texte, stellen sich Fragen nach Transparenz- und Kennzeichnungspflichten. Welche Pflichten die KI-Verordnung Anwenderunternehmen auferlegt und wann ein Unternehmen selbst als Anbieter gilt, ordnet die Übersicht der AI-Act-Pflichten ein. Wie sich die DSGVO auf Zugriffe, Freigaben und Protokolle eines Agenten auswirkt, behandelt der Beitrag zu KI-Agenten und DSGVO.

Für den Mittelstand heißt das

Prüfen Sie bei jedem Angebot, das „KI-Agent” draufschreibt, die vier Fragen von oben, vor allem Systemzugriff und Stopp-Punkte. Die Bezeichnung allein sagt wenig. Schon die Hersteller definieren unterschiedlich: n8n beschreibt einen KI-Agenten als autonomes System, das Entscheidungen trifft und in seiner Umgebung handelt; Microsoft beschreibt einen Agenten in Copilot Studio als KI-Assistenten, der Gespräche führt und Aufgaben erledigt. Maßgeblich ist, welche Werkzeuge das System bekommt und was es in Ihrem Betrieb damit tatsächlich verändert.

Lassen Sie sich die Schleife zeigen, nicht die Oberfläche: welche Werkzeuge angeschlossen sind, welche davon lesen und welche schreiben, welche Iterationsgrenze gesetzt ist und an welcher Stelle ein Mensch freigibt. Kann ein Anbieter diese vier Punkte nicht benennen, klären Sie sie, bevor Sie weiterverhandeln.

Und wählen Sie den ersten Anwendungsfall nach der Frage aus, ob der Vorgang Varianten kennt. Ist er immer gleich, nehmen Sie einen klassischen Workflow; der ist günstiger und leichter nachvollziehbar. Kennt er viele Ausnahmen, die heute Menschen im Kopf haben, ist das der Fall, in dem ein Agent etwas leisten kann, was vorher nicht automatisierbar war.

FAQ

Was ist der Unterschied zwischen einem KI-Agenten und einem Chatbot?

Der Unterschied liegt im Grad der Eigenständigkeit, nicht in einer scharfen Grenze. Ein Chatbot ist primär eine Gesprächsoberfläche, kann aber durchaus Werkzeuge aufrufen und Vorgänge auslösen. Ein Agent bekommt ein Ziel statt einer Frage und bestimmt den Weg dorthin weitgehend selbst. Die Kategorien überlappen sich, und viele Produkte liegen dazwischen. Prüfen Sie deshalb die konkreten Fähigkeiten statt der Bezeichnung.

Ist ein KI-Agent dasselbe wie RPA?

Nein. Klassisches RPA führt eine fest programmierte Abfolge samt vorher festgelegter Regeln aus; was keine Regel abdeckt, landet als Ausnahme beim Menschen oder bricht ab. Ein Agent bekommt ein Ziel statt einer Abfolge und entscheidet selbst über den Weg dorthin. Bei völlig gleichförmigen Vorgängen prüfen Sie zuerst eine klassische Automatisierung: über eine Schnittstelle, oder per RPA, wenn das System keine bietet.

Wie oft ruft ein KI-Agent Werkzeuge auf, bevor er aufhört?

So oft, bis das Modell eine Antwort ohne weiteren Werkzeugaufruf liefert oder eine gesetzte Grenze greift. Im AI Agent Node von n8n heißt diese Grenze Max Iterations und steht laut Dokumentation standardmäßig auf 10, im Agents SDK von OpenAI heißt sie max_turns und steht im Quellcode ebenfalls auf 10 (Stand 28. September 2026). Legen Sie die Grenze bewusst fest und prüfen Sie im Test, was Ihr Workflow ausgibt, wenn sie erreicht wird.

Brauchen wir für einen KI-Agenten eigene Entwickler?

Für den Betrieb nicht zwingend, für den Bau kommt es auf den Anwendungsfall an. Einfache Agenten lassen sich auf Automatisierungsplattformen wie n8n oder Low-Code-Werkzeugen wie Microsoft Copilot Studio ohne klassische Softwareentwicklung zusammenstellen. Sobald mehrere Systeme ohne fertige Schnittstellen angebunden werden, brauchen Sie technische Unterstützung, intern oder extern.

Wie verhindern wir, dass ein Agent etwas Falsches tut?

Über definierte Grenzen: Welche Werkzeuge bekommt er überhaupt, welche Aktionen darf er ohne Rückfrage ausführen, ab welchem Betrag oder welcher Unsicherheit legt er den Fall einem Menschen vor, und was wird protokolliert? Diese Stopp-Punkte gehören in die Anforderung, nicht als Nachbesserung ins Projekt.