„Prompt Engineer" war nie ein präziser Jobtitel, aber eine Zeit lang musste er das auch nicht sein. Wenn es bei der ganzen Arbeit nur darum ging, aus einem einzelnen Inferenzaufruf eine einzige gute Antwort herauszuholen, deckte ein einziges Skillset das ab: die Anweisung gut formulieren, ein paar Beispiele geben, vielleicht etwas abgerufenen Text hinzufügen, fertig. Dieses Skillset ist nach wie vor wichtig. Aber es deckt nicht mehr ab, was „einen Agenten bauen" Mitte 2026 bedeutet, und diese Lücke zeigt sich in einem spezifischen, wiedererkennbaren Fehlermuster: Agenten, die in einer Demo großartig funktionieren und dann still und leise schlechter werden, sich selbst widersprechen oder vergessen, was der Nutzer ihnen vor zwei Sitzungen gesagt hat.

Ein aktueller Beitrag von Machine Learning Mastery benennt diese Lücke direkt, und es lohnt sich, dabei zu verweilen, weil er sich sauber auf zwei unterschiedliche Aufgaben abbilden lässt, für die man tatsächlich eingestellt werden könnte. Context Engineering ist das, was innerhalb eines einzelnen Inferenzaufrufs passiert: entscheiden, was in das Kontextfenster kommt, wo es strukturell platziert wird und was komprimiert oder verworfen wird, damit das Modell nicht in irrelevanten Tokens ertrinkt. Memory Engineering ist ein anderes Problem, das nur über mehrere Aufrufe hinweg existiert: was nach Ende einer Sitzung festgehalten wird, wo es gespeichert wird, wie es beim nächsten Mal abgerufen wird und wie es gepflegt wird (aktualisiert, dedupliziert, verfallen gelassen), damit es nicht verrottet. Laut diesem Beitrag lassen sich die Fehler, die in langen, sitzungsübergreifenden Agenten-Workflows auftreten, meist darauf zurückführen, dass diese beiden Aufgaben vermischt oder eine von ihnen ausgelassen wird — besonders an dem, was dort als „Retrieval-Grenze" bezeichnet wird: der Moment, in dem ein Agent entscheiden muss, ob etwas, das er braucht, bereits vor ihm liegt oder aus dem Speicher geholt werden muss.

Warum das Vermischen der eigentliche Bug ist, nicht nur ein Detail

Denken Sie darüber nach, worauf jede Disziplin optimiert. Context Engineering optimiert ein einzelnes, begrenztes, wegwerfbares Fenster — die richtige Informationsscheibe genau jetzt, für diesen einen Austausch, vor das Modell bringen und den Rest dann verwerfen. Memory Engineering optimiert einen dauerhaften Speicher, der sitzungsübergreifend bestehen bleiben, bei neu eintreffenden Informationen konsistent bleiben und eine viel schwierigere Frage beantworten muss: nicht „was ist relevant für diesen Prompt", sondern „was ist es überhaupt wert, behalten zu werden, und für wie lange."

Das sind unterschiedliche Designprobleme mit unterschiedlichen Fehlermustern. Ein Context-Engineering-Fehler macht eine Antwort schlechter. Ein Memory-Engineering-Fehler summiert sich — schlechte Einträge häufen sich an, veraltete Fakten werden abgerufen, als wären sie aktuell, und niemand bemerkt es, bis der Agent selbstbewusst etwas wiederholt, das drei Sitzungen zuvor korrigiert wurde. Wenn eine Person (oder eine Prompt-Vorlage) still und leise beide Aufgaben übernimmt, ohne sie zu unterscheiden, übernimmt die Speicherschicht tendenziell Context-Engineering-Gewohnheiten, die sie nicht übernehmen sollte: den Speicher überfüllen, so wie man ein Fenster überfüllen würde, oder Retrieval als Relevanz-Ranking-Problem behandeln, obwohl es eigentlich ein Kuratierungs- und Wartungsproblem ist. Das ist die Vermischung, auf die der Forschungs-Digest hinweist, und sie deckt sich mit etwas, das Praktiker bereits anekdotisch beschreiben: Agenten, die in einer einzelnen Sitzung beeindruckend sind und ab der fünften Sitzung unzuverlässig.

Wie jede Aufgabe im Alltag tatsächlich aussieht

Wenn Sie herausfinden wollen, welche dieser beiden Aufgaben Sie bereits erledigen oder auf welche Sie hinarbeiten möchten, unterscheidet sich die Alltagsarbeit deutlich genug, um sie auseinanderzuhalten:

Context Engineering, in der Praxis: entscheiden, welche Teilmenge der verfügbaren Informationen (Dokumente, Tool-Ausgaben, frühere Runden) tatsächlich in diesen Aufruf gehört; auswählen, wo im Prompt sie platziert wird, da die Position beeinflusst, wie Modelle sie gewichten; Kompressions- oder Zusammenfassungsschritte schreiben, damit ein langer Tool-Trace nicht das gesamte Budget auffrisst; und dies pro Aufgabe abstimmen, da ein Debugging-Agent und ein Schreib-Agent selbst bei demselben zugrunde liegenden Modell unterschiedliche Kontextformen wollen.

Memory Engineering, in der Praxis: eine Schreibrichtlinie definieren (was es wert ist, nach einer Sitzung dauerhaft gespeichert zu werden — nicht alles ist es); eine Speicherschicht auswählen (ein Vektorspeicher, eine strukturierte Datenbank, einfache Dateien, eine Hybridlösung) und ehrlich mit den jeweiligen Kompromissen umgehen; die Retrieval-Strategie aufbauen, die entscheidet, was wann wieder herauskommt; und laufende Wartung betreiben — bereinigen, doppelte Fakten zusammenführen, Widersprüche behandeln, wenn der Nutzer seine Meinung ändert. Dieser letzte Teil, die Wartung, ist der, den man am häufigsten auslässt, weil er nicht sichtbar ist, bevor ein Agent nicht schon wochenlang läuft.

Man kann beobachten, wie die Branche beginnt, diese Belange strukturell zu trennen, nicht nur konzeptionell. Lenny's Newsletter zeigt in einer Anleitung zum Aufbau eines Debugging-Harnischs auf dem Claude Agent SDK, dass Berechtigungen, Tool-Adapter und der umgebende „Harness" als eigene technische Fläche behandelt werden, getrennt vom Prompting darin — derselbe Instinkt, angewandt auf eine andere Nahtstelle. Und Googles neuere Gemini-API-Funktionen „Managed Agents" — Hintergrundausführung, Anmeldedaten-Auffrischung über mehrere Interaktionen hinweg — sind faktisch das Eingeständnis des Plattformanbieters, dass sitzungsübergreifend persistenter Zustand nun Infrastruktur ist, die entworfen werden muss, und kein Nebeneffekt eines ausreichend langen Kontextfensters. Jemand muss dieses Design verantworten. Im Moment tut das bei vielen Teams niemand explizit.

Warum das für Ihren Jobtitel wichtig ist, nicht nur für Ihren Code

Wenn Sie am Anfang oder in der Mitte Ihrer Karriere stehen und „Prompt Engineer" oder „AI Engineer" in Ihrem Lebenslauf steht, lohnt es sich zu fragen, für welche dieser beiden Aufgaben Sie tatsächlich Nachweise vorlegen können — denn generalistische KI-Agenten-Rollen beginnen sich in spezifischere Rollen aufzuspalten, so wie sich „Webmaster" irgendwann in Frontend, Backend und DevOps aufgeteilt hat. Das ist eine Absicherung, keine Schlagzeile: Ich habe noch keine belastbaren Einstellungsdaten gesehen, die „Memory Engineer" als eigenständigen Titel bestätigen, also betrachten Sie dies als eine Einschätzung, wohin sich die Arbeit entwickelt, nicht als Behauptung, dass Stellenbörsen bereits so sortiert sind. Aber der zugrunde liegende Druck ist real und lässt sich auf den oben genannten Digest zurückführen: Agenten-Teams stoßen auf einen spezifischen, benennbaren Fehler (sitzungsübergreifende Verschlechterung), der eine spezifische, benennbare Ursache hat (das Vermischen zweier Disziplinen), und diese Kombination ist üblicherweise das, was aus einer unscharfen Rolle zwei scharf umrissene macht.

Der praktische Schritt besteht nicht darin, sich selbst einen Titel auszudenken. Es geht darum, konkret beantworten zu können, welches Problem man tatsächlich gelöst hat. Haben Sie etwas ausgeliefert, bei dem Sie eine Schreibrichtlinie entworfen haben — eine Regel dafür, was ein Agent dem Speicher anvertraut und was er verwirft? Haben Sie einen Retrieval-Grenz-Fehler debuggt, bei dem ein Agent etwas aus dem Speicher benötigte und es entweder nicht abgerufen oder die falsche Version abgerufen hat? Das sind überprüfbare Behauptungen, die Sie in einem Vorstellungsgespräch aufstellen können, gestützt durch ein Repository oder eine Nachbetrachtung, und sie sagen etwas aus, was ein allgemeines „Ich schreibe gute Prompts" nicht sagt: dass Sie den Unterschied verstehen zwischen einer einzelnen besseren Antwort und einem Agenten, der über die Zeit hinweg vertrauenswürdig bleibt.

Eine Warnung

Nennen Sie sich nicht „Memory Engineer", nur weil Sie einmal einer Anwendung eine Vektordatenbank hinzugefügt haben. Die Disziplin, auf die die Forschung hinweist, umfasst die unglamouröse Hälfte — Wartung, Verfall, Widerspruchsbehandlung — und das ist die Hälfte, die das oben beschriebene Fehlermuster tatsächlich verhindert. Wenn Ihr Portfolio-Stück ein System ist, das in den Speicher schreibt, aber nie etwas bereinigt oder korrigiert wird, haben Sie nur die halbe Arbeit eines Memory Engineers geleistet, und das Problem des Scheiterns ab der dritten Sitzung wartet immer noch auf der anderen Hälfte auf Sie.