"Prompt engineer" var aldrig en præcis jobtitel, men i en periode behøvede den ikke at være det. Hvis hele dit job bestod i at få ét godt svar ud af ét enkelt inferenskald, dækkede ét sæt færdigheder det: formuler instruktionen godt, giv et par eksempler, tilføj måske noget hentet tekst, færdig. Det færdighedssæt betyder stadig noget. Men det dækker ikke længere, hvad "at bygge en agent" betyder i midten af 2026, og kløften viser sig som en specifik, genkendelig fejltype: agenter der fungerer glimrende i en demo og derefter langsomt forringes, modsiger sig selv eller glemmer, hvad brugeren fortalte dem to sessioner tidligere.

Et nyere indlæg fra Machine Learning Mastery navngiver kløften direkte, og det er værd at dvæle ved, fordi det passer præcist på to forskellige jobs, man rent faktisk kunne blive ansat til at udføre. Context engineering er det, der sker inden i ét enkelt inferenskald: at afgøre, hvad der skal ind i konteksten (context window), hvor det skal placeres strukturelt, og hvad der skal komprimeres eller udelades, så modellen ikke drukner i irrelevante tokens. Memory engineering er et andet problem, der kun findes på tværs af kald: hvad der skrives ned, efter en session slutter, hvor det opbevares, hvordan det hentes frem næste gang, og hvordan det vedligeholdes (opdateres, dubletter fjernes, udløber), så det ikke rådner. Ifølge indlægget kan de fejl, der opstår i lange, flersessions-agentworkflows, oftest spores tilbage til, at man sammenblander disse to opgaver, eller springer en af dem over — særligt ved det, de kalder "retrieval-grænsen" (retrieval boundary), det øjeblik hvor en agent skal afgøre, om noget den har brug for, allerede ligger foran den, eller skal hentes fra lageret.

Hvorfor sammenblandingen er den egentlige fejl, ikke en detalje

Tænk på, hvad hver disciplin faktisk optimerer for. Context engineering optimerer et enkelt, afgrænset og engangs-vindue — få det rette udsnit af information foran modellen lige nu, til denne ene udveksling, og smid resten væk bagefter. Memory engineering optimerer et varigt lager, der skal overleve på tværs af sessioner, forblive konsistent efterhånden som ny information kommer til, og besvare et langt sværere spørgsmål: ikke "hvad er relevant for denne prompt", men "hvad er overhovedet værd at gemme, og hvor længe."

Det er forskellige designproblemer med forskellige fejltyper. En fejl i context engineering gør ét svar ringere. En fejl i memory engineering hober sig op — dårlige skrivninger akkumuleres, forældede fakta hentes frem, som var de aktuelle, og ingen opdager det, før agenten selvsikkert gentager noget, der blev rettet tre sessioner tidligere. Hvis én person (eller én promptskabelon) i det stille udfører begge opgaver uden at skelne mellem dem, har hukommelseslaget en tendens til at arve vaner fra context engineering, som det ikke bør have: at overfylde lageret, ligesom man ville overfylde et vindue, eller at behandle retrieval som et relevans-rangeringsproblem, når det i virkeligheden er et kuraterings- og vedligeholdelsesproblem. Det er den sammenblanding, forskningsresuméet peger på, og det stemmer overens med noget, praktikere allerede beskriver anekdotisk: agenter, der er imponerende i én session og upålidelige ved session fem.

Hvordan hvert job faktisk ser ud i hverdagen

Hvis du prøver at finde ud af, hvilket af disse to du allerede udfører, eller hvilket du gerne vil bygge dig hen imod, adskiller det daglige arbejde sig nok til, at man kan kende forskel:

Context engineering i praksis: at afgøre, hvilken delmængde af tilgængelig information (dokumenter, tool-output, tidligere replikker) der reelt hører hjemme i dette kald; at vælge, hvor i prompten den skal placeres, eftersom placeringen påvirker, hvor meget vægt modellen lægger på den; at skrive komprimerings- eller opsummeringstrin, så en lang tool-trace ikke æder hele budgettet; og at tilpasse dette efter opgave, eftersom en debugging-agent og en skrivende agent ønsker forskellige kontekstformer, selv på den samme underliggende model.

Memory engineering i praksis: at definere en skrivepolitik (hvad er værd at bevare, efter en session slutter — ikke alt er det); at vælge et lagringslag (en vektor-database, en struktureret database, almindelige filer, en hybrid) og være ærlig om afvejningerne ved hver; at bygge den retrieval-strategi, der afgør, hvad der kommer frem igen, og hvornår; og at udføre løbende vedligeholdelse — beskæring, sammenlægning af dubletfakta, håndtering af modsigelser, når brugeren skifter mening. Den sidste del, vedligeholdelsen, er den folk oftest springer over, fordi den ikke er synlig, før en agent har kørt i ugevis.

Man kan se branchen begynde at adskille disse hensyn strukturelt, ikke bare begrebsmæssigt. Lenny's Newsletters gennemgang af, hvordan man bygger en debugging-harness på Claude Agent SDK, behandler tilladelser, tool-adaptere og den omkringliggende "harness" som deres egen ingeniørflade, adskilt fra promptingen indeni — samme instinkt, blot anvendt på en anden søm. Og Googles nyere Gemini API-funktioner til "Managed Agents" — baggrundskørsel, fornyelse af legitimationsoplysninger på tværs af interaktioner — er reelt platformsleverandøren, der indrømmer, at sessionsvarende tilstand nu er infrastruktur, der skal designes, ikke en sidegevinst af et tilstrækkeligt langt kontekstvindue. Nogen må eje det design. Lige nu er der på mange teams ingen, der eksplicit gør det.

Hvorfor det betyder noget for din jobtitel, ikke kun din kode

Hvis du er tidligt eller midt i din karriere, og "prompt engineer" eller "AI engineer" står på dit CV, er det værd at spørge, hvilket af disse to jobs du rent faktisk kan pege på beviser for at have udført — for generalist-AI-agentroller er ved at blive trukket fra hinanden til mere specifikke roller, ligesom "webmaster" til sidst blev delt op i frontend, backend og DevOps. Det er en forbeholdsafvejning, ikke en overskrift: Jeg har endnu ikke set hårde ansættelsesdata, der bekræfter "memory engineer" som en selvstændig titel, så betragt dette som et bud på, hvor arbejdet er på vej hen, ikke en påstand om, at jobopslag allerede er sorteret sådan. Men det underliggende pres er reelt og kan spores til resuméet ovenfor: agentteams støder på en specifik, navngivelig fejl (forringelse på tværs af sessioner), som har en specifik, navngivelig årsag (sammenblanding af to discipliner), og den kombination er normalt det, der forvandler en uklar rolle til to skarpe.

Det praktiske skridt er ikke at opfinde en titel til dig selv. Det er at kunne svare konkret på, hvilket problem du rent faktisk har løst. Har du leveret noget, hvor du designede en skrivepolitik — en regel for, hvad en agent gemmer i hukommelsen, og hvad den kasserer? Har du fejlrettet en retrieval-grænsefejl, hvor en agent havde brug for noget fra lageret og enten ikke hentede det, eller hentede den forkerte version? Det er efterprøvelige påstande, du kan fremsætte til en jobsamtale, understøttet af et repo eller en postmortem, og de siger noget, et generisk "jeg skriver gode prompts" ikke gør: at du forstår forskellen på at gøre ét svar bedre og at gøre en agent troværdig over tid.

En advarsel

Omdøb ikke dig selv til "memory engineer", fordi du én gang har tilføjet en vektor-database til et projekt. Den disciplin, forskningen peger på, omfatter den mindre glamourøse halvdel — vedligeholdelse, udløb, håndtering af modsigelser — og det er den halvdel, der rent faktisk forhindrer den fejltype, der er beskrevet ovenfor. Hvis dit porteføljestykke er et system, der skriver til hukommelsen, men hvor intet nogensinde bliver beskåret eller rettet, har du bygget halvdelen af en memory engineers job, og problemet med at fejle efter session tre venter stadig på dig i den anden halvdel.