Was Context Engineering ist
Context Engineering ist die Praxis, alles zu entscheiden, zusammenzustellen und auszuliefern, was ein KI-Modell braucht, um eine Aufgabe gut zu erledigen, und zwar bevor das Modell läuft. Dazu gehören der System-Prompt, die angehängten Dokumente, das, was sich das Modell über Sie merkt, die Werkzeuge, die es aufrufen darf, und alles, was bereits im Gespräch steht. Prompt Engineering justiert einen Satz. Context Engineering justiert den gesamten Eingabe-Stack.
Anthropics Definition ist die präziseste im Umlauf: „the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference“ (die Strategien, mit denen während der LLM-Inferenz der optimale Satz an Token, also an Informationen, kuratiert und gepflegt wird). Das Leitprinzip, das dort mitgeliefert wird, sollte man auswendig können, denn es ist zugleich der Test dafür, ob man es richtig macht: Gesucht ist „the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome“ (die kleinstmögliche Menge signalstarker Token, die die Wahrscheinlichkeit des gewünschten Ergebnisses maximiert). (Anthropic, 2025)
Stellen Sie es sich vor wie das Briefing einer neuen Beraterin. Ein schlechtes Briefing ist eine einzeilige E-Mail. Ein gutes Briefing enthält den Hintergrund des Unternehmens, die relevante Vorgeschichte, die benötigten Dateien, die Stakeholder, eine Vorstellung davon, wie Erfolg aussieht, und die Grenzen des Auftrags. Wenn Sie eine brillante Beraterin engagieren und ihr ein schlechtes Briefing geben, bekommen Sie ein mittelmäßiges Ergebnis. Bei KI ist es genauso.
Achten Sie darauf, was in der Definition nicht vorkommt: Cleverness. Es gibt keine magische Formulierung, kein Geheimwort, das ein besseres Modell hervorzaubert. Die Arbeit ähnelt eher dem Redigieren als einer Beschwörung. Es geht darum, vor dem Gespräch zu entscheiden, was in den Raum gehört, und, mindestens genauso wichtig, was nicht.
Der Tweet, der ihm den Namen gab
Am 19. Juni 2025 schrieb Tobi Lütke, der CEO von Shopify, auf X, dass er den Begriff „context engineering“ dem Begriff „prompt engineering“ vorziehe. Er beschrieb ihn als „the art of providing all the context for the task to be plausibly solvable by the LLM“ (die Kunst, den gesamten Kontext so bereitzustellen, dass die Aufgabe für das LLM plausibel lösbar wird). Sechs Tage später verstärkte Andrej Karpathy, eine der angesehensten Stimmen der KI-Szene, den Begriff. Seine Definition war schärfer: „context engineering is the delicate art and science of filling the context window with just the right information for the next step“ (die feine Kunst und Wissenschaft, das Kontextfenster mit genau den richtigen Informationen für den nächsten Schritt zu füllen). (Karpathy, 2025)
Der Ausdruck selbst war nicht neu. Walden Yan von Cognition, dem Team hinter dem autonomen Coding-Agenten Devin, hatte eine Woche zuvor, am 12. Juni, „Don't Build Multi-Agents“ veröffentlicht und Context Engineering darin „effectively the #1 job of engineers building AI agents“ genannt, also faktisch die wichtigste Aufgabe von Entwicklern, die KI-Agenten bauen. Doch erst die Beiträge von Lütke und Karpathy machten die Bezeichnung mainstream. Im Monat darauf veröffentlichte Gartner einen Report mit dem Titel „Lead the Shift to Context Engineering as Prompt Engineering Fades“ und der unverblümten Zusammenfassung: „Context engineering is in, and prompt engineering is out“ (Context Engineering ist in, Prompt Engineering ist out). Gartners begleitende Prognose: Bis 2028 werden Context-Engineering-Funktionen in 80 Prozent der Software-Werkzeuge stecken, mit denen KI-Anwendungen gebaut werden, und die Genauigkeit agentischer KI um mindestens 30 Prozent verbessern. (Gartner, 2025)
Was da geschah, war kein Rebranding. Es war eine Korrektur. Die KI-Community räumte still ein, dass die Fähigkeit namens „Prompt Engineering“ immer schon eine Teilmenge von etwas Größerem war, und dass diese Teilmenge nicht länger der interessante Teil ist. Ein Prompt ist eine Komponente. Kontext ist der ganze Raum.
Das ist deshalb relevant, weil Wissensarbeiter zwei Jahre lang das Falsche gelernt haben. Sie haben Prompt-Vorlagen auswendig gelernt. Sie haben Twitter-Threads mit dem „ultimativen Prompt“ gesammelt. Sie haben den Prompt wie einen Zauberspruch behandelt. Diese Mühe ist nicht nutzlos, aber sie reicht nicht mehr aus. Die Frage ist nicht, wie Sie Ihre Anfrage formulieren. Die Frage ist, was Sie neben Ihre Anfrage stellen.
Ist Prompt Engineering wirklich tot?
Kurze Antwort: Die Berufsbezeichnung ist tot, die Techniken sind es nicht.
Es ist verlockend, das als Generationswechsel zu lesen, bei dem alles Alte falsch ist. Das ist eine bequeme Erzählung. Chain-of-Thought, Few-Shot-Beispiele, Rollenzuweisung und explizite Ausgabeformate wirken nach wie vor, und sie tauchen weiterhin in gut konstruierten Kontexten auf.
Was sich geändert hat, ist die Obergrenze. 2023 konnte ein gut formulierter Prompt die Qualität einer Antwort verdoppeln, weil die zugrunde liegenden Modelle von Mehrdeutigkeit leicht aus dem Konzept zu bringen waren. Mit der richtigen Satzstruktur verwandelte sich GPT-3.5 vom stolpernden Praktikanten in einen kohärent argumentierenden Analysten. Diese Lücke war real, und Prompt Engineering hat sie ausgenutzt.
Frontier-Modelle brauchen 2026 kein Händchenhalten mehr. Claude Opus 5, GPT-5.6 und Gemini 3.1 Pro kommen mit unscharfen Anfragen recht gut zurecht. Der Grenzertrag der Formulierung ist gefallen. Der Grenzertrag von passendem Quellenmaterial, sauber begrenztem Gedächtnis und kuratierten Beispielen ist dagegen deutlich gestiegen. Der Hebel hat sich verschoben.
Hier der Vergleich im Überblick.
| Dimension | Prompt Engineering | Context Engineering |
|---|---|---|
| Was justiert wird | Die Formulierung der Anfrage | Der gesamte Eingabe-Stack, der ins Modell fließt |
| Grundeinheit | Ein Satz | Ein Bündel: System-Prompt, Dokumente, Gedächtnis, Werkzeuge, Verlauf |
| Für wen | Alle, die ein Chatfenster benutzen | Alle, deren Ergebnisqualität von KI abhängt |
| Nötige Fähigkeit | Gutes Schreiben, Mustererkennung | Kuratierung, Informationsarchitektur, Urteilsvermögen |
| Wann es scheitert | Das Modell missversteht die Anweisung | Das Modell versteht gut, aber ihm fehlen Fakten, Beispiele oder Verlauf für eine gute Antwort |
| Lösung, wenn es hakt | Umformulieren, Beispiele ergänzen, Ausgabeformat vorgeben | Die richtige Quelle ergänzen, die falschen streichen, Gedächtnis anpassen, Abruf eingrenzen |
| Hochphase | 2022 bis 2024 | Ab 2025 |
Beachten Sie die letzte Zeile. Prompt Engineering ist nicht gestorben, weil es falsch war. Es ist gestorben, weil der Engpass woanders hingewandert ist.
Ist Context Engineering auch schon tot?
Kurze Antwort: Das Etikett verblasst, die Praxis nicht.
Die Gegenbewegung ist stark genug für ein eigenes Genre. Joe Reis veröffentlichte im März 2026 „Gartner Declares 2026 The Year of Context™“ und verspottete den Context Engineer als Mischung aus „data engineer, ontologist, librarian, corporate anthropologist, and therapist“ (Data Engineer, Ontologe, Bibliothekar, Unternehmensanthropologe und Therapeut), dessen eigentliche Tätigkeit darin bestehe, „updating a YAML file“, also eine YAML-Datei zu aktualisieren. Zieht man die Pointen ab, bleiben drei Einwände stehen, und zwei davon enthalten etwas Wahres.
„Die Modelle werden das absorbieren.“ Die Behauptung lautet, dass Agenten-Frameworks Kompaktierung, Abruf und Gedächtnis inzwischen automatisch erledigen, sodass sich niemand mehr über Kontext Gedanken machen muss. Daran ist etwas Substanzielles. Automatische Kompaktierung und Just-in-Time-Abruf haben tatsächlich eine ganze Kategorie manueller Arbeit beseitigt. Aber die Automatisierung hat die Arbeit verschoben, nicht gelöscht. Irgendjemand entscheidet weiterhin, was in die Gedächtnisdatei kommt, welche Quellen der Retriever anfassen darf und was der Agent ignorieren soll. Automatisiert wurde die Mechanik. Das Urteilsvermögen nicht.
„Das war immer nur ein Modewort für gute Eingaben.“ Teilweise berechtigt. Eingaben zu kuratieren ist keine neue Idee, und der Begriff wurde von Anbietern, die Kontextprodukte verkaufen, so weit gedehnt, dass er fast alles abdeckte. Aber einer Sache einen Namen zu geben, verändert, wie ernst sie genommen wird. 2023 hat niemand seine KI-Eingaben systematisch geprüft. Heute tun das viele Teams, und sie tun es, weil der Name der Praxis eine Form gegeben hat.
„Wegen Context Rot lässt sich das ohnehin nicht wegkonstruieren.“ Dieser Einwand steht auf dem Kopf. Dass Modelle mit wachsender Eingabe schlechter werden, ist das Argument für bewusste Kontextarbeit, nicht dagegen. Wäre mehr Kontext immer besser, wäre Kuratierung sinnlos und man könnte einfach alles hineinkippen.
Der ehrliche Stand Mitte 2026: Der Ausdruck hat seinen Hype-Höhepunkt hinter sich, und die eigenständige Rolle „Context Engineer“ ist eher im Entstehen als Standard. Adobe schreibt Stellen mit genau diesem Titel aus, doch in den meisten Unternehmen sitzt die Arbeit in bestehenden Rollen im Bereich KI, Daten oder Plattform-Engineering. Die Praxis dahinter ist etablierter denn je. Rechnen Sie damit, dass das Etikett so in den Hintergrund tritt wie „Responsive Design“: aufgesogen von der Standarddefinition guter Arbeit.
Die sechs Ebenen des Kontexts
Wer Context Engineering bewusst betreiben will, muss wissen, woran genau gearbeitet wird. Jede moderne KI-Interaktion speist sich aus sechs Ebenen, ob man darüber nachdenkt oder nicht. Die Kunst besteht darin, zu wissen, an welcher man drehen muss.
| Ebene | Zweck | Beispiel |
|---|---|---|
| System-Prompt | Legt fest, wer das Modell ist, welche Regeln gelten und welcher Ton herrscht | Eine claude.md-Datei im Repository, Cursors .cursorrules oder eine Custom-GPT-Anweisung wie „Rolle: erfahrener Redakteur. Aktiv formulieren. Niemals Gedankenstriche verwenden.“ |
| Dauerhaftes Gedächtnis | Was sich das Modell über Gespräche hinweg über Sie merkt | ChatGPTs Memory-Funktion, die Beruf, Schreibstil und laufende Projekte speichert |
| Abruf (RAG) | Holt bei Bedarf passende Ausschnitte aus einer größeren Wissensbasis | Die Frage an die KI „Was habe ich letzten Monat zu Netzwerkeffekten markiert?“, woraufhin sie genau diese Passagen holt |
| Werkzeugnutzung | Erlaubt dem Modell, zu handeln oder Live-Daten zu holen | Das Modell ruft einen Taschenrechner auf, führt Code aus, sucht im Web oder fragt den Kalender ab |
| Anhänge | Dateien, Bilder oder URLs, die in diese konkrete Sitzung geladen werden | Ein PDF-Vertrag, der zur Prüfung eingeworfen wird, oder ein eingefügter Screenshot zur Fehlersuche |
| Gesprächsverlauf | Was in diesem Thread bereits gesagt wurde | Das Hin und Her oberhalb der aktuellen Nachricht, inklusive früherer Korrekturen und Präferenzen |
Ein gut konstruierter Kontext nutzt alle sechs Ebenen bewusst. Ein schlecht konstruierter Kontext kippt alles in eine einzige Ebene (meist die Anhänge, oft den Gesprächsverlauf) und hofft, dass das Modell es schon sortieren wird.
Der häufigste Fehler von Wissensarbeitern besteht darin, KI als Chat-Oberfläche zu behandeln, obwohl sie in Wahrheit ein Kontext-Assembler ist. Fast alles, was die Antwort bestimmt, ist bereits geschehen, bevor Sie die erste Taste drücken.
Eine verwandte Perspektive darauf, wie persönliche Informationsarchitektur den Nutzen von KI prägt, findet sich unter persönliches Kontextmanagement.
Warum größere Kontextfenster es schlimmer machten, nicht besser
2023 war ein Kontextfenster von 100.000 Token exotisch. 2026 ist eine Million die gewöhnliche Grundausstattung: rund 1.050.000 bei GPT-5.6, 1.048.576 bei Gemini 3.6 Flash und 1.000.000 bei Claude Opus 5. Llama 4 Scout wirbt mit 10 Millionen. Man kann den vollständigen Text von Krieg und Frieden mehrfach in einen einzigen Prompt kippen. Die naheliegende Annahme lautet also, dass Context Engineering leichter wird. Mehr Platz, weniger Triage, oder?
Falsch. Es wurde schwerer.
Die Grundlagenarbeit dazu ist Liu et al. (2024), „Lost in the Middle: How Language Models Use Long Contexts“, erschienen in TACL. Die Forscher prüften, ob Modelle bestimmte Informationen finden und nutzen können, abhängig davon, wo diese in einem langen Kontext platziert sind. Der Befund ist unbequem: Die Leistung verläuft U-förmig. Modelle achten am stärksten auf Informationen ganz am Anfang und ganz am Ende des Kontexts. Was in der Mitte steht, wird systematisch untergewichtet, manchmal komplett übergangen. (Liu et al., 2024)
Wer eine kritische Anweisung in die Mitte eines 50-seitigen Dokuments setzt, muss damit rechnen, dass das Modell handelt, als hätte es sie nie gesehen. Das ist kein Fehler, den man mit besseren Prompts umgeht.
Im Juli 2025 veröffentlichte Chroma dann „Context Rot: How Increasing Input Tokens Impacts LLM Performance“ von Kelly Hong, Anton Troynikov und Jeff Huber. Sie testeten 18 Frontier-Modelle, darunter GPT-4.1, Claude 4, Gemini 2.5 und Qwen3. Das Ergebnis war über alle Modelle hinweg konsistent: Die Leistung sank mit wachsender Eingabe, lange bevor das Kontextfenster auch nur annähernd voll war. Modelle nutzen ihren Kontext nicht gleichmäßig. Zwischen etwa 10.000 und 100.000 Token brach die Genauigkeit um mehrere zehn Prozentpunkte ein, und bei einem Millionen-Token-Modell ist das das erste Zehntel des Fensters.
Entscheidend ist, dass die Schwelle an einer absoluten Tokenzahl hängt, nicht an einem Anteil des Fensters. Databricks maß für Llama 3.1 405B einen Abfall der Korrektheit ab etwa 32.000 Token, bei kleineren Modellen früher. Ein größeres Fenster zu kaufen verschiebt diese Zahl nicht. Ein Fenster von einer Million Token bringt keine Million nutzbarer Token, es bringt nur mehr Raum, das Problem zu vergrößern. Meta veröffentlicht für die vollen 10 Millionen Token von Llama 4 Scout nahezu perfekte Ergebnisse beim Nadel-im-Heuhaufen-Abruf, aber einen platzierten Fakt zu finden ist nicht dasselbe wie über das Korpus zu schlussfolgern, und kein veröffentlichter Benchmark zeigt, dass die Qualität des Schlussfolgerns auf dieser Länge hält.
Anthropic beschreibt die Ursache so, dass die Konsequenz sofort klar wird. Kontext sei „a finite resource with diminishing marginal returns“ (eine endliche Ressource mit abnehmendem Grenznutzen), und Modelle arbeiteten mit einem „attention budget“, einem Aufmerksamkeitsbudget, bei dem „every new token introduced depletes this budget by some amount“ (jedes neue Token zehrt dieses Budget ein Stück weit auf). Die Architektur erklärt, warum: Ein Transformer muss für n Token n² paarweise Beziehungen berechnen, weshalb die Aufmerksamkeit dünner wird, je größer die Eingabe ist. (Anthropic, 2025)
Das sind die versteckten Kosten der Millionen-Token-Ära. Das Fenster wuchs schneller als die Fähigkeit der Modelle, es zu nutzen, und damit wurde „Was lasse ich weg?“ zur wertvollsten Frage im gesamten Stack. Die architektonische Sicht auf dasselbe Problem, samt der Frage, wann man stattdessen zum Abruf greift, steht unter Context Rot, RAG und langer Kontext.
Die vier Arten, wie Kontext scheitert
Kontextverschmutzung ist der Sammelbegriff für einen Kontext, der durch Material verdorben wurde, das dort nichts zu suchen hat. Der Ausdruck ist nützlich und als Diagnose wertlos, denn zu wissen, dass der Kontext verschmutzt ist, sagt nicht, was entfernt werden muss. Die brauchbarste Aufschlüsselung stammt von Drew Breunig, der am 22. Juni 2025 „How Long Contexts Fail“ veröffentlichte. Er zerlegte Kontextverschmutzung in vier klar unterschiedene Fehlermodi, und die Taxonomie hat sich gehalten, weil jeder Modus eine andere Korrektur verlangt.
| Fehlermodus | Was passiert | Erkennungszeichen | Korrektur |
|---|---|---|---|
| Kontextvergiftung | Eine Halluzination oder ein Fehler gelangt in den Kontext und wird immer wieder herangezogen | Das Modell wiederholt selbstbewusst einen Fakt, den es nie bekommen hat | Neuen Thread starten. Prüfen, was ins Gedächtnis darf |
| Kontextablenkung | Der Kontext wird so lang, dass sich das Modell zu stark auf ihn stützt und vernachlässigt, was es im Training gelernt hat | Antworten werden repetitiv, das Modell wiederholt frühere Aktionen statt zu schlussfolgern | Kompaktieren oder zusammenfassen, dann neu starten |
| Kontextverwirrung | Überflüssiger Inhalt fließt in die Antwort ein und senkt ihre Qualität | Irrelevante Werkzeuge werden aufgerufen, themenfremde Details tauchen im Ergebnis auf | Werkzeugliste und Quellenliste kürzen |
| Kontextkonflikt | Neue Informationen oder Werkzeuge widersprechen dem, was bereits im Kontext steht | Das Modell laviert, widerspricht sich oder greift zur falschen Anweisung | Den Widerspruch entfernen. Die Regel einmal klar wiederholen |
Die Beispiele dahinter sind konkret. Für die Vergiftung verweist Breunig auf einen Gemini-2.5-Agenten, der Pokémon spielte, Spielzustände halluzinierte, sie in seinen Zielabschnitt schrieb und dann lange Phasen damit verbrachte, unmögliche Ziele zu verfolgen. Für die Ablenkung zitiert er genau das Databricks-Ergebnis, das schon den vorigen Abschnitt trägt: Die Korrektheit rutscht ab etwa 32.000 Token, bei einem Modell, dessen Fenster ein Vielfaches davon fasst.
Für die Verwirrung gibt es die handfestesten Belege. Auf dem Berkeley Function-Calling Leaderboard gilt laut Breunigs Zusammenfassung: „every model performs worse when provided with more than one tool“ (jedes Modell schneidet schlechter ab, sobald es mehr als ein Werkzeug bekommt), und Modelle rufen gelegentlich Werkzeuge auf, die nichts mit der Anfrage zu tun haben. In einem GeoEngine-Benchmark scheiterte ein quantisiertes Llama 3.1 8B an der Aufgabe, als es 46 Werkzeuge bekam, und löste sie mit 19. Gleiches Modell, gleiche Aufgabe, weniger Optionen.
Für den Konflikt zitiert Breunig Forschung von Microsoft und Salesforce zu „geshardeten“ Prompts, bei denen dieselbe Information über mehrere Nachrichten verteilt statt auf einmal geliefert wird. Die Leistung fiel im Schnitt um 39 Prozent, und o3 stürzte bei den betroffenen Aufgaben von 98,1 auf 64,1 ab.
Das Muster, das man verinnerlichen sollte: Drei dieser vier Fehlermodi werden schlimmer, wenn man Kontext hinzufügt. Nur einer, der tatsächlich fehlende Fakt, wird besser. Diese Asymmetrie ist das ganze Argument für Kuratierung.
Was die Forschung sagt: die Arbeiten, die zählen
Vier Dokumente tragen hier den größten Teil der Last, und wer nur diese liest, ist fast allen voraus, die online darüber streiten. Der Anker ist „A Survey of Context Engineering for Large Language Models“ (arXiv:2507.13334), eingereicht am 17. Juli 2025. Die Arbeit umfasst 166 Seiten und arbeitet 1.411 zitierte Veröffentlichungen durch, womit sie das Nächste ist, was das Feld an einer Landkarte hat.
Die Rahmung des Surveys lautet, dass Context Engineering „transcends simple prompt design to encompass the systematic optimization of information payloads for LLMs“ (über einfaches Prompt-Design hinausgeht und die systematische Optimierung der Informationsfracht für LLMs umfasst). Er teilt das Feld in grundlegende Komponenten (Kontextabruf und -erzeugung, Kontextverarbeitung, Kontextverwaltung) und darauf aufbauende Systemimplementierungen: RAG, Gedächtnissysteme, werkzeugintegriertes Schlussfolgern und Multi-Agenten-Architekturen. Wer sich je gefragt hat, wo RAG im Verhältnis zu Context Engineering steht: Der Abruf ist eine Maschine innerhalb der größeren Disziplin.
Der interessanteste Befund ist eine Lücke, die die Autoren als „a defining priority for future research“ markieren, also als bestimmende Priorität künftiger Forschung. Modelle, die mit gutem Context Engineering angereichert sind, „demonstrate remarkable proficiency in understanding complex contexts“ (zeigen bemerkenswerte Kompetenz im Verstehen komplexer Kontexte), doch sie „exhibit pronounced limitations in generating equally sophisticated, long-form outputs“ (stoßen beim Erzeugen ebenso anspruchsvoller langer Texte an deutliche Grenzen). Im Klartext: Wir sind viel besser darin geworden, Modelle mit Informationen zu füttern, als darin, lange, hochwertige Arbeit wieder herauszubekommen. Wer je erlebt hat, wie eine KI eine brillante Zusammenfassung und anschließend einen mittelmäßigen Entwurf von 3.000 Wörtern produziert, kennt das Gefühl.
Das zweite Dokument, das sich vollständig zu lesen lohnt, ist Anthropics „Effective context engineering for AI agents“ vom 29. September 2025. Es hat Praktikern das Vokabular gegeben, das die meisten Werkzeuge heute verwenden:
- Just-in-Time-Abruf: leichte Kennungen (Dateipfade, Suchanfragen, Links) im Kontext halten und die eigentlichen Daten erst zur Laufzeit laden, statt alles vorab zu laden.
- Kompaktierung: Nähert sich ein Gespräch der Fenstergrenze, wird es zusammengefasst und ein neues Fenster initialisiert. Anthropic merkt an, dass die Schwierigkeit vollständig in der Auswahl liegt, denn „overly aggressive compaction“ (zu aggressives Kompaktieren) verliert feine Kontextdetails, deren Bedeutung sich erst später zeigt.
- Strukturierte Notizen: Der Agent schreibt Notizen in ein dauerhaftes Gedächtnis außerhalb des Kontextfensters und liest sie bei Bedarf zurück.
- Sub-Agenten-Architekturen: Eng umrissene Aufgaben gehen an spezialisierte Agenten mit sauberen Kontextfenstern, und ein leitender Agent fasst die Ergebnisse zusammen.
Diese vier Techniken wurden für autonome Agenten entworfen. Alle vier haben ein manuelles Gegenstück, das ein Mensch im Chatfenster ausführen kann, und genau darum geht es in den nächsten beiden Abschnitten. Wie diese Ideen im täglichen Agenten-Werkzeugkasten auftauchen, steht unter Skills, Subagents und Hooks.
Die Fähigkeit, die niemand benannt hat: Kuratierung
Wenn Context Rot das Problem ist, ist Kuratierung die Lösung. Und Kuratierung ist zufällig eine Fähigkeit, die die meisten Wissensarbeiter längst praktizieren, ohne sie so zu nennen.
Jedes Mal, wenn Sie eine Passage in einem Artikel markieren, kuratieren Sie. Sie sagen damit: Das hier zählt. Der Rest ist Hintergrund. Wenn Sie ein PDF kommentieren, eine Studie als Lesezeichen ablegen oder ein Zitat speichern, tun Sie dasselbe. Sie bauen einen Signal-Rausch-Filter über eine Welt voller Text.
Das Problem war bis vor Kurzem, dass diese Kuratierung eingesperrt war. Ihre Markierungen lagen in einer App. Ihre Kindle-Notizen in einer anderen. Ihre Webrecherche im Browserverlauf. Wenn Sie sich hinsetzten, um eine KI zu briefen, konnten Sie nichts davon effizient in das Kontextfenster holen. Am Ende lasen Sie alles erneut oder, schlimmer, fügten rohe Quellen ein und hofften auf das Beste.
Context Engineering als Disziplin hat genau hier eine große Lücke. Unternehmen haben sie mit internen Wissensdatenbanken und RAG-Pipelines geschlossen. Einzelne Wissensarbeiter aber haben kein Entwicklerteam. Diese Menschen haben dasselbe Problem (zu viel Quellmaterial, zu wenig Signal) und keinerlei Infrastruktur.
Deshalb sind Lesewerkzeuge, die Markierungen dauerhaft festhalten, still und leise zu KI-Infrastruktur geworden. Glasps Web-Highlighter existiert genau dafür: Er verwandelt Ihre Lektüre in strukturierten, abrufbaren Kontext. Wenn Sie einen Absatz in einem Blogbeitrag markieren, wird diese Markierung zu einem Stück Kontext, das Sie später jeder KI übergeben können, gefiltert nach Thema, Quelle oder Datum.
Dasselbe Prinzip gilt für lange Lektüre. Ihre Kindle-Markierungen sind wohl das hochwertigste Signal, das Sie je darüber erzeugt haben, was Ihnen wichtig ist. Sie haben lange genug aufmerksam gelesen, um sie zu markieren. Das ist ein teurer Filter, und er ist verschwendet, wenn die Markierungen in einem geschlossenen System liegen bleiben.
Context Engineering für Einzelpersonen (nicht nur für Entwickler)
Das meiste, was über Context Engineering geschrieben wird, richtet sich an Entwickler. Es geht um den Bau produktiver KI-Systeme: wie man einen System-Prompt für einen Coding-Agenten formt, wie man Dokumente für den Abruf zerlegt, wie man Werkzeugaufrufe verdrahtet. Das ist nützlich, wenn Sie Software ausliefern. Weniger nützlich ist es, wenn Sie als Berater, Forscher, Autor, Analyst oder Student bessere KI-Ergebnisse wollen.
Aber dieselbe Disziplin greift. Sie führen sie eben von Hand aus.
Sie entwerfen System-Prompts, nur informell. Jedes Custom GPT, jedes Claude-Projekt, jede Anweisungsdatei im Stil von claude.md ist ein System-Prompt. Wer schreibt „Rolle: mein Rechercheassistent. Arbeitsgebiet: Politik für erneuerbare Energien. Skeptische Zusammenfassungen bevorzugen.“, betreibt System-Prompt-Design. Tun Sie es bewusst.
Sie verwalten Gedächtnis. ChatGPTs Memory-Funktion und Claudes Projekte erlauben beide, Fakten festzupinnen, die über Gespräche hinweg bestehen bleiben. Die meisten Menschen ignorieren das entweder (und verlieren Kontinuität) oder kippen alles hinein (und erzeugen Rauschen). Richtig ist, das Gedächtnis wie einen Lebenslauf zu kuratieren: nur die Dinge, die das Modell jedes Mal nutzen soll.
Sie betreiben Abruf, manuell. Den richtigen Artikel in einen Chat einzufügen ist manuelles RAG. Die Frage ist, woher „der richtige Artikel“ kommt. Kommt er aus hektischem Scrollen im Browserverlauf, haben Sie kein Abrufsystem. Kommt er aus einer Sammlung von Passagen, die Sie bereits als interessant markiert haben, haben Sie eines.
Sie laden Anhänge absichtlich. Die Versuchung ist, das ganze Buch hochzuladen. Besser sind die 40 Seiten, die Sie tatsächlich markiert haben. Damit umgehen Sie Context Rot, weil Sie schon vorgelagert filtern.
Dazu kommen die vier Agententechniken aus Anthropics Spielbuch, die jeweils eine manuelle Fassung haben:
| Agententechnik | Die manuelle Fassung, die heute schon geht |
|---|---|
| Just-in-Time-Abruf | Eine Liste von Quell-Links im Thread halten und den Volltext erst einfügen, wenn das Modell ihn wirklich braucht |
| Kompaktierung | Wird ein Thread lang und werden die Antworten repetitiv, eine Zusammenfassung der bisherigen Entscheidungen anfordern und damit einen frischen Chat beginnen |
| Strukturierte Notizen | Den laufenden Stand eines Projekts in einem Dokument außerhalb des Chats führen und die aktuelle Fassung neu einfügen, statt sich auf den Scrollverlauf zu verlassen |
| Sub-Agenten | Für getrennte Teilaufgaben getrennte Chats führen statt eines Mega-Threads und nur die Schlussfolgerungen wieder zusammenführen |
Die Kompaktierung ist das, was den meisten fehlt. Lange Threads werden mit der Zeit schlechter, weil alte Nachrichten den Kontext unnütz dominieren, und das ist exakt der Fehlermodus Ablenkung aus der Tabelle weiter oben. In der Regel ist es besser, für eine neue Teilaufgabe einen frischen Thread mit sauberem Briefing zu starten, als den Mega-Thread fortzuführen.
Nichts davon verlangt Entwicklerkenntnisse. Es verlangt genau die Fähigkeit, die gute Forscherinnen und gute Journalisten längst haben: zu wissen, was hineingehört, was gestrichen wird und woher man was holt.
Ihre Highlights sind Ihr Wettbewerbskontext
Jetzt kommt der unterschätzte Teil.
Die meisten Menschen behandeln ihre Notizen und Markierungen als Gedächtnisstütze. Als etwas, zu dem man irgendwann zurückkehrt. Diese Sichtweise ergab 2010 Sinn, als das Zurückkehren die einzige Möglichkeit war, sie zu nutzen. 2026 ist sie überholt.
Ihre Markierungen sind heute ein Strom, der an eine KI übergeben werden kann. Jede markierte Passage, jedes gespeicherte Zitat, jede Anmerkung ist ein Stück Kontext. Und weil es durch Ihre Aufmerksamkeit entstanden ist, hat es mehr Signal als alles, was zufällig aus dem Web zusammengekratzt wird.
Denken Sie darüber nach, was das im Wettbewerb bedeutet. Zwei Wissensarbeiter nutzen dasselbe KI-Modell. Der eine hat drei Jahre strukturierten Lesens und Markierens hinter sich. Der andere hat drei Jahre Browser-Tabs, die er nie wieder geöffnet hat. Stellen beide der KI dieselbe Frage, kann der Erste sein eigenes kuratiertes Korpus einspeisen. Der Zweite bleibt auf den generischen Trainingsdaten des Modells sitzen und auf dem, was er aus dem Gedächtnis einfügen kann. Der Unterschied ist keine Prompt-Lücke. Es ist eine Kontext-Lücke.
Deshalb hat sich verschoben, wie sich Glasp positioniert. Der ursprüngliche Pitch war ein sozialer Web-Highlighter: Dinge markieren, sehen, was andere markiert haben, eine Leser-Identität aufbauen. Das stimmt alles weiterhin. Aber der tiefere Wert liegt heute darin, dass jede Markierung ein Kontext-Token ist, das auf seinen Einsatz wartet. Ihre Lesegeschichte wächst Absatz für Absatz zu einem persönlichen RAG-Korpus an.
Kombiniert mit Glasps KI-Chat rückt der Ablauf nah an das heran, was Entwickler für ihre Unternehmen bauen. Sie markieren beim Lesen. Später stellen Sie Fragen, und die KI schöpft aus dem, was Ihnen tatsächlich wichtig war, statt aus einem generischen Web-Index. Das ist Context Engineering, nur dass der Kontext Ihre eigene Bibliothek ist.
Mehr dazu, wie das die Beziehung zwischen Lesen und KI umdreht, steht unter KI-Lese-Assistenten.
Ein einfaches Framework für den Kontext jeder KI-Aufgabe
Genug Theorie. Hier ist ein konkreter Ablauf für den nächsten Chat.
Schritt 1: Die Aufgabe definieren, bevor Sie tippen. Ein Satz. Wie sieht „fertig“ aus? „Memo von 500 Wörtern, das die drei wichtigsten Argumente gegen die Vier-Tage-Woche zusammenfasst, geschrieben für einen skeptischen COO.“ Das ist eine Aufgabe. „Hilfe mit diesem Artikel“ ist keine.
Schritt 2: Quellen sammeln, dann kürzen. Holen Sie das Material, das wirklich zur Aufgabe gehört. Wenn Markierungen zum Thema existieren, beginnen Sie dort und nicht bei den vollständigen Artikeln. Wenn ein Gedächtnis eingerichtet ist, prüfen Sie, ob es bereits nützlichen Hintergrund enthält. Lassen Sie alles weg, was nur am Rande zusammenhängt. Context Rot ist real.
Schritt 3: Rolle und Regeln setzen. Sagen Sie dem Modell vor der Aufgabe, wer es ist und welche Regeln gelten. „Rolle: Lektorat für einen skeptischen COO. Kein Fachjargon. Keine Weichmacher. Zahlen vor Adjektiven.“ Das ist die System-Prompt-Ebene. Sie kostet zehn Sekunden und verändert den Ton von allem, was folgt.
Schritt 4: Aufgabe und Bündel in der richtigen Reihenfolge einspeisen. Der wichtigste Kontext kommt zuerst, die Aufgabe zuletzt. Wegen des Lost-in-the-Middle-Effekts gehören die Anweisung und das schärfste Material an den Anfang und ans Ende. Die Mitte ist ein Sumpf.
Schritt 5: Diagnostizieren, bevor Sie iterieren. Ist das Ergebnis schlecht, widerstehen Sie dem Drang, den Prompt zwölfmal umzuschreiben. Gehen Sie stattdessen die vier Fehlermodi als Checkliste durch. Steckt ein falscher Fakt darin, der immer wiederkehrt (Vergiftung)? Ist der Thread lang und repetitiv (Ablenkung)? Haben Sie drei Quellen angehängt, obwohl eine relevant war (Verwirrung)? Haben Sie zwei Anweisungen gegeben, die sich widersprechen (Konflikt)? Jeder Fall verlangt eine andere Korrektur, und keine davon heißt Umformulieren.
Nach ein paar Dutzend Durchläufen wird das zum Reflex. Sie hören auf zu fragen „Wie prompte ich das?“ und fragen stattdessen „Was muss das Modell sehen, bevor es antwortet?“. Diese Verschiebung ist die ganze Disziplin.
Häufig gestellte Fragen
Was ist Context Engineering in einfachen Worten?
Es ist die Entscheidung darüber, was ein KI-Modell sieht, bevor es antwortet. Dazu gehören die Anweisungen, die es bekommt, die angehängten Dokumente, das, was es sich über Sie merkt, die Werkzeuge, die es nutzen kann, und das bisherige Gespräch. Prompt Engineering deckt nur die Formulierung der Anfrage ab, und die ist eine Eingabe unter vielen.
Ist Prompt Engineering wirklich tot?
Der Ausdruck geht in Rente. Die Techniken dahinter funktionieren weiter. Chain-of-Thought, Few-Shot-Beispiele und klare Ausgabeformate sind alle weiterhin nützlich. Tot ist die Vorstellung, dass gute Formulierung allein für großartige Ergebnisse sorgt. 2026 ist die Formulierung ein kleiner Hebel. Der große ist das Zusammenstellen des Kontexts. Wenn Menschen sagen „Prompt Engineering ist tot“, meinen sie das.
Ist Context Engineering tot oder nur ein Modewort?
Der Begriff hat seinen Hype-Höhepunkt hinter sich, und die eigenständige Berufsbezeichnung „Context Engineer“ ist eher im Entstehen als Standard: Adobe schreibt Stellen unter genau diesem Namen aus, aber in den meisten Unternehmen steckt die Arbeit in bestehenden Rollen im Bereich KI, Daten oder Plattform-Engineering. Die Praxis ist etablierter denn je, und sie wird in die normale KI-Arbeit aufgesogen, statt zu verschwinden. Automatische Kompaktierung und automatischer Abruf in modernen Agenten-Werkzeugen haben einige manuelle Schritte entfernt, aber irgendjemand entscheidet weiterhin, was ins Gedächtnis kommt und welche Quellen das Modell sehen darf. Genau diese Entscheidung ist die Arbeit.
Was ist Kontextverschmutzung?
Es ist der Oberbegriff für einen Kontext, der durch Material verdorben wurde, das dort nicht hingehört. Drew Breunigs Taxonomie zerlegt Kontextverschmutzung in vier Modi: Vergiftung (ein Fehler gelangt hinein und wird wiederholt), Ablenkung (der Kontext wird so lang, dass sich das Modell zu stark auf ihn stützt), Verwirrung (irrelevanter Inhalt zieht die Antwort herunter) und Konflikt (zwei Kontextteile widersprechen einander). Zu diagnostizieren, welcher Modus vorliegt, ist wichtig, weil die Korrekturen verschieden sind.
Was sind die besten Arbeiten zu Context Engineering?
Beginnen Sie mit „A Survey of Context Engineering for Large Language Models“ (arXiv:2507.13334), einer 166-seitigen Übersicht über 1.411 Veröffentlichungen. Für die Belege zum Versagen bei langem Kontext lesen Sie Liu et al. (2024) „Lost in the Middle“ in TACL und Chromas technischen Bericht „Context Rot“ von 2025. Für die angewandte Praxis ist Anthropics „Effective context engineering for AI agents“ (September 2025) das nützlichste nicht-akademische Dokument.
Was ist der Unterschied zwischen Context Engineering und RAG?
RAG (Retrieval-Augmented Generation) ist eine Ebene des Context Engineering, konkret die Abrufebene. Es ist die Maschinerie, die bei Bedarf passende Ausschnitte aus einer Wissensbasis holt. Context Engineering ist die breitere Disziplin, die RAG einschließt, dazu System-Prompts, Gedächtnis, Werkzeugnutzung, Anhänge und Gesprächsverlauf.
Lösen größere Kontextfenster das nicht irgendwann von selbst?
Bisher haben sie es nicht getan, und die Belege sprechen dagegen. Liu et al. (2024) zeigten, dass Modelle die Mitte langer Kontexte übergehen. Chromas Studie von 2025 zeigte, dass alle 18 getesteten Frontier-Modelle deutlich vor dem Füllen des Fensters abbauen. Fenster, die mit 10 Millionen Token beworben werden, haben Ergebnisse für den Nadelabruf, aber keinen veröffentlichten Benchmark, der die Qualität des Schlussfolgerns auf dieser Länge belegt. Der Engpass ist nicht die Fenstergröße. Es ist die Verteilung der Aufmerksamkeit innerhalb des Fensters.
Muss man technisch sein, um Context Engineering zu betreiben?
Nein. Die Ingenieursmetapher schreckt manche ab, aber sie bedeutet nur, die Arbeit bewusst statt zufällig zu tun. Eine Beraterin, die ein Briefing vorbereitet, ein Journalist, der für einen Beitrag recherchiert, eine Studentin, die Quellenmaterial für einen Aufsatz ordnet: Das ist alles Context Engineering in Verkleidung. Die Kernfähigkeit heißt Kuratierung und Urteilsvermögen.
Wie hängt das mit den „Memory“-Funktionen von KI zusammen?
Gedächtnis (etwa ChatGPTs dauerhaftes Memory oder Claudes Projekte) ist eine Kontextebene. Es ist das, was das Modell über Sitzungen hinweg über Sie weiß. Context Engineering schließt Gedächtnis ein, ist aber breiter. Das Gedächtnis ist die dauerhaft aktive Ebene. Abruf, Anhänge und System-Prompts sind die Ebenen pro Aufgabe. Wer Kontext gut konstruiert, nutzt sie alle zusammen.
Ist das nicht einfach schickes Notizenmachen?
Teilweise. Der Unterschied ist, dass klassisches Notizenmachen darauf optimiert ist, dass Sie Ihre Notizen erneut lesen. Context Engineering ist darauf optimiert, dass ein Modell Ihre Notizen konsumiert. Die formalen Anforderungen unterscheiden sich (Struktur, Atomarität und Abrufbarkeit zählen mehr), aber die zugrunde liegende Praxis, festzuhalten, was erinnernswert ist, bleibt dieselbe. Wer gut Notizen macht, hat hier einen Vorsprung.
Fazit: Die neue Kulturtechnik
Jede Computer-Ära hatte eine Kulturtechnik, die Amateure von ernsthaften Nutzern trennte. In den 2000ern war es, gut googeln zu lernen. In den 2010ern war es, Informationen in Werkzeugen wie Notion oder Airtable zu strukturieren. 2026 ist es, Kontext für KI zu konstruieren.
Die Menschen, die das begreifen, ziehen weit an denen vorbei, die es nicht tun. Nicht, weil sie besseren Zugang zu Modellen hätten (alle haben dieselben Modelle), sondern weil sie zu jeder Aufgabe mit besserem Material antreten. Sie wissen, was hineingehört. Sie wissen, was wegbleibt. Sie wissen, wo ihre beste Quelle zu einem Thema liegt, weil sie sich vor Monaten die Mühe gemacht haben, sie festzuhalten.
Deshalb wird Kuratierung still und leise zur wertvollsten Metafähigkeit der KI-Ära. Jede gespeicherte Markierung, jede kommentierte Passage, jede Lektüre, die tatsächlich verarbeitet wird, ist eine Einzahlung in eine persönliche Kontextmaschine. Die Zukunft der KI-Produktivität gehört nicht den Menschen mit Geheim-Prompts. Sie gehört den Menschen mit durchdachten Bibliotheken.
Sie lesen ohnehin. Sie haben ohnehin eine Meinung dazu, was zählt. Die einzige Frage ist, ob irgendetwas davon lange genug bleibt, um Ihrem künftigen Ich und der KI an Ihrer Seite zu nützen. Die Werkzeuge existieren. Die Gewohnheit ist der schwierige Teil.
Suchen Sie sich heute etwas Lesenswertes. Markieren Sie die Stellen, auf die es ankommt. Das ist Context Engineering. Alles andere ist Technik.
