"Prompt engineer" was nooit een precieze functietitel, maar dat hoefde ook lange tijd niet. Als je hele taak eruit bestond om met één inferentie-aanroep één goed antwoord te krijgen, dan volstond één vaardighedenpakket: de instructie goed formuleren, een paar voorbeelden geven, misschien wat opgehaalde tekst toevoegen, klaar. Dat vaardighedenpakket doet er nog steeds toe. Maar het dekt niet meer wat "een agent bouwen" medio 2026 inhoudt, en die kloof uit zich in een specifiek, herkenbaar faalpatroon: agents die in een demo geweldig werken en vervolgens sluipenderwijs achteruitgaan, zichzelf tegenspreken, of vergeten wat de gebruiker ze twee sessies geleden heeft verteld.

Een recent artikel van Machine Learning Mastery benoemt die kloof rechtstreeks, en het is de moeite waard om erbij stil te staan, omdat het naadloos aansluit op twee verschillende functies waarvoor je daadwerkelijk zou kunnen worden aangenomen. Context engineering is wat er binnen één inferentie-aanroep gebeurt: bepalen wat er in het contextvenster komt, waar het structureel wordt geplaatst, en wat er wordt gecomprimeerd of weggelaten zodat het model niet verzuipt in irrelevante tokens. Memory engineering is een ander probleem dat alleen tussen aanroepen door bestaat: wat er na afloop van een sessie wordt vastgelegd, waar het wordt opgeslagen, hoe het de volgende keer wordt opgehaald, en hoe het wordt onderhouden (bijgewerkt, ontdubbeld, laten verlopen) zodat het niet verrot. Volgens dat artikel zijn de storingen die zich voordoen in lange, meersessie-agentworkflows meestal terug te voeren op het door elkaar halen van deze twee taken, of op het overslaan van een van beide — vooral bij wat men de "retrieval boundary" noemt, het moment waarop een agent moet beslissen of iets wat hij nodig heeft al vóór hem ligt, of moet worden opgehaald uit opslag.

Waarom het door elkaar halen ervan de eigenlijke fout is, en geen detail

Bedenk waar elke discipline op optimaliseert. Context engineering optimaliseert één begrensd, wegwerpbaar venster — de juiste snede informatie nú voor het model neerleggen, voor deze ene uitwisseling, en de rest weggooien. Memory engineering optimaliseert een duurzame opslag die sessies moet overleven, consistent moet blijven naarmate nieuwe informatie binnenkomt, en een veel lastigere vraag moet beantwoorden: niet "wat is relevant voor deze prompt", maar "wat is überhaupt de moeite waard om te bewaren, en voor hoe lang."

Dat zijn verschillende ontwerpproblemen met verschillende faalpatronen. Een fout in context engineering maakt één antwoord slechter. Een fout in memory engineering stapelt zich op — slechte schrijfacties hopen zich op, verouderde feiten worden opgehaald alsof ze actueel zijn, en niemand merkt het totdat de agent vol overtuiging iets herhaalt wat drie sessies geleden al werd gecorrigeerd. Als één persoon (of één prompttemplate) stilletjes beide taken uitvoert zonder ze te onderscheiden, neigt de geheugenlaag ertoe gewoontes van context engineering over te nemen die het niet zou moeten overnemen: opslag net zo overladen als je een venster zou overladen, of retrieval behandelen als een relevantie-rangschikkingsprobleem terwijl het eigenlijk een curatie- en onderhoudsprobleem is. Dat is de vermenging waar het onderzoeksoverzicht op wijst, en het strookt met iets wat praktijkmensen al anekdotisch beschrijven: agents die in één sessie indrukwekkend zijn en tegen sessie vijf onbetrouwbaar.

Hoe elke taak er in de praktijk, dag in dag uit, daadwerkelijk uitziet

Als je probeert uit te zoeken welke van deze twee je al doet, of welke je juist zou willen opbouwen, dan verschilt het dagelijkse werk voldoende om ze uit elkaar te houden:

Context engineering, in de praktijk: bepalen welke deelverzameling van de beschikbare informatie (documentatie, tooloutput, eerdere beurten) daadwerkelijk in deze aanroep thuishoort; kiezen waar in de prompt die informatie komt te staan, aangezien positie beïnvloedt hoe zwaar modellen eraan tillen; compressie- of samenvattingsstappen schrijven zodat een lang tool-traceverslag niet het hele budget opsoupeert; en dit per taak afstemmen, aangezien een debug-agent en een schrijf-agent — zelfs op hetzelfde onderliggende model — een andere contextvorm willen.

Memory engineering, in de praktijk: een schrijfbeleid bepalen (wat is het waard om na een sessie te bewaren — niet alles is dat); een opslaglaag kiezen (een vectorstore, een gestructureerde database, gewone bestanden, een hybride vorm) en eerlijk zijn over de afwegingen van elk; de ophaalstrategie bouwen die bepaalt wat er wanneer weer naar boven komt; en doorlopend onderhoud plegen — opschonen, dubbele feiten samenvoegen, tegenstrijdigheden afhandelen wanneer de gebruiker van gedachten verandert. Dat laatste onderdeel, onderhoud, is degene die het vaakst wordt overgeslagen, omdat het pas zichtbaar wordt nadat een agent al weken draait.

Je ziet de sector deze zaken al structureel beginnen te scheiden, niet alleen conceptueel. De doorloop van Lenny's Newsletter over het bouwen van een debug-harnas op de Claude Agent SDK behandelt permissies, tooladapters en het omringende "harnas" als een eigen technisch domein, los van de prompting daarbinnen — hetzelfde instinct, toegepast op een andere naad. En de nieuwere "Managed Agents"-functies van Google's Gemini API — achtergronduitvoering, credential-vernieuwing tussen interacties door — komen er in feite op neer dat de platformleverancier toegeeft dat sessie-persistente status nu infrastructuur is die ontworpen moet worden, en geen bijverschijnsel van een lang genoeg contextvenster. Iemand moet de eigenaar van dat ontwerp zijn. Op dit moment is dat bij veel teams niemand expliciet.

Waarom dit ertoe doet voor je functietitel, niet alleen voor je code

Als je vroeg of halverwege je carrière zit en "prompt engineer" of "AI engineer" op je cv staat, loont het de moeite jezelf af te vragen van welke van deze twee taken je daadwerkelijk bewijs kunt tonen — want generalistische AI-agentrollen beginnen uiteen te vallen in specifiekere rollen, net zoals "webmaster" uiteindelijk opsplitste in frontend, backend en DevOps. Dat is een voorbehoud, geen kop boven het artikel: ik heb nog geen harde wervingsdata gezien die "memory engineer" als op zichzelf staande titel bevestigen, dus zie dit als een inschatting van waar het werk naartoe beweegt, niet als een bewering dat vacaturesites al zo zijn ingedeeld. Maar de onderliggende druk is reëel en te herleiden tot het bovenstaande overzicht: agentteams lopen tegen een specifiek, benoembaar falen aan (achteruitgang over meerdere sessies) met een specifieke, benoembare oorzaak (het door elkaar halen van twee disciplines), en die combinatie is doorgaans wat een vage rol in twee scherp afgebakende rollen verandert.

De praktische stap is niet om zelf een titel te verzinnen. Het is om concreet te kunnen antwoorden welk probleem je daadwerkelijk hebt opgelost. Heb je iets uitgebracht waarbij je een schrijfbeleid hebt ontworpen — een regel voor wat een agent aan het geheugen toevertrouwt en wat hij weggooit? Heb je een storing bij de retrieval-grens opgelost, waarbij een agent iets uit opslag nodig had en dat óf niet ophaalde óf de verkeerde versie ophaalde? Dat zijn controleerbare beweringen die je in een sollicitatiegesprek kunt doen, onderbouwd met een repo of een postmortem, en ze zeggen iets wat een algemeen "ik schrijf goede prompts" niet zegt: dat je het verschil begrijpt tussen één antwoord beter maken en een agent op de lange termijn betrouwbaar maken.

Een waarschuwing

Doop jezelf niet om tot "memory engineer" op grond van het feit dat je ooit één keer een vectordatabase aan een project hebt toegevoegd. De discipline waar het onderzoek op wijst omvat ook de onaantrekkelijke helft — onderhoud, verlopen, tegenstrijdigheden afhandelen — en dat is nu juist de helft die het hierboven beschreven faalpatroon daadwerkelijk voorkomt. Als jouw portfoliostuk een systeem is dat wel naar het geheugen schrijft maar waarin nooit iets wordt opgeschoond of gecorrigeerd, heb je maar de helft van het werk van een memory engineer gebouwd, en het probleem van falen-na-sessie-drie ligt nog steeds op je te wachten aan de andere helft.