„Prompt engineer” nigdy nie był precyzyjnym tytułem stanowiska, ale przez jakiś czas nie musiał nim być. Jeśli cała twoja praca polegała na wydobyciu jednej dobrej odpowiedzi z jednego wywołania modelu, wystarczał jeden zestaw umiejętności: dobrze sformułować polecenie, dodać kilka przykładów, może dorzucić trochę pobranego tekstu i gotowe. Ten zestaw umiejętności wciąż ma znaczenie. Ale przestał obejmować to, co w połowie 2026 roku oznacza „budowanie agenta”, a ta luka objawia się konkretnym, rozpoznawalnym wzorcem awarii: agentami, które świetnie działają w demo, a potem po cichu się degradują, zaprzeczają same sobie albo zapominają, co użytkownik powiedział im dwie sesje wcześniej.

Niedawny artykuł z Machine Learning Mastery nazywa tę lukę wprost i warto się nad nim zatrzymać, bo pokrywa się on dokładnie z dwiema różnymi pracami, do których faktycznie mógłbyś zostać zatrudniony. Inżynieria kontekstu to coś, co dzieje się wewnątrz jednego wywołania modelu: decydowanie, co trafia do okna kontekstu, gdzie strukturalnie się to znajduje i co zostaje skompresowane albo odrzucone, żeby model nie tonął w nieistotnych tokenach. Inżynieria pamięci to inny problem, który istnieje wyłącznie pomiędzy wywołaniami: co zostaje zapisane po zakończeniu sesji, gdzie jest przechowywane, jak jest pobierane następnym razem i jak jest utrzymywane (aktualizowane, deduplikowane, wygaszane), żeby się nie zdezaktualizowało. Według tego artykułu, awarie pojawiające się w długich, wielosesyjnych przepływach pracy agentów najczęściej dają się sprowadzić do pomylenia tych dwóch zadań albo pominięcia jednego z nich – zwłaszcza w miejscu, które autorzy nazywają „granicą pobierania”, czyli momencie, gdy agent musi zdecydować, czy to, czego potrzebuje, jest już przed nim, czy trzeba to pobrać z pamięci.

Dlaczego mylenie ich to prawdziwy błąd, a nie szczegół

Zastanów się, co każda z tych dyscyplin optymalizuje. Inżynieria kontekstu optymalizuje pojedyncze, ograniczone, jednorazowe okno – ma umieścić właściwy wycinek informacji przed modelem właśnie teraz, na potrzeby tej jednej wymiany, a resztę odrzucić. Inżynieria pamięci optymalizuje trwały magazyn, który musi przetrwać między sesjami, pozostać spójny w miarę napływu nowych informacji i odpowiedzieć na dużo trudniejsze pytanie: nie „co jest istotne dla tego promptu”, tylko „co w ogóle warto zachować i na jak długo”.

To są różne problemy projektowe, z różnymi wzorcami awarii. Błąd w inżynierii kontekstu psuje jedną odpowiedź. Błąd w inżynierii pamięci narasta – złe zapisy się kumulują, nieaktualne fakty są pobierane tak, jakby wciąż były prawdziwe, i nikt tego nie zauważa, dopóki agent z pełnym przekonaniem nie powtórzy czegoś, co zostało skorygowane trzy sesje wcześniej. Jeśli jedna osoba (albo jeden szablon promptu) po cichu wykonuje obie te prace bez ich rozróżniania, warstwa pamięci zwykle dziedziczy nawyki z inżynierii kontekstu, których nie powinna: przepełnianie magazynu tak, jak przepełnia się okno kontekstu, albo traktowanie pobierania jako problemu rankingu trafności, podczas gdy to naprawdę problem kuracji i utrzymania. To właśnie ta pomyłka, na którą wskazuje ten przegląd badań, i pokrywa się ona z czymś, co praktycy już opisują anegdotycznie: agenci imponujący w jednej sesji, a niewiarygodni już w piątej.

Jak każda z tych prac wygląda na co dzień

Jeśli próbujesz ustalić, którą z tych rzeczy już robisz albo w którą stronę chciałbyś się rozwijać, codzienna praca wygląda na tyle inaczej, że da się je odróżnić:

Inżynieria kontekstu w praktyce to: decydowanie, jaki podzbiór dostępnych informacji (dokumentacja, wyniki narzędzi, poprzednie tury) faktycznie powinien znaleźć się w danym wywołaniu; wybieranie, w którym miejscu promptu ma się to znaleźć, bo pozycja wpływa na to, jak model to waży; pisanie kroków kompresji lub podsumowania, żeby długi ślad działania narzędzia nie pochłonął całego budżetu; oraz dostrajanie tego pod konkretne zadanie, bo agent do debugowania i agent do pisania chcą innego kształtu kontekstu nawet przy tym samym modelu bazowym.

Inżynieria pamięci w praktyce to: definiowanie polityki zapisu (co warto zachować po zakończeniu sesji – nie wszystko na to zasługuje); wybór warstwy przechowywania (baza wektorowa, baza strukturalna, zwykłe pliki, jakiś hybrydowy wariant) i uczciwe rozliczenie kompromisów każdego z nich; budowanie strategii pobierania, która decyduje, co i kiedy wraca; oraz bieżące utrzymanie – przycinanie, scalanie zduplikowanych faktów, obsługa sprzeczności, gdy użytkownik zmieni zdanie. Ta ostatnia część, utrzymanie, jest tą, którą ludzie pomijają najczęściej, bo nie widać jej, dopóki agent nie działa już od tygodni.

Widać, że branża zaczyna rozdzielać te kwestie strukturalnie, nie tylko pojęciowo. Omówienie budowy narzędzia do debugowania na Claude Agent SDK w Lenny's Newsletter traktuje uprawnienia, adaptery narzędzi i otaczającą je „uprząż” jako osobną powierzchnię inżynierską, odrębną od promptowania wewnątrz niej – ten sam instynkt, zastosowany do innego szwu. A nowsze funkcje „Managed Agents” w Gemini API od Google – wykonywanie w tle, odświeżanie poświadczeń między interakcjami – to w istocie dostawca platformy przyznający, że stan utrzymywany między sesjami jest teraz infrastrukturą, którą trzeba zaprojektować, a nie efektem ubocznym wystarczająco długiego okna kontekstu. Ktoś musi wziąć odpowiedzialność za ten projekt. Obecnie, w wielu zespołach, nikt tego wyraźnie nie robi.

Dlaczego ma to znaczenie dla twojego stanowiska, a nie tylko dla twojego kodu

Jeśli jesteś na wczesnym lub średnim etapie kariery i masz w CV „prompt engineer” albo „AI engineer”, warto zapytać samego siebie, którą z tych dwóch prac faktycznie potrafisz udokumentować dowodami – bo ogólne role związane z agentami AI zaczynają się rozpadać na bardziej konkretne, tak jak „webmaster” z czasem rozdzielił się na frontend, backend i DevOps. To zabezpieczenie, nie nagłówek: nie widziałem jeszcze twardych danych rekrutacyjnych potwierdzających „memory engineer” jako samodzielny tytuł stanowiska, więc traktuj to jako odczyt kierunku, w którym zmierza ta praca, a nie twierdzenie, że tablice ogłoszeń już są tak posegregowane. Ale leżąca u podstaw presja jest realna i da się ją prześledzić do wspomnianego przeglądu: zespoły agentowe napotykają konkretną, nazywalną awarię (degradację wielosesyjną), która ma konkretną, nazywalną przyczynę (pomylenie dwóch dyscyplin), a taka kombinacja zwykle jest tym, co zamienia niewyraźną rolę w dwie wyraźne.

Praktycznym posunięciem nie jest wymyślanie sobie tytułu. Jest nim umiejętność konkretnej odpowiedzi na pytanie, który problem faktycznie rozwiązałeś. Czy dostarczyłeś coś, w czym zaprojektowałeś politykę zapisu – regułę określającą, co agent zapisuje w pamięci, a co odrzuca? Czy debugowałeś awarię na granicy pobierania, gdy agent potrzebował czegoś z pamięci i albo tego nie pobrał, albo pobrał niewłaściwą wersję? To sprawdzalne twierdzenia, które możesz przedstawić na rozmowie kwalifikacyjnej, poparte repozytorium albo analizą powdrożeniową, i mówią one coś, czego nie mówi ogólne „piszę dobre prompty”: że rozumiesz różnicę między poprawieniem jednej odpowiedzi a uczynieniem agenta wiarygodnym w dłuższej perspektywie.

Przestroga

Nie przemianowuj się na „memory engineera” tylko dlatego, że raz dodałeś do projektu bazę wektorową. Dyscyplina, na którą wskazują te badania, obejmuje mniej efektowną połowę – utrzymanie, wygaszanie, obsługę sprzeczności – i to właśnie ta połowa faktycznie zapobiega opisanemu wyżej wzorcowi awarii. Jeśli twoim portfolio jest system, który zapisuje do pamięci, ale nic nigdy nie jest przycinane ani korygowane, zbudowałeś tylko połowę pracy inżyniera pamięci, a problem „psuje się po trzeciej sesji” wciąż czeka na ciebie po drugiej stronie.