Context Engineering für Unternehmen: was nach Prompt Engineering wirklich zählt

Was Context Engineering von Prompt Engineering unterscheidet

Prompt Engineering hat sich über die letzten Jahre als Disziplin etabliert: wie formuliert man eine Anweisung an ein Sprachmodell so, dass die Antwort verlässlich das gewünschte Format, den gewünschten Ton und die gewünschte inhaltliche Schärfe trifft. Das ist eine wichtige Disziplin — und sie reicht nicht aus, sobald ein Modell in einer realen Anwendung mehr sieht als nur eine einzelne Frage.

Ein produktives Setup gibt dem Modell pro Aufruf eine ganze Sammlung an Inhalten: einen System-Prompt mit Anweisungen, eine Sammlung von Wissensauszügen aus dem Retrieval, eine Liste von verfügbaren Werkzeugen mit Beschreibungen, eine Konversationshistorie und schließlich die aktuelle Nutzerfrage. Diese Sammlung ist der „Kontext" — und ihre Gestaltung ist eine eigene Disziplin.

Context Engineering beantwortet drei Fragen, die Prompt Engineering allein nicht klärt: Was kommt überhaupt in den Kontext? In welcher Reihenfolge? Was bleibt draußen — und warum? Diese drei Fragen treffen jede produktive LLM-Anwendung, unabhängig vom Modell, vom Anbieter und vom Use Case.

Die fünf Komponenten des Kontexts

In einer produktiven Anwendung sitzen typischerweise fünf Komponenten parallel im Kontextfenster. Ihr Zusammenspiel zu beherrschen ist die eigentliche Aufgabe von Context Engineering.

Die erste Komponente ist der System-Prompt. Hier stehen Rolle, Verhaltensregeln, Format-Vorgaben und globale Einschränkungen. Diese Komponente ändert sich pro Aufruf nicht — was sie zum natürlichen Kandidaten für Prompt-Caching macht. Wie eine saubere System-Prompt-Disziplin im Detail aussieht, haben wir im Beitrag zum Prompt Engineering im Unternehmen ausgeführt.

Die zweite Komponente ist die Werkzeugbeschreibung. Welche Tools stehen dem Modell zur Verfügung, mit welchen Argumenten, mit welcher Semantik. Das ist im Kontext oft umfangreicher als gedacht — pro Tool entstehen schnell hunderte Tokens, bevor der eigentliche Inhalt anfängt. Wie sich Tool-Definitionen sauber schneiden lassen, behandelt unser Beitrag zu Tool-Use und Function Calling.

Die dritte Komponente ist abgerufenes Wissen. Bei RAG-Systemen kommen pro Anfrage Auszüge aus der Wissensbasis hinzu. Diese Komponente ist meist die größte und gleichzeitig die volatilste — sie ändert sich mit jeder Anfrage. Hier entstehen die meisten Token-Ausreißer.

Die vierte Komponente ist die Konversationshistorie. In mehrstufigen Dialogen wächst sie mit jedem Schritt. Ohne Disziplin füllt sie das Kontextfenster, lange bevor der eigentliche Vorgang abgeschlossen ist.

Die fünfte Komponente ist die aktuelle Nutzeranfrage. Sie ist meistens die kleinste — und gleichzeitig die einzige, auf die das Engineering-Team keinen direkten Einfluss nimmt. Sie definiert, was die anderen vier Komponenten zusammen leisten müssen.

Token-Budget-Management als operative Disziplin

Jedes Modell hat ein Kontextfenster mit harter Obergrenze — und einen weichen Bereich, in dem die Antwortqualität spürbar zu sinken beginnt, lange bevor das harte Limit erreicht wird. Context Engineering bedeutet, mit beidem bewusst umzugehen.

Praktisch heißt das: pro Anwendung wird ein Token-Budget pro Komponente festgelegt. Wie viele Tokens dürfen System-Prompt und Werkzeugbeschreibungen maximal beanspruchen? Wie viele bleiben für abgerufenes Wissen, wie viele für die Konversationshistorie? Welcher Rest ist für die Antwort reserviert? Ohne diese Aufteilung wachsen einzelne Komponenten unkontrolliert in die Domäne der anderen — und am Ende fehlt dem Modell der Platz für eine gute Antwort.

In Anwendungen mit hohem Volumen wird dieses Token-Budget gleichzeitig zur Kostendisziplin: jede zusätzliche Eingabe-Token-Schicht zahlt sich pro Aufruf wider. Welche Hebel im Detail wirken — Modell-Tiering, Prompt-Caching, Retrieval-Disziplin — haben wir im Beitrag zur LLM-Kostenoptimierung ausgeführt. Context Engineering ist dort die übergeordnete Klammer.

Reihenfolge und Hierarchie im Kontextfenster

Sprachmodelle behandeln nicht alle Tokens im Kontext gleich. Die Position entscheidet, wie stark eine Information ins Antwortverhalten einfließt. Diese Beobachtung ist alt, im Long-Context-Zeitalter aber besonders relevant — und wirkt sich auf jede produktive Anwendung aus.

Drei Muster sind in unseren Projekten besonders robust. Erstens stehen Anweisungen, die das Verhalten regeln — Verbote, Format-Vorgaben, Eskalationsregeln — am Anfang des Kontexts. Zweitens stehen aktuelle Aufgabe und Nutzeranfrage nahe am Ende, weil Modelle die jüngsten Tokens stärker gewichten. Drittens werden abgerufene Wissensquellen bewusst dazwischen platziert und klar als „Kontext, nicht als Anweisung" markiert.

Diese Reihenfolge ist mehr als ein Stil — sie ist eine Verteidigungslinie. Inhalte aus Wissensquellen, die fälschlicherweise als Anweisung interpretiert werden, sind die zentrale Klasse von Prompt-Injection-Risiken. Eine bewusste Hierarchie im Kontext senkt die Wirksamkeit vieler Injection-Versuche spürbar — sie ersetzt sie nicht, aber sie ist eine wichtige Schicht.

Long-Context-Modelle und ihre Trade-offs

Mit Modellen, die hunderttausend bis Millionen Tokens im Kontext halten, klingt Context Engineering zunächst einfacher: einfach mehr reinwerfen. In der Praxis entstehen mit langem Kontext eigene Probleme, die wir in produktiven Setups regelmäßig sehen.

Erstens Aufmerksamkeit verteilt sich. Modelle bei langem Kontext verlieren häufig die Schärfe für einzelne Aussagen in der Mitte — das bekannte „lost in the middle"-Phänomen ist nicht verschwunden, nur abgemildert. Wer wichtige Informationen verlässlich nutzen will, sollte sie an exponierten Positionen platzieren, nicht im langen Bauch des Kontexts.

Zweitens Latenz und Kosten skalieren. Auch wenn das Modell viele Tokens verarbeiten kann, dauert das spürbar länger und kostet pro Aufruf entsprechend mehr. Bei interaktiven Anwendungen am Arbeitsplatz wird langer Kontext schnell zum Geschwindigkeitsproblem.

Drittens verschwimmt die Quellenzuordnung. Je mehr Material im Kontext liegt, desto schwerer wird für das Modell, eine Antwort eindeutig auf eine konkrete Quelle zurückzuführen. Belegbarkeit leidet — und mit ihr das Vertrauen der Nutzer in die Antwort.

Die ehrlichste Antwort ist meist nicht „mehr Kontext", sondern besseres Retrieval: weniger Material, aber relevanter. Hier zahlt sich Investition in die Wissensbasis und das Retrieval-Verfahren mehr aus als der Wechsel zu einem Modell mit größerem Kontextfenster.

Context Caching strategisch nutzen

Mit Anbieter-seitigem Prompt-Caching — etwa Anthropic Prompt Caching oder vergleichbare Mechanismen — verändert sich die Wirtschaftlichkeit von Context Engineering. Stabile Teile des Kontexts werden zwischengespeichert und müssen nicht bei jedem Aufruf neu verarbeitet werden.

Damit Caching wirksam wird, müssen die stabilen Teile architektonisch klar von den volatilen getrennt sein. Praktisch heißt das: System-Prompt, Werkzeugbeschreibungen und stabile Wissens-Grundlagen kommen in einen Block, der gecacht wird; anfragespezifisches Wissen, Konversationshistorie und Nutzerfrage kommen in einen getrennten Block, der pro Aufruf neu zusammengestellt wird.

Diese Trennung ist eine Architektur-Entscheidung, keine reine Konfiguration. Wer sie nicht beim ersten Bau einplant, verbaut sich später teure Optimierungswege — denn nachträglich ist es deutlich aufwendiger, einen unsauber gewachsenen Prompt- Aufbau wieder in saubere Schichten zu zerlegen.

Context Engineering in agentischen Anwendungen

In agentischen Setups wird Context Engineering noch entscheidender, weil mehrere Modellaufrufe nacheinander erfolgen und jeder eine eigene Kontext-Komposition verlangt. Drei zusätzliche Aspekte werden hier besonders wichtig.

Erstens Zwischenergebnisse als Kontext. Was ein Schritt produziert, wird oft im nächsten gebraucht — aber nicht jedes Detail. Eine bewusste Komprimierung, Zusammenfassung oder selektive Übernahme ist Pflicht; sonst wächst der Kontext mit jedem Schritt linear, und das System läuft in Latenz und Kostenprobleme.

Zweitens Kontext pro Sub-Agent. In Multi-Agent-Systemen sieht jeder Agent typischerweise nicht alles. Welche Information wem mitgegeben wird, ist eine Designentscheidung — die Antwortqualität und das Sicherheitsmodell hängen daran.

Drittens klare Trennung zwischen Lese- und Aktions-Kontext. Wer ein Modell zuerst etwas lesen lässt und dann eine Aktion auslösen, sollte beide Schritte mit unterschiedlich gestaltetem Kontext bedienen — der Lese-Schritt mit möglichst neutralem, der Aktions-Schritt mit klar gefassten Erwartungen. Diese Trennung ist eng mit der gleichnamigen Verteidigung gegen indirekte Prompt Injection verwandt.

Tests und Beobachtbarkeit für Context-Strategien

Eine Context-Strategie ist nur so gut wie die Disziplin, mit der sie geprüft wird. Drei Bausteine machen den Unterschied zwischen einer Strategie auf dem Papier und einer, die im Betrieb trägt.

Erstens Token-Telemetrie pro Komponente. Wie viele Tokens verbrauchen System-Prompt, Werkzeugbeschreibungen, Wissen und Historie pro Anfrage tatsächlich? Welche Anwendungen reißen das Budget? Welche Anfragen liegen sehr nah am harten Kontextlimit? Diese Beobachtbarkeit gehört in dieselbe Schicht, die wir im Beitrag zu LLM-Monitoring und Observability ausgeführt haben.

Zweitens Regressionstests bei jeder Context-Änderung. Eine scheinbar harmlose Umstellung im System-Prompt oder in der Reihenfolge der Wissensauszüge kann Antwortqualität spürbar verschieben. Tests gegen ein kuratiertes Set realer Anfragen sichern, dass Optimierungen wirklich Verbesserungen sind. Diese Disziplin überschneidet sich direkt mit LLM-Qualitätssicherung.

Drittens Modellwechsel als Context-Frage. Wenn ein neues Modell getestet wird, ist nicht nur die Antwortqualität pro Anfrage relevant, sondern auch wie das neue Modell mit derselben Context-Komposition umgeht. Manche Modelle verarbeiten lange Kontexte besser, andere reagieren empfindlicher auf Reihenfolge. Eine Context-Strategie sollte daher pro Modell überprüft werden, nicht einmal entworfen und dann unverändert übernommen.

Typische Fehler in Context-Strategien

Der häufigste Fehler ist, alles ins Kontextfenster zu werfen, was technisch hineinpasst. Mehr Kontext ist nicht automatisch besser — und oft messbar schlechter, wenn das Modell vor lauter Material die wichtigen Aussagen verliert.

Der zweite Fehler ist, Wissensauszüge als Anweisungen behandeln zu lassen. Ohne klare Markierung, dass abgerufenes Material Inhalt und keine Befehle ist, entstehen Antworten, die plötzlich Anweisungen aus den Quellen übernehmen — die Tür zu indirekter Prompt Injection.

Der dritte Fehler ist, Werkzeugbeschreibungen unkontrolliert wachsen zu lassen. Jedes neue Tool kostet Tokens — und in Anwendungen mit dreißig oder mehr Werkzeugen geht ein erheblicher Teil des Kontextfensters allein für die Beschreibungen drauf, bevor die eigentliche Aufgabe beginnt. Eine klare Auswahl relevanter Tools pro Aufruf, statt aller verfügbaren, ist hier eine ehrliche Verbesserung.

Der vierte Fehler ist, die Konversationshistorie unverändert mitzuschleppen. Ab einer bestimmten Tiefe lohnt sich Komprimierung, selektive Übernahme oder klare Schnitte zwischen Phasen — sonst wächst sie zur dominanten Komponente, die alles andere verdrängt.

Der fünfte Fehler ist, Context Engineering als einmalige Auslegung zu behandeln. Modelle ändern sich, Wissensbasen wachsen, Anwendungsmuster verschieben sich. Eine Context-Strategie gehört in den laufenden Betrieb — mit Telemetrie, Reviews und expliziten Anpassungspunkten bei Modellwechseln.

Wann externe Unterstützung sinnvoll ist

Für eine erste Anwendung mit klarem Use Case lässt sich Context Engineering intern stemmen, wenn das Team Erfahrung mit produktiven LLM-Anwendungen hat. Sobald aber mehrere Anwendungen, agentische Setups, große Wissensbestände oder eine Plattform für mehrere Teams zusammenkommen, lohnt sich ein gezielter Blick von außen — auf Komponentenschnitt, Token-Budgets, Caching-Architektur und Tests.

Wir arbeiten mit Unternehmen, die LLM-Anwendungen nicht über die einzelne Prompt-Formulierung verbessern wollen, sondern über die Architektur dahinter. Wenn das zu Ihrer Situation passt, sprechen Sie uns an — am besten zu Beginn, wenn Komponentenschnitt, Reihenfolge und Caching-Strategie noch gestaltbar sind. Den passenden Rahmen dafür bieten wir über AI Engineering und unser LLM-QA.