Context Engineering vs. Memory Engineering vs. Harness Engineering: Die 3 Disziplinen hinter Production Agents

Drei Dinge entscheiden darüber, ob ein Agent den Kontakt mit der Produktivumgebung überlebt, und die meisten Teams behandeln sie wie ein einziges. Context Engineering optimiert das Signal-Rausch-Verhältnis dessen, was bei jedem Aufruf in das Kontextfenster gelangt: was aufgenommen, was weggelassen, was komprimiert und wie Aktualität gegenüber Relevanz abgewogen werden soll. Memory Engineering ist das System, mit dem ein Agent über die Zeit hinweg lernt: was gespeichert, was abgerufen, was vergessen werden soll und wie sich Wissen zwischen verschiedenen Durchläufen entwickelt. Harness Engineering ist das eigenwillige Gerüst um das Modell herum: die Runtime-Schleife, Tool-Aufrufe, Retries, Guardrails und Kostenkontrollen, die ein Sprachmodell in einen zuverlässigen Mitarbeiter verwandeln. Es handelt sich um separate Disziplinen. Sie scheitern auf unterschiedliche Weise. Produktiv-Agenten benötigen alle drei, und die meisten Teams finanzieren nur eine.

Die drei Disziplinen im Vergleich

Der schnellste Weg, den Unterschied zu verstehen, besteht darin, sie nebeneinander aufzustellen. Jede Disziplin optimiert etwas anderes, bricht auf andere Weise zusammen und zeigt sich in einem anderen Teil des Stacks.

Derselbe Agent. Drei Ebenen. Ein Fehler in der einen sieht völlig anders aus als ein Fehler in den anderen – genau das ist der Grund, warum das Zusammenwerfen dieser Disziplinen das Debugging von Agenten so extrem erschwert.

Context Engineering: Das Aufmerksamkeitsbudget verwalten, nicht die Token-Anzahl

Context Engineering ist die Praxis der Entscheidung, was bei einem bestimmten Aufruf in das Kontextfenster gelangt, was komprimiert, was bei Bedarf abgerufen und was weggelassen wird. Anthropic formuliert das Ziel so, „die kleinste Menge an informationsreichen Token zu finden, die die Wahrscheinlichkeit eines gewünschten Ergebnisses maximieren“. Die knappe Ressource ist nicht die Fenstergröße. Es ist die Aufmerksamkeit des Modells.

Hier liegt der Fehler beim Instinkt des „größeren Kontextfensters“. Jedes Token, das Sie hinzufügen, verbraucht einen Teil eines festen Aufmerksamkeitsbudgets. Anthropic verweist auf Forschungen zum Kontextverfall: Mit steigender Token-Anzahl im Fenster sinkt die Fähigkeit des Modells, sich präzise an einen bestimmten Fakt aus diesem Fenster zu erinnern – und das bei jedem getesteten Modell. Mehr Kontext bedeutet routinemäßig schlechtere Antworten, nicht bessere.

Das Fehlermuster ist tückisch, weil es unauffällig ist. Der richtige Fakt befindet sich im Prompt. Er ist nur unter lose zusammenhängenden Datensätzen, widersprüchlichen Definitionen und redundantem Hintergrundwissen vergraben, die alle um die Aufmerksamkeit konkurrieren. Der Agent liefert eine selbstsichere Antwort, die auf den falschen drei Sätzen basiert, und im Protokoll steht nichts von „zu viel Rauschen“. Es sieht so aus, als sei das Modell verwirrt gewesen. Dabei war es einfach überfordert.

Gutes Context Engineering besteht aus einer Reihe von Entscheidungen, die bei jedem Aufruf neu getroffen werden. Abgerufene Ergebnisse priorisieren und nur die besten weitergeben, nicht alle. Lange Historien in einer fortlaufenden Zusammenfassung komprimieren. Eine aktuelle Nachricht gegenüber einer älteren, aber relevanteren abwägen. Den Tool-Output auf die relevanten Felder reduzieren. Die Disziplin ist die Subtraktion, und sie wird zurückgesetzt, wenn der Aufruf endet. Nichts davon bleibt dauerhaft bestehen.

Memory Engineering: Entscheiden, was der Agent behält und was er vergisst

Memory Engineering ist die entgegengesetzte Achse. Während Context Engineering regelt, was das Modell bei einer einzelnen Anfrage sieht, regelt das Memory-System, was sich das System über Anfragen hinweg merkt und wie dieses Wissen im Laufe der Zeit geschrieben, abgerufen, bewertet und gepflegt wird. Der Kontext ist designgemäß flüchtig. Der Speicher ist der Teil, der den Aufruf überlebt.

Die Disziplin umfasst vier Entscheidungen. Was gespeichert wird, damit der Agent das Ergebnis eines Durchlaufs erfasst, anstatt es zu verlieren. Was abgerufen wird, damit das richtige Wissen aus der Vergangenheit im richtigen Moment zum Vorschein kommt. Was vergessen wird, damit sich alter Zustand nicht ansammelt und zukünftige Entscheidungen verfälscht. Und wie sich Wissen entwickelt, damit ein Fakt, der im letzten Quartal wahr war, aktualisiert wird, anstatt ihm für immer blind zu vertrauen.

Das Memory-System scheitert in zwei Richtungen, und beide sind teuer. Entweder vergisst es, was wichtig war, sodass der Agent ein bereits gelöstes Problem erneut angeht, eine Frage stellt, die der Kunde bereits beantwortet hat, oder mitten in einer mehrteiligen Aufgabe den Faden verliert. Oder es erinnert sich zu gut und agiert mit voller Selbstüberzeugung auf Basis eines gespeicherten Fakts, der inzwischen veraltet, falsch oder gar nicht erst verifiziert war. Der zweite Fehler ist der gefährlichere. Ein Agent mit einem schlechten Memory-System ist schlimmer als einer ohne, weil er den Fehler weiterträgt und verstärkt.

Deshalb ist Memory nicht einfach nur eine Datenbank. Ein Vector Store liefert Ihnen den Abruf. Er liefert Ihnen jedoch keine Schreibrichtlinie, keine Vergessensrichtlinie oder eine Methode, um aktuelles Wissen von abgelaufenem Wissen zu unterscheiden. Das sind Engineering-Entscheidungen – und sie zu überspringen ist der Grund, warum Teams am Ende Agenten haben, die umso unzuverlässiger werden, je länger sie laufen.

Harness Engineering: Das Gerüst, das Zuverlässigkeit wiederholbar macht

Das Harness (Einfassung bzw. Gerüst) ist die Software um das Modell herum, die alles außer der eigentlichen Schlussfolgerung verwaltet. Es ist die Schleife, die das Modell aufruft, den Output parst, die Tool-Aufrufe ausführt, Ergebnisse zurückspielt und entscheidet, wann gestoppt werden muss, plus der Kontrollfluss, der verhindert, dass all das aus dem Ruder läuft. Wenn der Kontext das ist, was das Modell sieht, und das Memory das ist, woran es sich erinnert, dann ist das Harness die Maschine, in der es läuft.

Die Komponenten sind unglamourös, aber tragend: Die Agent-Schleife und ihre Stoppbedingungen. Tool- und Funktionsaufrufe, weitergeleitet an reale Systeme. Retries mit Backoff für vorübergehende Fehler und eine harte Grenze, damit ein fehlerhaftes Tool nicht ewig wiederholt wird. Timeouts und Limits für maximale Schritte, damit ein blockierter Durchlauf beendet wird, anstatt hängenzubleiben. Budget-Obergrenzen, damit eine einzelne Aufgabe nicht unbegrenzt Token oder Budget verbrennen kann. Guardrails für Inputs, Outputs und jeden Tool-Aufruf. Tracing, damit Sie bei Fehlern sehen können, wo es hakt.

Harness-Fehler sind diejenigen, die Schlagzeilen machen. Das Modell schloss richtig, aber der Durchlauf geriet in eine Schleife und verursachte immense Kosten. Ein Tool meldete einen Fehler und der Agent versuchte es fünfzig Mal erneut. Es gab keine Guardrail bei einer Schreibaktion, sodass der Agent etwas Unumkehrbares tat. Nichts davon ist ein Problem des Modells. Es ist ein fehlendes Gerüst, und kein besseres Modell der Welt kann das beheben.

Über das Harness Engineering wird die Zuverlässigkeit in der Produktivumgebung überhaupt erst aufgebaut. Ein Agent für das Forderungsmanagement, der Fälle mit einer Genauigkeit von 96 % bei unter 2 % Regression klassifiziert, ist kein Märchen über ein magisches Modell. Es ist das Ergebnis von Runtime, Tools und Absicherungen, die um das Modell herum entwickelt wurden: Eindeutige Fälle werden automatisch bearbeitet, Fälle mit geringem Vertrauen an eine Person weitergeleitet, und die gesamte Schleife ist so instrumentiert, dass die Genauigkeit bei steigendem Volumen stabil bleibt. Das ist auch der Grund, warum die Wahl des Modells weniger wichtig ist, als Teams annehmen. Wenn das Harness die Zuverlässigkeit sichert, können Sie das zugrunde liegende Modell austauschen, ohne den Agenten neu bauen zu müssen. Ein produktiver agentischer Workflow kann in 4 bis 6 Wochen live gehen, weil der schwierige Teil ein wiederverwendbares Gerüst ist und kein Prompt, den Sie unendlich perfektionieren müssen.

Warum Teams alle drei miteinander verwechseln

Die meisten Teams sehen nur ein einziges Problem – „Unser Agent ist unzuverlässig“ – und greifen zu einem einzigen Hebel. Meistens ist es das Modell. Manchmal ist es der Prompt. Der Grund, warum die Lösung selten von Dauer ist, liegt darin, dass die drei Disziplinen auf eine Weise scheitern, die von außen betrachtet identisch aussieht. Eine falsche Antwort könnte an Rauschen im Kontext liegen, an einem veralteten Fakt im Memory oder an einer Guardrail, die nie ausgelöst wurde. Das Symptom ist dasselbe. Die Ursache liegt an drei verschiedenen Stellen.

So verschiebt sich die Investition einseitig. Ein Team steckt Monate in das Prompt-Tuning und Kontext-Tricks, bringt es heraus, und der Agent baut bei langen Aufgaben immer noch ab, weil die eigentliche Lücke im Memory lag. Ein anderes Team baut eine ausgeklügelte Memory-Ebene auf und versteht nicht, warum der Agent bei einem einzelnen Aufruf immer noch halluziniert, weil der eingehende Kontext verrauscht war. Ein drittes Team hat sauberen Kontext und gutes Memory und wird trotzdem nachts um 2 Uhr alarmiert, weil es keine Begrenzung für Retries und keine Budget-Guardrails gibt. Jedes Team war kompetent. Jedes hat sich auf die falsche Disziplin konzentriert.

Die konzeptionelle Falle besteht darin, „Kontext“ als Allheilmittel zu behandeln. Das ist verlockend, weil letztendlich alle drei Bereiche Token durch dasselbe Fenster schleusen. Aber das Token im Fenster ist der allerletzte Schritt. Wie es ausgewählt wurde, ist Context Engineering. Ob es aus einem vergangenen Durchlauf hätte überdauern sollen, ist Memory Engineering. Ob der Aufruf, der es verwendet hat, wiederholt, begrenzt und kontrolliert wurde, ist Harness Engineering. Wenn Sie diese drei Fragen in einer einzigen zusammenfassen, verlieren Sie die Fähigkeit zu erkennen, welche davon fehlerhaft ist.

Das neue Denkmuster

Ein Agent ist kein Modell mit einem Prompt. Es sind drei Engineering-Disziplinen, die auf einem Modell aufbauen, und jede davon beweist ihren Wert unabhängig voneinander. Context Engineering sorgt bei jedem Aufruf für ein sauberes Signal. Memory Engineering entscheidet, was zwischen den Aufrufen überlebt und was losgelassen werden sollte. Harness Engineering macht das Ganze wiederholbar, begrenzt und sicher. Wenn Sie nur eine Disziplin finanzieren, erhalten Sie eine Demo. Wenn Sie alle drei finanzieren, erhalten Sie einen Agenten, der auch im sechsten Monat noch zuverlässig funktioniert. Wenn Ihr Agent also ausfällt, lautet die wirklich hilfreiche erste Frage nicht „Welches Modell?“, sondern „Welche Disziplin?“.

Sie wollen echte Einblicke aus der Praxis statt nur Hype? Wir versenden einen kurzen wöchentlichen Bericht darüber, was KI-Agenten in der Produktion tatsächlich zuverlässig macht. Hier abonnieren.