Eine Zeit lang war „Prompt Engineering“ der Name, den wir der Kunst gaben, gute Ergebnisse aus großen Sprachmodellen herauszuholen. Das machte Sinn in den frühen Tagen. Die meisten Menschen nutzten Einzelinteraktionen, und der Haupthebel fühlte sich tatsächlich wie die Formulierung an: klarer fragen, ein Beispiel hinzufügen, das Format einschränken – und das Modell verhielt sich besser.
\nDieser Rahmen ist nun zu klein für das wirkliche Problem.
\nWenn ein KI-System im Produktivbetrieb versagt, liegt das Problem meist nicht darin, dass das Modell einen weiteren cleveren Satz im System-Prompt gebraucht hätte. Das Problem ist, dass das Modell nicht die richtigen Informationen gesehen hat, zu viele irrelevante Informationen gesehen hat, die richtigen Informationen in der falschen Form gesehen hat oder den richtigen Zustand nicht von einem Schritt zum nächsten übertragen konnte. Mit anderen Worten: Das Problem war nicht nur der Prompt. Das Problem war die gesamte Kontext-Pipeline.
\nDeshalb hat sich der Begriff Context Engineering durchgesetzt. Die Formulierung gelangte Mitte 2025 in den Mainstream der KI-Diskussion, als Tobi Lütke und Andrej Karpathy argumentierten, dass „Prompt Engineering“ die wirkliche Arbeit, die in den Aufbau zuverlässiger LLM-Systeme fließt, herunterspiele.[1] Aber die zugrunde liegende Disziplin ist älter als der Name. Wenn Sie RAG, Tool Calling, Gedächtnissysteme, Zusammenfassungen oder Evaluierungs-Loops gebaut haben, haben Sie bereits Teile von Context Engineering gemacht. Was sich geändert hat, ist, dass wir endlich einen Namen haben, der den gesamten Job beschreibt.
\nWenn Sie das einfachstmögliche Bild wollen: Context Engineering ist die Schicht zwischen der Außenwelt und dem Arbeitsgedächtnis des Modells.
\nflowchart TD\n U[\"User request\"] --> CE[\"Context engine\"]\n\n I[\"Instructions and policies\"] --> CE\n R[\"Retrieved knowledge\"] --> CE\n M[\"Memory and saved state\"] --> CE\n T[\"Tool definitions and results\"] --> CE\n H[\"Recent conversation history\"] --> CE\n\n CE --> W[\"Model context window\"]\n W --> L[\"LLM reasons and acts\"]\n L --> O[\"Answer or tool call\"]\n O --> S[\"New memory, logs, and state\"]\n S --> CE\nDas ist das ganze Spiel.
\nDas Modell ist die Reasoning-Engine. Die Context Engine entscheidet, worüber das Modell nachdenken darf.
\nEin Grund, warum der Begriff Anklang findet, ist, dass er mehrere Fäden zusammenführt, die sich bisher getrennt entwickelt hatten.
\nRetrieval-Augmented Generation, oder RAG, lehrte uns, dass Modelle zur Inferenzzeit Zugriff auf externes Wissen brauchen.[2] ReAct lehrte uns, dass Reasoning und Handeln besser funktionieren, wenn Modelle Tools aufrufen, Ergebnisse beobachten und von dort weitermachen können.[3] Gedächtnisforschung lehrte uns, dass langlaufende Assistenten Indexierung, Retrieval und Lesestrategien brauchen, statt endloser Transkript-Akkumulation.[4] Long-Context-Evaluation zeigte, dass einfach mehr Tokens in ein Modell zu stopfen nicht dasselbe ist wie besseres Arbeitsgedächtnis zu geben.[5][6][7]
\nSo betrachtet, ist Context Engineering kein Ersatz für diese Ideen. Es ist der Schirm über ihnen.
\nDieser Schirm ist wichtig, weil moderne KI-Systeme nicht mehr isolierte Prompts sind. Sie sind dynamische Systeme, die Anweisungen, Dokumente, strukturierte Daten, Tool-Outputs und vorherigen Zustand zu einem temporären Kontextfenster für den nächsten Schritt zusammenbauen. LangChain beschrieb das treffend, als es Context Engineering als die Arbeit definierte, die richtigen Informationen und Tools im richtigen Format bereitzustellen, damit das LLM die Aufgabe plausibel erledigen kann.[8]
\nDie Formulierung „plausibel die Aufgabe erledigen“ leistet dort viel Arbeit. Es ist der richtige Test.
\nWenn ein Agent versagt, sollte die erste Frage nicht lauten: „Wie mache ich den Prompt schlauer?“
\nDie erste Frage sollte lauten: „Habe ich dem Modell tatsächlich gegeben, was es zum Erfolg braucht?“
\nPrompt Engineering ist nach wie vor wichtig. Es ist nur zu einem Teilbereich einer größeren Disziplin geworden.
\nDas alte mentale Modell war:
\n| Prompt Engineering | \nContext Engineering | \n
|---|---|
| Bessere Anweisungen schreiben | \nDie volle Informationsumgebung aufbauen | \n
| Fokus auf eine einzelne Anfrage | \nFokus auf Mehrschritt-Systeme | \n
| Größtenteils statisch | \nDynamisch und zustandsbehaftet | \n
| Wortlaut optimieren | \nAuswahl, Struktur, Gedächtnis und Tools optimieren | \n
| Einen einzelnen Modellaufruf verbessern | \nDen gesamten Loop verbessern | \n
Dieser Unterschied wird offensichtlich, sobald Sie einen Agenten bauen.
\nAngenommen, Sie bauen einen Support-Agenten für Enterprise-Software. Der Nutzer fragt: „Warum laufen unsere API-Requests in Timeouts?“
\nWenn Sie nur in Prompt-Kategorien denken, könnten Sie den Wortlaut verbessern:
\nDas sind gute Verbesserungen. Aber sie reichen nicht.
\nDie wirklichen Systemfragen sind schwieriger:
\nDas ist Context Engineering.
\nDer Prompt ist ein einzelner Posten darin.
\nIn der Praxis umfasst Kontext alles, was das Modell zur Inferenzzeit sieht, nicht nur den sichtbaren Prompt.[8][9]
\nDas bedeutet normalerweise:
\nDeshalb ist die Formulierung „das Kontextfenster füllen“ so zentral geworden. Das Kontextfenster ist nicht nur ein Ort, an den Text kommt. Es ist das temporäre Arbeitsgedächtnis des Modells. Alles, was hineingelangt, konkurriert um Aufmerksamkeit.
\nUnd Konkurrenz ist das Schlüsselwort.
\nJedes zusätzliche Token ist nicht nur zusätzliche Information. Es ist auch zusätzliche Ablenkung.
\nEiner der häufigsten Irrtümer auf dem aktuellen KI-Markt ist, dass größere Kontextfenster Context Engineering weniger wichtig gemacht hätten.
\nDie Forschung zeigt in die entgegengesetzte Richtung.
\nLost in the Middle zeigte, dass Modelle lange Kontexte oft ungleichmäßig nutzen, besser abschneiden, wenn relevante Informationen am Anfang oder Ende stehen, und schlechter, wenn wichtige Informationen in der Mitte liegen.[5] Die Long-Context-RAG-Studie von Databricks fand heraus, dass zwar mehr abgerufene Dokumente helfen können, aber nur eine kleine Zahl state-of-the-art-Modelle starke Performance über 64k Tokens hinaus beibehielt.[6] Chromas Context Rot-Bericht ging noch weiter: Selbst einfache Aufgaben werden mit wachsender Eingabelänge weniger zuverlässig, besonders wenn Mehrdeutigkeit und Ablenkungen hinzukommen.[7]
\nDies ist der Teil, den viele Teams auf die harte Tour lernen.
\nGrößere Fenster beseitigen nicht die Notwendigkeit zu wählen. Sie machen die Kosten schlechter Entscheidungen zunächst weniger offensichtlich und später schmerzhafter.
\nEin langer Prompt kann auf mindestens vier verschiedene Arten scheitern:
\nDeshalb geht es bei Context Engineering nicht darum, Tokens zu maximieren. Es geht darum, die Signaldichte im Kontextfenster zu maximieren.
\nHier kommt eine der besten jüngsten Ideen ins Spiel.
\nJason Liu argumentierte, dass der nächste Schritt nach klassischem Chunk-basiertem RAG darin besteht, nicht nur an „die ähnlichsten Passagen“ zu denken, sondern an die Form des Suchraums.[10] Sein Rahmen ist besonders nützlich, weil er eine Entwicklung aufzeichnet, durch die viele Teams bereits gehen:
\nDie ersten drei sind Verbesserungen dessen, was abgerufen wird.
\nDie vierte ist interessanter. Sie verbessert, was der Agent über das Korpus selbst lernt.
\nFacets geben dem Modell so etwas wie periphere Sicht. Statt nur die Top-Chunks zurückzugeben, kann das System auch aggregierte Metadaten zurückgeben:
\nDas ist wichtig, weil Similarity Search darauf verzerrt ist, was am leichtesten zu matchen ist, nicht unbedingt was am wichtigsten zu prüfen ist.[10] Ein Retrieval-System mag gut dokumentierte, gelöste Incidents überrepräsentieren und spärliche, noch offene Incidents unterrepräsentieren. Eine juristische Suche mag unterschriebene Verträge überrepräsentieren und die unsignierten verstecken, die tatsächlich Aufmerksamkeit brauchen. Facets helfen dem Agenten, nicht nur „was gematcht hat“ zu sehen, sondern „was sonst noch in der Nähe existiert“.
\nDas ist ein großer konzeptioneller Wandel.
\nRAG ging meist um Retrieval.
\nContext Engineering geht zunehmend um Navigation.
\nDer einfachste Weg, Context Engineering greifbar zu machen, ist es, in die tatsächlichen Jobs aufzuteilen, die es erledigt.
\nDie erste Aufgabe ist zu entscheiden, was überhaupt ins Fenster gehört.
\nDas umfasst Retrieval, Ranking, Filtering, Quellenwahl und Frische-Checks. Es klingt offensichtlich, aber hier wird noch immer eine enorme Qualität gewonnen oder verloren. Benchmarks wie BRIGHT zeigen, dass realistisches Retrieval viel schwieriger ist als oberflächliches semantisches Matching vermuten lässt.[11] Wenn Ihre Retrieval-Qualität schwach ist, wird keine Menge nachgelagerter Prompt-Polierung das Ergebnis vollständig retten.
\nSelection ist nicht nur „relevante Chunks finden“. Es ist:
\nGute Systeme holen oft weniger als naive Systeme, aber bewusster.
\nDie zweite Aufgabe ist zu entscheiden, wie der gewählte Kontext repräsentiert wird.
\nDie gleiche Information kann hilfreich oder nutzlos sein, je nach Formatierung. Anthropics Tool-Use-Guidance ist da explizit: Tool-Beschreibungen und Interfaces prägen das Modellverhalten stark.[9] Long-Context-Prompting-Guidance gibt ähnliche Empfehlungen für XML-Tagging, Quellenlabeling und klar getrennte Dokumentabschnitte.[12]
\nIn der Praxis bedeutet Struktur:
\nEin kurzes, gut gelabeltes Ergebnis übertrifft oft einen riesigen JSON-Blob.
\nDie dritte Aufgabe ist, Kontext zu reduzieren, ohne das Wichtige zu zerstören.
\nHier werden viele Agentensysteme entweder viel besser oder viel schlechter.
\nKompression kann bedeuten:
\nOpenAIs Prompt-Caching-Dokumentation zeigt, dass Prompt-Reihenfolge ökonomisch wie kognitiv wichtig ist: Statische, geteilte Präfixe sind billiger und schneller, wenn sie vorne platziert werden, weil Cache-Hits von exakter Präfix-Wiederverwendung abhängen.[13] OpenAIs neuere Responses-API-Arbeit an Compaction treibt dieselbe Idee weiter, indem langlaufende Agenten-Historie als etwas behandelt wird, das vor dem Füllen des Fensters in eine token-effizientere Repräsentation komprimiert werden sollte.[14]
\nKompression ist nicht optional. Die einzige Frage ist, ob Sie sie bewusst machen oder das Kontextfenster sich selbst degradieren lassen.
\nDie vierte Aufgabe ist zu entscheiden, was über die aktuelle Wendung hinaus persistieren soll.
\nHier machen viele Teams denselben Fehler: Sie verwechseln Gedächtnis mit Transkript-Aufbewahrung.
\nAber gutes Gedächtnis ist nicht „alles für immer behalten“. LongMemEval rahmt Langzeitgedächtnis als Drei-Stufen-Problem: Indexierung, Retrieval und Lesen.[4] Das ist der richtige Weg, darüber nachzudenken. Ein Gedächtnissystem sollte dem Modell helfen, die richtige vorherige Tatsache im richtigen Moment wiederzufinden, nicht es in der kompletten Vergangenheit zu ertränken.
\nDas führt zu einer nützlichen Unterscheidung:
\nWenn alles im Arbeitsgedächtnis bleibt, wird das Modell abgelenkt.\nWenn alles hinausgeschoben wird, verliert das Modell den Zusammenhang.
\nContext Engineering entscheidet, was in welche Schicht gehört.
\nDie fünfte Aufgabe ist, Tools für das Modell lesbar zu machen.
\nDas ist ein unterschätzter Teil der Disziplin. Eine Tool-Oberfläche ist nicht nur Software-API-Design. Sie ist auch Kontext-Design.
\nDas Modell muss verstehen:
\nDeshalb sind Tool-Beschreibungen so wichtig.[9] Deshalb ist Jason Lius Betonung von Tool-Ergebnissen wichtig.[10] Der Output eines Tools beantwortet nicht nur die aktuelle Anfrage. Er lehrt den Agenten, wie er über die nächste Anfrage nachdenken soll.
\nWenn die Tool-Oberfläche durch ein Protokoll wie MCP standardisiert wird, wird das noch wichtiger. MCP macht es einfacher, Tools, Ressourcen und Prompts mit LLM-Anwendungen zu verbinden, aber es entscheidet nicht, welche Informationen aufbereitet, wie gefiltert oder wie viel davon in den nächsten Modellaufruf injiziert werden soll.[15] Das Protokoll ist die Infrastruktur. Context Engineering bleibt die Kunst.
\nDie sechste Aufgabe ist zu entscheiden, wann Kontext nicht geteilt werden soll.
\nDas ist einer der größten Unterschiede zwischen Spielzeug-Demos und Produktions-Agenten.
\nManchmal ist die richtige Antwort nicht ein größerer geteilter Prompt. Es sind mehrere kleinere Prompts mit isolierten Scopes.
\nAnthropics Multi-Agent-Research-System ist ein starkes Beispiel.[16] Ihre Subagenten laufen parallel mit separaten Kontextfenstern, was ihnen hilft, verschiedene Zweige eines Problems zu erkunden, ohne sich gegenseitig mit jedem Zwischenschritt zu kontaminieren. LangChain beschreibt ein ähnliches Muster unter „isolate“: Manchmal ist der beste Weg, Agenten-Zuverlässigkeit zu verbessern, Kontexte zu splitten statt sie anzuhäufen.[17]
\nDas ist wichtig, weil geteilter Kontext versteckte Kosten hat. Er schafft Pfadabhängigkeit. Ein einzelner schlechter Zweig kann den nächsten beeinflussen, und den nächsten, und den nächsten.
\nIsolation ist ein Weg, den Schadensradius zu begrenzen.
\n2025 war Context Engineering meist ein nützlicher Name für ein Problem, das die Leute bereits spürten. 2026 beginnt es, sich zu einer Architektur zu verfestigen.
\nDer erste große Wandel ist, dass Builder dauerhaften Zustand außerhalb des rohen Kontextfensters verschieben. Anthropics Context Editing und Memory Tool trennen explizit, was live im Arbeitsfenster bleibt, von dem, was über Sessions hinweg persistieren soll.[18] OpenAIs Januar-2026-Cookbook zur Personalisierung macht denselben Schritt in anderer Form: strukturierte Zustandsobjekte, die über Runs hinweg persistieren und bewusst zu Beginn jedes Runs zurück ins Arbeitsgedächtnis injiziert werden.[19] OpenAIs Responses API treibt das einen Schritt weiter mit nativer Compaction, sodass langlaufende Agenten-Loops nicht von jedem Team verlangen, ein eigenes Zusammenfassungssubsystem von Grund auf zu bauen.[14]
\nAnthropics Managed Agents macht das zugrunde liegende Muster ungewöhnlich explizit: Die Session ist nicht das Kontextfenster des Modells.[20] Das ist eine kritische Idee für 2026. Das Fenster ist temporäres Arbeitsgedächtnis. Das Session-Log ist das dauerhafte Objekt. Das Harness entscheidet, wie dieser dauerhafte Kontext geschnitten, komprimiert und für den nächsten Modellaufruf rehydriert wird.
\nDer zweite Wandel ist, dass Retrieval just in time und oberflächen-nativer wird. Statt jeden möglicherweise relevanten Token vorzuladen, geben Teams Agenten Retrieval-Oberflächen, die sie bereits bedienen können. Mintlify's ChromaFs ist ein gutes Beispiel: Statt eine volle Sandbox für Dokumenten-Retrieval zu booten, präsentiert es Docs als virtuelles Dateisystem, navigierbar mit ls, cat und grep, was die p90-Session-Erstellung von etwa 46 Sekunden auf etwa 100 Millisekunden senkt.[21] Turso's AgentFS treibt dieselbe Intuition in Richtung allgemeiner Agenten-Ausführung: eine Copy-on-Write-Dateisystem-Abstraktion mit portabler Single-File-Speicherung und eingebautem Auditing.[22]
Der dritte Wandel ist, dass Context Graphs zu einer Implementierungsrichtung werden, nicht nur einer Metapher. Foundation Capitals These machte den Begriff sichtbar, aber die stärkere Behauptung ist architektonisch: Wenn Agenten im Ausführungspfad sitzen, können sie Entscheidungsspuren als dauerhafte Artefakte erfassen, nicht nur finale Outputs emittieren.[26][27] Open-Source-Systeme wie Graphiti und kommerzielle Plattformen wie Zep operationalisieren das als temporale Kontext-Graphen mit Gültigkeitsfenstern, Provenanz-Episoden und hybridem Retrieval über Semantik, Keywords und Graph-Struktur.[23] TrustGraph verfolgt einen verwandten Ansatz, indem es Kontext als versioniertes Artefakt behandelt: Graph, Embeddings, Evidenz und Policies gebündelt in portable „Context Cores“, die wie Build-Outputs promoted oder zurückgerollt werden können.[24][25]
\nDer vierte Wandel ist, dass Context Engineering nun in realer Software-Praxis sichtbar wird, nicht nur in Plattform-Blogs. Die MSR-Papier 2026 zu Context Engineering in Open-Source-Software untersuchte 466 Repositories und fand, dass KI-Kontextdateien wie AGENTS.md sich verbreiten, aber noch keine stabile Inhaltsstruktur haben.[28] Das ist wichtig, weil es einen Schritt von der Theorie zu operativen Artefakten markiert. Kontext ist nicht länger nur etwas, das zur Laufzeit inferiert wird. Er wird verfasst, versioniert, reviewed und gemined als Teil des Software-Lebenszyklus.
Wenn Sie das 2026-Mentalmodell in einem Bild wollen, sieht es so aus:
\nflowchart LR\n E[\"Session log / events\"] --> A[\"Context assembler\"]\n F[\"Files, docs, and tools\"] --> A\n G[\"Context graph / memory\"] --> A\n P[\"Policies and AGENTS.md\"] --> A\n\n A --> W[\"Working context window\"]\n W --> X[\"Agent action\"]\n\n X --> E\n X --> G\nDas ist eine sehr andere Architektur als „Prompt + Vektor-Suche“.
\nEin Grund, warum diese Diskussion trübe wird, ist, dass Leute Context Engineering und Context Graph verwenden, als ob sie dasselbe bedeuten. Tun sie nicht.
\nContext Engineering ist die breitere Disziplin. Es ist die Arbeit zu entscheiden, was ins nächste Kontextfenster kommt, was draußen bleibt, was komprimiert und was bei Bedarf abgerufen wird.
\nEin Context Graph ist ein mögliches Langzeitgedächtnis-Substrat innerhalb dieses größeren Systems.
\nDiese Unterscheidung ist wichtig, weil nicht jeder nützliche Agent einen Context Graph braucht. Ein Dokumentationsassistent über größtenteils statische Inhalte mag gutes Retrieval, Tool-Design und Compaction brauchen, aber keinen Graphen. Ein Coding-Agent kommt überraschend weit mit Repository-Anweisungen, einem dauerhaften Session-Log und einer Dateisystem-Abstraktion.[20][21][22][28]
\nContext Graphs werden überzeugend, wenn das Problem vier Eigenschaften hat:
\nDeshalb ist die beste Definition eines Context Graphs meiner Ansicht nach nicht „eine Graphdatenbank für KI“. Es ist eine dauerhafte Repräsentation von Präzedenz.
\nDeshalb sind Entscheidungsspuren so wichtig. Foundation Capitals Rahmen ist hier nützlich: Regeln sagen dem Agenten, was im Allgemeinen passieren sollte; Entscheidungsspuren sagen ihm, was in einem spezifischen Fall unter realen Einschränkungen mit realen Ausnahmen passiert ist.[26] Sobald diese Spuren über Entitäten und Zeit verknüpft sind, bekommt man etwas viel Wertvolleres als generisches Gedächtnis. Man bekommt durchsuchbares Urteilsvermögen.
\nWenn ich heute einen ernsthaften Context-Engineering-Stack bauen würde, würde ich nicht mit dem Graphen anfangen. Ich würde mit den Interfaces und Promotion-Regeln anfangen.
\nJede Aktion, jedes Tool-Ergebnis, jede Beobachtung und jedes wichtige Zwischenartefakt sollte in einem append-only Session-Log oder Event-Store landen. Das ist Ihr wiederherstellbares Kontextobjekt.[14][20]
\nVerwechseln Sie nicht das aktive Kontextfenster mit der Source of Truth.
\nDas Fenster ist zum Reasoning.\nDie Session ist für Recovery, Replay, Debugging und selektive Rehydration.
\nDer Assembler sollte explizit verwalten:
\nDas ist die Schicht, die entscheidet, was das Modell jetzt sieht. Sie sollte beobachtbar, testbar und billig zu ändern sein.[18][19][14]
\nGeben Sie dem Modell zuerst leichtgewichtige Handles: Dateipfade, Objekt-IDs, URLs, Query-Templates, Ticket-IDs, Incident-IDs. Dann lassen Sie es Details nur holen, wenn nötig.[9][18][21]
\nHier werden Dateisysteme, MCP-Tools, Search-APIs und strukturierte Queries wertvoller als riesige Top-K-Dumps.
\nNicht alles sollte Gedächtnis werden.
\nIch würde vier Klassen von Artefakten promoten:
\nAlles andere sollte im Session-Log bleiben, bis es beweist, dass es eine Promotion verdient.
\nDas ist der Teil, den viele Teams invertieren.
\nDer Graph sollte nicht Ihr rohes Transkript in Graph-Form sein. Er sollte die kuratierte Schicht sein, die über Sessions und unterhalb der Echtzeit-Assembly sitzt:
\nWenn Sie den Promotion-Schritt überspringen, wird der Graph zu einer Müllhalde.\nWenn Sie Promotion richtig hinbekommen, wird der Graph zum Gedächtnis dafür, wie die Organisation tatsächlich reasoned.[23][26]
\nBis 2026 ist eine der vielversprechendsten Ideen, Kontext als versioniertes Artefakt zu behandeln. In Softwareprojekten zeigt sich das als AGENTS.md und andere repository-spezifische Kontextdateien.[28] In graph-nativen Systemen zeigt es sich als Context Cores: portable Bündel aus Ontologie, Graph-Struktur, Embeddings, Provenanz und Retrieval-Policy.[24][25]
Das ist wichtig, weil Kontextänderungen dieselbe operative Disziplin brauchen wie Codeänderungen:
\nSobald Kontext ein Artefakt wird, wird er regierbar.
\nSie brauchen beides:
\nDas sind nicht dieselben Dinge.
\nIch will wissen:
\nWenn Sie diese Fragen nicht beantworten können, debuggen Sie immer noch im Dunkeln Prompts.
\nWenn Sie versuchen zu bewerten, wo Ihr eigenes System steht, ist dieses Reifegradmodell nützlicher als abstrakte Definitionen.
\nSie haben einen System-Prompt, eine Nutzernachricht und vielleicht ein paar Beispiele.
\nDas kann für enge Aufgaben überraschend gut funktionieren. Es bricht schnell, wenn die Aufgabe frisches Wissen, Persistenz oder Tools braucht.
\nSie fügen zur Laufzeit Dokumente hinzu.
\nHier hören viele Teams auf. Hier beginnen auch viele Teams, die Grenzen naiven Chunkings, Rankings und Kontext-Bloats zu sehen.
\nSie verwalten jetzt absichtlich Historie, Tool-Ergebnisse, Gedächtnis und Formatierung.
\nDas ist das erste Level, wo „Context Engineering“ ein nützlicher Begriff wird, weil das System nicht mehr nur Prompt plus Retrieval ist. Es baut dynamisch mehrere Formen von Kontext zusammen.
\nDas System ändert, wie es Kontext aufbaut, basierend auf der Aufgabe.
\nEs kann:
\nAn diesem Punkt ist Kontext-Konstruktion Teil der Kernlogik der Anwendung.
\nDas System behandelt Kontext als first-class Engineering Surface.
\nEs hat:
\nHin bewegen sich die stärksten Produktionssysteme.
\nWenn ich die ganze Disziplin auf eine Checkliste reduzieren müsste, würde sie so aussehen:
\nKeines davon ist glamourös. Genau deshalb zählt es.
\nPrompt Engineering wurde populär, weil es wie eine Abkürzung klang.
\nContext Engineering zählt, weil es die tatsächliche Arbeit beschreibt.
\nDer Schwerpunkt in der KI verschiebt sich.
\nDie Grenzfrage war früher: Wie schlau ist das Modell?
\nDie angewandte Frage ist zunehmend: Was bekommt das Modell zu sehen, bevor es handeln muss?
\nDas ist ein anderes Engineering-Problem. Es geht weniger um einzelne Prompts und mehr um Systemdesign. Weniger um Formulierung und mehr um Informationsfluss. Weniger um One-Shot-Output-Qualität und mehr darum, ob ein Agent über Zeit zuverlässig bleiben kann.
\nDeshalb wird Context Engineering als Disziplin weiter wachsen. Je besser die Modelle werden, desto mehr der verbleibenden Fehler sehen wie Kontextfehler aus. Fehlender Zustand. Falsches Tool. Schlechtes Retrieval. Aufgeblähte Historie. Schlechte Formatierung. Widersprüchliche Evidenz. Schwaches Gedächtnis. Unbegrenzte Loops.
\nDie Ironie ist, dass KI-Systeme dadurch eher wie klassische Software wirken, nicht weniger. Wir sind zurück dabei, Pipelines, Interfaces, Zustandsmaschinen, Speicherhierarchien, Caches und Observability-Schichten zu bauen. Das Neue ist, dass all diese Stücke jetzt im Dienste einer probabilistischen Reasoning-Engine existieren.
\nDer Name mag neu sein. Die Richtung nicht.
\nZuverlässige KI-Systeme werden von Teams gebaut, die Kontext als first-class Product Surface behandeln.
\nAlle anderen werden das Modell weiterhin als unzuverlässig bezeichnen.
\nReferences:
\n[1] Simon Willison. (2025, June 27). Context engineering.
\n[2] Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.
\n[3] Yao, S. et al. (2023). ReAct: Synergizing Reasoning and Acting in Language Models.
\n[4] Wu, D. et al. (2025). LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory.
\n[5] Liu, N. F. et al. (2023). Lost in the Middle: How Language Models Use Long Contexts.
\n[6] Leng, Q. et al. (2024). Long Context RAG Performance of Large Language Models.
\n\n[8] LangChain. (2025, June 23). The rise of \"context engineering\".
\n[9] Anthropic. How to implement tool use.
\n[10] Jason Liu. (2025, August 27). Beyond Chunks: Why Context Engineering is the Future of RAG.
\n\n[12] Anthropic. Long context prompting tips.
\n\n\n[15] Model Context Protocol. What is the Model Context Protocol (MCP)?
\n[16] Anthropic. (2025, June 13). How we built our multi-agent research system.
\n[17] LangChain. (2025, July 2). Context Engineering.
\n[18] Anthropic. (2025, September 29). Managing context on the Claude Developer Platform.
\n\n[20] Anthropic. Scaling Managed Agents: Decoupling the brain from the hands.
\n[21] Mintlify. (2026, March 24). How we built a virtual filesystem for our Assistant.
\n[22] Turso. AgentFS.
\n[23] Zep. Graphiti: Build Real-Time Knowledge Graphs for AI Agents.
\n[24] TrustGraph. The context development platform.
\n[25] TrustGraph. Working with Context Cores.
\n[26] Gupta, J., and Garg, A. (2025, December 22). AI's trillion-dollar opportunity: Context graphs.
\n[27] Garg, A. (2026, January 16). Why context graphs are the missing layer for AI.
\n", "source_hash": "sha256:43286410ec2f1b23129ef8d7330ac9e09e780a8159635d34658ade10aac0581a", "model": "moonshotai/kimi-k2.6", "generated_at": "2026-05-31T02:56:21.590959+00:00" }