"Prompt engineer" var aldrig en exakt jobbtitel, men ett tag behövde den inte vara det. Om hela jobbet gick ut på att få fram ett enda bra svar från ett enda inferensanrop, räckte en enda uppsättning färdigheter: formulera instruktionen väl, ge ett par exempel, lägg kanske till lite hämtad text, klart. Den kompetensen spelar fortfarande roll. Men den täcker inte längre vad "att bygga en agent" innebär i mitten av 2026, och glappet visar sig som ett specifikt, igenkännbart felmönster: agenter som fungerar utmärkt i en demo men sedan tyst försämras, motsäger sig själva, eller glömmer vad användaren berättade för dem två sessioner tidigare.

En färsk artikel från Machine Learning Mastery sätter fingret direkt på detta glapp, och det är värt att stanna upp vid, eftersom det tydligt motsvarar två olika jobb man faktiskt skulle kunna bli anställd för att göra. Context engineering är det som sker inom ett enda inferensanrop: att avgöra vad som ska in i kontextfönstret, var det ska placeras strukturellt, och vad som ska komprimeras eller tas bort så att modellen inte dränks i irrelevanta tokens. Memory engineering är ett annat problem som bara existerar mellan anrop: vad som skrivs ner efter att en session avslutats, var det lagras, hur det hämtas nästa gång, och hur det underhålls (uppdateras, dedupliceras, får utgångsdatum) så att det inte förfaller. Enligt artikeln beror de fel som uppstår i långa agent-arbetsflöden med flera sessioner oftast på att man blandar ihop dessa två uppgifter, eller hoppar över en av dem — särskilt vid det de kallar "hämtningsgränsen" ("retrieval boundary"), det ögonblick då en agent måste avgöra om något den behöver redan finns framför den eller måste hämtas från lagring.

Varför sammanblandningen är den egentliga buggen, inte en detalj

Tänk på vad respektive disciplin optimerar för. Context engineering optimerar ett enda, avgränsat, engångsfönster — få rätt informationsskiva framför modellen just nu, för just den här utväxlingen, och släng sedan resten. Memory engineering optimerar en varaktig lagring som måste överleva mellan sessioner, hålla sig konsekvent när ny information tillkommer, och besvara en mycket svårare fråga: inte "vad är relevant för den här prompten" utan "vad är överhuvudtaget värt att behålla, och hur länge."

Det här är olika designproblem med olika felmönster. Ett misstag inom context engineering gör ett enda svar sämre. Ett misstag inom memory engineering ackumuleras — dåliga skrivningar hopar sig, föråldrade fakta hämtas som om de vore aktuella, och ingen märker det förrän agenten självsäkert upprepar något som rättades till för tre sessioner sedan. Om en enda person (eller en enda promptmall) tyst sköter båda jobben utan att skilja dem åt, tenderar minneslagret att ärva vanor från context engineering som det inte borde: att proppa lagringen full på samma sätt som man proppar ett fönster fullt, eller att behandla hämtning som ett relevansrankningsproblem när det egentligen är ett kuraterings- och underhållsproblem. Det är den sammanblandningen forskningssammanfattningen pekar på, och den stämmer överens med något utövare redan beskriver anekdotiskt: agenter som är imponerande under en enda session och opålitliga vid session fem.

Hur respektive jobb faktiskt ser ut i vardagen

Om du försöker räkna ut vilket av dessa du redan gör, eller vilket du vill bygga dig mot, ser vardagsarbetet tillräckligt olika ut för att man ska kunna skilja dem åt:

Context engineering, i praktiken: att avgöra vilken delmängd av tillgänglig information (dokument, verktygsutdata, tidigare turer) som faktiskt hör hemma i just detta anrop; att välja var i prompten den ska placeras, eftersom position påverkar hur modeller viktar den; att skriva komprimerings- eller sammanfattningssteg så att ett långt verktygsspår inte äter upp hela budgeten; och att finjustera detta per uppgift, eftersom en felsökningsagent och en skrivagent vill ha olika kontextformer även med samma underliggande modell.

Memory engineering, i praktiken: att definiera en skrivpolicy (vad som är värt att bevara efter en session — allt är det inte); att välja ett lagringslager (en vektordatabas, en strukturerad databas, vanliga filer, någon hybrid) och vara ärlig om avvägningarna för vart och ett; att bygga hämtningsstrategin som avgör vad som kommer tillbaka ut och när; och att sköta löpande underhåll — beskära, slå ihop dubbla fakta, hantera motsägelser när användaren ändrar sig. Den sista delen, underhåll, är den folk hoppar över oftast, eftersom den inte syns förrän en agent har körts i veckor.

Man kan se hur branschen börjar separera dessa frågor strukturellt, inte bara begreppsmässigt. Lenny's Newsletters genomgång av att bygga en felsökningsrigg ("harness") på Claude Agent SDK behandlar behörigheter, verktygsadaptrar och den omgivande "riggen" som en egen ingenjörsyta, skild från prompt-arbetet inuti den — samma instinkt, tillämpad på en annan skarv. Och Googles nyare "Managed Agents"-funktioner i Gemini API:et — bakgrundskörning, uppdatering av autentiseringsuppgifter mellan interaktioner — är i praktiken plattformsleverantören som medger att sessionsbeständigt tillstånd numera är infrastruktur som måste designas, inte en bieffekt av ett tillräckligt långt kontextfönster. Någon måste äga den designen. Just nu är det, på många team, ingen som uttryckligen gör det.

Varför detta spelar roll för din jobbtitel, inte bara din kod

Om du är tidigt eller mitt i karriären och har "prompt engineer" eller "AI engineer" på ditt CV, är det värt att fråga sig vilket av dessa två jobb du faktiskt kan visa bevis på att du utfört — för generalistiska AI-agentroller börjar dras isär till mer specifika sådana, på samma sätt som "webmaster" så småningom delades upp i frontend, backend och DevOps. Det är en reservation, inte en rubrik: jag har ännu inte sett hårda rekryteringsdata som bekräftar "memory engineer" som en fristående titel, så se det här som en läsning av vart arbetet är på väg, inte ett påstående om att jobbannonser redan är sorterade på det viset. Men det underliggande trycket är verkligt och går att spåra till sammanfattningen ovan: agentteam stöter på ett specifikt, namngivbart fel (försämring över flera sessioner) som har en specifik, namngivbar orsak (sammanblandning av två discipliner), och den kombinationen är oftast det som förvandlar en luddig roll till två skarpa.

Det praktiska draget är inte att uppfinna en titel åt dig själv. Det är att konkret kunna svara på vilket problem du faktiskt har löst. Har du levererat något där du designade en skrivpolicy — en regel för vad en agent sparar till minnet och vad den kastar? Har du felsökt ett fel vid hämtningsgränsen, där en agent behövde något från lagring men antingen inte hämtade det eller hämtade fel version? Det är kontrollerbara påståenden du kan göra i en intervju, styrkta av ett repo eller en efteranalys, och de säger något som ett generiskt "jag skriver bra prompter" inte gör: att du förstår skillnaden mellan att göra ett svar bättre och att göra en agent pålitlig över tid.

En varning

Kalla dig inte "memory engineer" bara för att du en gång lagt till en vektordatabas i ett projekt. Disciplinen forskningen pekar på omfattar den oglamorösa halvan — underhåll, utgångsdatum, hantering av motsägelser — och det är den halvan som faktiskt förhindrar felmönstret som beskrivs ovan. Om ditt portföljarbete är ett system som skriver till minnet men där ingenting någonsin beskärs eller rättas, har du byggt hälften av en memory engineers jobb, och problemet med att agenten fallerar efter session tre väntar fortfarande på dig på den andra halvan.