Context Engineering: Warum der Kontext wichtiger ist als der Prompt

Der Prompt ist nicht das Problem — der Kontext ist es

Vor ein paar Tagen habe ich hier über Prompt Engineering geschrieben. Über Techniken, Patterns, die Kunst, einem LLM die richtige Anweisung zu geben. Alles korrekt, alles wichtig. Aber ich muss ehrlich sein: Prompt Engineering allein reicht nicht mehr. Nicht in einer Welt, in der KI-Agenten eigenständig arbeiten, Tools aufrufen und komplexe Aufgaben über mehrere Schritte hinweg lösen.

Was gerade in der KI-Community passiert, hat einen Namen: Context Engineering. Und es verändert fundamental, wie wir über die Interaktion mit Large Language Models nachdenken.

Die Kurzversion: Es geht nicht mehr darum, den perfekten Prompt zu formulieren. Es geht darum, dem Modell den richtigen Kontext zur Verfügung zu stellen — zur richtigen Zeit, in der richtigen Struktur, mit den richtigen Informationen. Das klingt nach einem feinen Unterschied. In der Praxis ist es ein Paradigmenwechsel.

Was ist Context Engineering eigentlich?

Prompt Engineering fragt: Wie formuliere ich meine Anweisung optimal?

Context Engineering fragt: Welche Informationen braucht das Modell, um die bestmögliche Entscheidung zu treffen — und wie stelle ich sie bereit?

Der Unterschied ist subtil, aber entscheidend. Beim Prompt Engineering optimierst du einen String. Beim Context Engineering designst du ein System. Du baust die Architektur, die dafür sorgt, dass ein LLM in jedem Moment genau die Informationen hat, die es braucht — nicht mehr und nicht weniger.

Stell dir einen neuen Mitarbeiter vor. Prompt Engineering: ihm eine perfekt formulierte E-Mail mit der Aufgabe schicken. Context Engineering: Wiki-Zugang, Team-Einführung, Code-Konventionen, relevante Tickets — und dann die Aufgabe. Wer liefert bessere Ergebnisse?

In der Praxis beschäftigst du dich mit Fragen wie:

• Welche Dateien muss das Modell sehen, bevor es Code schreibt?
• Welche vergangenen Entscheidungen sind relevant für die aktuelle Aufgabe?
• Welche Tools stehen zur Verfügung und wie sind sie dokumentiert?
• Wie viel Kontext passt ins Context Window — und was passiert, wenn es voll ist?
• Welche Informationen sind veraltet und müssen raus?

Das sind keine Prompt-Fragen. Das sind Architektur-Fragen.

Warum jetzt? Die Grenzen von Prompt Engineering

Prompt Engineering funktioniert hervorragend für einzelne Interaktionen. Du stellst eine Frage, bekommst eine Antwort. Du gibst eine Aufgabe, bekommst ein Ergebnis. Für den Chat-Use-Case ist das perfekt.

Aber sobald KI-Agenten ins Spiel kommen — Systeme, die eigenständig arbeiten, Entscheidungen treffen und über mehrere Schritte hinweg agieren — stößt reines Prompt Engineering an seine Grenzen. Warum?

Kontextverlust über Zeit: Ein Agent durchläuft dutzende Schritte. Irgendwann ist das Context Window voll, Informationen gehen verloren, Entscheidungen widersprechen sich. Kein Prompt verhindert das — es ist ein strukturelles Problem.

Dynamischer Informationsbedarf: In Schritt 1 braucht der Agent die Projektstruktur, in Schritt 3 die API-Doku, in Schritt 7 die Testergebnisse. Alles von Anfang an reinpacken geht nicht — du musst dynamisch entscheiden, was wann relevant ist.

Tool-Orchestrierung: Wie Tools definiert und dokumentiert sind, bestimmt, ob sie korrekt genutzt werden. Function Calling ist ein Baustein, aber die Architektur drumherum entscheidet.

Multi-Agent-Koordination: Wenn mehrere Agenten zusammenarbeiten, braucht jeder den richtigen Kontext — aber nicht den gesamten. Ein Informationsdesign-Problem, kein Prompt-Problem.

Die vier Säulen des Context Engineering

Aus meiner Praxis heraus sehe ich vier zentrale Bereiche, die Context Engineering ausmachen:

1. Instruktionskontext: Wer bist du und was sind die Regeln?

Das ist die Ebene, die dem klassischen Prompt Engineering am nächsten kommt — aber systematischer gedacht. Es geht nicht um einzelne Prompts, sondern um persistente Konfiguration.

In der Praxis heißt das: Du definierst Coding-Standards, Tech-Stack, Sicherheitsregeln und No-Gos einmalig als Konfiguration, die bei jedem Aufruf automatisch geladen wird. In KI-Agent-Plattformen wie OpenClaw geschieht das über System-Prompts und Konfigurationsdateien.

Der entscheidende Punkt: Diese Instruktionen müssen gepflegt werden — wie Code. Ändert sich dein Stack, muss der Instruktionskontext aktualisiert werden.

2. Wissenskontext: Was musst du wissen, um die Aufgabe zu lösen?

Hier wird es spannend — und hier scheitern die meisten Setups. Es geht um die Frage: Welches Wissen braucht das Modell für die aktuelle Aufgabe?

Statisches Wissen sind Dinge wie Dokumentation, API-Referenzen, Code-Konventionen. Die ändern sich selten und können vorab bereitgestellt werden.

Dynamisches Wissen ist kontextabhängig: der aktuelle Zustand der Codebase, offene Issues, letzte Änderungen, Testergebnisse. Das muss zum richtigen Zeitpunkt abgerufen werden.

RAG (Retrieval-Augmented Generation) ist das bekannteste Pattern dafür — Wissen in einer Vektordatenbank speichern und bei Bedarf die relevantesten Chunks abrufen. Aber RAG ist nur ein Werkzeug. Context Engineering fragt weiter: Was speicherst du? Wie chunkst du? Wie rankst du Relevanz? Was passiert bei veralteten Informationen?

Die Erfahrung zeigt: Ein Agent mit Zugriff auf die richtige Dokumentation schreibt besseren Code als ein Agent mit dem perfekten Prompt aber ohne Doku.

3. Gedächtniskontext: Was ist vorher passiert?

LLMs haben kein echtes Gedächtnis. Jede Anfrage startet bei Null. Das Context Window simuliert Kurzzeit-Gedächtnis, aber es ist begrenzt. Und genau hier wird Context Engineering zur Ingenieurskunst.

Es gibt verschiedene Ebenen von Gedächtnis, die du designen kannst:

Session-Memory ist das Context Window selbst — was in der aktuellen Konversation passiert ist. Arbeits-Memory speichert, was der Agent bei früheren Aufgaben gelernt hat, welche Fehler korrigiert wurden, welche Präferenzen der Nutzer hat. Langzeit-Memory enthält grundlegende Informationen über Projekt, Nutzer und Infrastruktur.

Die Herausforderung ist nicht das Speichern — das ist trivial. Die Herausforderung ist, das richtige Gedächtnis zur richtigen Zeit abzurufen. 500 Einträge bei jeder Anfrage laden verschwendet Context Window und verwässert die relevanten Informationen.

4. Handlungskontext: Was kannst du tun?

Die vierte Säule betrifft Tools und Aktionen. Das Model Context Protocol (MCP) definiert, wie Agenten mit externen Tools kommunizieren. Aber der Handlungskontext geht weiter:

• Berechtigungen: Was darf der Agent tun? Dateien lesen ist harmlos, E-Mails senden ist kritisch. Diese Sicherheits-Boundaries müssen explizit definiert sein.
• Priorisierung: Wenn ein Agent fünf Tools hat, die theoretisch funktionieren — welches soll er wählen? Die Beschreibung und der Kontext der Tools beeinflussen diese Entscheidung.
• Fehlerbehandlung: Was passiert, wenn ein Tool-Aufruf fehlschlägt? Der Agent braucht Kontext darüber, wie er mit Fehlern umgehen soll — erneut versuchen, Alternative nutzen oder den Nutzer fragen.

Die Qualität der Tool-Beschreibungen ist mindestens so wichtig wie der Prompt selbst. Ein schlecht beschriebenes Tool wird falsch oder gar nicht genutzt.

Context Engineering in der Webentwicklung: Praxis-Beispiele

Genug Theorie. Wie sieht Context Engineering konkret aus, wenn du als Webentwickler mit KI-Agenten arbeitest?

Beispiel 1: Code-Generierung mit Projektkontext

Statt dem Agenten nur zu sagen “Schreib mir eine API-Route”, stellst du sicher, dass er die bestehende Projektstruktur kennt, die vorhandenen Models und ihre Relationen sieht, bestehende API-Routen als Referenz hat und die Test-Konventionen versteht. Das Ergebnis: Code, der sich nahtlos ins Projekt einfügt — keine falschen Imports, keine inkompatiblen Patterns, keine falschen Annahmen über den Stack.

Beispiel 2: Debugging mit History-Kontext

Ein Bug taucht auf. Statt nur den Stacktrace zu übergeben, reichst du den letzten Git-Diff, relevante Log-Einträge und Informationen über frühere ähnliche Bugs an. Mit diesem Kontext wird aus einem generischen “Versuch mal dies und das” ein präzises “Der Bug wurde durch Commit xyz eingeführt, Zeile 42 hat eine Race Condition beim Cache-Invalidation.”

Beispiel 3: Content-Erstellung mit Brand-Kontext

Auch bei Content macht Context Engineering den Unterschied. Statt “Schreib einen Blogpost” gibst du dem System deine bisherigen Posts als Stil-Referenz, Brand Voice Guidelines, bereits behandelte Themen und die typische Leserschaft. Das Ergebnis fühlt sich an, als hättest du es selbst geschrieben — weil der Kontext das Modell in deine Perspektive versetzt.

Context Window Management: Die technische Herausforderung

Ein zentrales Problem: Das Context Window ist endlich. Selbst bei 200.000+ Token ist Platz ein knappes Gut. Und mehr Kontext bedeutet nicht automatisch bessere Ergebnisse — es gibt das “Lost in the Middle”-Phänomen: LLMs gewichten Informationen am Anfang und Ende stärker als in der Mitte.

Die wichtigsten Strategien: Relevanz-Filterung (nur laden, was für die aktuelle Aufgabe zählt), Komprimierung (lange Historien zusammenfassen statt roh behalten), Priorisierung (Instruktionen vor Wissen vor Gedächtnis) und Lazy Loading (Dokumentation erst laden, wenn sie gebraucht wird). All das erfordert ein System, das Relevanz automatisch bewertet — nicht manuelles Copy-Paste in den Chat.

Context Engineering als Architektur-Disziplin

Was mich fasziniert: Context Engineering ist im Kern eine Architektur-Aufgabe. Du designst ein Informationssystem — welche Daten wo gespeichert werden, wie sie abgerufen werden, in welcher Reihenfolge sie bereitgestellt werden.

Das ist vertrautes Terrain für uns Webentwickler. Caching-Strategien, Datenbank-Indizes, API-Versioning, Zugriffskontrolle — wir übertragen diese Konzepte jetzt auf die KI-Welt. Wer in Systemen denkt statt in einzelnen Prompts, hat hier einen natürlichen Vorteil.

Der Shift: Von “Was sage ich der KI?” zu “Was weiß die KI?”

Der fundamentale Mindset-Shift ist: Hör auf, den perfekten Prompt zu suchen. Fang an, das perfekte Informationssystem zu bauen.

Prompt Engineering wird nicht verschwinden. Es bleibt eine wichtige Teilkompetenz. Aber es wird eine Ebene in einem größeren System — nicht das System selbst.

Die Entwickler, die den größten Nutzen aus KI ziehen, sind nicht die mit den cleversten Prompts — es sind die, die Kontext als System designen. Die Architekturen bauen, in denen KI-Modelle ihr volles Potenzial entfalten.

Wenn du gerade erst startest, fang mit Prompt Engineering an — das sind die Grundlagen. Aber behalte im Hinterkopf: Der wahre Hebel liegt nicht im Prompt. Er liegt im Kontext.