निर्देशों के बजाय सीमाएँ: स्वायत्त AI-एजेंटों पर नियंत्रण कैसे बनाए रखें

AI-एजेंट जितने अधिक स्वायत्त होते जाते हैं, हम उतनी ही अधिक बार उन्हें आदतन तरीके से नियंत्रित करने की कोशिश करते हैं — प्रॉम्प्ट में नियम लिखते हैं: «इसे मत छुओ», «केवल वहीं काम करो», «कभी वह मत करो»। तीन समानांतर एजेंटों के साथ प्रयोग के दौरान मैंने दो दिनों में ऐसे मामलों का जीवंत संग्रह जुटाया जहाँ यह तरीका टूटता है — और जहाँ दूसरा तरीका काम करता है। लेख का सार सरल है: निर्देश एक विनती है जिसे एजेंट कुछ प्रायिकता के साथ पूरा करता है; सीमा सिस्टम का एक गुण है जो आज्ञापालन पर निर्भर नहीं करता। जब एजेंट एक था और निगरानी में काम करता था, तो अंतर शैलीगत लगता था। जब एजेंट कई हो गए, तो वह स्थापत्य-संबंधी निकला।

एक सत्र की पाँच घटनाएँ

नीचे दिए गए सभी मामले इस ब्लॉग पर एक ही कार्य-सत्र में हुए — वे प्रलेखित हैं, और हर एक दर्शाता है कि पाठ के माध्यम से प्रबंधन किस तरह विफल होता है।

निर्देश नहीं था — दुर्घटना हो गई। अपने कार्य की तैयारी में एजेंट ने git stash सामान्य निर्देशिका में निष्पादित किया और मेरी उन अन-कमिट फ़ाइलों को स्टैश में ले गया जिनका उसके कार्य से कोई संबंध नहीं था। किसी ने कुछ «तोड़ा» नहीं: निषेध ही मौजूद नहीं था। यह निर्देशों का मूलभूत गुण है — वे दुर्घटनाओं के बाद लिखे जाते हैं। एजेंट को क्या नहीं करना चाहिए, इसकी पूरी सूची लिखना असंभव है।

निर्देश था — और काम नहीं आया। पहली दुर्घटना के बाद मैंने एजेंटों को स्पष्ट नियम जोड़ा: «कड़ाई से अपनी कार्य निर्देशिका में ही काम करो»। एक एजेंट ने फिर भी मुख्य निर्देशिका में git-कमांड निष्पादित किया — बस उसे निरपेक्ष पथ से संबोधित किया। न द्वेष से और न मूर्खता से: मॉडल प्रायिक है, और पाठ्य नियम का पालन भी एक प्रायिकता है, जो संदर्भ की लंबाई और रनों की संख्या से गुणित होती है।

तकनीकी सीमा चुपचाप काम आई। उसी प्रयोग में सबसे अपेक्षित दुर्घटना एक बार भी नहीं हुई — «एक एजेंट ने सबकी ब्रांच बदल दी»। इसलिए नहीं कि एजेंट सावधान थे, बल्कि इसलिए कि git worktree भौतिक रूप से एक ब्रांच को दो कार्य-प्रतियों में लिखने की अनुमति नहीं देता। सुरक्षा उपकरण में अंतर्निहित है। उसे याद रखने की ज़रूरत नहीं, उसका पालन करने की ज़रूरत नहीं — वह बस है।

निर्देश वहाँ खड़ा था जहाँ सीमा होनी चाहिए थी। सबसे अप्रिय खोज: इस ब्लॉग के प्रोड को प्रॉम्प्ट की एक पंक्ति सुरक्षित रख रही थी। master में push स्वचालित डिप्लॉय शुरू करता है, और हर एजेंट को उससे केवल «कोई git push नहीं» पाठ अलग करता था। वह टिका रहा — पर यह भाग्य है, नियंत्रण नहीं: यहाँ असली सीमा पहुँच अधिकार, protected branch, लेखन-अधिकार-रहित टोकन है। विनती ताले की जगह खड़ी थी।

स्वयं एजेंट के ऊपर सीमा। सत्र में दो बार रनटाइम ने प्रयोगाधीन एजेंटों को नहीं, बल्कि मेरे मुख्य सहायक को रोका: अनुमति-वर्गीकरणकर्ता ने प्रोड-सर्वर तक SSH और अन-कमिट संपादनों के सामूहिक विलोपन को अवरुद्ध किया — ऐसी क्रियाएँ जो औपचारिक रूप से कार्य से अनुसरण करती थीं, पर स्पष्ट मानवीय «हाँ» माँगती थीं। दोनों अवरोध सही थे। और दोनों एजेंट के «अनुशासन» के ऊपर हुए, जो पूरी ईमानदारी से मानता था कि वह योजना के अनुसार कार्य कर रहा है।

सिद्धांत नया नहीं — केवल सत्ता नई है

इंजीनियरिंग ने यह सबक LLM से बहुत पहले सीख लिया था। Toyota की उत्पादन प्रणाली में सिद्धांत को poka-yoke: कहा जाता है: त्रुटि को प्रक्रिया का उपकरण रोकता है, निष्पादक की सतर्कता नहीं। वह पुर्ज़ा जो केवल सही दिशा में ही लगाया जा सकता है, «सही दिशा में लगाओ» पोस्टर से अधिक विश्वसनीय है। प्लेटफ़ॉर्म इंजीनियरिंग में इसे ही guardrails कहते हैं, सुरक्षा में — defense in depth। हर जगह एक ही विचार: इस पर निर्भर मत रहो कि निष्पादक ने पढ़ा, समझा और भूला नहीं — ऐसा करो कि गलत क्रिया असंभव या महँगी हो जाए।

“निर्देश एक विनती है। सीमा सिस्टम का गुण है। विनतियों पर टिका नियंत्रण नियंत्रण नहीं, संचयी प्रभाव वाला भाग्य है।”

– समानांतर एजेंटों के साथ दो दिनों के काम का मुख्य निष्कर्ष

AI-एजेंटों के साथ यह पुराना सिद्धांत तीन कारणों से और तीखा हो जाता है। एजेंट कई हैं — निर्देश की विफलता की प्रायिकता हर एजेंट के हर रन से गुणित होती है। एजेंट तेज़ हैं — «गलती शुरू होने» और «सब बिगड़ जाने» के बीच सेकंड बीतते हैं, मनुष्य हस्तक्षेप नहीं कर पाता। और एजेंट शाब्दिक हैं, पर विश्वसनीय नहीं: वे प्रॉम्प्ट का पाठ किसी भी जूनियर से अधिक मेहनत से निष्पादित करते हैं, फिर भी प्रायिक रूप से — और पैमाने पर नियमों का प्रायिक पालन उल्लंघन की गारंटी देता है।

व्यवहार में सीमाएँ कैसी दिखती हैं

इस सत्र के बाद मैंने जो परतें बनाईं — फ़ाइल सिस्टम से सत्यापन तक:

• फ़ाइल सिस्टम: हर एजेंट को अपनी कार्य-प्रति (git worktree, जिसे Anthropic अनुशंसित करता है समानांतर सत्रों के लिए, Claude Code में यह अंतर्निहित है), और OS स्तर पर — सैंडबॉक्स: Claude Code में sandboxing OS के मानक आदिम तत्वों से फ़ाइल सिस्टम और नेटवर्क को अलग करता है — Anthropic के आँकड़ों के अनुसार, इसने उनके आंतरिक अनुमति अनुरोधों को 84% तक घटा दिया, और सफल prompt-injection अंदर ही बंद रहता है।
• लेखन अधिकार: उत्पाद और मास्टर अधिकारों से सुरक्षित होते हैं, प्रॉम्प्ट से नहीं — protected branch, push के अधिकार के बिना टोकन, एजेंटों के लिए अलग खाते। प्रॉम्प्ट में छोड़ने के अनुरोध किए जा सकते हैं, पर दूसरी परत के रूप में।
• Runtime: worktree डेटाबेस, पोर्ट और कंटेनरों को अलग नहीं करता — वे सभी प्रतियों में साझा होते हैं। जो एजेंट टेस्ट और सर्वर चलाते हैं, उन्हें एकबारगी संसाधन चाहिए: अस्थायी डेटाबेस, अपना पोर्ट, प्रति एजेंट कंटेनर।
• क्रियाओं की अनुमतियाँ: अपरिवर्तनीय क्रियाएँ पुष्टि या क्लासिफायर से गुज़रती हैं — जैसे Claude Code में auto mode, जो हर क्रिया का मूल्यांकन करता है, बजाय इसके कि या तो हर बात पूछे या कुछ भी न पूछे। यह वह सीमा है जो केवल मनुष्य के स्पष्ट निर्णय से हिलती है।
• आर्टिफैक्ट्स से सत्यापन: एजेंट की स्व-रिपोर्ट पर नहीं, बल्कि डिस्क पर छोड़े गए निशानों पर भरोसा करें। मेरा अटका हुआ एजेंट इंटरफ़ेस में काम करता दिख रहा था; निदान उसकी प्रति में बीस मिनट तक नई फ़ाइलें न होने से हुआ। अपनी शाखा में कमिट — वही विचार: ऐसा परिणाम जो विफलता और एजेंट के आशावाद, दोनों से बचा रहे।

इस योजना में निर्देश कहीं गायब नहीं होते — वे पहली नहीं, अंतिम परत बन जाते हैं। प्रॉम्प्ट में «अपनी डायरेक्टरी में काम करो» अब भी उपयोगी है: यह प्रयासों की आवृत्ति घटाता है। पर प्रयास और दुर्घटना के बीच आशा नहीं, एक सीमा होनी चाहिए।

ईमानदार चेतावनियाँ

सीमा निरपेक्ष नहीं है: सैंडबॉक्स से बचा जा सकता है, क्लासिफायर गलतियाँ करते हैं, और प्रकाशित बायपास विश्लेषण यह नियमित रूप से दिखाते हैं। इसलिए सीमाएँ परतों में बनाई जाती हैं — जैसे सुरक्षा में सब कुछ। और सीमा शुरुआत में निर्देश से महँगी पड़ती है: worktree, अधिकार और सैंडबॉक्स सेट करना — घंटों का काम, प्रॉम्प्ट में एक पंक्ति लिखना — सेकंडों का। विषमता दूसरी जगह है: सीमा का भुगतान एक बार होता है, निर्देश का — हर रन पर विफलता की संभावना से। मेरे लिए आइसोलेशन की सेटिंग पहले ही पुनःआरंभ में फलदायी रही, जो बिना किसी टकराव के पूरा हुआ।

निष्कर्ष

श्रृंखला का प्रश्न है — AI-एजेंटों को वास्तविक काम में कैसे एकीकृत करें, नियंत्रण खोए बिना। इस लेख का उत्तर: नियंत्रण वह नहीं जो एजेंट को लिखा गया है, बल्कि वह जो उसके चारों ओर बना है। प्रॉम्प्ट में एक और «कभी X मत करो» जोड़ने से पहले, खुद से पूछें: क्या X को तकनीकी रूप से असंभव बनाया जा सकता है? यदि हाँ — तो प्रयासों की सही जगह वही है। प्रॉम्प्ट माँगे; मना सिस्टम को करना चाहिए।

स्रोत और संदर्भ

• Making Claude Code more secure and autonomous with sandboxing (Anthropic Engineering) — OS स्तर पर फ़ाइल सिस्टम और नेटवर्क का आइसोलेशन; 84% के आँकड़े का स्रोत।
• How we contain Claude across products (Anthropic Engineering, 2026) — एजेंट उत्पादों में निष्पादन सीमाएँ समग्र रूप से कैसे बनी हैं।
• How we built Claude Code auto mode (Anthropic Engineering) — अनुमति क्लासिफायर «हर बात पूछने» और «कुछ भी न पूछने» के बीच की सीमा के रूप में।
• Poka-Yoke (Lean Enterprise Institute) — प्रक्रिया-डिज़ाइन द्वारा त्रुटि रोकने का क्लासिक सिद्धांत।
• git-worktree और git-stash — Git का आधिकारिक दस्तावेज़: कार्य प्रतियों की यांत्रिकी और साझा स्टैश।
• Claude Code: Best practices for agentic coding (Anthropic Engineering) — समानांतर सत्रों के लिए worktree की सिफ़ारिश।
• अपने कोड पर LLM की ईमानदार तुलना कैसे करें: तीन Claude मॉडलों के साथ प्रयोग — श्रृंखला का पिछला लेख: वह प्रयोग जिसमें वर्णित घटनाएँ एकत्र की गईं।