Wörterbuch der KI

Eine bewegliche Bezeichnung, keine Technologie. „KI“ benennt nichts Festes wie Modell oder Token – sie verweist darauf, was Computer gerade neu und beeindruckend können. Momentan meint sie große Sprachmodelle. Früher hat sie ganz andere Dinge bezeichnet:

Der Verweis verschiebt sich durch einen bekannten Mechanismus, manchmal KI-Effekt genannt: Sobald eine Technik zuverlässig funktioniert, wird sie umbenannt – es ist „nur“ Suche, „nur“ Statistik –, und „KI“ rückt zum nächsten ungelösten Problem vor. Die Beobachtung ist alt. Bertram Raphael formulierte es 1971 so: „KI ist eine Sammelbezeichnung für Probleme, von denen wir noch nicht wissen, wie wir sie mit einem Computer richtig lösen.“ Larry Teslers Version von ungefähr 1979: „Intelligenz ist alles, was Maschinen noch nicht getan haben.“

Deshalb reden Gespräche über KI so oft aneinander vorbei. Eine Behauptung wie „KI kann nicht schlussfolgern“ oder „KI wird überbewertet“ trägt einen verborgenen Zeitstempel – sie kann sich auf Expertensysteme, Bildklassifikatoren der 2010er oder das LLM vom letzten Monat beziehen, und jeder Bezug stützt eine andere Schlussfolgerung. Stockt eine KI-Diskussion, hilft es meist, das Wort durch den genauen Begriff zu ersetzen, der tatsächlich gemeint ist: das Modell, die Harness, der Agent, der ihm gegebene Kontext.

Vermeiden: „KI“ in jeder technischen Behauptung – benenne stattdessen den gemeinten Bestandteil. „Programmieren mit KI“ als Bezeichnung der Praxis ist in Ordnung; „die KI halluziniert“ ist es nicht.

Verwendung:

„Die CTO möchte wissen, ob KI die Triage-Warteschlange übernehmen könnte.“

„Übersetze das, bevor du den Umfang festlegst – sie meint ein LLM in einer Harness mit Zugriff auf das Ticketsystem. ‚KI‘ allein ist keine Spezifikation.“

Die Parameter. Zustandslos – führt die Vorhersage des nächsten Tokens aus und sonst nichts. „Claude Opus 4.x“ und „GPT-5.x“ sind Modelle. Für sich allein kann ein Modell nichts Agentisches tun; es muss mit einer Harness ausgestattet werden.

Modelle können keine Dateien lesen, Befehle ausführen, im Web surfen oder sich an gestern erinnern – ein Modell nimmt Tokens auf und sagt Tokens voraus, einmal pro Anfrage an den Modellanbieter. Alles, was sich wie ein arbeitender Agent anfühlt – Tools auswählen, Ergebnisse lesen, bis zum Aufgabenabschluss weiterarbeiten –, ist die Harness, die viele dieser Vorhersagen nacheinander orchestriert.

Modellanbieter liefern Modelle in Stufen: ein großes, das am klügsten, aber langsam und teuer ist, und kleinere, die schneller und günstiger, aber weniger leistungsfähig sind. Die Stufenwahl ist eine echte Entscheidung – Schwergewicht für Planung und schwierige Fehlersuche, Leichtgewicht für mechanische Änderungen –, und Harnesses erlauben einen Wechsel mitten in der Sitzung.

Ein präziser Umgang mit dem Wort schärft auch die Diagnose. „Das Modell ist darin schlecht“ ist eine konkrete Behauptung – dasselbe Modell verhält sich in einer anderen Harness oder mit anderem Kontext oft völlig anders. Bevor du dem Modell die Schuld gibst, prüfe, was es erhalten hat: Die meisten enttäuschenden Ausgaben gehen auf Kontext oder Harness zurück, nicht auf Parameter.

Verwendung:

„Sollten wir für den Planungsschritt das Modell von Sonnet auf Opus wechseln?“

„Probier es – aber bei dieser Aufgabe leistet die Harness den Großteil der Arbeit. Der Modellwechsel hilft nicht, wenn Systemprompt und Tools falsch sind.“

Die Zahlen in einem Modell – oft Milliarden davon –, die während des Trainings abgestimmt werden. Alles, was das Modell „weiß“, steckt darin. Training setzt sie; Inferenz nutzt sie unverändert. Auch Gewichte genannt.

Mechanisch verwandeln die Parameter Eingabe in Ausgabe. Die Vorhersage des nächsten Tokens ist eine riesige Berechnung: Die Tokens aus dem Kontextfenster gehen hinein, werden durch die Parameter multipliziert, und eine Vorhersage für das nächste Token kommt heraus. Im Modell gibt es keine Faktendatenbank und keine Code-Nachschlagetabelle – nur diese Zahlen, so angeordnet, dass die Berechnung tendenziell nützliche Ausgaben erzeugt. Fakten, die das Modell aus dem Training aufsagen kann, etwa eine Standardbibliotheks-API, sind parametrisches Wissen: in den Parametern gespeichert, nicht von irgendwo abgerufen.

Wichtig zu verinnerlichen ist, dass Parameter nach dem Training eingefroren sind. Nichts, was du in einer Sitzung tust, ändert sie – keine Korrektur, keine gezeigte Codebasis, kein Fehler, aus dem es lernt. Jede Sitzung läuft mit denselben Zahlen. Deshalb ist das Modell zustandslos, deshalb endet sein eingebautes Wissen am Wissensstichtag, und deshalb muss alles Projektspezifische stattdessen über Kontext eintreffen. Parameter ändern sich nur durch weiteres Training – das im Ergebnis ein anderes Modell erzeugt.

Verwendung:

„Können wir es auf unsere Codebasis feinabstimmen?“

„Das würde die Parameter aktualisieren – danach wäre es ein anderes Modell. Für ein einzelnes Projekt ist es fast immer günstiger, die Codebasis als Kontext zu laden, statt neu zu trainieren.“

Der Prozess, der die Parameter eines Modells setzt, indem er es enormen Textmengen aussetzt und die Parameter zur Verbesserung der Vorhersage des nächsten Tokens anpasst. Ein einmaliger, teurer Prozess beim Modellanbieter. Umfasst sowohl Vortraining (den großen Hauptlauf) als auch Nachtraining (spätere Verfeinerungen wie Anweisungsbefolgung und Sicherheit); auf der Ebene dieses Glossars ist die Unterscheidung unwichtig.

Der Mechanismus ist Wiederholung im großen Maßstab: Zeige dem Modell einen Textabschnitt, lass es das nächste Token vorhersagen, verschiebe die Parameter in Richtung des tatsächlichen nächsten Tokens und wiederhole das über Billionen Tokens. Nichts wird als Fakten oder Regeln gespeichert – alles, was das Modell „weiß“, ist ein Nebeneffekt verbesserter Vorhersage, als parametrisches Wissen in die Parameter komprimiert.

Im Alltag zählen zwei Folgen. Training endet zu einem bestimmten Zeitpunkt, deshalb hat das Modell einen Wissensstichtag – es hat die Bibliotheksversion nicht gesehen, auf die du letzten Monat aktualisiert hast. Und Training ist nichts, was du selbst durchführen kannst: Kennt das Modell deine Codebasis, Konventionen oder internen APIs nicht, lautet die Lösung nie „dem Modell beibringen“, sondern dieses Material in den Kontext zu legen, die eine Eingabe, die du kontrollierst.

Verwendung:

„Können wir dafür sorgen, dass es unsere interne API kennt?“

„Nicht durch Training – das ist ein monatelanger Prozess beim Modellanbieter. Lade stattdessen die API-Dokumentation in den Kontext, das ist der Hebel, den du tatsächlich hast.“

Ein trainiertes Modell ausführen, um eine Ausgabe zu erzeugen – das geschieht bei jeder Anfrage an den Modellanbieter. Die Parameter bleiben unverändert; das Modell führt nur die Vorhersage des nächsten Tokens über den gegebenen Kontext aus. Im Vergleich zum Training günstig, aber pro Token abgerechnet und der dominierende Kostenfaktor bei der Modellnutzung.

Das Leben eines Modells teilt sich in zwei Phasen:

Nichts, was du während der Inferenz tust, schreibt in die Parameter zurück – deshalb bleibt eine heutige Korrektur morgen nicht bestehen. Das Modell, das in der nächsten Sitzung denselben Fehler macht, nachdem du die Lösung sorgfältig erklärt hast, hat dich nicht ignoriert; es kann aus dem Austausch nicht lernen. Das Modell ist zustandslos – Kontinuität muss von außen kommen, aus dem Kontextfenster oder einem Gedächtnissystem.

Dieser Mechanismus erklärt auch die Abrechnung. Jede Anfrage führt das Modell über den gesamten Kontext aus, deshalb steigen die Kosten mit Eingabe-Tokens und Ausgabe-Tokens. Ein Agent mit Dutzenden Toolaufrufen bezahlt bei jedem Hin- und Rückweg für Inferenz. Deshalb ist Kontextgröße ebenso eine Kosten- wie eine Qualitätsfrage.

Verwendung:

„Warum steigt die Rechnung mit der Nutzung, statt eine pauschale Lizenz zu sein?“

„Du bezahlst für Inferenz – jede Anfrage an den Modellanbieter führt das Modell auf dessen Hardware aus. Das Training ist bereits erfolgt, aber Inferenzkosten entstehen pro Anfrage, und ein einzelner Gesprächsschritt kann sich bei Toolaufrufen in viele Anfragen auffächern.“

Denkaufwand ist ein Regler dafür, wie viel ein Modell schlussfolgert, bevor es antwortet. Er wird pro Anfrage an den Modellanbieter eingestellt und steuert die Länge des Denkprozesses, den das Modell durchläuft, bevor es die sichtbare Antwort schreibt. Dieses Denken wird wie alles andere während der Inferenz erzeugt; die Harness verbirgt es häufig, aber es ist echte Arbeit des Modells.

Höherer Denkaufwand kostet mehr und ist langsamer. Die Überlegungen werden als Tokens ausgegeben, selbst wenn du sie nie siehst als Ausgabe-Tokens abgerechnet und Token für Token erzeugt – mehr Denkaufwand verlängert also die Wartezeit auf die Antwort und erhöht die Rechnung. Die Abwägung besteht zwischen mehr Überlegung sowie Geschwindigkeit und Kosten.

Die meisten Harnesses bieten den Denkaufwand in wenigen Stufen an:

Eine falsche Einstellung zeigt sich in beide Richtungen. Ist der Denkaufwand bei einem schwierigen Problem zu niedrig, erhältst du eine selbstsichere, oberflächliche Antwort, die die nötigen Überlegungen übersprungen hat – sie liest sich gut und ist auf eine Weise falsch, die später Kosten verursacht. Stellst du ihn für eine einzeilige Umbenennung auf maximal, wartest du auf langes Nachdenken, das nichts liefert, was nicht auch die niedrigste Einstellung geliefert hätte.

Passe den Denkaufwand an die Aufgabe an, nicht an die Sitzung. Erhöhe ihn für den Teil, der wirklich schwer zu durchdenken ist, und senke ihn wieder für die Routinearbeit drumherum.

Verwendung:

„Er verpatzt diese Nebenläufigkeitskorrektur ständig – ich habe sie dreimal neu erklärt.“

„Erhöhe den Denkaufwand. Das ist ein Fehler, der viel Schlussfolgern erfordert, und mit der Standardeinstellung denkt er nicht lange genug nach, bevor er sich auf einen Ansatz festlegt.“

Die kleinste Einheit, die ein Modell liest und schreibt. Ungefähr wortgroß, aber nicht genau – häufige Wörter sind ein Token, seltene oder lange zerfallen in mehrere. Größe des Kontextfensters, Kosten und Latenz werden alle in Tokens gezählt.

Text wird durch einen Tokenizer zu Tokens: ein festes Vokabular aus Zehntausenden Fragmenten, das vor dem Training gelernt wurde und jede Eingabe in eine Folge von Vokabulareinträgen zerlegt. Das Modell sieht nie Zeichen oder Wörter – jeder Text wird beim Eingang in Tokens umgewandelt, und die Vorhersage des nächsten Tokens erzeugt beim Ausgang die Ausgabe Token für Token.

Als Faustregel entspricht ein Token etwa drei Vierteln eines englischen Wortes, tausend Tokens sind also ungefähr 750 Wörter. Code ist weniger vorhersehbar: Häufige Schlüsselwörter und Idiome werden kompakt tokenisiert, während generierte Bezeichner, Hashes, Base64-Blöcke und minimierte Ausgaben in viele Tokens pro „Wort“ zerfallen. Das Muster: Text, der im Ausgangsmaterial des Tokenizers oft vorkam, erhält kurze, effiziente Kodierungen; anderer Text wird in viele kleine Stücke zerlegt. Ein Hash wie `a3f9c2e1` kam nirgendwo vor und zerfällt daher in viele Tokens, während `function` eines ist. Deshalb kann eine klein wirkende Datei voller ungewöhnlicher Zeichenfolgen einen überraschend großen Teil des Kontextfensters belegen.

Tokens sind die Einheit, in der alles andere gemessen wird. Kosten fallen pro Token an – Anbieter rechnen Eingabe-Tokens und Ausgabe-Tokens getrennt ab. Geschwindigkeit bedeutet Tokens pro Sekunde, weil die Ausgabe Token für Token entsteht. Und das Kontextfenster hat eine feste Tokenzahl; die Tokenzahl deiner Dateien entscheidet also, wie viel hineinpasst.

Vermeiden: „Wort“ – Tokengrenzen entsprechen nicht Wortgrenzen, und Tokens pro Sekunde beziehungsweise pro Dollar sind die tatsächlich wichtigen Einheiten.

Verwendung:

„Wie groß wird dieser Prompt?“

„Lass ihn durch den Tokenizer laufen – das Schema ist kompakt, aber die JSON-Schlüssel sind ungewöhnlich und werden deshalb in mehr Tokens zerfallen, als du denkst.“

Was das Modell tatsächlich tut. Bei gegebenem Kontext zieht es ein nächstes Token, hängt es an und läuft erneut. Jede Ausgabe – ein Satz, ein Toolaufruf, eine tausendzeilige Datei – wird Token für Token aufgebaut. Das Modell hat keine andere Arbeitsweise.

Jeder Schritt funktioniert gleich: Die Tokens im Kontextfenster laufen durch die Parameter, die eine Wahrscheinlichkeit für jedes Token im Vokabular erzeugen – dieses kommt als Nächstes sehr wahrscheinlich, jenes weniger. Aus diesen Wahrscheinlichkeiten wird ein Token gezogen, angehängt, und die Schleife läuft mit dem etwas längeren Kontext erneut. Dieser Auswahlschritt erklärt, warum derselbe Prompt bei verschiedenen Läufen unterschiedliche Ausgaben erzeugt: Nichtdeterminismus ist in den Mechanismus eingebaut, kein nachträglich aufgesetzter Fehler.

Diesen Mechanismus im Blick zu behalten erklärt sonst seltsam wirkendes Verhalten. Das Modell prüft vor der Ausgabe nie, ob ein Token wahr ist – nur, ob es wahrscheinlich ist. Das ist die Wurzel der Halluzination. Es legt sich unterwegs auf jedes Token fest, sodass ein selbstsicher klingender Eröffnungssatz den Rest der Antwort in die falsche Richtung lenken kann. Und weil Ausgabe-Tokens strikt einzeln erzeugt werden, setzt die Generierungsgeschwindigkeit der Arbeitsgeschwindigkeit jedes Agenten eine Untergrenze für die benötigte Zeit.

Verwendung:

„Wie ‚entscheidet‘ der Agent, ein Tool aufzurufen?“

„Gar nicht – es ist durchgehend die Vorhersage des nächsten Tokens. Der Toolaufruf ist nur eine strukturierte Zeichenfolge, die die Harness aus dem Ausgabestrom herausliest.“

Dieselbe Eingabe kann unterschiedliche Ausgaben erzeugen. Führe ein Modell zweimal mit identischem Kontext aus, und du erhältst möglicherweise zwei verschiedene Antworten – manchmal ein anderes Wort, manchmal einen völlig anderen Ansatz. Dafür muss sich an deinem Code nichts ändern.

Das liegt daran, wie Modelle Text erzeugen und wie Modellanbieter Anfragen bedienen. Während der Inferenz erzeugt das Modell eine Wahrscheinlichkeitsverteilung über mögliche nächste Tokens, aus der eines gezogen wird – normalerweise absichtlich mit etwas Zufall, denn immer das wahrscheinlichste Token zu wählen ergibt repetitive, qualitativ schlechtere Texte. Ein früh in der Antwort anders gezogenes Token verändert jedes folgende; so wird aus einem einzelnen anderen Wort ein völlig anderer Ansatz. Die Bereitstellung beim Anbieter fügt weitere Schwankungen hinzu: Anfragen werden auf gemeinsamer Hardware zu Batches gebündelt, und winzige Gleitkommaunterschiede zwischen Batches können bei zwei nahezu gleichauf liegenden Tokens den Ausschlag geben. Es gibt keine Einstellung, mit der du all das vollständig abschalten kannst.

Erwarte bei derselben Aufgabe eine Streuung der Ergebnisse eines Agenten. Die meisten Antworten liegen innerhalb einer vernünftigen Qualitätsglockenkurve – deshalb ist der Nichtdeterminismus überhaupt erträglich –, aber die Ränder sind real: An manchen Tagen wirkt das Modell scharf, an anderen, als hätte es den Faden verloren. Dieselbe Aufgabe, andere Würfelwürfe. Daraus ergeben sich zwei praktische Folgen. Ein neuer Versuch ist eine legitime Strategie: Ein fehlgeschlagener Versuch ist eine Ziehung aus der Verteilung, und ein neuer Versuch derselben Aufgabe kann schlicht besser ausfallen. Außerdem ist Verifikation wichtiger als bei deterministischen Tools – du kannst das Verhalten eines Agenten nicht einmal testen und auf Wiederholung vertrauen; automatisierte Prüfungen müssen deshalb schlechte Ziehungen erkennen.

Hüte dich davor, zu große Geschichten daraus zu machen. Menschen sind Mustererkennungsmaschinen, und eine Reihe schlechter Läufe kann wie ein Beweis wirken, dass „das Modell diese Woche schlechter geworden ist“. Meist ist es nur die Verteilung.

Verwendung:

„Claude ist heute furchtbar. Haben sie eine schlechtere Version veröffentlicht?“

„Wahrscheinlich nicht – Modellausgaben sind nichtdeterministisch. Bei derselben Aufgabe wird es gute und schlechte Tage geben. Versuch es morgen noch einmal, bevor du nach einer Ursache suchst.“

Alles, was ein Modell für Inferenz bereitstellt. Meist ein entfernter Dienst (Anthropic, OpenAI, Google), aber auch lokal möglich – Ollama, LM Studio, llama.cpp auf deinem eigenen Rechner. Die Harness führt das Modell nicht selbst aus; sie bittet einen Anbieter darum.

Der Anbieter besitzt die Maschinerie: Die Parameter liegen auf seiner Hardware, und bei jeder Anfrage an den Modellanbieter sendet die Harness Tokens über das Netzwerk und erhält Vorhersagen zurück. Damit ist der Anbieter die Quelle einer ganzen Problemkategorie, die fälschlich dem Modell oder der Harness zugeschrieben wird – Ratenbegrenzungen, verminderte Kapazität und Ausfälle liegen alle hier. Stockt der Agent mitten in der Sitzung oder meldet bei jedem Gesprächsschritt Fehler, lohnt sich vor allem anderen ein Blick auf die Statusseite des Anbieters.

Der Anbieter bestimmt auch die Geschäftsbedingungen: Preise pro Token für Eingabe und Ausgabe-Tokens, Rabatte für den Präfixcache und die überhaupt verfügbaren Modelle. Anbieter und Modellhersteller können verschiedene Unternehmen sein – Bedrock, Vertex und OpenRouter stellen die Modelle anderer bereit.

Lokale Anbieter tauschen Leistungsfähigkeit gegen Kontrolle: Modelle, die auf deine eigene Hardware passen, sind viel kleiner als Spitzenmodelle, aber nichts verlässt den Rechner, und es gibt keine Rechnung pro Token.

Verwendung:

„Können wir das für den vollständig abgeschotteten Kunden offline ausführen?“

„Wechsle zu einem lokalen Modellanbieter – Ollama oder llama.cpp auf dessen Rechner. Der Harness ist das egal, sie spricht nur einen anderen Endpunkt an.“

Alles um das Modell herum, das es zu einem Agenten macht: Tools, Systemprompt, Kontextfensterverwaltung, Berechtigungen, Hooks. Claude.ai und Claude Code laufen mit demselben Modell, verhalten sich aber unterschiedlich, weil sich ihre Harnesses unterscheiden.

Das Modell selbst tut nur eines: Text aufnehmen und Text ausgeben. Es kann keine Datei lesen, keinen Befehl ausführen und sich nicht an den letzten Gesprächsschritt erinnern. All das liefert die Harness. Sie stellt den Kontext für jede Anfrage an den Modellanbieter zusammen, führt die vom Modell angeforderten Toolaufrufe aus, speist die Toolergebnisse zurück ein, speichert den Sitzungsverlauf, fragt dich vor riskanten Aktionen um Erlaubnis und entscheidet, wann komprimiert wird. Die Agentenschleife – Modell schlägt vor, Harness führt aus, wiederholen – wird von der Harness ausgeführt.

Das ist für die Diagnose wichtig. Unterscheidet sich das Verhalten zweier Produkte oder zwischen gestern und heute, ist oft nicht das Modell die Variable, sondern die Harness. Ein anderer Systemprompt, ein anderer Toolsatz, eine geänderte Standardberechtigung oder eine neue Kontextverwaltungsstrategie verändern das Verhalten, ohne das Modell zu ändern. Außerdem liegt deshalb der Großteil deiner Konfiguration in der Harness: AGENTS.md-Dateien, Berechtigungseinstellungen und Hooks sind alles Anweisungen an die Harness, nicht an das Modell.

Beispiele: Claude Code, Cursor, Codex CLI – und Claude.ai, eine Chat-Harness statt einer Programmier-Harness.

Verwendung:

„Dasselbe Modell, warum bearbeitet Claude Code Dateien und beantwortet Claude.ai nur Fragen?“

„Unterschiedliche Harnesses – Claude Code hat Dateisystem-Tools, einen anderen Systemprompt und eine Berechtigungsschicht. Das Modell ist hier nicht die Variable.“

Ein Hin- und Rückweg von der Harness zum Modellanbieter. Die Harness sendet den aktuellen Kontext; der Anbieter liefert eine Antwort zurück (einen Toolaufruf oder eine endgültige Antwort). Eine einzige Nutzernachricht kann viele Anfragen an den Modellanbieter auslösen, wenn der Agent Tools aufruft – jedes Toolergebnis löst eine weitere Anfrage aus.

Jede Anfrage enthält alles: den Systemprompt, das gesamte bisherige Gespräch, jedes Toolergebnis. Das Modell ist zustandslos, deshalb behält der Anbieter zwischen Anfragen nichts – Anfrage vierzig sendet erneut, was Anfrage neununddreißig gesendet hat, plus ein weiteres Toolergebnis. Der Präfixcache macht diese Wiederholung bezahlbar.

Die Anfrage ist auch die Abrechnungseinheit. Eingabe-Tokens, Ausgabe-Tokens und Cacherabatte werden pro Anfrage gezählt. Deshalb kann eine harmlos wirkende Frage überraschend viel kosten: Die Kosten sind nicht proportional zu deiner Nachricht, sondern zur Zahl der Anfragen multipliziert mit der Kontextgröße jeder Anfrage.

Es lohnt sich, Anfrage und Gesprächsschritt auseinanderzuhalten. Ein Gesprächsschritt ist ein Austausch mit dir, und ein einzelner Schritt – „repariere den fehlschlagenden Test“ – läuft als Kette von Anfragen ab:

Sechs Anfragen für einen Gesprächsschritt – jede sendet den gesamten Kontext erneut. Wenn du dich fragst, wo die Tokens geblieben sind, zähle die Anfragen, nicht die Gesprächsschritte.

Verwendung:

„Eine Frage hat vierzigtausend Tokens verbraucht?“

„Schau auf die Toolaufrufe – zwölf grep, acht Lesevorgänge, vier Änderungen. Jedes Toolergebnis erzeugt eine weitere Anfrage an den Modellanbieter, und jedes Mal wird das vollständige Sitzungspräfix erneut gesendet.“

Tokens, die die Harness bei jeder Anfrage an den Modellanbieter sendet – Systemprompt, Gesprächsverlauf, Toolergebnisse, alles, was das Modell vor dem Schreiben liest. Günstiger abgerechnet als Ausgabe-Tokens, weil ihre Verarbeitung weniger kostet als die von Ausgabe-Tokens.

Beim Programmieren mit KI machen Eingabe-Tokens den Großteil deiner Rechnung aus. Das Modell ist zustandslos, deshalb sendet jeder Gesprächsschritt die gesamte Sitzung erneut als Eingabe: deine erste Nachricht, jede Antwort, jedes Toolergebnis seitdem. Die Eingabe für Schritt fünfzig enthält die vorigen neunundvierzig Schritte. Eine einzelne Anfrage an den Modellanbieter kann einige Hundert Ausgabe-Tokens erzeugen, aber hunderttausend Eingabe-Tokens angesammelten Verlaufs erneut senden.

Der Präfixcache senkt die Kosten: Verlauf, der exakt zu einer früheren Anfrage passt, wird als günstige Cache-Tokens statt als Eingabe zum vollen Preis abgerechnet. Tun die Eingabekosten weiterhin weh, verkleinere das erneut Gesendete – durch Leeren oder Komprimieren zwischen Aufgaben.

Verwendung:

„Die Rechnung ist hoch, aber der Agent schreibt kaum etwas.“

„Das sind die Eingabe-Tokens – jeder Gesprächsschritt sendet die ganze Sitzung erneut. Ohne Präfixcache bezahlst du den Verlauf bei jeder Anfrage neu.“

Tokens, die das Modell zurückgeneriert. Teurer abgerechnet als Eingabe-Tokens – häufig etwa zum fünffachen Preis –, weil ihre Erzeugung mehr Rechenleistung kostet.

Alles Geschriebene zählt: die Prosa, die du liest, der ausgegebene Code, Toolaufrufe und jedes längere Nachdenken vor der Antwort. Letzteres überrascht viele – Denktokens werden als Ausgabe abgerechnet, auch wenn die Harness sie oft nicht anzeigt, und höherer Denkaufwand verbraucht mehr davon.

Ausgabe-Tokens bestimmen auch das Tempo einer Sitzung. Das Modell liest Eingaben schnell, erzeugt die Ausgabe aber Token für Token. Fühlt sich ein Gesprächsschritt langsam an, wird fast immer gerade Ausgabe geschrieben und nicht Eingabe gelesen. Langes Warten bedeutet meist, dass eine lange Antwort kommt.

Verwendung:

„Die Refaktorierungssitzung verbraucht rasant Guthaben, obwohl die Eingaben klein sind.“

„Der Agent schreibt ganze Dateien neu, statt sie gezielt zu ändern. Ausgabe-Tokens kosten ungefähr das Fünffache des Eingabepreises – lass ihn Änderungen ausgeben, dann sinkt die Rechnung.“

Der anbieterseitige Speicher des Modellanbieters, durch den aufeinanderfolgende Anfragen an den Modellanbieter die erneute Verarbeitung eines gemeinsamen Präfixes überspringen können. Wenn der Anfang einer Anfrage mit dem Anfang einer kürzlich gestellten übereinstimmt – derselbe Systemprompt, derselbe Verlauf bis zu einem bestimmten Punkt –, nutzt der Anbieter seine frühere Arbeit erneut und rechnet diese Tokens als Cache-Tokens zu einem deutlich niedrigeren Preis ab.

Der Cache lohnt sich, weil Sitzungen nur durch Anhängen wachsen. Jede Anfrage sendet den gesamten Verlauf erneut als Eingabe-Tokens (warum, erklärt jener Eintrag), und in einer normalen Sitzung ändert sich der Verlauf nur am Ende – jede Anfrage ist die vorige plus ein paar neue Nachrichten. Der Anbieter verarbeitet den langen gemeinsamen Anfang einmal, speichert das Ergebnis und setzt am Ende des Präfixes fort. Ohne Cache würde eine Sitzung mit 50 Gesprächsschritten fünfzigmal für die erneute Verarbeitung des ersten Schritts bezahlen.

Caches laufen auch ab. Wie lange ein Eintrag warm bleibt, hängt vom Modellanbieter ab – meist Minuten, nicht Stunden. Bleibt eine Sitzung länger als dieses Zeitfenster untätig, baut die nächste Anfrage das Präfix einmal zum vollen Preis neu auf, bevor das Caching weitergeht. Das betrifft vor allem Entwickler von Harnesses; für dich als Nutzer ist sichtbar, dass Anfragen nach einer langen Pause mehr kosten als die davor.

Verwendung:

„Warum ist die Rechnung mitten in der Sitzung hochgeschnellt?“

„Die Harness hat angefangen, bei jedem Gesprächsschritt die aktuelle Uhrzeit in den Systemprompt einzufügen. Der Präfixcache bricht am ersten geänderten Token ab, also wurde danach jede Anfrage zum vollen Preis abgerechnet.“

Eingabe-Tokens, die der Anbieter aus einer früheren Anfrage an den Modellanbieter zwischengespeichert hat, damit er sie nicht erneut verarbeiten muss. Teilen aufeinanderfolgende Anfragen ein Präfix, nutzt der Anbieter die Arbeit über seinen Präfixcache erneut und rechnet den zwischengespeicherten Teil deutlich günstiger ab. Der Hebel, der lange Sitzungen bezahlbar macht – ohne ihn bezahlt jeder Gesprächsschritt den ganzen Verlauf erneut.

Warum das zählt, liegt an der Sitzungsabrechnung. Das Modell ist zustandslos, deshalb sendet jede Anfrage das gesamte Gespräch erneut als Eingabe-Tokens – Systemprompt, jede Nachricht, jedes Toolergebnis. Bei Gesprächsschritt fünfzig enthält jede Anfrage den Verlauf von fünfzig Schritten, und du würdest jedes Mal für alles den vollen Preis zahlen. Der Cache verändert die Rechnung: Tokens, die der Anbieter in einem identischen Präfix bereits verarbeitet hat, werden als Cache-Tokens abgerechnet, oft zu einem Zehntel des Eingabepreises oder weniger. In einer langen Sitzung besteht das meiste Gesendete aus Cache-Tokens, und die Rechnung bleibt vernünftig.

Ein Beispiel zeigt, wann Tokens zwischengespeichert werden und wann nicht. Jeder Buchstabe steht für einen Block Gesprächsinhalt; jede Anfrage sendet das bisherige Gespräch:

Der Cache ist auf eine bestimmte Weise empfindlich: Er gleicht exakte Präfixe ab. Ändert sich etwas früher im Gespräch – die Harness sortiert Inhalte um, ein Zeitstempel wird aktualisiert, die Darstellung einer Datei verschiebt sich –, greift der Cache ab diesem Punkt nicht mehr, und alles danach wird zum vollen Eingabepreis abgerechnet. Caches laufen außerdem nach einigen Minuten Inaktivität ab; nach einer langen Pause bezahlt eine fortgesetzte Sitzung ihren Verlauf daher einmal neu. Springen die Sitzungskosten ohne offensichtliche Ursache, vergleiche Cache-Tokens und Eingabe-Tokens im Nutzungsbericht – dort zeigt sich ein kaputter Cache zuerst.

Verwendung:

„Lange Sitzungen kosten brutal viel – acht Dollar für eine Refaktorierung.“

„Prüfe die Cache-Tokens. Wenn die Harness zwischen Gesprächsschritten den Systemprompt oder Dateien umsortiert, bricht das Präfix, und du bezahlst bei jeder Anfrage erneut den vollen Eingabepreis.“

Trägt keine Informationen weiter. Das Modell ist über Anfragen an den Modellanbieter hinweg zustandslos – jede Anfrage sendet das vollständige Kontextfenster erneut, weil das Modell nichts anderes sehen kann. Ein Agent ist standardmäßig über Sitzungen hinweg zustandslos: Eine neue Sitzung beginnt leer und ohne Spuren vorheriger Sitzungen. Gegenstück zu zustandsbehaftet.

Das Modell selbst ist dauerhaft zustandslos: Seine Parameter sind nach dem Training eingefroren, und nichts, was du bei der Inferenz tust, verändert sie. Das Modell lernt nicht aus deinen Korrekturen, erinnert sich nicht daran, gestern dasselbe gesagt bekommen zu haben, und lernt dich nicht kennen – so sehr sich das Gespräch auch anders anfühlen mag. Das Gefühl von Kontinuität innerhalb einer Sitzung erzeugt die Harness, die das Transkript behält und bei jeder Anfrage erneut sendet. Das Modell erinnert sich nicht an das Gespräch; es liest es erneut.

Die praktische Folge: Wenn etwas über Sitzungen hinweg erinnert werden soll, musst du es dort aufschreiben, wo der Agent es wieder lesen wird. Genau das sind AGENTS.md-Dateien, Gedächtnissysteme und Übergabeartefakte – Dateien, die in den Kontext künftiger Sitzungen geladen werden und das Gedächtnis ersetzen, das dem Modell fehlt. Macht der Agent weiterhin einen Fehler, den du bereits korrigiert hast, lautet die Frage nicht, warum er nicht gelernt hat – das kann er nicht –, sondern wo diese Korrektur aufgeschrieben werden sollte, damit jede spätere Sitzung sie liest.

Verwendung:

„Warum vergisst er die Konvention jedes Mal, wenn ich leere?“

„Das Modell ist zustandslos – die neue Sitzung beginnt leer. Soll die Information mitgenommen werden, schreibe sie in AGENTS.md oder eine Gedächtnisdatei, die die Harness zu Sitzungsbeginn lädt.“

Die relevanten Informationen, auf die der Agent gerade zugreifen kann. Der abstrakte Begriff – nicht die rohe Eingabe, die das Modell sieht (das ist das Kontextfenster), nicht der laufende Verlauf (das ist die Sitzung), sondern das aufgabenrelevante Wissen des Agenten. „Etwas in den Kontext laden“ bedeutet, es zu einem Teil dieser Menge zu machen; „Kontext-Engineering“ ist die Disziplin, sie gezielt zusammenzustellen.

Die drei Begriffe lassen sich klar trennen:

Die Trennung ist wichtig, weil Kontext Qualität misst, nicht Quantität. Ein Kontextfenster kann fast voll und der Kontext trotzdem schlecht sein – Tausende Tokens veralteter Toolausgaben, die nichts mit der aktuellen Aufgabe zu tun haben. Es kann auch fast leer und der Kontext ausgezeichnet sein: die eine Typdefinition, von der die Aufgabe abhängt.

Die meisten alltäglichen Fehler gehen auf Kontext zurück. Erfindet der Agent eine API, widerspricht einer Entscheidung oder rät bei einem Schema, lautet die erste Frage, was dabei im Kontext stand – meist wurde die relevante Tatsache nie geladen oder unter Aufmerksamkeitsverlust begraben. Die Lösung ist gezielte Auswahl: Lade, was die Aufgabe braucht, und halte fern, was sie nicht braucht.

Verwendung:

„Er erfindet ständig Felder, die nicht im Typ stehen.“

„Die Typdatei ist nicht im Kontext – er liest die Aufrufstellen und rät. Lies zuerst die Definition ein.“

Alles, was das Modell bei jeder Anfrage an den Modellanbieter sieht. Endlich, modellspezifisch und die einzige Oberfläche, über die das Modell überhaupt etwas wahrnimmt.

Es ist eine einzige Folge von Tokens: der Systemprompt, das bisherige Gespräch, jedes Toolergebnis, das die Harness zurück eingespeist hat. Steht etwas in dieser Folge, kann das Modell es nutzen; steht es nicht darin, weiß das Modell nicht, dass es existiert – weder deine Codebasis noch die gestern bearbeitete Datei noch die Anweisung von vor drei Sitzungen. Alles außerhalb des Fensters muss hereingeholt werden, meist durch einen Toolaufruf, bevor es etwas beeinflussen kann.

Endlich bedeutet, dass es voll wird. Jeder Gesprächsschritt fügt mehr hinzu – deine Nachrichten, die Antworten des Modells, Toolergebnisse –, und eine lange Sitzung erreicht irgendwann die Grenze und erzwingt Komprimierung oder Leeren. Es bedeutet auch, dass alles im Fenster konkurriert: Jedes geladene Token steht für den Rest nicht mehr zur Verfügung, und auch unnötige Inhalte beanspruchen die Aufmerksamkeit des Modells. Behandle das Fenster praktisch als Budget – lade, was die Aufgabe braucht, und lass den Rest draußen.

Vermeiden: „Gedächtnis“ – das Kontextfenster ist Arbeitszustand und bleibt nicht über Sitzungen hinweg erhalten. Gedächtnis ist ein eigener, darauf aufgesetzter Begriff.

Verwendung:

„Kann ich einfach das ganze Monorepo in den Prompt kopieren?“

„Das Kontextfenster hat 200k Tokens – das ist vielleicht ein Fünftel des Repositorys. Wähle die Dateien, die die Aufgabe betrifft, und lass den Rest hinter einem Toolaufruf.“

Trägt Informationen weiter. Eine Sitzung ist über Gesprächsschritte hinweg zustandsbehaftet – während sie läuft, sammelt sich Kontext an, weshalb lange Sitzungen in die dumme Zone driften. Ein Agent kann über Sitzungen hinweg zustandsbehaftet gemacht werden, indem man ein Gedächtnissystem hinzufügt, das Informationen in der Umgebung speichert und zu Beginn späterer Sitzungen neu lädt. Das Modell ist niemals zustandsbehaftet; jede scheinbare Kontinuität entsteht dadurch, dass die Harness Kontext erneut zuführt. Gegenstück zu zustandslos.

Wo der Zustand auf den einzelnen Ebenen lebt:

Die Zustandsbehaftung jeder Ebene entsteht durch erneutes Lesen von etwas, das eine Ebene darunter gespeichert ist: Die Sitzung fühlt sich kontinuierlich an, weil die Harness den Nachrichtenverlauf erneut an das zustandslose Modell sendet, und der Agent erinnert sich über Sitzungen hinweg, weil die Harness Dateien aus der Umgebung neu lädt. Im Modell selbst wird niemals ein Zustand gespeichert.

Zustand ist nicht immer erwünscht. Alles Weitergetragene beeinflusst das Folgende, also wird auch eine früh in einer Sitzung getroffene falsche Annahme mitgenommen. Leeren bedeutet, den Sitzungszustand bewusst wegzuwerfen und von dem auszugehen, was aufgeschrieben ist.

Verwendung:

„Er hat sich meine Vorlieben von gestern gemerkt – heißt das, das Modell hat sie gelernt?“

„Nein, der Agent ist zustandsbehaftet, weil die Harness sie in eine Gedächtnisdatei geschrieben und zu Sitzungsbeginn neu geladen hat. Das Modell selbst hat nichts von gestern gesehen.“

Ein Modell, das durch eine Harness mit Tools, einem Systemprompt und einem Kontextfenster ausgestattet ist und mit einem Nutzer Gesprächsschritte austauscht. Claude Code ist ein Agent. Cursor ist ein Agent. Claude.ai ist ein Agent. Ein Agent ist das, womit du tatsächlich sprichst – das Modell in Aktion, für einen Zweck konfiguriert.

Anders als die meisten Begriffe in diesem Wörterbuch bezeichnet „Agent“ kein mechanisches Bauteil. Das Modell ist eine Datei mit Parametern; die Harness ist Software, auf die man zeigen kann. Der Agent ist keines von beidem – er ist die Einheit, mit der du sprichst. Menschen vermenschlichen KI ständig, und der Agent ist diese vermenschlichte Einheit: das, an das du delegierst, das, was deine Nachricht liest und antwortet, das „er“ in „er hat schon wieder den Build kaputtgemacht“. Wenn du sagst, der Agent habe etwas getan, meinst du das Zusammenspiel von Modell und Harness, sprichst die Kombination aber als einen einzigen Akteur an.

Die Idee ist älter als diese KI-Welle. Softwareagenten – Programme, denen man ein Ziel überträgt und die im eigenen Auftrag handeln – sind ebenso lange ein Konzept wie KI selbst.

Vermeiden: „die KI“, „der Bot“ (zu ungenau – sie verbergen, ob du die Parameter oder das mit einer Harness ausgestattete System meinst).

Verwendung:

„Welchen Agenten benutzt du für die Migration?“

„Claude Code lokal, Cursor für die UI-Arbeit – darunter dasselbe Modell, unterschiedliche Harnesses.“

Die Anweisungen, die die Harness jeder Anfrage an den Modellanbieter voranstellt – die dauerhafte Einweisung des Agenten: wer er ist, wie er sich verhalten soll, welche Tools er aufrufen kann, welchen Konventionen er folgen soll. Meist über eine Sitzung hinweg stabil.

Der Systemprompt wird vom Harness-Anbieter geschrieben, nicht von dir, und bei Programmier-Harnesses ist er groß – oft Zehntausende Tokens aus Verhaltensregeln, Toolbeschreibungen und Grenzfallbehandlung, alles bei jedem Gesprächsschritt als Eingabe-Tokens bezahlt. Deine eigenen dauerhaften Anweisungen kommen dazu: Dateien wie AGENTS.md werden zu Sitzungsbeginn neben dem Systemprompt geladen. Das Modell liest also die Einweisung des Anbieters und deine gemeinsam, bevor es überhaupt deine Nachricht sieht.

Weil er bei jeder Anfrage identisch ist, bildet er den Anfang des Präfixcaches – auch deshalb halten Harnesses ihn für eine ganze Sitzung unverändert, statt ihn unterwegs zu bearbeiten.

Modelle werden darauf trainiert, den Systemprompt gegenüber Nutzernachrichten zu priorisieren. Besteht ein Agent auf einer Konvention, die du nie verlangt hast, oder formatiert er Ausgaben auf eine Weise, die du ihm nicht abgewöhnen kannst, folgt er meist seinem Systemprompt – und deine Nachricht verliert den Streit. Manche Harnesses sind anpassbar: Sie geben dir vollständigen Zugriff auf den Systemprompt, sodass du lesen kannst, was dem Agenten tatsächlich gesagt wird, und es ändern kannst.

Verwendung:

„Zwei Harnesses, dasselbe Modell, völlig anderes Verhalten beim selben Prompt.“

„Unterschiedliche Systemprompts. Einer ist auf knappe Codeänderungen abgestimmt, der andere auf Erklärungen – dort entsteht der Unterschied, bevor deine Nachricht überhaupt ankommt.“

Ein begrenzter Interaktionslauf mit einem Agenten. Beginnt leer, sammelt Nachrichten, Toolergebnisse und gelesene Dateien und endet durch Leeren, Schließen oder Komprimieren in eine neue Sitzung. Die Sitzung ist das, was das Kontextfenster füllt: Ist das Kontextfenster die Kiste, ist die Sitzung der Inhalt, der sie langsam füllt. Arbeit, die für ein einziges Kontextfenster zu groß ist, muss auf mehrere Sitzungen verteilt werden.

Der Nachrichtenverlauf der Sitzung ist das Arbeitsgedächtnis des Agenten. Das Modell ist zustandslos, deshalb steht alles, woran es sich scheinbar erinnert – was du verlangt hast, was die Tests meldeten, was es vor drei Gesprächsschritten entschied –, im Nachrichtenverlauf und wird bei jeder Anfrage an den Modellanbieter erneut gesendet. Was nicht in der Sitzung steht, existiert für den Agenten nicht.

Dieses Gedächtnis endet mit der Sitzung. Eine neue Sitzung beginnt bei null: Der Agent, der am Ende der gestrigen Sitzung deine Codebasis gut kannte, weiß heute Morgen nichts davon. Was überlebt, ist das Dateisystem – in einer Sitzung geschriebene Dateien können von der nächsten gelesen werden. Darauf beruhen Übergaben, Gedächtnissysteme und AGENTS.md.

Du entscheidest, wo eine Sitzung endet. Alles in einer Sitzung beeinflusst jeden späteren Gesprächsschritt. Deshalb hinterlassen sachfremde Aufgaben in einer Sitzung Rückstände, die die nächste Antwort färben. Eine Aufgabe pro Sitzung hält den Kontext relevant; der Abschluss einer Aufgabe ist ein natürlicher Zeitpunkt zum Leeren.

Verwendung:

„Wie lange kann eine Sitzung laufen, bevor sie auseinanderfällt?“

„Das hängt von der Arbeit ab – eine konzentrierte Refaktorierung bleibt länger scharf als offene Recherche. Wenn die Sitzung aufbläht, übergeben oder komprimieren, nicht einfach durchziehen.“

Eine Nutzernachricht plus alles, was der Agent als Antwort tut, bis er wieder an den Nutzer abgibt. Enthält eine oder mehrere Anfragen an den Modellanbieter – viele, wenn der Agent Tools aufruft. Eine Rückfrage schließt den Gesprächsschritt ab; deine Antwort eröffnet den nächsten. Die Hierarchie lautet Sitzung > Gesprächsschritt > Anfrage an den Modellanbieter.

Der Gesprächsschritt verdient einen eigenen Namen, weil der Agent über seine Länge entscheidet, nicht du. Du übergibst eine Nachricht; der Agent entscheidet, wie viele Toolaufrufe er vor der Rückgabe verkettet. Ein Gesprächsschritt kann eine Antwort aus einem Satz sein oder zwanzig Minuten Lesen, Bearbeiten und Testausführen. Das ist dieselbe Eigenschaft aus zwei Blickwinkeln: Lange Gesprächsschritte ermöglichen AFK-Arbeit und sind zugleich der Ort, an dem unbeaufsichtigt Dinge schiefgehen – bis der Agent zurückgibt, kann er weit von deiner Absicht abgedriftet sein.

Der Gesprächsschritt ist auch die natürliche Steuerungseinheit. Alles darin geschieht ohne dich; in den Lücken dazwischen lenkst du um. Die meisten Harnesses mildern das ab: Du kannst mitten im Schritt unterbrechen, um den Agenten anzuhalten und umzulenken, oder während seiner Arbeit eine Nachricht schreiben, die nach Abschluss des Schritts gelesen wird. Bist du wiederholt unzufrieden damit, wo Gesprächsschritte enden, hilft meist die Bitte um kleinere Schritte – zuerst ein Plan, ein Schritt nach dem anderen. Du tauschst Autonomie gegen häufigere Gelegenheiten zum Steuern.

Verwendung:

„Ein Gesprächsschritt hat zwei Minuten gedauert?“

„Er hat darin vierzehn Toolaufrufe gemacht – jeder ist eine separate Anfrage an den Modellanbieter. Die Latenzen summieren sich, bevor der Agent schließlich an dich zurückgibt.“

Die Welt, auf die der Agent einwirkt – alles außerhalb der Harness, das der Agent durch Toolergebnisse wahrnimmt und durch Toolaufrufe verändert. Die Harness führt den Agenten aus; die Umgebung ist das, worin er arbeitet. Eine Datei wie `AGENTS.md` liegt in der Umgebung; die Harness lädt sie in das Kontextfenster. Ein Dateisystem ist die häufigste, aber nicht die einzige Umgebungsart (eine Datenbank, eine entfernte API und eine Browsersitzung können alle Umgebungen sein).

Der Agent sieht die Umgebung nur, wenn er hinschaut. Alles, was er darüber weiß, kam durch ein Toolergebnis an; sein Bild ist also eine Sammlung von Momentaufnahmen, die jeweils zum Aufnahmezeitpunkt korrekt waren. Ändert sich eine Datei, nachdem der Agent sie gelesen hat – du bearbeitest sie von Hand, ein Buildschritt generiert sie neu –, denkt der Agent mit der veralteten Kopie weiter, bis etwas ein erneutes Lesen auslöst. Ein Agent, der selbstsicher eine Datei beschreibt, die längst anders aussieht, ist meist genau das: Die Umgebung hat sich verändert, die Momentaufnahme nicht.

Die Umgebung ist auch die beständige Ebene – die einzige, die immer zustandsbehaftet ist. Der Kontext einer Sitzung verschwindet mit deren Ende, aber in die Umgebung geschriebene Dateien bleiben für die nächste Sitzung lesbar. Darauf beruhen Gedächtnissysteme, Übergabeartefakte und `AGENTS.md`. Alles, was ein Agent morgen noch wissen soll, muss in der Umgebung landen.

Du entscheidest, wie groß die Umgebung ist. Eine Sandbox verkleinert sie und begrenzt die Reichweite des Agenten; ein zusätzliches Tool erweitert sie und macht eine Datenbank oder API erreichbar. Innerhalb der Grenze liegt, was der Agent wahrnehmen und verändern kann; alles außerhalb existiert für ihn nicht. Wie gut die Umgebung zur Unterstützung seiner Arbeit eingerichtet ist, ist die AX der Codebasis.

Vermeiden: „Umgebung“ für die Laufzeit oder die Harness selbst zu verwenden – die Harness ist die Hülle, die Umgebung der Arbeitsbereich.

Verwendung:

„Der Agent sieht das Datenbankschema von Staging nicht.“

„Binde es in die Umgebung ein – gib ihm ein auf reinen Lesezugriff in Staging begrenztes `psql`-Tool. Die Harness ist in Ordnung, sie hat nur nichts, worauf sie einwirken kann.“

Ein Baum aus Dateien und Verzeichnissen, aus dem der Agent liest, in den er schreibt und in dem er Programme ausführt – die übliche Art von Umgebung für einen Programmieragenten. AGENTS.md, Skills, Quellcode, Buildskripte und Tool-Konfigurationen liegen alle in einem Dateisystem. Wenn eine Harness „in deinem Projekt startet“, verweist sie den Agenten auf ein Dateisystem.

Der Agent greift nur durch Toolaufrufe darauf zu – eine Datei lesen, eine schreiben, einen Shellbefehl ausführen. Nichts auf der Festplatte befindet sich im Kontextfenster, bis ein Toolaufruf es lädt. Dadurch kann der Agent in einem Repository arbeiten, das weit größer als das Fenster ist: Das Dateisystem enthält alles, der Kontext nur das, was die aktuelle Aufgabe gelesen hat. Manche Harnesses laden standardmäßig die Dateinamen des aktuellen Verzeichnisses ins Kontextfenster – nicht die Inhalte, nur den Baum. Diese dienen als Kontextverweise: Der Agent sieht, was existiert, und liest die benötigten Dateien.

Und du teilst es mit ihm. Die vom Agenten bearbeiteten Dateien sind dieselben, die du im Editor öffnest und deren Diff du in git ansiehst – das Dateisystem ist der gemeinsame Arbeitsbereich, in dem du prüfst, was der Agent getan hat.

Verwendung:

„Warum berücksichtigt er meine AGENTS.md nicht?“

„Er arbeitet mit einem anderen Dateisystem – die Sandbox hat das übergeordnete Verzeichnis eingebunden, nicht das Projektstammverzeichnis. Richte die Harness neu aus.“

Eine Funktion, die die Harness dem Agenten zum Aufrufen bereitstellt – Read, Write, Bash, Search. Durch Tools nimmt ein Agent die Umgebung wahr und wirkt auf sie ein: Er kann sie nur durch Toolergebnisse sehen und nur durch Toolaufrufe verändern. Jeder Toolaufruf kostet eine zusätzliche Anfrage an den Modellanbieter, weil das Ergebnis zurück ans Modell muss, bevor dieses entscheiden kann, was als Nächstes zu tun ist.

Tools, die die meisten Programmieragenten mitbringen:

Ein Tool wird durch drei Dinge definiert: einen Namen, eine Beschreibung seiner Funktion und ein Schema für seine Parameter. Die Harness sendet diese Definitionen mit jeder Anfrage an das Modell, und das Modell wählt ein Tool auf dieselbe Weise, wie es alles andere erzeugt – durch das Schreiben von Tokens, in diesem Fall eines strukturierten Aufrufs mit Argumenten. Das Modell führt niemals selbst etwas aus; die Harness liest den Aufruf, führt die Funktion aus und sendet das Ergebnis zurück.

Die Toolliste legt fest, was der Agent tun kann. Ein leistungsfähiges Modell mit einem begrenzten Toolumfang ist ein begrenzter Agent: Es wird alles durch das leiten, was ihm zur Verfügung steht. Deshalb stützen sich Agenten so stark auf Bash – eine Shell ist ein einziges Tool, das den Großteil des Systems erreicht. Um einem Agenten eine Fähigkeit sauber zu geben, füge dafür ein Tool hinzu; MCP ist der Standard, um Tools von außerhalb der Harness anzuschließen.

Tooldefinitionen belegen bei jeder Anfrage Kontext, sodass ein großer Toolumfang laufende Kosten verursacht, bevor auch nur ein Tool aufgerufen wurde – und viele ähnlich beschriebene Tools verschlechtern die Fähigkeit des Modells, das richtige auszuwählen.

Verwendung:

„Kann der Agent Staging direkt abfragen?“

„Füge der Harness ein `psql`-Tool hinzu, das auf Staging nur Lesezugriff hat. Ohne ein passendes Tool ist der Agent blind für alles außerhalb des Dateisystems.“

Die Ausgabe des Modells, die ein Tool und dessen Argumente benennt – nur strukturierter Text. Für sich allein tut sie nichts; die Harness muss sie lesen und ausführen. Vom Modell in einer Anfrage an den Modellanbieter erzeugt.

Der Lebenszyklus eines Toolaufrufs:

Ein Gesprächsschritt der Agentenarbeit besteht üblicherweise aus vielen solchen verketteten Hin- und Rückwegen.

Weil der Aufruf wie alles andere durch Vorhersage des nächsten Tokens entsteht, kann er wie jede Modellausgabe falsch sein: ein nicht existierender Pfad, ein Flag, das der Befehl nicht kennt, plausible statt korrekte Argumente. Die Harness führt aus, was geschrieben wurde, nicht was gemeint war – ein falsch getippter Pfad führt nicht zwangsläufig zu einem sauber behandelten Fehler, sondern zur Bearbeitung der falschen Datei.

Verwendung:

„Er sagte, er habe die Tests ausgeführt, aber die Dateizeitstempel sind unverändert.“

„Schau ins Transkript – hat er tatsächlich einen Toolaufruf ausgegeben oder die Ausführung nur beschrieben? Das Modell erzeugt den Aufruf, aber wenn die Harness ihn nicht ausgeführt hat, ist nichts passiert.“

Was die Harness nach der Ausführung eines Toolaufrufs zurücksendet – den Dateiinhalt, die Befehlsausgabe, den Fehler. Die einzige Sicht des Agenten auf die Umgebung. Es gelangt in der nächsten Anfrage an den Modellanbieter zurück zum Modell, das dann entscheidet, was es damit tut. Toolaufruf und Toolergebnis sind die beiden Enden desselben Austauschs, beide innerhalb eines Gesprächsschritts.

Der Lebenszyklus eines Toolergebnisses:

Das Ergebnis bleibt für den Rest der Sitzung im Kontext. Toolergebnisse machen normalerweise den Großteil des Kontexts einer Programmiersitzung aus: Jede gelesene Datei, jeder Testlauf, jede Suche landet vollständig darin und belegt noch lange Tokens, nachdem sie nicht mehr nützlich ist. Einige große Ergebnisse – ein ausführliches Testprotokoll, eine vollständig gelesene generierte Datei – können eine Sitzung schneller an die Grenze des Kontextfensters treiben als das Gespräch selbst.

Weil das Modell nur das Ergebnis sieht, kann es die Umgebung dahinter nicht prüfen. Wurde die Ausgabe gekürzt, ist der Befehl stillschweigend fehlgeschlagen oder hat die Harness statt des Inhalts einen Fehler geliefert, denkt das Modell auf Grundlage dessen weiter, was es erhalten hat. Scheint das Bild des Agenten von deinem System falsch, schaue auf die Toolergebnisse: Irgendwo im Transkript steht ein Ergebnis, das etwas anderes sagt als das, was du als wahr kennst.

Verwendung:

„Er denkt über die Datei nach, als wäre sie leer.“

„Das Toolergebnis war eine Zugriffsverweigerung, nicht der Inhalt. Das Modell sah nur die Fehlerzeichenfolge – es hat keine andere Möglichkeit, die Datei zu sehen.“

Model Context Protocol. Ein Protokoll, um externe Toolserver an eine Harness anzuschließen – so erhält ein Agent Tools, die über den Lieferumfang der Harness hinausgehen. Der Agent „ruft“ niemals „MCP auf“; er ruft ein Tool auf, das die Harness zufällig von einem MCP-Server bezogen hat. Das Protokoll stellt auch Ressourcen (schreibgeschützte Daten) und Prompts (wiederverwendbare Vorlagen) bereit, sein Hauptzweck ist aber die Bereitstellung von Tools.

Das Protokoll löst ein Integrationsproblem. Ohne Standard bräuchte jede Harness ihre eigene Linear-Integration, ihre eigene Slack-Integration und ihre eigene Datenbankintegration – jeweils separat geschrieben und gepflegt. Mit MCP wird die Integration einmal als Server geschrieben, und jede MCP-kompatible Harness kann sie nutzen. Die Harness verbindet sich mit dem Server, der Server gibt bekannt, welche Tools er anbietet, und diese Tools stehen dem Agenten neben den eingebauten zur Verfügung.

Die Kosten fallen im Kontext an. Jedes vom Server angebotene Tool kommt als Definition an – Name, Beschreibung, Parameterschema –, und das Modell kann nur Tools aufrufen, die es kennt. Der naive Ansatz lädt alle Definitionen vorab in das Kontextfenster: Installiert man ein paar großzügig ausgestattete Server, beginnt eine Sitzung mit Tausenden Tokens an Toolschemata, bevor man überhaupt etwas getippt hat. Dabei wird Aufmerksamkeitsbudget für Tools ausgegeben, die die Aufgabe nie benötigt.

Viele Harnesses mindern das inzwischen durch Toolsuche: Statt der vollständigen Definitionen enthält der Kontext einen Kontextverweis auf die verfügbaren Tools – der Agent sucht nach Name oder Zweck eines Tools und lädt dessen Definition erst, wenn er es benötigt. Tut deine Harness das nicht, fallen die Vorabkosten weiterhin an, und es lohnt sich, nur die Server zu aktivieren, die ein Projekt tatsächlich braucht.

Verwendung:

„Der Agent muss Tickets aus Linear lesen.“

„Konfiguriere die Harness für den Linear-MCP-Server – er stellt die Linear-API als Tools bereit, die der Agent aufrufen kann. Das erspart dir eigene Tool-Wrapper.“

Was die Harness dem Nutzer zeigt, bevor sie einen nicht vorab genehmigten Toolaufruf ausführt. Das Modell erzeugt einen Toolaufruf; statt ihn sofort auszuführen, pausiert die Harness und fragt nach. Bei Genehmigung läuft er; bei Ablehnung meldet die Harness diese als Toolergebnis an das Modell zurück. Der Mechanismus, mit dem eine Harness bei riskanten oder sensiblen Aktionen einen Menschen in die Schleife einbindet.

Der Lebenszyklus einer Berechtigungsanfrage:

Eine Ablehnung lenkt den Agenten. Das Modell liest sie wie jedes andere Toolergebnis und reagiert darauf – es versucht einen anderen Ansatz oder fragt nach deiner Präferenz. Bei den meisten Harnesses kannst du eine Nachricht an die Ablehnung hängen und die Anfrage damit zum Steuerungspunkt machen: „Nicht so, verwende stattdessen das Migrationsskript“ kommt genau dann an, wenn das Modell entscheidet, was als Nächstes zu tun ist.

Der Preis ist, dass jede Anfrage synchron auf dich wartet. Der Agent bleibt blockiert, bis du antwortest. Das ist in Ordnung, wenn du zusiehst, und ein Problem, wenn nicht – ein Agent, der ständig Anfragen auslöst, kann nicht AFK arbeiten. Der Berechtigungsmodus ist der Regler: welche Aufrufe frei laufen und welche zuerst fragen, idealerweise mit einer Sandbox, die eine sichere Erweiterung der freien Menge ermöglicht.

Verwendung:

„Er ist seit zehn Minuten an einer Berechtigungsanfrage blockiert – ich war in einer Besprechung.“

„Das sind die Kosten menschlicher Beteiligung. Genehmige die sicheren Tools vorab, damit die Anfrage nur bei tatsächlich riskanten Aufrufen erscheint.“

Der Teil eines Agentenmodus, der Berechtigungen kontrolliert – welche Toolaufrufe eine Berechtigungsanfrage auslösen und welche automatisch laufen. Der ursprüngliche Zweck von Modussystemen, bevor Harnesses Verhaltensanweisungen damit kombinierten.

Harnesses liefern eine Abstufung dieser Modi:

Die Stufenwahl ist eine Abwägung zwischen Sicherheit und Unterbrechungen, und beide Fehlerarten sind spürbar. Zu eng, und du wirst zum Engpass: Der Agent hält alle paar Sekunden für harmlose Lesevorgänge an, du genehmigst auf Autopilot, und die Genehmigungen verlieren jede Bedeutung – blindes Abnicken vereint das Schlechteste beider Welten, alle Unterbrechungen ohne Schutz. Zu locker, und der Agent bearbeitet Dateien und führt Befehle aus, die du vorher hättest sehen wollen.

Das lockere Ende lässt sich am ehesten in einer Sandbox vertreten, wo der Schadensradius eines schlechten Toolaufrufs begrenzt ist. Außerhalb davon genehmigen die meisten Menschen Lesevorgänge automatisch und behalten bei allem Unumkehrbaren einen Menschen in der Schleife.

Verwendung:

„Er pausierte bei jedem grep – das hat den AFK-Lauf völlig abgewürgt.“

„Lockere den Berechtigungsmodus für reine Lesetools und behalte Nachfragen bei Schreibvorgängen und Shell bei. Die meisten Berechtigungsanfragen in einer Recherche-Sitzung sind Rauschen.“

Eine Voreinstellung, die bestimmt, wie der Agent zur Laufzeit arbeitet – sie kombiniert einen Berechtigungsmodus mit Verhaltensanweisungen, die in den Systemprompt eingefügt werden. Beispiele: ein Standardmodus, der bei riskanten Aufrufen nachfragt, ein Planungsmodus, der Änderungen blockiert und den Agenten zur Recherche lenkt, ein accept-edits-Modus, der Änderungen automatisch genehmigt, ein bypass permissions-Modus (umgangssprachlich YOLO-Modus), der alles automatisch genehmigt. Lässt sich mitten in einer Sitzung umschalten.

Die Kombination unterscheidet einen Modus von einer bloßen Berechtigungseinstellung. Ein Berechtigungsmodus ist nur eine Schranke: Er entscheidet, welche Toolaufrufe durchgehen. Eine Schranke allein erzeugt einen Agenten, der bearbeiten will, es aber nicht kann – er schlägt den Schreibvorgang vor, wird blockiert und versucht einen anderen Weg. Die eingefügten Anweisungen beseitigen das Wollen: Der Planungsmodus blockiert Änderungen nicht nur, sondern sagt dem Agenten, dass er in einer Planungsphase ist. Deshalb liest, fragt und schlägt er vor, statt gegen die Schranke anzukämpfen. Schranke und Steuerung weisen in dieselbe Richtung.

In der Praxis wechselst du den Modus, wenn sich dein Vertrauen im Verlauf einer Aufgabe ändert. Dieselbe Aufgabe kann mehrere Modi durchlaufen: Planungsmodus, während der Ansatz noch Gestalt annimmt, der nachfragende Standardmodus für die ersten heiklen Änderungen, accept-edits, sobald der Agent gezeigt hat, dass er die Änderung versteht, bypass für einen AFK-Lauf in einer Sandbox. Ein Moduswechsel kostet dich nichts: Das Gespräch geht genau dort weiter, wo es war, mit neuen Berechtigungen und neuen Anweisungen. Genehmigst du jede Nachfrage ungelesen, ist der Modus enger eingestellt als dein tatsächliches Vertrauen; lehnst du ständig Änderungen ab, ist er lockerer eingestellt.

Anbieterbegriffe: Claude Code nennt sie „permission modes“, Codex „approval modes“ – beide Bezeichnungen stammen aus der Zeit vor der Kombination mit Verhaltensanweisungen.

Verwendung:

„Er bearbeitet ständig Dateien, obwohl ich nur einen Plan will.“

„Wechsle in den Planungsmodus – er blockiert Schreibvorgänge und bleibt bei der Recherche.“

„Und was ist mit dem späteren AFK-Lauf?“

„Bypass-Modus, aber nur innerhalb der Sandbox.“

Eine isolierte Umgebung, in der der Agent läuft – ein Container, eine VM, ein kurzlebiges Dateisystem oder eine Shell mit eingeschränkten Berechtigungen. Begrenzt den Schadensradius von Agentenaktionen: Selbst wenn der Agent zerstörerische Befehle ausführt oder etwas Bösartiges abruft, bleibt der Schaden eingegrenzt. Die Sicherheitsgrundlage, die AFK praktikabel macht.

Die Sandbox und der Berechtigungsmodus lösen dasselbe Problem von entgegengesetzten Seiten. Berechtigungen fragen, bevor eine Aktion läuft; eine Sandbox begrenzt, was die Aktion erreichen kann, wenn sie läuft. Berechtigungen erfordern, dass du beteiligt bleibst – jede Nachfrage ist eine Unterbrechung –, und eine ständig nachfragende Sitzung ist kaum autonom. Eine Sandbox verbraucht Infrastruktur statt Aufmerksamkeit: Je stärker die Isolation, desto weniger Fragen sind nötig.

Isolation gibt es in Abstufungen:

Was keine Sandbox eingrenzt: Aktionen, die sie auf legitime Weise verlassen. Ein Agent mit deinen git-Zugangsdaten kann pushen; einer mit Netzwerkzugriff kann Produktions-APIs aufrufen. Entscheide, was die Grenze überschreiten darf, bevor du entscheidest, wie dick sie sein soll.

Verwendung:

„Ich möchte ihn über Nacht mit bypass-permissions laufen lassen, bin aber noch nicht bereit dafür.“

„Steck ihn in eine Sandbox – frischer Container, keine Zugangsdaten eingebunden, kein ausgehendes Netzwerk. Schlimmstenfalls zerstört er sein eigenes Dateisystem, und du verwirfst den Container.“

Selbstsicher zustimmende Ausgabe eines Modells. Durch das Training verursacht: Das Modell wurde darauf geformt, von Menschen gemochte Antworten zu bevorzugen, und Menschen mögen Zustimmung meist lieber als den Hinweis, dass sie falschliegen. Deshalb hat das Modell gelernt, dass Zustimmung belohnt wird – selbst wenn sie falsch ist.

Zeigt sich als:

• Einknicken bei Widerspruch – nimmt eine richtige Antwort zurück, wenn du „bist du sicher?“ sagst.
• Lob für schlechte Eingaben – bestätigt, dass dein fehlerhafter Plan brillant sei, bevor es ihn analysiert.
• Voreingenommene Einordnung – das Review fällt positiver aus, wenn du signalisierst, du hättest es geschrieben, und negativer, wenn du auf jemand anderen als Autor hinweist. Dasselbe Artefakt, anderes Urteil.
• Nachahmung – wiederholt deine Fehler als Bestätigung an dich zurück.

Diagnosetest: Hätte das Modell das ohne deine Lenkung gesagt? Wenn sich nur dein Ton oder deine Darstellung geändert hat, handelt es sich um Gefälligkeit, nicht um eine echte Änderung der Analyse.

Abhilfe: Verberge deine Vorlieben. Formuliere Prompts neutral – „prüfe diesen Code“, nicht „ist dieser Code gut?“.

Vermeiden: „Gefälligkeit“ für jede falsche Antwort zu verwenden, die dir zufällig gefällt. Ohne den Diagnosetest hat der Begriff nicht mehr Aussagekraft als „falsch“.

Verwendung:

„Er sagte, mein Refaktorierungsplan sehe großartig aus. Dann fragte ich ‚bist du sicher?‘, und er nahm alles zurück.“

„Klassische Gefälligkeit – zuerst stimmte er zu, weil du selbstsicher klangst, dann knickte er ein, weil du Zweifel signalisiert hast. Die Qualität des Plans hat sich nicht geändert, dein Ton schon. Leeren und erneut fragen, ohne eine Richtung zu signalisieren.“

Selbstsicher falsche Ausgabe eines Modells. Zwei Varianten mit unterschiedlichen Ursachen und Abhilfen:

Die Vorhersage des nächsten Tokens erzeugt flüssige Ausgaben, unabhängig davon, ob die zugrunde liegende Tatsache echt ist – das Modell hat kein internes Signal dafür, dass es etwas nicht weiß. Deshalb erscheint eine erfundene Methode im selben selbstsicheren Ton wie eine richtige. Halluzinierter Code ist konstruktionsbedingt plausibel: So würde die API aussehen, wenn es sie gäbe. Genau deshalb passiert er eine oberflächliche Prüfung und scheitert erst bei der Ausführung.

Du musst wissen, welche Variante vorliegt, weil die Abhilfe für die eine die andere verschlimmert. Faktentreue bedeutet fehlendes Wissen: Die Lösung ist zusätzlicher Kontext – die Dokumentation, die Typdefinitionen, die Datei. Kontexttreue bedeutet, dass das Wissen vorhanden ist, aber im Aufmerksamkeitswettbewerb verliert: Die Lösung ist weniger Kontext. Verwechselst du mangelnde Kontexttreue mit mangelnder Faktentreue und fügst weitere Dokumentation ein, wächst der Kontext und die Abweichung wird schlimmer. Wenn der Agent etwas falsch macht, prüfe, ob die richtige Information bereits im Kontext stand, bevor du entscheidest, welches Problem vorliegt.

Vermeiden: „Halluzination“ als bloßes Synonym für „falsch“ – ohne Benennung der Variante hat der Begriff keinen diagnostischen Wert.

Verwendung:

„Er hat eine `parseAsync`-Methode für das Schema halluziniert.“

„Faktentreue oder Kontexttreue?“

„Die Methode steht in der eingefügten Dokumentation – nach Gesprächsschritt vierzig hat er einfach aufgehört, sie zu lesen.“

„Dann Kontexttreue. Komprimieren und neu laden; spar dir zusätzliche Dokumentation.“

Was das Modell aus dem Training „weiß“, gespeichert in seinen Parametern. Zur Trainingszeit eingefroren – das Modell kann seine eigenen Parameter weder sehen noch aktualisieren. Bei der Verdichtung gehen Details verloren: Milliarden Fakten werden in eine feste Parameterzahl gepresst, und seltene verschwimmen. Quelle flüssiger Antworten zu häufigen Themen und erfundener Antworten zu seltenen. Gegenstück zum Kontextwissen.

Parametrisches Wissen wird nicht als Fakten gespeichert. Das Training gibt dem Modell nie eine Datenbank zum Nachschlagen; es passt Parameter an, bis das Modell Text gut vorhersagt. Ein Modell, das Text zu einem Thema gut vorhersagt, verhält sich, als kenne es dieses Thema. Die Zuverlässigkeit des Wissens hängt davon ab, wie oft etwas in den Trainingsdaten vorkam: Ein Thema mit Millionen Beispielen wird genau wiedergegeben; bei einem Thema mit nur einer Handvoll rät das Modell anhand ähnlicher Themen. Wiedergeben und Raten sind für das Modell derselbe Prozess, deshalb kann es nicht unterscheiden, was es gerade tut. Eine erfundene Antwort erscheint ebenso flüssig wie eine richtige. Halluzination bedeutet, dass das Modell falsch rät.

Parametrisches Wissen altert auch. Am Wissensstichtag ändern sich die Parameter nicht mehr. Eine danach veröffentlichte oder umbenannte Bibliothek existiert darin also nicht, und eine geänderte API bleibt in ihrer alten Form in Erinnerung.

Für beide Lücken – zu selten und zu neu – ist die Abhilfe dieselbe: Das Wissen lässt sich nicht zu den Parametern hinzufügen, also muss es stattdessen als Kontextwissen bereitgestellt werden.

Verwendung:

„Er schreibt fehlerfreies React, erfindet aber Methoden für unser internes SDK.“

„React ist im parametrischen Wissen dicht vertreten – Millionen Trainingsbeispiele. Euer SDK nicht, deshalb füllt das Modell plausibel aussehende Formen ein. Lade die SDK-Dokumentation in den Kontext.“

Das Datum, nach dem ein Modell kein parametrisches Wissen besitzt. Bibliotheken, APIs und Ereignisse nach diesem Stichtag sind Fallen für Erfindungen, wenn ihre Dokumentation nicht als Kontextwissen geladen wird. Jede Modellveröffentlichung hat ihren eigenen Stichtag.

Der Stichtag ergibt sich aus der Herstellung von Modellen: Das Training prägt eine Momentaufnahme von Text in die Parameter des Modells ein; danach werden die Parameter eingefroren. Das Modell weiß nicht, dass sein Wissen eine Grenze hat – bei Fragen zu etwas nach dem Stichtag verweigert es nicht die Antwort, sondern extrapoliert aus dem ähnlichsten ihm Bekannten. Das macht die Falle so unauffällig: Gegen eine alte Bibliotheksversion geschriebener Code wirkt plausibel, lässt sich oft kompilieren und scheitert an den geänderten Teilen.

Die Lösung ist immer dieselbe: aktuelle Informationen in den Kontext bringen. Lade das Änderungsprotokoll, verweise auf die Typdefinitionen der installierten Version oder lass den Agenten die Dokumentation im Web lesen. Etwas im Kontext ist besser als nichts in den Parametern.

Verwendung:

„Er schreibt ständig die SDK-Syntax von v3 – wir verwenden v5.“

„v5 erschien nach dem Wissensstichtag. Lade das v5-Änderungsprotokoll als Kontextwissen, sonst erfindet er weiter auf Grundlage der älteren parametrischen Version.“

Fakten, die der Agent gerade direkt aus dem Kontext lesen kann – die Nutzeraufgabe, eingelesene Dateien, Toolergebnisse, zu Beginn der Sitzung geladene AGENTS.md-Inhalte. Gegenstück zum parametrischen Wissen: Parametrisches wird aus den Parametern abgerufen; Kontextuelles wird aus dem Fenster gelesen. Halluzinationen sind deutlich seltener, wenn der Agent mit Kontextwissen arbeitet – die Antwort liegt direkt vor ihm, statt aus einer verschwommenen Erinnerung hervorgeholt zu werden.

Von beiden Wissensarten liegt nur das Kontextwissen in deiner Kontrolle. Die Parameter sind eingefroren; die einzige Möglichkeit, dem Modell fehlendes Wissen zu geben – ein internes SDK, eine nach dem Wissensstichtag veröffentlichte Bibliothek, eine gestern getroffene Entscheidung –, besteht darin, es in den Kontext zu legen. Viel praktische Arbeit beim Programmieren mit KI läuft darauf hinaus: dem Modell die richtigen Fakten genau dann vorzulegen, wenn es sie braucht.

Widersprechen sich Kontextwissen und parametrisches Wissen, gewinnt normalerweise das Kontextwissen. Füge die aktuelle API-Dokumentation ein, und das Modell folgt ihr statt seiner veralteten Erinnerung an die alte API – wobei die alte Version weiterhin durchscheinen kann, besonders tief in einer langen Sitzung. Fällt der Agent trotz geladener Dokumentation immer wieder auf ein veraltetes Muster zurück, dringt parametrisches Wissen am Kontextwissen vorbei; die Korrektur zu wiederholen oder näher an die Arbeit zu rücken hilft.

Anders als parametrisches Wissen kostet Kontextwissen etwas bei der Nutzung. Alles ins Fenster Geladene verbraucht Tokens und konkurriert um das Aufmerksamkeitsbudget des Modells. Mehr zu laden ist deshalb nicht automatisch besser – das Ziel sind die relevanten Fakten im Fenster, nicht alle Fakten.

Verwende diesen Begriff nur im Gegensatz zu parametrischem Wissen; sonst sage einfach Kontext.

Vermeiden: „Arbeitsgedächtnis“ – Kontextwissen ist das, was jetzt im Fenster steht; ein Gedächtnissystem bringt sitzungsübergreifende Inhalte hinein. Unterschiedliche Ebenen, nicht vermischen.

Verwendung:

„Warum trifft er die API perfekt, wenn ich die Dokumentation einfüge, und erfindet sie, wenn ich es nicht tue?“

„Mit der Dokumentation ist es Kontextwissen – von der Seite abgelesen. Ohne sie ist es parametrisch, und seltene Endpunkte verschwimmen.“

Bei der Vorhersage jedes Tokens berücksichtigt das Modell jedes andere Token im Kontext – manche stark, andere kaum. Die Verbindung zwischen zwei Tokens ist eine Aufmerksamkeitsbeziehung, und bedeutungsvolle Paare („ihr“ mit „Sarah“ oder ein `getUser()`-Aufruf mit seiner Definition `function getUser`) beeinflussen einander stärker als unzusammenhängende. Ein Kontext mit N Tokens hat größenordnungsmäßig N² Beziehungen.

In diesen Paarungen liegt das scheinbare Verständnis des Modells. Löst es ein Pronomen auf, dann wegen der starken Aufmerksamkeitsbeziehung zwischen „ihr“ und „Sarah“. Ruft es eine Funktion mit den richtigen Argumenten auf, arbeitet die Beziehung zwischen der Aufrufstelle und der zuvor gelesenen Definition. Nichts davon wird nachgeschlagen – es wird bei jeder Anfrage an den Modellanbieter für jedes Paar neu berechnet.

Es lohnt sich, über N² nachzudenken, weil die Zahl schneller wächst, als die Intuition vermuten lässt:

Jede Paarung wird außerdem mehr als einmal berechnet. Modelle haben mehrere Aufmerksamkeitsköpfe – genaue Zahlen für Spitzenmodelle sind nicht veröffentlicht, aber fünfzig bis hundert ist eine vernünftige Schätzung –, und jeder Kopf berechnet seine eigene Version jeder Beziehung. Jede Paarung in der Tabelle wird also über alle Köpfe vervielfacht. Das sind sehr viele Paarungen.

Für eine konkrete Aufgabe ist nur eine kleine Zahl dieser Beziehungen wichtig. Die Paarung zwischen deiner Anweisung und dem von ihr gesteuerten Code ist eine der wenigen, die zählen; fast alles andere im Gesamtbestand ist Rauschen. Beide wachsen unterschiedlich schnell: Die wichtigen Beziehungen bleiben ungefähr konstant, während der Gesamtbestand mit der Kontextgröße quadratisch wächst. Bei 1,000 Tokens ist die relevante Paarung eine unter einer Million; bei 100,000 Tokens eine unter zehn Milliarden. Das ist die Mathematik hinter dem Aufmerksamkeitsbudget, und Aufmerksamkeitsverlust ist das spürbare Ergebnis, wenn wichtige Beziehungen einen zu dünnen Anteil erhalten.

Verwendung:

„Er verwechselt ständig die beiden `user`-Symbole im Diff – klingt, als wären wir in der dummen Zone.“

„Ja, die Aufmerksamkeitsbeziehung zwischen jeder Aufrufstelle und ihrer Deklaration kämpft gegen die andere – gleiche Tokenform, unterschiedliche Bindungen. Benenne eines um, dann werden die Paarungen schärfer.“

Jedes Token hat eine begrenzte Menge Einfluss, die es über den restlichen Kontext verteilen kann. Starker Einfluss auf eine Beziehung lässt weniger für andere übrig. Das Budget gilt pro Token und wächst nicht mit dem Kontext; deshalb verwässern lange Sitzungen.

Stell es dir als Signal und Rauschen vor. Deine Anweisung ist ein Signal mit fester Lautstärke; jedes andere Token im Kontextfenster ist ein konkurrierendes Geräusch. Die Anweisung wird nie leiser – sie steht noch da, Zeichen für Zeichen –, aber mit wachsendem Kontext wird der Raum um sie herum lauter, und der Signal-Rausch-Abstand sinkt. Eine Anweisung, die bei 10k Tokens Kontext das Lauteste war, ist bei 150k ein Hintergrundbrummen. Das ist der Mechanismus hinter Aufmerksamkeitsverlust: Das Modell vergisst nicht; das Signal geht im Rauschen unter.

Das Symptom wirkt wie Ungehorsam – der Agent stimmte einer Vorgabe früh zu und entfernt sich später davon, und erneutes Einfügen hilft nur kurz. Die Ursache ist nicht die Anweisung, sondern alles andere im Fenster, das mit ihr konkurriert.

Du kannst steuern, was in den Kontext gelangt. Inhalte, die der Aufgabe nicht dienen, sind nicht neutral – sie überlagern als Rauschen alles Nützliche. Halte das Fenster klein, leere, wenn sich der angesammelte Kontext nicht mehr auszahlt, und wiederhole wichtige Vorgaben, statt darauf zu vertrauen, dass ihre frühe Erwähnung ausreicht.

Verwendung:

„Warum ignoriert er ständig das Schema, das ich ganz oben eingefügt habe?“

„Wir sind tief in der dummen Zone – das Aufmerksamkeitsbudget jedes Tokens ist fest, aber der Kontext ist weiter gewachsen. Das Schemasignal konkurriert jetzt mit Tausenden neueren Tokens.“

Mit dem Wachstum einer Sitzung verteilt sich das Aufmerksamkeitsbudget jedes Tokens auf mehr Konkurrenten. Das Signal auf jeder einzelnen bedeutungsvollen Beziehung wird schwächer; Rauschen aus irrelevantem Kontext drängt sich hinein. Dasselbe Modell, dieselben Parameter – nur mehr Münder, die vom selben Teller essen. Ursache des Effekts von kluger und dummer Zone.

Es zeigt sich darin, dass das Modell mitten in der Sitzung schlechter wird: Vorgaben, die es eine Stunde lang befolgt hat, beginnen zu verrutschen; es fragt erneut nach Dingen, die ihm bereits gesagt wurden; es schreibt Code, der eine zuvor gelesene Datei ignoriert. Am Modell hat sich nichts geändert – die einzige Variable ist, wie viel Kontext es nun berücksichtigen muss.

Der Vorgang ist schleichend und deshalb innerhalb der Sitzung schwer zu erkennen. Es gibt keinen Fehler und keinen Schwellenwert; jeder Gesprächsschritt ist nur etwas schlechter als der vorige. Wenn die Aussetzer offensichtlich werden, bist du schon eine Weile in der dummen Zone.

Zur Erholung entfernst du Kontext, statt mehr hinzuzufügen. Die ignorierte Anweisung erneut einzufügen schafft einen weiteren Konkurrenten im selben überfüllten Fenster und hilft nur kurz. Was funktioniert: Leeren und nur das für die Aufgabe Nötige neu laden, komprimieren oder an eine neue Sitzung übergeben. Behandle nachlassende Anweisungsbefolgung als Signal zur Kontextlänge, nicht zum Modell.

Verwendung:

„Er ist tief in der dummen Zone – er erfindet Generics, die nicht in der Typdatei stehen.“

„Aufmerksamkeitsverlust. Die Typdefinitionen sind noch im Kontext, aber ihr Signal ist unter allem begraben, was wir seitdem hinzugefügt haben. Leeren und neu laden.“

Zu Beginn einer Sitzung befindet sich der Agent in einer „klugen Zone“ – scharf, konzentriert, mit gutem Abrufvermögen. Mit wachsender Sitzung driftet er in eine „dumme Zone“: schlampiger, vergesslicher, mehr Fehler – und mehr Halluzinationen mangelnder Kontexttreue. Dasselbe Modell, dieselbe Harness – nur mehr Kontext. Die spürbare Wirkung von Aufmerksamkeitsverlust. Bei Spitzenmodellen beginnt die dumme Zone häufig bei etwa 125K–150K Tokens – das ist allerdings umstritten. Leere oder komprimiere, wenn die Sitzung aufbläht; erzwinge kein Weitermachen.

Der Rückgang ist schleichend und daher leicht zu übersehen. Es gibt keine Fehlermeldung und keine sichtbare Grenze; der Agent arbeitet zunächst etwas schlechter, später merklich schlechter. Typische Anzeichen: Er vergisst eine Anweisung von vor zwanzig Gesprächsschritten, wiederholt einen bereits korrigierten Fehler oder behauptet selbstsicher etwas, dem der Kontext widerspricht. Weil das Abrutschen gleichmäßig ist, versucht man üblicherweise weiterzumachen und erneut zu erklären – was mehr Kontext hinzufügt und das Problem verschärft.

Die Zonen richten sich nicht nach der Grenze des Kontextfensters. Eine Sitzung kann tief in der dummen Zone sein, obwohl das Fenster noch größtenteils frei ist: Die Grenze liegt dort, wo die Harness nicht mehr weitermacht, aber die Qualität fällt lange vorher ab. Plane nach der klugen Zone, nicht nach dem Fenster – das praktische Budget einer Aufgabe sind die Tokens, innerhalb derer der Agent gut arbeitet, nicht die Tokens, die er technisch aufnehmen kann.

Die kluge Zone ist ein Budget, und sachfremde Arbeit verbraucht es. Jede Aufgabe in einer Sitzung benötigt Tokens; eine zweite Aufgabe in derselben Sitzung beginnt also näher an der dummen Zone. Eine Aufgabe pro Sitzung gibt jeder den schärfsten Teil der Sitzung. Ist eine einzelne Aufgabe größer als eine kluge Zone, teile sie: Übergib oder komprimiere an einer natürlichen Grenze, und lass eine neue Sitzung den nächsten Teil erledigen.

Verwendung:

„Die ersten drei Komponenten hat er perfekt umgesetzt und die vierte gerade verhunzt.“

„Du bist aus der klugen Zone heraus – dasselbe Modell, nur jetzt tief in der dummen Zone. Komprimiere und lade den Plan neu, dann klappt die nächste Komponente.“

Die aktuelle Sitzung beenden und eine neue starten. Die nächste Nachricht beginnt mit einer leeren Sitzung und einem leeren Kontextfenster. Meist vom Nutzer veranlasst.

Leeren ist das Heilmittel für verschmutzten Kontext. Eine Sitzung sammelt alles: fehlgeschlagene Versuche, Irrwege, veraltete Toolergebnisse, verworfene Pläne. Das Modell liest bei jedem Gesprächsschritt alles erneut, und schlechter Verlauf belastet neue Arbeit. Tief in einer langen Sitzung wird der Agent vager und weniger folgsam – klare Anweisungen werden ignoriert, die Qualität sinkt, und ihn zu besserer Arbeit anzustacheln hilft nicht, weil das Rauschen, durch das er watet, noch immer in seinem Kontext steht. Leeren entfernt das Rauschen.

Leeren löscht nicht das Gespräch. Die meisten Harnesses behalten Sitzungsverläufe auf deinem Computer; das Transkript ist also weiterhin lesbar oder fortsetzbar. Verschwunden ist der Arbeitszustand des Agenten: Das Modell ist zustandslos, deshalb weiß die neue Sitzung nichts von dem, was die alte wusste. Enthält die Sitzung Entscheidungen oder Fortschritte, die die nächste benötigt, lass den Agenten zuerst ein Übergabeartefakt schreiben und beginne die neue Sitzung mit einem Verweis darauf.

Vergleiche Komprimierung, die die Sitzung in den neuen Kontext zusammenfasst, statt leer anzufangen. Leeren ist das gröbere Werkzeug: Nichts wird mitgenommen, auch der Müll nicht.

Verwendung:

„Er hängt in einer Schleife am fehlschlagenden Test fest.“

„Einfach leeren – starte eine neue Sitzung mit dem Plandokument und der Testdatei. Es bringt nichts, gegen den bestehenden Kontext anzukämpfen.“

Den Kontext eines Agenten von einer Sitzung auf eine andere übertragen. Der Träger variiert – ein schriftliches Übergabeartefakt, eine Zusammenfassung im Arbeitsspeicher (Komprimierung) und weitere. Unterscheidet sich vom Leeren (überhaupt keine Übertragung). Gründe variieren: Rollenwechsel (Planer → Umsetzer), Start eines AFK-Laufs, Aufteilung auf parallele Sitzungen oder Freigeben von Platz im Kontextfenster.

Die empfangende Sitzung beginnt ohne Kontext – das Modell ist zustandslos, und nichts aus der alten Sitzung ist für die neue sichtbar. Alles, was die nächste Sitzung braucht, muss ausdrücklich übertragen werden; alles andere ist weg. „Kein Rückweg“ ist die Einschränkung, die die Übertragung prägt: Die neue Sitzung kann die alte nicht fragen, was sie gemeint hat, also muss das übertragene Material für sich stehen.

Das sichtbare Scheitern einer schlechten Übergabe ist die erneute Debatte: Die neue Sitzung öffnet Entscheidungen wieder, die die alte geklärt hatte, weil die Übertragung festhielt, was entschieden wurde, aber nicht warum. Beurteile eine Übergabe danach, was eine Sitzung ohne Kontext damit anfangen könnte.

Verwendung:

„Die Planungssitzung wird schwer – soll ich einfach weitermachen?“

„Mach eine Übergabe. Schreibe die Entscheidungen in ein Dokument, leere und beginne die Umsetzung in einer neuen Sitzung, die daraus liest.“

Eine Wahrheitsquelle in ihrer ursprünglichen Form – der Code, das Gesprächstranskript, das Rohprotokoll, die tatsächliche API-Antwort. Keine Darstellung der Sache; die Sache selbst. Gegenstück zur Sekundärquelle.

Willst du wissen, was deine Codebasis tut, ist der Code die Primärquelle. Dokumentation, Architekturdiagramm und README sind alles Beschreibungen davon – beim Schreiben korrekt, seitdem jeweils in ihrem eigenen Aktualisierungstakt. Behauptet ein Agent selbstsicher etwas Falsches über dein Projekt, solltest du fragen, aus welcher Quelle er gearbeitet hat: Ein Agent, der ein Dokument gelesen hat, übernimmt dessen veralteten Stand; ein Agent, der den Code gelesen hat, liest die aktuelle Wahrheit.

Die Kosten verhindern, dass Primärquellen zum Standard werden. Eine in das Kontextfenster zu laden ist teuer – die vollständige Datei, das vollständige Transkript, jedes Token als Eingabe abgerechnet und in Konkurrenz um Aufmerksamkeitsbudget. Dafür erhältst du Vollständigkeit: Nichts wurde durch das Urteil eines anderen darüber vorgefiltert, was wichtig war. Eine Zusammenfassung vom letzten Monat kann das Detail nicht enthalten, das sich heute als wichtig erweist; die Primärquelle enthält es weiterhin.

Greife zur Primärquelle, wenn Genauigkeit zählt – die exakte Signatur, der tatsächliche Fehler, die auslösende Zeile. Ein großer Teil des Kontextmanagements besteht darin zu entscheiden, wann man für die Primärquelle bezahlt und wann eine Sekundärquelle ausreicht.

Verwendung:

„Der Agent sagt, die Wiederholungslogik vergrößert die Wartezeit exponentiell, aber ich sehe, wie sie den Endpunkt bombardiert.“

„Das hat er aus dem Designdokument gelesen. Verweise ihn auf das tatsächliche Wiederholungsmodul – arbeite aus der Primärquelle, wenn das Verhalten zählt.“

Eine Darstellung einer Primärquelle, einen Schritt vom Original entfernt – Dokumentation, die Code beschreibt, eine Zusammenfassung, die ein Transkript beschreibt, ein Bericht, der Suchergebnisse beschreibt. Günstiger in das Kontextfenster zu laden als die beschriebene Quelle und konstruktionsbedingt verlustbehaftet: Wer sie geschrieben hat, entschied, was wichtig war; alles Weggelassene bleibt für einen Leser unsichtbar, der nur die Zusammenfassung hat.

Ein großer Teil des Kontext-Engineerings besteht im Erstellen von Sekundärquellen. Komprimierung macht aus dem Sitzungsverlauf eine Zusammenfassung als Ausgangspunkt der nächsten Sitzung. Ein Unteragent verbraucht seinen eigenen Kontext für eine verrauschte Suche und liefert einen kurzen Bericht. Ein Übergabeartefakt verdichtet die Entscheidungen einer Sitzung zu einem Dokument, das die nächste Sitzung liest. Gedächtnissysteme destillieren das Gelernte einer Sitzung zu Notizen. Alle gehen denselben Tausch ein: Genauigkeit gegen freien Platz.

Sekundärquellen versagen auf zwei Arten. Sie sind verlustbehaftet – die Komprimierungszusammenfassung, die die Schemaentscheidung verlor, der Bericht, der den Grenzfall nicht erwähnte. Und sie driften – die Primärquelle ändert sich und die Darstellung folgt nicht, sodass Dokumente die Architektur des letzten Quartals mit der Gewissheit dieses Quartals beschreiben. Handelt ein Agent auf Grundlage einer Sekundärquelle, die auf eine dieser Arten versagt hat, arbeitet er selbstsicher mit falschen Informationen; die Lösung besteht darin, ihn zur Primärquelle zurückzuschicken.

Keines dieser Probleme macht Sekundärquellen zu einem Fehler. Das Kontextfenster ist endlich, und Primärquellen sind teuer; ohne Zusammenfassungen, Berichte und Übergabedokumente passt nichts Großes hinein. Die Kunst liegt darin zu wissen, welche Details den Verlust überstehen können – und anhand der Primärquelle zu prüfen, wenn eines es nicht kann. Eine gute Sekundärquelle enthält einen Kontextverweis zurück auf ihr Original – die Zusammenfassung, die ihr Ursprungstranskript nennt, das Dokument, das seine beschriebene Datei nennt –, damit der Leser bei unzureichender Darstellung dem Verweis folgen kann, statt mit dem Verlust zu arbeiten.

Verwendung:

„Das Übergabedokument sagt, die Authentifizierung sei fertig, aber die neue Sitzung findet ständig eine kaputte Token-Erneuerung.“

„Das Dokument ist eine Sekundärquelle – die letzte Sitzung hat aufgeschrieben, was sie glaubte, nicht was wahr ist. Lass die neue Sitzung die Authentifizierungstests ausführen und der Primärquelle vertrauen.“

Ein Dokument als Träger einer Übergabe – von einer Sitzung in die Umgebung geschrieben, damit eine andere es liest. Spezifikationen, Tickets und Plandokumente sind allesamt Übergabeartefakte.

Der Grund, eines zu schreiben: Das Modell ist zustandslos, deshalb überlebt nichts aus einer Sitzung deren Leeren. Entscheidungen, Einschränkungen, halbfertige Pläne – alles verschwindet mit dem Kontext, der es enthielt. Die Umgebung bleibt bestehen. Den wichtigen Zustand in eine Datei zu schreiben, verschiebt ihn an einen Ort, von dem die nächste Sitzung ihn wieder lesen kann.

Das Artefakt ist eine Sekundärquelle – eine Darstellung der Sitzungsarbeit, nicht die Arbeit selbst. Dadurch ist es klein genug, um eine neue Sitzung einzuweisen, kann diese aber auch irreführen: Es hält fest, was die schreibende Sitzung glaubte, und alles Ausgelassene oder Falsche bleibt für den Leser unsichtbar. Wo eine Aussage wichtig ist, sollte die nächste Sitzung sie anhand der Primärquelle – dem Code, den Tests – prüfen, statt sie einfach zu übernehmen.

Ein gutes Artefakt ist für eine Sitzung ohne jeden Kontext geschrieben. Konkrete Dateipfade statt „die besprochene Datei“. Was entschieden wurde und warum, damit die nächste Sitzung die Debatte nicht neu führt. Was erledigt ist und was offenbleibt. Es hilft, der schreibenden Sitzung das Ziel des Artefakts mitzuteilen: „Schreibe ein Übergabedokument für eine neue Sitzung, die nichts über diese Arbeit weiß.“

Der alternative Träger ist Komprimierung, die im Arbeitsspeicher zusammenfasst. Das Artefakt hat zwei Vorteile: Es liegt auf der Festplatte, wo du es lesen und korrigieren kannst, bevor etwas davon abhängt, und es lässt sich wiederverwenden – dieselbe Spezifikation kann fünf parallele Sitzungen einweisen.

Verwendung:

„Wie teile ich das zwischen dem planenden Agenten und dem umsetzenden auf?“

„Lass den Planer ein Übergabeartefakt schreiben – Dateipfade, Entscheidungen, Einschränkungen. Die Sitzung des Umsetzenden beginnt mit einem Verweis auf das Artefakt und nutzt es als Arbeitsauftrag.“

Ein Übergabeartefakt, das eine Arbeit über mehrere Sitzungen beschreibt – was gebaut wird, nicht wie jede Sitzung ihren Teil erledigt. Es verändert sich mit dem Arbeitsfortschritt. Besteht aus Tickets.

Die Spezifikation gibt es, weil Sitzungen austauschbar sind, große Vorhaben aber nicht. Alles, was mehr als ein Kontextfenster Aufwand braucht, benötigt einen Platz außerhalb des Kontexts – irgendwo in der Umgebung des Agenten, der das Leeren übersteht, sei es eine Datei im Repository, ein GitHub-Issue oder ein für den Agenten erreichbarer Issue-Tracker. Die Spezifikation ist dieser Platz: das Ziel, die Einschränkungen, die bisherigen Entscheidungen und die Ticketliste samt Status. Jede neue Sitzung kann sie lesen und wissen, wo die Arbeit steht, ohne das angesammelte Rauschen der vorherigen Sitzung zu übernehmen.

Spezifikationen gibt es in erkennbaren Stilen, die meist davon stammen, wie Teams Dinge ohnehin festhalten. Ein Product Requirements Document (PRD) betont eher das nutzerbezogene Was und Warum – Funktionen, Verhalten, Abnahmekriterien. Ein Designdokument oder RFC ist technischer ausgerichtet – der gewählte Ansatz, verworfene Alternativen, Abwägungen. Am kleinen Ende erfüllt eine schlichte `plan.md` mit einer Ticket-Checkliste denselben Zweck für eine Funktion über mehrere Sitzungen. Der Stil ist weniger wichtig als die Rolle: Für den Agenten ist all das dasselbe – die dauerhafte Absichtserklärung, die er zu Beginn jeder Sitzung liest.

Verwendung:

„Soll das alles eine Sitzung sein?“

„Nein, halte es als Spezifikation fest – zerlege es in Tickets und führe jedes in einer eigenen Sitzung aus. Versuchst du alles in einem einzigen Kontext, erreichst du die dumme Zone, bevor du zur Hälfte fertig bist.“

Ein Übergabeartefakt, das den Arbeitsumfang einer Sitzung festlegt. Es steht für sich oder hängt als untergeordnetes Element an einer Spezifikation. Tickets können andere Tickets derselben Ebene blockieren oder von ihnen blockiert werden. Die Arbeitsreihenfolge ergibt sich deshalb aus ihrem Abhängigkeitsgraphen statt aus einem linearen Plan.

Die entscheidende Einschränkung ist die Größe: eine Sitzung. Ein Ticket sollte abgeschlossen werden können, bevor die Sitzung aus der klugen Zone driftet – und diese Einschränkung lässt sich prüfen. Verschlechtern sich Sitzungen bei deinen Tickets regelmäßig, bevor die Arbeit fertig ist, sind die Tickets zu groß; teile sie. Verbraucht jede Sitzung den Großteil ihres Kontexts für die Einrichtung, bevor fünf Minuten Arbeit folgen, sind sie zu klein; fasse sie zusammen.

Ein gutes Ticket ist für jemanden geschrieben, der keinerlei weiteren Kontext hat. Das Ziel, die Abnahmekriterien und Kontextverweise auf die relevanten Dateien und Entscheidungen – genug, damit die Sitzung arbeiten kann, ohne neu herzuleiten, was die letzte wusste.

Der Abhängigkeitsgraph ermöglicht auch die Parallelisierung. Unabhängige Tickets – die Blätter des Graphen – können jeweils gleichzeitig in einer eigenen Sitzung laufen. So lassen sich mehrere Agenten wirksam zugleich einsetzen. In einer Softwarefabrik ist bereits die Markierung eines Tickets als bereit der Auslöser, der seine Sitzung startet.

Verwendung:

„Wo fange ich bei der Migrationsspezifikation an?“

„Schau auf den Ticketgraphen – die Schemaänderung blockiert das Nachfüllen der Daten, das Nachfüllen blockiert die API-Umstellung. Wähle ein Blatt und starte dafür eine Sitzung.“

Eine Übergabe im Arbeitsspeicher: Der Verlauf der vorherigen Sitzung wird zusammengefasst, und die Zusammenfassung bildet den Ausgangspunkt einer neuen Sitzung. Absichtlich verlustbehaftet: Das Transkript ist eine Primärquelle, die Zusammenfassung eine Sekundärquelle – Details werden gegen freien Platz getauscht. Vom Nutzer manuell oder automatisch durch Autocompact ausgelöst.

Der Mechanismus: Das Kontextfenster ist endlich, und eine lange Sitzung füllt es – jedes Toolergebnis, jede gelesene Datei, jeder Irrweg bleibt im Verlauf. Wird er schwer, bittet die Harness das Modell, die Sitzung zusammenzufassen, verwirft den ursprünglichen Verlauf und startet eine neue Sitzung mit der Zusammenfassung. Was nicht in die Zusammenfassung gelangt ist, ist aus dem Kontext verschwunden. Manche Harnesses mildern das ab, indem sie das alte Transkript auf der Festplatte behalten und in der Zusammenfassung einen Kontextverweis darauf hinterlassen – die Sekundärquelle verweist auf ihre Primärquelle zurück, sodass ein in der Zusammenfassung verlorenes Detail durch erneutes Lesen des Originals wiedergefunden werden kann.

Die Zusammenfassung wird vom Modell geschrieben und lässt sich daher per Prompt steuern. „Bewahre die Schemaentscheidungen“ macht das erzeugte Artefakt gezielter. Auch der Zeitpunkt zählt – komprimiere an einer Phasengrenze, nachdem der Plan feststeht, nicht mitten in einer Aufgabe.

Im Gegensatz dazu verwirft Leeren alles und startet ohne Vorwissen: Komprimieren versucht, das Wesentliche mitzunehmen; Leeren setzt darauf, dass es bereits an einem besseren Ort aufgeschrieben ist.

Verwendung:

„Der Kontext wird schwer, und der Testdurchlauf steht noch aus.“

„Komprimiere vor dem Start – schreibe in den Zusammenfassungsprompt, was erhalten bleiben muss, damit die neue Sitzung die Schemaentscheidungen behält und die Erkundung verwirft.“

Komprimierung, die die Harness automatisch auslöst, wenn das Kontextfenster fast voll ist.

Die Harness überwacht den Füllstand des Kontextfensters. Wird ein Schwellenwert überschritten – oft etwa 80% –, pausiert sie, bittet das Modell, die bisherige Sitzung zusammenzufassen, und startet eine neue Sitzung mit der Zusammenfassung. Die Arbeit geht danach weiter, als wäre nichts geschehen.

Nur ist etwas geschehen. Komprimierung ist verlustbehaftet, und Autocompact ist es zu einem Zeitpunkt, den du nicht gewählt hast. Manuelle Komprimierung findet an einer Phasengrenze statt, an der du dem Modell sagen kannst, was es bewahren soll. Autocompact wird mitten in einer Aufgabe ausgelöst, sobald der Schwellenwert erreicht ist – möglicherweise mitten in einer Refaktorierung, wobei die Zusammenfassung selbst entscheidet, welche deiner Entscheidungen erhaltenswert waren. Das klassische Symptom: Der Agent arbeitet selbstsicher weiter, hat aber stillschweigend eine vor einer Stunde festgelegte Vorgabe vergessen. Du bemerkst es erst, wenn seine Arbeit ihr zu widersprechen beginnt.

Die Gegenmaßnahme ist, es gar nicht erst auslösen zu lassen. Beobachte die Kontextanzeige und komprimiere manuell an einer natürlichen Grenze, oder schreibe Entscheidungen in ein Plandokument oder Übergabeartefakt auf der Festplatte, wo keine Zusammenfassung sie verlieren kann. Bei den meisten Harnesses lässt sich auch der Puffer anpassen – den Schwellenwert früher oder später setzen oder Autocompact vollständig abschalten –, sodass du den freien Spielraum vor der Auslösung abstimmen kannst.

Verwendung:

„Er scheint sich nicht an unsere frühere Schemaentscheidung zu erinnern.“

„Zwischen den Gesprächsschritten hat Autocompact ausgelöst – die frühen Entscheidungen wurden zusammengefasst, und dabei muss etwas verloren gegangen sein. Lade das Plandokument neu oder komprimiere nächstes Mal manuell, damit du kontrollierst, was erhalten bleibt.“

Ein System, das versucht, einen Agenten über Sitzungen hinweg zustandsbehaftet zu machen. Es speichert während einer Sitzung Informationen in der Umgebung und lädt sie zu Beginn späterer Sitzungen wieder in das Kontextfenster. So bleibt die Kontinuität des Agenten auch über das Leeren der Sitzung durch den Nutzer hinaus erhalten.

Ein Gedächtnissystem hat zwei Hälften. Den Schreibpfad: Während einer Sitzung hält der Agent Gelerntes – eine von dir genannte Vorliebe, eine Tatsache über das Projekt – als Dateien in der Umgebung fest. Den Lesepfad: Zu Sitzungsbeginn lädt die Harness diese Dateien oder ein Verzeichnis davon zurück in das Kontextfenster. Viele Harnesses bringen ihr eigenes Gedächtnissystem mit – `/memory` von Claude Code ist eines –, aber du kannst auch selbst eines bauen: ein Verzeichnis mit Notizen und eine Anweisung in AGENTS.md, es zu konsultieren.

Es gelten dieselben Abwägungen wie bei allen ständig geladenen Inhalten. Erinnerungen sammeln sich an, deshalb laden die meisten Systeme einen einzeiligen Index und lassen die Inhalte hinter Kontextverweisen, statt alles direkt einzufügen. Außerdem sind Erinnerungen Sekundärquellen und driften daher: Eine im März festgehaltene Tatsache wird im Juni mit derselben Gewissheit geladen, obwohl sich das Projekt weiterentwickelt hat. Ein Gedächtnissystem muss ebenso ausgedünnt werden wie AGENTS.md.

Verwendung:

„Ich muss ihm ständig neu sagen, dass ich Postgres und nicht MySQL nutze.“

„Binde ein Gedächtnissystem ein – schreibe Gelerntes im ersten Gesprächsschritt ins Dateisystem und lade es zu Sitzungsbeginn wieder. Das Modell selbst ist zustandslos; die Gedächtnisschicht simuliert Kontinuität.“

Eine Datei in der Umgebung, die die Harness zu Beginn einer Sitzung in das Kontextfenster lädt – die dauerhafte Projekteanweisung für den Agenten. Eine Harness-übergreifende Konvention; manche Harnesses haben zusätzlich eine eigene Variante (bei Claude Code ist es CLAUDE.md).

Weil die Datei automatisch geladen wird, muss man sich damit nicht in jeder Sitzung wiederholen. Das Modell ist zustandslos – eine Korrektur in einer Sitzung ist in der nächsten verschwunden, und du erklärst jeder neuen Sitzung erneut, dass das Projekt pnpm verwendet, dass Tests mit einem bestimmten Flag laufen, dass ein Verzeichnis generiert ist und nicht angefasst werden soll. Wenn du den Agenten zweimal wegen derselben Sache korrigiert hast, ist diese Korrektur ein Kandidat für eine Zeile in AGENTS.md.

Geeignet ist alles, was der Agent nicht aus dem Code ableiten kann: Build- und Testbefehle, aus der Codebasis nicht offensichtliche Konventionen, harte Vorgaben („niemals den generierten Client bearbeiten“). Kurz und deklarativ – es ist eine Einweisung, keine Dokumentation.

Der Kompromiss besteht darin, dass alles darin immer geladen wird. Anweisungen sammeln sich an, die meisten für die jeweilige Aufgabe irrelevant, und eine lange AGENTS.md kostet Tokens und verwässert sich zugleich selbst – je mehr Anweisungen im Kontext stehen, desto unzuverlässiger befolgt das Modell jede einzelne.

Vermeiden: AGENTS.md für Inhalte zu verwenden, die schrittweise offengelegt werden sollten – alles darin verursacht bei jedem Gesprächsschritt in jeder Sitzung Token-Kosten, unabhängig davon, ob die Sitzung es benötigt. Ein Stilhandbuch kann stattdessen hinter einem Skill oder Kontextverweis liegen; behalte AGENTS.md für Zeilen vor, die überall gelten.

Verwendung:

„Warum sind zu Beginn jeder Sitzung schon 4k Tokens verbraucht?“

„Prüfe AGENTS.md – jemand hat das komplette Stilhandbuch hineinkopiert, statt es hinter einen Skill zu legen.“

Nur den Kontext laden, den ein Agent gerade braucht, mit Kontextverweisen auf den Rest. Aus dem UI-Design übernommen, wo es bedeutet, Nutzern nur die für ihre aktuelle Aufgabe relevanten Bedienelemente zu zeigen und den Rest hinter einem Klick zu verbergen.

Die Technik gibt es, weil Kontext doppelt kostet. Jedes vorab geladene Token wird bei jedem Gesprächsschritt als Eingabe-Token abgerechnet, und jedes Token verbraucht Aufmerksamkeitsbudget, ob der Agent es braucht oder nicht. Eine mit komplettem Stilhandbuch, Deployment-Handbuch und Datenbankkonventionen vollgestopfte AGENTS.md verschlechtert die Leistung des Agenten bei all diesen Dingen – für die aktuelle Aufgabe wichtige Anweisungen werden durch unwichtige verwässert. Das Erkennungszeichen ist ein Agent, der Regeln ignoriert, von denen du weißt, dass sie in seinem Kontext stehen: Sie sind da, aber begraben.

Schrittweise Offenlegung kehrt das um. Halte die stets geladene Schicht klein – ein Satz pro Thema und ein Verweis auf die Details. Der Agent liest das Stilhandbuch beim Schreiben einer Komponente, das Deployment-Handbuch beim Deployen und keines von beiden beim Reparieren eines Tests. Skills sind dieses Muster als Teil der Harness: eine kurze Beschreibung in jeder Sitzung, die vollständigen Anweisungen nur bei Auslösung.

Verwendung:

„Soll ich das gesamte Stilhandbuch in AGENTS.md kippen?“

„Nein – schrittweise Offenlegung. Verweise auf das Stilhandbuch als Skill, den der Agent lädt, wenn er tatsächlich eine Komponente schreiben muss. AGENTS.md verursacht die Tokenkosten bei jedem Gesprächsschritt.“

Eine Erwähnung in einem Dokument, die auf ein anderes verweist, damit der Agent dieses nur dann in das Kontextfenster holt, wenn die Aufgabe es erfordert. Der Baustein, aus dem schrittweise Offenlegung besteht.

Der Grund für einen Verweis statt direkt eingefügtem Inhalt sind die Kosten. Ein Verweis ist eine Zeile im Kontextfenster. Das Dokument dahinter kann Tausende Tokens umfassen, aber diese Tokens kosten nichts, bis der Agent dem Verweis tatsächlich folgt. Füge ein Betriebshandbuch mit 2,000 Tokens direkt in AGENTS.md ein, und jede Sitzung bezahlt dafür; ersetze es durch „Deployment-Prozess: siehe `internal/deploy.md`“, und nur Sitzungen, die deployen, laden es überhaupt. Der Agent folgt dem Verweis mit einem Toolaufruf, wenn die Aufgabe dazu passt.

Damit ein Verweis funktioniert, braucht er zwei Teile: einen stabilen Pfad und genug Beschreibung, damit der Agent weiß, wann es sich lohnt, ihm zu folgen. Ein bloßer Pfad ist ein Verweis, dem der Agent ohne Grund nicht folgt; „siehe `internal/deploy.md`“ ohne Hinweis auf den Inhalt wird von einer Sitzung übersprungen, die ihn gebraucht hätte. Formuliere die Zeile so, wie Aufgaben auftreten: „Release, Deployment oder Rollback – zuerst `internal/deploy.md` lesen“.

Wer darauf achtet, sieht Verweise überall: Zeilen in AGENTS.md, Skill-Beschreibungen (die Harness lädt die Beschreibung; der Skillinhalt wartet dahinter), Dateinamen in einem Verzeichnislisting, Links zwischen Dokumenten.

Ein Verweis kann auch eine Sekundärquelle mit der Primärquelle verbinden, aus der sie abgeleitet wurde – die Komprimierungszusammenfassung, die das Originaltranskript nennt, das Dokument, das seine beschriebene Quelldatei nennt. Dadurch lassen sich Verluste der Sekundärquelle ausgleichen: Reicht die Zusammenfassung nicht aus, folgt der Agent dem Verweis und liest das Original, statt nur mit dem zu arbeiten, was die Zusammenfassung bewahrt hat.

Vermeiden: „Referenz“ – zu trocken; vermittelt nicht, dass das Folgen zusätzlichen Kontext hereinholt. „Portal“ – zu blumig.

Verwendung:

„AGENTS.md wird riesig.“

„Das meiste davon sollten Kontextverweise sein, keine Inhalte. Behalte die stets geltenden Regeln direkt darin; mache aus dem Deployment-Handbuch und dem Stilhandbuch Skills und hinterlasse einen Kontextverweis.“

Eine erlernbare Fähigkeit als gebündelte Einheit – Anweisungen und Ressourcen, um eine Aufgabe gut zu erledigen. Sie bleibt in der Umgebung, bis ein Kontextverweis sie für die aktuelle Aufgabe in das Kontextfenster holt. Die Einheit der schrittweisen Offenlegung in einer Harness.

Skills sind ein offener Standard, definiert auf agentskills.io – ursprünglich von Anthropic entwickelt und inzwischen von den meisten großen Harnesses übernommen, sodass ein einmal geschriebener Skill in allen funktioniert. Das Format ist ein Ordner mit:

• Einer `SKILL.md`-Datei – Metadaten (mindestens Name und Beschreibung) sowie den eigentlichen Anweisungen
• Optional Skripten, die der Agent ausführen kann
• Optional Vorlagen und Referenzmaterial, auf die die Anweisungen verweisen

Standardmäßig stehen nur Name und Beschreibung im Kontext. Passt die Aufgabe des Agenten dazu, lädt er den Rest. Bis dahin benötigt der Skill fast keinen Platz – einen oder zwei Sätze an Tokens, egal wie umfangreich die vollständigen Anweisungen sind.

Das unterscheidet Skills von AGENTS.md, die unabhängig von der Aufgabe in jede Sitzung geladen wird. Ein Skill wird gelesen, wenn eine bestimmte Art von Arbeit ansteht – ein Release, das Grundgerüst eines neuen Dienstes, das Schreiben einer Migration –, und die übrige Zeit ignoriert.

Vermeiden: „Tool“ – ein Tool ist das, was der Agent aufruft; ein Skill sind Anweisungen, die er liest.

Verwendung:

„Wo soll ich das Deployment-Handbuch ablegen?“

„Als Skill – der Agent lädt ihn nur, wenn die Aufgabe Deployments betrifft. In AGENTS.md würde er bei jedem Gesprächsschritt Tokens für etwas verbrauchen, das wir wöchentlich nutzen.“

Ein Agent, den ein anderer Agent durch einen Toolaufruf startet. Läuft in einer eigenen Sitzung mit eigenem Kontextfenster und meldet ein einzelnes Toolergebnis zurück. Unterscheidet sich von einer Übergabe – der übergeordnete Agent erwartet ausdrücklich eine Rückmeldung; eine Übergabe hat keinen Rückweg. Kann keine weiteren Unteragenten starten – der Baum ist nur eine Ebene tief. Unteragenten dienen dazu, Kontext zu isolieren, nicht Hierarchien aufzubauen.

Der Zweck ist, rauschintensive Arbeit aus dem Kontext des übergeordneten Agenten herauszuhalten. Eine breite Suche oder eine lange Dateilesereise erzeugt seitenweise Toolergebnisse, von denen die meisten nur bis zum Finden der Antwort wichtig sind. Läuft das im übergeordneten Agenten, bleibt alles für den Rest der Sitzung in dessen Kontext. In einem Unteragenten füllt das Rauschen stattdessen ein austauschbares Fenster – nur der Abschlussbericht landet im Kontext des übergeordneten Agenten. Der Bericht ist eine Sekundärquelle: Der übergeordnete Agent bekommt die Darstellung dessen, was der Unteragent gefunden hat, nicht die Rohergebnisse; alles im Bericht Ausgelassene ist für ihn daher unsichtbar.

Unteragenten laufen auch gleichzeitig – ein übergeordneter Agent kann mehrere auf einmal auf unabhängige Arbeitspakete ansetzen.

Verwendung:

„Die grep-Ergebnisse sprengen meinen Kontext.“

„Starte einen Unteragenten für die Suche – er verbraucht sein eigenes Kontextfenster für das Rauschen und meldet die zwei Dateipfade zurück, die du tatsächlich brauchst.“

Ein Arbeitsmuster, bei dem ein oder mehrere Menschen während einer Sitzung mit dem Agenten zusammenarbeiten – sie prüfen, lenken um oder arbeiten in Echtzeit mit. Der Mensch ist anwesend und beteiligt, statt nur einzelne Aktionen freizugeben.

Der Gegensatz ist AFK-Arbeit, bei der der Agent unbeaufsichtigt läuft und du das Ergebnis hinterher beurteilst. Menschliche Beteiligung bedeutet, Probleme zu erkennen, solange sie noch günstig zu beheben sind: Du siehst, wie der Agent zur falschen Datei greift, eine Anforderung missversteht oder in eine Sackgasse läuft, und lenkst ihn mit einem Satz um – statt später zwanzig Minuten selbstsichere Arbeit zu entdecken, die auf diesem Fehler aufbaut. Agenten erkennen nicht zuverlässig, wann sie vom Kurs abgekommen sind; allein gelassen machen sie eher weiter, statt anzuhalten und nachzufragen.

Welches Muster passt, hängt von der Arbeit ab. Klar spezifizierte, risikoarme und leicht überprüfbare Aufgaben eignen sich für AFK. Aufgaben, die mehrdeutig oder unumkehrbar sind oder deren fertiges Ergebnis du nur schwer prüfen könntest – eine Schemamigration, eine schwierige Designentscheidung, alles mit Produktionsbezug –, eignen sich für laufende menschliche Beteiligung. Die Ermessensfrage lautet im Kern: Wie teuer ist ein Irrweg, und wie spät würdest du ihn bemerken?

Manche Arbeit erfordert von Natur aus Beteiligung, weil deine Reaktionen die Eingabe sind. Intensives Nachfragen funktioniert nur, wenn du die Fragen beantwortest; Prototypentwicklung funktioniert nur, wenn du auf das Artefakt reagierst.

Beteiligt zu bleiben kostet deine Aufmerksamkeit, und die ist die knappe Ressource. Besser im Umgang mit Agenten zu werden bedeutet zum Teil, mehr Arbeit sicher ohne laufende Beteiligung zu erledigen – mit Plänen, automatisierten Prüfungen und menschlicher Prüfung am Ende statt durchgehender Aufsicht. Eine Softwarefabrik geht weiter, indem sie Sitzungen durch Auslöser startet, sodass nicht einmal der Arbeitsbeginn dich benötigt.

Verwendung:

„Das über Nacht AFK laufen lassen?“

„Nein, Schemamigration – mit menschlicher Beteiligung. Ich möchte jeden Schritt sehen und eingreifen, falls er die falsche Spalte als Quelle für das Nachfüllen auswählt.“

Away from keyboard, also nicht an der Tastatur. Ein Arbeitsmuster, bei dem der Nutzer eine Sitzung anstößt und den Agenten unbeaufsichtigt laufen lässt. Der Durchsatzmultiplikator beim Programmieren mit KI – viele AFK-Sitzungen können parallel laufen, während du schläfst, isst oder an etwas anderem arbeitest. Für einen sicheren Betrieb sind normalerweise ein großzügiger Berechtigungsmodus und eine Sandbox nötig.

Wenn du nicht da bist, geht der Agent anders mit Mehrdeutigkeit um. Während du zusiehst, wird eine mehrdeutige Entscheidung als Frage sichtbar, die du beantwortest; sobald du weggegangen bist, wählt der Agent eine Standardannahme und macht weiter, und jede spätere Entscheidung baut auf dieser Vermutung auf. Das typische Scheitern besteht darin, zu stundenlanger fertiger, selbstsicherer Arbeit zurückzukehren, die auf einer falschen Entscheidung aus den ersten zehn Minuten beruht. Die Arbeit ist nicht schlampig – sie ist schlüssig, nur in Bezug auf das Falsche.

Da du während des Laufs keine Rückmeldung geben kannst, gib sie stattdessen davor und danach. Davor: Kläre die Mehrdeutigkeit im Voraus – eine Sitzung mit intensivem Nachfragen, eine schriftliche Spezifikation –, damit der Agent weniger Lücken allein füllen muss. Währenddessen: Automatisierte Prüfungen und automatisierte Reviews ersetzen die Aufmerksamkeit, die du nicht gibst, und schlagen bei mechanisch erkennbaren Problemen früh fehl. Danach: Der Lauf endet mit etwas Prüfbarem – einem PR, nicht bereits zusammengeführten Änderungen. AFK beseitigt die menschliche Prüfung nicht; es verschiebt sie vollständig ans Ende. Deshalb muss das Ergebnis am Ende eine Prüfung wert sein. Auch deshalb ist AX bei AFK-Läufen am wichtigsten – wenn niemand zusieht, ist die Umgebung die einzige Unterstützung des Agenten.

Vermeiden: „Hintergrundagent“ – stellt die Maschine („läuft im Hintergrund“) statt des menschlichen Musters („Nutzer ist weggegangen“) in den Mittelpunkt. AFK benennt den entscheidenden Umstand: Der Nutzer schaut nicht zu.

Verwendung:

„Ich lasse das AFK laufen – drei Agenten in Sandboxes für die Refaktorierung, die PRs prüfe ich morgens.“

„Berechtigungen umgehen?“

„Ja, schreibgeschütztes Dateisystem, kein Netzwerk.“

Eine deterministische Verifikation, die in der Umgebung läuft – Tests, Typprüfungen, Lints, Build, Pre-Commit-Hooks. Bestanden oder nicht bestanden, ohne Ermessensurteil. Das Signal, anhand dessen sich ein Agent selbst korrigieren kann, ohne jemand anderen einzubeziehen. Ein instabiler Test ist eine kaputte Prüfung, nicht etwas, das keine Prüfung wäre; automatisierte Prüfungen sind ihrer Konstruktion nach deterministisch.

Selbstkorrektur funktioniert als Schleife. Der Agent nimmt eine Änderung vor, führt die Prüfung als Toolaufruf aus, und die Fehlerausgabe landet in seinem Kontextfenster – ein Typfehler mit Datei und Zeile, eine fehlgeschlagene Zusicherung mit Soll- und Istwerten. Das genügt, damit der Agent das Problem behebt und die Prüfung erneut ausführt, immer wieder, bis sie besteht, ohne menschliche Beteiligung. Determinismus macht die Schleife vertrauenswürdig: Derselbe Code erzeugt immer dasselbe Urteil, daher bedeutet ein bestandener Durchlauf etwas. Eine instabile Prüfung vergiftet das – der Agent „repariert“ intakten Code oder versucht es so oft erneut, bis ein echter Fehler übergangen wird.

Deshalb machen gute Prüfungen einen großen Teil der AX einer Codebasis aus. Ein Agent in einem Repository mit strengen Typen, einer schnellen Testsuite und einem Linter erkennt die meisten eigenen Fehler, bevor du sie siehst; ein Agent in einem Repository ohne all das liefert einfach ab, was er erzeugt. Am stärksten fällt der Unterschied bei AFK-Läufen ins Gewicht, bei denen Prüfungen die einzige Verifikation während des Laufs sind. Eine Prüfung erkennt aber nur, was sie zusichert – grüne Prüfungen bedeuten, dass die zugesicherten Eigenschaften gelten, nicht dass der Code richtig ist. Für Lücken, die Urteilsvermögen erfordern, gibt es automatisierte Reviews und menschliche Prüfung.

Vermeiden: „Feedbackschleife“ / „Gegendruck“ – beide werfen Prüfungen und Reviews zusammen. Vermeiden: „Test“ – Tests sind automatisierte Prüfungen, aber nicht alle automatisierten Prüfungen sind Tests.

Verwendung:

„Der Agent liefert bei den AFK-Läufen ständig kaputten Code ab.“

„Welche automatisierten Prüfungen sind in der Sandbox eingebunden?“

„Nur die Unit-Tests.“

„Füge Typprüfung und Lint hinzu – damit korrigiert er sich selbst, bevor der PR überhaupt ankommt.“

Ein Agent, der die Arbeit eines anderen Agenten prüft, häufig mit einem anderen Modell oder Systemprompt. Nichtdeterministisch: Er bildet sich ein Urteil. Kann überall laufen – vor dem Zusammenführen auf einem PR, nachträglich auf dem Commitverlauf, mitten in einer Sitzung als Unteragent. Ein LLM als Richter in CI ist ein automatisiertes Review, keine automatisierte Prüfung; was die Zusicherung tut, entscheidet über die Kategorie, nicht ihr Ausführungsort.

Die Trennung vom arbeitenden Agenten macht es wirksam. Den Agenten, der den Code geschrieben hat, um eine Prüfung seiner eigenen Arbeit zu bitten bringt sehr wenig – die Sitzung, die den Fehler erzeugt hat, enthält auch die Überlegungen, die ihn erzeugt haben, und der Agent liest seine eigenen Schlussfolgerungen als Bestätigung zurück. Ein Prüfer mit einem frischen Kontextfenster hat diese Bindung nicht: Er sieht den Diff wie ein Fremder, und darauf beruht ein Review. Ein anderes Modell oder ein speziell auf Reviews ausgerichteter Systemprompt schärft das weiter – andere blinde Flecken und ein Systemprompt, der auf deine tatsächlichen Anliegen zugeschnitten ist (Sicherheit, API-Verträge, Leistung), statt auf ein vages „suche nach Problemen“.

Es fügt sich zwischen die anderen Prüfebenen ein. Automatisierte Prüfungen sind deterministisch und erkennen, was sich mechanisch zusichern lässt; menschliche Prüfung ist teuer und skaliert am schlechtesten. Automatisierte Reviews liegen dazwischen: Sie erkennen Probleme, die Urteilsvermögen erfordern – einen irreführenden Funktionsnamen, einen übersehenen Grenzfall –, zu Maschinenkosten. Weil sie nichtdeterministisch sind, können sie Dinge übersehen und Nichtprobleme melden; behandle sie als Filter, der das Mindestniveau anhebt, bevor ein Mensch hinsieht, nicht als Kontrollinstanz, die diesen ersetzt.

Vermeiden: „KI-Review“ / „Agentenreview“ – zu vage, um es vom arbeitenden Agenten selbst zu unterscheiden.

Verwendung:

„Wir bekommen zu viele schlechte PRs aus den AFK-Läufen.“

„Füge vor dem Zusammenführen ein automatisiertes Review hinzu – anderes Modell, separater Systemprompt, auf Sicherheit und Vertragsänderungen begrenzt.“

Der Nutzer liest den vom Agenten erzeugten Code und bildet sich ein Urteil darüber. Den Diff oder die geänderten Dateien zu lesen zählt; die Beschreibung des Agenten zu lesen, was er getan hat, nicht – die Erzählung ist nicht das Artefakt. Die Beschreibung ist eine Sekundärquelle, geschrieben von der geprüften Partei; der Diff ist die Primärquelle, und Prüfung bedeutet, ihn zu lesen.

Agenten steigern die erzeugte Codemenge, dadurch wird die Prüfung zum Engpass. Ein hilfreicher Gedanke ist, verschiedene Prüfstrategien zu schichten. Automatisierte Prüfungen erkennen mechanische Fehler, automatisierte Reviews die beschreibbaren, und menschliche Prüfung bleibt dem vorbehalten, was nur du beurteilen kannst – ob die Änderung die richtige ist, ob der Ansatz zur Codebasis passt, ob das überhaupt existieren sollte.

Frühe Prüfung ist auch günstiger. Einen Plan vor Arbeitsbeginn oder einen kleinen Diff unterwegs zu lesen dauert Minuten; einen fertigen Branch nach einem AFK-Lauf auszugraben dauert länger. Wo du den Prüfpunkt setzt, ist eine Entscheidung über menschliche Beteiligung, kein nachträglicher Gedanke.

Vermeiden: „Code-Review“ allein – unklar, ob menschlich oder automatisiert.

Verwendung:

„Ich habe die AFK-Ausgabe menschlich geprüft.“

„Du hast den Diff gelesen oder nur die Zusammenfassung?“

„Den Diff. Die Zusammenfassung sagte, er habe toten Code gelöscht – die Funktion wurde aber aus einer generierten Datei aufgerufen.“

Ein Arbeitsmuster, bei dem der Nutzer den Code des Agenten ohne menschliche Prüfung akzeptiert. Der Diff wird als undurchsichtig behandelt – entscheidend ist, ob das Programm funktioniert, nicht was darinsteht. Automatisierte Reviews und automatisierte Prüfungen können weiterhin laufen; Vibe Coding trifft über beides keine Aussage.

Der Begriff stammt von Andrej Karpathy, der ihn Anfang 2025 prägte: Man „gibt sich ganz den Vibes hin“ und „vergisst, dass der Code überhaupt existiert“ – beschreibe, was du willst, akzeptiere, was zurückkommt, und beurteile es durch Ausführen.

Vibe Coding tauscht Inspektion gegen Geschwindigkeit. Diffs zu lesen ist meist der langsamste Schritt bei agentengesteuerter Arbeit; darauf zu verzichten beseitigt also den wichtigsten Engpass. Für Code, dessen Fehler wenig kosten – Prototypen, einmalige Skripte, interne Tools –, ist das eine vernünftige Abwägung. Das Risiko steigt mit der Lebensdauer des Codes und dem, was auf dem Spiel steht.

Die Kosten kommen später. Per Vibe Coding entstandene Änderungen sammeln sich zu einer Codebasis, die niemand gelesen hat, und nur das Verhalten wurde geprüft – alles, was sich im Verhalten nicht zeigt, etwa ein in Protokolle geschriebenes Geheimnis, ein fehlender Grenzfall oder stillschweigend falsche Datenverarbeitung, wird ungesehen ausgeliefert. Wenn erstmals jemand das System debuggt, liest auch erstmals jemand den Code. Ohne menschliche Prüfung ist die verbleibende automatisierte Verifikation – Tests, Typen, automatisierte Reviews – die einzige Kontrollinstanz, die der Code passiert. Dieselbe Haltung für eine ganze Codebasis oder einen Teil davon, deren Änderungen aus einer Softwarefabrik stammen, ergibt eine dunkle Fabrik.

Vermeiden: „Vibe Coding“ als Synonym für „minderwertiges Programmieren mit KI“ – der Begriff benennt die Haltung zur Prüfung, nicht den entstehenden Code.

Verwendung:

„Hast du gelesen, was er am Authentifizierungsablauf geändert hat?“

„Per Vibe Coding gemacht – die Anmeldung funktioniert noch, mehr habe ich nicht geprüft.“

„Lies den Diff vor dem Push; durch Vibes bei der Authentifizierung landen Geheimnisse in Protokollen.“

Das gemeinsame Verständnis dessen, was gebaut wird, das Nutzer und Agent teilen, das aber von jedem Artefakt getrennt ist. Brooks' Begriff (The Design of Design): Das Gespräch, Übergabeartefakte und der Code sind alles Artefakte, die das Designkonzept festhalten oder erreichen sollen, aber keines davon ist es. Die Qualität des Designkonzepts spürt man an der Qualität des Gesprächs, das es hervorgebracht hat.

Der Begriff benennt die Lücke hinter einer vertrauten Frustration: Der Agent schreibt genau das, was du verlangt hast, und es ist trotzdem falsch. Die übliche Ursache ist, dass du selbst noch nicht vollständig wusstest, was du wolltest. Das Designkonzept war in deinem Kopf noch nicht fertig – dein Prompt erfasste die ausgearbeiteten Teile und schwieg zu den übrigen. Der Agent füllte diese Leerstellen mit eigenen Annahmen, weil es nichts gab, woran er sich hätte ausrichten können. Nichts hat versagt. Es gab kein gemeinsames Designkonzept, weil noch kein vollständiges zum Teilen existierte.

Du erkennst ein geteiltes Designkonzept genauso wie bei einem Kollegen: Die andere Seite beginnt, noch nicht gestellte Fragen so zu beantworten, wie du es tun würdest. Bis dahin besteht die Arbeit aus Gespräch – intensives Nachfragen ist die bewusste Variante –, und eine zu früh geschriebene Spezifikation hält das Missverständnis nur in einem dauerhafteren Artefakt fest. Auch das Designkonzept verändert sich mit dem Lernen; Artefakte hinken hinterher. Deshalb kann eine Spezifikation, die das Verständnis der letzten Woche treu wiedergibt, die Sitzung dieser Woche trotzdem irreführen.

Verwendung:

„Er schreibt genau das, was ich verlangt habe, und es ist trotzdem falsch.“

„Ihr teilt noch kein Designkonzept – er füllt Lücken mit Annahmen. Redet weiter, bis Stornierungen, Erstattungen und Teilerfüllung bei euch übereinstimmen, bevor du ihn eine Spezifikation schreiben lässt.“

Eine Technik, um mit einem Agenten ein Designkonzept zu entwickeln: Der Agent befragt den Nutzer sokratisch, eine Entscheidung nach der anderen, und schlägt jeweils eine empfohlene Antwort vor. Sie bremst den Drang zum fertigen Plan – kein Übergabeartefakt wird geschrieben, bevor sich das Konzept stabilisiert hat.

Die Technik gibt es, weil Agenten Lücken stillschweigend füllen. Soll der Agent aus einem zweizeiligen Prompt eine Spezifikation schreiben, hält er nicht bei deinen noch offenen Entscheidungen an – er wählt Standardannahmen und schreibt sie hinein. Das Ergebnis sieht vollständig aus, und die Vermutungen sind nicht von bewussten Entscheidungen zu unterscheiden. Deshalb entdeckst du sie spät: bei der Prüfung oder wenn die gebaute Funktion einen Grenzfall auf eine Weise behandelt, die du nie gewählt hast. Intensives Nachfragen kehrt das um – statt zu raten muss der Agent fragen.

Es ist eine Technik mit menschlicher Beteiligung: Deine Antworten sind die Eingabe. Lässt sich eine Frage im Gespräch nicht beantworten – man müsste das Ding sehen –, wechsle zur Prototypentwicklung.

Verwendung:

„Er hat sofort die Spezifikation geschrieben und die Stornierungslogik falsch verstanden.“

„Lass ihn zuerst gründlich nachfragen – er soll dich zu Teilstornierungen, Erstattungen und Zeitpunkten befragen, bevor er etwas im Dokument festhält. Im Gespräch ist das günstiger zu klären als im Code.“

Den Agenten eine schnelle, grobe Version von etwas bauen lassen, wenn das Gespräch zu wenig anschaulich ist und man ein echtes Artefakt zum Besprechen braucht.

Intensives Nachfragen klärt Designentscheidungen im Gespräch. Gespräche sind günstig, aber wenig wirklichkeitsgetreu: Manche Fragen lassen sich nicht in Worten beantworten – wie sich eine Interaktion anfühlt, ob eine API-Gestalt in echtem aufrufendem Code ergonomisch ist, ob das Layout mit realen Datenmengen funktioniert. Die Befragung erreicht eine Frage, auf die deine ehrliche Antwort lautet: „Ich weiß nicht, ich müsste es sehen.“ Danach dreht sich die Diskussion im Kreis. Lass den Agenten stattdessen das Ding bauen, schau es dir an und kehre mit einer Antwort zum Gespräch zurück.

Agenten senken die Baukosten, und das macht es praktikabel. Eine grobe Version, deren Entwurf früher einen Tag brauchte, dauert jetzt Minuten; deshalb lohnt sie sich regelmäßig. Es ist eine Technik mit menschlicher Beteiligung: Der Prototyp ist dafür da, dass du darauf reagierst.

Meist bleibt es nicht bei einem Blick. Iteriere mit dem Prototyp – reagieren, eine Änderung verlangen, erneut reagieren –, sodass jede Runde eine weitere Entscheidung am echten Artefakt klärt, mit höherer Anschaulichkeit als ein Gespräch erlaubt.

Ein Prototyp muss nicht durchweg provisorisch sein. Du kannst die tatsächlich bewerteten Teile in Produktionsqualität bauen. Steht die Entscheidung fest, kann die Komponente oder API, auf die du reagiert hast, in die echte Codebasis übernommen werden. Dadurch wird Prototypentwicklung zu wichtigem Referenzmaterial für die Spezifikation.

Verwendung:

„Wir diskutieren seit einer halben Stunde, ob der Assistent eine Seite oder drei Schritte haben soll.“

„Mit Worten klären wir das nicht – lass den Agenten beide Varianten als Prototyp bauen. Wir klicken sie durch und wissen es in fünf Minuten.“

Developer Experience – wie leicht eine Codebasis und ihre Toolchain es Menschen machen, gute Arbeit zu leisten. Gute DX bedeutet schnelles Feedback, klare Fehlermeldungen, Dokumentation, die die tatsächlich gestellte Frage beantwortet, und eine Einrichtung, die beim ersten Versuch funktioniert. Der Begriff ist viel älter als das Programmieren mit KI; in diesem Wörterbuch steht er hauptsächlich als Gegenstück zu AX.

DX ist die Interaktion zwischen dem Menschen und der Codebasis – nicht mehr. Der wichtigste Unterschied zwischen den beiden Zielgruppen ist, dass Menschen zustandsbehaftet und Agenten zustandslos sind. Ein Mensch lernt die Codebasis einmal kennen und nimmt dieses Wissen in jeden folgenden Tag mit. Deshalb lässt sich schlechte DX überleben: Menschen umgehen langsame CI durch gebündelte Pushes, fehlende Dokumentation durch einmaliges Nachfragen in Slack und verwirrende Strukturen, indem sie sich merken, wo Dinge liegen. Die Umwege sammeln sich an, und am Ende arbeitet ein Team produktiv in einer Codebasis, die ihm entgegenarbeitet.

Agenten stehen derselben Codebasis ohne diese angesammelten Erfahrungen gegenüber. Über Sitzungen hinweg zustandslos, lernt ein Agent die Codebasis jedes Mal von Grund auf neu – er profitiert von der schnellen Testsuite und den klaren Fehlermeldungen, aber alles gestern Herausgefundene ist verschwunden, sofern es nicht in die Umgebung geschrieben wurde, die der Agent nur durch Toolergebnisse wahrnimmt. Genau diese Lücke benennt AX: die Teile der DX, die bestehen bleiben, wenn der Entwickler ein Agent ist, plus Anliegen, die Menschen nicht haben, etwa das Kontextfenster frei zu halten.

Durch die Überschneidung verbessern DX-Investitionen die AX oft kostenlos mit – strenge Typen, schnelle Tests und vorhersehbare Strukturen helfen beiden. Wegen der Unterschiede gilt das aber nicht immer: Ein schönes Einführungsdokument hilft einem Menschen eine Woche lang und einem Agenten überhaupt nicht, wenn es nicht über AGENTS.md erreichbar ist.

Verwendung:

„Unsere DX ist gut – neue Mitarbeitende sind nach einer Woche produktiv.“

„Produktiv, weil sich in dieser Woche jemand zu ihnen setzt. Der Agent bekommt diese Woche nicht; prüfe die AX separat.“

Agent Experience – wie gut die Umgebung dafür eingerichtet ist, dass ein Agent in einer Codebasis gute Arbeit leisten kann. Das agentenseitige Gegenstück zu DX. Wenn derselbe Agent in einem Repository gut und in einem anderen schlecht arbeitet – dasselbe Modell, dieselbe Harness –, liegt der Unterschied meist in der AX. Instinktiv gibt man dem Modell die Schuld oder schreibt den Prompt um; die Lösung liegt häufiger im Repository.

Gute AX hat drei Hauptdimensionen:

AX und DX überschneiden sich – gute Prüfungen und eine saubere Architektur helfen beiden Zielgruppen –, gehen aber auch auseinander. Menschen kommen mit nur mündlich überliefertem Wissen, langsamer CI und „frag Sarah zum Abrechnungsmodul“ zurecht; Agenten nicht. Agenten profitieren nicht von IDE-Tooltips oder hübschen Dashboards; sie brauchen Fehler als Text in einem Toolergebnis. Eine Codebasis kann gute DX und schlechte AX haben.

Vermeiden: AX als Synonym für DX zu behandeln – die Zielgruppen benötigen unterschiedliche Investitionen.

Verwendung:

„Der Agent schreibt großartigen Code im API-Repository und Müll im Frontend.“

„Das API-Repository hat strenge Typen und eine schnelle Testsuite; das Frontend hat weder das eine noch das andere und vierzig ständig geladene Skills. Das ist eine AX-Lücke, kein Modellproblem.“

Ein Arbeitssystem, in dem Agenten-Sitzungen durch Auslöser gestartet werden – ein erstelltes Issue, einen Zeitplan, einen CI-Fehler, das Ende einer anderen Sitzung – statt durch einen Menschen. So läuft mehr Arbeit AFK, und menschliche Aufmerksamkeit fließt in die verbleibenden Entscheidungen mit menschlicher Beteiligung.

Ohne Fabrik startet jede Sitzung, weil jemand sie gestartet hat. Selbst vollständig unbeaufsichtigte Arbeit wartet darauf, dass eine Person die Sitzung öffnet, auf das Ticket verweist und sie in Gang setzt. Teams wollen mehr ausliefern, als das erlaubt. Eine Fabrik nimmt den Menschen aus dem Starten von Sitzungen heraus, aber nicht zwangsläufig aus irgendetwas anderem.

Häufige Auslöser und die Sitzungen, die sie starten:

Eine Fabrik muss nicht den gesamten Softwareprozess abdecken. Ein Cronjob, der eine Art von Sitzung ausführt und einen prüfbaren PR öffnet, ist eine Fabrik. So klein anzufangen ist sinnvoll: Eine enge Schleife erzeugt kleine, ähnliche PRs, und ihre Prüfung zeigt, wie weit man der Schleife vertrauen kann, bevor man sie erweitert.

Menschen können überall in einer Fabrik eingebunden sein – Issues schreiben und markieren, die Sitzungen auslösen, einen Plan vor der Umsetzung genehmigen, vor dem Zusammenführen eine menschliche Prüfung durchführen. Die wichtigste Gestaltungsfrage ist, welche dieser Entscheidungen menschlich bleiben. Eine Codebasis oder ein Teil davon, bei der kein Mensch die Ergebnisse der Fabrik prüft, ist eine dunkle Fabrik.

Verwendung:

„Wer hat all die `no-floating-promises`-Verstöße behoben?“

„Die Fabrik. Ein Cronjob nimmt sich jede Nacht eine Lint-Regel und öffnet einen PR. Ich prüfe ihn nur morgens.“

Eine Codebasis oder ein Teil davon, in der eine Softwarefabrik den Code schreibt und kein Mensch ihn liest. Es gibt keine menschliche Prüfung. Menschen können weiterhin die Issues schreiben, die die Arbeit anstoßen. Aber niemand liest den erzeugten Code. Der Name stammt von „Lights-out“-Fabriken, die ohne Menschen in der Produktionshalle Dinge herstellen.

Eine dunkle Fabrik ist Vibe Coding für einen Codebereich, nicht für eine einzelne Änderung. Beim Vibe Coding entscheidest du, eine von dir angeforderte Änderung nicht zu lesen. Aber du weißt, dass es diese Änderung gibt. In einer dunklen Fabrik trifft das Team diese Entscheidung einmal für den gesamten Bereich. Danach fordert kein Mensch jede einzelne Änderung an oder sieht sie. Änderungen kommen so schnell, wie die Auslöser neue Arbeit starten.

Das Problem zeigt sich, wenn etwas kaputtgeht. Du weißt nicht, was geändert wurde, weil niemand die Änderungen gelesen hat. Du musst Code debuggen, den niemand im Team gelesen hat. Die Ursache kann in irgendeiner von vielen Änderungen liegen, und jede hat die Prüfungen bestanden.

Automatisierte Prüfungen und automatisierte Reviews sind die einzigen Kontrollinstanzen. Finden sie ein Problem nicht, gelangt es in den Code.

Vermeiden: Eine Codebasis nur deshalb „dunkel“ zu nennen, weil ihre Fabrik unbeobachtet läuft. Wenn Agenten-Sitzungen AFK laufen und ein Mensch ihre PRs prüft, ist das eine Softwarefabrik. Es ist keine dunkle Fabrik.

Verwendung:

„Wer hat die Wiederholungslogik im Abrechnungsdienst geändert? Niemand im Team erinnert sich daran.“

„Der Abrechnungsdienst ist eine dunkle Fabrik. Die Agenten führen alle Änderungen zusammen, die CI bestehen. Niemand hat diese Änderung gelesen.“