KI & Agenten · Ontologie

Es gibt keinen Review-Agenten

Tom Jansen · 08.07.2026 · 12 Min. Lesezeit

Neulich habe ich die „Kent Beck“-Folge von Gergely Orosz’ Podcast The Pragmatic Engineer gehört, übrigens ein großartiger Podcast. Kent erzählt darin, wie er beim Programmieren mit einem Thesaurus am Schreibtisch saß und sehr ernsthaft darüber nachgedacht hat, die richtigen Wörter und Namen für die Dinge zu finden, die er gerade programmiert.

So hat das hier angefangen: als Vokabelübung. Ich wollte endlich saubere Definitionen für die Wörter haben, die alle rund um KI-Agenten benutzen: Goal, Task, Tool, Harness, Agent.

Aufschreiben, schärfen, fertig. Stattdessen endete die Reise damit, dass ich jetzt glaube, dass das Wort „Agent“ selbst ein Problem ist, und dass wir für LLMs, oder breiter für agentische GenAI-Systeme, das falsche Identitätskonzept übernommen haben.

Der Auslöser war das hier: Leute sprechen vom „Coding-Agenten“ und vom „Review-Agenten“, als wären das zwei verschiedene Entitäten. Zwei Spezialisten, wie Kollegen. Aber schau dir an, was tatsächlich läuft: dasselbe Modell, dasselbe Harness, oft buchstäblich derselbe Code. Der einzige Unterschied sind ein paar Absätze Prompt und ein frisches Kontextfenster, wenn überhaupt. Wenn ein Kollege morgens Code schreibt und nachmittags Code reviewt, sagen wir nicht, dass die Firma zwei Mitarbeiter hat. Wir sagen, eine Person hat zwei Jobs gemacht. Warum zählen wir bei Agenten also anders?

Meine erste Antwort war: Was sie trennt, ist die Session, der angesammelte Kontext und so etwas wie eine Motivation. Coding will Output produzieren, Review will Probleme finden. Das fühlte sich richtig an, aber ich hatte es trotzdem noch nicht ganz richtig.

Das Modell ist ein Typ

Die menschliche Analogie funktioniert so: Ein kontinuierliches Selbst setzt verschiedene Hüte auf. Ich als Entwickler und ich als Reviewer sind Rollen über einem einzigen Körper und Geist, einem einzigen Gedächtnisstrom, einer einzigen Geschichte.

Jetzt such das entsprechende kontinuierliche Selbst unter dem Coding-Agenten und dem Review-Agenten. Da ist nichts. Das Modell ist zustandslos. Jeder Aufruf startet bei denselben eingefrorenen Gewichten. Nimm den Kontext weg und du bekommst keinen Agenten mit Amnesie. Du bekommst gar keinen Agenten, nur ein Modell.

Die Session trennt also nicht einfach zwei Individuen. Sie konstituiert das Individuum.

Niemand glaubt, dass zwei Prozesse, die dasselbe Binary ausführen, heimlich eine Entität sind. Und niemand glaubt, dass das Binary selbst jemand ist. „Der Coding-Agent“ und „der Review-Agent“ sind dasselbe Ding, nur mit anderen Argumenten gestartet.

Interessant ist: Es scheitert auch anders herum als normale Anthropomorphisierung. Menschliche Identität setzt einen Körper, einen Geist, eine Geschichte voraus. Ein Modell bricht alle drei Verhältnisse: ein Modell, N parallele Instanzen, null intrinsische Geschichte. Ein Modell ist weniger wie eine Person, die Rollen spielt, und mehr wie eine Population, die man bei Bedarf instanziieren kann. Das wird noch klarer, wenn „Agent A“ für Research-Arbeit oder Ähnliches eine Armee vage definierter Sub-Agenten aufruft.

Motivation ist nur Text

Ich dachte zuerst, der Unterschied zwischen Coder und Reviewer seien unterschiedliche Reward Functions. Das ist zwar falsch, hat mich aber in die richtige Richtung geschoben und macht den Punkt noch stärker.

Bei der Inferenz gibt es keinen Reward. Nichts wird optimiert, nichts wird als Anreiz empfunden. Was wie Motivation aussieht, ist Text im Kontext: „Schreibe Code, der die Tests besteht“ versus „Finde alles, was an diesem Code falsch ist“. Der ganze Unterschied zwischen den zwei „Agenten“ sind ein paar Absätze Prompt. Welche echten Dispositionen es auch gibt, Hilfsbereitschaft, Vorsicht, Stil, sie leben in den gemeinsamen Gewichten, im Modell- oder Systemprompt, die zumindest über eine gewisse Zeit stabil bleiben, und sind damit zwischen beiden identisch. Die Teile, die sich unterscheiden, sind genau die Teile mit dem schwächsten Anspruch darauf, eine Entität zu sein: Wörter.

Wo die menschliche Analogie scheitert

Eine Person, die ihren eigenen Code reviewt, trägt ihre frühere Argumentation mit sich herum, ihre Commitments, ihren Druck zur Selbstkonsistenz, ihren Schmerz und ihr Leiden und dadurch auch ihre Liebe zur eigenen Arbeit.

Eine Coding-Session, die ihren eigenen Output reviewen soll, hat ein sehr ähnliches Problem: Die Rechtfertigung für jeden Shortcut steht direkt im Kontext, und der Review erbt sie. Eine frische Session hat das nicht. Sie ist eine Zweitmeinung von einem Arzt, der die erste Diagnose nie gesehen hat.

Coder und Reviewer in getrennte Sessions zu splitten, ist Informationshygiene.

Bei Menschen kann man diese Unvoreingenommenheit nicht auf Knopfdruck herstellen. Bei Modellen kann man es, kostenlos, in Millisekunden. Das Multi-Agent-Pattern ist also operativ richtig und ontologisch aufgeblasen zugleich. Der Wert lag nie darin, dass es zwei Entitäten gibt. Der Wert liegt darin, dass es zwei Kontexte gibt und einer davon sauber ist.

Man sieht den gegenteiligen Fehler draußen in der Praxis skalieren. Ich habe neulich einen Post von jemandem gelesen, der 2024 25 Agenten gebaut hatte, jeweils mit Namen, Gesicht und Rollenprofil, wie Mitarbeiter: einer für Marketing, einer für Support, einer für Reporting. Berater verkaufen genau das als „AI employees“, und es resoniert, weil es vertraut wirkt. Ein Jahr später hatte er alles davon weggeworfen und betreibt jetzt einen Agenten, der über hundert Prozesse ausführt.

Seine Diagnose: Wenn du KI als Mitarbeiter denkst, baust du ein Organigramm. Und mit vielen Agenten baust du genau das wieder auf, was du eigentlich vermeiden wolltest. Silos, Wissensinseln, Koordinationsaufwand, bis du den Überblick verlierst wie eine Firma, die zu schnell tausend Leute eingestellt hat.

Worauf er stattdessen gekommen ist, ist die Spec/Run-Unterscheidung, operativ entdeckt: ein Executor, der mit Zugriff auf Daten, Prozesse, Tools und Regeln jede digitale Arbeit erledigen kann, beliebig oft, parallel. Lies diese Liste nochmal. Daten, Prozesse, Tools, Regeln. Das sind Kontext, Workflows, Tools und Guardrails. Er hat die 25 Arbeiter gelöscht und die vier Komponenten behalten, weil die 25 Agenten nie 25 Entitäten waren. Sie waren ein Programm mit 25 Stellenbeschreibungen, und das Organigramm war der laufende Preis dafür, so zu tun, als wäre es anders.

Wichtig ist aber, was die Löschung überlebt: Du spawnst trotzdem einen separaten Run, wenn du einen sauberen Kontext brauchst, wie beim Reviewer oben. Die Lektion ist nicht „niemals splitten“. Die Lektion ist: Splitten heißt Prozesse spawnen, nicht Personal einstellen. Und Prozesse brauchen keine Namen und Gesichter.

Der Modellwechsel-Test

Ein guter Testfall dafür, wo Identität eigentlich sitzt: Tausche mitten in einer Session das Modell aus, sagen wir ein Upgrade von einer Modellgeneration auf die nächste, aber behalte den vollständigen Kontext. Derselbe Agent oder nicht?

Mein Session-Kontinuitäts-Instinkt sagte ja: dasselbe Transkript, dieselben angesammelten Commitments, dieselbe Trajektorie. Der offensichtliche Einwand sagt nein: Modelle unterscheiden sich in Grundfähigkeit, Denktiefe und darin, wie sie sich bei derselben Temperature verhalten. Wenn der Agent die Ansammlung von allem ist, was ihn definiert, dann ist das Modell klar ein Teil davon.

Beide Antworten sind richtig, weil sie unterschiedliche Dinge tracken.

Die eine verfolgt numerische Identität: „Ist es dasselbe fortdauernde Ding?“
Die andere verfolgt qualitative Identität: „Hat es dieselben Eigenschaften?“

Bei Menschen fallen diese Dinge ständig auseinander. Ein Schlaganfall oder zwanzig Jahre Altern verändern Fähigkeiten drastisch, und trotzdem sagen wir „dieselbe Person“, weil wir glauben, dass darunter eine Tatsache liegt.

Bei Agenten gibt es diese Tatsache nicht. Identität wird nicht entdeckt, sie wird festgelegt. Eine Buchhaltungskonvention, die wir danach wählen, was wir tracken müssen: Abrechnung, Caching, Reproduzierbarkeit. Die eigentliche Frage ist also nicht „ändert ein Modellwechsel den Agenten“, sondern „welche Konvention ist nützlich“.

Sortiere alles nach Lebensdauer

Um diese Konvention zu finden, nimm jede Komponente und sortiere sie danach, wie lange sie lebt:

Gewichte und Architektur. Beim Training eingefroren. Ein neuer Trainingslauf ist ein neues Modell. Punkt.
Harness-Code. Stabile, versionierte Software.
Rollen, Skills, Prompts. Editierbare Artefakte, ändern sich durch menschliche Entscheidung.
Memory Store. Wächst über Sessions hinweg an.
Sampling-Konfiguration. Temperature, Thinking Budget. Pro Request gesetzt.
Session-Kontext. Lebt für einen Run.
Der Forward Pass. Aktivierungen, nach Millisekunden weg.

Ein Ding auf dieser Leiter

Das erklärt auch genauer, warum „Agent“ in die Irre führt. Es ist nicht nur, dass das Wort Kontinuität voraussetzt, während diese Systeme ephemer sind. Personen-Nomen setzen voraus, dass Fähigkeit, Erinnerung und Kontinuität in einem Substrat verschmolzen sind. Die Skills, Erinnerungen und Persistenz eines Menschen leben im selben Gehirn und verändern sich zusammen. In einem KI-System sind sie auseinandergezogen: Fähigkeit ist in Gewichten eingefroren, Verhalten wird durch Request-Konfiguration moduliert, Kontinuität wird durch Kontext getragen, Memory wächst in Dateien an. Vier Dinge, vier verschiedene Lebensdauern. Kein Nomen, das sich Personen-Semantik leiht, kann das beschreiben.

Lesen vs. Werden

Damit kommen wir zu den Memory-Features, mit denen jedes Agentenprodukt gerade wirbt. Sind sie Teil der Identität des Agenten, so wie menschliche Erinnerung Teil unserer Identität ist?

Die wichtige Unterscheidung ist Lesen versus Werden. Wenn du dich an etwas erinnerst, verdrahtet der Abruf die Gedächtnisspur physisch neu. Menschliches Gedächtnis aktualisiert dasselbe Substrat, das auch denkt. Das heißt: Erinnerungen verändern sich beim Erinnern. Du wirst durch Erinnern verändert. Wenn ein Modell seine Memory-Datei liest, ändert sich der Kontext, nicht der Leser. Die Gewichte nach dem Lesen sind bitidentisch mit den Gewichten davor.

Diese Systeme haben also kein Gedächtnis im konstitutiven Sinn. Sie haben eine Prothese. Die ehrliche Analogie ist Leonard aus Memento: keine Fähigkeit, neue Langzeiterinnerungen zu bilden, funktioniert komplett über Notizen und Tattoos. Agenten-Memory ist wie Tattoos für einen zustandslosen Leser. Eine gut sortierte Bibliothek neben dem Modell, keine Veränderung im Modell.

Aber daraus zu schließen, dass Memory außerhalb von Identität liegt, wäre falsch. In der Spec-Sicht passt es sauber hinein: Der Memory Store ist Teil der Spec und individualisiert sie damit. Zwei Instanzen desselben Modells mit unterschiedlichen Memory Stores verhalten sich unterschiedlich und sind unterschiedliche Specs. Memory ist auf Spec-Ebene identitätskonstituierend, auf Modellebene aber nicht.

Die Ausnahme bestätigt die Regel: Fine-Tuning wäre echtes Werden, Erfahrung, die die Gewichte erreicht. Und achte darauf, wie wir das Ergebnis nennen. Ein neues Modell. Wir geben still zu, dass eine Änderung am Substrat Identität auf eine Weise verändert, wie das Anhängen an eine Bibliothek es nicht tut.

Hör auf zu fragen, was der Agent ist

Ein letzter Gedanke. Selbst eine vollständig fixierte Spec erzeugt kein identisches Verhalten. Bei Temperature > 0 gibt dir dieselbe Spec jedes Mal einen anderen Run, und in der Praxis ist selbst Temperature 0 nicht perfekt deterministisch.

Meine praktische Regel nach all dem: Hör auf zu fragen, was der Agent ist. Frag stattdessen, was wahr sein müsste, damit zwei Runs als dasselbe Ding zählen, wie dieses Ding von anderen Dingen getrennt ist, und benenne dann genau das. Das ist weniger mystisch als zwei Kollegen. Und ich glaube, es ist deutlich nützlicher.

Die vollständige Ontologie

Hier ist, wo die Vokabelübung am Ende gelandet ist. So sortiert, dass jede Definition nur Begriffe verwendet, die über ihr schon definiert sind. Wenn eine Ontologie sich nicht so linearisieren lässt, hat sie versteckte Zirkularität.

Auftraggeber — die Partei, für die das System arbeitet. Setzt das Ziel, erteilt die Befugnis zu handeln, verantwortet das Ergebnis.
Ziel — eine Beschreibung des Weltzustands, den der Auftraggeber haben will. Das Erfolgskriterium.
Umgebung — alles außerhalb des Systems, das beobachtet oder verändert werden kann. Dort lebt Zustand.
Ereignis — eine unveränderliche Aufzeichnung, dass in der Umgebung etwas passiert ist, egal ob vom System verursacht oder nicht.
Tool — eine Schnittstelle, über die die Umgebung beobachtet oder beeinflusst werden kann.
Aktion — die kleinste Einheit des Tuns. Eine einzelne Nutzung eines Tools.
Aufgabe — eine abgegrenzte Arbeitseinheit mit Done-Bedingung, die das Ziel voranbringt.
Workflow — die Methode: die möglicherweise verzweigte Reihenfolge von Aktionen, durch die eine Aufgabe erledigt wird.
Guardrail — eine vom Auftraggeber autorisierte Einschränkung, die Aktionen mit inakzeptablen Folgen blockiert.
Modell — eingefrorene Gewichte. Der Reasoning-Kern, der Kontext liest und die nächste Aktion auswählt. Ein neuer Trainingslauf ist ein neues Modell.
Konfiguration — die Regler pro Request: Temperature, Thinking Budget, verfügbare Tools. Verhaltensmodifikatoren, keine Substanz.
Skill — paketiertes Know-how, um Tools zu benutzen und Workflows kompetent auszuführen.
Kontext — alles, was zum Entscheidungszeitpunkt bekannt ist: Ziel, beobachteter Zustand, Geschichte von Aktionen und Ereignissen, Einschränkungen.
Memory — eine Bibliothek, auf die das System zeigt. Wächst über Runs hinweg an. Wird gelesen, nie absorbiert.
Rolle — ein Ziel plus eine Perspektive, als Kontext verpackt. „Coder“ und „Reviewer“ sind Rollen. Eine Stellenbeschreibung, kein Arbeiter.
Loop — der Zyklus, der läuft, bis das Ziel erreicht ist oder eine Guardrail ihn stoppt: Ereignisse beobachten, Kontext aktualisieren, das Modell eine Aktion wählen lassen, sie ausführen, wieder beobachten.
Harness — die Maschinerie um das Modell herum, die den Loop ausführt: Kontext einspeisen, Aktionen über Tools ausführen, Guardrails durchsetzen.
Spec — das reproduzierbare Rezept: Modell, Konfiguration, Harness-Version, Rolle, Skills, Memory-Pointer. Das stabile Ding. Änderungen bekommen Versionssemantik.
Run — eine Ausführung einer Spec, die Kontext ansammelt. Das ephemere Ding.
Session — der Kontext, den ein Run ansammelt. Die einzige Kontinuität im ganzen System.
Agent — Kurzform für einen Run einer Spec. Praktische Entitäten-Sprache, nützlich so wie „der Prozess wartet auf einen Lock“ nützlich ist, irreführend so wie „das Binary will etwas“ irreführend wäre.

Zwei strukturelle Notizen zur Liste. Der Workflow ist absichtlich nicht Teil der Agent-Definition. Ein fähiges System generiert seinen Workflow zur Laufzeit, also ist der Workflow Output, nicht Anatomie. Und der Loop lebt im Harness: Das Harness ist der Körper, der Loop ist sein Herzschlag.