Context Engineering (deutsch etwa Kontextgestaltung) bezeichnet in der Informatik die systematische Gestaltung der Informationsumgebung, in der ein großes Sprachmodell (LLM) arbeitet. Im Unterschied zum Prompt-Engineering, das einzelne Eingaben optimiert, umfasst Context Engineering die Architektur persistenter Kontextsysteme – einschließlich Systemanweisungen, Dateistrukturen, Konventionen und Abhängigkeitssysteme.Philipp Schmid: Context Engineering. philschmid.de, 2025. Online: https://www.philschmid.de/context-engineering

Der Begriff wurde im Juni 2025 von Tobi Luetke, CEO von Shopify, geprägt und in der Folge von Entwicklern und Forschern aufgegriffen.Tobi Luetke: Beitrag auf X (vormals Twitter), 18. Juni 2025. Online: https://x.com/tobi/status/1935533422589399127

Begriffsgeschichte Tobi Luetke schlug den Begriff am 18. Juni 2025 als Ablösung von Prompt Engineering vor. Seine Definition: Context Engineering sei „die Kunst, sämtlichen Kontext bereitzustellen, damit eine Aufgabe vom LLM plausibel lösbar wird“. Simon Willison, Mitschöpfer des Django-Webframeworks und Blogger zu KI-Themen, erklärte am 27. Juni 2025, der Begriff werde sich durchsetzen, da Prompt Engineering falsche Assoziationen wecke – nämlich die Annahme, es genüge, Eingaben in ein Chatfenster zu tippen.Simon Willison: Context Engineering. simonwillison.net, 27. Juni 2025. Online: https://simonwillison.net/2025/jun/27/context-engineering/

Philipp Schmid (Senior AI Developer Relations bei Google DeepMind) formalisierte den Begriff: Context Engineering sei „die Disziplin, dynamische Systeme zu entwerfen und zu bauen, die die richtige Information mit den richtigen Werkzeugen im richtigen Format zum richtigen Zeitpunkt bereitstellen“. Schmids zentrale These: Die Mehrheit der Fehler in KI-Agentensystemen seien keine Modellfehler mehr, sondern Kontextfehler.

Andrej Karpathy, ehemaliger KI-Leiter bei Tesla und Mitgründer von OpenAI, ordnete Context Engineering in sein Konzept von Software 3.0 ein: Natürliche Sprache werde zur Programmiersprache für LLMs, und die Gestaltung des Kontexts sei die zentrale Ingenieursaufgabe.Andrej Karpathy: Software 3.0. Latent Space Podcast, 2025. Online: https://www.latent.space/p/s3

Abgrenzung zu Prompt Engineering MerkmalPrompt-EngineeringContext EngineeringGegenstandEinzelne Eingabe (Prompt)Gesamte InformationsumgebungZeithorizontPro InteraktionSession- und projektüberdauerndPersistenzKeine (flüchtig)Versioniert, strukturiertKomplexitätTextoptimierungSystemarchitekturAnalogieEinen Brief formulierenEin Büro einrichten Während Prompt Engineering eine gute Antwort auf eine einzelne Frage anstrebt, zielt Context Engineering auf konsistent gute Antworten über Sessions, Aufgaben und Domänen hinweg.

Technische Grundlagen

Kontextfenster LLMs verarbeiten Eingaben innerhalb eines begrenzten Kontextfensters (gemessen in Token). Alles, was das Modell bei einer Antwort berücksichtigen soll – Systemanweisungen, Gesprächsverlauf, Referenzdokumente – muss in dieses Fenster passen. Context Engineering adressiert die Frage, wie dieses begrenzte Fenster optimal befüllt wird.

Instruktionsdateien Mehrere LLM-Werkzeuge verwenden projektbezogene Instruktionsdateien im Markdown-Format, die beim Start einer Sitzung automatisch in den Kontext geladen werden:

CLAUDE.md – verwendet von Claude Code (Anthropic). Hierarchisch: global (Benutzerebene), Projekt (Repository-Ebene), lokal (Verzeichnisebene).Anthropic: Memory. Claude Code Dokumentation, 2026. Online: https://code.claude.com/docs/en/memory AGENTS.md – verwendet von Cursor und anderen Coding-Assistenten GEMINI.md – verwendet von Google Gemini Code Assist copilot-instructions.md – verwendet von GitHub Copilot

Alle folgen demselben Prinzip: Eine Markdown-Datei fungiert als persistenter Systemprompt für ein Repository oder Projekt.

Geschichteter Kontext (Layered Context) Ein wiederkehrendes Architekturmuster in der Praxis ist die Schichtung von Kontext in mehrere Ebenen mit abnehmender Allgemeinheit: EbeneInhaltLebensdauerBeispielGlobalIdentität, Konventionen, ArbeitsstilDauerhaftCLAUDE.md, SystemdateienProjektDomänenkontext, ProjektstatusProjektdauerREADME.md, StatusdateienAufgabeSpezifische Dateien, WerkzeugeSitzungsdauerEinzelne Dokumente, Skills Dieses Muster wurde unabhängig von mehreren Praktikern beschrieben,Petter Chr. Bjelland: Three layers of context for useful AI. Medium, 2025. Online: https://medium.com/@pcbje/three-layers-of-context-for-useful-ai-f533276ca50aSen Lin: Designing the 3 layers of AI context. UX Collective, 2025. Online: https://uxdesign.cc/designing-the-3-layers-of-ai-context-9a35a5f6e63a darunter Teresa Torres (Autorin von Continuous Discovery Habits), die ein vergleichbares dreischichtiges System aus Obsidian, Markdown-Dateien und Claude Code beschrieb.Peter Yang: Full Tutorial: Automate Your Life with Claude Code — Teresa Torres. CreatorEconomy, 2026. Online: https://creatoreconomy.so/p/automate-your-life-with-claude-code-teresa-torresChatPRD: How I AI: Teresa Torres. chatprd.ai, 2026. Online: https://www.chatprd.ai/how-i-ai/teresa-torres-claude-code-obsdian-task-management

Es weist strukturelle Parallelen zum Drei-Speicher-Modell der Kognitionspsychologie auf (Arbeitsgedächtnis, episodisches Gedächtnis, semantisches Gedächtnis nach Tulving).Serokell: Design Patterns for Long-Term Memory in LLM-Powered Architectures. serokell.io, 2025. Online: https://serokell.io/blog/design-patterns-for-long-term-memory-in-llm-powered-architectures

Anwendung: Knowledge Operating System Als Knowledge Operating System (kurz Knowledge OS) wird ein strukturiertes, versioniertes Wissens-Repository bezeichnet, das sowohl menschliches Denken als auch LLM-Kontext bedient. Der Begriff entstand ab 2025 in der Praxis von Wissensarbeitern, die bestehende Konzepte des Personal Knowledge Management (PKM) mit LLM-Kontextarchitektur verbanden.

Ein Knowledge OS unterscheidet sich von klassischen PKM-Systemen (wie Zettelkasten, Getting Things Done oder Tiago Fortes Second Brain) durch zwei Merkmale:

Duale Leserschaft – Die Inhalte sind sowohl für den Menschen als auch für maschinelle Verarbeitung durch LLMs optimiert. Kontextarchitektur – Die Struktur folgt nicht nur einer Ordnungslogik (wie PARA), sondern einer Ladestrategie: Welcher Kontext wird wann in welcher Granularität dem LLM bereitgestellt.

Typische Implementierungen verwenden Markdown-Dateien in einem Git-versionierten Repository, verwaltet über Werkzeuge wie Obsidian oder Visual Studio Code, und angebunden an LLM-Clients wie Claude Code, Cursor oder GitHub Copilot.

In der Praxis setzen solche Systeme auf ein Schichtenmodell, das über die technische Kontexthierarchie (Global/Projekt/Aufgabe) hinausgeht: Eine Knowledge-Schicht für Fachwissen, eine Identity-Schicht für berufliche Positionierung und eine Sensemaking-Schicht für strategische Reflexion. Der anfängliche Aufwand für den Aufbau eines solchen Systems liegt bei etwa 30 Stunden, amortisiert sich jedoch durch Wiederverwendung: Folgeprojekte benötigen deutlich weniger Zeit, da Positionierung und Inhalte bereits strukturiert vorliegen (Compound-Effekt).

Verwandte Konzepte KonzeptUrheberJahrBeziehung zu Knowledge OSMemexVannevar Bush1945Hypothetisches Gerät zum Speichern und Verknüpfen persönlichen WissensZettelkastenNiklas Luhmannab 1951Verzettelungssystem mit atomaren, verlinkten NotizenGetting Things DoneDavid Allen2001Aufgabenverwaltung durch externalisierte SystemeSecond Brain / PARATiago Forte2017Digitale Notizorganisation nach HandlungsrelevanzEvergreen NotesAndy Matuschakca. 2019Konzeptorientierte, evolvierende NotizenDigital Gardendiverse (u. a. Maggie Appleton)ca. 2020öffentliche, wachsende Wissenssammlungen

Herausforderungen Philipp Schmid und Praktiker benennen wiederkehrende Probleme:

Kontextüberlastung – Mehr Kontext verbessert die Ergebnisse nicht linear; ab einem Schwellenwert sinkt die Qualität. Wartungsschulden – Veralteter Kontext kann das LLM aktiv in die Irre führen. Lebendige Systeme erfordern kontinuierliche Pflege. Automatisierungsparadox – Der Aufbau eines zeitsparenden Systems erfordert zunächst erheblichen Zeitaufwand. Transfergrenzen – Kontextsysteme, die für eine Person funktionieren, sind nicht ohne Weiteres auf andere oder auf Teams übertragbar.

Forschung Die akademische Forschung an der Schnittstelle von Wissensmanagement und LLMs befindet sich im Frühstadium. Erste systematische Übersichten erschienen ab 2025:

Kirchner (2025) untersuchte den Einsatz generativer KI im Wissensmanagement von Softwareentwicklungsteams.E. Kirchner: Generative AI Meets Knowledge Management: Insights From Software Development Practices. In: Knowledge and Process Management, Wiley, 2025. Online: https://onlinelibrary.wiley.com/doi/full/10.1002/kpm.70004 Eine systematische Literaturübersicht von 63 Studien analysierte den Einsatz von RAG und LLMs im Unternehmens-Wissensmanagement.RAG and LLMs for Enterprise Knowledge Management. In: Applied Sciences, MDPI, 2025. Online: https://www.mdpi.com/2076-3417/16/1/368

Ein frühes Beispiel für den Begriff Knowledge Operating System in der Informatik ist das KnowOS-Projekt von Travers, Massar und Shrager (2005), ein Common-Lisp-Framework für Bioinformatik, das auf Arbeiten für die NASA zurückging.M. Travers, J.P. Massar, J. Shrager: KnowOS: The (Re)Birth of the Knowledge Operating System. International Lisp Conference, 2005.

Siehe auch Prompt-Engineering Wissensmanagement Zettelkasten Obsidian (Software) Retrieval Augmented Generation

Einzelnachweise

Weblinks Philipp Schmid: Context Engineering – Formale Definition und Einordnung Simon Willison: Context Engineering – Begriffsgeschichte und Practitioner-Perspektive Anthropic: Claude Code Memory – Technische Dokumentation zu Instruktionsdateien

Kategorie:Künstliche Intelligenz Kategorie:Wissensmanagement