«Prompt engineer» har aldri vært en presis stillingstittel, men en stund var det ikke nødvendig. Hvis hele jobben din var å få ett godt svar ut av ett enkelt inferens-kall, dekket ett ferdighetssett hele saken: formuler instruksjonen godt, gi et par eksempler, kanskje legg til noe hentet tekst, ferdig. Det ferdighetssettet betyr fortsatt noe. Men det dekker ikke lenger hva «å bygge en agent» innebærer medio 2026, og gapet viser seg som et bestemt, gjenkjennelig feilmønster: agenter som fungerer strålende i en demo og deretter stille forringes, motsier seg selv, eller glemmer hva brukeren fortalte dem to økter tidligere.

Et fersk innlegg fra Machine Learning Mastery navngir dette gapet direkte, og det er verdt å dvele ved fordi det stemmer godt overens med to forskjellige jobber du faktisk kunne blitt ansatt for å gjøre. Context engineering er det som skjer inne i ett enkelt inferens-kall: å avgjøre hva som skal inn i kontekstvinduet, hvor det plasseres strukturelt, og hva som skal komprimeres eller fjernes slik at modellen ikke drukner i irrelevante tokens. Memory engineering er et annet problem som bare finnes på tvers av kall: hva som skrives ned etter at en økt avsluttes, hvor det lagres, hvordan det hentes frem neste gang, og hvordan det vedlikeholdes (oppdateres, dupliseres bort, utløper) slik at det ikke råtner. Ifølge innlegget kan feilene som dukker opp i lange, flerøkts agent-arbeidsflyter oftest spores tilbake til at disse to jobbene blandes sammen, eller at man hopper over en av dem — særlig ved det de kaller «hentegrensen» («the retrieval boundary»), øyeblikket der en agent må avgjøre om noe den trenger allerede ligger foran den, eller må hentes fra lagring.

Hvorfor sammenblandingen er selve feilen, ikke bare en detalj

Tenk på hva hver disiplin optimaliserer for. Context engineering optimaliserer et enkelt, avgrenset, engangsvindu — få riktig informasjonsutsnitt foran modellen akkurat nå, for denne ene utvekslingen, og kast så resten. Memory engineering optimaliserer et varig lager som må overleve på tvers av økter, forbli konsistent etter hvert som ny informasjon kommer inn, og besvare et mye vanskeligere spørsmål: ikke «hva er relevant for denne prompten», men «hva er overhodet verdt å beholde, og hvor lenge».

Dette er ulike designproblemer med ulike feilmønstre. En context-engineering-feil gjør ett svar dårligere. En memory-engineering-feil forsterker seg over tid — dårlige skrivninger hoper seg opp, utdaterte fakta hentes frem som om de var aktuelle, og ingen legger merke til det før agenten selvsikkert gjentar noe som ble korrigert tre økter tidligere. Hvis én person (eller én prompt-mal) stille gjør begge jobbene uten å skille mellom dem, har minnelaget en tendens til å arve context-engineering-vaner det ikke burde ha: å overfylle lageret slik man ville overfylt et vindu, eller å behandle henting som et relevans-rangeringsproblem når det egentlig er et kuraterings- og vedlikeholdsproblem. Det er denne sammenblandingen forskningsoppsummeringen peker på, og det stemmer overens med noe utøvere allerede beskriver anekdotisk: agenter som er imponerende i én økt og upålitelige innen økt fem.

Hvordan hver jobb faktisk ser ut i praksis

Hvis du prøver å finne ut hvilken av disse du allerede driver med, eller hvilken du ønsker å bygge deg mot, er det daglige arbeidet forskjellig nok til at man kan skille dem fra hverandre:

Context engineering, i praksis: å avgjøre hvilken delmengde av tilgjengelig informasjon (dokumenter, verktøyresultater, tidligere replikker) som faktisk hører hjemme i dette kallet; å velge hvor i prompten det plasseres, siden posisjon påvirker hvor mye vekt modellene legger på det; å skrive komprimerings- eller oppsummeringssteg slik at et langt verktøyspor ikke spiser opp hele budsjettet; og å justere dette per oppgave, siden en feilsøkingsagent og en skriveagent ønsker ulike konteksformer selv med samme underliggende modell.

Memory engineering, i praksis: å definere en skrivepolicy (hva som er verdt å ta vare på etter en økt — ikke alt er det); å velge et lagringslag (en vektordatabase, en strukturert database, rene filer, en eller annen hybrid) og være ærlig om avveiningene ved hver av dem; å bygge hentestrategien som avgjør hva som kommer tilbake ut og når; og å drive løpende vedlikehold — beskjære, slå sammen dupliserte fakta, håndtere motsigelser når brukeren ombestemmer seg. Den siste delen, vedlikehold, er den folk oftest hopper over, fordi den ikke er synlig før en agent har kjørt i flere uker.

Man kan se at bransjen begynner å skille disse hensynene strukturelt, ikke bare begrepsmessig. Lenny's Newsletters gjennomgang av å bygge en feilsøkingsrigg på Claude Agent SDK behandler tillatelser, verktøyadaptere og den omkringliggende «riggen» som en egen ingeniørflate atskilt fra selve promptingen inni den — samme instinkt, anvendt på en annen skjøt. Og Googles nyere «Managed Agents»-funksjoner i Gemini API — bakgrunnskjøring, fornyelse av påloggingsinformasjon på tvers av interaksjoner — er i praksis plattformleverandøren som innrømmer at øktvarig tilstand nå er infrastruktur som må designes, ikke en bieffekt av et langt nok kontekstvindu. Noen må eie det designet. Akkurat nå er det, i mange team, ingen som eksplisitt gjør det.

Hvorfor dette betyr noe for stillingstittelen din, ikke bare koden din

Hvis du er tidlig i eller midt i karrieren og «prompt engineer» eller «AI engineer» står på CV-en, er det verdt å spørre hvilken av disse to jobbene du faktisk kan vise til konkrete bevis på å ha utført — for generalist-roller innen AI-agenter begynner å bli splittet opp i mer spesifikke roller, på samme måte som «webmaster» til slutt ble delt opp i frontend, backend og DevOps. Det er en forbeholdsklausul, ikke en overskrift: jeg har ikke sett harde ansettelsesdata som bekrefter «memory engineer» som en selvstendig tittel ennå, så betrakt dette som en lesning av hvor arbeidet er på vei, ikke en påstand om at stillingsannonser allerede er sortert slik. Men det underliggende presset er reelt og kan spores til oppsummeringen nevnt over: agent-team støter på en bestemt, navngivbar feil (forringelse over flere økter) som har en bestemt, navngivbar årsak (sammenblanding av to disipliner), og den kombinasjonen er vanligvis det som gjør en uklar rolle om til to skarpe.

Det praktiske grepet er ikke å finne opp en tittel til deg selv. Det er å kunne svare konkret på hvilket problem du faktisk har løst. Har du levert noe der du designet en skrivepolicy — en regel for hva en agent forplikter seg til å lagre i minnet, og hva den forkaster? Har du feilsøkt en hentegrense-feil, der en agent trengte noe fra lagring og enten ikke hentet det, eller hentet feil versjon? Dette er sjekkbare påstander du kan gjøre i et intervju, underbygget av et repo eller en postmortem, og de sier noe et generisk «jeg skriver gode prompter» ikke gjør: at du forstår forskjellen mellom å gjøre ett svar bedre og å gjøre en agent pålitelig over tid.

En advarsel

Ikke omdøp deg selv til «memory engineer» på grunnlag av å ha lagt til en vektordatabase i et prosjekt én gang. Disiplinen forskningen peker på inkluderer den mindre glamorøse halvdelen — vedlikehold, utløp, håndtering av motsigelser — og det er den halvdelen som faktisk forhindrer feilmønsteret beskrevet over. Hvis porteføljestykket ditt er et system som skriver til minnet, men der ingenting noensinne blir beskåret eller korrigert, har du bygget halvparten av en memory engineers jobb, og problemet med å svikte etter tredje økt venter fortsatt på deg på den andre halvdelen.