„Prompt engineer” nu a fost niciodată un titlu de post precis, dar o vreme nici nu a fost nevoie să fie. Dacă întreaga ta muncă însemna să obții un singur răspuns bun dintr-un singur apel de inferență, un singur set de competențe era suficient: formulează bine instrucțiunea, oferă câteva exemple, adaugă poate niște text recuperat, gata. Acel set de competențe încă contează. Dar nu mai acoperă ce înseamnă „construirea unui agent” la mijlocul lui 2026, iar diferența se manifestă printr-un tipar de eșec specific și ușor de recunoscut: agenți care funcționează excelent într-o demonstrație și apoi se degradează pe tăcute, se contrazic sau uită ce le-a spus utilizatorul cu două sesiuni în urmă.

Un articol recent de la Machine Learning Mastery denumește direct această diferență și merită să ne oprim asupra lui, pentru că se suprapune clar peste două meserii distincte pentru care ai putea fi efectiv angajat. Context engineering este ceea ce se întâmplă în interiorul unui singur apel de inferență: a decide ce intră în fereastra de context, unde anume se plasează structural și ce este comprimat sau eliminat pentru ca modelul să nu se înece în tokeni irelevanți. Memory engineering este o problemă diferită, care există doar între apeluri succesive: ce se consemnează după încheierea unei sesiuni, unde se stochează, cum este recuperat data următoare și cum este întreținut (actualizat, deduplicat, expirat) pentru a nu se degrada. Potrivit articolului respectiv, eșecurile care apar în fluxurile de lucru lungi, cu mai multe sesiuni, ale agenților își au originea cel mai adesea în confundarea acestor două sarcini sau în omiterea uneia dintre ele — mai ales la ceea ce ei numesc „granița de recuperare” (retrieval boundary), momentul în care un agent trebuie să decidă dacă ceva de care are nevoie se află deja în fața lui sau trebuie preluat din stocare.

De ce confundarea celor două este chiar bug-ul, nu un detaliu

Gândește-te ce optimizează, de fapt, fiecare disciplină. Ingineria contextului optimizează o singură fereastră, limitată și de unică folosință — pune felia potrivită de informație în fața modelului chiar acum, pentru acest schimb de mesaje, apoi aruncă restul. Ingineria memoriei optimizează un depozit durabil, care trebuie să supraviețuiască între sesiuni, să rămână consecvent pe măsură ce apar informații noi și să răspundă la o întrebare mult mai grea: nu „ce este relevant pentru acest prompt”, ci „ce merită păstrat deloc și pentru cât timp”.

Acestea sunt probleme de proiectare diferite, cu moduri de eșec diferite. O greșeală de inginerie a contextului strică un singur răspuns. O greșeală de inginerie a memoriei se acumulează — scrierile proaste se adună, faptele expirate sunt recuperate de parcă ar fi actuale, iar nimeni nu observă până când agentul repetă cu încredere ceva ce fusese corectat cu trei sesiuni în urmă. Dacă o singură persoană (sau un singur șablon de prompt) face pe ascuns ambele meserii fără să le distingă, stratul de memorie tinde să moștenească obiceiuri din ingineria contextului pe care nu ar trebui să le aibă: supraîncărcarea stocării așa cum ai supraîncărca o fereastră, sau tratarea recuperării ca pe o problemă de clasare după relevanță, când de fapt este o problemă de curatoriere și întreținere. Aceasta este confuzia spre care arată sinteza de cercetare, și se potrivește cu ceva ce practicienii descriu deja anecdotic: agenți impresionanți într-o singură sesiune și nesiguri până la a cincea sesiune.

Cum arată de fapt fiecare meserie, zi de zi

Dacă încerci să-ți dai seama pe care dintre ele o faci deja sau spre care ai vrea să te îndrepți, munca de zi cu zi arată suficient de diferit încât să le poți deosebi:

Ingineria contextului, în practică: a decide ce subset din informația disponibilă (documentație, ieșiri ale uneltelor, ture anterioare) chiar aparține acestui apel; a alege unde în prompt se plasează, pentru că poziția influențează cum îl ponderează modelele; a scrie pași de comprimare sau rezumare pentru ca o urmă lungă a unei unelte să nu consume tot bugetul; și a regla acest lucru per sarcină, întrucât un agent de depanare și un agent de scriere au nevoie de forme de context diferite chiar și pe același model de bază.

Ingineria memoriei, în practică: a defini o politică de scriere (ce merită păstrat după o sesiune — nu totul merită); a alege un strat de stocare (o bază vectorială, o bază de date structurată, fișiere simple, vreun hibrid) și a fi onest în privința compromisurilor fiecăruia; a construi strategia de recuperare care decide ce iese înapoi și când; și a face întreținere continuă — eliminarea informațiilor vechi, contopirea faptelor duplicate, gestionarea contradicțiilor când utilizatorul se răzgândește. Acea ultimă parte, întreținerea, este cea pe care oamenii o omit cel mai adesea, pentru că nu este vizibilă până când un agent nu a rulat săptămâni întregi.

Se poate observa că industria începe să separe aceste preocupări structural, nu doar conceptual. Ghidul din Lenny's Newsletter despre construirea unui harnas de depanare pe Claude Agent SDK tratează permisiunile, adaptoarele pentru unelte și „harnasul” din jur ca pe o suprafață de inginerie proprie, distinctă de prompting-ul din interiorul lui — același instinct, aplicat pe o altă cusătură. Iar funcțiile mai noi „Managed Agents” din API-ul Gemini al Google — execuție în fundal, reînnoirea acreditărilor între interacțiuni — reprezintă practic recunoașterea, din partea furnizorului de platformă, a faptului că starea persistentă între sesiuni este acum infrastructură care trebuie proiectată, nu un efect secundar al unei ferestre de context suficient de lungi. Cineva trebuie să-și asume acea proiectare. În prezent, în multe echipe, nimeni nu o face în mod explicit.

De ce contează asta pentru titlul postului tău, nu doar pentru codul tău

Dacă ești la început de carieră sau la mijlocul ei și ai „prompt engineer” sau „AI engineer” pe CV, merită să te întrebi pentru care dintre aceste două meserii poți arăta efectiv dovezi — pentru că rolurile generaliste de agent AI încep să se despartă în roluri mai specifice, la fel cum „webmaster” s-a despărțit până la urmă în frontend, backend și DevOps. Aceasta este o rezervă, nu un titlu de senzație: încă nu am văzut date concrete de angajare care să confirme „memory engineer” ca titlu de sine stătător, așa că tratează asta ca pe o citire a direcției în care se îndreaptă munca, nu ca pe o afirmație că anunțurile de angajare sunt deja organizate așa. Dar presiunea de fond este reală și poate fi urmărită până la sinteza de mai sus: echipele de agenți se lovesc de un eșec specific, care poate fi numit (degradarea pe mai multe sesiuni) și care are o cauză specifică, care poate fi numită (confundarea a două discipline), iar această combinație este de obicei ceea ce transformă un rol neclar în două roluri bine definite.

Mișcarea practică nu este să-ți inventezi un titlu. Este să poți răspunde, concret, la ce problemă ai rezolvat de fapt. Ai livrat vreodată ceva pentru care ai proiectat o politică de scriere — o regulă pentru ce consemnează un agent în memorie și ce aruncă? Ai depanat vreodată un eșec la granița de recuperare, în care un agent avea nevoie de ceva din stocare și fie nu l-a preluat, fie a preluat versiunea greșită? Acestea sunt afirmații verificabile pe care le poți face la un interviu, susținute de un repo sau de o analiză post-mortem, și spun ceva ce un generic „scriu prompturi bune” nu spune: că înțelegi diferența dintre a face un răspuns mai bun și a face un agent demn de încredere în timp.

O avertizare

Nu te reeticheta drept „memory engineer” doar pentru că ai adăugat cândva o bază de date vectorială într-un proiect. Disciplina spre care arată cercetarea include și jumătatea neatrăgătoare — întreținere, expirare, gestionarea contradicțiilor — și aceasta este jumătatea care chiar previne tiparul de eșec descris mai sus. Dacă piesa ta de portofoliu este un sistem care scrie în memorie, dar nimic nu este vreodată eliminat sau corectat, ai construit doar jumătate din meseria unui inginer de memorie, iar problema eșecului după a treia sesiune te așteaptă în continuare în cealaltă jumătate.