In meinem Arbeitsalltag wiederholt sich dieselbe Besprechung. Ein Anbieter führt einem Führungsteam einen „Agenten“ vor, und das Team verlässt den Termin in dem Glauben, es habe einen ausgesprochen cleveren Chatbot gesehen. Was da zur Unterschrift liegt, arbeitet eigenständig, sucht sich seine nächsten Schritte selbst, greift in die Systeme des Unternehmens ein und macht weiter, bis es die Aufgabe für erledigt hält. Woraus dieses Ding besteht, hat dem Team niemand gezeigt.
Diese Lücke ist der Grund, warum die Agentenprojekte, die ich sehe, ins Stocken geraten oder den Verantwortlichen insgeheim Angst machen. Das Wort „Agent“ verdeckt, was da eingeführt wird: ein Modell und ein Harness darum herum – so nennt der Fachjargon alles, was nicht das Modell ist. Über das Modell reden alle. Nutzen und Risiko sitzen im Harness.
Dieser Beitrag ist die Teileliste. Wie so ein Agent gebaut wird, können Sie am Beispiel der Rechnungsprüfung nachlesen; hier geht es um etwas anderes. Wenn Ihnen das nächste Mal jemand einen Agenten zeigt (ein Anbieter oder Ihr eigenes Team), erkennen Sie die Teile: welche Sie hinterfragen müssen, welchen Sie vertrauen können und wofür Sie eine Regel brauchen. Es sind fünf, und keines davon ist Zauberei.
Der Motor allein bringt Sie nicht vom Fleck
Fangen Sie bei der Unterscheidung an, die am meisten Klarheit schafft: Das Modell ist nicht der Agent.
Das Modell (Claude, GPT, Gemini, welches auch immer Sie einsetzen) ist ein Motor für Text. Sie geben ihm Text, und es sagt voraus, welcher Text als Nächstes am nützlichsten ist. Von allein kann es keine Datei öffnen, keine E-Mail verschicken und nicht in den Zahlen von gestern nachsehen, und an Ihr letztes Gespräch erinnert es sich nicht. Für sich genommen ist es ein sehr belesener Kollege, den jemand in einen Raum ohne Telefon gesperrt hat und der zwischen zwei Terminen alles vergisst.
Das Harness ist alles, was diesen Motor überhaupt arbeiten lässt: die Schleife, die ihn in Gang hält, die Werkzeuge, über die er in Ihre Systeme eingreift, das Gedächtnis, das die Aufgabe über alle Schritte hinweg zusammenhält, und die Aufzeichnung dessen, was er getan hat. Thorsten Ball, der den Coding-Agenten Amp mit aufgebaut hat, bringt es in seinem öffentlichen Werkstattbericht „How to Build an Agent“ auf eine Formel: „an LLM, a loop, and enough tokens“ – ein Sprachmodell, eine Schleife und genug Tokens. Ein Sprachmodell ist der eben beschriebene Motor für Text; Tokens sind die Einheiten, in denen ein solcher Motor Text liest und schreibt, und deshalb lässt sich sein Verbrauch überhaupt budgetieren. Ball hat das nicht behauptet, sondern gezeigt: Er hat einen Agenten öffentlich gebaut, und der lauffähige Agent kam mit weniger als 400 Zeilen Code aus, das meiste davon Standardcode.
Der Satz ist beruhigend und ein wenig beunruhigend zugleich. Beruhigend, weil der Nimbus wegfällt: In einem Agenten steckt keine verborgene Intelligenz, sondern eine Schleife, die Sie verstehen können. Beunruhigend, weil daraus etwas folgt: Läuft ein Agent auf eine Schleife und ein paar Werkzeuge hinaus, dann hat nicht der Hersteller des Modells festgelegt, worauf Ihr Agent zugreifen darf, wie weit er unbeaufsichtigt gehen darf und ob hinterher jemand sehen kann, was er getan hat, sondern derjenige, der das Harness geschrieben hat. Gesteuert wird im Harness, nirgends sonst.
Fünf Teile. Vom Modellanbieter kommt genau eines; über die anderen vier hat längst jemand entschieden, meist ohne dass die Frage je gestellt wurde.
Die Schleife – und wer ihr sagt, wann Schluss ist
Unter der Oberfläche läuft in jedem Agenten dieselbe kurze Runde. Das Harness schickt dem Modell das Ziel und alles, was bisher bekannt ist. Zurück kommt entweder die fertige Antwort oder die Bitte, ein Werkzeug einzusetzen. Im zweiten Fall führt das Harness das Werkzeug aus, fügt dessen Ergebnis – im Fachjargon eine Beobachtung – dem bisher Bekannten hinzu und schickt alles zusammen zurück. Das Modell liest das Ergebnis und entscheidet über den nächsten Schritt. Runde um Runde, bis das Modell die Aufgabe für erledigt hält oder eine Abbruchregel greift.
Das ist der tatsächliche Aufbau, keine für Sie geglättete Skizze davon. Die Leute, die solche Systeme bauen, beschreiben die Schleife mit denselben Worten. Anthropics eigene Dokumentation zu Claude Code braucht für die Schleife einen einzigen Satz: Das Modell wertet Ihre Anweisung aus, ruft Werkzeuge auf, um zu handeln, nimmt deren Ergebnisse entgegen und wiederholt das, bis die Aufgabe erledigt ist. Der Agenten-Baukasten von OpenAI beschreibt dieselbe Runde: das Modell aufrufen, die angeforderten Werkzeuge ausführen, ihre Ergebnisse dem bisher Bekannten hinzufügen und wieder von vorn beginnen. Diese Schleife ist der Takt, in dem alles andere läuft.
An dieser Schleife sitzen zwei Regler: die Abbruchregel und die Freigabe. Wer sie nicht einstellt, hat sie trotzdem eingestellt.
Drei Eigenschaften dieser Schleife sind für Sie wichtiger als für diejenigen, die den Code schreiben.
Das Modell wählt in jeder Runde seinen nächsten Schritt selbst. Es folgt keinem festen Skript, das Sie von vorn bis hinten lesen könnten. Zwischen „Ziel erhalten“ und „fertig gemeldet“ können zwanzig Schritte liegen, die niemand vorgegeben hat, und jeden davon sucht sich das Modell selbst aus.
In der Schleife steckt außerdem die Autonomie. Wie viele Runden darf ein Agent drehen, bevor er anhalten und einen Menschen fragen muss? Welche Schritte laufen ohne Ihr Zutun durch, und welche brauchen vorher eine Freigabe? Das sind die beiden Regler, und wie Sie diese einstellen, ist die folgenreichste Entscheidung, die bei einem Agenten ansteht. Ab Werk ist keine dieser Grenzen gezogen: Dieselbe Dokumentation von Anthropic hält nüchtern fest, dass die Schleife ohne solche Grenzen weiterläuft, bis das Modell selbst zu dem Schluss kommt, es sei fertig. Ein Agent ohne Abbruchregel und ohne Freigabe ist nicht mächtiger. Er ist eben nur schlechter beaufsichtigt.
Und die Schleife bringt einen Agenten auch wieder in die Spur. Scheitert ein Schritt, kommt der Fehlschlag als weitere Beobachtung in die Schleife zurück, und das Modell darf es erneut versuchen: ein anderer Befehl, ein anderer Weg. Von außen sieht dieses selbstkorrigierende Verhalten nach Intelligenz aus. Dabei ist es nur die Schleife, die den Fehler noch einmal einspeist.
Die Werkzeuge: wo der Agent an Ihre Systeme herankommt
Auf sich allein gestellt erzeugt das Modell nur Text. Erst Werkzeuge lassen es handeln, und genau die sollten Sie sich am gründlichsten ansehen: Jedes Werkzeug ist eine Tür aus der Sandbox (der abgeschotteten Umgebung, in der ein Agent nichts Echtes berührt) hinaus in ein System, mit dem Ihr Unternehmen tatsächlich arbeitet.
Technisch ist ein Werkzeug unspektakulär. Sie geben dem Modell eine Liste dessen, was es tun darf: jedes Werkzeug mit einem Namen, einem schlichten Satz dazu, wann man es einsetzt, und der Angabe, welche Eingaben es braucht. Ausführen kann das Modell selbst nichts. Es sagt sinngemäß: bitte send_invoice mit diesen Werten ausführen. Das Harness tut es und reicht das Ergebnis zurück. Balls Werkstattbericht zerlegt den Ablauf in zwei Schritte: Man nennt dem Modell die verfügbaren Werkzeuge, und will es eines einsetzen, sagt es Bescheid, statt selbst zu handeln. Ein Werkzeug, das eine Datei liest, eines, das eine Rechnung verschickt: jedes davon ist ein kleines Stück Code, das dem Harness gehört, und das Modell kann nur fragen.
Welche Tür ein Modell wählt, hängt von dem einen Satz ab, den jemand daneben geschrieben hat. Lassen Sie sich diese Sätze vorlegen; sie sind kurz, und um sie zu beurteilen, brauchen Sie kein Fachwissen.
Zwei Dinge folgen daraus, und über beide entscheiden Sie.
Die Anbindung wird gerade vereinheitlicht. Statt jede Verbindung zwischen einem Agenten und einem System von Hand zu bauen, greifen Teams zunehmend zum Model Context Protocol (MCP), der genormten Steckdose zwischen einem Modell und Ihren Systemen: Ein Agent spricht viele Werkzeuge und Datenquellen über ein und denselben Anschluss an. Wer die Mechanik dahinter sehen will, findet sie in einem eigenen Beitrag über das Model Context Protocol. Hier zählt nur eines: „Werkzeuge“ ist die Stelle, an der Ihr Agent an Ihre Systeme herankommt, und MCP ist inzwischen der übliche Weg dorthin.
Und ein häufiger Grund, warum es mit den Werkzeugen schiefgeht: Es sind zu viele, und sie sind schlecht beschrieben. Diese Beschreibungen stehen in demselben Text, den das Modell in jeder Runde liest, und die Ergebnisse der Werkzeuge stehen dort ebenfalls; je länger die Liste, desto weniger Platz bleibt für alles andere. Das Engineering-Team von Anthropic hat dafür eine eigene Überschrift; übersetzt lautet sie: Werkzeugdefinitionen überladen das Kontextfenster. Beschrieben werden dort Agenten, die an Tausende von Werkzeugen angeschlossen sind und sich durch alle hindurcharbeiten, bevor sie überhaupt bei der Anfrage ankommen. Das ist ein Anbieter, der über eine Schwäche des eigenen Protokolls schreibt: ein Praxisbericht, keine unabhängige Messung. Entscheidend ist die Richtung: Die Anweisungen, die Sie sorgfältig formuliert haben, können neben den Werkzeugbeschreibungen zu einem Rundungsfehler schrumpfen.
Der belegte Platz ist nur die eine Hälfte der Kosten. Geben Sie einem Agenten vierzig einander überschneidende Werkzeuge, zögert er oder verbraucht Runden damit, sich für eine Tür zu entscheiden. Ein durchdachtes Harness stellt wenige, scharf zugeschnittene Werkzeuge bereit; eine lange, unscharfe Liste ist das Warnzeichen. Wenn Sie einen Agenten prüfen, fragen Sie nach der Zahl der Werkzeuge und danach, wer bei jedem einzelnen entschieden hat, dass es dazugehört.
Damit ist geklärt, woran ein Agent herankommt. Was er sehen kann, ist eine eigene Frage, und eine merkwürdigere.
Das Gedächtnis eines Agenten reicht genau eine Runde weit
Dieses Teil überrascht die meisten. Das Modell behält nichts. Bei jedem Aufruf sieht es nur den Text, den das Harness ihm gerade mitgibt, und vergisst alles in dem Moment, in dem es antwortet. Ball sagt es unumwunden: Der Server des Modellanbieters ist zustandslos, er sieht nur das Gespräch, das man ihm schickt, und den Zustand zu halten ist Sache dessen, der das Harness baut. Der Eindruck, ein Agent behalte Ihre Aufgabe über ein Dutzend Schritte hinweg im Kopf, entsteht allein dadurch, dass das Harness jedes Mal den gesamten Verlauf erneut mitschickt.
Ein falsch bestücktes Fenster sieht von außen aus wie ein richtiges. Deshalb ist die Frage, was hineindarf, keine technische Frage, sondern eine der Aufsicht.
Dieses erneut mitgeschickte Bündel (das Ziel, die Schritte bis hierher, die Ergebnisse der Werkzeuge, die abgerufenen Dokumente) heißt Kontextfenster und ist das gesamte Arbeitsgedächtnis des Agenten. Alles, was der Agent gerade weiß, steht darin; was nicht darin steht, weiß er nicht. Ob ein Agent nützlich oder gefährlich ist, entscheidet deshalb das Kontextfenster, nicht das Modell und nicht die Werkzeuge. Ein Agent, der sauberen, passenden, richtig zugeschnittenen Kontext bekommt, arbeitet wie eine Expertin, die die Akte gelesen hat. Derselbe Agent, der zu viel bekommt oder die falschen Daten oder eine veraltete Angabe, die einer aktuellen unbemerkt widerspricht, arbeitet mit voller Überzeugung nach der falschen Vorlage – und warnt Sie nicht, weil von innen alles stimmig aussieht.
Dieses Fenster gut zu füllen ist echtes Handwerk: was hineinsoll, was draußen bleibt, was erst geholt wird, wenn die Aufgabe es verlangt. Darin unterscheidet sich ein verlässlicher Agent von einem launischen, und das ist ein Thema für sich; worauf es beim Kontext-Engineering ankommt, habe ich an anderer Stelle beschrieben.
Für die Teileliste genügt ein Punkt. Das Urteil eines Agenten ist immer nur so gut wie das, was in dieser Runde in seinem Fenster steht, und ob darin Veraltetes oder Verfälschtes liegt, sieht von außen niemand. Genau dort müssen auch Ihre Datenregeln greifen: Wenn eine bestimmte Art von Dokumenten das Modell nie erreichen darf oder ein Feld mit Kundendaten das Unternehmen nicht verlassen darf, dann entscheidet sich im Kontextfenster, ob diese Regel hält – und zwar in jeder Runde neu.
Und weil das Modell nach jeder Runde alles vergisst, bleibt vom Wissen des Agenten nur das übrig, was das Harness mitgeschrieben hat.
Der Flugschreiber: was bleibt, wenn etwas schiefgeht
Das letzte Teil zeigen die wenigsten Demos. Dabei entscheidet es darüber, ob Sie einem Agenten Ihr Geschäft anvertrauen können oder nur darauf hoffen dürfen, dass alles gutgeht. Ein Agent arbeitet nicht deterministisch: Geben Sie ihm dieselbe Aufgabe zweimal, kann er zwei verschiedene Wege nehmen, weil das Modell jeden Schritt neu wählt. Ein festes Programm können Sie Zeile für Zeile lesen; einen Agenten können Sie nur beobachten. Also muss das Harness mitschreiben, was es beobachtet hat: jeden Schritt des Modells, jeden Werkzeugaufruf, jedes Ergebnis, jede Stelle, an der das Modell die Richtung gewechselt hat.
Diese Aufzeichnung heißt Ablaufprotokoll, im Fachjargon Trace, und dafür ist inzwischen eigene Software entstanden. Bei OpenTelemetry, dem offenen Standard hinter einem Großteil des heutigen Monitorings, wird sogar an einem gemeinsamen Format für die Ablaufprotokolle von Agenten gearbeitet. Diese Arbeit ist erklärtermaßen unfertig: In der Statuszeile des Dokuments steht bis heute „Development“. Gut zu wissen, bevor ein Anbieter Ihnen seine Ablaufprotokolle als Standard verkauft.
Fünf Schritte, einer davon falsch. Ob dieses Protokoll existiert, wird lange vor dem Tag festgelegt, an dem Sie es brauchen.
Ohne Ablaufprotokoll bleibt ein Agent undurchsichtig: Am Ende kommt ein Ergebnis heraus, und wenn es falsch ist, haben Sie nichts in der Hand als eben dieses Ergebnis. Mit Protokoll wird derselbe Fehlschlag zu einer Geschichte, die man nachlesen kann: dieses Werkzeug aufgerufen, diesen Fehler bekommen, daraufhin ein anderes versucht, und hier steht der Schritt, der wirklich falsch war. Das ist der Unterschied zwischen einem Agenten, den Sie steuern, und einem, dem Sie nur vertrauen.
Das Ablaufprotokoll trägt auch dazu bei, dass ein Agent sich aus einem Fehler wieder herausarbeitet. Hier greifen zwei Teile ineinander: die Schleife, die weiterläuft, und die Aufzeichnung, die mitschreibt. Ein gut gebautes Harness scheitert nachvollziehbar: Es setzt bewusst neu an, es hält an der Grenze an, die Sie gezogen haben, und holt dort einen Menschen dazu. Ein schlecht gebautes scheitert lautlos und macht weiter. Führt Ihnen ein Team also einen Agenten vor, lassen Sie sich das Protokoll eines Laufs öffnen, der schiefgegangen ist. Entweder man geht es mit Ihnen Schritt für Schritt durch, oder man wechselt das Thema.
Die Teileliste – und was Sie damit anfangen können
Setzen Sie die fünf Teile zusammen, ergibt das Ganze ein klares Bild. Ein Modell, das Text vorhersagt. Eine Schleife, die es weitermachen und seinen nächsten Schritt selbst wählen lässt. Werkzeuge, über die es in Ihre Systeme eingreift. Ein Kontextfenster, das als Arbeitsgedächtnis dient und jede Runde vollständig erneut mitgeschickt wird. Und ein Ablaufprotokoll, das festhält, was in jedem Schritt geschehen ist. Daraus besteht ein Agent, und Sie sehen ihn jetzt vollständig.
Einen Agenten zu verantworten verlangt weit weniger von Ihnen, als einen zu bauen. Vier Fragen genügen, eine an jedes Teil rund um das Modell. Achten Sie dabei darauf, ob die Antwort eine echte Entwurfsentscheidung ist oder eine Ausflucht:
- Die Schleife: Wie weit darf der Agent allein gehen, bevor er anhalten und einen Menschen fragen muss, und welche Handlungen brauchen vorher eine Freigabe?
- Die Werkzeuge: Auf wie viele kann er zugreifen, wer hat bei jedem entschieden, dass es dazugehört, und welche davon etwas ändern oder senden, statt nur zu lesen?
- Der Kontext: Welche Daten dürfen in sein Fenster, welche bleiben draußen, und welche dürfen das Modell gar nicht erst erreichen?
- Das Ablaufprotokoll: Kann jemand nachvollziehen, was der Agent vergangenen Dienstag getan hat, und kann diese Person das Protokoll eines gescheiterten Laufs öffnen und Ihnen vorlesen?
Keine dieser Fragen setzt Kenntnisse in Data Science voraus. Es sind Fragen der Steuerung, also der Governance, und wer das Ding gebaut hat, kann sie durchaus ohne Fachchinesisch beantworten. Wo ein Agentenprojekt ins Stocken gerät, ist die Vorgeschichte meist dieselbe: Jemand hat das Modell eingeführt, und für das Harness war niemand zuständig. Behandeln Sie das Harness als das eigentliche Produkt, denn das ist es.
Der Motor wird von allein besser: Alle paar Monate können die Modelle mehr, und das bekommen Sie geschenkt. Das Harness nicht. Wie Ihres aussehen muss, hängt von Ihren Systemen und Ihrem Risiko ab; genau da setzt meine Arbeit als Fractional CAIO meistens an. Entweder Sie entwerfen das Harness, oder Sie erben es ungewollt, und für diese Entscheidung müssen Sie geradestehen.
