Context Engineering für LLM-Agenten: Was Prompt Engineering 2026 abgelöst hat

Niemand, mit dem ich arbeite, schreibt noch System-Prompts um. Die Teams, die 2026 zuverlässige LLM-Agenten betreiben, verbringen ihre Zeit mit etwas anderem: Sie entscheiden, was ins Kontextfenster kommt, was draußen bleibt — und wann etwas wieder rausfliegt.

Wenn Sie schon einen Agenten gebaut haben, der in der Demo glänzt und nach zwölf echten Gesprächsrunden auseinanderfällt, kennen Sie das Problem. Der Prompt war nie das Problem. Der Kontext war es.

Context Engineering ist die Disziplin, die aus dieser Erkenntnis entstanden ist. In diesem Guide zeige ich, was sie konkret umfasst: den Unterschied zum Prompt Engineering, die vier Stellhebel in der Produktion, die Rolle von reasoning-basiertem Retrieval — und, was Vendor-Content konsequent auslässt: wann Sie keinen Memory-Layer bauen sollten. Dazu die Token-Zahlen aus einem Dokumenten-Agenten, den ich dieses Frühjahr umgebaut habe, denn über die Kostenseite laufen am Ende die Budget-Gespräche.

Was ist Context Engineering?

Context Engineering ist die Praxis, gezielt zu gestalten, was ein LLM-Agent zur Laufzeit sieht: welche Anweisungen, abgerufenen Dokumente, Memories, Tool-Definitionen und Gesprächsverläufe das begrenzte Kontextfenster belegen — und in welcher Form. Wo Prompt Engineering einen statischen Textblock optimiert, verwaltet Context Engineering ein dynamisches Budget, das sich mit jeder Runde ändert.

Das Engineering-Team von Anthropic, das Ende 2025 einen der prägenden Beiträge zum Thema veröffentlicht hat, beschreibt Kontext als „kritische, aber endliche Ressource". Diese Formulierung ist bei mir hängen geblieben. Ein Fenster mit 200.000 Token klingt unendlich, bis Ihr Agent vierzig Tool-Aufrufe gemacht hat, jeder mit dreitausend Token JSON als Rückgabe, und die eigentliche Aufgabenbeschreibung irgendwo in der Mitte begraben liegt. Ich habe genau das in einem Session-Replay gesehen. Es war ernüchternd.

Die Disziplin dreht sich um vier wiederkehrende Entscheidungen:

• Selektion — was kommt ins Fenster (Retrieval, Memory-Reads, Tool-Ergebnisse)
• Kompression — in welcher Form (Zusammenfassungen, Compaction, strukturierte Extrakte)
• Reihenfolge — wo es steht (Modelle beachten Anfang und Ende des Kontexts stärker)
• Verfall — wann es geht (Trimmen, Archivieren ins Memory, Verwerfen)

Wer Agenten in Produktion betreibt, trifft diese Entscheidungen bereits. Die Frage ist nur, ob bewusst.

Sie bauen gerade Ihren ersten Produktions-Agenten? Starten Sie mit meinem Guide zu Architektur, Evaluation und Observability von LLM-Agenten — er legt das Fundament für diesen Artikel.

Context Engineering vs. Prompt Engineering: Was sich wirklich geändert hat

Prompt Engineering optimiert die Anweisungen; Context Engineering optimiert die gesamte Informationsumgebung, in der das Modell arbeitet. Der Wandel kam, weil Agenten die Grundannahmen des Prompt Engineerings gesprengt haben: eine Eingabe, eine Ausgabe, ein Mensch liest das Ergebnis.

Eine Agenten-Schleife funktioniert anders. Jeder Tool-Aufruf hängt Output ans Fenster an. Jede Runde fügt Verlauf hinzu. In Runde fünfzehn ist Ihr sorgfältig getunter System-Prompt ein Rundungsfehler: vielleicht 2 % der Token, auf die das Modell achtet. Das Engineering-Team von Mem0 hat gemessen, dass die Gesprächsqualität in typischen Setups nach 10–15 Runden spürbar abnimmt. Das deckt sich mit dem, was ich in Kundensystemen sehe: Der Agent wird nicht dümmer, sein Kontext wird lauter.

Ein Vergleich, der im März bei Stefan, dem CTO einer Münchner Logistikgruppe, den Groschen fallen ließ: Prompt Engineering heißt, ein gutes Briefing-Dokument zu schreiben. Context Engineering heißt, den gesamten Nachrichtendienst zu führen — zu entscheiden, welche Berichte auf den Schreibtisch kommen, welche auf einen Absatz eingedampft werden und welche ins Archiv wandern.

Ein ehrlicher Einwand: Die Grenze ist unscharf, und einiges, was 2026 als „Context Engineering" vermarktet wird, ist Prompt Engineering mit frischem Anstrich. Der Test: Trifft das System zur Laufzeit dynamische Entscheidungen über die Zusammensetzung des Kontexts? Wenn sich zwischen den Runden nichts ändert außer angehängtem Verlauf, betreiben Sie noch kein Context Engineering.

Warum große Kontextfenster das Problem nicht gelöst haben

Größere Fenster haben Context Engineering nicht überflüssig gemacht, weil die Aufmerksamkeit des Modells nicht gleichmäßig über das Fenster verteilt ist. Die „Lost in the Middle"-Forschung (Liu et al., 2023) zeigte, dass die Abrufgenauigkeit für Informationen in der Mitte langer Kontexte deutlich einbricht. Jeder Praktiker-Benchmark seitdem bestätigt eine Variante dieses Effekts.

Dazu kommt eine Kostenuntergrenze, die kein Modell-Release aufgehoben hat. Input-Token werden bei jedem Aufruf berechnet. Ein Agent, der 150.000 Token veralteten Verlauf durch eine Session mit zwanzig Aufrufen schleppt, bezahlt diese Token zwanzigmal. Bei Preisen der GPT-4o-Klasse von 2,50 $ pro Million Input-Token klingt das billig, bis Sie mit tausenden Sessions pro Tag multiplizieren.

Und es gibt eine Qualitätsobergrenze. Langkontext-Degradation (Praktiker nennen es inzwischen „Context Rot") zeigt sich darin, dass Agenten erledigte Arbeit wiederholen, früheren Entscheidungen widersprechen oder sich an irrelevantem Tool-Output festbeißen. Nach meiner Erfahrung ist der Verfall schleichend und in Evals schwer zu erkennen, wenn man nicht gezielt lange Sessions testet. Genau deshalb teste ich lange Sessions.

Die vier Stellhebel des Context Engineering in der Produktion

Context Engineering in der Produktion läuft auf vier Stellhebel hinaus: Retrieval, Memory, Compaction und Tool-Design. Jedes Framework-Feature, das ich dieses Jahr evaluiert habe (LangGraph-Checkpointing, die Memory-API von Mem0, die Auto-Compaction von Claude Code, Lettas Memory-Blocks), implementiert einen dieser Hebel.

Hebel 1: Retrieval — das Fenster just-in-time füttern

Retrieval-Augmented Generation bleibt das Arbeitspferd: Statt alles vorzuladen, holen Sie, was der aktuelle Schritt braucht. Neu in 2026: Retrieval selbst ist vielfältiger geworden. Vektorsuche ist nicht mehr die Standardantwort. Dazu gleich mehr, das Thema verdient einen eigenen Abschnitt.

Meine Faustregel: Alles, was der Agent brauchen könnte, gehört in einen abrufbaren Speicher; nur was er in dieser Runde braucht, gehört ins Fenster. Die Retrieval-Seite behandle ich ausführlich in RAG in Produktion.

Hebel 2: Memory — Wichtiges über Sessions hinweg erhalten

Memory-Systeme extrahieren dauerhafte Fakten aus Gesprächen und speichern sie außerhalb des Fensters. Mem0 (über 62.000 GitHub-Sterne, Stand Mitte 2026) und Letta führen das Open-Source-Feld an; Mem0 berichtet von bis zu 80 % Token-Einsparung, wenn Memory das Abspielen des Roh-Verlaufs ersetzt.

Der Mechanismus ist weniger wichtig als die Disziplin: Jeder Memory-Write ist eine redaktionelle Entscheidung. Wer alles speichert, hat das laute Fenster nur eine Ebene tiefer nachgebaut — mit zusätzlicher Latenz.

Hebel 3: Compaction — zusammenfassen, bevor Sie ertrinken

Compaction ersetzt alten Kontext durch eine verdichtete Version, sobald das Fenster voll läuft. Claude Code macht das nahe der Grenze automatisch; LangGraph und die meisten Agenten-Frameworks bieten Hooks für eigene Strategien. Die Kunst liegt darin, was die Compaction überlebt: Architektur-Entscheidungen, ungelöste Fehler und Nutzer-Constraints müssen; roher Tool-Output fast nie.

Ich behandle Compaction-Prompts wie Produktionscode. Sie werden versioniert, getestet und reviewt, denn eine schlechte Compaction lobotomiert Ihren Agenten mitten in der Session, ohne dass es jemand merkt.

Hebel 4: Tool-Design — die Flut an der Quelle stoppen

Das billigste Token ist das, das nie ins Fenster gelangt. Tools, die 5.000 Token rohes JSON zurückgeben, obwohl der Agent drei Felder braucht, sind der häufigste Kontext-Bug in meinen Audits und der am schnellsten behobene. Sourcegraphs Benchmark ihres MCP-basierten Code-Retrievals hat den Punkt dieses Frühjahr eindrucksvoll belegt: Ein dateiübergreifendes Refactoring, das einen Baseline-Agenten 96 Tool-Aufrufe und 84 Minuten kostete, schrumpfte mit maßgeschneiderten Retrieval-Tools auf 5 Aufrufe und 4,4 Minuten.

Wenn Sie Tools über das Model Context Protocol anbinden: Meine Übersicht Skills vs. MCP vs. Plugins erklärt, welche Ebene des Ökosystems wofür zuständig ist.

Lieber die Checklisten-Version? Ich habe die vier Hebel in ein einseitiges Kontext-Audit-Arbeitsblatt verdichtet, mit dem ich jedes Projekt beginne. Kostenlos anfordern → — keine Registrierung, ich schicke Ihnen einfach das PDF.

Wo reasoning-basiertes Retrieval hingehört (der Blickwinkel, den kaum jemand einnimmt)

Eine Verbindung, die ich selten gezogen sehe: Vektorloses, reasoning-basiertes Retrieval ist eine Context-Engineering-Technik, nicht nur eine RAG-Variante. Ansätze wie PageIndex navigieren einen Dokumentbaum, wie ein Mensch ein Inhaltsverzeichnis überfliegt: Das Modell schlussfolgert, wo die Antwort steht, statt Embeddings zu vergleichen.

Aus Sicht des Kontext-Budgets verändert das die Ökonomie. Vektor-RAG holt k Chunks und hofft; bei geringer Konfidenz drehen Teams k auf 10 oder 20 hoch und fluten das Fenster mit vielleicht-relevantem Text. Baumbasiertes Retrieval lädt zuerst Struktur (billig: ein Inhaltsverzeichnis kostet ein paar hundert Token) und bohrt nur dort nach, wohin das Reasoning zeigt. In den dokumentenlastigen Systemen, die ich für Finanz- und Versicherungskunden baue, summiert sich dieser Unterschied über eine Session erheblich.

Beide Ansätze habe ich an einem 300-seitigen Aufsichtsdokument verglichen, dokumentiert in meinem PageIndex-vs.-Vektordatenbank-Vergleich: PageIndex erreichte 98,7 % Genauigkeit auf FinanceBench, wo klassisches Vektor-RAG bei 60–80 % landet. Was ich damals unterschätzt habe, ist der Kontext-Nebeneffekt: Weniger, präziser gewählte Token im Fenster bedeuten weniger „Lost in the Middle"-Degradation, zusätzlich zum Genauigkeitsgewinn. Zwei Siege, eine Architekturentscheidung.

Wann Sie keinen Memory-Layer brauchen

Sie brauchen kein Memory-System, wenn Ihre Sessions kurz sind, Ihre Nutzer anonym oder Ihr Aufgabenzustand in eine Datenbankzeile passt. Diesen Abschnitt werden die Memory-Anbieter nicht schreiben — also schreibe ich ihn.

Der größte Teil des top-rankenden Contents zu Context Engineering stammt von Firmen, die Memory-Infrastruktur verkaufen: Mem0, Supermemory, Zep. Der Content ist oft gut. Er ist aber strukturell unfähig, Ihnen zu sagen, dass eine Postgres-Tabelle plus ein sauber designtes Retrieval-Tool geschätzt 70 % der Fälle löst, die als „Agent Memory" gepitcht werden. Die 70 % sind meine Schätzung aus den Audits dieses Jahres, keine Studie; ich würde mich freuen, wenn jemand dazu echte Zahlen veröffentlicht.

Mein Entscheidungsrahmen, in der Reihenfolge, in der ich ihn tatsächlich anwende:

1. Sessions unter ~10 Runden? Der reine Verlauf passt ins Fenster. Nichts tun.
2. Zustand ist strukturiert (Bestellstatus, Ticket-Felder, Nutzereinstellungen)? Datenbank plus Lese-Tool. Strukturierter Zustand in einem Memory-Blob ist ein Bug, kein Feature.
3. Session-übergreifende Personalisierung wirklich nötig? Erst jetzt Memory-Systeme evaluieren, mit einem zweiwöchigen Prototyp statt einem Plattform-Commitment.
4. Compliance- oder Audit-Anforderungen? (Bei meinen Banken- und Versicherungskunden entscheidet dieser Punkt.) Ein Memory-Layer, den Sie nicht pro Nutzer einsehen, exportieren und löschen können, ist ein DSGVO-Risiko. Prüfen Sie das vor dem Proof of Concept, nicht danach.

Im Februar habe ich den Agenten eines mittelständischen DACH-Versicherers auditiert, bei dem eine Memory-Plattform „für Personalisierung" eingebaut worden war. Katrin, die Data-Verantwortliche, hatte das Setup aus einem Pilotprojekt von 2025 geerbt. Es speicherte über 40 Fakten pro Nutzer und injizierte sie in jede Session, doch die Eval-Suite zeigte: Diese Personalisierung veränderte in unter 3 % der Gespräche das Ergebnis. Das Entfernen der Schicht senkte die Token-Kosten pro Session um rund ein Drittel und vereinfachte die Datenschutz-Folgenabschätzung erheblich. Das Team war nicht unfähig; es war den Standard-Ratschlägen von 2025 gefolgt. Die Standard-Ratschläge waren für diesen Fall falsch.

Heißt das, Memory-Layer sind überbewertet? Nicht ganz. Ich setze Mem0 aktuell in zwei Projekten ein, und dort verdient es seinen Platz. Es heißt: Die Entscheidung verdient einen echten Entscheidungsprozess, und „alle bauen gerade Memory ein" ist keiner.

Unsicher, auf welcher Seite des Rahmens Ihr System landet? Genau solche Fragen beantwortet mein KI-Readiness-Audit in einem festen zweiwöchigen Format — Architektur-Review inklusive, ohne langfristige Bindung.

Token-Ökonomie: Was Context Engineering wirklich spart

Bewusstes Kontext-Management senkt die Input-Token-Kosten in Agenten-Workloads typischerweise um 40–80 %, und der Effekt schlägt sich auch in der Latenz nieder, nicht nur in den Kosten. Das sind die zwei Zahlen, die CFO und Nutzer interessieren, also konkret:

Der Dokumenten-Agent, den ich dieses Frühjahr für einen Logistikkunden umgebaut habe (Modell der Claude-Sonnet-Klasse, ~2.000 Sessions/Tag), sah nach vier Wochen Kontext-Arbeit so aus:

Die Maßnahmen, nach Wirkung sortiert: Tool-Output-Trimming (der mit Abstand größte Hebel, ein Such-Tool ging von ~4.800 auf ~350 Token pro Aufruf), Compaction alle 8 Runden, und Referenzdokumente vom Vorladen auf On-Demand-Retrieval umgestellt. Kein Modell-Upgrade. Kein nennenswertes Prompt-Rewriting.

Öffentliche Benchmarks erzählen dieselbe Geschichte in größerem Maßstab: Sourcegraphs CodeScaleBench-Ergebnisse (März 2026) zeigten einen Sprung der Datei-Retrieval-Präzision von 0,140 auf 0,478 mit kontextbewusstem Tooling; Mem0 nennt bis zu 80 % Token-Reduktion bei langen Gesprächen. Ihre Zahlen werden abweichen. Die Richtung nicht.

Der Einstieg: eine 30-Tage-Sequenz

Beginnen Sie mit Messen, denn Kontext-Probleme sind unsichtbar, bis Sie sie loggen. Die Sequenz, die ich im ersten Monat eines Projekts fahre:

Woche 1 — instrumentieren. Token-Zahlen pro Runde, pro Tool-Aufruf und pro Kontext-Segment loggen (System, Verlauf, Retrieval, Tool-Output). Ein Budget, das Sie nicht sehen, können Sie nicht steuern. Mit vorhandener Observability aus meinem Produktions-Agenten-Guide ist das ein Nachmittag Arbeit.

Woche 2 — Tools trimmen. Tools nach zurückgegebenen Token sortieren. Die drei größten Sünder so umschreiben, dass sie nur liefern, was der Agent konsumiert. Das ist durchgängig die Arbeit mit dem höchsten ROI pro Stunde in der ganzen Disziplin.

Woche 3 — Compaction einbauen. Einen Zusammenfassungs-Checkpoint bei ~60 % Fensterauslastung implementieren. Den Compaction-Prompt wie Produktionscode schreiben; gegen eine Checkliste testen, welche Muss-Fakten ihn überleben.

Woche 4 — Retrieval und Memory evaluieren. Erst jetzt. Den Entscheidungsrahmen aus dem vorigen Abschnitt durchgehen. Wenn Memory seinen Platz verdient: zwei Wochen mit einem Anbieter prototypen, bevor Sie sich festlegen.

Langzeit-Evals gehören in jede dieser Wochen. Eine synthetische 30-Runden-Session, die prüft, ob der Agent die Constraints aus Runde 1 noch respektiert, findet Context Rot, bevor Ihre Nutzer es tun.

Das Fazit

Context Engineering ist das, wozu Prompt Engineering herangewachsen ist, als Agenten die Produktion erreichten: das bewusste Management einer endlichen, teuren, ungleich beachteten Ressource. Die vier Hebel (Retrieval, Memory, Compaction, Tool-Design) sind nicht exotisch. Die meisten Teams ziehen sie nur in der falschen Reihenfolge und kaufen eine Memory-Plattform, bevor sie ein einziges Tool-Output getrimmt haben.

Beginnen Sie mit Instrumentierung, stoppen Sie die Flut an der Quelle, und lassen Sie jedes Token im Fenster seinen Platz rechtfertigen. Meine Erfahrung aus den Projekten dieses Jahres: Teams, die so arbeiten, liefern Agenten, die billiger, schneller und — das überrascht mich immer noch ein wenig — messbar genauer sind.

Wenn Sie ein zweites Paar Augen für das Kontext-Budget Ihres Agenten wollen: Ich biete KI-Readiness-Audits mit festem Umfang für Unternehmen, die Agenten vom Pilot in die Produktion bringen. Zwei Wochen, konkrete Zahlen, kein Retainer. Oder starten Sie kostenlos — das Kontext-Audit-Arbeitsblatt deckt die erste Woche in Eigenregie ab.

---

Über den Autor: Pawel Owerczuk ist Entwickler für KI-Agenten und RAG-Systeme mit über 10 Jahren Software-Engineering-Erfahrung. Er begleitet Unternehmen in DACH und den Nordics vom KI-Pilot in die Produktion — Banken, Versicherungen, Automotive, Pharma. Über mich · LinkedIn · GitHub

Quellen: Anthropic — Effective context engineering for AI agents · Liu et al., Lost in the Middle (2023) · Sourcegraph — Context engineering guide + CodeScaleBench · Mem0 — Context engineering guide