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.^[1]

Der Begriff wurde im Juni 2025 von Tobi Luetke, CEO von Shopify, geprägt und in der Folge von Entwicklern und Forschern aufgegriffen.^[2]

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“.^[2] 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.^[3]

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“.^[1] Schmids zentrale These: Die Mehrheit der Fehler in KI-Agentensystemen seien keine Modellfehler mehr, sondern Kontextfehler.^[1]

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.^[4]

Merkmal	Prompt-Engineering	Context Engineering
Gegenstand	Einzelne Eingabe (Prompt)	Gesamte Informationsumgebung
Zeithorizont	Pro Interaktion	Session- und projektüberdauernd
Persistenz	Keine (flüchtig)	Versioniert, strukturiert
Komplexität	Textoptimierung	Systemarchitektur
Analogie	Einen Brief formulieren	Ein 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.^[3]

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.^[1]

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).^[5]
• 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.^[6]

Ein wiederkehrendes Architekturmuster in der Praxis ist die Schichtung von Kontext in mehrere Ebenen mit abnehmender Allgemeinheit:^[7]

Ebene	Inhalt	Lebensdauer	Beispiel
Global	Identität, Konventionen, Arbeitsstil	Dauerhaft	CLAUDE.md, Systemdateien
Projekt	Domänenkontext, Projektstatus	Projektdauer	README.md, Statusdateien
Aufgabe	Spezifische Dateien, Werkzeuge	Sitzungsdauer	Einzelne Dokumente, Skills

Dieses Muster wurde unabhängig von mehreren Praktikern beschrieben,^[8][9] darunter Teresa Torres (Autorin von Continuous Discovery Habits), die ein vergleichbares dreischichtiges System aus Obsidian, Markdown-Dateien und Claude Code beschrieb.^[10][11]

Es weist strukturelle Parallelen zum Drei-Speicher-Modell der Kognitionspsychologie auf (Arbeitsgedächtnis, episodisches Gedächtnis, semantisches Gedächtnis nach Tulving).^[12]

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.^[13]

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

1. Duale Leserschaft – Die Inhalte sind sowohl für den Menschen als auch für maschinelle Verarbeitung durch LLMs optimiert.
2. 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.^[10][5]

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.^[15] 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).^[15]

Konzept	Urheber	Jahr	Beziehung zu Knowledge OS
Memex	Vannevar Bush	1945	Hypothetisches Gerät zum Speichern und Verknüpfen persönlichen Wissens
Zettelkasten	Niklas Luhmann	ab 1951	Verzettelungssystem mit atomaren, verlinkten Notizen
Getting Things Done	David Allen	2001	Aufgabenverwaltung durch externalisierte Systeme
Second Brain / PARA	Tiago Forte	2017	Digitale Notizorganisation nach Handlungsrelevanz
Evergreen Notes	Andy Matuschak	ca. 2019	Konzeptorientierte, evolvierende Notizen
Digital Garden	diverse (u. a. Maggie Appleton)	ca. 2020	öffentliche, wachsende Wissenssammlungen

Philipp Schmid und Praktiker benennen wiederkehrende Probleme:^[1]

• 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.^[15]
• Transfergrenzen – Kontextsysteme, die für eine Person funktionieren, sind nicht ohne Weiteres auf andere oder auf Teams übertragbar.

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.^[16]
• Eine systematische Literaturübersicht von 63 Studien analysierte den Einsatz von RAG und LLMs im Unternehmens-Wissensmanagement.^[17]

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.^[18]

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

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