„Prompt engineer“ nikdy nebyl přesný pracovní titul, ale nějakou dobu to nebylo potřeba. Pokud byla vaší jedinou náplní práce dostat jednu dobrou odpověď z jednoho volání modelu, stačila jedna sada dovedností: dobře zformulovat instrukci, přidat pár příkladů, možná doplnit nějaký vyhledaný text, hotovo. Tato sada dovedností je pořád důležitá. Ale už nepokrývá to, co v polovině roku 2026 znamená „stavět agenta“, a tato mezera se projevuje jako konkrétní, rozpoznatelný způsob selhání: agenti, kteří v demu fungují skvěle, a pak potichu degradují, sami si odporují nebo zapomenou, co jim uživatel řekl před dvěma session.

Nedávný článek od Machine Learning Mastery pojmenovává tuto mezeru přímo a stojí za to se u něj zastavit, protože se přehledně mapuje na dvě různé pracovní role, na které byste mohli být skutečně najati. Context engineering je to, co se odehrává uvnitř jednoho volání modelu: rozhodování, co se dostane do kontextového okna, kam to strukturálně patří a co se má komprimovat nebo vynechat, aby se model neutápěl v irelevantních tokenech. Memory engineering je jiný problém, který existuje pouze napříč voláními: co se zapíše po skončení session, kde se to uloží, jak se to příště vyhledá a jak se to udržuje (aktualizuje, odstraňují se duplicity, nastavuje se expirace), aby to nezastaralo. Podle onoho článku selhání, která se objevují v dlouhých, vícesession agentních workflow, se nejčastěji dají vystopovat k tomu, že se tyto dvě role smíchají, nebo se jedna z nich úplně vynechá — zejména v místě, které autoři nazývají „hranice vyhledávání“ (retrieval boundary), tedy v okamžiku, kdy se agent musí rozhodnout, zda to, co potřebuje, už má před sebou, nebo si to musí vyžádat z úložiště.

Proč je jejich směšování skutečnou chybou, a ne jen detailem

Zamyslete se nad tím, co každá z těchto disciplín vlastně optimalizuje. Context engineering optimalizuje jedno ohraničené, jednorázové okno — dostat správný výřez informací před model právě teď, pro tuto jednu výměnu, a zbytek zahodit. Memory engineering optimalizuje trvalé úložiště, které musí přežít napříč session, zůstat konzistentní s příchodem nových informací a odpovědět na mnohem těžší otázku: nikoli „co je relevantní k tomuto promptu“, ale „co vůbec stojí za to si uchovat, a na jak dlouho“.

Jde o odlišné návrhové problémy s odlišnými způsoby selhání. Chyba v context engineeringu zhorší jednu odpověď. Chyba v memory engineeringu se kumuluje — špatné zápisy se hromadí, zastaralá fakta se vyhledávají, jako by byla aktuální, a nikdo si toho nevšimne, dokud agent sebejistě nezopakuje něco, co bylo opraveno před třemi session. Pokud jedna osoba (nebo jedna šablona promptu) potichu vykonává obě role, aniž by je rozlišovala, vrstva paměti má tendenci zdědit návyky z context engineeringu, které by dědit neměla: přeplňovat úložiště stejně, jako byste přeplnili okno, nebo přistupovat k vyhledávání jako k problému řazení podle relevance, přestože je to ve skutečnosti problém kurátorství a údržby. Přesně na toto směšování výzkumný přehled poukazuje a shoduje se to s tím, co praktici už popisují anekdoticky: agenti, kteří v jedné session působí impozantně, ale do páté session jsou nespolehliví.

Jak obě role vypadají v praxi, den co den

Pokud se snažíte zjistit, kterou z těchto rolí už vykonáváte, nebo ke které byste chtěli směřovat, každodenní práce vypadá dostatečně odlišně na to, aby se daly rozeznat:

Context engineering v praxi: rozhodování, jaká podmnožina dostupných informací (dokumentace, výstupy nástrojů, předchozí tahy) do tohoto volání skutečně patří; volba, kam v promptu ji umístit, protože pozice ovlivňuje, jakou váhu jí model přikládá; psaní kroků pro kompresi nebo sumarizaci, aby dlouhá stopa z nástroje nesežrala celý rozpočet; a doladění tohoto nastavení podle úkolu, protože ladicí agent a psací agent chtějí odlišný tvar kontextu, i když běží na stejném základním modelu.

Memory engineering v praxi: definování politiky zápisu (co stojí za to po skončení session uchovat — ne všechno za to stojí); výběr úložné vrstvy (vektorové úložiště, strukturovaná databáze, obyčejné soubory, nějaký hybrid) a upřímné zhodnocení kompromisů každé z nich; vybudování strategie vyhledávání, která rozhoduje, co se vrátí zpět a kdy; a průběžná údržba — prořezávání, slučování duplicitních faktů, řešení rozporů, když si to uživatel rozmyslí. Právě tato poslední část, údržba, je ta, kterou lidé nejčastěji vynechávají, protože není vidět, dokud agent neběží několik týdnů.

Je vidět, že se tyto obory v odvětví začínají oddělovat strukturálně, nejen koncepčně. Návod od Lenny's Newsletter na sestavení ladicího harness na Claude Agent SDK zachází s oprávněními, adaptéry nástrojů a okolním „harness“ jako s vlastní inženýrskou plochou odlišnou od promptování uvnitř něj — stejný instinkt, aplikovaný na jiný šev. A novější funkce „Managed Agents“ v Gemini API od Googlu — běh na pozadí, obnova přihlašovacích údajů napříč interakcemi — jsou v podstatě přiznáním výrobce platformy, že stav trvalý napříč session je nyní infrastruktura, kterou je třeba navrhnout, nikoli vedlejší efekt dostatečně dlouhého kontextového okna. Někdo musí tento návrh vlastnit. V mnoha týmech to momentálně výslovně nedělá nikdo.

Proč na tom záleží pro váš pracovní titul, nejen pro váš kód

Pokud jste na začátku nebo v polovině kariéry a v životopise máte „prompt engineer“ nebo „AI engineer“, stojí za to se zeptat, u které z těchto dvou rolí dokážete skutečně doložit, že ji vykonáváte — protože generalistické role kolem AI agentů se začínají štěpit na specifičtější, podobně jako se „webmaster“ nakonec rozdělil na frontend, backend a DevOps. Je to spíš opatrná úvaha než senzace: zatím jsem neviděl tvrdá náborová data potvrzující „memory engineer“ jako samostatný titul, takže to berte jako odhad, kterým směrem se práce ubírá, nikoli jako tvrzení, že pracovní portály už jsou takto uspořádané. Ale ten základní tlak je reálný a dá se vystopovat k výše zmíněnému přehledu: agentní týmy narážejí na konkrétní, pojmenovatelné selhání (degradace napříč session), které má konkrétní, pojmenovatelnou příčinu (směšování dvou disciplín), a tato kombinace je obvykle tím, co z rozostřené role udělá dvě ostré.

Praktický krok není vymyslet si titul. Je to schopnost konkrétně odpovědět, který problém jste skutečně vyřešili. Nasadili jste něco, kde jste navrhli politiku zápisu — pravidlo, co si agent ukládá do paměti a co zahazuje? Ladili jste selhání na hranici vyhledávání, kdy agent potřeboval něco z úložiště a buď si to nevyžádal, nebo si vyžádal špatnou verzi? To jsou ověřitelná tvrzení, která můžete uvést na pohovoru, podložená repozitářem nebo rozborem incidentu, a říkají něco, co obecné „píšu dobré prompty“ neřekne: že chápete rozdíl mezi tím, jak zlepšit jednu odpověď, a tím, jak udělat agenta dlouhodobě důvěryhodným.

Varování

Nepřejmenovávejte se na „memory engineera“ jen na základě toho, že jste jednou do projektu přidali vektorovou databázi. Disciplína, na kterou výzkum poukazuje, zahrnuje i tu méně efektní polovinu — údržbu, expiraci, řešení rozporů — a právě tato polovina je tou, která skutečně brání výše popsanému způsobu selhání. Pokud je vaší ukázkovou prací systém, který zapisuje do paměti, ale nic se v ní neprořezává ani neopravuje, postavili jste jen polovinu práce memory engineera, a problém selhávání po třetí session na vás stále čeká v té druhé polovině.