"Prompt engineer" was nog nooit 'n presiese posbenaming nie, maar vir 'n tyd lank hoef dit nie te wees nie. As jou hele werk was om een goeie antwoord uit een enkele inferensie-oproep te kry, het een vaardigheidstel dit gedek: formuleer die instruksie goed, gee 'n paar voorbeelde, voeg dalk 'n bietjie herwonne teks by, klaar. Daardie vaardigheidstel is steeds belangrik. Maar dit dek nie meer wat "om 'n agent te bou" middel-2026 beteken nie, en die gaping kom na vore as 'n spesifieke, herkenbare mislukkingspatroon: agente wat pragtig werk in 'n demonstrasie en dan stilweg agteruitgaan, hulself weerspreek, of vergeet wat die gebruiker hulle twee sessies gelede vertel het.

'n Onlangse stuk van Machine Learning Mastery noem die gaping reguit, en dit is die moeite werd om by stil te staan, want dit sluit netjies aan by twee verskillende werke wat jy eintlik aangestel kan word om te doen. Konteks-ingenieurswese is wat binne een inferensie-oproep gebeur: besluit wat in die konteksvenster ingaan, waar dit strukureel geplaas word, en wat saamgepers of laat vaar word sodat die model nie in irrelevante tokens versuip nie. Geheue-ingenieurswese is 'n ander probleem wat slegs oor oproepe heen bestaan: wat neergeskryf word nadat 'n sessie eindig, waar dit gestoor word, hoe dit die volgende keer opgehaal word, en hoe dit onderhou word (opgedateer, gededupliseer, laat verval) sodat dit nie vrot nie. Volgens daardie stuk kan die mislukkings wat in lang, multi-sessie agent-werkvloeie voorkom, meestal teruggevoer word na die vermenging van hierdie twee take, of die oorslaan van een daarvan — veral by wat hulle die "herwinningsgrens" noem, die oomblik wanneer 'n agent moet besluit of iets wat dit nodig het, reg voor hom lê, of eers uit stoor gehaal moet word.

Waarom die vermenging daarvan die werklike fout is, nie net 'n detail nie

Dink na oor waarvoor elke dissipline optimaliseer. Konteks-ingenieurswese optimaliseer 'n enkele, begrensde, weggooibare venster — kry die regte snit inligting reg nou voor die model, vir hierdie een uitruil, en gooi dan die res weg. Geheue-ingenieurswese optimaliseer 'n blywende bewaarplek wat oor sessies heen moet oorleef, konsekwent moet bly namate nuwe inligting inkom, en 'n baie moeiliker vraag moet beantwoord: nie "wat is relevant tot hierdie prompt" nie, maar "wat is dit werd om glad te behou, en vir hoe lank."

Dit is verskillende ontwerpprobleme met verskillende mislukkingspatrone. 'n Fout in konteks-ingenieurswese maak een antwoord swakker. 'n Fout in geheue-ingenieurswese vermenigvuldig — swak inskrywings hoop op, verouderde feite word opgehaal asof dit nog aktueel is, en niemand agterkom dit nie totdat die agent selfversekerd iets herhaal wat drie sessies gelede reggestel is. As een persoon (of een promptsjabloon) stilweg altwee take doen sonder om tussen hulle te onderskei, neig die geheuelaag om gewoontes van konteks-ingenieurswese oor te erf wat dit nie behoort te doen nie: stoor oorpak soos jy 'n venster sou oorpak, of herwinning behandel as 'n relevansie-rangskikkingsprobleem terwyl dit eintlik 'n kurasie-en-onderhoudprobleem is. Dit is die vermenging waarna die navorsingsopsomming wys, en dit stem ooreen met iets wat praktisyns reeds anekdoties beskryf: agente wat in 'n enkele sessie indrukwekkend is en teen die vyfde sessie onbetroubaar.

Hoe elke werk daagliks werklik lyk

As jy probeer uitvind watter een van hierdie jy reeds doen, of watter een jy sou wou uitbou, lyk die daaglikse werk verskillend genoeg om uitmekaar te hou:

Konteks-ingenieurswese, in die praktyk: besluit watter subversameling van beskikbare inligting (dokumente, hulpmiddel-uitsette, vorige beurte) werklik in hierdie oproep tuishoort; kies waar in die prompt dit gaan, aangesien posisie beïnvloed hoe modelle dit weeg; skryf saampers- of opsommingstappe sodat 'n lang hulpmiddel-spoor nie die hele begroting opeet nie; en dit per taak verstel, aangesien 'n ontfoutingsagent en 'n skryfagent verskillende konteksvorms verlang, selfs op dieselfde onderliggende model.

Geheue-ingenieurswese, in die praktyk: omskryf 'n skryfbeleid ('n mens wat werd is om te behou nadat 'n sessie verby is — nie alles is dit nie); kies 'n bergingslaag ('n vektorstoor, 'n gestruktureerde databasis, gewone lêers, 'n hibriede kombinasie) en eerlik wees oor die kompromieë van elkeen; bou die herwinningstrategie wat besluit wat weer uitkom en wanneer; en deurlopende onderhoud doen — snoei, dupliserende feite saamvoeg, teenstrydighede hanteer wanneer die gebruiker van gedagte verander. Daardie laaste deel, onderhoud, is die deel wat mense die meeste oorslaan, want dit is nie sigbaar nie totdat 'n agent al vir weke loop.

Jy kan sien hoe die bedryf hierdie sake struktureel begin skei, nie net konseptueel nie. Lenny's Newsletter se deurloop van die bou van 'n ontfoutingstuig op die Claude Agent SDK behandel toestemmings, hulpmiddel-adapters, en die omringende "tuig" as hul eie ingenieursvlak, apart van die prompting daarbinne — dieselfde instink, toegepas op 'n ander naat. En Google se nuwer Gemini API "Managed Agents"-kenmerke — agtergrond-uitvoering, geloofsbriefvernuwing oor interaksies heen — is in wese die platformverskaffer wat toegee dat sessie-blywende toestand nou infrastruktuur is wat ontwerp moet word, nie 'n newe-effek van 'n lank genoeg konteksvenster nie. Iemand moet daardie ontwerp besit. Op baie spanne op die oomblik doen niemand dit uitdruklik nie.

Waarom dit saak maak vir jou posbenaming, nie net jou kode nie

As jy vroeg of middel in jou loopbaan is en "prompt engineer" of "AI engineer" op jou CV staan, is dit die moeite werd om te vra van watter van hierdie twee werke jy eintlik bewyse kan toon dat jy dit doen — want generalistiese KI-agentrolle begin uitmekaar getrek word in meer spesifieke rolle, net soos "webmaster" uiteindelik in front-end-, back-end- en DevOps-rolle opgesplits het. Dit is 'n verskansing, nie 'n opskrif nie: ek het nog nie harde aanstellingsdata gesien wat "memory engineer" as 'n selfstandige posbenaming bevestig nie, so beskou dit as 'n aanvoeling oor waarheen die werk beweeg, nie 'n bewering dat werksborde reeds so gesorteer is nie. Maar die onderliggende druk is werklik en na te speur tot die opsomming hierbo: agentspanne loop teen 'n spesifieke, benoembare mislukking vas (multi-sessie agteruitgang) wat 'n spesifieke, benoembare oorsaak het (die vermenging van twee dissiplines), en daardie kombinasie is gewoonlik wat 'n vaag rol in twee skerp rolle verander.

Die praktiese stap is nie om 'n titel vir jouself uit te dink nie. Dit is om konkreet te kan antwoord watter probleem jy werklik opgelos het. Het jy iets uitgereik waar jy 'n skryfbeleid ontwerp het — 'n reël vir wat 'n agent na geheue toebind en wat dit laat vaar? Het jy 'n herwinningsgrens-mislukking ontfout, waar 'n agent iets uit stoor nodig gehad het en dit óf nie gaan haal het nie, óf die verkeerde weergawe gehaal het? Dit is nagaanbare bewerings wat jy in 'n onderhoud kan maak, gerugsteun deur 'n bewaarplek of 'n na-mortem-ontleding, en hulle sê iets wat 'n generiese "ek skryf goeie prompts" nie sê nie: dat jy die verskil verstaan tussen om een antwoord beter te maak en om 'n agent oor tyd heen betroubaar te maak.

'n Waarskuwing

Moenie jouself "memory engineer" herbenoem net omdat jy eenmaal 'n vektordatabasis by 'n projek gevoeg het nie. Die dissipline waarna die navorsing wys, sluit die minder glansryke helfte in — onderhoud, verval, teenstrydigheidhantering — en dit is die helfte wat werklik die mislukkingspatroon hierbo beskryf, voorkom. As jou portefeuljestuk 'n stelsel is wat na geheue skryf maar niks ooit gesnoei of reggestel word nie, het jy net die helfte van 'n geheue-ingenieur se werk gebou, en die faal-teen-die-derde-sessie-probleem wag steeds vir jou by die ander helfte.