Infrastruktur & Betrieb
Context Engineering — die Kunst, einem KI-Modell den richtigen Kontext zu geben
Der Prompt ist nur die Spitze des Eisbergs. Was ein KI-Modell sieht, bevor es antwortet — Systeminstruktionen, Retrieval-Ergebnisse, Tool-Outputs, Session-Historie — entscheidet über die Qualität. Context Engineering ist die Disziplin, diese Informationsumgebung zu gestalten.
Warum das Thema jetzt wichtig wird
Der Prompt allein reicht nicht
Prompt Engineering war 2023/2024 die Kernkompetenz für alle, die mit KI arbeiten. 2026 hat sich das Bild verschoben. Ein kluger Prompt hilft — aber er trägt keinen mehrstufigen Agenten, kein unternehmenskritisches System und keine 50-Schritte-Pipeline.
Tobi Lütke, CEO von Shopify, hat den Begriff geprägt, den Simon Willison im Juni 2025 festhielt: "the art of providing all the context for the task to be plausibly solvable by the LLM". Die Kunst, einem Modell genau den Kontext zu geben, der eine Aufgabe lösbar macht — nicht mehr, nicht weniger.
Andrej Karpathy hat die Idee aufgegriffen und erweitert: Der Context Window wird zur Programmschicht. Was ins Fenster passt, wird ausgeführt. Was nicht hineinpasst, muss komprimiert, selektiert oder abgerufen werden.
Context Engineering bedeutet:
- →Systeminstruktionen — die Regeln und Rollen für das Modell
- →Retrieval-Ergebnisse — was aus Wissensdatenbanken, Code und Dokumenten abgerufen wird
- →Tool-Outputs — was API-Calls, Datenbank-Abfragen und Berechnungen zurückliefern
- →Session-Historie — was bisher passiert ist
- →Memory & State — persistente Informationen über Sessions hinweg
- →Output-Schemata — erwartete Struktur der Antwort
Methodik
Vier Strategien, die Kontext beherrschbar machen
Context Engineering ist kein neues Prompt-Rezept. Es ist ein System aus vier Strategien, die bestimmen, was ein Modell sieht, wie es priorisiert und was draußen bleibt. Jede Strategie adressiert eine andere Herausforderung.
write
Write — Kontext schreiben
Systemprompt, Instruktionen, Regeln und Rollenklären, die das Modellverhalten steuern. Der Teil, der dem klassischen Prompt Engineering am nächsten kommt — aber versioniert, getestet und reviewed wird, nicht als Einzeiler im Chat.
select
Select — Kontext auswählen
Welche Informationen aus Unternehmensdatenbanken, Wikis, Code-Repositories und Dokumenten landen im Kontextfenster? Retrieval, RAG, Semantic Layer — all das sind Selektionsmechanismen. Die entscheidende Frage: Was ist die kleinste Menge an Information, die die Aufgabe plausibel lösbar macht?
compress
Compress — Kontext verdichten
Lange Konversationen, Session-Historien und Tool-Outputs müssen zusammengefasst werden, damit der Kontext nicht überläuft. Compaction (Zusammenfassung von Zwischenschritten), Structured Note-Taking und hierarchisches Memory (kurz-/langfristig) sind die Werkzeuge.
isolate
Isolate — Kontext isolieren
Nicht jeder Kontext gehört in jedes Fenster. Vertrauliche Daten, Personalakten oder strategische Informationen müssen getrennt bleiben. Sub-Agents, Tool-Berechtigungen und scopierte Wissensbasen sorgen dafür, dass nur das sichtbar wird, was für die aktuelle Aufgabe nötig ist.
Die vier Strategien basieren auf dem Framework von Lushbinary (2026) ergänzt um den organisationalen Isolate-Aspekt, der in der KV-Org-KB als wiederkehrendes Muster identifiziert wurde.
Praxiseinführung
Fünf Phasen: Vom Daten-Chaos zur Kontext-Infrastruktur
Der Weg zum produktionstauglichen Context Engineering führt durch fünf Phasen. Jede Phase baut auf der vorherigen auf — und hat ein typisches Anti-Pattern, das Teams immer wieder zurückwirft.
1. Daten harmonisieren
Daten aus Silos zusammenführen, bereinigen und strukturieren. Nicht jedes Dokument ist gleich nützlich — Qualität vor Quantität.
Anti-Pattern:
Alle verfügbaren Daten in einen RAG-Index kippen und hoffen, dass das Modell das Richtige findet.
2. Abfrage-Muster verstehen
Welche Fragen stellen Nutzer und Agenten? Welche Informationen werden dafür wirklich gebraucht? Nur wenn die Retrieval-Strategie zu den tatsächlichen Abfragen passt, entsteht Wert.
Anti-Pattern:
Eine Retrieval-Architektur bauen, ohne je analysiert zu haben, was Nutzer eigentlich fragen.
3. Retrieval & Re-Ranking
Die relevantesten Dokumente finden, in die richtige Reihenfolge bringen und dem Modell verfügbar machen. GraphRAG und Ontologien helfen, wenn reine Vektorsuche an ihre Grenzen stößt.
Anti-Pattern:
Vektorsuche als Allheilmittel — ohne Metadaten-Filter, ohne Re-Ranking, ohne Verständnis dafür, wann eine Ontologie nötig wäre.
4. Halluzinations-Validierung
Das Modell darf antworten — aber die Antwort muss gegen die Quellen geprüft werden. Grounding, Citation-Checks und Factual-Consistency-Modelle stellen sicher, dass die Antwort im Kontext bleibt.
Anti-Pattern:
Dem Modell blind vertrauen, weil die Antwort gut klingt — selbst wenn sie nicht in den Quellen steht.
5. Transparente Quellenangaben
Jede Antwort muss zurückverfolgbar sein. Nutzer und Agenten müssen sehen, woher eine Information stammt — und ob sie aktuell ist. Das schafft Vertrauen und ermöglicht Korrektur.
Anti-Pattern:
Eine KI-Antwort präsentieren, ohne dass jemand prüfen kann, ob die Quelle belastbar ist.
Die Phasen basieren auf Atlans Context Engineering Framework (2026) und OPEN.de's Mittelstands-Leitfaden (2026).
Architektur
Vier Säulen des Context Layers
Context Engineering ist nicht nur Methodik — es braucht eine technische Infrastruktur. Die AI-Org Knowledge Base hat aus mehreren Quellen (Sourcegraph, Simba Khadder, Databricks, Atlan) voneinander unabhängige, aber konsistente Architekturbeschreibungen identifiziert.
1
On-Demand Retrieval
Informationen werden erst im Moment der Anfrage abgerufen — nicht vorgehalten. RAG, GraphRAG und hybride Suchen gehören hierher. Die Herausforderung: Latenz, Relevanz und Kosten im Gleichgewicht zu halten.
2
Aktuelle Daten
Echtzeit-Daten aus APIs, Datenbanken und Events. Kein Retrieval, sondern direkter Zugriff. Hier geht es um Geschwindigkeit und Korrektheit — und darum, Staleness zu vermeiden.
3
Schnelle Retrieval-Ergebnisse
Vektordatenbanken, Embedding-Caches und Indizes für Low-Latency-Zugriff. Nicht alle Anfragen brauchen die volle Retrieval-Pipeline — oft reicht ein vorberechneter Embedding.
4
Memory
Persistente Informationen über Sessions hinweg. Kurzzeitgedächtnis (aktuelle Sitzung), Langzeitgedächtnis (wiederkehrende Muster) und episodisches Gedächtnis (spezifische Ereignisse). Memory wird 2026 zum First-Class-MCP-Primitiv.
Basierend auf Simba Khadders Context-Engine-Architektur (2026), Sourcegraphs Practical Guide (2026) und KI-Syndikat (2026).
Organisation
Context Engineering ist keine Tech-Disziplin
Die meisten Teams denken Context Engineering technisch: bessere Retrieval-Pipelines, größere Kontextfenster, schnellere Indizes. Aber die eigentliche Herausforderung ist organisational.
Kontext als Infrastruktur, nicht als Team-Ressource
Wenn jedes Team seinen eigenen Context Layer baut, entstehen Doppelarbeit, inkonsistente Qualität und keine organisatorische Hebelwirkung. Die strategisch wichtigste Entscheidung ist, Kontext als Shared Infrastructure zu behandeln — eine einzige, gesteuerte Schicht, die alle Agenten und Anwendungen versorgt.
Quelle: DataHub (2026)
Kontext-Produkte statt Prompt-Sammlungen
Ein guter Prompt ist kein Produkt. Ein Context Product schon: es ist versioniert, getestet, reviewed und hat einen Owner. Atlan beschreibt Context Products als "versioned, tested, governed bundles of context" — das ist die Messlatte.
Quelle: Atlan Context Engineering Framework (2026)
Kontext-Pflege ist Engineering Operations
Kontext wird stale, wenn niemand ihn pflegt. Regeln ändern sich, Dokumente werden aktualisiert, Datenbank-Schemata migrieren. Context Engineering braucht Staleness-Checks, Review-Zyklen und Freigabeprozesse — das ist kein einmaliger Aufwand, sondern dauerhafter Betrieb.
Quelle: Packmind (2026), AI-Org Knowledge Base
Wer ist für Kontext verantwortlich?
In vielen Organisationen gibt es niemanden, der sagt: "Dieser Kontext ist korrekt, aktuell und vollständig." Die Verantwortung verteilt sich zwischen Fachbereichen (die das Wissen haben) und Engineering (das die Pipeline baut). Klare Ownership — ähnlich wie Data Ownership — ist die Voraussetzung.
Quelle: Cortex (2026), Anthropic (2026)
Risiken
Woran Context Engineering scheitert
Die Technik ist bekannt. Die Anti-Patterns wiederholen sich. Fünf typische Fehler, die Teams immer wieder zurückwerfen:
Kontext-Rot
Kontext, der nicht aktualisiert wird, wird zur Desinformation. Ein System-Prompt vom Januar 2026, der im Juni noch aktiv ist, produziert systematisch falsche Antworten.
Lost in the Middle
Das Modell verliert Informationen aus der Mitte des Kontextfensters — Stanford-Studien zeigen, dass die ersten und letzten Tokens überproportional gewichtet werden. Längere Kontexte sind nicht automatisch bessere Kontexte.
Zu viel Kontext
Wenn alles in den Kontext gepackt wird, verwässert das die relevanten Informationen. Die Kunst ist nicht, möglichst viel unterzubringen — sondern die kleinste Menge, die die Aufgabe lösbar macht.
Keine Isolierung vertraulicher Daten
Wenn ein Agent Zugriff auf alle Unternehmensdaten hat, ist ein Leak vorprogrammiert. Context Isolation ist kein Nice-to-have, sondern Grundvoraussetzung für Compliance.
Context als reines Tech-Thema behandeln
Die effektivste Retrieval-Pipeline nützt nichts, wenn das Fachwissen nicht dokumentiert, nicht aktuell und nicht verantwortet ist. Context Engineering ist immer auch Organisationsentwicklung.
Selbstcheck
Wo steht eure Organisation?
Fünf Fragen, die zeigen, ob Context Engineering bei euch schon beginnt — oder ob die Verantwortung noch im Prompt-Engineering steckt.
Wisst ihr, welche Informationen eure KI-Systeme aktuell im Kontext haben — und wer sie verantwortet?
Wenn die Antwort 'nein' ist, habt ihr keine Kontrolle über euren Kontext.
Werden eure System-Instruktionen und Retrieval-Quellen versioniert, getestet und regelmäßig reviewed?
Wenn sie in einem Chat-Verlauf oder einer unversionierten Datei leben, seid ihr im Prompt-Engineering — nicht im Context Engineering.
Könnt ihr nachvollziehen, warum ein Agent eine bestimmte Entscheidung getroffen hat — und auf welcher Quelle sie basiert?
Wenn nicht, fehlt die Grundlage für Vertrauen und Korrektur.
Wisst ihr, welche Daten im Kontextfenster landen dürfen — und welche nicht?
Wenn jedes Teammitglied entscheidet, was es in den Prompt schreibt, gibt es keine Isolierung vertraulicher Informationen.
Habt ihr einen Prozess, der sicherstellt, dass alter Kontext erkannt und ersetzt wird?
Wenn nicht, produziert ihr systematisch Kontext-Rot — und damit schleichend falsche Antworten.
Wenn ihr zwei oder mehr Fragen mit "Nein" beantwortet, steckt ihr noch im Prompt Engineering. Der nächste Schritt ist nicht ein besseres Modell — es sind bessere Kontext-Prozesse.
Einordnung
Warum Context Engineering zur Führungsaufgabe wird
Context Engineering klingt technisch — und es hat eine tiefe technische Seite. Aber die Entscheidungen, die darüber bestimmen, ob KI in einer Organisation zuverlässig arbeitet, sind nicht technisch.
Wer entscheidet, welcher Kontext wichtig ist? Das ist eine Business-Frage. Wer pflegt den Kontext? Das ist eine Organisationsfrage. Wer stellt sicher, dass der Kontext aktuell ist? Das ist eine Governance-Frage.
Die Organisationen, die 2026 den größten Wert aus KI ziehen, sind nicht die mit den größten Modellen — es sind die, die verstanden haben, dass der Kontext das Betriebssystem der KI ist. Und Betriebssysteme brauchen Architektur, Betrieb und Verantwortung.
Verwandte Perspektiven
Context Engineering im AI-Hub
Context Engineering verbindet mehrere Themen des AI-Hubs. Es ist die Klammer zwischen der Retrieval-Infrastruktur einerseits und der Arbeitsweise von Teams und Agenten andererseits.
RAG & Semantic Layer — die Retrieval-Infrastruktur
Chunk-RAG, GraphRAG, Ontologien und Semantic Layer sind die Infrastruktur, die Context Engineering füttert. Ohne eine funktionierende Retrieval-Schicht ist Context Engineering nur Prompt-Engineering mit besseren Instruktionen.
Beyond LLMs — die gesamte KI-Landkarte
Context Engineering braucht ein Verständnis für die gesamte KI-Landkarte — nicht nur LLMs, sondern auch Retrieval, kleine Modelle, Embeddings und klassisches ML.
Agentic Engineering — die Arbeitsweise mit Agenten
Harness, Specs, Traces und Review-Systeme sind die Werkzeuge, mit denen Context Engineering praktisch wird. Agentic Engineering ohne Context Engineering ist blind für die Informationsumgebung des Agenten.
KI-Piloten & Skalierung — der Betrieb
Der häufigste Grund, warum KI-Initiativen nicht skalieren, ist laut aktueller Forschung schlechter Kontext, nicht das Modell. Context Engineering ist die Voraussetzung für zuverlässigen Betrieb.
Weiterlesen
Quellen und Vertiefung
- →
Sourcegraph — Context Engineering: A Practical Guide for AI Agents (2026)
sourcegraph.com/blog/context-engineering — Vier Säulen des Context Layers, praktische Pipeline-Architektur.
- →
Atlan — Context Engineering Framework for Enterprise AI in 2026
atlan.com/know/context-engineering-framework — Phase-0-Start im Data Catalog, Kontext-Produkte, fünf Implementierungsschritte.
- →
DataHub — Context Management Strategies for Enterprise AI
datahub.com/blog/context-management-strategies — Kontext als Shared Infrastructure, der strategisch wichtigste Shift.
- →
Lushbinary — Context Engineering for AI Agents: 2026 Production Guide
lushbinary.com/blog/context-engineering-ai-agents-production-guide — Die vier Strategien (Write, Select, Compress, Isolate) und Referenz-Architektur.
- →
OPEN.de — Context Engineering: KI-Fundament im Mittelstand
open.de/blog/context-engineering-ki-fundament-im-mittelstand — Deutscher Praxisleitfaden mit fünf Implementierungsphasen.
- →
Paperclipped — Context Engineering für KI-Agenten: Komplett-Guide 2026
paperclipped.de — LangChain Context Engineering, Memory-Stufen, Kompression — deutschsprachig und produktionsnah.
- →
KI-Syndikat — Dein KI-Tool ist nicht das Problem — dein Kontext ist es
ki-syndikat.de — Tobi Lütkes Definition von Context Engineering, Praxisbezug.
- →
Computer Weekly — Warum Context Engineering in Unternehmen immer wichtiger wird
computerweekly.com/de/feature/ — Ontologie als ROI-Treiber für KI-Projekte, Enterprise-Perspektive.
Vertiefung im AI-Hub
Mehr Orientierung zu KI in Organisationen
Diese Seite ist Teil der KI-Orientierung unter /themen/ai. Vertiefende Perspektiven:
- RAG & Semantic Layer— Chunk-RAG, GraphRAG, Ontologien und die Infrastruktur des Wissenszugangs
- Beyond LLMs— Gesamte KI-Landkarte mit Retrieval, Semantic Layer, klassischem ML
- Agentic Engineering— Harness, Kontext, Specs, Review und Traces
- KI-Piloten & Skalierung— Warum 85% der KI-Initiativen nie in Produktion gehen