Was ist ein KI-Agent?

Die kurze Antwort

Ein KI-Agent ist ein Sprachmodell, das in einer Schleife arbeitet, Werkzeuge benutzt und dabei von Programmcode zusammengehalten wird. Dieser Code heißt Harness. Er ruft das Modell auf, führt Protokoll über das Gespräch, gibt dem Modell eine Rolle, führt die vorgeschlagenen Werkzeugaufrufe wirklich aus und zieht die Grenzen ein, an die sich das Modell halten muss.

Das Modell selbst ist dabei erstaunlich passiv. Es kann nichts tun. Es kann nur Text vorschlagen, und dass daraus am Ende eine Datei entsteht, eine Mail rausgeht oder ein Datensatz sich ändert, ist jedes Mal die Leistung des Harness. Wer „Agent“ sagt und dabei an das Modell denkt, sucht die Intelligenz an der falschen Stelle. Ob ein Agent brauchbar wird, entscheidet sich fast vollständig im Code drumherum.

Deshalb behandeln wir die Frage „Was ist ein KI-Agent?“ auf dieser Plattform als Bauanleitung und nicht als Definitionsfrage. Es gibt eine überschaubare Zahl von Bauteilen. Jedes hat eine Aufgabe, jedes hat eine Handvoll typischer Fehler, und jedes hat hier seine eigene Seite.

Was ein Agent nicht ist

Kein Chatbot. Ein Chatbot nimmt eine Frage entgegen und gibt eine Antwort zurück, und das ist ein einzelner LLM-Call, hin und zurück, danach ist der Vorgang beendet. Ein Agent bricht an dieser Stelle nicht ab, sondern darf eine Zwischenhandlung vorschlagen, das Ergebnis dieser Handlung sehen und mit dem neuen Wissen weiterarbeiten. Aus einem Austausch wird ein Ablauf.

Keine Automatisierung im gewohnten Sinn. Normale Automatisierung baust du für Abläufe, die du kennst: Schritt eins, dann Schritt zwei, bei Fehler in Zweig drei, und weil der Ablauf vorher feststeht, ist jede Abweichung davon ein Bug und kein Feature.

Einen Agenten baust du für Szenarien, die du nicht kennst, mit einem Werkzeug, das genauso wenig planbar ist. Du legst keine Reihenfolge fest. Du legst den Rahmen fest: welche Werkzeuge es gibt, was sie dürfen, wann Schluss ist. Welchen Weg der Agent darin nimmt, entscheidet er beim Laufen. Das kostet etwas, und zwar an einer Stelle, die man leicht übersieht. Jede Schleife muss in allen Lebenslagen funktionieren, nicht nur in der, für die du sie gebaut hast.

Daraus folgt eine Faustregel, die ich unbequem finde. Ist ein Ablauf vollständig bekannt, dann ist ein Agent die schlechtere Lösung. Teurer. Langsamer. Schwerer zu prüfen. Er lohnt sich dort, wo die Fälle auseinanderlaufen und sonst eine Fallunterscheidung nach der anderen dazukäme.

Kein Assistent, der „versteht“. Das Modell hat kein Gedächtnis zwischen zwei Aufrufen. Beim zweiten Aufruf weiß es nicht, dass es einen ersten gab. Alles, was nach Erinnerung aussieht, ist Text, den der Harness erneut mitgeschickt hat. Wer das einmal begriffen hat, hört auf, dem Modell Absichten zu unterstellen, und fängt an, den Kontext zu bauen.

Block I: Der Harness und seine fünf Bauteile

Der Harness ist der Kern. Er besteht aus fünf Bauteilen, die aufeinander aufbauen. Jedes ist für sich klein, und erst zusammen ergeben sie einen Agenten.

1. Der LLM-Call. Am Anfang steht ein einziger Aufruf. Eine Nachricht hin, eine Antwort zurück. Hier lernst du, was tatsächlich über die Leitung geht, also Rollen, Tokens, Temperatur und Stoppwörter, und warum dieser eine Aufruf zustandslos bleibt, egal wie oft du ihn wiederholst. Ein Agent ist das noch nicht. Es ist nur Text.

2. Die Message-History. Weil das Modell nichts behält, führt der Harness Buch: Er hängt jede Frage und jede Antwort an eine Liste und schickt diese Liste beim nächsten Mal wieder komplett mit, damit aus einzelnen Anrufen ein Gespräch wird. Und aus dieser einfachen Mechanik folgt schon die erste harte Grenze, denn die Liste wächst und das Kontextfenster nicht.

3. Der System Prompt. Bevor das erste Wort des Nutzers ankommt, steht dort, wer der Agent ist. Rolle, Tonfall, Regeln, Zuständigkeit. Ich halte ihn für die billigste und wirksamste Stellschraube am ganzen Aufbau, und für die, an der am meisten Aberglaube klebt.

4. Tools & Loop. Hier wird aus dem Sprachmodell ein Agent. Du beschreibst dem Modell Werkzeuge, es schlägt einen Aufruf vor, der Harness führt ihn aus und legt das Ergebnis zurück in die History, dann entscheidet das Modell erneut, und das geht so lange weiter, bis das Ziel erreicht oder eine Abbruchbedingung erfüllt ist. Wahrnehmen, entscheiden, handeln, prüfen. Darauf läuft alles hinaus.

5. Guardrails. Ein Agent, der handeln darf, kann Schaden anrichten. Guardrails prüfen die Eingaben, filtern die Ausgaben, begrenzen Schleifendurchläufe und Kosten und stoppen zuverlässig das, was unter keinen Umständen passieren darf. Ein Anbau für später sind sie nicht. Ohne sie ist die Schleife aus Schritt vier ein Versprechen ohne Deckung.

Diese fünf reichen für einen lauffähigen Agenten. Alles Weitere macht ihn besser, aber nicht erst möglich. Die Konzept-Übersicht zeigt sie im Zusammenhang.

Ein Durchlauf, Schritt für Schritt

Am schnellsten wird der Unterschied an einem konkreten Auftrag klar. Nehmen wir an, ein Agent soll die Frage beantworten: „Wie viele offene Rechnungen sind älter als 30 Tage, und wie hoch ist die Summe?“ Er hat zwei Werkzeuge. Eine Datenbankabfrage und einen Rechner.

Runde eins. Der Harness schickt System Prompt, Werkzeugbeschreibungen und Frage an das Modell. Das Modell antwortet nicht mit einer Zahl. Es schlägt etwas vor: datenbank_abfrage(status="offen", faellig_vor="2026-07-10"). Mehr passiert im Modell nicht. Es hat Text erzeugt, der zufällig die Form eines Werkzeugaufrufs hat.

Der Harness handelt. Er prüft, ob dieses Werkzeug überhaupt erlaubt ist und ob die Parameter plausibel aussehen, führt die Abfrage aus und hängt das Ergebnis als neue Nachricht an die History: 14 Datensätze, mit Beträgen. Hätte die Abfrage einen Fehler geworfen, ginge die Fehlermeldung in derselben Form zurück. Ein Agent, der Fehler nie zu sehen bekommt, kann sie auch nicht umgehen.

Runde zwei. Derselbe Aufruf noch einmal, nur ist die History jetzt länger. Das Modell sieht die 14 Datensätze und schlägt den nächsten Schritt vor, rechner(operation="summe", werte=[…]). Wieder führt der Harness aus, wieder wandert das Ergebnis in die History.

Runde drei. Jetzt hat das Modell alles beisammen und antwortet im Klartext. 14 Rechnungen, 23.480 Euro. Kein Werkzeugaufruf mehr. Für den Harness ist das die Abbruchbedingung.

Drei Dinge finde ich an diesem Ablauf bemerkenswert. Das Modell wurde dreimal aufgerufen und nicht einmal, jede Runde kostet also Zeit und Geld. Nichts davon war vorher festgelegt, denn bei einer anderen Frage wären es zwei Runden oder sieben, in anderer Reihenfolge. Und an jeder Stelle, an der der Harness ausführt, hätte er auch ablehnen können. Dort sitzen die Guardrails, und dort wirken sie auch als einzige.

Block II: Was daneben steht

Ein Harness ist zunächst nur eine Hülle. Technisch fertig. Fachlich leer. Von deinen Systemen, deinen Daten und deinen Regeln weiß er nichts. Block II ist alles, was daneben gestellt wird, damit aus dem Werkzeug dein Agent wird.

Memory ist der erste eigene Dienst neben dem Harness. Die Kunst daran liegt nicht im Speichern. Sie liegt in der Auswahl. Was von allem Gespeicherten fährt bei dieser einen Anfrage wieder mit? Schickst du alles mit, sprengt es den Kontext, und schickst du zu wenig mit, wirkt der Agent dumm, obwohl er alles Nötige gespeichert hat.

Sidecars sind eigene, zustandslose Dienste für alles, was der Agent nicht raten soll. Eine Berechnung, eine Umwandlung, eine Prüfung. Ein Sidecar beantwortet die Frage, was eigentlich am anderen Ende eines Werkzeugs hängt.

Tool-Calling im Betrieb erklärt, warum ein einzelner Werkzeugaufruf fast immer gelingt und zwanzig hintereinander fast nie. Die Trefferquoten multiplizieren sich. 95 Prozent je Schritt sind nach zwanzig Schritten noch 36 Prozent. Dieses Bauteil handelt von allem, was man ringsherum baut, damit die Kette trotzdem hält.

Tiny Agents und die Kompressionsgrenze liegt eine Etage darüber. Von zweihundert verfügbaren Fähigkeiten sieht das Modell immer nur die, die du ihm zeigst, und die Ausgaben all der übrigen fluten ihm den Kontext, sobald du großzügig wirst. Auswahl ist hier kein Detail. Sie ist die eigentliche Konstruktionsarbeit.

Guardrails im Betrieb ist die Kontrollebene außerhalb des Harness. Sie prüft auch dann noch, wenn der Harness fremd ist oder selbst gekapert wurde. Gateway, Detektoren, Schleusen, Policy.

Block III: Worauf das Ganze läuft

Unter jedem Agenten liegt ein Modell, und unter dem Modell liegt Technik, die man kennen sollte, bevor man Rechnungen oder Antwortzeiten erklären muss.

Wie ein LLM funktioniert ist der Anfang von allem. Eine Maschine, die das nächste Token rät, in Schleife. Warum dieses Raten reicht, um zu übersetzen und zu programmieren, und warum Halluzination keine Störung ist, sondern die Aufgabe.

Die Modell-Landschaft zeigt, welche Modelle es gibt, offen und geschlossen, in welchen Größen, und woran du das für deine Aufgabe passende erkennst.

Was in einem Modell-Download steckt: Gewichte, Tokenizer, Chat-Template. Drei Dinge, die zusammengehören und deren Verwechslung die Hälfte aller seltsamen Ausgaben erklärt.

Inferenz-Engines machen aus einer Datei mit Gewichten eine API, die Anfragen beantwortet.

Hardware ist die harte Speichergrenze. VRAM entscheidet, was überhaupt läuft, und Quantisierung entscheidet, zu welchem Preis.

Benchmarks erklären, wie man Modelle vergleicht, ohne den veröffentlichten Ranglisten blind zu glauben.

Wie man einen Agenten baut

Die Reihenfolge oben ist meine Empfehlung und keine Gliederung. Sie beginnt beim einzelnen Aufruf und endet bei der Kontrollebene, und jeder Schritt wird erst interessant, wenn der davor sitzt.

Praktisch heißt das: Bau zuerst den kleinsten Agenten, der überhaupt etwas tut. Ein Modell, ein Werkzeug, eine Schleife mit hartem Abbruch nach fünf Runden. Erst wenn dieser Aufbau nachvollziehbar läuft, kommt das zweite Werkzeug dazu. Der häufigste Fehler beim Einstieg ist, mit einem Framework zu beginnen, das alle fünf Bauteile schon versteckt hat, denn es läuft sofort, und beim ersten seltsamen Verhalten fehlt dir jede Vorstellung davon, wo du überhaupt nachsehen müsstest.

Falsch ist ein Framework deshalb nicht. Es ist nur die zweite Entscheidung und nicht die erste. Wer die fünf Bauteile einmal selbst gebaut hat, liest danach jedes Framework als das, was es ist: eine Sammlung von Voreinstellungen zu diesen fünf Fragen.

Nachbauen kannst du das in den Tutorials. Dort läuft der Weg vom ersten Aufruf bis zum Agenten mit Werkzeugen an echtem Code entlang.

Woran Agenten scheitern

Drei Muster sehe ich immer wieder, und alle drei haben mit dem Modell wenig zu tun.

Die Kette ist zu lang. Fehlerquoten multiplizieren sich. Wer einem Agenten zwanzig Schritte am Stück zumutet, baut ein System, das meistens irgendwo hängen bleibt. Hilfreich sind kürzere Aufträge, eingestreute Zwischenprüfungen und Werkzeuge, die im Fehlerfall etwas Verwertbares zurückgeben statt einer nackten Ausnahme, mit der das Modell nichts anfangen kann.

Der Kontext läuft voll. Jede Werkzeugausgabe, jede Zwischenantwort und jede angehängte Datei belegt Platz im Kontextfenster, bis das Wesentliche irgendwann so weit hinten steht, dass es schlicht untergeht. Kontext ist eine begrenzte Ressource und muss aktiv verwaltet werden. Dafür gibt es Memory, Zusammenfassung und Auswahl.

Die Rechte sind zu weit. Ein Agent, der schreiben darf, schreibt irgendwann etwas Falsches. Die Frage ist nicht, ob das passiert. Die Frage ist, was es dann kostet. Enge Rechte, ein zweiter Blick vor teuren Aktionen und eine harte Kostengrenze sind billiger als jede nachträgliche Korrektur.

Die Begriffe, die immer wieder fallen

Rund um Agenten hat sich ein Vokabular gebildet, das wir alle oft unscharf benutzen. Hier die wichtigsten Begriffe in je zwei Sätzen. Jeder führt weiter zu der Seite, auf der er ausführlich steht.

Token. Die Einheit, in der Modelle rechnen. Kein Buchstabe und kein Wort, sondern ein Textstück, das der Tokenizer gelernt hat. Kosten, Geschwindigkeit und Kontextgrenze werden in Tokens gemessen und nicht in Zeichen, Genaueres im LLM-Call.

Kontextfenster. Die Obergrenze dessen, was das Modell bei einem Aufruf gleichzeitig sehen kann. System Prompt, History, Werkzeugbeschreibungen und Werkzeugausgaben teilen sich diesen einen Platz.

Tool Calling / Function Calling. Zwei Namen für dieselbe Sache. Das Modell gibt statt Fließtext einen strukturierten Aufruf aus, den der Harness ausführt. Beide Begriffe meinen den Vorschlag und nicht die Ausführung, siehe Tools & Loop.

Agentic Loop. Die Schleife aus Vorschlag, Ausführung, Rückgabe, neuer Entscheidung. Sie ist der Unterschied zwischen einem Modell mit Werkzeugen und einem Agenten.

MCP. Ein Protokoll, das Werkzeuge einheitlich beschreibt, damit nicht jede Anbindung neu erfunden wird. Es löst das Anschlussproblem und nicht das Auswahlproblem. Welche Werkzeuge das Modell sieht, bleibt eine Entwurfsentscheidung, siehe Tiny Agents.

RAG. Suche über eigene Dokumente, deren Treffer vor dem Aufruf in den Prompt gelegt werden. Eine Spielart von Memory, nur über Handbücher statt über Gespräche.

Halluzination. Eine flüssig formulierte, sachlich falsche Ausgabe. Für einen Agenten ist sie besonders teuer, weil sie am Anfang einer Kette steht und alle folgenden Schritte auf ihr aufbauen.

Multi-Agent / Schwarm. Mehrere Agenten, die sich Aufgaben teilen. Das lohnt sich erst, wenn ein einzelner Agent zuverlässig läuft. Sonst multiplizierst du die Fehlerquellen, statt die Arbeit zu teilen.

Häufige Fragen

Braucht man dafür ein großes Modell? Nicht unbedingt. Nach meiner Erfahrung entscheidet die Werkzeugbeschreibung für viele Aufgaben mehr als die Modellgröße. Größere Modelle verzeihen schlechte Prompts eher, was ein Komfortgewinn ist und kein Konzept.

Lokal oder als API? Beides funktioniert, und wir betreiben hier beides. Eine API ist der schnellere Einstieg, ein selbst betriebenes Modell die Antwort auf Datenschutz-, Kosten- und Verfügbarkeitsfragen. Was dafür nötig ist, steht in Block III.

Ist ein Agent zuverlässig? Nicht von selbst. Zuverlässigkeit entsteht aus Guardrails, kurzen Ketten, geprüften Zwischenschritten und aus der Bereitschaft, eine Aufgabe eben nicht an einen Agenten zu geben, wenn ein schlichtes Skript sie schneller und nachvollziehbarer erledigt.

Kann ich mir das nicht einfach in ChatGPT zusammenklicken? Für den Anfang ja, und für manche Aufgaben dauerhaft. Wo zusammengeklickte Agenten im Betrieb brechen, und welches Bauteil das jeweils erklärt, steht auf Agenten in ChatGPT bauen - wozu dann eine Plattform?.

Wo fängt man an? Bei Block I, Bauteil eins. Der LLM-Call ist ohne Konto lesbar und dauert eine Viertelstunde.