Context Engineering
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]
Begriffsgeschichte
[Bearbeiten | Quelltext bearbeiten]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]
Abgrenzung zu Prompt Engineering
[Bearbeiten | Quelltext bearbeiten]| 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]
Technische Grundlagen
[Bearbeiten | Quelltext bearbeiten]Kontextfenster
[Bearbeiten | Quelltext bearbeiten]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]
Instruktionsdateien
[Bearbeiten | Quelltext bearbeiten]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]
Geschichteter Kontext (Layered Context)
[Bearbeiten | Quelltext bearbeiten]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]
Anwendung: Knowledge Operating System
[Bearbeiten | Quelltext bearbeiten]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]
- 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.[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]
Verwandte Konzepte
[Bearbeiten | Quelltext bearbeiten]| 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 |
Herausforderungen
[Bearbeiten | Quelltext bearbeiten]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.
Forschung
[Bearbeiten | Quelltext bearbeiten]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]
Siehe auch
[Bearbeiten | Quelltext bearbeiten]Einzelnachweise
[Bearbeiten | Quelltext bearbeiten]- 1 2 3 4 5 Philipp Schmid: Context Engineering. philschmid.de, 2025. Online: https://www.philschmid.de/context-engineering
- 1 2 Tobi Luetke: Beitrag auf X (vormals Twitter), 18. Juni 2025. Online: https://x.com/tobi/status/1935533422589399127
- 1 2 Simon Willison: Context Engineering. simonwillison.net, 27. Juni 2025. Online: https://simonwillison.net/2025/jun/27/context-engineering/
- ↑ Andrej Karpathy: Software 3.0. Latent Space Podcast, 2025. Online: https://www.latent.space/p/s3
- 1 2 Anthropic: Memory. Claude Code Dokumentation, 2026. Online: https://code.claude.com/docs/en/memory
- ↑ XML vs Markdown for high performance tasks. 13. Mai 2025, abgerufen am 17. März 2026 (englisch).
- ↑ Effective context engineering for AI agents. Abgerufen am 17. März 2026 (englisch).
- ↑ Petter Chr. Bjelland: Three layers of context for useful AI. Medium, 2025. Online: https://medium.com/@pcbje/three-layers-of-context-for-useful-ai-f533276ca50a
- ↑ Sen Lin: Designing the 3 layers of AI context. UX Collective, 2025. Online: https://uxdesign.cc/designing-the-3-layers-of-ai-context-9a35a5f6e63a
- 1 2 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-torres
- ↑ ChatPRD: How I AI: Teresa Torres. chatprd.ai, 2026. Online: https://www.chatprd.ai/how-i-ai/teresa-torres-claude-code-obsdian-task-management
- ↑ 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
- ↑ Context Engineering: Ein Knowledge OS mit Claude aufbauen — David Latz. Abgerufen am 17. März 2026.
- ↑ Prompt Engineering Is Dead, and Context Engineering Is Already Obsolete: Why the Future Is Automated Workflow Architecture with LLMs. 12. Juli 2025, abgerufen am 17. März 2026 (englisch).
- 1 2 3 Linja Scharffetter: Mein Wissen hat eine Architektur – Knowledge Operating System in der Praxis. 2026, abgerufen am 8. April 2026.
- ↑ 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
- ↑ RAG and LLMs for Enterprise Knowledge Management. In: Applied Sciences, MDPI, 2025. Online: https://www.mdpi.com/2076-3417/16/1/368
- ↑ M. Travers, J.P. Massar, J. Shrager: KnowOS: The (Re)Birth of the Knowledge Operating System. International Lisp Conference, 2005.
Weblinks
[Bearbeiten | Quelltext bearbeiten]- Philipp Schmid: Context Engineering – Formale Definition und Einordnung
- Simon Willison: Context Engineering – Begriffsgeschichte und Practitioner-Perspektive
- Anthropic: Claude Code Memory – Technische Dokumentation zu Instruktionsdateien