"प्रॉम्प्ट इंजीनियर" कभी भी कोई सटीक नौकरी का शीर्षक नहीं रहा, लेकिन कुछ समय तक इसकी ज़रूरत भी नहीं थी। अगर आपका पूरा काम बस एक ही इन्फरेंस कॉल से एक अच्छा जवाब निकालना था, तो एक ही हुनर उसके लिए काफी था: निर्देश को अच्छी तरह लिखना, कुछ उदाहरण देना, शायद कुछ रिट्रीव किया हुआ टेक्स्ट जोड़ना, बस इतना ही। यह हुनर अब भी मायने रखता है। लेकिन 2026 के मध्य में "एजेंट बनाने" का जो मतलब है, उसे यह अब पूरी तरह कवर नहीं करता, और यह कमी एक खास, पहचानने योग्य नाकामी के रूप में सामने आ रही है: ऐसे एजेंट जो डेमो में शानदार काम करते हैं और फिर चुपचाप बिगड़ने लगते हैं, खुद का खंडन करने लगते हैं, या भूल जाते हैं कि यूज़र ने उन्हें दो सेशन पहले क्या बताया था।
Machine Learning Mastery के एक हालिया लेख में इस कमी को सीधे तौर पर नाम दिया गया है, और इस पर ध्यान देना ज़रूरी है क्योंकि यह साफ़-साफ़ दो अलग-अलग नौकरियों से मेल खाता है जिनके लिए आपको वाकई नियुक्त किया जा सकता है। कॉन्टेक्स्ट इंजीनियरिंग वह है जो एक इन्फरेंस कॉल के भीतर होता है: यह तय करना कि कॉन्टेक्स्ट विंडो में क्या जाए, वह संरचनात्मक रूप से कहाँ जाए, और क्या कंप्रेस या हटाया जाए ताकि मॉडल अप्रासंगिक टोकनों में डूब न जाए। मेमोरी इंजीनियरिंग एक अलग समस्या है जो सिर्फ़ कॉल्स के बीच मौजूद रहती है: सेशन खत्म होने के बाद क्या दर्ज किया जाए, वह कहाँ संग्रहीत हो, अगली बार उसे कैसे निकाला जाए, और उसे कैसे बनाए रखा जाए (अपडेट, डुप्लिकेट-रहित, और एक्सपायर करके) ताकि वह सड़ न जाए। उस लेख के अनुसार, लंबे, बहु-सेशन एजेंट वर्कफ़्लो में दिखने वाली नाकामियाँ अक्सर इन्हीं दो कामों को गड्डमड्ड करने या इनमें से किसी एक को छोड़ देने से जुड़ी होती हैं — खासकर उस बिंदु पर जिसे वे "रिट्रीवल बाउंड्री" कहते हैं, यानी वह पल जब किसी एजेंट को यह तय करना होता है कि जिस चीज़ की उसे ज़रूरत है वह पहले से उसके सामने मौजूद है या उसे स्टोरेज से लानी होगी।
इन्हें गड्डमड्ड करना ही असली गड़बड़ी है, कोई मामूली बात नहीं
ज़रा सोचिए कि हर अनुशासन किसे बेहतर बनाने की कोशिश करता है। कॉन्टेक्स्ट इंजीनियरिंग एक इकलौती, सीमित और डिस्पोज़ेबल विंडो को बेहतर बनाने पर काम करती है — अभी, इस एक आदान-प्रदान के लिए, जानकारी का सही हिस्सा मॉडल के सामने लाना, और फिर बाकी सब फेंक देना। मेमोरी इंजीनियरिंग एक टिकाऊ भंडार को बेहतर बनाने पर काम करती है, जिसे सेशनों के पार टिके रहना है, नई जानकारी आने पर भी संगत बने रहना है, और एक कहीं ज़्यादा कठिन सवाल का जवाब देना है: यह नहीं कि "इस प्रॉम्प्ट के लिए क्या प्रासंगिक है", बल्कि यह कि "आखिर क्या रखने लायक है, और कब तक।"
ये अलग-अलग डिज़ाइन समस्याएँ हैं जिनकी नाकामी के तरीके भी अलग-अलग हैं। कॉन्टेक्स्ट-इंजीनियरिंग की गलती एक जवाब को खराब बनाती है। मेमोरी-इंजीनियरिंग की गलती संचित होती चली जाती है — गलत एंट्रियाँ जमा होती रहती हैं, पुरानी जानकारी को ऐसे निकाला जाता है मानो वह ताज़ा हो, और किसी को तब तक पता नहीं चलता जब तक एजेंट भरोसे के साथ वह बात न दोहरा दे जिसे तीन सेशन पहले ठीक किया जा चुका था। अगर एक ही व्यक्ति (या एक ही प्रॉम्प्ट टेम्प्लेट) चुपचाप दोनों काम बिना फ़र्क किए कर रहा है, तो मेमोरी लेयर अक्सर वे आदतें अपना लेती है जो उसे कॉन्टेक्स्ट-इंजीनियरिंग से नहीं लेनी चाहिए: जैसे विंडो को ज़्यादा भरने की तरह स्टोरेज को भी ज़रूरत से ज़्यादा भर देना, या रिट्रीवल को प्रासंगिकता-रैंकिंग की समस्या मानना जबकि असल में यह क्यूरेशन और रखरखाव की समस्या है। यही वह गड्डमड्ड है जिसकी ओर यह रिसर्च डाइजेस्ट इशारा कर रहा है, और यह उस बात से भी मेल खाता है जो प्रैक्टिशनर पहले से ही किस्सों के तौर पर बताते आए हैं: ऐसे एजेंट जो एक ही सेशन में प्रभावशाली लगते हैं लेकिन पाँचवें सेशन तक अविश्वसनीय हो जाते हैं।
हर काम असल में रोज़मर्रा में कैसा दिखता है
अगर आप यह समझने की कोशिश कर रहे हैं कि इनमें से आप पहले से क्या कर रहे हैं, या आगे किस दिशा में बढ़ना चाहते हैं, तो इनका रोज़मर्रा का काम इतना अलग दिखता है कि इन्हें आसानी से पहचाना जा सकता है:
व्यवहार में, कॉन्टेक्स्ट इंजीनियरिंग: यह तय करना कि उपलब्ध जानकारी (दस्तावेज़, टूल आउटपुट, पिछले टर्न) का कौन-सा हिस्सा वाकई इस कॉल में शामिल होना चाहिए; यह चुनना कि प्रॉम्प्ट में वह कहाँ जाए, क्योंकि स्थिति इस बात को प्रभावित करती है कि मॉडल उसे कितना महत्व देता है; ऐसे कंप्रेशन या सारांशीकरण चरण लिखना ताकि किसी लंबे टूल-ट्रेस से पूरा बजट न खप जाए; और हर काम के हिसाब से इसे ट्यून करना, क्योंकि एक डिबगिंग एजेंट और एक लेखन एजेंट को, एक ही अंतर्निहित मॉडल पर भी, अलग-अलग तरह के कॉन्टेक्स्ट की ज़रूरत होती है।
व्यवहार में, मेमोरी इंजीनियरिंग: एक राइट पॉलिसी तय करना (सेशन के बाद क्या बनाए रखने लायक है — हर चीज़ नहीं होती); एक स्टोरेज लेयर चुनना (वेक्टर स्टोर, स्ट्रक्चर्ड डेटाबेस, सादी फ़ाइलें, या कोई हाइब्रिड) और हर एक के ट्रेडऑफ़ के बारे में ईमानदार रहना; एक रिट्रीवल रणनीति बनाना जो तय करे कि क्या और कब वापस निकाला जाए; और लगातार रखरखाव करना — छँटाई करना, दोहरे तथ्यों को मिलाना, और जब यूज़र अपना मन बदले तो विरोधाभासों को संभालना। यह आखिरी हिस्सा, यानी रखरखाव, वही है जिसे लोग सबसे ज़्यादा छोड़ देते हैं, क्योंकि जब तक कोई एजेंट हफ़्तों तक न चले, तब तक यह नज़र ही नहीं आता।
आप देख सकते हैं कि यह इंडस्ट्री अब इन सरोकारों को सिर्फ़ वैचारिक रूप से नहीं, बल्कि संरचनात्मक रूप से भी अलग करने लगी है। Lenny's Newsletter का Claude Agent SDK पर एक डिबगिंग हार्नेस बनाने का वॉकथ्रू, परमिशन, टूल एडाप्टर, और आस-पास के "हार्नेस" को उसके भीतर होने वाली प्रॉम्प्टिंग से अलग एक अपनी खुद की इंजीनियरिंग सतह के रूप में देखता है — वही सहज बोध, बस एक अलग जोड़ पर लागू। और Google के नए Gemini API "Managed Agents" फ़ीचर — बैकग्राउंड एग्ज़ीक्यूशन, इंटरैक्शन्स के आर-पार क्रेडेंशियल रिफ़्रेश — असल में इस बात की स्वीकृति है कि सेशन-पर्सिस्टेंट स्टेट अब एक ऐसा इन्फ्रास्ट्रक्चर है जिसे डिज़ाइन किया जाना चाहिए, न कि किसी काफ़ी लंबी कॉन्टेक्स्ट विंडो का साइड-इफ़ेक्ट। किसी न किसी को इस डिज़ाइन का ज़िम्मा लेना ही होगा। अभी, कई टीमों में, स्पष्ट रूप से यह ज़िम्मा किसी का भी नहीं है।
यह आपकी नौकरी के शीर्षक के लिए क्यों मायने रखता है, न कि सिर्फ़ आपके कोड के लिए
अगर आप करियर की शुरुआत में हैं या मध्य-करियर में हैं और आपके रिज़्यूमे पर "प्रॉम्प्ट इंजीनियर" या "AI इंजीनियर" लिखा है, तो यह पूछना ज़रूरी है कि इन दो कामों में से किसे करने का ठोस सबूत आप वाकई दिखा सकते हैं — क्योंकि जनरलिस्ट AI-एजेंट भूमिकाएँ अब ज़्यादा विशिष्ट भूमिकाओं में बँटने लगी हैं, ठीक वैसे ही जैसे "वेबमास्टर" आखिरकार फ्रंटएंड, बैकएंड और DevOps में बँट गया था। यह एक एहतियाती बात है, कोई बड़ा दावा नहीं: मैंने अभी तक ऐसा कोई पक्का हायरिंग डेटा नहीं देखा जो "मेमोरी इंजीनियर" को एक अलग शीर्षक के तौर पर पुख्ता करे, इसलिए इसे यह समझें कि काम किस दिशा में जा रहा है, न कि यह दावा कि जॉब बोर्ड पहले से ही इस तरह बँट चुके हैं। लेकिन इसके पीछे का दबाव असली है और ऊपर बताए गए डाइजेस्ट से जुड़ा हुआ भी: एजेंट टीमों को एक खास, नाम लेने लायक नाकामी (बहु-सेशन गिरावट) का सामना करना पड़ रहा है, जिसका एक खास, नाम लेने लायक कारण है (दो अनुशासनों को गड्डमड्ड करना), और आमतौर पर यही मेल एक धुंधली भूमिका को दो साफ़ भूमिकाओं में बदल देता है।
व्यावहारिक कदम यह नहीं है कि आप अपने लिए कोई नया शीर्षक गढ़ लें। बल्कि यह है कि आप ठोस तरीके से यह जवाब दे सकें कि आपने असल में कौन-सी समस्या हल की है। क्या आपने कभी ऐसा कुछ शिप किया है जिसमें आपने एक राइट पॉलिसी डिज़ाइन की हो — यह नियम कि एजेंट मेमोरी में क्या दर्ज करे और क्या छोड़ दे? क्या आपने कभी किसी रिट्रीवल-बाउंड्री नाकामी को डिबग किया है, जहाँ किसी एजेंट को स्टोरेज से कुछ चाहिए था और उसने या तो उसे लाया ही नहीं या गलत वर्ज़न ला दिया? ये ऐसे दावे हैं जिन्हें आप इंटरव्यू में कर सकते हैं और किसी रिपॉज़िटरी या पोस्टमॉर्टम से साबित कर सकते हैं, और ये वह बात कहते हैं जो एक सामान्य "मैं अच्छे प्रॉम्प्ट लिखता हूँ" नहीं कहती: यह कि आप एक जवाब को बेहतर बनाने और किसी एजेंट को लंबे समय तक भरोसेमंद बनाने के बीच के फ़र्क को समझते हैं।
एक चेतावनी
सिर्फ़ इसलिए खुद को "मेमोरी इंजीनियर" का नया लेबल न दे दें कि आपने कभी किसी प्रोजेक्ट में एक वेक्टर डेटाबेस जोड़ दिया था। यह रिसर्च जिस अनुशासन की ओर इशारा करती है उसमें वह बेरौनक आधा हिस्सा भी शामिल है — रखरखाव, एक्सपायरी, विरोधाभासों को संभालना — और असल में यही आधा हिस्सा है जो ऊपर बताई गई नाकामी को रोकता है। अगर आपके पोर्टफ़ोलियो का नमूना ऐसा सिस्टम है जो मेमोरी में लिखता तो है लेकिन कभी कुछ छाँटा या ठीक नहीं किया जाता, तो आपने मेमोरी इंजीनियर के काम का सिर्फ़ आधा हिस्सा बनाया है, और तीसरे सेशन के बाद नाकाम होने वाली समस्या अब भी बाकी आधे हिस्से में आपका इंतज़ार कर रही है।