Hindi naman talaga eksaktong titulo ng trabaho ang "prompt engineer," pero sa mahabang panahon, hindi na kailangan pa nito maging ganoon. Kung ang buong trabaho mo ay kunin ang isang magandang sagot mula sa isang inference call, sapat na ang isang set ng kasanayan: husayan ang pagkakabuo ng instruksyon, magbigay ng ilang halimbawa, marahil magdagdag ng nakuhang teksto, tapos na. Mahalaga pa rin ang set ng kasanayang iyon. Pero hindi na ito sapat para saklawin ang kahulugan ng "paggawa ng ahente" sa kalagitnaan ng 2026, at lumalabas ang puwang na ito bilang isang tiyak at nakikilalang paraan ng pagkabigo: mga ahente na maayos gumana sa isang demo pero unti-unti nang bumababa ang kalidad, sumasalungat sa sarili, o nakalilimutan kung ano ang sinabi ng user dalawang session na ang nakalipas.

Direktang pinangalanan ng isang bagong artikulo mula sa Machine Learning Mastery ang puwang na ito, at sulit itong pag-isipan dahil malinaw itong tumutugma sa dalawang magkaibang trabaho na maaari mong talagang ma-hire para gawin. Ang context engineering ay ang nagaganap sa loob ng isang inference call: ang pagpapasya kung ano ang isasama sa context window, saan ito ilalagay sa istruktura, at ano ang i-compress o itatapon para hindi malunod ang modelo sa mga token na walang kaugnayan. Ang memory engineering ay ibang problema na umiiral lamang sa buong hanay ng mga tawag: ano ang isusulat matapos matapos ang isang session, saan ito iimbak, paano ito babawiin sa susunod na pagkakataon, at paano ito pananatilihin (i-update, alisin ang duplikado, palitan kung expired) para hindi ito mabulok. Ayon sa artikulong iyon, ang mga pagkabigo na lumalabas sa mahaba at maraming-session na daloy ng trabaho ng ahente ay karaniwang nagmumula sa paghalo ng dalawang trabahong ito, o sa paglaktaw sa isa sa mga ito — lalo na sa tinatawag nilang "retrieval boundary," ang sandaling kinakailangang pagpasyahan ng ahente kung ang isang bagay na kailangan nito ay nasa harapan na o kailangan pa nitong kunin mula sa imbakan.

Bakit ang paghalo sa kanila ang talagang bug, hindi lang isang detalye

Isipin ang layunin ng bawat disiplina. Ang context engineering ay nag-o-optimize ng isang solo, may-hangganan, at maiitatapong window — kunin ang tamang bahagi ng impormasyon sa harap ng modelo ngayon, para sa isang palitan ng mensaheng ito, tapos itapon ang iba. Ang memory engineering naman ay nag-o-optimize ng isang matibay na imbakan na dapat manatiling buo sa buong sesyon, manatiling pare-pareho habang dumarating ang bagong impormasyon, at sagutin ang mas mahirap na tanong: hindi "ano ang may kaugnayan sa prompt na ito" kundi "ano ba talaga ang sulit na itago, at hanggang kailan."

Magkaibang problema sa disenyo ito na may magkaibang paraan ng pagkabigo. Ang isang pagkakamali sa context engineering ay nagpapasama lamang ng isang sagot. Ang pagkakamali sa memory engineering ay tumataas nang tumataas — naiipon ang mga maling isinulat, kinukuha ang mga lumang katotohanan na parang kasalukuyan pa rin, at wala nang napapansin hanggang sa may-kumpiyansang ulitin ng ahente ang isang bagay na naitama na noong tatlong session na ang nakalipas. Kung ang isang tao (o isang prompt template) ang tahimik na gumagawa ng dalawang trabaho nang hindi ito nakikilala bilang hiwalay, ang memory layer ay may tendensiyang manahin ang mga gawi sa context engineering na hindi dapat: sobrang pagpuno sa imbakan sa paraang gagawin mo sa isang window, o pagturing sa retrieval bilang isang problema sa relevance-ranking kung sa totoo lang ay problema ito sa curation at maintenance. Iyan ang paghahalong itinuturo ng research digest, at tumutugma ito sa isang bagay na inilalarawan na ng mga practitioner batay sa kanilang karanasan: mga ahente na kahanga-hanga sa isang session pero hindi na maaasahan pagsapit ng ikalimang session.

Ano talaga ang hitsura ng bawat trabaho sa araw-araw

Kung sinusubukan mong alamin kung alin sa mga ito ang ginagawa mo na, o alin ang nais mong paunlarin, sapat na kaiba ang pang-araw-araw na trabaho para makilala ang pagkakaiba:

Ang context engineering, sa praktika: pagpapasya kung aling bahagi ng magagamit na impormasyon (mga dokumento, resulta ng tool, nakaraang turno) ang talagang nauukol sa tawag na ito; pagpili kung saan sa prompt ito ilalagay, dahil naaapektuhan ng posisyon ang bigat na ibinibigay ng modelo dito; pagsulat ng mga hakbang sa compression o summarization para hindi maubos ng mahabang tool trace ang buong badyet; at pag-aayos nito ayon sa bawat gawain, dahil magkaibang hugis ng context ang nais ng isang debugging agent at ng isang writing agent kahit pareho lang ang batayang modelo.

Ang memory engineering, sa praktika: pagtukoy ng write policy (ano ang sulit na itago matapos ang isang session — hindi lahat ay ganoon); pagpili ng storage layer (isang vector store, isang structured database, ordinaryong file, o kombinasyon ng mga ito) at pagiging tapat sa mga kalamangan at kahinaan ng bawat isa; paggawa ng retrieval strategy na magpapasya kung ano ang babawiin at kailan; at ang patuloy na maintenance — pag-aalis ng hindi na kailangan, pagsasanib ng mga duplikadong katotohanan, at paghawak sa mga pagkakasalungat kapag nagbago ang isip ng user. Ang huling bahaging iyon, ang maintenance, ang pinakakaraniwang nilalaktawan ng mga tao, dahil hindi ito nakikita hangga't hindi tumatakbo ang ahente sa loob ng ilang linggo.

Makikita mong nagsisimula nang ihiwalay ng industriya ang mga alalahanin na ito sa antas ng istruktura, hindi lang sa antas ng konsepto. Ang walkthrough ng Lenny's Newsletter tungkol sa paggawa ng debugging harness gamit ang Claude Agent SDK ay itinuturing ang mga permission, tool adapter, at ang nakapaligid na "harness" bilang kanya-kanyang sukatang gawain sa engineering na hiwalay sa prompting sa loob nito — ang parehong instinct, ipinatupad sa ibang bahagi. At ang mga bagong feature ng Google na "Managed Agents" sa Gemini API — background execution, pag-refresh ng credential sa buong interaksyon — ay sa totoo lang pag-amin na ng vendor ng platform na ang session-persistent state ay ngayon isa nang imprastraktura na dapat dinisenyo, hindi lang epekto ng sapat na haba ng context window. May dapat mangako ng pagmamay-ari sa disenyong iyon. Sa kasalukuyan, sa maraming team, walang tahasang gumagawa nito.

Bakit mahalaga ito sa titulo ng trabaho mo, hindi lang sa code mo

Kung nagsisimula ka pa lang o nasa gitna ng iyong karera at nasa resume mo ang "prompt engineer" o "AI engineer," sulit itanong sa sarili kung alin sa dalawang trabahong ito ang may talagang ebidensiya na ginagawa mo — dahil nagsisimula nang mahati ang mga generalist na papel sa AI-agent sa mas tiyak na mga papel, gaya ng paghati sa kalaunan ng "webmaster" sa frontend, backend, at DevOps. Isa itong pag-iingat, hindi isang malaking pahayag: wala pa akong nakitang matibay na datos sa paghire na nagpapatunay na "memory engineer" ay isa na talagang bukod-tanging titulo, kaya ituring mo itong isang pagbasa sa direksyon ng papuntahan ng trabaho, hindi isang paghahabol na naayos na ganito ang mga job board sa kasalukuyan. Pero totoo ang nakararaming presyon sa ilalim nito at masusubaybayan ito pabalik sa digest sa itaas: nakakaranas ang mga team ng ahente ng isang tiyak at napapangalanang pagkabigo (ang pagbaba ng kalidad sa maraming session) na may tiyak at napapangalanang sanhi (paghalo sa dalawang disiplina), at ang kumbinasyong iyon ang karaniwang nagpapabago ng isang malabong papel patungo sa dalawang malinaw na papel.

Ang praktikal na hakbang ay hindi ang pag-imbento ng titulo para sa sarili mo. Ito ay ang kakayahang sagutin, nang tiyak, kung aling problema ang talagang nalutas mo. Nakapaglabas ka na ba ng isang bagay kung saan dinisenyo mo ang isang write policy — isang panuntunan kung ano ang itatago ng isang ahente sa memorya at ano ang itatapon? Nadibug mo na ba ang isang pagkabigo sa retrieval boundary, kung saan kinailangan ng isang ahente ng isang bagay mula sa imbakan pero hindi ito nakuha o nakuha ang maling bersyon? Iyan ang mga paghahabol na maaari mong ipahayag sa isang interbyu, na sinusuportahan ng isang repositoryo o isang postmortem, at may sinasabi ito na hindi masasabi ng pangkaraniwang "magaling akong sumulat ng prompt": na nauunawaan mo ang pagkakaiba ng paggawa ng isang sagot na mas mahusay laban sa paggawa ng isang ahente na mapagkakatiwalaan sa mahabang panahon.

Isang babala

Huwag mong ipapalit ang tawag sa sarili mo na "memory engineer" dahil lang nakadagdag ka na ng isang vector database sa isang proyekto nang minsan. Ang disiplinang itinuturo ng pananaliksik ay may kasamang hindi-kaakit-akit na kalahati — ang maintenance, ang expiry, ang paghawak ng pagkakasalungat — at ito ang kalahati na talagang pumipigil sa paraan ng pagkabigo na inilarawan sa itaas. Kung ang piraso ng iyong portfolio ay isang sistema na sumusulat sa memorya pero walang inaalis o itinatama, nagawa mo lamang ang kalahati ng trabaho ng isang memory engineer, at ang problemang nagkakabigo pagsapit ng ikatlong session ay naghihintay pa rin sa kabilang kalahati.