Prompt Engineering ist tot. Lang lebe Context Engineering

Ich habe aufgehört, meine Prompts zu optimieren. Nicht weil es nicht funktioniert – sondern weil es die falsche Frage ist.

Die richtige Frage ist: Was steht im Context, wenn der Agent loslegt?

Das Problem mit langen Konversationen

Wer regelmäßig mit LLMs arbeitet, kennt das Muster: Am Anfang eines Chats läuft alles glatt. Nach zwanzig, dreißig Nachrichten fängt das Modell an, frühere Anweisungen zu ignorieren, sich zu widersprechen oder Details zu vergessen, die es eigentlich kennt. Das nennt sich Context Rot.

Das ist kein Bug. Es ist ein strukturelles Problem.

Meredith Whittaker, Präsidentin der Signal Foundation, hat das beim 39C3 auf den Begriff gebracht: Exponential Decay of Success. Die Mathematik dahinter ist ernüchternd. Wenn ein Modell bei jedem Schritt eine Fehlerrate von nur einem Prozent hat (also zu 99% korrekt ist), liegt die Erfolgswahrscheinlichkeit nach 100 Schritten noch bei etwa 37 Prozent. Nach 1.000 Schritten: 0,004 Prozent. Aktuelle Top-Modelle verlieren ab ungefähr 60 Schritten signifikant an Zuverlässigkeit – selbst bei einer nominellen Korrektheit von über 85 Prozent.

Lange Konversationen sind also nicht nur unbequem. Sie sind systematisch unzuverlässig.

Was neuere Modelle anders machen

Frühe Modelle waren auf einzelne Anfragen optimiert – kurzer Context, eine Antwort, fertig. Neuere Modelle sind anders ausgelegt. Sie sind nicht für lange Dialoge gebaut, sondern dafür, einen vollständigen Context einmalig zu laden und dann eigenständig zu handeln: Sub-Agenten starten, Tools aufrufen, Teilprobleme delegieren.

Das ist kein gradueller Unterschied. Das ist ein anderes Paradigma.

Das Open-Weights-Modell GPT-OSS-20B steht stellvertretend für die alte Schule: ein Modell, das primär über einen sorgfältig formulierten Prompt mit Informationen versorgt wurde – großer Context war weder Ziel noch Stärke. Genau deshalb ist es explizit als not suitable for long context recall and tool calling dokumentiert. Das war keine Schwäche des Modells, sondern ein Spiegel der damaligen Annahmen. Heute zeigt sich, dass sich das mit vertretbarem Aufwand ändern lässt: Neuere Modelle wie Nvidia Nemotron 3 Super oder das fine-getunete Persona Kappa (20,9B MoE, 131K-Token-Context, RULER-Benchmark 100 Prozent über alle Contextlängen) sind gezielt auf große Contexts und Tool-Calling ausgelegt – und Kappa wurde auf einer einzigen Workstation mit vier Desktop-GPUs trainiert, kein Rechenzentrum, kein InfiniBand.

Context Engineering statt Prompt Engineering

Anthropic bringt es in ihrem Engineering-Blog auf den Punkt:

„Find the smallest possible set of high-signal tokens that maximize the likelihood of desired outcomes.“

High-Signal-Tokens sind Tokens, die dem Modell tatsächlich nützliche Information liefern – im Gegensatz zu Fülltext, der den Context aufbläht ohne etwas beizutragen. Ein präziser Funktionsname ist ein High-Signal-Token. Eine ausführliche Einleitung, die das Modell auf das vorbereitet, was es sowieso schon weiß, ist es nicht.

Context ist eine endliche, wertvolle Ressource – kein Freitextfeld. Was im Contextfenster landet, entscheidet über die Qualität des Ergebnisses: Welche Dokumente, welche Tool-Definitionen, welcher System-Prompt, welche Artefakte aus früheren Schritten.

Prompt Engineering war die Kunst, das Beste aus einem schlechten Context herauszuholen. Context Engineering ist die Disziplin, den Context von Anfang an richtig aufzubauen.

Ralph Loops: kurze Zyklen statt langer Ketten

Eine praktische Antwort auf Context Rot sind Ralph Loops: statt einer langen, zunehmend degradierenden Konversation arbeitet man in kurzen, fokussierten Iterationen. Jeder Loop bekommt einen frisch aufgebauten, gezielten Context. Fehler werden aufgelöst, dann geht es in den nächsten Loop – mit sauberem Ausgangszustand.

Das klingt aufwändiger als ein langer Chat. In der Praxis ist es zuverlässiger.

Zwei Phasen, nicht eine

Wer mit Agenten arbeitet, hat heute im Grunde zwei Phasen – auch wenn das die meisten noch nicht explizit so behandeln.

Phase 1: Context aufbauen. Ich arbeite interaktiv mit einem Agenten, um die Spezifikation eines Projekts zu erarbeiten. Nicht durch einen einzigen langen Prompt, sondern im Dialog: Projekt grob umreißen, technische Vorgaben definieren, einzelne Spec-Dateien anlegen – auf Basis von PDFs, bestehenden Skripten, Anforderungen. Offene Fragen kläre ich im Interview-Modus: der Agent fragt, ich antworte. Das Ergebnis ist ein implementation-plan.md – das Dokument, das den nächsten Agenten startet.

Phase 2: Agenten loslassen. Den fertigen Context übergeben, einen oder mehrere Agenten starten, Ralph-Loop-Stil, und dann – weitgehend autonom – laufen lassen. Keine Nachjustierung per Prompt. Keine Magie.

Was das bedeutet

Die ganzen Tricks aus der Prompt-Engineering-Ära werden überflüssig. „Act as an expert in…“ – unnötig. Magische Phrasierungen, die das Modell in den richtigen Modus versetzen sollen – Workarounds für einen schlecht aufgebauten Context.

Die eigentliche Arbeit verschiebt sich nach vorne: Welche Informationen braucht der Agent wirklich? Was lasse ich weg? Wie strukturiere ich die Spec, damit der nächste Schritt sauber starten kann?

Das ist weniger Zauberei. Und deutlich mehr Ingenieursarbeit.