Zusammenfassung

Context Engineering und Prompt Engineering lösen unterschiedliche Probleme. Prompt Engineering ist die Praxis, bessere Anweisungen für ein Modell zu formulieren, wie z.B. die Aufgabe, Rolle, das Format und Beispiele. 

Context Engineering ist die Praxis, die Informationsumgebung zu gestalten, in der das Modell agiert: die Daten, die es abruft, den Speicher, den es verwaltet, die Tools, die es aufrufen kann, die Berechtigungen, die es einschränken, den Workflow-Status, den es verfolgt, und die Regeln, die bestimmen, was es ignorieren soll.

Prompt Engineering funktioniert weiterhin für Einzelaufgaben wie Zusammenfassen, Extrahieren, Umschreiben oder Klassifizieren. Context Engineering wird zu einer echten Disziplin, sobald ein KI-System innerhalb eines Workflows läuft oder Entscheidungen trifft, die später erklärt werden müssen.

Die Unterscheidung ist wichtig, weil ein besserer Prompt fehlenden oder unautorisierten Kontext nicht beheben kann. Für KI-Agenten ist Context Engineering die Produktionsarchitektur.

Der Prompt ist meist nicht das ganze Problem

Die meisten Teams versuchen, einen unzuverlässigen KI-Agenten zu reparieren, indem sie den Prompt umschreiben. Manchmal hilft es, aber oft nicht. Und das Team schreibt ihn erneut um, dann ein drittes Mal, überzeugt davon, dass die richtige Wortkombination nur eine Iteration entfernt ist.

Das Problem ist, was das Modell sieht, bevor es die Anweisung befolgt. Dokumentation, die vor drei Monaten geändert wurde, ein CRM-Feld, das niemand ausgefüllt hat, zwei Richtlinien, die sich widersprechen, ein Tool, das der Agent niemals hätte aufrufen dürfen, oder ein Datensatz, den der Benutzer niemals hätte sehen sollen.

Prompt Engineering verbessert die Form einer Antwort. Context Engineering ändert die Bedingungen, unter denen die Antwort erzeugt wird.

Der Unterschied ist in einer Demo leicht zu ignorieren, wo die Daten sauber sind und der Workflow nur einen Schritt lang ist. In der Produktion wird es teuer, wo die Daten unübersichtlich sind, der Workflow neun Schritte umfasst und eine falsche Antwort eine Rückerstattung oder eine E-Mail an einen Kunden auslöst.

Bevor wir uns also mit Agenten und Architektur befassen, verdient der grundlegende Vergleich eine klare Antwort.

Was ist Prompt Engineering?

Prompt Engineering ist die Praxis, Anweisungen, Beispiele, Einschränkungen und das Ausgabeformat zu gestalten, die einem Modell helfen, eine bessere Antwort zu produzieren. Es wirkt sich auf den Teil der Interaktion aus, den Sie direkt formulieren.

Ein guter Prompt steuert mehrere Dinge gleichzeitig: die Aufgabe selbst, die Rolle, die das Modell einnehmen soll, den Ton, die Ausgabestruktur, den Detaillierungsgrad, den Argumentationsstil und die Beispiele, die dem Modell zeigen, wie eine gute Antwort aussieht. Richtig angewendet, verwandelt es eine vage Anfrage in eine präzise.

Schwacher Prompt: „Fassen Sie diesen Kundenanruf zusammen.“

Besserer Prompt: „Fassen Sie diesen Kundenanruf für einen VP of Sales zusammen. Listen Sie Kaufsignale, Einwände, Erwähnungen von Wettbewerbern und Folgeaufgaben auf. Trennen Sie bestätigte Fakten von Annahmen. Verwenden Sie kurze Aufzählungspunkte.“

Die zweite Version erstellt eine nützlichere Zusammenfassung auf jedem fähigen Modell, da sie Unklarheiten bezüglich Zielgruppe, Struktur und Relevanz beseitigt.

Prompt Engineering hat seinen festen Platz in der Inhaltserstellung, Zusammenfassung, Umschreibung, Klassifizierung, strukturierten Extraktion, beim Brainstorming und den meisten internen Einzelanfragen, bei denen die benötigten Informationen bereits im Prompt enthalten sind. In diesen Fällen hat das Modell alles, was es braucht, vor sich, und die einzige verbleibende Variable ist, wie klar Sie fragen.

Doch Prompt Engineering birgt eine versteckte Annahme. Es geht davon aus, dass das Modell bereits die richtige Aufgabe, die richtigen Daten und die richtigen Grenzen vor sich hat. Diese Annahme trifft auf eine Zusammenfassung eines eingefügten Dokuments zu. Sie bricht in dem Moment, in dem das Modell innerhalb eines Workflows agieren muss, der sich während der Ausführung ändert.

Was ist Context Engineering?

Context Engineering ist das Design der Informationsumgebung um ein Modell herum. Es entscheidet, was das Modell sehen, abrufen, speichern, ignorieren, verwenden und worauf es reagieren kann, während es an einer Aufgabe arbeitet.

Wo Prompt Engineering die Anweisung schreibt, stellt Context Engineering alles andere zusammen, was das Modell erreicht. Dazu gehören Systemanweisungen, API-Antworten, die Rolle und Berechtigungen des Benutzers, Compliance-Einschränkungen usw.

Context Engineering ist der Begriff, den das Engineering-Team von Anthropic für das verwendet, was es als die natürliche Weiterentwicklung des Prompt Engineering bezeichnet, und die Definition ist bewusst eng gefasst. Context Engineering ist die Menge von Strategien zur Kuratierung der richtigen Tokens im Fenster des Modells während der Inferenz, einschließlich allem, was außerhalb des Prompts selbst dort landet. Das Modell schließt nicht über Ihre Datenbank oder Ihr CRM. Es schließt über alles, was es ins Fenster geschafft hat. Context Engineering steuert dieses Fenster.

Ein konkreter Fall macht die Lücke offensichtlich. Stellen Sie sich einen Support-Copiloten vor, der eine Abrechnungsfrage beantwortet. Ein perfekt geschriebener Prompt kann diese nicht beantworten. Der Copilot benötigt den Plan des Kunden, dessen Vertragsbedingungen, die Rechnungshistorie, die aktuellen Preise, die Support-Stufe, die Region, die Rückerstattungsrichtlinien und die Grenze, die entscheidet, welche dieser Informationen er preisgeben darf. Ist dieser Kontext falsch, ist die Ausgabe falsch, egal wie elegant die Anweisung ist. Ist er richtig, liefert selbst ein mittelmäßiger Prompt noch eine brauchbare Antwort.

Es gibt einen Grund, warum diese Disziplin jetzt und nicht schon vor drei Jahren aufkam. Frühe LLM-Arbeiten bestanden hauptsächlich aus Prompting, da die meisten Anwendungsfälle einmalig waren, wie z.B. "klassifiziere dies", "schreibe das um", "generiere dies". Agenten veränderten die Form des Problems. Ein Agent läuft in einer Schleife, zieht bei jedem Schritt Informationen herein, ruft Tools auf und akkumuliert Zustände. Bei Schritt vierzehn ist der Kontext das Ergebnis von dreizehn früheren Schritten, die fast alles in das Fenster hätten ziehen können. Niemand schreibt diesen Kontext von Hand. Er muss als System konzipiert werden, und genau das ist Context Engineering.

Context Engineering vs. Prompt Engineering: Der vollständige Vergleich

Der Unterschied ist am einfachsten zu erkennen, wenn man sie nebeneinanderlegt. Jede Disziplin steuert eine andere Ebene desselben Systems.

Die Tabelle ist weniger ein Vergleich von Gegenspielern als vielmehr eine Karte, welches Problem Sie tatsächlich lösen, wenn ein Agent sich falsch verhält.

Ersetzt Context Engineering das Prompt Engineering?

Nein. Context Engineering ersetzt das Prompt Engineering nicht. Es integriert es in eine größere Disziplin.

Prompt Engineering ist immer noch wichtig, weil das Modell klare Anweisungen benötigt. Aber in einem Produktionssystem ist der Prompt eine von mehreren Schichten, und es ist nicht die Schicht, die am häufigsten versagt. Das System benötigt auch Kontextauswahl, Abruf, Speicher, Tool-Steuerung, Berechtigungen, Evaluierung und Beobachtbarkeit. Jedes davon ist ein separates Anliegen mit einem eigenen Fehlermodus.

Es hilft, die Ebenen explizit zu betrachten:

• Prompt Engineering ist die Anweisungsebene.
• RAG ist die Retrieval-Ebene.
• Speicher ist die Kontinuitätsebene.
• Tool-Nutzung ist die Aktionsebene.
• Berechtigungen sind die Zugriffsebene.
• Evaluierung ist die Qualitätsebene.
• Observability ist die Überwachungsebene.
• Context Engineering ist das System, das all diese koordiniert.

Liest man diese Liste, so wirkt die Beziehung nicht mehr wie eine Abfolge, sondern wie eine Einschließung. Prompt Engineering wurde nicht ersetzt. Es wurde von „der Aufgabe“ zu „einer Ebene der Aufgabe“ herabgestuft, was der normale Lebenszyklus jeder Fähigkeit ist, die zu einer Ingenieurdisziplin heranreift.

Das Muster ist bekannt. Frühe Web-Arbeiten betrachteten Design als eine ungeteilte Fähigkeit, dann reifte das Feld und spaltete sich in UI und UX auf: verwandt, aber eigenständig, jede mit ihren eigenen Werkzeugen und Verantwortlichen. KI durchläuft jetzt dieselbe Trennung. Prompting war die gesamte Aufgabe, als die gesamte Aufgabe darin bestand, eine Frage zu beantworten. Es ist jetzt eine Spezialität, da die Aufgabe darin besteht, ein System zu betreiben.

Ein besserer Prompt kann eine Antwort verbessern. Er kann nicht entscheiden, welche Kundendaten der Agent sehen darf, welche Richtlinie aktuell ist oder ob der Agent die Abrechnungs-API aufrufen soll.

Deshalb ändert sich der Vergleich auch komplett, wenn man von einem Chatbot zu einem Agenten wechselt. Ein Chatbot antwortet. Ein Agent handelt. Sobald ein Modell handeln kann, wird jede andere Ebene zu einem Ort, an dem eine falsche Aktion entstehen kann, und der Prompt ist nicht mehr der Ort, an dem das meiste Risiko liegt.

Wann Prompt Engineering ausreicht

Prompt Engineering ist ausreichend, wenn die Aufgabe in sich abgeschlossen, risikoarm ist und nicht von Kontext abhängt, der sich ändert, während das Modell arbeitet. Wenn alles, was das Modell benötigt, bereits im Prompt enthalten ist und eine falsche Antwort leicht zu erkennen und abzulehnen ist, benötigen Sie keine Architektur. Sie benötigen gute Anweisungen.

Der gemeinsame Nenner ist, dass nichts außerhalb des Prompts wahr sein muss, damit die Aufgabe erfolgreich ist. Das Modell greift nicht auf eine Datenbank zu, wählt kein Werkzeug aus, erinnert sich nicht an einen vorherigen Schritt oder handelt im Namen eines bestimmten Benutzers mit spezifischen Berechtigungen.

Eine kurze Checkliste fasst es zusammen. Prompt Engineering ist in der Regel ausreichend, wenn:

• Das Modell keine Live-Geschäftsdaten benötigt.
• Keine Tools aufgerufen werden.
• Kein Speicher erforderlich ist;
• Es gelten keine benutzerspezifischen Berechtigungen.
• Die Aufgabe ist in ein oder zwei Durchläufen erledigt.
• Ein Mensch kann Fehler leicht erkennen.
• Die Ausgabe löst keine operativen, finanziellen, rechtlichen oder kundenbezogenen Maßnahmen aus.

Wenn all dies zutrifft, investieren Sie in den Prompt und belassen Sie es dabei. Das Hinzufügen von Retrieval, Speicher und einem Evaluierungs-Framework zu einer Aufgabe, die ein eingefügtes Dokument zusammenfasst, ist Over-Engineering, und Over-Engineering ist eine eigene Art des Scheiterns. Reife bedeutet zu wissen, welches Problem man hat.

Sobald eine dieser Bedingungen entfällt, hört Prompt Engineering auf, die Hauptdisziplin zu sein. Meistens fallen sie gleichzeitig weg.

Wann Kontext-Engineering notwendig wird

Kontext-Engineering wird notwendig, sobald das Modell in einem echten Geschäftsworkflow agieren muss. Der Übergang ist nicht schleichend. Eines Tages fasst der Agent Texte zusammen; am nächsten Tag liest er Live-Daten, wählt Tools aus und überträgt den Zustand über mehrere Schritte hinweg, und die Disziplin, die seine Zuverlässigkeit regelt, ändert sich grundlegend.

Jede Zeile zeigt einen Fall, in dem ein perfekt geschriebener Prompt für das Ergebnis irrelevant ist. Ein Vertriebsmitarbeiter, der mit veralteten Preisen arbeitet, liegt bei der Zahl selbstbewusst falsch, und keine Anweisung korrigiert eine Zahl, die das Modell nie hatte. Ein HealthTech-Assistent, der den falschen Patientenkontext abruft, ist gefährlich, egal wie sorgfältig man ihn zur Vorsicht angewiesen hat. 

Beachten Sie das Muster dieser Fehler. Die Ausgabe ist nicht fehlerhaft formatiert. Sie ist gut geschrieben und falsch. Das ist das Kennzeichen eines Kontextproblems. Prompt-Fehler äußern sich in schlechter Formatierung und vagen Antworten. Kontextfehler hingegen äußern sich in selbstbewussten, plausiblen Antworten, die auf falschen Eingaben basieren, was die teurere Art ist, da sie die Überprüfung übersteht.

Hier kehrt sich auch die Kostenstruktur um. Bei einer Aufgabe mit einem einzigen Durchlauf kostet eine falsche Antwort eine abgelehnte Ausgabe. In einem mehrstufigen Workflow pflanzt sich eine falsche Eingabe in Schritt zwei durch jeden späteren Schritt fort, und der Agent verbringt den Rest des Durchlaufs damit, sorgfältig von einer falschen Prämisse aus zu argumentieren. Je besser das Modell, desto überzeugender verteidigt es den Fehler.

Warum KI-Agenten versagen, wenn Kontext wie ein Prompt behandelt wird

Dies ist die Behauptung, auf der der Rest dieses Artikels basiert: Die meisten Fehler von KI-Agenten sind Kontextfehler im Gewand eines Prompt-Fehlers. Das Team sieht eine schlechte Ausgabe, geht davon aus, dass die Anweisung fehlerhaft ist, und schreibt sie neu. Die Ausgabe verbessert sich leicht, bricht dann aber beim nächsten Grenzfall wieder zusammen, weil die Anweisung nie der fehlerhafte Teil war.

Es gibt sieben häufige Wege, auf denen der Kontext versagt. Jeder hat eine andere Lösung, und das Umschreiben des Prompts behebt keinen davon.

1. Fehlender Kontext. Der Agent erhält nicht die Informationen, die er zur Erledigung der Aufgabe benötigt. Ein Vertriebsmitarbeiter entwirft Verlängerungsnachrichten ohne Vertragsbedingungen, ohne Nutzungsdaten und ohne Einblick in offene Support-Tickets. Die Anweisung war in Ordnung. Die Eingaben fehlten.

2. Veralteter Kontext. Der Agent ruft Informationen ab, die früher zutreffend waren. Ein Support-Copilot zitiert eine Rückerstattungsrichtlinie, die sich vor drei Monaten geändert hat, selbstbewusst und in der Region des Kunden, weil die alte Richtlinie noch im Index vorhanden ist.

3. Verrauschter Kontext. Zu viele irrelevante Informationen gelangen in das Fenster. Ein Engineering-Assistent erhält jede Log-Zeile der letzten Stunde anstatt der wenigen, die mit der fehlgeschlagenen Bereitstellung zusammenhängen, und das benötigte Signal ist unter Tausenden von Zeilen begraben, die es nicht benötigt.

4. Widersprüchlicher Kontext. Das Modell sieht zwei Quellen, die sich widersprechen, und hat keine Regel, welche davon Vorrang hat. Eine Preisgestaltungsseite, eine interne Tabelle und ein CRM-Datensatz zeigen drei verschiedene Unternehmenspreise. Das Modell wählt einen aus. Es kann nicht wissen, dass es falsch gewählt hat.

5. Unberechtigter Kontext. Der Agent erhält Daten, die der Benutzer niemals hätte sehen dürfen. Ein kundenorientierter Assistent kann interne Eskalationsnotizen lesen, oder schlimmer noch, Daten eines anderen Mandanten, weil die Abrufschicht nie auf den anfragenden Benutzer beschränkt war.

6. Kontext durch Werkzeugverwirrung. Der Agent hat zu viele oder sich überschneidende Werkzeuge und wählt das falsche aus. Ein Betriebsagent kann CRM-, Abrechnungs- und Supportdatensätze aktualisieren, und keine Regel definiert, welche Aktion genehmigt werden muss. Es aktualisiert die Abrechnung, obwohl es eine Notiz protokollieren sollte.

7. Unbeobachtbarer Kontext. Niemand kann überprüfen, was das Modell gesehen hat, bevor es gehandelt hat. Eine falsche Antwort wird gemeldet, und das Team kann nicht rekonstruieren, welche Dokumente, welcher Speicher, welche Werkzeugausgaben oder welcher Benutzerstatus sie geprägt haben. Der Fehler ist real, und die Ursache ist unsichtbar.

Wenn das Team den Prompt immer wieder umschreibt, während diese Probleme bestehen bleiben, poliert es den Satz und ignoriert das System. Der Satz war nie das Problem. Dies sind auch keine exotischen Randfälle. LangChain katalogisiert eine ähnliche Reihe unter Namen wie Kontextvergiftung, Ablenkung, Verwirrung und Konflikt, und das Engineering-Team bei Cognition hat Kontext-Engineering als die größte Aufgabe beim Aufbau von Agenten beschrieben. Die Terminologie variiert, aber die Diagnose bleibt dieselbe: Das Modell schließt korrekt aus falschen Eingaben, und keine Anweisung ändert die Eingaben.

Die Lösung ist eine Schicht, die bewusst entscheidet, was das Modell erreicht, bevor das Modell überhaupt Schlussfolgerungen zieht. Diese Schicht braucht einen Namen und eine Form, was der Gegenstand des restlichen Artikels ist.

Die Kontext-Kontrollebene: Ein besserer Weg, den Kontext von KI-Agenten zu gestalten

Ein KI-Agent in der Produktion benötigt eine Kontext-Kontrollebene, weil jemand entscheiden muss, was das Modell sieht, bevor es spricht, schlussfolgert, abruft oder handelt. In den meisten Teams wird diese Entscheidung zufällig getroffen, verteilt auf ein Abrufskript, einen System-Prompt und was auch immer der letzte Ingenieur angeschlossen hat.

Eine Kontext-Kontrollebene hat acht Komponenten, plus eine Frage der Verantwortlichkeit, die entscheidet, ob die anderen acht den Kontakt mit der Produktion überleben. Betrachten Sie diese Sammlung als eine Design-Checkliste für jeden Agenten, der einen realen Workflow berührt.

1. Kontextquellen

Definieren Sie, woher der Agent Informationen beziehen kann: Dokumente, Datenbanken, CRM, ERP, Produktanalysen, Tickets, Protokolle, APIs, Benutzerprofile, Richtlinien-Repositories und frühere Konversationen.

Die Disziplin hier ist Zurückhaltung. Nicht jede verfügbare Quelle sollte zu einer Agentenquelle werden. Einen Agenten mit allem zu verbinden, ist der schnellste Weg, ihn zu vergiften, denn jede zusätzliche Quelle ist ein weiterer Weg für veraltete, irrelevante oder unautorisierte Informationen, um in den Kontext zu gelangen. Entscheiden Sie, worauf der Agent zugreift, bevor Sie entscheiden, wie er darauf zugreift.

2. Kontextauswahl

Definieren Sie, was für diesen spezifischen Schritt relevant ist. Für jede gegebene Aktion muss das System vier Fragen beantworten: was der Agent gerade benötigt, was ausgeschlossen werden sollte, welche Quelle maßgeblich ist und was der minimal nützliche Kontext ist.

Der Standard sollte der kleinste ausreichende Satz sein, nicht der größte verfügbare. Bei der Auswahl wird das Aufmerksamkeitsbudget entweder sinnvoll eingesetzt oder verschwendet. Ein Agent, der genau das bekommt, was er braucht, argumentiert gut. Ein Agent, der alles bekommt, was er möglicherweise brauchen könnte, argumentiert schlechter, langsamer und mit höheren Kosten.

3. Kontextberechtigungen

Definieren Sie, worauf der Agent für diesen Benutzer, diese Rolle, diesen Mandanten, diese Region und diesen Workflow zugreifen darf. Dazu gehören rollenbasierter Zugriff, Mandantenisolierung, der Umgang mit PII und PHI, Schwärzung, Genehmigungsgrenzen und eine klare Trennung zwischen interner und externer Sichtbarkeit.

In einem Multi-Mandanten- oder regulierten System ist dies keine Funktion. Es ist die Grenze zwischen einem Produkt und einem Vorfall. Eine Aufforderung, die besagt „zeige nur Daten an, die der Benutzer sehen darf“, ist ein Wunsch. Eine Berechtigungsebene, die den Kontext filtert, bevor er das Modell erreicht, ist eine Kontrolle.

4. Kontextspeicher

Definieren Sie, was der Agent sich merken kann: Kurzzeit-Aufgabenspeicher, Langzeit-Benutzerspeicher, Kontospeicher, Workflow-Status, Ablaufregeln und die Dinge, die niemals gespeichert werden dürfen.

Der Speicher ist der Ort, an dem die Zuverlässigkeit leise erodiert. Ein Speicher, der nie bereinigt wird, wird zu einem langsamen Leck an veralteten und unsicheren Informationen, und ein Agent, der sich das Falsche merkt, ist schwerer zu debuggen als einer, der sich nichts merkt. Zu entscheiden, was der Agent vergisst, ist genauso wichtig wie zu entscheiden, was er behält.

5. Kontext-Tools

Definieren Sie, welche Tools der Agent aufrufen kann und unter welchen Bedingungen: Nur-Lese-Tools, Schreib-Tools, risikoreiche Aktionen, Genehmigungsregeln und die Validierung von Tool-Ausgaben.

Ein Test, der es wert ist, übernommen zu werden: Wenn ein menschlicher Ingenieur nicht mit Sicherheit sagen kann, welches Tool in einer bestimmten Situation zu verwenden ist, kann es der Agent auch nicht. Die Tool-Ausbreitung ist ein getarntes Kontextproblem. Jedes Tool-Schema nimmt Platz im Kontextfenster ein, und ein überladener Tool-Satz führt genau zu den im vorherigen Abschnitt beschriebenen Fehlern durch Tool-Verwirrung. Weniger, klarere Tools sind besser als viele, sich überschneidende.

6. Kontextkomprimierung

Definieren Sie, wie lange oder komplexe Informationen zusammengefasst werden, ohne das kritische Signal zu verlieren: Zusammenfassung, Chunking, Ranking, Quellenverweise und das Entfernen irrelevanter Historie.

Das Ziel ist ein Fenster mit hohem Signal-Rausch-Verhältnis, kein vollständig gefülltes. Komprimierung ermöglicht es einem Agenten, eine lange Aufgabe auszuführen, ohne dass die Leistung mit zunehmender Konversation nachlässt, und ihr Fehlen ist der Grund, warum einige Agenten schlechter werden, je länger sie laufen.

7. Kontextbewertung

Definieren Sie, wie die Kontextqualität vor und nach dem Start getestet wird, hinsichtlich Relevanz, Aktualität, Vollständigkeit, Berechtigungsübereinstimmung, Konflikterkennung, Nachvollziehbarkeit, Latenz und Kosten.

Die meisten Teams testen die Ausgabe des Modells. Wenige testen den Kontext, aus dem die Ausgabe erstellt wurde, wo der Fehler normalerweise liegt. Die Bewertung des Kontexts bedeutet nicht nur zu fragen: „War die Antwort gut?“, sondern auch: „Hatte das Modell die richtigen Informationen, in der richtigen Aktualität, die dieser Benutzer sehen durfte, und wurden Konflikte gelöst?“ Eine gute Antwort aus schlechtem Kontext ist Glück, und Glück lässt sich nicht skalieren.

8. Kontext-Observability

Definieren Sie, wie das Team überprüft, was der Agent gesehen hat und warum er sich auf eine bestimmte Weise verhalten hat: Kontextprotokolle, abgerufene Quellen, Tool-Ausgaben, Speicherzustand, Prompt-Versionen, Genehmigungsereignisse und Fehler-Traces.

Wie Harrison Chase von LangChain es ausdrückte: Traces sind der Ort, an dem die Quelle der Wahrheit für einen Agenten jetzt liegt. Code sagt Ihnen, was das System tun kann. Traces sagen Ihnen, was es tatsächlich in dem Moment gesehen hat, als es handelte. Ohne sie wird jeder Produktionsfehler zu einer Vermutung.

Ein Modell ohne Kontext-Observability ist kein intelligentes System. Es ist eine selbstbewusste Black Box mit Zugriff auf Ihren Workflow.

Die neunte Frage: Verantwortlichkeit

Die acht Komponenten sind technischer Natur. Die neunte ist organisatorisch, und sie ist diejenige, die die meisten Teams übergehen. Jemand muss die Kontextebene nach dem Start verantworten. Nicht den Prompt, nicht das Modell, sondern den Kontext: die Quellen, die Berechtigungen, die Speicherregeln, die Evaluierungssuite, die Protokolle.

Wenn die Verantwortlichkeit nicht zugewiesen ist, verfällt der Kontext. Quellen veralten, Berechtigungen driften ab, der Speicher bläht sich auf, und niemand ist rechenschaftspflichtig, weil das Modell der sichtbare Teil ist und das Modell die Schuld zugeschoben bekommt. Die Checkliste später in diesem Artikel greift dies wieder auf, weil es die einzige Frage ist, die am besten vorhersagt, ob ein Agent überlebt.

Kontext-Engineering in realen KI-Systemen

Frameworks sind leicht zu befürworten, aber schwer anzuwenden. Die klarsten Beispiele für Kontext-Engineering sind diejenigen, bei denen ein guter Prompt niemals ausreichen würde und die Lösung strukturell war. Dieser Fall, der aus den Systemen stammt, die Codebridge entwickelt, zeigt, was die Context Control Plane in der Praxis verändert. Er beginnt mit einer vernünftigen Anweisung, einer sauberen Demo und einer Produktionsumgebung, die alles offenbart, was die Anweisung nie wusste.

Ein HealthTech Workflow-Assistent

Szenario. Eine HealthTech-Plattform fügt einen KI-Assistenten hinzu, um Klinikpersonal dabei zu unterstützen, Patienteninformationen zu navigieren und einen Workflow zu durchlaufen.

Die reine Prompt-Version. Das Team weist den Assistenten an, vorsichtig, konservativ und medizinisch verantwortungsbewusst zu sein. Die Anweisung ist aufrichtig, aber fast bedeutungslos. Die eigentlichen Risiken sind strukturell: den Kontext des falschen Patienten anzuzeigen, keinen Audit-Trail zu hinterlassen, die Eskalation undefiniert zu lassen oder Daten außerhalb der Rolle des Klinikpersonals offenzulegen. Keines davon ist ein Formulierungsproblem. Ein fehlendes Berechtigungsmodell lässt sich nicht durch Anweisungen beheben.

Die Kontext-Engineering-Lösung.

• Patientenspezifischer Abruf, beschränkt auf den Fall, der dem Klinikpersonal vorliegt
• Rollenbasierter Zugriff, sodass jede Rolle nur das sieht, wozu sie berechtigt ist, und nichts darüber hinaus
• Ein Audit-Trail, der aufzeichnet, was der Assistent abgerufen und angezeigt hat
• Menschliche Genehmigung für jede risikoreiche Aktion
• Quellenangaben zu jeder klinischen Behauptung, damit das Klinikpersonal überprüfen und nicht nur vertrauen kann
• Eine strikte Trennlinie zwischen administrativer Unterstützung und klinischer Beurteilung

Die Erkenntnis. In einem regulierungsintensiven Bereich ist Kontext-Engineering eine Sicherheits- und Compliance-Anforderung. Codebridges RadFlow AI, ein KI-gestützter Radiologie-Workflow-Assistent, wurde genau auf dieser Prämisse aufgebaut. 

Ein HIPAA-konformes System, das in die bestehende PACS-Infrastruktur integriert ist und darauf ausgelegt wurde, Radiologen zu unterstützen, anstatt sie zu ersetzen. Dessen Ergebnisse wurden vom klinischen Lenkungsausschuss des Kunden und einer unabhängigen Doppelblindstudie validiert, bevor irgendeiner Zahl vertraut wurde. Die Intelligenz befand sich in einer kontrollierten Kontextschicht. Das machte es in einem Krankenhaus einsetzbar, anstatt nur in einer Demo zu beeindrucken. Frühere Arbeiten, von einem Tool zur Krebsbehandlungsverwaltung bis hin zu einer Wissensplattform der Big Four, folgten derselben Disziplin: Das Modell war der einfache Teil, und die Kontextarchitektur war das Produkt.

Wenn in einem Krankenhaus etwas schiefgeht, ist „Das Modell hat einen Fehler gemacht“ keine akzeptable Antwort. Der Audit-Trail und die Quellenverweise existieren, damit ein Kliniker und später eine Aufsichtsbehörde genau rekonstruieren können, was der Assistent gesehen hat und warum es aufgetaucht ist. Das heißt, Beobachtbarkeit wird als klinische Anforderung behandelt, nicht als technische Spielerei.

Kontext-Engineering vs. RAG: Sind sie dasselbe?

Eine gängige Abkürzung behandelt Kontext-Engineering und RAG als dasselbe. Das sind sie nicht. RAG ist eine Technik innerhalb des Kontext-Engineerings, eine wichtige, aber sie beantwortet eine enge Frage.

RAG ruft externe Informationen ab und fügt sie dem Fenster des Modells hinzu. Das ist wertvoll und macht den Großteil dessen aus, was viele Produktionssysteme heute tun. Aber der Abruf allein entscheidet nicht, ob die Informationen hätten abgerufen werden sollen, wie sie gegenüber anderen Quellen zu bewerten sind, ob dieser Benutzer sie sehen darf, wie sie sich mit Speicher und Tools kombinieren oder was das System tun soll, wenn zwei abgerufene Quellen widersprüchlich sind. Das sind Fragen des Kontext-Engineerings, und RAG beantwortet sie nicht.

Die Branche hat begonnen, dies offen auszusprechen. In einer 2026er Umfrage unter Daten- und IT-Führungskräften, stimmten mehr als drei Viertel zu, dass RAG allein nicht ausreicht für zuverlässige Produktions-KI, und dass größere Kontextfenster es nicht retten, weil mehr Kapazität ohne bessere Kuration nur mehr Raum für Rauschen schafft.

RAG kann Dokumente in den Raum stellen. Kontext-Engineering entscheidet, welche Dokumente dorthin gehören, wer sie lesen darf und was der Agent tun soll, wenn sie widersprüchlich sind.

So erkennen Sie, ob Ihr KI-Problem ein Prompt-Problem oder ein Kontext-Problem ist

Bevor Sie ein KI-System neu aufbauen, finden Sie heraus, welche Art von Fehler Sie vor sich haben. Die Lösung für ein Prompt-Problem und die Lösung für ein Kontext-Problem haben fast nichts gemeinsam, und Teams verschwenden Wochen damit, das eine auf das andere anzuwenden.

Das Symptom sagt Ihnen normalerweise, was es ist.

Die Unterscheidung ist klar genug, um danach zu handeln. Wenn die Ausgabe schlecht formatiert ist, beginnen Sie mit dem Prompt. Wenn die Ausgabe gut formatiert ist und auf falschen Fakten, einem falschen Benutzerstatus, falschen Tools, einem falschen Speicher oder falschen Berechtigungen basiert, ist der Prompt nicht Ihr Problem, und ihn neu zu schreiben ist Bewegung ohne Fortschritt.

Eine CTO-Checkliste vor dem Aufbau eines KI-Agenten

Bevor Sie einen KI-Agenten aufbauen, definieren Sie den Kontext, den er benötigt. Die meisten Teams definieren das Modell und den Prompt und entdecken dann die Kontextschicht in der Produktion, Vorfall für Vorfall. Die Architektur sollte diese Fragen beantworten, bevor der Workflow skaliert, nicht danach:

Führen Sie diese Liste als Design-Review durch, nicht als Launch-Checkliste. Jede Frage, die Sie vor dem Aufbau nicht beantworten können, wird Ihnen die Produktion beantworten, zu einem schlechteren Zeitpunkt und zu einem höheren Preis. Die Teams, deren Agenten überleben, sind diejenigen, die bewusst und im Voraus entschieden haben, was ihre Agenten wissen durften.

Fazit

Der Vergleich zwischen Kontext-Engineering und Prompt-Engineering ist eine praktische Unterscheidung zwischen der Verbesserung einer Anweisung und dem Entwurf des Systems darum herum.

Prompt-Engineering ist immer noch wichtig. Es gibt dem Modell eine klare Aufgabe, und eine klare Aufgabe ist nicht optional. Aber ein KI-Agent braucht mehr als eine klare Aufgabe. Er benötigt aktuelle Daten, zuverlässigen Abruf, kontrollierten Speicher, sichere Tools, berechtigungsbewussten Zugriff, einen erhaltenen Workflow-Status, Evaluierung, Beobachtbarkeit und einen Verantwortlichen. Das sind architektonische Belange.

Das nächste Mal, wenn ein Agent fehlschlägt, widerstehen Sie dem Reflex, den Prompt zu öffnen. Fragen Sie, was das Modell gesehen hat, bevor es geantwortet hat. Wenn Ihr KI-Agent auch nach zehnmaligem Umschreiben des Prompts immer wieder fehlschlägt, ist der Prompt wahrscheinlich nicht das Problem. Das System verlangt vom Modell, innerhalb einer Kontextebene zu agieren, die nie dafür konzipiert wurde.

Bevor Sie einen Agenten skalieren, nehmen Sie einen Workflow und bilden Sie die dahinterliegende Kontextarchitektur ab: die Daten, die Tools, die Berechtigungen, den Speicher, die Evaluierung und die Verantwortlichkeiten. Diese eine Übung verrät Ihnen mehr darüber, ob der Agent bereit ist, als jede Prompt-Überprüfung es jemals tun wird.

Bei Codebridge ist dies die Ebene, die wir zuerst konzipieren. Wenn Sie einen KI-Agenten entwickeln oder evaluieren und dessen Zuverlässigkeit nicht den Anforderungen entspricht, ist die schnellste Diagnose selten ein besserer Prompt. Es ist ein ehrlicher Blick auf den Kontext, in dem der Agent läuft.