AI एजेंट कब न बनाएं (इसके बजाय यह करें)

विषय सूची

अगस्त 2026 में प्रकाशित।

TL;DR: ज़्यादातर AI एजेंट आइडिया उस काम के लिए गलत टूल होते हैं। कोई भी एजेंट कोड लिखने से पहले मैं पांच अयोग्यता संकेतों की जांच करता हूं — अस्थिर प्रक्रिया, कम आवृत्ति, कोई पास/फेल टेस्ट न होना, कोई आसान टूल जो पहले से काम करता हो, या ऐसा अपरिवर्तनीय फेलियर मोड जिसके लिए मैं समय पर गेट नहीं बना सकता। अगर इनमें से एक भी सच है, तो मैं नहीं बनाता। इसके बजाय मैं सस्ते विकल्पों की एक सीढ़ी उतरता हूं, और तभी कस्टम एजेंट पर वापस लौटता हूं जब उस सीढ़ी पर कुछ भी नहीं टिकता।

[ऑपरेटर का दृष्टिकोण] मैं एक कंसल्टिंग ब्रांड और Pickleland — टेक्सास के प्फ्लुगर्विल में एक पिकलबॉल फैसिलिटी — में 30 से ज़्यादा एजेंट प्रोडक्शन में चलाता हूं। मैंने जितने एजेंट शिप किए हैं, कम से कम उतने ही आइडिया मार भी डाले हैं, और उनमें से लगभग कोई भी इसलिए नहीं मरा कि आइडिया बुरा था — वे इसलिए मरे क्योंकि उस खास काम के लिए एजेंट गलत टूल था। यह पोस्ट वह फ़िल्टर है जिसे मैं “क्या मुझे यह बनाना चाहिए” के “मैं इसे कैसे बनाऊं” में बदलने से पहले चलाता हूं।

डिफ़ॉल्ट जवाब है “नहीं”

जिस ROI फ्रेमवर्क का इस्तेमाल मैं करता हूं वह बताता है कि कोई ऑटोमेशन अपनी निर्माण और रखरखाव लागत वापस दिलाता है या नहीं। यह सही दूसरा सवाल है। पहला सवाल ज़्यादा सिंपल है और लगातार छोड़ दिया जाता है: क्या इसे वाकई एजेंट होने की ज़रूरत है?

“एजेंट” LLM से जुड़ी किसी भी चीज़ के लिए डिफ़ॉल्ट लेबल बन गया है, ठीक वैसे ही जैसे पंद्रह साल पहले “ऐप” स्क्रीन से जुड़ी किसी भी चीज़ के लिए डिफ़ॉल्ट लेबल बन गया था। मॉडल को छूने वाली हर चीज़ को एक स्थायी, स्वायत्त, टूल-कॉलिंग सिस्टम की ज़रूरत नहीं होती जो ट्रिगर्स पर नज़र रखे और खुद एक्शन ले। जिसे लोग “एजेंट बनाना” कहते हैं, उसमें से बहुत कुछ असल में “एक वाकई अच्छा प्रॉम्प्ट लिखना और उसे हाथ से चलाना” होता है, और यह कोई फेलियर मोड नहीं है — यह अक्सर सही अंतिम स्थिति ही होती है।

मैं “कस्टम एजेंट बनाना” को विकल्पों की सीढ़ी पर सबसे महंगा विकल्प मानता हूं, पहली सीढ़ी नहीं। इसे अपनाने से पहले, मैं जांचता हूं कि क्या काम खुद ही अयोग्य साबित हो जाता है।

पांच संकेत कि एजेंट गलत टूल है

इनमें से कोई भी एक, अकेले, आमतौर पर मुझे रोकने के लिए काफी होता है।

1. प्रक्रिया अभी स्थिर नहीं है। अगर वर्कफ़्लो पिछले महीने में दो बार बदला है क्योंकि बिज़नेस खुद अभी तय कर रहा है कि उसे क्या चाहिए, तो एक एजेंट आज के उस वर्जन को लॉक कर देता है जो फिर से बदलने वाला है। हर बार जब प्रक्रिया बदलेगी, आप प्रॉम्प्ट, टूल स्कीमा और इवैल सेट फिर से लिखेंगे — मतलब आप बिज़नेस चलाने के बजाय एक एजेंट को मेंटेन कर रहे होंगे। इसे तब तक मैनुअल चलाएं जब तक यह एक तिमाही तक स्थिर न रहे, फिर उस स्थिर वर्जन को ऑटोमेट करें।

2. यह पेबैक के लिए बहुत कम चलता है। साल में दो बार होने वाला काम इतने एक्ज़ीक्यूशन जमा नहीं करता कि निर्माण समय, टेस्टिंग समय और एक इवैल सेट को जस्टिफाई कर सके, चाहे बनने के बाद यह कितना भी अच्छा परफॉर्म करे। कम-आवृत्ति, ज़्यादा-बनाने-में-मेहनत, ऑटोमेशन के लिए लगभग सबसे बुरा क्वाड्रेंट है — आप पूरी निर्माण लागत चुकाते हैं और लगभग कोई बचत हासिल नहीं करते।

3. आप इसके लिए पास/फेल टेस्ट नहीं लिख सकते। अगर आप पहले से यह नहीं बता सकते कि सही आउटपुट कैसा दिखता है — इतनी अच्छी तरह कि उसे प्रोग्रामेटिक रूप से जांचा जा सके — तो आप इसके लिए इवैल हार्नेस नहीं बना सकते — और जिस एजेंट का आप मूल्यांकन नहीं कर सकते, उस पर आप अंधेरे में उड़ रहे होते हैं। ऐसे काम जो शुद्ध रूप से स्वाद (“क्या यह मेरे जैसा लगता है”) या बिना किसी लगातार रूब्रिक वाले शुद्ध जजमेंट के होते हैं, वे मैनुअल ही रहते हैं, या हर बार ह्यूमन-रिव्यू्ड रहते हैं, जो उन्हें ऑटोमेट करने के मकसद को ही हरा देता है।

4. कोई आसान टूल पहले से यह काम कर रहा है। एजेंट को स्कोप करने से पहले पूछें कि एक स्प्रेडशीट फॉर्मूला, एक सिंगल LLM-स्टेप वाला Zapier/Make/n8n वर्कफ़्लो, या एक सेव किया गया प्रॉम्प्ट आपको क्या दिलाएगा। अगर ईमानदार जवाब “90% रास्ता तय” है, तो आखिरी 10% शायद ही कभी अपने खुद के इन्फ्रास्ट्रक्चर, मॉनिटरिंग और मेंटेनेंस टैक्स वाले एजेंट को खड़ा करने को जस्टिफाई करे। मैंने ऐसे कामों के लिए एजेंट स्कोप किए हैं जिन्हें एक फ़िल्टर व्यू और एक रिकरिंग कैलेंडर रिमाइंडर उतनी ही अच्छी तरह हल कर देता।

5. फेलियर मोड अपरिवर्तनीय है और आपके पास गेट को सही तरीके से बनाने का समय नहीं है। कुछ एक्शन — एक मास ईमेल भेजना, एक रिफंड, एक पब्लिक पोस्ट — वापस नहीं लिए जा सकते। ह्यूमन-इन-द-लूप गेट ठीक इसी के लिए बने हैं, लेकिन एक जल्दबाज़ी में बनाया गया गेट जिसे कोई वाकई रिव्यू नहीं करता, बिना ऑटोमेशन के भी बुरा है: यह असल सब्सटेंस के बिना निगरानी का आभास पैदा करता है। अगर आपके पास गेट को सही तरीके से बनाने और स्टाफ़ करने का समय नहीं है, तो यह धीमा होने का संकेत है, गेट छोड़ देने की वजह नहीं।

अगर इनमें से पांचों लागू नहीं होते — प्रक्रिया स्थिर है, यह काफी बार चलता है, आप सही को परिभाषित कर सकते हैं, कोई आसान टूल इसे कवर नहीं करता, और फेलियर मोड या तो वापस लिया जा सकता है या ठीक से गेटेड है — तो इस पर ROI गणित चलाना उचित है।

बनाने से पहले जिस सीढ़ी को मैं उतरता हूं

जब कोई काम पांच जांचों में से किसी एक में फेल होता है — या इससे पहले भी — तो मैं इस लिस्ट को क्रम से नीचे उतरता हूं, और उस पहली सीढ़ी पर रुक जाता हूं जो वाकई समस्या हल कर देती है।

1. सीधे मॉडल से पूछें। कोई रैपर नहीं, कोई टूल कॉल नहीं, कोई स्थायी इन्फ्रास्ट्रक्चर नहीं। Claude खोलें, कॉन्टेक्स्ट पेस्ट करें, सवाल पूछें, जवाब इस्तेमाल करें। यह लोगों की उम्मीद से कहीं ज़्यादा वन-ऑफ और कभी-कभार होने वाले कामों को हैंडल कर लेता है, क्योंकि “एजेंट” वाली सहज प्रवृत्ति उन चीज़ों के लिए भी जग जाती है जिन्हें सिर्फ एक बार होना है।

2. एक सेव किया हुआ प्रॉम्प्ट या प्रोजेक्ट इंस्ट्रक्शन। अगर एक ही तरह का रिक्वेस्ट बार-बार आता है लेकिन हर बार इनपुट जुटाने और आउटपुट रिव्यू करने के लिए एक इंसान की ज़रूरत है, तो ट्रिगर को ऑटोमेट करने के बजाय प्रॉम्प्ट को एक टेम्प्लेट के रूप में सेव करें — प्रोजेक्ट इंस्ट्रक्शन, एक कस्टम इंस्ट्रक्शन सेट, एक स्निपेट। आपको इन्फ्रास्ट्रक्चर के बिना ही एजेंट जैसी कंसिस्टेंसी का फ़ायदा मिल जाता है।

3. एक सिंगल LLM-स्टेप वाला नो-कोड ऑटोमेशन टूल। ऐसे कामों के लिए जिन्हें वाकई एक ट्रिगर चाहिए (एक नया फ़ॉर्म सबमिशन, शीट में एक नई रो) लेकिन लॉजिक खुद सिंपल है, बीच में एक मॉडल कॉल वाला वर्कफ़्लो टूल कस्टम कोड से बनाने और मेंटेन करने में कहीं सस्ता पड़ता है। जब भी ट्रिगर स्टैंडर्ड हो और वॉल्यूम कम-से-मध्यम हो, मैं कस्टम इन्फ्रास्ट्रक्चर से पहले इसी की तरफ जाता हूं।

4. मैनुअल रूप से चलाया जाने वाला टेम्प्लेट। कुछ प्रक्रियाओं को ऑटोमेशन से ज़्यादा फ़ायदा एक चेकलिस्ट से होता है, क्योंकि वैल्यू एक इंसान के हर स्टेप पर सोचने में है, स्पीड में नहीं। जिन कामों में सोचना ही मुद्दा है, वहां सोच को ऑटोमेट करके ख़त्म न करें।

5. आउटसोर्सिंग। असली अस्पष्टता या जजमेंट वाली किसी भी चीज़ के लिए, जहां आपके पास इवैल सेट बनाने और मेंटेन करने का समय नहीं है, एक इंसान — एक VA, एक स्पेशलिस्ट, एक प्रोडक्टाइज्ड सर्विस प्रोवाइडर — अक्सर उस एजेंट से जल्दी शुरू हो जाता है और बीच रास्ते में ठीक करना आसान होता है, जिसे आप अभी भी ट्यून कर रहे हैं।

6. तभी: एक कस्टम एजेंट। अगर आप सीढ़ी उतर चुके हैं और उस पर कुछ भी नहीं टिकता — ट्रिगर को लोड के तहत असली जजमेंट चाहिए, वॉल्यूम मैनुअल या आउटसोर्स्ड हैंडलिंग के लिए बहुत ज़्यादा है, और यह ROI गणित पास करता है — तभी अपने खुद के रिलायबिलिटी स्टैक वाला एक पर्पस-बिल्ट एजेंट अपनी निर्माण लागत के काबिल साबित होता है।

दो-हफ़्ते का शैडो टेस्ट

किसी भी ऐसी चीज़ के लिए जो किनारे पर बैठी है — पांचों जांच पास करती है लेकिन फिर भी मुझे पूरा भरोसा नहीं है — मैं निर्माण शुरू करने से पहले दो-हफ़्ते का शैडो टेस्ट चलाता हूं। मैं खुद यह काम करता हूं, मॉडल को स्वायत्त सिस्टम के बजाय कोपायलट के रूप में इस्तेमाल करते हुए: वही प्रॉम्प्ट जो मैं आखिरकार एजेंट को दूंगा, वही इनपुट, लेकिन हर आउटपुट कहीं भी जाने से पहले मैं उसे खुद पढ़ता हूं।

उस टेस्ट से दो चीज़ें निकलती हैं। पहली, क्या मॉडल वाकई उस क्वालिटी बार पर काम में अच्छा है जो मुझे चाहिए — अगर मैं आधा आउटपुट हाथ से फिर से लिख रहा हूं, तो बाकी सब कुछ के बावजूद वह काम ऑटोमेट करने के लिए तैयार नहीं है। दूसरी, एक असली इवैल सेट: दो हफ़्तों के इनपुट और वे आउटपुट जिन्हें मैंने सही माना, ठीक वही हैं जो एक इवैल हार्नेस को चाहिए, और बनाने का फ़ैसला लेने तक मैंने आमतौर पर इसे मुफ़्त में जुटा लिया होता है।

शैडो टेस्ट प्रोडक्शन में जाने से पहले एज केस भी सामने ला देता है। मैनुअल ट्रायल के दौरान यह पता चलना कि 15% इनपुट को खास हैंडलिंग चाहिए, एजेंट शिप होने के बाद किसी कस्टमर कंप्लेंट से यह पता चलने की तुलना में कहीं सस्ता है।

एक आइडिया मारने के बाद मैं जो नियम लागू करता हूं

एजेंट आइडिया को मारना उसके पीछे की समस्या को मारने जैसा नहीं है। अगर कोई काम फ़िलहाल खुद को अयोग्य साबित कर देता है — प्रक्रिया अभी भी बदल रही है, वॉल्यूम बहुत कम है — तो मैं लिख लेता हूं कि क्यों, और एक मोटा री-चेक पॉइंट तय करता हूं (आमतौर पर किसी खास ट्रिगर से जुड़ा हुआ: “बुकिंग 50/हफ़्ता पार करने पर दोबारा जांचें,” सिर्फ़ एक तारीख नहीं)। जो एजेंट आइडिया एक बार मार दिए जाते हैं और फिर कभी दोबारा नहीं देखे जाते, वे चुपचाप स्थायी मैनुअल काम में बदल जाते हैं जिसे दोबारा जांचना किसी को याद नहीं रहता।

उल्टा अनुशासन भी उतना ही मायने रखता है: जो आइडिया पांचों जांच और ROI गणित पास कर लेता है, वह अपने-आप आज ही नहीं बन जाता। वह बाकी सब चीज़ों की तरह उसी क्यू में जाता है, उन ऑटोमेशन के मुकाबले रैंक होता है जो पहले से पेबैक साबित कर चुके हैं। फ़िल्टर पास करने से किसी काम को लाइन में जगह मिलती है, प्राथमिकता से छूट नहीं।

अक्सर पूछे जाने वाले प्रश्न

क्या यह सिर्फ ऑटोमेशन के खिलाफ दलील नहीं है?

नहीं — यह ऑटोमेशन के सबसे महंगे रूप को डिफ़ॉल्ट मान लेने के खिलाफ दलील है। ऊपर दी गई सीढ़ी के ज़्यादातर विकल्प अब भी ऑटोमेशन ही हैं; वे बस हल्के हैं। मैं दर्जनों एजेंट प्रोडक्शन में चलाता हूं। मुद्दा बनाने से बचना नहीं है; मुद्दा है सीधे “कस्टम एजेंट बनाओ” पर कूद जाना बंद करना, जब एक सेव किया हुआ प्रॉम्प्ट या नो-कोड वर्कफ़्लो निर्माण और मेंटेनेंस लागत के एक छोटे हिस्से में वही नतीजा दे देता है।

अगर काम का वॉल्यूम बाद में साफ़ तौर पर बढ़ने वाला है तो?

यह मौजूदा नंबरों से आगे बढ़कर बनाने की एक जायज़ वजह है — मैंने इस अपवाद को ROI फ्रेमवर्क में कवर किया है। लेकिन यह ऊपर दिए गए पांच संकेतों को ओवरराइड नहीं करता। अगर प्रक्रिया अभी भी अस्थिर है या आप अभी सही आउटपुट परिभाषित नहीं कर सकते, तो बढ़ता वॉल्यूम बस इतना मतलब रखता है कि आप एक बड़े पैमाने पर टूटे हुए एजेंट को मेंटेन करेंगे। पहले अस्थिरता और टेस्टेबिलिटी ठीक करें; एक बार वे हल हो जाएं तो स्केल जल्दी बनाने की वजह है, उन्हें छोड़ने की वजह नहीं।

मुझे कैसे पता चले कि नो-कोड टूल स्टेप “काफी अच्छा” है या कस्टम कोड चाहिए?

पहले इसे आज़माएं और अपने इवैल सेट के खिलाफ मापें, भले ही वह अनौपचारिक ही क्यों न हो। नो-कोड LLM स्टेप सिंगल-पर्पज़, सिंगल-इनपुट कामों को अच्छी तरह हैंडल करते हैं। जैसे ही आपको मल्टी-स्टेप टूल यूज़, रन्स के बीच स्थायी स्टेट, या ऐसा कंडीशनल लॉजिक चाहिए जिसे टूल का बिल्डर साफ़-साफ़ एक्सप्रेस नहीं कर सकता, वे दबाव में आने लगते हैं। अगर आप उस दीवार से टकराते हैं, तो यह कस्टम इन्फ्रास्ट्रक्चर पर जाने का असली संकेत है — वहां से शुरू करने की वजह नहीं।

क्या यह इंटरनल टूल्स पर कस्टमर-फेसिंग टूल्स से अलग तरह से लागू होता है?

पांचों संकेत एक ही तरह से लागू होते हैं, लेकिन दांव अलग होते हैं। अस्थिर प्रक्रिया वाला एक इंटरनल टूल टूटने पर सिर्फ़ आपकी खुद की टीम का समय बर्बाद करता है। अस्थिर प्रक्रिया वाला एक कस्टमर-फेसिंग टूल उन लोगों का भरोसा कमज़ोर करता है जिन्होंने आपका इवैल सेट बनने के लिए साइन अप नहीं किया था। मैं ख़ासतौर पर कस्टमर-फेसिंग ऑटोमेशन को संकेत पांच के सख़्त वर्जन पर रखता हूं — “ठीक से गेटेड” का बार तब ऊंचा होता है जब गलती के दूसरी तरफ कोई सहकर्मी नहीं बल्कि कोई अजनबी हो।

आप सबसे आम तौर पर किस वजह से एजेंट आइडिया मारते हैं?

संकेत तीन — कोई साफ़ पास/फेल टेस्ट न होना। स्कोपिंग के दौरान इसे मिस करना सबसे आसान है क्योंकि काम तब तक अच्छी तरह परिभाषित लगता है जब तक आप पहले से यह लिखने की कोशिश नहीं करते कि सही आउटपुट असल में कैसा दिखता है। अगर मैं इसे एक या दो वाक्यों में नहीं कर सकता, तो मुझे पता चल जाता है कि एजेंट का मूल्यांकन नहीं किया जा सकेगा, यानी उसे सुधारा नहीं जा सकेगा, यानी वह अभी नहीं बनेगा।