Context Engineering: Die Schicht zwischen Prompts und verlaesslichen AI-Produkten
Context Engineering ist die praktische Arbeit, Informationen, Zustand, Tools, Grenzen und Tests so zu gestalten, dass ein AI-Workflow nachvollziehbar handeln kann.
Zuletzt aktualisiert am
Context Engineering ist die praktische Arbeit, die Informationen zu waehlen, zu ordnen und zu testen, die ein AI-System vor einer Antwort oder Aktion erhaelt. Ein Prompt ist nur ein Teil dieser Umgebung. Ebenso wichtig sind Dokumente, Nutzerzustand, Memory, Retrieval, Tool-Zugriff, Berechtigungen, Ausgabeformate, Schutzregeln und die Frage, wie das Team ein Ergebnis bewertet.
Der Begriff ist nuetzlich, weil viele Fehler in AI-Produkten keine reinen Modellfehler sind. Ein Modell kann faehig sein, bekommt aber den falschen Vertragstext, kennt den aktuellen Account-Status nicht, zieht eine veraltete Richtlinie, vergisst eine Entscheidung aus dem vorherigen Schritt oder ruft ein Tool ohne ausreichenden Kontext auf. Ein besser formulierter Prompt kann Ton und Struktur verbessern. Er kann keine fehlende betriebliche Information erfinden.
Fuer Teams, die AI nur als einmaliges Chatfenster einsetzen, wirkt das Thema abstrakt. Sobald ein System jedoch Support beantwortet, Repositorys analysiert, Kundendaten verarbeitet oder in mehreren Schritten plant, wird Context Engineering Produktinfrastruktur. Die Hinweise in diesem Artikel wurden am 12. Juli 2026 geprueft.
Ein konkreter Fehler: eine Rueckerstattung ohne Kontext
Nehmen wir einen Support Assistant. Der Prompt lautet: “Beantworte die Frage des Kunden zur Rueckerstattung gemaess unserer Richtlinie.” Das klingt vernuenftig, ist aber kein belastbarer Ablauf.
| Was der Assistant braucht | Warum es fuer die Antwort wichtig ist |
|---|---|
| Aktuelle Rueckerstattungsrichtlinie | Alte Versionen koennen andere Fristen oder Ausnahmen enthalten |
| Kaufdatum, Plan und Region | Anspruch und Steuer- oder Vertragsbedingungen koennen abweichen |
| Bisheriger Support-Verlauf | Eine fruehere Zusage oder Eskalation darf nicht verloren gehen |
| Eskalationsregel | Manche Faelle brauchen menschliche Pruefung statt einer automatischen Zusage |
| Sprach- und Tonvorgaben | Eine rechtlich relevante Aussage darf nicht frei umformuliert werden |
| Zitatfaehige Quelle | Kunde und Mitarbeiter muessen die Regel nachpruefen koennen |
Fehlt einer dieser Punkte oder ist er veraltet, kann die Antwort freundlich und sehr selbstsicher sein, aber trotzdem falsch. Context Engineering fragt daher zuerst: Welche Information durfte das System sehen, welche Information haette es sehen muessen, und welche Information durfte nicht als Steueranweisung gelten?
Die vier Arbeitsfelder
| Feld | Leitfrage | Typisches Artefakt |
|---|---|---|
| Quellenwahl | Welche Information soll das System sehen? | Retriever, Dokumentenindex, Datenbankabfrage, File Picker |
| Zustandsverwaltung | Was muss ueber mehrere Schritte erhalten bleiben? | Ziel des Nutzers, Freigabe, Session-Historie, Berechtigung |
| Instruktionsdesign | Wie soll das Modell Quellen und Regeln verwenden? | Systeminstruktion, Task Contract, Ausgabeformat |
| Evaluation | Hat besserer Kontext die Aufgabe wirklich verbessert? | Testfaelle, Traces, Review-Scores, Regression Checks |
Diese Ebenen greifen ineinander. Retrieval ohne klare Aufgabe kann viel irrelevanten Text liefern. Eine gute Instruktion ohne aktuellen Zustand bleibt unvollstaendig. Ein Tool mit Zugriff auf den richtigen Datensatz kann trotzdem falsch handeln, wenn sein Scope zu gross ist. Und ohne Tests merkt das Team nicht, ob eine neue Quelle den allgemeinen Workflow verbessert oder nur eine Demo.
Abgrenzung zu verwandten Begriffen
| Begriff | Schwerpunkt | Rolle im Gesamtbild |
|---|---|---|
| Prompt Engineering | Formulierung von Instruktionen | Ein Baustein von Context Engineering |
| RAG | Externe Information zum Zeitpunkt der Aufgabe holen | Eine Strategie der Quellenwahl |
| Agent Workflow | Mehrere Schritte planen und ausfuehren | Braucht Kontext, Zustand, Tools und Evaluation |
| MCP | Standardisierte Verbindung zu Tools und Daten | Kann Zugriff portabler machen, ersetzt aber keine Auswahlentscheidung |
| Memory | Informationen ueber Interaktionen halten | Teil der Zustandsverwaltung |
| Observability | Traces, Inputs und Outputs sichtbar machen | Grundlage, um Kontextfehler zu finden |
Die Abgrenzung ist auch kommerziell relevant. “Bessere Prompts” ist ein enger Bedarf. Teams bezahlen eher fuer die Moeglichkeit, Fehler zu debuggen: Welcher Kontext wurde verwendet? Welcher haette dabei sein muessen? Hat das Modell eine Regel ignoriert oder die Regel nie erhalten? Welcher Tool-Call aenderte die Antwort?
Ein Debugging-Workflow statt einer “Context Platform”
Ein erstes Produkt oder internes Tool muss nicht jede Form von Memory und RAG loesen. Es kann mit einer nachvollziehbaren Trace beginnen.
| Schritt | Was festhalten | Nutzen |
|---|---|---|
| Aufgabe | Nutzerfrage, Erfolgskriterium, Risikostufe | Macht klar, was der Lauf leisten sollte |
| Eingaben | Verwendete Dokumente, Felder, Versionen und Herkunft | Zeigt fehlende oder veraltete Quellen |
| Retrieval | Kandidaten, Auswahlgrund und nicht verwendete Alternativen | Zeigt Rauschen und falsche Treffer |
| Zustand | Vorherige Entscheidung, Rolle, Berechtigung, Region | Verhindert, dass der Lauf Kontext erfindet |
| Tools | Toolname, Parameter, Ergebnis und Freigabe | Macht Aktionen pruefbar |
| Ausgabe | Struktur, Quellen, Unsicherheit und Eskalation | Hilft Menschen, Resultate zu kontrollieren |
| Test | Gleiche Aufgabe vor und nach einer Aenderung | Trennt Verbesserung von Zufall |
Ein DACH-Produktteam kann diesen Ablauf bei einem Coding Assistant anwenden. Wenn der Agent eine falsche Konfiguration vorschlaegt, sollte die Frage nicht nur “war der Prompt schlecht?” sein. Vielleicht lag die aktuelle Version der Dokumentation nicht im Kontext, ein altes README wurde bevorzugt, die Repository-Richtlinie fehlte oder der Agent durfte einen externen Befehl vorschlagen, ohne den Deployment-Status zu kennen.
Lokale Arbeitsszenarien
Context Engineering wird glaubwuerdig, wenn das Beispiel eine echte Arbeitsgrenze zeigt.
| Team | Aufgabe | Kontext, der fehlen kann | Sichere erste Verbesserung |
|---|---|---|---|
| Deutscher B2B-Support | Sicherheitsfragebogen vorbereiten | Freigegebene Aussagen, Vertragsausnahmen, Sprache des Kunden | Quellenpflichtige Antwortentwuerfe mit menschlicher Freigabe |
| Entwicklerteam | Setup-Fehler in einem Repository finden | Branch, Laufzeitversion, interne Build-Hinweise | Read-only Trace mit verwendeten Dateien und Unsicherheiten |
| Ecommerce-Team | Produktbeschreibung fuer einen Markt anpassen | Zulässige Claims, Katalogdaten, Versandregion | Strukturierter Entwurf mit Claim-Flags statt automatischem Publish |
| HR- oder Enablement-Team | Lernmaterial zusammenfassen | Zielrolle, aktuelle Richtlinie, sensible Daten | Zugelassene Quellen und keine dauerhafte Speicherung privater Notizen |
Im deutschen B2B-Kontext kommt oft eine deutsche Kauf- und Datenschutzsprache neben englischen technischen Docs hinzu. Ein guter Workflow sagt daher nicht nur “lies alle Dokumente”. Er trennt: Welche deutsche Seite ist fuer Sales und Procurement verbindlich? Welche englische Quelle ist technisch aktuell? Welche Aussage darf das System ohne menschliche Pruefung nicht treffen?
Fehler, die Teams sichtbar machen sollten
Zu viel Kontext
Mehr Dokumente sind nicht automatisch besser. Ein langer Kontext kann aktuelle Regeln verdecken, untrusted Text ueberbewerten oder die Aufgabe unklar machen. Messen Sie, ob eine Quelle wirklich zur Antwort beigetragen hat.
Veraltete oder widerspruechliche Quellen
Ein Retriever, der alte Preis- oder Policy-Seiten liefert, erzeugt konsistente Fehler. Version, Owner und Aktualitaet muessen fuer kritische Quellen sichtbar sein.
Tool-Rechte ohne Aufgabenrahmen
Ein Agent sollte nicht jede verfuegbare Aktion sehen. Scope, Consent und menschliche Freigabe gehoeren zum Kontext, nicht nur zur Sicherheitskonfiguration.
Keine Regressionstests
Eine Aenderung kann eine Demo verbessern und zehn andere Faelle verschlechtern. Behalten Sie einen kleinen, realistischen Testkatalog mit normalen, unvollstaendigen und adversarialen Inputs.
Ein Einstieg fuer kleine Teams
- Waehlen Sie einen wiederholbaren Ablauf mit klarer Fehlerfolge, etwa Support-Entwurf oder Dokumentationssuche.
- Protokollieren Sie einen erfolgreichen und einen fehlgeschlagenen Lauf mit Quellen, Zustand und Tool-Aufrufen.
- Markieren Sie pro Fehler nur eine wahrscheinlich fehlende oder noisy Information.
- Aendern Sie zuerst Auswahl, Version oder Freigabe - nicht sofort den gesamten Prompt.
- Wiederholen Sie dieselben Testfaelle und lassen Sie eine Fachperson die Ergebnisse bewerten.
- Erweitern Sie Memory oder Tools erst, wenn die Basis nachvollziehbar ist.
Context Engineering macht AI nicht magisch verlaesslich. Es macht die Gruende fuer Verlaesslichkeit oder Fehler sichtbar und damit bearbeitbar.