„Prompt inženjer" nikada nije bio precizan naziv radnog mesta, ali neko vreme to nije ni bilo potrebno. Ako je ceo vaš posao bio da iz jednog poziva modela izvučete jedan dobar odgovor, jedan skup veština je to pokrivao: dobro formulišite uputstvo, dodajte par primera, možda ubacite malo preuzetog teksta, gotovo. Taj skup veština je i dalje bitan. Ali on više ne pokriva ono što „izgradnja agenta" znači sredinom 2026. godine, a taj jaz se ispoljava kao specifičan, prepoznatljiv obrazac otkazivanja: agenti koji sjajno rade na demou, a zatim tiho degradiraju, protivreče sami sebi ili zaboravljaju šta im je korisnik rekao pre dve sesije.

Nedavni tekst sa sajta Machine Learning Mastery direktno imenuje taj jaz, i vredi se zadržati na njemu jer se jasno preslikava na dva različita posla za koje biste zapravo mogli biti angažovani. Inženjering konteksta je ono što se dešava unutar jednog poziva modela: odlučivanje šta ulazi u prozor konteksta, gde se to strukturno postavlja i šta se komprimuje ili izbacuje kako model ne bi bio preplavljen nebitnim tokenima. Inženjering memorije je drugačiji problem koji postoji samo kroz više poziva: šta se beleži nakon završetka sesije, gde se to čuva, kako se dobija nazad sledeći put i kako se održava (ažurira, deduplicira, ističe) kako ne bi istrulelo. Prema tom tekstu, greške koje se javljaju u dugim, višesesijskim tokovima rada agenata najčešće vode poreklo od mešanja ova dva posla, ili preskakanja jednog od njih — naročito na onome što nazivaju „granicom pretraživanja" (retrieval boundary), trenutku kada agent mora da odluči da li se nešto što mu treba nalazi ispred njega ili mora biti dohvaćeno iz skladišta.

Zašto je njihovo mešanje zapravo greška, a ne detalj

Razmislite šta svaka od ovih disciplina zapravo optimizuje. Inženjering konteksta optimizuje jedan, ograničen, jednokratan prozor — postaviti pravi isečak informacija ispred modela upravo sada, za ovu jednu razmenu, a zatim odbaciti ostalo. Inženjering memorije optimizuje trajno skladište koje mora da preživi kroz više sesija, ostane dosledno kako pristižu nove informacije, i odgovori na mnogo teže pitanje: ne „šta je relevantno za ovaj prompt", već „šta uopšte vredi sačuvati, i na koliko dugo".

To su različiti problemi dizajna sa različitim obrascima otkazivanja. Greška u inženjeringu konteksta pogorša jedan odgovor. Greška u inženjeringu memorije se gomila — loši upisi se akumuliraju, zastarele činjenice se dohvataju kao da su aktuelne, i niko to ne primećuje sve dok agent samouvereno ne ponovi nešto što je ispravljeno pre tri sesije. Ako jedna osoba (ili jedan šablon prompta) tiho obavlja oba posla ne praveći razliku između njih, sloj memorije obično nasleđuje navike iz inženjeringa konteksta koje mu ne bi trebalo — prepunjavanje skladišta na način na koji biste prepunili prozor, ili tretiranje pretraživanja kao problema rangiranja po relevantnosti, kada je to zapravo problem kuriranja i održavanja. To je mešanje na koje ukazuje istraživački pregled, i to se poklapa sa nečim što praktičari već opisuju anegdotski: agenti koji su impresivni u jednoj sesiji, a nepouzdani do pete sesije.

Kako svaki od ovih poslova zapravo izgleda iz dana u dan

Ako pokušavate da shvatite koji od ovih poslova već obavljate, ili koji biste želeli da razvijate, svakodnevni rad se dovoljno razlikuje da se to može razaznati:

Inženjering konteksta, u praksi: odlučivanje koji podskup dostupnih informacija (dokumentacija, izlazi alata, prethodni koraci) zaista pripada ovom pozivu; biranje gde u promptu to ide, jer pozicija utiče na to koliku težinu model tome pridaje; pisanje koraka za kompresiju ili sumarizaciju kako dug trag rada alata ne bi pojeo ceo budžet; i podešavanje ovoga po zadatku, jer agent za otklanjanje grešaka i agent za pisanje žele različite oblike konteksta čak i na istom osnovnom modelu.

Inženjering memorije, u praksi: definisanje politike upisa (šta vredi sačuvati nakon sesije — ne vredi baš sve); biranje sloja za skladištenje (vektorska baza, strukturirana baza podataka, obični fajlovi, neki hibrid) i iskreno sagledavanje kompromisa svakog od njih; izgradnja strategije pretraživanja koja određuje šta se vraća i kada; i tekuće održavanje — čišćenje, spajanje dupliranih činjenica, rešavanje protivrečnosti kada korisnik promeni mišljenje. Taj poslednji deo, održavanje, jeste onaj koji ljudi najčešće preskaču, jer nije vidljiv sve dok agent ne radi nedeljama.

Može se videti kako industrija počinje strukturno, a ne samo konceptualno, da razdvaja ove nadležnosti. Vodič lista Lenny's Newsletter o izgradnji sistema za otklanjanje grešaka na Claude Agent SDK-u tretira dozvole, adaptere alata i okružujući „harness" kao sopstvenu inženjersku površinu, odvojenu od promptovanja unutar njega — isti instinkt, primenjen na drugi šav. A noviji Gemini API funkcije „Managed Agents" kompanije Google — izvršavanje u pozadini, obnavljanje akreditiva kroz interakcije — zapravo predstavljaju priznanje samog dobavljača platforme da je stanje koje traje kroz sesije sada infrastruktura koja mora biti dizajnirana, a ne sporedni efekat dovoljno dugog prozora konteksta. Neko mora da preuzme vlasništvo nad tim dizajnom. Trenutno, u mnogim timovima, to niko eksplicitno ne radi.

Zašto je ovo bitno za naziv vašeg radnog mesta, ne samo za vaš kod

Ako ste na početku ili sredini karijere i „prompt inženjer" ili „AI inženjer" vam stoji u biografiji, vredi se zapitati za koji od ova dva posla zapravo možete da pružite dokaz da ga obavljate — jer se generalističke uloge AI-agent inženjera počinju cepati na specifičnije, na isti način na koji se „vebmaster" na kraju podelio na frontend, bekend i DevOps. To je ograda, a ne senzacionalna vest: još nisam video čvrste podatke o zapošljavanju koji potvrđuju „inženjer memorije" kao samostalan naziv radnog mesta, pa ovo shvatite kao naznaku ka čemu posao ide, a ne kao tvrdnju da su oglasi za posao već tako sortirani. Ali osnovni pritisak je stvaran i može se pratiti do pomenutog pregleda: timovi koji rade na agentima nailaze na specifičan, imenjiv problem (degradacija kroz više sesija) koji ima specifičan, imenjiv uzrok (mešanje dve discipline), a ta kombinacija je obično ono što nejasnu ulogu pretvara u dve jasne.

Praktičan potez nije da sami sebi izmislite naziv. Radi se o tome da možete konkretno da odgovorite koji ste problem zapravo rešili. Da li ste isporučili nešto gde ste dizajnirali politiku upisa — pravilo o tome šta agent trajno beleži u memoriju, a šta odbacuje? Da li ste otklonili grešku na granici pretraživanja, gde je agentu bilo potrebno nešto iz skladišta, a on to ili nije dohvatio, ili je dohvatio pogrešnu verziju? To su tvrdnje koje se mogu proveriti i koje možete izneti na razgovoru za posao, potkrepljene repozitorijumom ili post-mortem analizom, i one govore nešto što generičko „pišem dobre promptove" ne govori: da razumete razliku između toga da jedan odgovor bude bolji i toga da agent tokom vremena bude pouzdan.

Upozorenje

Nemojte sebe preimenovati u „inženjera memorije" samo zato što ste jednom u projekat dodali vektorsku bazu podataka. Disciplina na koju ukazuje istraživanje uključuje i onu manje glamuroznu polovinu — održavanje, isticanje, rešavanje protivrečnosti — i to je upravo ta polovina koja zaista sprečava gore opisani obrazac otkazivanja. Ako je vaš primer iz portfolija sistem koji upisuje u memoriju, ali se ništa nikada ne čisti niti ispravlja, izgradili ste samo pola posla inženjera memorije, a problem otkazivanja posle treće sesije i dalje vas čeka na drugoj polovini.