A "prompt engineer" soha nem volt pontos munkakör-megnevezés, de egy ideig nem is kellett annak lennie. Ha a teljes munkád abból állt, hogy egyetlen inferenciahívásból egy jó választ csiholj ki, egyetlen készségkészlet is elég volt hozzá: fogalmazd meg jól az utasítást, adj hozzá néhány példát, esetleg tegyél bele valamennyi lekérdezett szöveget, és kész. Ez a készségkészlet még ma is fontos. De már nem fedi le azt, amit 2026 közepén az "agent építése" jelent, és ez a hiányosság egy jól felismerhető, konkrét hibamintázatban mutatkozik meg: olyan agentekben, amelyek egy demóban remekül teljesítenek, majd csendben leromlik a teljesítményük, önmagukkal kerülnek ellentmondásba, vagy elfelejtik, mit mondott nekik a felhasználó két munkamenettel korábban.

A Machine Learning Mastery egyik friss cikke nyíltan megnevezi ezt a hiányosságot, és érdemes elidőzni rajta, mert szépen ráillik két különböző munkakörre, amelyre valójában felvehetnének téged. A kontextusmérnökség az, ami egyetlen inferenciahívás belsejében történik: eldönteni, mi kerüljön a kontextusablakba, hol helyezkedjen el szerkezetileg, és mit kell összesűríteni vagy elhagyni, hogy a modell ne fulladjon bele a lényegtelen tokenekbe. A memóriamérnökség egy másik probléma, amely csak a hívások között létezik: mi kerül rögzítésre egy munkamenet végén, hol tárolják, hogyan hívják elő legközelebb, és hogyan tartják karban (frissítve, deduplikálva, lejáratva), hogy ne rohadjon meg. A cikk szerint a hosszú, több munkamenetes agent-munkafolyamatokban felbukkanó hibák leggyakrabban arra vezethetők vissza, hogy ezt a két feladatot összemossák, vagy egyiküket kihagyják — különösen az általuk "lekérdezési határnak" (retrieval boundary) nevezett pillanatban, amikor az agentnek el kell döntenie, hogy amire szüksége van, az már előtte van, vagy a tárolóból kell lehívnia.

Miért maga a hiba az, hogy összemossuk a kettőt, nem csak egy apró részlet

Gondoljuk át, mit optimalizál valójában az egyik és a másik szakterület. A kontextusmérnökség egyetlen, korlátozott, egyszer használatos ablakot optimalizál — az információ megfelelő szeletét kell a modell elé tenni éppen most, ehhez az egy váltáshoz, majd a többit el lehet dobni. A memóriamérnökség egy tartós tárolót optimalizál, amelynek munkameneteken át kell fennmaradnia, konzisztensnek kell maradnia az új információk beérkezésekor, és egy sokkal nehezebb kérdésre kell választ adnia: nem arra, hogy "mi releváns ehhez a prompthoz", hanem arra, hogy "mi éri meg egyáltalán a megtartást, és mennyi ideig".

Ezek különböző tervezési problémák, különböző hibamintázatokkal. Egy kontextusmérnöki hiba egyetlen választ tesz rosszabbá. Egy memóriamérnöki hiba felhalmozódik — a rossz írások egymásra torlódnak, az elavult tények úgy kerülnek elő, mintha aktuálisak lennének, és senki nem veszi észre, amíg az agent magabiztosan meg nem ismétel valamit, amit már három munkamenettel korábban helyesbítettek. Ha egyetlen ember (vagy egyetlen promptsablon) csendben mindkét feladatot végzi anélkül, hogy megkülönböztetné őket, a memóriaréteg hajlamos átvenni olyan kontextusmérnöki szokásokat, amelyeket nem kellene: úgy túltölteni a tárolót, ahogyan egy ablakot túltöltenénk, vagy relevancia-rangsorolási problémaként kezelni a lekérdezést, miközben az valójában karbantartási és kurátori probléma. Erre az összemosásra utal a kutatási összefoglaló, és ez összecseng azzal, amit a gyakorló szakemberek már anekdotikusan is leírnak: olyan agentekkel, amelyek egyetlen munkamenetben lenyűgözőek, az ötödik munkamenetre viszont megbízhatatlanná válnak.

Milyen valójában a napi munka mindkét szerepben

Ha próbálod kitalálni, hogy a kettő közül melyiket csinálod már most, vagy melyik felé szeretnél haladni, a napi munka eléggé eltér, hogy meg lehessen különböztetni őket:

A kontextusmérnökség a gyakorlatban: eldönteni, hogy a rendelkezésre álló információk (dokumentumok, eszközkimenetek, korábbi körök) mely részhalmaza tartozik valójában ebbe a hívásba; kiválasztani, hogy a promptban hol helyezkedjen el, mivel a pozíció befolyásolja, hogyan súlyozza azt a modell; olyan összesűrítési vagy összefoglalási lépéseket írni, amelyek megakadályozzák, hogy egy hosszú eszköznyomkövetés felfalja az egész keretet; és ezt feladatonként hangolni, mivel egy hibakereső agent és egy szövegíró agent más kontextusformát kíván, még ugyanazon az alapmodellen is.

A memóriamérnökség a gyakorlatban: írási szabályzat meghatározása (mi érdemes megőrzésre egy munkamenet után — nem minden); tárolási réteg kiválasztása (vektortár, strukturált adatbázis, egyszerű fájlok, valamilyen hibrid), és őszinte szembenézés mindegyik kompromisszumaival; a lekérdezési stratégia felépítése, amely eldönti, mi kerül vissza és mikor; és folyamatos karbantartás — ritkítás, ismétlődő tények összevonása, ellentmondások kezelése, amikor a felhasználó meggondolja magát. Ez az utolsó rész, a karbantartás, az, amit a legtöbben kihagynak, mert nem látható addig, amíg az agent hetekig nem futott.

Látható, hogy az iparág kezdi strukturálisan is szétválasztani ezeket a szempontokat, nem csak fogalmilag. A Lenny's Newsletter bemutatója, amely egy hibakereső keretrendszer felépítését írja le a Claude Agent SDK-n, a jogosultságokat, az eszközadaptereket és az őket körülvevő "keretrendszert" saját, a benne futó promptolástól elkülönült mérnöki felületként kezeli — ugyanaz az ösztön, csak egy másik ponton alkalmazva. És a Google újabb Gemini API "Managed Agents" funkciói — háttérben történő végrehajtás, hitelesítő adatok frissítése interakciók között — valójában azt jelentik, hogy a platformszolgáltató is elismeri: a munkameneteken átnyúló, tartós állapot mára olyan infrastruktúra, amelyet meg kell tervezni, nem pusztán egy elég hosszú kontextusablak melléktermékét. Valakinek tulajdonosává kell válnia ennek a tervezésnek. Jelenleg sok csapatnál senki nem az, kifejezetten.

Miért fontos ez a munkaköri megnevezésed szempontjából, nem csak a kódod szempontjából

Ha karriered korai vagy középső szakaszában jársz, és az önéletrajzodban a "prompt engineer" vagy "AI engineer" cím szerepel, érdemes megkérdezned magadtól, hogy a kettő közül melyikre tudsz konkrét bizonyítékot felmutatni — mivel az általános AI-agent szerepek kezdenek szétválni specifikusabb szerepekre, ugyanúgy, ahogyan a "webmester" idővel frontendre, backendre és DevOpsra bomlott. Ez inkább óvatos feltételezés, mint szenzációs cím: nem láttam még kemény felvételi adatokat, amelyek megerősítenék, hogy a "memory engineer" önálló munkakörként létezik, ezért ezt inkább annak jeleként kezeld, hogy merre halad a munka, nem pedig olyan állításnak, hogy az álláshirdetések már így vannak rendszerezve. De az alapul szolgáló nyomás valós, és visszavezethető a fentebb tárgyalt összefoglalóra: az agent-csapatok egy konkrét, megnevezhető hibába futnak (több munkameneten át tartó leromlás), amelynek konkrét, megnevezhető oka van (két szakterület összemosása), és ez a kombináció szokott egy homályos szerepkört két éles szerepkörré alakítani.

A gyakorlatias lépés nem az, hogy kitalálj magadnak egy címet. Az a lényeg, hogy konkrétan tudj válaszolni arra, melyik problémát oldottad meg valójában. Szállítottál már olyat, ahol írási szabályzatot terveztél — egy szabályt arra, mit rögzít egy agent a memóriájában, és mit dob el? Hibakerestél már olyan lekérdezési határ menti hibát, amikor egy agentnek szüksége lett volna valamire a tárolóból, de vagy nem hívta le, vagy a rossz verziót hívta le? Ezek olyan ellenőrizhető állítások, amelyeket egy interjún elmondhatsz, alátámasztva egy repóval vagy egy utóvizsgálati jelentéssel, és olyasmit fejeznek ki, amit egy általános "jó promptokat írok" mondat nem: hogy érted a különbséget egyetlen válasz jobbá tétele és egy agent hosszú távú megbízhatóvá tétele között.

Egy figyelmeztetés

Ne nevezd át magad "memory engineerré" csak azért, hogy egyszer hozzáadtál egy vektoradatbázist egy projekthez. Az a szakterület, amelyre a kutatás rámutat, tartalmazza a kevésbé csillogó felét is — a karbantartást, a lejáratást, az ellentmondások kezelését —, és éppen ez a fele az, amely valójában megakadályozza a fentebb leírt hibamintázatot. Ha a portfóliódarabod egy olyan rendszer, amely ír a memóriába, de semmit soha nem ritkítanak vagy javítanak ki, akkor csak a memory engineer munkájának a felét végezted el, és a "harmadik munkamenet után elromlik" probléma még ott vár rád a másik felén.