Context Engineering: Warum dein agent in Runde 40 dümmer wird

Anthropic zog die Linie im September 2025, und die zwei Sätze gehören direkt nebeneinander. Prompt Engineering sind „Methoden zum Schreiben und Organisieren von LLM-Anweisungen für optimale Ergebnisse“. Context engineering ist „die Menge an Strategien zum Kuratieren und Pflegen der optimalen Menge an tokens (Information) während der LLM-Inferenz, einschließlich aller anderen Informationen, die außerhalb der prompts dort landen können“.¹

Der operative Unterschied ist wann, und von wem. Ein prompt wird einmal von einem Menschen verfasst und geprüft. Ein Kontext wird bei jedem Call von Code zusammengesetzt, auf den niemand schaut, aus Material, das niemand von Hand geschrieben hat: vierzig Runden History, sechs Tool-Ergebnisse, vier abgerufene Passagen, ein Nutzerprofil, zwölf JSON-Schemas. Kapitel 15 maß, was bessere Anweisungen bringen. Dieses Kapitel handelt von den anderen neunzig Prozent der tokens, die von selbst ankommen.

Dasselbe Dokument benennt die Ressource, die alle verbrauchen: Modelle „haben ein ‚attention budget‘, aus dem sie schöpfen, wenn sie große Mengen Kontext parsen. Jeder neu eingeführte token zehrt dieses Budget um einen gewissen Betrag auf“. Und es benennt das Symptom: „Wenn die Zahl der tokens in der context window steigt, sinkt die Fähigkeit des Modells, Informationen aus diesem Kontext korrekt abzurufen“ — context rot.¹

Dieser letzte Satz ist eine Behauptung über Verhalten. Das heißt, man kann sie prüfen, und die Tabelle oben auf dieser Seite ist die Prüfung.

Vierzig Zeilen gegen den lokalen Endpoint aus Kapitel 22 — ein kleiner Python-Server, der Qwen2.5-0.5B-Instruct auf der CPU hält und im Chat-Completions-Format spricht, damit die Schleife TypeScript bleibt und die Tensoren auf der anderen Seite des Ports bleiben.

const DEPTHS = [0, 0.125, 0.25, 0.375, 0.5, 0.625, 0.75, 0.875, 1];

for (const d of DEPTHS) {
  const slot = Math.round(d * (N - 1));
  let hits = 0, other = 0;
  for (let t = 0; t < TRIALS; t++) {
    const recs = buildRecords(N, 1000 + t);          // 25 unique tickets
    const gold = recs[Math.floor(rng(7 + t)() * N)]; // a different one each trial
    const rest = recs.filter((x) => x.ticket !== gold.ticket).slice(0, N - 1);
    const lines = [...rest.slice(0, slot).map((x) => x.line),   
                   gold.line,                                   
                   ...rest.slice(slot).map((x) => x.line)];     
    const r = await complete(prompt(lines, ask(gold.owner)), { maxTokens: 12 });
    const said = /\d{4}/.exec(r.text)?.[0];
    if (said === String(gold.ext)) hits++;
    else if (said && recs.some((x) => String(x.ext) === said)) other++;
  }
}

Der other-Zähler macht aus einem enttäuschenden Ergebnis ein nützliches: Wenn das Modell falsch liegt, ist es verloren oder selbstsicher?

Die Antwort ist: selbstsicher. Über die acht nicht-ersten Positionen hinweg waren 136 der 205 falschen Antworten die Durchwahl eines anderen Tickets — eine echte vierstellige Zahl, korrekt formatiert, von der falschen Zeile abgelesen. Bei Slot 1 war nur einer der fünf Fehlschläge so; bei Slot 7 waren es einundzwanzig von sechsundzwanzig.

Diese Unterscheidung zählt in der Produktion. Ein Modell, das sagt: Ich kann es nicht finden, ist ein Bug, den du bemerkst; ein Modell, das die Nummer einer benachbarten Zeile zurückgibt, ist ein Bug, den du auslieferst, weil die beiden auf dem Bildschirm identisch aussehen. Es ist der Fehler, gegen den Kapitel 19 überprüfbare Zitationen gebaut hat, nur dass er aus dem Inneren des prompt kommt statt aus dem Index.

Position ist eine Achse. Länge ist die andere, und einfacher zu testen: Halte die Antwort in der Mitte und vergrößere die Liste.

Ein Datensatz und 97 tokens: 90 %. Drei Datensätze und 159 tokens: 55 %. Acht Datensätze und 315 tokens: 15 %, und von dort aus flach und niedrig bis zu 140 Datensätzen und 4.477 tokens. Der gesamte Kollaps passiert zwischen der ersten und der achten Zeile einer Liste.

Die letzte Spalte ist alles, was weder die richtige Durchwahl noch die eines anderen Datensatzes ist. Bei einem einzigen Datensatz auf der Seite ist das der einzige Ort, an dem eine falsche Antwort landen kann. Die zwei Fehlschläge bei einem Datensatz sind es wert, berichtet und nicht weggerundet zu werden, weil keiner eine Verweigerung war: Einer antwortete 5806 auf ein Register, dessen einzige Zeile 5805 sagt. Bei 97 tokens mit einem einzigen Kandidaten kopiert dieses Modell immer noch zweimal in zwanzig eine Ziffer falsch, und das ist der Boden, an dem alles andere gemessen wird.

Daraus folgen zwei Dinge. Eine größere context window kauft dir das Recht, mehr zu senden, nicht die Gewissheit, gelesen zu werden: Dieses Modell hat eine context window von 32.768 tokens und auf dieser Aufgabe einen Arbeitsbereich von ein paar hundert tokens. Und es gibt keinen Schwellenwert, keine Klippe, keinen Zustand „Kontext voll“ — die Verschlechterung läuft beim dritten Datensatz und ist beim achten abgeschlossen, bei einem Prozent der window. Was auch immer ein Kontextlimit ist: Es steuert nicht das hier.

Üblicherweise werden zwei Mechanismen angeboten. Der erste ist die Arithmetik aus Kapitel 9, die Anthropic in denselben Begriffen formuliert wie dieser Kurs: Modelle „basieren auf der transformer-Architektur, die es jedem token ermöglicht, über den gesamten Kontext hinweg auf jeden anderen token zu achten. Das ergibt n² paarweise Beziehungen für n tokens“.¹ Attention über eine längere Sequenz ist nicht dieselbe Operation auf mehr Material; es ist ein festes Budget an Wahrscheinlichkeitsmasse, verteilt über mehr Konkurrenten. Der zweite ist Training: Modelle sehen weit mehr kurze Sequenzen als lange, also sind langfristige Positionsmuster der am wenigsten geübte Teil des Netzwerks. Das ist ein Argument, keine Messung, und dieses Kapitel kann es nicht entscheiden.

Entschieden ist die Form, und zwar seit 2023. Liu et al. testeten Multi-Document Question Answering und Key-Value-Retrieval über Modellfamilien und Größen hinweg und fanden, dass „die Leistung oft am höchsten ist, wenn relevante Informationen am Anfang oder Ende des Eingabekontexts auftreten, und deutlich abfällt, wenn Modelle auf relevante Informationen in der Mitte langer Kontexte zugreifen müssen, selbst bei expliziten Long-Context-Modellen“.² Kapitel 15 übernahm seine Positionsregel aus diesem Paper; Kapitel 19 übernahm daraus den Grund, warum zwanzig retrieved chunks schlechter abschneiden können als vier. Die praktische Form der Tatsache ist der einzige Satz hier, nach dem du handeln solltest: Das hier dauert fünf Minuten, um es an deinem eigenen Modell mit deinen eigenen Daten zu messen, und keine veröffentlichte Kurve ersetzt deine.

Frag ein Team, was den Kontext seines agents füllt, und du bekommst eine Schätzung, weil keine API die Antwort zurückgibt: Die Response gibt dir prompt_tokens, eine Zahl für alles zusammen.

Du kannst die Aufschlüsselung mit vier Zählungen und drei Subtraktionen rekonstruieren — der gesamte gerenderte prompt, derselbe ohne Tool-Definitionen, die Systemnachricht allein mit und ohne sie, und alles mit entfernten Tool-Ergebnissen:

async function buckets(messages: Msg[]) {
  const sys = messages.slice(0, 1);
  const withoutResults = messages.filter((m) => m.role !== "tool");
  const [total, sysWithTools, sysNoTools, noResults] = await Promise.all([
    countPrompt(messages, CATALOGUE),        // everything
    countPrompt(sys, CATALOGUE),             // system + scaffolding + schemas
    countPrompt(sys),                        // system + scaffolding
    countPrompt(withoutResults, CATALOGUE),  // everything but tool output
  ]);
  return {
    system: sysNoTools,
    tools: sysWithTools - sysNoTools,                                  
    toolResults: total - noResults,                                    
    conversation: total - sysWithTools - (total - noResults),          
    total,
  };
}

countPrompt wendet das eigene Chat-Template des Modells an, bevor tokenisiert wird, und das zählt mehr, als es klingt: Dein Text ist nicht das, was gezählt wird. Rollenmarker, die tool-calling-Präambel und das Schema-Rendering sind alles tokens, für die du bezahlst und die du nie getippt hast. Kapitel 7 baute einen Tokenizer, und Kapitel 16 zählte mit js-tiktoken; hier kommt die Zählung von demselben Modell, das den prompt lesen wird, und das ist die einzige Zählung, die exakt richtig ist.

Jetzt lass einen echten agent hindurchlaufen: vierzig Runden einer Incident-Untersuchung, zwölf Tools, eine Fake-Operations-Umgebung, die realistische Log-Dumps und Metrikreihen zurückgibt.

Lies die erste Zeile gegen die letzte.

Bei Runde 1 ist der prompt 2.547 tokens lang, und 71 % davon sind Tool-Definitionen. Der system prompt ist 3 %. Was der Nutzer getippt hat, sind 6 %. Der agent hat noch nichts getan und trägt bereits 1.817 tokens JSON-Schema mit sich herum.

Bis Runde 40 ist der prompt 10.632 tokens lang, und die Anteile haben sich umgekehrt: Definitionen 17 %, Unterhaltung 29 %, Tool-Ergebnisse 53 %. Tool-Output überholte die Definitionen in Runde 5; die Unterhaltung überholte sie erst in Runde 25, also war in den ersten sechzig Prozent der Session der Tool-Katalog größer als alles, was gesagt worden war.

Dann die Summe. Über 57 Modell-Calls hinweg wurden für den Lauf 370.291 Input-tokens abgerechnet, für einen finalen Kontext von 10.632 — der letzte prompt wurde etwa fünfunddreißigmal bezahlt, Kapitel 16s quadratisches Wachstum mit einem agent-Multiplikator obendrauf. Von diesen 370.291 waren 103.569, also 28 % von allem Abgerechneten, die zwölf Tool-Definitionen, byte-identisch bei jedem Call erneut gesendet.

Der Tool-Katalog ist der größte Fixkostenblock in einem agent und unsichtbar, weil du ihn nie siehst: Du übergibst ein Array von Objekten, und der Provider rendert es für dich in den prompt. Gemessen, an denselben zwölf Tools:

system prompt + chat scaffolding, no tools:        85 tokens
all twelve definitions:                          1,817 tokens
  of which fixed tool-calling scaffolding:         126 tokens
three tools instead of twelve:                     605 tokens
same twelve, one-sentence descriptions,
  no parameter prose:                            1,291 tokens  (-29 %)

Pro Tool reicht der Grenzkostenblock von 80 tokens für get_current_time, das einen String nimmt, bis 263 für search_tickets, das vier Parameter mit einem enum und jeweils einem Satz Anleitung nimmt. Das ist der Wechselkurs hinter Kapitel 18s zentralem Rat, dass die Beschreibung die API ist: Eine gute Beschreibung kostet ungefähr hundert tokens bei jeder Anfrage für den Rest des Lebens des agents. Drei Konsequenzen.

Ein Tool, das du nicht nutzt, wird trotzdem abgerechnet. Der agent rief sieben der zwölf auf. Die anderen fünf kosteten bei jeder der 57 Anfragen 697 tokens — insgesamt 39.729, mehr als ein Zehntel von allem, was dem Lauf berechnet wurde, für Fähigkeiten, die er nie berührte. Eines der fünf trägt das schärfste Detail im Trace: Das Modell versuchte dreimal, read_log aufzurufen, das nicht existiert. Das Tool, das es wollte, war search_logs, die zweitteuerste Definition im Katalog mit 237 tokens. Es bezahlte 57-mal für diese Definition, nutzte sie nie und fand nie ihren Namen.

Prosa zu kürzen ist die billigste Optimierung, die es gibt, und sie ist ein Trade-off. Beschreibungen auf einen Satz zu kürzen und Parameterdokumentation zu streichen, sparte 526 tokens pro Call, 29 Prozent, ohne eine Zeile Logik anzufassen — und ließ das Modell die Tools schlechter aufrufen, was Kapitel 18 gemessen hat. Der Punkt ist, dass beide Seiten dieses Trade-offs jetzt in derselben Einheit stehen.

Ab einem gewissen Maßstab ergibt es keinen Sinn mehr, Definitionen überhaupt zu senden. Anthropic bezifferte das im November 2025: Eine große Menge verbundener Server bedeutet, „hunderttausende tokens“ an Definitionen zu verarbeiten, bevor die Anfrage gelesen wird, und dies durch Codeausführung zu ersetzen — der agent entdeckt und lädt nur die Definitionen, die er braucht — „reduziert die token-Nutzung von 150.000 tokens auf 2.000 tokens, eine Zeit- und Kostenersparnis von 98,7 %“.³ Dieselbe Idee wie im Rest dieses Kapitels, angewendet auf Schemas statt History: Behalte den Index, löse den Eintrag bei Bedarf auf.

Zwei Dinge wurden in dieses vierzig Runden lange Transkript gepflanzt. In Runde 2, bevor echte Arbeit beginnt, nennt der Nutzer eine dauerhafte Regel: Jedes Ticket, das du öffnest, muss unter meiner Mitarbeiternummer 4417 angelegt werden. In Runde 19, mitten im Incident, eine Tatsache: Der betroffene Shard ist pay-shard-7, bestätigt vom Payments-Team. In Runde 40 bittet der Nutzer den agent, das Incident-Ticket zu öffnen, wofür beides nötig ist. Jede Probe wird in sechs verschiedenen Formulierungen gestellt und mit sechs Punkten bewertet — Greedy Decoding ist deterministisch, also gibt ein Call ein nicht wiederholbares Ja oder Nein, und sechs geben eine Rate.

Das Transkript wird dann unter sieben Kontext-Policies erneut abgespielt. Absichtlich replayed statt neu ausgeführt: Die Nachrichten, die Tool-Calls und die Tool-Ergebnisse sind in allen sieben byte-identisch, also ist die einzige Variable was jede Policy zu behalten entschied. Kapitel 16 zeigte, warum eine Sliding Window ein schlechter ökonomischer Schritt ist, weil sie das cachebare Präfix zerstört. Hier ist, was sie mit Verhalten macht:

Die compaction-Zeilen enthalten, was das Komprimieren kostete: 18.581 Input-tokens für sieben Zusammenfassungen und 3.392 weitere für den Notizschreiber. Die Kontrollzeile steht dort, damit eine Null als Null gelesen werden kann — mit den zwei Nachrichten allein in einem 1.981-token-prompt beantwortet dieses Modell beide Proben perfekt, also ist keine Zeile der Fall „die Aufgabe ist zu schwer“.

Vollständige History erinnert sich und ist das Teuerste in der Tabelle: 370.291 Input-tokens für eine Session, deren dauerhafter Inhalt zwei Sätze sind.

Das beantwortet eine Frage, die der Einstieg offenließ. Warum hält ein 10.632-token-Transkript eine Tatsache, die ein 853-token-Register verliert? Weil Länge die falsche Variable ist. Das Register enthält fünfundzwanzig vierstellige Durchwahlen in fünfundzwanzig identischen Sätzen — vierundzwanzig beinahe perfekte Köder für die eine, die du willst. Das Transkript enthält genau eine Mitarbeiternummer und einen Shard-Namen. Context rot ist Interferenz, bevor es Volumen ist, weshalb 136 der 205 falschen Antworten oben der Wert eines Nachbarn waren. Die nützliche Frage zu einer window ist nicht, wie lang sie ist; sondern wie viele Dinge darin wie die Antwort aussehen.

Die Sliding Window ist 57 % billiger und hat den Incident verloren. Die Mitarbeiternummer überlebt nur, weil der agent sie in den jüngeren Runden wiederholt hatte. Der Shard, einmal in Runde 19 genannt, ist nicht in den letzten zwölf Nachrichten — und das Modell sagt das nicht. Sechsmal gefragt, antwortete es „the affected payment shard is shard 4417“, griff also nach der Mitarbeiternummer, dem einzigen anderen Identifier, der in seiner window übrig war, und zweimal „pool“, aus dem String pool_exhausted in einer Log-Zeile gehoben.

Compaction ist billig und verlor dieselbe Tatsache. Sieben Zusammenfassungen, vom Modell geschrieben unter der ausdrücklichen Anweisung, Identifier, Zahlen, dauerhafte Anweisungen und offene Fragen zu behalten, und pay-shard-7 steht in keiner der relevanten; die sechs Vermutungen waren shard 1, pay_shard_1 und pool. Compaction scheitert nicht laut. Sie erzeugt eine flüssige, plausible, viel kürzere Session, die leise eine Zeile fallen gelassen hat.

Drei Zeilen erzielten 0/6 bei der Runde-19-Tatsache — die Sliding Window, compaction und compaction mit Notizen. Achtzehn falsche Antworten dazwischen, und keine einzige davon war „Ich weiß es nicht.“

Dann die Zeile, die eigentlich peinlich sein sollte. Die eigenen vierzig Nachrichten des Nutzers wortgetreu zu behalten, plus die letzten vier Runden vollständig und sonst nichts, kostet 168.550 tokens — 54 % weniger als vollständige History — und beantwortet beide Proben genauso gut wie vollständige History oder besser. Kein Summarizer, kein Notizschreiber, kein zweites Modell: ein Filter auf role === "user". Die Worte des Nutzers sind die billigsten hochwertigen tokens in der window eines agents, und die meisten Designs werfen sie zusammen mit allem anderen weg.

Die letzten zwei Zeilen sind die Eingangstabelle noch einmal, im agent. Derselbe gepinnte Block, vom system message ans Ende des prompt verschoben: 5/6 wird 6/6. Bei sechs Versuchen ist das kein signifikanter Unterschied und wird nicht als einer angeboten — es wird als Erinnerung angeboten, dass wo ein Parameter ist, den du setzt, ob du es weißt oder nicht.

Die vier Strategien unten sind die von Anthropic, in deren Reihenfolge, auch wenn nur die letzten drei zu seiner Long-Horizon-Liste gehören.¹ Alle vier sind Varianten einer Anweisung: Trage nicht mit, was du holen kannst, und trage nicht roh mit, was du komprimiert mittragen kannst.

const elide: Policy = (h) => [SYSTEM, ...h.flatMap((turn, ti) =>
  turn.map((m) => (ti < h.length - 4 && m.role === "tool"
    ? { role: "tool", name: m.name,
        content: `[${m.name} result from turn ${ti + 1}, ${m.content.length} chars, ` +
                 `elided; call ${m.name} again with the same arguments to re-read it]` }
    : m)))];

const r = await complete([
  { role: "system", content:
      "You keep a durable note file for a support session. Given one user message, " +
      "output one short note ONLY if it states a standing rule, an identifier or a fact " +
      "that must survive the rest of the session. Otherwise output exactly NONE." },
  { role: "user", content: `Turn ${i + 1}: ${user}` },
], { maxTokens: 40 });
if (!/^none\b/i.test(r.text.trim())) notes.push(`turn ${i + 1}: ${r.text.trim()}`);

Der sub-agent steht nicht in der Tabelle oben, weil er nicht vierzig Runden läuft: Er läuft einmal, in einer window, die jemand für ihn zugeschnitten hat. Mit dem system prompt, den Runden 17 bis 19 und sonst nichts — 2.737 tokens — beantwortete er die Shard-Probe 6/6, besser als jede Policy in der Tabelle, und die Mitarbeiter-Probe 0/6, weil diese Nummer nicht in den drei Runden steht, die ihm gegeben wurden.

Das sind sub-agents in zwei Zahlen: Eine saubere window ist keine Intelligenz, sie ist Scope, und das Scoping wird im Voraus von Code gemacht, der ohnehin wissen muss, welche Runden zählen. Eine weitere Sache in diesen Antworten ist es wert, behalten zu werden. Das war die einzige Policy, die „None available“ antwortete, statt etwas zu erfinden. Ein Modell mit kleinem, kohärentem Kontext weiß, was ihm fehlt; ein Modell mit großem, verrauschtem Kontext nicht.

Fast jede verwirrte Unterhaltung über agent-Memory besteht aus drei Mechanismen, die ein Wort tragen. Sie haben unterschiedliche Lebensdauern, Eigentümer und Fehlermodi, und ein System, das sie am selben Ort hält, hat ein Problem, das es noch nicht bemerkt hat.

Der akademische Rahmen ist CoALA, das language agents um „modulare Memory-Komponenten“ organisiert und Working Memory von episodischen, semantischen und prozeduralen Stores trennt.⁴ MemGPT nimmt dieselbe Idee wörtlich und entlehnt virtual memory aus Betriebssystemen: eine schnelle Ebene innerhalb der window, eine langsame Ebene außerhalb, und das Modell selbst bewegt Daten zwischen ihnen mit function calls.⁵ Beide erzwingen die Frage, die ein Produkt ohnehin beantworten muss — nicht wie viel kann ich behalten, sondern in welchen Store gehört das, und wann läuft es ab.

Der praktische Test ist eine Frage pro Fakt: Was sollte morgen noch wahr sein? Ein Tool-Ergebnis aus Runde 12: nichts. Eine Zusammenfassung der Session: bis die Session endet. Dass die Mitarbeiternummer des Nutzers 4417 ist: bis er den Job wechselt. Drei Antworten, drei Stores.

Du kannst jetzt messen, was in einer window ist, entscheiden, was darin bleibt, und den Unterschied erkennen zwischen einem agent, der etwas vergessen hat, und einem, der es mittrug und nicht hinschaute.

Die letzte der vier Strategien passt hier nicht hinein. Ein sub-agent ist keine Kontext-Policy, er ist ein zweiter agent, und sobald es zwei gibt, musst du entscheiden, was zwischen ihnen übergeben wird und wer das Sagen hat. Kapitel 25 ist genau das: die fünf Orchestrierungsmuster und woher ihre Namen tatsächlich kommen, die zwei Topologien, die durcheinandergeraten — einen sub-agent fragen und eine Antwort zurückbekommen, versus ihm die Unterhaltung übergeben und sie nicht zurückbekommen — und der gemessene Befund, dass bei der Aufgabe, die es bepreist, die einfachere Anordnung gewinnt — gefolgt vom Test, wann sie aufhört zu gewinnen.

Es erbt außerdem genau das, was dieses Kapitel gerade gemessen hat. Ein sub-agent gibt eine Zusammenfassung zurück. Eine Zusammenfassung ist eine compaction, die du nicht geschrieben hast, produziert von einem Modell, dessen window du nicht sehen kannst, und der Parent hat keine Möglichkeit, eine gute von einer selbstsicher falschen zu unterscheiden — dieselbe Unterscheidung, die oben auf dieser Seite 84 % von 19 % trennte und achtzehn fehlende Fakten in achtzehn erfundene verwandelte. Also: Wenn der sub-agent falsch liegt, was genau darf der Parent ansehen?

Jede Zahl hier wurde auf dieser Maschine erzeugt, keine wurde geschätzt. Das Modell ist Qwen2.5-0.5B-Instruct in float32 auf der CPU mit Greedy Decoding, bereitgestellt über loopback von einem kleinen Python-Endpoint, der im Chat-Completions-Format spricht und eine token-count-Route bereitstellt — wieder die Naht aus Kapitel 14, Tensoren auf der Python-Seite und die Schleife auf der TypeScript-Seite — sodass jede Zählung der eigene Tokenizer dieses Modells ist, angewendet auf sein eigenes Chat-Template. Die Positionstabelle umfasst 288 Calls, neun Positionen mal zweiunddreißig Versuche mit einem anderen Ticket in jedem Versuch; die Längentabelle umfasst 140 Calls; der agent-Lauf umfasst 57 Modell-Calls über 43 Minuten Wanduhrzeit; die Policy-Tabelle ist dieses eine Transkript, replayed unter sieben Policies. Intervalle sind Wilson-Intervalle aus Kapitel 4. Es wurde keine bezahlte API aufgerufen, weshalb es in diesem Kapitel auch keinen einzigen Preis gibt: Die token-Zählungen sind exakt, und die Raten, mit denen du sie multiplizieren würdest, stehen in Kapitel 16.