Context Engineering: Wie Sie KI-Tools als System nutzen statt als Chatfenster

Im März habe ich an dieser Stelle einen Artikel über Prompting veröffentlicht. Die Kernthese war simpel: Die Qualität einer KI-Ausgabe hängt nicht vom perfekt formulierten Prompt ab, sondern vom Kontext, den man dem Modell gibt. Rolle, Zielgruppe, Fachdaten, Formatvorgabe, Einschränkungen. Wer diese Bausteine liefert, bekommt brauchbare Ergebnisse. Wer sie weglässt, bekommt generischen Brei. Nicht weil das Modell schlecht ist, sondern weil es mit dem arbeiten muss, was es bekommt.

Dieser Artikel hat eine Lücke. Er behandelt Kontext als etwas, das man in ein Eingabefeld tippt. Ein Prompt, gut strukturiert, mit den richtigen Informationen angereichert, und dann hofft man auf das beste Ergebnis. In der Praxis reicht das für einfache Aufgaben. Für eine einzelne Produktbeschreibung, eine Meta-Description, eine Zusammenfassung. Aber wer KI-Tools regelmäßig einsetzt, für wiederkehrende Aufgaben, über mehrere Projekte hinweg, mit wachsendem Fachwissen im Hintergrund, stößt schnell auf ein Problem, das kein noch so guter Einzelprompt löst.

Das Problem ist nicht der Prompt. Das Problem ist das System drum herum. Oder genauer: das Fehlen eines Systems.

Sie arbeiten seit Monaten an einem Fachthema. Sie haben Dutzende Artikel gelesen, Videos geschaut, PDFs gesammelt. Dieses Wissen existiert auf Ihrer Festplatte, in Ihren Lesezeichen, in Ihrem Kopf. Aber in dem Moment, wo Sie eine KI dazu befragen wollen, stehen Sie vor zwei Problemen gleichzeitig: Das Kontextfenster ist begrenzt. Und Ihre Informationen liegen in unterschiedlichen Formaten an unterschiedlichen Orten. Sie kopieren einen Artikel rein, vielleicht zwei. Die KI antwortet auf Basis dieser Fragmente und ergänzt den Rest aus ihrem Trainingswissen, das veraltet, unpassend oder schlicht falsch sein kann. Sie korrigieren, prompten neu, laden ein anderes Dokument hoch, bekommen eine andere, aber nicht unbedingt bessere Antwort.

Genau für diese Verschiebung hat sich in der Fachwelt ein Begriff etabliert: Context Engineering. In meinem vorherigen Artikel habe ich ihn als Ausblick eingeführt. In diesem Artikel erkläre ich, was er konkret bedeutet, für alle, die KI-Tools nicht nur gelegentlich nutzen, sondern als festen Bestandteil ihrer Arbeit begreifen. Es geht nicht um Entwicklerthemen und nicht um Code. Es geht um die Frage: Wie baue ich das Informationssystem, das die KI braucht, um wirklich nützlich zu sein?

Was ist Context Engineering? Und warum taucht der Begriff gerade überall auf?

Wenn Sie in den letzten Wochen Artikel über KI-Entwicklung gelesen haben, sind Sie mit hoher Wahrscheinlichkeit über den Begriff Context Engineering gestolpert. Andrej Karpathy, Gründungsmitglied von OpenAI und ehemaliger KI-Chef von Tesla, nannte es die „Kunst und Wissenschaft, den Kontext zu füllen, der das Modell veranlasst, das gewünschte Ergebnis zu erzeugen". Anthropic, das Unternehmen hinter Claude, widmete dem Thema im September 2025 einen ausführlichen Engineering-Beitrag. Und auf Plattformen wie LinkedIn und X diskutieren Entwickler, ob der Begriff Prompt Engineering ablösen wird.

Aber was bedeutet er eigentlich? Und vor allem: Was bedeutet er für jemanden, der KI-Tools im Arbeitsalltag nutzt, ohne selbst Entwickler zu sein?

Die kürzeste Erklärung: Prompt Engineering ist die Fähigkeit, die richtigen Worte zu finden. Context Engineering ist die Fähigkeit, die richtige Informationsarchitektur zu bauen.

Wo der Unterschied sichtbar wird: Ein Beispiel aus der SEO-Praxis

Ein Beispiel aus meinem Arbeitsalltag als SEO macht das greifbar. Wir arbeiten bei Netzhirsch mit einem festen SEO-Framework: einem dokumentierten Prozess mit definierten Unterprozessen, Checklisten, Bewertungskriterien und Auswertungsmethoden. Dieses Framework-Wissen existiert in verschiedenen Dokumenten und Dateien. Gleichzeitig betreuen wir mehrere SEO-Projekte für unterschiedliche Websites, unterschiedliche Unternehmen, unterschiedliche Branchen, jeweils mit eigenen Datensätzen.

Auf der Ebene des Prompt Engineering würde man für jede Auswertung einen möglichst guten Prompt formulieren, die relevanten Framework-Dokumente in den Chat kopieren, die projektspezifischen Daten dazuladen und hoffen, dass das Modell beides sauber zusammenbringt. Beim zweiten Projekt dieselben Framework-Dokumente erneut hochladen, denselben System-Prompt von vorne schreiben, die neuen Daten einfügen. Beim dritten Projekt dasselbe.

Und irgendwann passiert, was in solchen Setups immer passiert:

Kein besserer Prompt löst diese Probleme. Sie entstehen nicht auf der Ebene der Formulierung, sondern auf der Ebene der Informationsarchitektur. Wie wird Framework-Wissen zentral gepflegt und projektübergreifend konsistent bereitgestellt? Wie trennt man methodisches Wissen, das für alle Projekte gilt, von projektspezifischen Daten, die strikt isoliert bleiben müssen?

Warum der Begriff gerade jetzt relevant wird

Das sind Context-Engineering-Fragen. Anthropic beschreibt die Verschiebung in seinem Engineering-Beitrag so: In den frühen Tagen der KI-Entwicklung war das Schreiben von Prompts der größte Teil der Arbeit, weil die meisten Anwendungsfälle einmalige Aufgaben waren. Eine Klassifikation, eine Texterstellung, eine Zusammenfassung. Je mehr sich die Nutzung aber in Richtung komplexerer Workflows entwickelt, die über mehrere Interaktionen und längere Zeiträume laufen, desto wichtiger wird die Frage, wie man den gesamten Kontextzustand steuert: System-Prompts, Tools, externe Daten, Konversationsverläufe, gespeichertes Wissen.

Für die Fachwelt ist das eine Verschiebung der Ingenieursdisziplin. Für alle anderen ist es eine Verschiebung der Denkweise. Und diese Denkweise beginnt mit einer Erkenntnis, die viele noch nicht verinnerlicht haben: Das Kontextfenster, in dem ein KI-Modell arbeitet, ist keine unbegrenzte Ressource. Es ist ein Arbeitsbereich mit sehr realen Grenzen.

Was das Kontextfenster wirklich ist, und warum „mehr reinpacken" keine Strategie ist

Im vorherigen Artikel habe ich das Kontextfenster als den begrenzten Arbeitsbereich beschrieben, in dem ein LLM operiert. Alles, was das Modell bei einer Anfrage „sehen" kann, liegt in diesem Fenster: der System-Prompt, die bisherige Konversation, hochgeladene Dokumente, der aktuelle Prompt. Was außerhalb liegt, existiert für das Modell nicht.

Diese Grundlagen bleiben gültig. Aber für das Verständnis von Context Engineering reicht die reine Größenangabe nicht aus. Die entscheidende Erkenntnis liegt eine Ebene tiefer, und sie widerspricht einer Intuition, die viele Nutzer haben: Mehr Kontext führt nicht automatisch zu besseren Ergebnissen. Ab einem bestimmten Punkt führt er zu schlechteren.

Context Rot: Warum volle Kontextfenster schlechtere Antworten liefern

Der KI-Anbieter Chroma hat für dieses Phänomen den Begriff Context Rot geprägt. In einer Studie testete Chroma 18 aktuelle Frontier-Modelle und kam zu einem eindeutigen Befund: Bei jedem einzelnen Modell sank die Fähigkeit, Informationen korrekt aus dem Kontext abzurufen, je mehr Tokens im Fenster lagen.

Die Erklärung ist architektonisch. Ein LLM basiert auf der Transformer-Architektur, in der jedes Token auf jedes andere Token im Kontext „achten" kann. Bei n Tokens entstehen n² paarweise Beziehungen. Je mehr Tokens im Fenster liegen, desto dünner verteilt sich diese Aufmerksamkeit. Anthropic nennt das in seinem Engineering-Beitrag ein Attention Budget: Das Modell muss seine Aufmerksamkeit auf alle Informationen im Fenster verteilen, und je mehr drin liegt, desto weniger Aufmerksamkeit bleibt für die einzelne Information.

Im vorherigen Artikel habe ich das „Lost in the Middle"-Problem beschrieben: LLMs verarbeiten Informationen am Anfang und Ende des Kontextfensters zuverlässiger als in der Mitte. Die Platzierungsstrategie, die ich dort empfohlen habe, bleibt ein hilfreicher Ansatz. Aber Context Rot zeigt, dass sie allein nicht reicht. Selbst die Verarbeitung am Anfang und Ende leidet, wenn das Fenster insgesamt zu voll ist. Es geht also nicht nur darum, wo man Informationen platziert. Es geht darum, wie viel man überhaupt hineingibt.

Lieber einen aufgeräumten Schreibtisch als einen überfüllten Aktenschrank

Für die Praxis hat das eine klare Konsequenz: Das Kontextfenster ist kein Aktenschrank, den man möglichst vollpackt. Es ist ein Schreibtisch. Und auf einem überfüllten Schreibtisch findet man nichts.

Zwei typische Fehler, die daraus entstehen:

Die Kontextebenen, die die meisten übersehen

Wenn die meisten Menschen an ihre Interaktion mit einer KI denken, denken sie an eine Ebene: den Prompt. Die Nachricht, die sie ins Eingabefeld tippen. In Wirklichkeit verarbeitet ein LLM bei jeder einzelnen Anfrage mehrere Informationsebenen gleichzeitig. Der Prompt ist nur die sichtbarste davon.

Im Prompting-Artikel habe ich diese Ebenen bereits eingeführt. Für das Verständnis von Context Engineering ist entscheidend, sie nicht als technische Details zu betrachten, sondern als Stellschrauben, an denen sich die Qualität jeder KI-Ausgabe drehen lässt. Jede Ebene beantwortet eine andere Frage. Und wer nur eine davon bedient, verschenkt die anderen.

Dauerhafte Anweisungen: Wer bin ich, und was soll das Modell wissen?

KI-Tools bieten zwei Wege, dem Modell dauerhaft Informationen mitzugeben. Die Bezeichnungen variieren zwischen den Anbietern (ChatGPT nennt es „Custom Instructions", Claude spricht von „User Preferences"), aber das Prinzip ist identisch. Der Unterschied zwischen den beiden Wegen ist simpel, aber wichtig.

• Globale Anweisungen gelten überall. Sie werden bei jedem Chat, in jedem Projekt automatisch mitgeschickt. „Ich arbeite im B2B-Marketing für einen mittelständischen Hersteller von Industriearmaturen. Meine Zielgruppe sind technische Einkäufer und Anlagenplaner im DACH-Raum. Ich schreibe auf Deutsch, sachlich-technisch, ohne Marketingfloskeln." Das ist das Grundprofil des Nutzers, die Informationen, die in jeder Interaktion relevant sind.
       
• Projektanweisungen gelten nur innerhalb eines bestimmten Projekts. In ChatGPT und Claude lassen sich Projekte anlegen, die jeweils eigene Anweisungen bekommen. „Du bist ein SEO-Analyst, der nach dem Framework X arbeitet. Du trennst strikt zwischen Framework-Methodik und projektspezifischen Daten. Du kennzeichnest Stellen, an denen Informationen fehlen." Das ist die aufgabenspezifische Konfiguration.

Also: Globale Anweisungen definieren, wer Sie sind. Projektanweisungen definieren, was das Modell in diesem konkreten Kontext tun soll. Beides zusammen bildet den Rahmen, innerhalb dessen das Modell arbeitet, noch bevor Sie überhaupt einen Prompt formuliert haben.

Memory: Das automatische Gedächtnis und seine Tücken

Memory geht einen Schritt weiter als dauerhafte Anweisungen. Hier speichert das Modell eigenständig Informationen aus früheren Gesprächen und greift später darauf zurück. Ohne dass der Nutzer aktiv etwas hinterlegt.

Der Nutzen ist offensichtlich: Das Modell lernt Ihre Präferenzen mit der Zeit kennen. Die Risiken habe ich im Prompting-Artikel bereits beschrieben, und sie sind im Kontext von Context Engineering noch relevanter. Memory unterscheidet traditionell nicht zwischen Projekten. Neuere Funktionen wie OpenAIs Project-only Memory setzen hier an, aber in der Standardkonfiguration gilt: Informationen aus Projekt A können in Antworten zu Projekt B auftauchen. Private Brainstorming-Ergebnisse eines Kollegen können die Tonalität in einem anderen Chat beeinflussen. Und veraltete Memories, die niemand aufräumt, liefern dem Modell bei jeder Anfrage Kontextfragmente, die längst nicht mehr stimmen.

Dokumente: Die Wissensbasis für die aktuelle Aufgabe

Hochgeladene Dokumente, Dateien und Webinhalte beantworten die Frage: Auf welches Fachwissen soll das Modell bei dieser Aufgabe zugreifen?

Das ist im Kern dasselbe Prinzip wie RAG (Retrieval Augmented Generation), das ich im Prompting-Artikel als Verfahren beschrieben habe, bei dem das Modell gezielt auf externe Wissensquellen zugreift. Der Unterschied: Beim manuellen Hochladen entscheiden Sie selbst, welche Dokumente relevant sind. Bei einer echten RAG-Pipeline trifft ein System diese Entscheidung automatisch. In beiden Fällen gilt: Die Qualität der Ausgabe hängt nicht mehr davon ab, was das Modell in seinen Trainingsdaten gesehen hat, sondern davon, was man ihm konkret zur Verfügung stellt.

Der häufigste Fehler an dieser Stelle ist nicht, zu wenig hochzuladen, sondern zu viel. Dokumente ins Projekt zu laden, „weil sie vielleicht relevant sein könnten", ist keine Kontextstrategie. Es ist eine Einladung an Context Rot.

Wie man ein Gedächtnis baut, das über einen Chat hinausgeht

Die Kontextebenen aus dem vorherigen Abschnitt lösen ein Problem: Sie machen einzelne Chats und Projekte besser. Aber sie stoßen an eine Grenze, die jeder kennt, der KI-Tools für wissensintensive Arbeit einsetzt.

Sie haben zu einem Fachgebiet über Monate oder Jahre Wissen angesammelt. Hunderte Artikel gelesen, Konferenzvorträge verfolgt, YouTube-Videos geschaut, PDFs gesammelt, LinkedIn-Posts gespeichert. Dieses Wissen existiert verstreut über Ihre Festplatte, Ihre Lesezeichen, Ihre Notizen. Aber in dem Moment, wo Sie die KI dazu befragen wollen, passt es nicht ins Kontextfenster. Nicht annähernd. Sie laden ein Dokument hoch, vielleicht zwei. Die KI antwortet auf Basis dieser Fragmente und ergänzt den Rest aus ihrem Trainingswissen. Das Ergebnis klingt plausibel, aber es basiert nur zu einem Bruchteil auf Ihrem tatsächlichen Wissensstand.

Auch Claude Projects oder ChatGPT-Projekte lösen dieses Problem nur bedingt. Die Upload-Grenzen sind endlich. Bei Hunderten Quellen in unterschiedlichen Formaten ist man schnell am Limit. Und selbst wenn alles hineinpassen würde: Ein Projekt, das mit Hunderten Dokumenten gefüllt ist, produziert exakt das Context-Rot-Problem aus dem vorherigen Abschnitt. Zu viel auf dem Schreibtisch, zu wenig Fokus.

Die Frage lautet also: Wie gibt man einer KI Zugang zu einer großen, wachsenden Wissensbasis, ohne das Kontextfenster zu überlasten?

Seinen eigenen KI-Bibliothekar erstellen

Die Antwort liegt in einem Prinzip, das in der KI-Entwicklung unter dem Namen RAG (Retrieval Augmented Generation) bekannt ist. Das Konzept ist einfacher als der Name vermuten lässt.

Stellen Sie sich eine Bibliothek vor. Sie haben eine Frage zu einem bestimmten Thema. Ein guter Bibliothekar liest nicht die gesamte Bibliothek durch, um Ihnen zu antworten. Er weiß, wo die relevanten Bücher stehen, schlägt die passenden Kapitel auf und legt Ihnen genau die Seiten vor, die Ihre Frage beantworten. Alles andere bleibt im Regal.

RAG funktioniert nach demselben Prinzip:

Das Kontextfenster bleibt schlank und fokussiert, während die Wissensbasis im Hintergrund beliebig groß sein kann.

Von der Datenbank zum lebenden Wiki

Andrej Karpathy hat diesen Gedanken weitergeführt. In einem vielbeachteten Beitrag auf der Plattform X stellte er ein Konzept vor, das über reine Recherche hinausgeht: LLM Knowledge Bases, also persönliche Wissensbibliotheken, die von einer KI gepflegt werden.

Der Ablauf folgt einer klaren Logik:

Sammeln. Rohdaten aus beliebigen Quellen werden an einem Ort zusammengeführt: Fachartikel, wissenschaftliche Papers, YouTube-Transkripte, Datensätze, Bilder. Alles, was zum Thema gehört, kommt in einen Rohordner.

Kompilieren. Eine KI verarbeitet diese Rohdaten und erstellt daraus ein strukturiertes Wiki: Zusammenfassungen, Konzeptartikel, Querverweise, Kategorien. Nicht der Mensch organisiert das Wissen. Die KI tut es.

Abfragen. Sobald das Wiki eine gewisse Größe erreicht hat, lassen sich komplexe Fragen dagegen stellen. Die KI recherchiert die Antwort innerhalb der eigenen Wissensbasis, verknüpft Informationen aus verschiedenen Quellen und liefert fundierte, quellenbasierte Ergebnisse.

Zurückschreiben. Die Ergebnisse jeder Recherche fließen zurück ins Wiki und reichern es an. Jede gestellte Frage, jede Analyse, jede Verknüpfung macht die Wissensbasis besser. Dabei ist entscheidend, dass nur verifizierte Ergebnisse zurückgeschrieben werden. Wenn ungeprüfte KI-Ausgaben zurück ins Wiki fließen, entsteht eine Feedback-Schleife, in der sich Fehler verfestigen statt aufgelöst zu werden.

Qualität sichern. Genau deshalb sind regelmäßige „Health Checks" durch die KI der letzte Schritt: Inkonsistenzen finden, fehlende Querverweise ergänzen, Widersprüche auflösen. Das Wiki wird nicht nur größer, sondern zuverlässiger.

Karpathy beschreibt, dass er selbst kaum noch manuell an seinem Wiki arbeitet. Die KI schreibt, strukturiert und pflegt. Er stellt die Fragen und steuert die Richtung. Bei rund 100 Artikeln und 400.000 Wörtern funktioniere das erstaunlich gut, auch ohne aufwändige technische Infrastruktur.

Ich habe diesen Ansatz für meine eigene Arbeit umgesetzt. Mein Ziel war es, zu einem spezifischen Fachgebiet eine Wissensbibliothek aufzubauen, die alles umfasst, was bestimmte Fachautoren je publiziert haben. Über 300 Quellen: Blogartikel, YouTube-Transkripte, PDFs, Konferenzvorträge.

Das Problem war exakt das, was ich oben beschrieben habe. Kein Kontextfenster der Welt fasst 300 Quellen gleichzeitig. Die Lösung war ein lokales System, das bei jeder Frage automatisch die passendsten Textstellen aus der gesamten Bibliothek findet und nur diese an die KI übergibt.

Dabei zeigte sich, dass eine einfache Ähnlichkeitssuche nicht ausreicht. Wer nach einem Fachbegriff wie „E-E-A-T" sucht, braucht Textstellen, die genau diesen Begriff enthalten. Eine semantische Suche findet aber möglicherweise Passagen über „Vertrauen und Expertise", die inhaltlich verwandt klingen, den konkreten Fachbegriff aber nie nennen. Die Lösung war eine Kombination aus zwei Suchwegen: einer semantischen Suche, die inhaltliche Verwandtschaft erkennt, und einer Begriffssuche, die exakte Fachterminologie aufspürt. Ein nachgeschaltetes Relevanz-Ranking filtert dann aus, was nur oberflächlich passt, und lässt nur die wirklich besten Quellen durch.

Über das Model Context Protocol (MCP), eine von Anthropic entwickelte offene Schnittstelle, die zunehmend auch von anderen KI-Tools unterstützt wird, ist diese Wissensbibliothek direkt mit Claude Desktop verbunden. Ich tippe eine Frage ein, und Claude durchsucht automatisch alle 300 Quellen, ohne dass ich ein Dokument manuell hochladen muss. Die Ergebnisse basieren auf dem, was meine Quellen tatsächlich sagen, nicht auf dem Trainingswissen des Modells. Und so sah dies im Claude-Chat dann aus mit über 24.000 Chunks aus 338 unterschiedlichen Quellen.

Was das für Sie bedeutet

Die Botschaft dieses Abschnitts ist nicht „Bauen Sie sich jetzt alle eine eigene RAG-Pipeline". Der technische Aufwand dafür ist je nach Anspruch erheblich. Die Botschaft ist eine andere: Die Zukunft der KI-Nutzung liegt darin, der KI das richtige Wissen zur richtigen Zeit zugänglich zu machen.

Das kann eine professionelle Wissensdatenbank wie die beschriebene sein. Das kann aber auch schon ein gut gepflegtes Claude Project sein, in dem Sie die wichtigsten Dokumente zu einem Thema kuratiert haben, mit einer durchdachten Projektanweisung und regelmäßiger Aktualisierung. Der Denkansatz ist derselbe: nicht alles auf einmal in den Kontext kippen, sondern ein System bauen, das der KI gezielt das gibt, was sie für die aktuelle Aufgabe braucht. Die Skalierung unterscheidet sich. Das Prinzip nicht.

Context Engineering im Alltag: Was Sie morgen anders machen können

Die bisherigen Abschnitte haben das Prinzip erklärt. Dieser Abschnitt macht es handhabbar. Denn Context Engineering klingt nach einem großen Konzept, beginnt aber mit kleinen Entscheidungen, die jeder sofort umsetzen kann.

Globale Anweisungen als Grundprofil pflegen

Die meisten Nutzer richten ihre globalen Anweisungen einmal ein und vergessen sie. Dabei sind sie der wirkungsvollste Hebel für konsistente Ergebnisse, weil sie bei jeder einzelnen Interaktion greifen, ohne dass man daran denken muss.

Ein gutes Grundprofil beantwortet drei Fragen: In welchem beruflichen Kontext arbeite ich? Welche Zielgruppe adressiere ich typischerweise? Welche Sprach- und Stilpräferenzen habe ich?

Ein Beispiel: „Ich arbeite als Marketing-Manager für einen mittelständischen Hersteller von Industriearmaturen. Meine Zielgruppe sind technische Einkäufer und Anlagenplaner im DACH-Raum. Ich schreibe auf Deutsch, sachlich-technisch, ohne Marketingfloskeln und ohne Anglizismen, wenn es ein deutsches Äquivalent gibt."

Das ist kein Prompt. Das ist ein dauerhafter Kontextrahmen, der jede spätere Interaktion präziser macht.

Projekte als Kontextcontainer nutzen

Claude Projects und ChatGPT-Projekte sind das mächtigste Context-Engineering-Werkzeug, das den meisten Nutzern bereits zur Verfügung steht. Entscheidend ist, wie man sie einsetzt.

Ein Projekt ist kein Sammelordner für alles, was irgendwie zum Thema gehört. Ein Projekt ist ein Kontextcontainer: eine abgegrenzte Umgebung mit eigenen Anweisungen, eigenen Dokumenten und einem eigenen Wissensbestand. Innerhalb des Containers hat die KI Zugriff auf alles, was sie braucht. Außerhalb des Containers existiert nichts davon.

Für das SEO-Framework-Beispiel aus Abschnitt 2 würde das konkret so aussehen:

Die Framework-Dokumente bleiben über alle Projekte hinweg gleich. Die projektspezifischen Daten werden pro Projekt ausgetauscht. Die Projektanweisung wird einmal sauber formuliert und bei Bedarf angepasst. So entsteht ein wiederholbarer Workflow, bei dem das methodische Wissen konstant bleibt und nur die Daten wechseln.

Memory bewusst steuern statt laufen lassen

Memory ist nützlich für stabile, langfristige Informationen: Unternehmensprofil, Zielgruppendefinition, bevorzugter Schreibstil. Für alles, was sich zwischen Projekten unterscheidet oder sich regelmäßig ändert, ist Memory eine Fehlerquelle.

Drei Regeln, die in der Praxis den Unterschied machen:

Erstens: Prüfen Sie regelmäßig, was gespeichert ist. Sowohl ChatGPT als auch Claude bieten die Möglichkeit, gespeicherte Memories einzusehen und einzeln zu löschen.

Zweitens: Nutzen Sie projektbezogene Memory, wo sie verfügbar ist. Bei projektbezogener Memory greift das Modell ausschließlich auf Konversationen innerhalb eines Projekts zu. Das verhindert die Kontextvermischung, die bei globaler Memory unweigerlich entsteht.

Drittens: Im Zweifelsfall lieber ohne. Wenn Sie mit vertraulichen Kundendaten arbeiten oder zwischen mehreren Projekten wechseln, ist deaktivierte Memory die sicherere Wahl. Was Sie an Komfort verlieren, gewinnen Sie an Kontrolle.

Der Workflow: Erst Kontext aufbauen, dann prompten

Die meisten Nutzer öffnen einen neuen Chat und beginnen sofort mit dem Prompt. Context Engineering dreht diese Reihenfolge um.

Vor dem ersten Prompt: Stimmt die Projektanweisung? Sind die richtigen Dokumente geladen? Sind irrelevante Dokumente entfernt? Enthält die Memory Informationen, die stören könnten?

Beim Prompten: Den Prompt schlank halten. Wer die Kontextebenen sauber konfiguriert hat, muss im Prompt selbst weniger erklären. Keine Rolle mehr formulieren, die schon in der Projektanweisung steht. Keine Stilregeln mehr wiederholen, die in den globalen Anweisungen stehen. Der Prompt konzentriert sich auf das, was nur er leisten kann: die konkrete Aufgabe.

Nach dem Ergebnis: Bei längeren Konversationen regelmäßig Zwischenergebnisse zusammenfassen lassen und einen neuen Chat starten. Das ist kein eleganter Ansatz, sondern ein pragmatischer Workaround: Solange KI-Tools kein automatisches Kontextfenster-Management bieten, bleibt das manuelle Zusammenfassen und Neustarten der zuverlässigste Weg, um Context Rot in langen Konversationen zu vermeiden.

Context Engineering von der anderen Seite

Bisher habe ich Context Engineering aus einer Richtung betrachtet: von innen. Wie gebe ich einem KI-Tool die richtigen Informationen, damit es brauchbare Ergebnisse liefert? Aber dieselbe Logik gilt auch in die andere Richtung.

KI-Systeme sind nicht nur Werkzeuge, die Unternehmen nutzen. Sie sind zunehmend auch Systeme, die über Unternehmen sprechen. In Chatbot-Antworten, in AI Overviews, in agentengesteuerten Kaufempfehlungen. Und was diese Systeme über ein Unternehmen wissen, hängt davon ab, welchen Kontext sie darüber finden.

Im Prompting-Artikel habe ich Andrea Volpinis Framework der drei Gedächtnisschichten vorgestellt: semantisches Gedächtnis (Fakten und Entitäten), episodisches Gedächtnis (Ereignisse und Bewertungen), prozedurales Gedächtnis (Abläufe und Schnittstellen). Jede dieser Schichten bestimmt, was KI-Systeme über ein Unternehmen wissen und ob sie es in ihren Antworten berücksichtigen. Wer diese Schichten nicht aktiv gestaltet, überlässt es dem Zufall.

Was diesen Abschnitt mit dem Rest des Artikels verbindet, ist der Denkansatz. Context Engineering als Nutzer heißt: der KI die richtigen Informationen geben, in der richtigen Struktur, zum richtigen Zeitpunkt. Context Engineering als Marke heißt: dafür sorgen, dass KI-Systeme die richtigen Informationen über Sie finden, in der richtigen Struktur, an den richtigen Stellen. Die Techniken unterscheiden sich. Das Prinzip ist identisch.

Vom Prompt zur Kontext-Architektur

Context Engineering ist kein neues Werkzeug, das man lernen muss. Es ist ein Perspektivwechsel. Die Frage „Wie formuliere ich meinen Prompt?" wird abgelöst durch die Frage „Welches Informationssystem habe ich aufgebaut?". Wer diese zweite Frage nicht stellt, wird mit zunehmender Komplexität der eigenen KI-Nutzung immer mehr Zeit mit Korrigieren verbringen statt mit Arbeiten.

Die gute Nachricht: Der Einstieg erfordert keinen technischen Umbau. Er erfordert eine Gewohnheitsänderung. Globale Anweisungen pflegen, Projekte als Kontextcontainer nutzen, Memory bewusst steuern, Dokumente kuratieren statt anhäufen. Alles, was Sie dafür brauchen, steht Ihnen heute schon zur Verfügung. Sie müssen es nur als System begreifen statt als Ansammlung einzelner Chats.

Und das gilt in beide Richtungen. Ob Sie eine KI als Werkzeug nutzen oder als Marke in KI-generierten Antworten sichtbar sein wollen: Die zentrale Kompetenz bleibt dieselbe. Kontext gestalten.