पिछले दो सालों में, AI एजेंट्स से जुड़ी करियर सलाह ज़्यादातर उन्हें अच्छी तरह प्रॉम्प्ट करना सीखने के इर्द-गिर्द रही है। अब वह दुर्लभ कौशल नहीं रहा। असली दुर्लभ कौशल है वह ढांचा बनाना जिसके भीतर एजेंट काम करता है — वह चीज़ जिसे अब बढ़ती संख्या में लोग हार्नेस कहते हैं — और यह इतना खास और इतना कठिन है कि यह किसी टीम में "AI वाले इंसान" की एक साइड ज़िम्मेदारी बनने के बजाय अपने आप में एक अलग जॉब डिस्क्रिप्शन बनता जा रहा है।
इसमें असल में क्या शामिल होता है, इसका सबसे स्पष्ट सार्वजनिक विवरण Lenny's Newsletter से मिलता है, जिसमें बताया गया है कि प्रोडक्ट-मैनेजमेंट टूल ChatPRD ने Sentry बग्स को अपने-आप डीबग करने के लिए एक हार्नेस कैसे बनाया। अगर आप यह तय कर रहे हैं कि इस क्षेत्र में विशेषज्ञता हासिल करनी है या नहीं, तो यह लेख पूरा पढ़ने लायक है, क्योंकि इसमें एक ऐसी बात कही गई है जिसे नज़रअंदाज़ करना आसान है: मॉडल कभी भी बाधा नहीं था। टीम ने Claude Agent SDK को नींव के रूप में इस्तेमाल किया, और फिर अपनी ज़्यादातर इंजीनियरिंग मेहनत एक कस्टम टर्मिनल UI पर और एजेंट को Sentry, Linear, GitHub, और Vercel से जोड़ने वाले एडेप्टरों के एक सेट पर खर्च की। यही असल में यह काम है, छोटे रूप में। चार सिस्टम, चार अलग-अलग ऑथ स्कीम, चार अलग-अलग डेटा आकार, और एक ऐसा UI जो इंसान को हर कदम पर निगरानी किए बिना देखने और बीच में दखल देने देता है।
"हार्नेस" असल में किन हिस्सों में बंटता है
अगर आप यह समझने की कोशिश कर रहे हैं कि यह कौशल-सेट बनाने लायक है या नहीं, तो इसे उन अलग-अलग हिस्सों में बांटना मददगार होगा जिनके लिए अलग से हायरिंग होती है, या कम से कम इंटरव्यू में जिन्हें अलग-अलग परखा जाता है:
- परमिशन डिज़ाइन। यह तय करना कि एजेंट को बिना निगरानी के क्या करने की अनुमति है (जैसे टिकट पढ़ना, PR का ड्राफ्ट बनाना) बनाम किन कामों के लिए इंसान का बीच में होना ज़रूरी है (मर्ज करना, डिप्लॉय करना, डिलीट करना, पैसे खर्च करना) — और इसे कोड में एक वास्तविक नीति के रूप में एन्कोड करना, न कि सिर्फ एक प्रॉम्प्ट निर्देश के रूप में जिसे मॉडल दबाव में नज़रअंदाज़ कर सकता है। यह प्रॉम्प्ट लिखने से कहीं ज़्यादा एक्सेस-कंट्रोल इंजीनियरिंग के करीब है।
- टूल एडेप्टर्स। हर बाहरी सिस्टम (Sentry, Linear, GitHub, Vercel, या जो भी आपकी कंपनी का स्टैक हो) के इर्द-गिर्द बने पतले, अच्छी तरह टेस्ट किए गए रैपर, जो एजेंट के इरादे को एक सुरक्षित, वैलिडेटेड API कॉल में बदलते हैं और जवाब को वापस ऐसी चीज़ में बदलते हैं जिस पर मॉडल तर्क कर सके। यह सामान्य सॉफ्टवेयर इंजीनियरिंग ही है — एरर हैंडलिंग, रिट्राई, स्कीमा वैलिडेशन — बस एक नए उपभोक्ता पर लागू की गई।
- टर्मिनल या कंसोल UI। एक ऐसा ज़रिया जिससे इंसान देख सके कि एजेंट क्या कर रहा है, कार्रवाइयों को स्वीकृत या अस्वीकृत कर सके, और जब वह अटक जाए तो बीच में दखल दे सके। ChatPRD ने अपना खुद का बनाया; बहुत सी टीमें इसकी जगह रेडीमेड एजेंट कंसोल इस्तेमाल करेंगी, लेकिन फिर भी किसी को यह तय करना होगा कि क्या दिखाया जाए, क्या छिपाया जाए, और किस काम के होने से पहले क्लिक की ज़रूरत हो।
- बड़े स्तर पर टूल चयन। Machine Learning Mastery का एक लेख एक ऐसी बात की ओर इशारा करता है जो जानने लायक है अगर आप डेमो से आगे कुछ भी बना रहे हैं: टूल कॉल्स पर एजेंट की सटीकता तब गिरने लगती है जब टूल कैटलॉग लगभग एक दर्जन विकल्पों को पार कर जाता है — मॉडल गलत टूल कॉल करने लगता है, पैरामीटर्स को गढ़ने लगता है, या खराब कॉल्स पर अटक जाता है। इसमें बताए गए उपायों (किसी दिए गए संदर्भ में कौन से टूल दिखाई भी दें इसे सीमित करना, रिट्रीवल-आधारित टूल खोज, विशेष सब-एजेंट्स की ओर रूटिंग, स्पष्ट प्लानिंग स्टेप्स, फॉलबैक लॉजिक, और रिग्रेशन पकड़ने के लिए बेंचमार्क हार्नेस) खुद ही उन चीज़ों की एक चेकलिस्ट हैं जिन्हें एक हार्नेस इंजीनियर को सिर्फ जानना नहीं बल्कि लागू करना आना चाहिए।
- कॉन्टेक्स्ट और मेमोरी इंजीनियरिंग। यही स्रोत एक ऐसा फर्क बताता है जिसे समझना ज़रूरी है: कॉन्टेक्स्ट इंजीनियरिंग (एक अकेले इनफरेंस कॉल में क्या-क्या और कहां जाता है) और मेमोरी इंजीनियरिंग (सेशन्स के पार क्या बना रहता है, वह कैसे स्टोर होता है, कैसे रिट्रीव होता है) अलग-अलग अनुशासन हैं जिनकी विफलताएं भी अलग-अलग तरह की होती हैं। इसका दावा है कि लंबे समय तक चलने वाले, कई-सेशन वाले एजेंट्स में ज़्यादातर गड़बड़ियां इन दोनों को गड्डमड्ड करने से जुड़ी होती हैं — सेशन मेमोरी को सिर्फ और ज़्यादा कॉन्टेक्स्ट जैसा मान लेना, या इसका उल्टा — खासकर उस बिंदु पर जहां सिस्टम यह तय करता है कि क्या रिट्रीव करना है।
इस बात के सबूत कि यह एक असली, फंड किए जाने लायक भूमिका है — सिर्फ शौकिया लोगों का कोई कोना नहीं
संदेह करने वाले वाजिब तौर पर पूछेंगे कि क्या "हार्नेस इंजीनियर" एक नौकरी है या किसी और की नौकरी के भीतर बस एक काम है। इस डाइजेस्ट के दो डेटा पॉइंट बताते हैं कि यह पहले वाली दिशा की ओर बढ़ रहा है। पहला, Microsoft की Aspire टीम — सिर्फ 10 लोगों का समूह — ने GitHub के Agentic Workflows का इस्तेमाल कर के कई रिपॉज़िटरी में डॉक्यूमेंटेशन PRs को अपने-आप बनाना शुरू किया, और दो रिलीज़ों में संबंधित प्रोडक्ट PR के शिप होने के औसतन 44.8 घंटे बाद 82 PRs मर्ज किए — बिना किसी नई हायरिंग के और बिना किसी प्रक्रिया के दोबारा प्रशिक्षण के। यह एक छोटी टीम को असाधारण रूप से बड़ा लाभ मिलने का उदाहरण है, खासतौर पर इसलिए क्योंकि किसी ने ढांचे में निवेश किया (वर्कफ़्लो परिभाषाएं, रिव्यू रूटिंग, ट्रिगर लॉजिक) बजाय इसके कि इंजीनियर हाथ से डॉक्स PRs लिखें। दूसरा, Microsoft Research के SkillOpt प्रोजेक्ट में एजेंट की "स्किल" फ़ाइलों — यानी वे निर्देश और सीमाएं जो तय करती हैं कि एजेंट अपने हार्नेस में कैसा व्यवहार करे — को हाथ से संपादित करने के बजाय व्यवस्थित रूप से ऑप्टिमाइज़ करने लायक चीज़ माना गया है, और इसमें बताया गया है कि यह एक बेंचमार्क ग्रिड के सभी 52 सेल्स (छह बेंचमार्क, सात मॉडल, तीन एक्ज़ीक्यूशन मोड) में सर्वश्रेष्ठ या सर्वश्रेष्ठ के बराबर रहा, और ऑप्टिमाइज़ की गई स्किल्स अलग-अलग मॉडलों और अलग-अलग हार्नेस में भी काम आईं। भले ही वह खास टूल मानक बने या न बने, यह इस बात का संकेत है कि उद्योग अब हार्नेस कॉन्फ़िगरेशन को अपने खुद के टूलिंग और बेंचमार्क वाले एक इंजीनियरिंग आर्टिफैक्ट की तरह देखना शुरू कर रहा है — वही राह जिसने "DevOps" को तदर्थ स्क्रिप्ट्स के एक ढेर से एक अनुशासन में बदल दिया था।
अब इस परत के लिए खासतौर पर इंफ्रास्ट्रक्चर भी बनाया जा रहा है। Google की Gemini API में हाल ही में घोषित "Managed Agents" क्षमताएं — बैकग्राउंड और असिंक्रोनस एक्ज़ीक्यूशन, रिमोट MCP सर्वर इंटीग्रेशन, कस्टम फ़ंक्शन कॉलिंग, इंटरैक्शनों के बीच क्रेडेंशियल रिफ्रेश — असल में उन्हीं समस्याओं के लिए पहले से बनी हुई प्लंबिंग हैं जिन्हें ChatPRD टीम ने हाथ से सुलझाया था। यह एक सामान्य पैटर्न है: जो एक टीम इस साल खुद बनाती है, उसे अगले साल कोई प्लेटफ़ॉर्म वेंडर प्रोडक्ट के रूप में पेश कर देता है। इससे हार्नेस-इंजीनियरिंग की भूमिका खत्म नहीं होती; यह बस न्यूनतम स्तर को ऊपर उठा देता है और काम को हर एडेप्टर शुरू से लिखने के बजाय मैनेज्ड प्रिमिटिव्स को जोड़ने और कॉन्फ़िगर करने की ओर मोड़ देता है — ठीक वैसे ही जैसे क्लाउड इंफ्रास्ट्रक्चर ने ऑप्स इंजीनियरों को खत्म नहीं किया, बल्कि यह बदल दिया कि वे अपना समय किस पर खर्च करते हैं।
अगर आप इस भूमिका को अपना लक्ष्य बना रहे हैं तो इसका क्या मतलब है
अगर आप इस काम में विश्वसनीय दिखना चाहते हैं तो पोर्टफोलियो या रिज़्यूमे में डालने लायक कुछ ठोस, जांचने योग्य चीज़ें: किसी ऐसे असली API के खिलाफ, जिस पर आपका नियंत्रण नहीं है, एक एडेप्टर को शुरू से आखिर तक बनाएं (ऑथ, एरर हैंडलिंग, रेट लिमिट्स सब शामिल हों, सिर्फ आसान-रास्ते वाला डेमो नहीं); एक एजेंट के लिए ऐसा परमिशन मॉडल डिज़ाइन और दस्तावेज़ित करें जो read/propose/act कार्रवाइयों में फर्क करे और यह दिखाए कि हर सीमा वहीं क्यों है; और एक ऐसा रिव्यू इंटरफ़ेस बनाएं या कॉन्फ़िगर करें जिसमें इंसान एजेंट की कार्रवाइयों को चलने से पहले मंज़ूरी दे, क्योंकि यही वह हिस्सा है जिस पर ज़्यादातर कंपनियां किसी एजेंट को प्रोडक्शन छूने देने से पहले ज़ोर देंगी। अगर आप किसी हार्नेस-इंजीनियरिंग नौकरी के प्रस्ताव को परख रहे हैं या अपनी खुद की ज़िम्मेदारियों का दायरा तय कर रहे हैं, तो खासतौर पर यह पूछें कि परमिशन मॉडल का मालिक कौन है, एडेप्टर्स का मालिक कौन है, और ह्यूमन-रिव्यू सतह का मालिक कौन है — अभी बहुत सी टीमों में इन तीनों चीज़ों का कोई स्पष्ट मालिक नहीं है, और यही वह खाली जगह है जिसे भरने के लिए यह भूमिका आकार ले रही है।
एक बात साफ तौर पर कह देनी ज़रूरी है: ऊपर दिए गए किसी भी स्रोत से इस खास पदनाम के लिए कोई हायरिंग-मार्केट आंकड़ा नहीं मिलता, और "हार्नेस इंजीनियर" अभी तक ऐसा जॉब टाइटल नहीं है जो आपको नौकरी की पोस्टिंग्स में दिखेगा — यह "AI इन्फ्रास्ट्रक्चर इंजीनियर," "एजेंट प्लेटफ़ॉर्म इंजीनियर," या सीधे "सीनियर बैकएंड इंजीनियर, AI सिस्टम्स" जैसे टाइटलों के भीतर छिपा दिख रहा है। इसे LinkedIn पर खोजने लायक कोई टाइटल न मानें, बल्कि एक ऐसा कौशल-सेट मानें जिसे बनाना और सही ढंग से बताना है।