Context Engineering: Warum ein besserer Prompt für KI-Agenten nicht mehr reicht

Vor zwei Jahren konnte man auf LinkedIn kaum über KI lesen, ohne früher oder später bei demselben Begriff zu landen:

Prompt Engineering.

„Du musst nur den richtigen Prompt schreiben.“

Dann kamen Prompt-Bibliotheken.

Prompt-Templates.

Prompt-Kurse.

Und System-Prompts, die irgendwann länger wurden als manche Arbeitsverträge.

Für einfache KI-Aufgaben ist gutes Prompting weiterhin wichtig.

Bei modernen KI-Agenten reicht es aber nicht mehr.

Denn ein Agent muss nicht nur wissen, was er tun soll.

Er muss während seiner Arbeit ständig entscheiden können:

Welche Informationen sind gerade relevant?

Welche Werkzeuge stehen zur Verfügung?

Was ist in den letzten Arbeitsschritten passiert?

Welche Unternehmensdaten braucht er jetzt?

Welche Informationen kann er wieder vergessen?

Und was darf überhaupt in das Context Window?

Genau dieses Problem beschreibt ein Begriff, der für moderne KI-Entwicklung immer wichtiger wird:

Context Engineering.

Anthropic bezeichnet Context Engineering als natürliche Weiterentwicklung von Prompt Engineering. Statt nur die Anweisungen an das Modell zu optimieren, wird der gesamte Informationszustand kuratiert, den ein Modell bei einem bestimmten Schritt erhält.

TL;DR: Das Wichtigste in Kürze

• Prompt Engineering optimiert die Anweisung. Context Engineering optimiert den gesamten Informationszustand eines Modells.
• Zum Context gehören unter anderem System Prompt, Chatverlauf, Unternehmensdaten, Tool-Beschreibungen, RAG-Ergebnisse und Agent Memory.
• Mehr Kontext ist nicht automatisch besser.
• Sehr große Context Windows können Modelle mit irrelevanten Informationen überladen.
• Gute Agenten laden Informationen deshalb möglichst just in time.
• Informationen sollten gespeichert, zusammengefasst oder verworfen werden können.
• Für produktive Unternehmens-KI wird Context Engineering zunehmend wichtiger als der „perfekte Mega-Prompt“.

Was ist Context Engineering?

Context Engineering bezeichnet die gezielte Auswahl, Strukturierung und Pflege aller Informationen, die einem Sprachmodell während eines Verarbeitungsschritts zur Verfügung stehen.

Zum Context gehören nicht nur Prompts.

Sondern beispielsweise:

System Instructions
       ↓
Aktuelle Nutzeranfrage
       ↓
Bisherige Unterhaltung
       ↓
Relevante Unternehmensdaten
       ↓
Verfügbare Tools
       ↓
Ergebnisse vorheriger Tool Calls
       ↓
Agent Memory
       ↓
────────────────────────
      LLM / Agent

Anthropic definiert den Begriff entsprechend als Strategien zur Kuratierung und Aufrechterhaltung eines möglichst geeigneten Token-Sets während der Inferenz – also inklusive Informationen, die außerhalb des eigentlichen Prompts in den Modellkontext gelangen.

Das klingt theoretisch.

In realen Agentenprojekten ist es extrem praktisch.

Prompt Engineering vs. Context Engineering: Was ist der Unterschied?

Prompt Engineering beantwortet die Frage „Welche Anweisung geben wir dem Modell?“. Context Engineering beantwortet zusätzlich „Welche Informationen bekommt das Modell genau jetzt, um diese Anweisung erfüllen zu können?“.

Prompt Engineering ist also Teil des Context Engineering.

Nicht dessen Alternative.

Warum kann man nicht einfach alles in den Prompt packen?

Theoretisch klingt die Lösung sehr einfach.

Wenn ein Modell Kontext braucht:

Geben wir ihm einfach alles.

Komplette Produktdokumentation.

Alle bisherigen Nachrichten.

CRM-Daten.

30 Tool-Beschreibungen.

Interne Richtlinien.

Die letzten 200 Agentenschritte.

Dann kann es sich aussuchen, was relevant ist.

Problem gelöst.

Leider nicht.

Mehr Context ist nicht automatisch besser

Große Context Windows erhöhen die Menge verfügbarer Informationen, aber irrelevanter Context kann Aufmerksamkeit, Geschwindigkeit und Kosten verschlechtern.

Anthropic verweist bei diesem Problem unter anderem auf das als Context Rot bezeichnete Verhalten: Mit wachsender Kontextmenge kann die Fähigkeit von Modellen abnehmen, relevante Informationen zuverlässig aus dem gesamten Kontext herauszuziehen.

Man kann sich das ungefähr vorstellen wie einen Menschen.

Frage an Mitarbeiter A:

„Was ist der aktuelle Preis von Produkt X? Hier ist die relevante Preisliste.“

Einfach.

Jetzt:

„Was ist der aktuelle Preis von Produkt X? Hier sind sämtliche E-Mails der letzten drei Jahre, das komplette ERP-Handbuch, 1.200 Produktseiten und alle Preislisten seit 2018.“

Die Antwort ist irgendwo darin enthalten.

Die Aufgabe ist trotzdem nicht einfacher geworden.

Kontext besitzt ein Aufmerksamkeitsbudget

Anthropic verwendet dafür ein hilfreiches Konzept:

Ein Sprachmodell besitzt gewissermaßen ein begrenztes Attention Budget.

Jede zusätzliche Information konkurriert mit den anderen Informationen um Aufmerksamkeit.

Deshalb lautet eine der wichtigsten Regeln des Context Engineering:

Gib dem Modell nicht möglichst viel Information. Gib ihm möglichst viel relevante Information.

Das ist ein fundamentaler Unterschied.

Beispiel: Ein KI-Agent für Kundenservice

Ein Kunde schreibt:

„Ich möchte meine Lieferadresse für Bestellung 28471 ändern.“

Was muss der Agent wissen?

Vielleicht:

• Identität des Kunden
• Bestellung 28471
• aktueller Versandstatus
• Regeln für Adressänderungen
• Tool update_shipping_address

Was benötigt er wahrscheinlich nicht?

• sämtliche 73 vergangenen Bestellungen
• komplette Produktdokumentation
• gesamte interne Unternehmensrichtlinie
• alle CRM-Notizen
• Marketingkampagnen des Kunden
• Tools für Rechnungsstorno
• Tools für Benutzerverwaltung

Ein gutes Agentensystem stellt deshalb nicht das gesamte Unternehmen in den Context.

Es stellt die richtigen Informationen im richtigen Moment bereit.

Die sechs wichtigsten Context-Bausteine

1. System Instructions

Der stabile Kern.

Beispielsweise:

• Rolle des Agenten
• grundsätzliche Regeln
• Sicherheitsgrenzen
• Eskalationslogik
• gewünschtes Verhalten

Diese Instruktionen sollten klar und möglichst kompakt sein.

Ein 25-seitiger System Prompt ist nicht automatisch besser als ein präziser dreiseitiger.

2. Aktueller User Context

Nicht jeder Nutzer darf dasselbe sehen.

Context kann beispielsweise enthalten:

{
  "user_id": "usr_184",
  "role": "sales",
  "language": "de",
  "customer_account": "c_9281"
}

Damit kann der Agent sein Verhalten anpassen.

Wichtig:

Der Context beschreibt Berechtigungen nicht nur sprachlich.

Die tatsächlichen APIs müssen sie weiterhin technisch durchsetzen.

3. Conversation Context

Ein Agent muss teilweise wissen, was vorher gesagt wurde.

Aber muss er wirklich jede Nachricht der letzten 400 Turns erneut bekommen?

Nicht zwangsläufig.

Stattdessen kann das System ältere Interaktionen verdichten.

Beispiel:

Statt 30 Nachrichten:

„Der Nutzer plant eine Migration von System A zu B. Budgetrahmen X. API Y ist bereits vorhanden. Datenschutzprüfung noch offen.“

Diese Kompression reduziert Context.

4. Retrieved Context

Hier kommen RAG und Suche ins Spiel.

Statt sämtliche Dokumente immer mitzuliefern, sucht das System bei Bedarf nach relevanten Informationen.

Frage:

„Wie lange beträgt die Garantie für Produkt A17?“

Retrieval liefert genau die relevanten Abschnitte.

Das ist Context Engineering.

RAG ist also nicht das gesamte Konzept.

RAG ist eine Möglichkeit, Context dynamisch bereitzustellen.

5. Tool Context

Auch Tools benötigen Aufmerksamkeit.

Angenommen, ein Agent erhält gleichzeitig 120 Funktionen.

Darunter:

search_customer

create_invoice

cancel_invoice

update_invoice

export_invoice

find_employee

delete_employee

search_inventory

…

Selbst wenn alles sauber beschrieben ist, wird die Tool-Auswahl schwieriger.

Ein sinnvoller Ansatz kann sein:

Schritt 1

Agent erkennt:

Das ist ein Supportfall.

Schritt 2

Jetzt werden nur Support-Tools aktiviert.

Das reduziert Komplexität und potenziellen Blast Radius gleichzeitig.

6. Working Memory

Bei längeren Agentenaufgaben entsteht ein temporärer Arbeitszustand.

Zum Beispiel:

Ziel:
Angebot für Kunde Müller vorbereiten.

Bereits erledigt:
✓ Kunde identifiziert
✓ vorheriges Angebot gefunden
✓ aktuelle Preise geladen

Offen:
- Lieferzeit bestätigen
- neues Angebot erzeugen

Der Agent benötigt nicht zwangsläufig sämtliche Rohdaten der vorherigen Tool Calls.

Häufig reicht dieser verdichtete Zustand.

Was ist Agent Memory?

Agent Memory bezeichnet Informationen, die außerhalb des unmittelbaren Context Windows gespeichert und bei späteren Schritten oder Sitzungen wieder abgerufen werden können.

Dabei lohnt sich eine Unterscheidung.

Kurzzeitgedächtnis

Informationen innerhalb eines laufenden Vorgangs.

Langzeitgedächtnis

Informationen, die später wieder relevant werden.

Zum Beispiel:

Kunde bevorzugt Kommunikation auf Englisch.

Oder:

Bei diesem Projekt wurde Architekturentscheidung B gewählt.

Problematisch wird Memory, wenn einfach alles gespeichert wird.

Ein System benötigt Regeln:

• Was ist dauerhaft relevant?
• Wie lange?
• Für wen?
• Kann die Information veraltet sein?
• Kann sie vom Nutzer geändert werden?
• Darf sie überhaupt gespeichert werden?

Memory ist damit nicht nur eine technische Funktion.

Es ist auch ein Datenmodell.

Ein häufiger Fehler: Tool-Ergebnisse sammeln sich endlos an

Angenommen, ein Agent untersucht einen Fehler.

Tool 1 liefert 5.000 Zeichen Logs.

Tool 2 liefert 10.000.

Tool 3 weitere 8.000.

Dann führt der Agent zehn weitere Schritte aus.

Wenn jeder Tool Output dauerhaft im kompletten Context verbleibt, wächst das System immer weiter.

Dabei ist möglicherweise nur eine Information relevant:

Fehlerursache: abgelaufenes API-Token.

Ein guter Agent kann deshalb Resultate verdichten.

Aus:

25.000 Tokens Rohdaten

werden vielleicht:

API authentication failed.
Root cause: token expired at 08:14 UTC.
Affected endpoint: /v2/orders.

Der Rest muss nicht zwangsläufig weitergetragen werden.

Context Compaction: Das Gedächtnis aufräumen

Context Compaction bedeutet, ältere oder umfangreiche Agenteninformationen zu einer kleineren, weiterhin handlungsfähigen Repräsentation zusammenzufassen.

Das ist besonders bei lang laufenden Agenten wichtig.

Vereinfacht:

Turns 1–30
   ↓
Zusammenfassung
   ↓
Turns 31–50
   ↓
Zusammenfassung + aktueller Zustand
   ↓
Turns 51...

Damit lässt sich eine Aufgabe deutlich länger fortführen, ohne permanent den vollständigen Verlauf mitzuschleppen.

Context sollte „Just in Time“ geladen werden

Das ist aus unserer Sicht eines der stärksten Architekturprinzipien.

Nicht:

Alles, was der Agent jemals brauchen könnte, sofort hinein.

Sondern:

Was benötigt er für den nächsten sinnvollen Schritt?

Beispiel Angebotsagent:

Schritt 1

Kundenanfrage verstehen.

Context:

E-Mail.

Schritt 2

Kunden identifizieren.

Context:

Extrahierte Kundendaten + CRM Search Tool.

Schritt 3

Altes Angebot prüfen.

Context:

relevanter CRM-Datensatz + Angebotsdaten.

Schritt 4

Aktuelle Preise.

Context:

nur betroffene Produkt-IDs + Pricing Tool.

Der Context verändert sich mit der Aufgabe.

Genau das ist Context Engineering.

Warum verbessert das auch die Sicherheit?

Weniger Context bedeutet häufig:

weniger unnötiger Datenzugriff.

Ein Agent für eine Lieferzeitanfrage muss nicht automatisch komplette Kundenakten erhalten.

Ein Vertriebsagent benötigt keine Personalinformationen.

Ein Supportagent braucht keine Buchhaltungsadministration.

Das Prinzip:

„Nur relevante Informationen laden“

passt damit hervorragend zu:

Least Privilege.

Context Engineering ist deshalb nicht ausschließlich Performance-Optimierung.

Es kann auch Teil einer guten Datenschutz- und Sicherheitsarchitektur sein.

Warum verbessert Context Engineering die Kosten?

Tokens kosten Geld.

Ein überladener Context wird bei vielen Modellaufrufen immer wieder übertragen.

Angenommen:

Agent führt 15 Schritte aus.

Jeder Schritt enthält 100.000 Tokens unnötigen Verlauf.

Dann entstehen bei jedem Schritt erneut große Inputmengen.

Wenn dieselbe Aufgabe mit 15.000 relevanten Tokens funktioniert, sinken:

• Kosten
• Latenz
• Komplexität

gleichzeitig.

Der billigste Token ist immer noch der, der gar nicht erst gesendet werden musste.

Wie viel Context ist optimal?

Es gibt keine universelle Tokenzahl. Optimal ist der kleinste Context, der alle Informationen enthält, die das Modell für die aktuelle Entscheidung zuverlässig benötigt.

Deshalb braucht man Tests.

Zum Beispiel:

Variante A

Komplette Wissensbasis.

Variante B

Top 20 Retrieval-Ergebnisse.

Variante C

Top 5 + Metadaten.

Dann messen:

• fachliche Qualität
• Halluzinationen
• Tool-Auswahl
• Kosten
• Latenz

Vielleicht gewinnt Variante C.

Vielleicht nicht.

Context Engineering ist keine rein intuitive Disziplin.

Sie lässt sich evaluieren.

Praktisches Beispiel: Angebotsagent

Nehmen wir folgenden Auftrag:

„Erstelle für Meyer GmbH ein neues Angebot auf Basis des Angebots vom März, aber mit 50 statt 30 Einheiten.“

Schlechte Architektur

Der Agent erhält:

• kompletten CRM-Export des Kunden
• alle 80 bisherigen Angebote
• komplette Produktdatenbank
• sämtliche Preisregeln
• alle 40 verfügbaren Tools
• gesamten Chatverlauf

Dann:

„Mach mal.“

Kann funktionieren.

Bessere Architektur

Schritt 1 – Intent

Erkennen:

create_quote_from_previous

Schritt 2 – Kunde

CRM-Suche liefert:

customer_id: 4711

Schritt 3 – Referenzangebot

Tool sucht Angebote vom März.

Nur drei Treffer kommen zurück.

Schritt 4 – Nutzer/Agent wählt relevantes Angebot

Daten werden geladen.

Schritt 5 – Positionen

Nur betroffene Produktdaten werden ergänzt.

Schritt 6 – Preislogik

Backend berechnet Preise deterministisch.

Schritt 7 – KI

Formuliert Angebotstext beziehungsweise Zusammenfassung.

Das Modell besitzt bei jedem Schritt genau den Context, den es benötigt.

Das ist weniger „magisch“.

Aber erheblich kontrollierbarer.

Prompt Engineering bleibt trotzdem wichtig

Context Engineering bedeutet nicht:

Prompts sind egal.

Ein schlechter System Prompt bleibt schlecht.

Unklare Tool-Beschreibungen bleiben problematisch.

Eine widersprüchliche Aufgabe bleibt widersprüchlich.

Die Prioritäten verschieben sich lediglich.

Bei einfachen LLM-Features kann das größte Problem tatsächlich der Prompt sein.

Bei komplexen Agenten lautet die schwierigere Frage häufig:

Was weiß das Modell gerade – und warum?

Welp-IT-Einschätzung: Das beste LLM löst keine schlechte Context-Architektur

Bei KI-Projekten wird sehr viel Energie in die Modellwahl gesteckt.

Welches Modell hat den besten Benchmark?

Welches reasoning model?

Welcher Provider?

Das ist relevant.

Aber bei Unternehmensagenten entsteht ein großer Teil der Qualität außerhalb des Modells.

Zum Beispiel:

• Wie werden Daten ausgewählt?
• Wie aktuell sind sie?
• Wie werden Tools beschrieben?
• Welche Tools stehen wann zur Verfügung?
• Welche Informationen werden gespeichert?
• Welche werden komprimiert?
• Welche Berechtigungen gelten?
• Wann wird neu recherchiert?

Genau deshalb ist professionelle KI-Entwicklung zunehmend klassische Softwarearchitektur plus LLM-spezifische Komponenten.

Der Prompt ist ein Baustein.

Nicht das System.

Eine Context-Engineering-Checkliste

Vor dem Produktiveinsatz eines Agenten würden wir mindestens diese Fragen beantworten:

Instructions

• Sind die zentralen Regeln klar?
• Gibt es Widersprüche?

Data

• Welche Daten braucht der Agent tatsächlich?
• Sind sie aktuell?
• Darf der Nutzer sie sehen?

Retrieval

• Wann wird gesucht?
• Wie viele Ergebnisse werden geladen?
• Wie werden Quellen priorisiert?

Tools

• Sind nur relevante Tools verfügbar?
• Sind Tool-Beschreibungen eindeutig?
• Werden Rechte backendseitig geprüft?

Memory

• Was wird gespeichert?
• Wann wird es vergessen?
• Kann Information veralten?

Long-running tasks

• Wann wird Context zusammengefasst?
• Welche Zwischenergebnisse müssen dauerhaft bleiben?

Evaluation

• Hat mehr Context tatsächlich bessere Ergebnisse geliefert?

Wenn die letzte Frage nie getestet wurde, lautet die Antwort erstaunlich häufig nur:

„Wir dachten halt, mehr wäre besser.“

FAQ zu Context Engineering

Ist Context Engineering dasselbe wie RAG?

Nein. RAG ist eine Technik innerhalb von Context Engineering. Context Engineering umfasst zusätzlich Prompts, Tools, Memory, Conversation State und weitere Informationen, die dem Modell zur Verfügung stehen.

Braucht man Context Engineering nur für KI-Agenten?

Nein. Auch einfache LLM-Anwendungen profitieren davon. Besonders wichtig wird es allerdings bei Agenten, weil diese über viele Schritte hinweg Informationen erzeugen, Tools verwenden und ihren Arbeitszustand verändern.

Ist ein größeres Context Window immer besser?

Nein. Ein größeres Context Window schafft mehr Kapazität, garantiert aber nicht, dass jede Information darin gleich zuverlässig berücksichtigt wird. Relevanz und Struktur bleiben entscheidend. Anthropic verweist in diesem Zusammenhang auf abnehmende Retrieval-Leistung bei zunehmender Kontextmenge.

Was ist wichtiger: Prompt Engineering oder Context Engineering?

Für einfache Einzelschritt-Aufgaben kann Prompt Engineering dominieren. Bei komplexen Agenten ist der gesamte Context häufig mindestens ebenso wichtig. Prompt Engineering bleibt ein Teil einer größeren Context-Strategie.

Fazit: Der beste Prompt kennt nicht automatisch die richtigen Informationen

Die erste Generation von LLM-Anwendungen fragte:

„Was sollen wir dem Modell sagen?“

Die nächste Generation muss zusätzlich fragen:

„Was soll das Modell in diesem Moment wissen?“

Das ist Context Engineering.

Nicht möglichst viele Tokens.

Nicht möglichst große Prompts.

Nicht jedes Unternehmensdokument auf einmal.

Sondern:

die richtige Anweisung,

mit den richtigen Daten,

den richtigen Tools,

dem richtigen Arbeitszustand,

im richtigen Moment.

Und genau diese scheinbar unspektakuläre Arbeit entscheidet häufig darüber, ob ein KI-Agent nur beeindruckend wirkt – oder tatsächlich zuverlässig arbeitet.

Sie möchten einen KI-Agenten bauen, der Ihre echten Unternehmensdaten und Systeme nutzen kann?

Welp-IT entwickelt individuelle KI-Agenten, KI-Automatisierungen und KI-Integrationen – inklusive APIs, RAG, Tool-Calling, Berechtigungslogik und der zugrunde liegenden Softwarearchitektur.

→ KI-Entwicklung mit Welp-IT: https://www.welpit.de/ki-entwicklung

Technische Quelle: Anthropic Engineering, Effective context engineering for AI agents. Anthropic beschreibt Context Engineering als die gezielte Kuratierung des gesamten Modellkontexts und weist insbesondere auf die begrenzte Aufmerksamkeit bei zunehmender Kontextmenge hin.