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 Leute nutzten Einzelinteraktionen, und der Haupthebel fühlte sich tatsächlich wie Formulierung an: klarer fragen, ein Beispiel hinzufügen, das Format einschränken – und das Modell verhielt sich besser.
\nDieser Rahmen ist jetzt zu klein für das wirkliche Problem.
\nWenn ein KI-System in der Produktion versagt, liegt das Problem meist nicht darin, dass das Modell einen cleveren Satz mehr im System-Prompt gebraucht hätte. Das Problem ist, dass das Modell die richtigen Informationen nicht gesehen hat, zu viele irrelevante Informationen gesehen hat, die richtigen Informationen im falschen Format 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.
\nDarum 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 unterschätzt, die in den Aufbau zuverlässiger LLM-Systeme fließt.[1] Aber die zugrunde liegende Disziplin ist älter als der Name. Wenn Sie RAG, Tool Calling, Memory-Systeme, 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 so stark ankommt, ist, dass er mehrere Stränge 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] Memory-Forschung lehrte uns, dass langlaufende Assistenten Indexierung, Retrieval und Lese-Strategien brauchen, anstatt endlos Transkripte anzuhäufen.[4] Long-Context-Evaluierung zeigte, dass einfach mehr Tokens in ein Modell zu stopfen nicht dasselbe ist wie ihm ein 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 keine isolierten Prompts mehr 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 immer noch wichtig. Es ist nur zu einer Teilmenge einer größeren Disziplin geworden.
\nDas alte mentale Modell war:
\n| Prompt Engineering | \nContext Engineering | \n
|---|---|
| Bessere Anweisungen schreiben | \td>\nDie volle Informationsumgebung aufbauen | \n
| Fokus auf eine einzelne Anfrage | \nFokus auf Multi-Step-Systeme | \n
| Meist 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:
\nDarum ist die Formulierung „das Kontextfenster füllen“ so zentral geworden. Das Kontextfenster ist nicht nur ein Ort, wo Text hinkommt. 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: Sie performen besser, wenn relevante Informationen am Anfang oder Ende stehen, und schlechter, wenn wichtige Informationen in der Mitte sitzen.[5] Databricks' Long-Context-RAG-Studie 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 hielt.[6] Chromas Context Rot-Bericht ging noch weiter: Selbst einfache Aufgaben werden weniger zuverlässig, wenn die Eingabelänge wächst, besonders wenn Mehrdeutigkeit und Ablenkungen eingeführt werden.[7]
\nDas 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 zuerst weniger offensichtlich und später schmerzhafter.
\nEin langer Prompt kann auf mindestens vier verschiedene Arten scheitern:
\nDarum 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üngeren 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 Progression aufzeichnet, die viele Teams bereits durchlaufen:
\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. Anstatt 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 signierte 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 Shift.
\nRAG ging meist um Retrieval.
\nContext Engineering geht zunehmend um Navigation.
\nAm einfachsten wird Context Engineering konkret, wenn man es in die tatsächlichen Jobs zerlegt, die es erledigt.
\nDie erste Aufgabe ist zu entscheiden, was überhaupt ins Fenster verdient.
\nDas umfasst Retrieval, Ranking, Filtering, Quellenwahl und Freshness-Checks. Es klingt offensichtlich, aber hier wird noch immer enorm viel 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 downstream Prompt-Polishing das Ergebnis vollständig retten.
\nSelection ist nicht nur „relevante Chunks finden“. Es ist:
\nGute Systeme holen oft weniger als naive Systeme, aber dafür 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 formen das Modellverhalten stark.[9] Long-Context-Prompting-Guidance macht ähnliche Empfehlungen für XML-Tagging, Quellenlabeling und klar getrennte Dokumentabschnitte.[12]
\nIn der Praxis bedeutet Struktur:
\nEin kurzes, gut gelabeltes Ergebnis schlägt 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.
\nCompression kann bedeuten:
\nOpenAIs Prompt-Caching-Dokumentation zeigt, dass Prompt-Reihenfolge sowohl ökonomisch als auch kognitiv wichtig ist: Statische, geteilte Prefixes sind billiger und schneller, wenn sie vorne platziert werden, weil Cache-Hits von exakter Prefix-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]
\nCompression 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 Memory-System 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 Working Memory bleibt, wird das Modell abgelenkt.\nWenn alles hinausgeschoben wird, verliert das Modell Kontinuität.
\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:
\nDarum sind Tool-Beschreibungen so wichtig.[9] Darum ist auch 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 werden sollen, wie sie gefiltert werden oder wie viel davon in den nächsten Modellaufruf injiziert werden soll.[15] Das Protokoll ist die Infrastruktur. Context Engineering bleibt das Handwerk.
\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 Zwischendetail 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 einen versteckten Kostenpunkt hat. Er schafft Pfadabhängigkeit. Ein einzelner schlechter Zweig kann den nächsten Schritt beeinflussen, und den nächsten, und den nächsten.
\nIsolation ist ein Weg, die Blast Radius zu begrenzen.
\n2025 war Context Engineering meist ein nützlicher Name für ein Problem, das Leute bereits spürten. 2026 beginnt es, sich zu einer Architektur zu verfestigen.
\nDer erste große Shift ist, dass Builder dauerhaften Zustand außerhalb des rohen Kontextfensters verschieben. Anthropics Context-Editing- und Memory-Tool trennen explizit, was live im Working Window bleibt, von dem, was über Sessions persistieren soll.[18] OpenAIs Januar-2026-Cookbook zur Personalisierung macht denselben Move in anderer Form: strukturierte Zustandsobjekte, die über Runs persistieren und bewusst zu Beginn jedes Runs zurück ins Working Memory injiziert werden.[19] OpenAIs Responses API treibt das dann mit nativer Compaction einen Schritt weiter, damit langlaufende Agenten-Loops nicht von jedem Team ein eigenes Zusammenfassungs-Subsystem von Grund auf bauen müssen.[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 2026-Idee. Das Fenster ist transientes Arbeitsgedächtnis. Das Session-Log ist das dauerhafte Objekt. Der Harness entscheidet, wie dieser dauerhafte Kontext geschnitten, komprimiert und für den nächsten Modellaufruf rehydriert wird.
\nDer zweite Shift ist, dass Retrieval just in time und interface-nativer wird. Anstatt jeden möglicherweise relevanten Token vorzuladen, geben Teams Agenten Retrieval-Oberflächen, die sie bereits bedienen können. Mintlifys ChromaFs ist ein gutes Beispiel: Statt einen vollen Sandbox für Dokumenten-Retrieval zu booten, präsentiert es Docs als virtuelles Dateisystem, navigierbar mit ls, cat und grep, was p90 Session Creation 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 Shift 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 Validity Windows, Provenance-Episoden und hybridem Retrieval über Semantik, Keywords und Graph-Struktur.[23] TrustGraph geht einen verwandten Ansatz, indem es Kontext als versioniertes Artefakt behandelt: Graph, Embeddings, Evidence und Policies gebündelt in portable „Context Cores“, die wie Build-Outputs promoted oder zurückgerollt werden können.[24][25]
\nDer vierte Shift ist, dass Context Engineering jetzt in realer Software-Praxis sichtbar ist, nicht nur in Plattform-Blogs. Die 2026er-MSR-Arbeit über 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 Move von 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 2026er-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 matschig wird, ist, dass Leute Context Engineering und Context Graph so 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 wird und was on demand 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 Graphen werden überzeugend, wenn das Problem vier Eigenschaften hat:
\nDarum ist die beste Definition eines Context Graphen meiner Meinung nach nicht „eine Graphdatenbank für KI“. Es ist eine dauerhafte Repräsentation von Präzedenz.
\nDarum sind auch Decision Traces so wichtig. Foundation Capitals Rahmen ist hier nützlich: Regeln sagen dem Agenten, was im Allgemeinen passieren sollte; Decision Traces sagen ihm, was in einem spezifischen Fall unter realen Einschränkungen mit realen Ausnahmen passiert ist.[26] Sobald diese Traces ü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 managen:
\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 ziehen, 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 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 zur Müllhalde.\nWenn Sie Promotion richtig machen, wird der Graph zum Gedächtnis dafür, wie die Organisation tatsächlich reasoniert.[23][26]
\nBis 2026 ist eine der vielversprechendsten Ideen, Kontext als versioniertes Artefakt zu behandeln. In Software-Projekten 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, Provenance 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 dasselbe.
\nIch will wissen:
\nWenn Sie diese Fragen nicht beantworten können, debuggen Sie immer noch Prompts im Dunkeln.
\nWenn Sie versuchen, einzuschätzen, 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.
\nDas ist, wo viele Teams aufhören. Es ist auch, wo viele Teams die Limitationen von naivem Chunking, Ranking und Context Bloat sehen.
\nSie managen 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 länger nur Prompt plus Retrieval ist. Es baut dynamisch mehrere Formen von Kontext zusammen.
\nDas System ändert, wie es Kontext baut, 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:
\nDas ist, wo die stärksten Produktionssysteme hinfahren.
\nWenn ich die ganze Disziplin auf eine Checkliste reduzieren müsste, würde sie so aussehen:
\nNichts 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 Frontier-Frage 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.
\nDarum 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 Beweise. Schwaches Gedächtnis. Unbegrenzte Loops.
\nDie Ironie ist, dass das KI-Systeme mehr wie klassische Software fühlen lässt, nicht weniger. Wir sind zurück dabei, Pipelines, Interfaces, Zustandsmaschinen, Memory-Hierarchien, Caches und Observability-Schichten zu bauen. Das Neue ist, dass all diese Stücke jetzt im Dienst 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:06439831ac1517be8133283f1d00da17f9c53f69c1ad451e26852bea67244ceb", "model": "moonshotai/kimi-k2.6", "generated_at": "2026-06-10T20:58:18.197247+00:00" }