AI agents अब किसी काम को करने का तरीका खुद चुन सकते हैं, पहले से तय प्रक्रिया के हर चरण का पालन करना ज़रूरी नहीं रहा। यह लचीलापन उपयोगी है, लेकिन इससे यह बदल जाता है कि एंटरप्राइज़ एप्लिकेशन को आगे होने वाली हर चीज़ पर नियंत्रण कैसे रखना होगा।
जब एक जानी-पहचानी प्रक्रिया अनजाना मोड़ ले ले
एक मैन्युफैक्चरिंग कंपनी एक अहम प्रोडक्शन रन की तैयारी कर रही है, तभी एक सप्लायर बताता है कि एक ज़रूरी कंपोनेंट तीन हफ़्ते देर से पहुँचेगा। परचेज़िंग मैनेजर को जल्दी से कोई विकल्प चाहिए, लेकिन विकल्प ढूँढना सिर्फ़ कीमतें देखने तक सीमित नहीं है। डिलीवरी शेड्यूल, मौजूदा कॉन्ट्रैक्ट, सप्लायर की मंज़ूरियाँ और इन्वेंटरी की उपलब्धता, इन सबका ध्यान रखना पड़ता है।
एक पारंपरिक एंटरप्राइज़ एप्लिकेशन में मैनेजर यह जानकारी जुटाने के लिए कई सिस्टम से गुज़र सकता है। कुछ चरण पहले से automated हो सकते हैं, जैसे मंज़ूर सप्लायरों की जाँच करना या खरीद के अनुरोध को मंज़ूरी के लिए आगे भेजना। प्रक्रिया परिष्कृत हो सकती है, लेकिन उसकी मुख्य गतिविधियाँ और निर्णय के रास्ते आमतौर पर डेवलपमेंट के दौरान ही तय हो जाते हैं।
अब सोचिए कि मैनेजर किसी AI agent से कहता है कि वह दो हफ़्ते के भीतर डिलीवरी दे सकने वाला वैकल्पिक सप्लायर खोजे, विकल्पों की तुलना करे और कोई समाधान सुझाए। agent सप्लायर डेटाबेस देखता है, इन्वेंटरी जाँचता है और डिलीवरी शेड्यूल की समीक्षा करता है। जब कोई भी मंज़ूर सप्लायर समय-सीमा पूरी नहीं कर पाता, तो वह विकल्प खोजता है और ऐसी जानकारी पहचानता है जिसकी आगे जाँच ज़रूरी है।
असली फ़र्क यह नहीं है कि सॉफ़्टवेयर ने अचानक फ़ैसले लेना सीख लिया है। एंटरप्राइज़ एप्लिकेशन दशकों से ऐसा कर रहे हैं। बदलाव यह है कि AI agent काम चलते-चलते अपने कुछ अगले कदम खुद तय कर सकता है, उसे पूरी तरह पहले से तय क्रम पर निर्भर नहीं रहना पड़ता।
इससे एक आर्किटेक्चर का सवाल खड़ा होता है: agent को आगे क्या होगा, यह तय करने की कितनी आज़ादी मिलनी चाहिए, और एंटरप्राइज़ सिस्टम को नियंत्रण कहाँ अपने पास रखना चाहिए?
पहले से तय workflow से AI-निर्देशित execution तक
पारंपरिक workflow automation उन प्रक्रियाओं पर बनता है जिन्हें डेवलपर पहले से डिज़ाइन करते हैं। उदाहरण के लिए, इनवॉइस-प्रोसेसिंग सिस्टम किसी सप्लायर को verify कर सकता है, इनवॉइस को परचेज़ ऑर्डर से मिला सकता है, मंज़ूरी की सीमाएँ जाँच सकता है और भुगतान शुरू कर सकता है। अलग-अलग परिस्थितियाँ अलग रास्तों पर ले जा सकती हैं, और मंज़ूरियों के इंतज़ार में प्रक्रिया कई दिनों तक चल सकती है।
ये सिस्टम न तो सरल हैं और न पुराने पड़ चुके हैं। workflow engines पहले से जटिल समन्वय, retries और रुकावटों से उबरने की सुविधा देते हैं। उदाहरण के लिए, Temporal का दस्तावेज़ बताता है कि workflows विफलताओं के बावजूद execution की प्रगति कैसे सुरक्षित रख सकते हैं।
AI agents प्रक्रिया में लचीलापन एक अलग बिंदु पर लाते हैं। जाँच के हर चरण को पहले से तय करने के बजाय, डेवलपर agent को एक लक्ष्य, इस्तेमाल की अनुमति वाले tools का समूह और उनके उपयोग की सीमाएँ दे सकते हैं। फिर agent उपयुक्त tool चुन सकता है, उसके नतीजे की जाँच कर सकता है और तय कर सकता है कि आगे कौन-सी जानकारी जुटानी है।
सप्लायर वाले उदाहरण में agent को पता चल सकता है कि कोई वैकल्पिक कंपोनेंट किसी मौजूदा सप्लायर से उपलब्ध है। फिर वह खोज आगे बढ़ाने से पहले जाँच सकता है कि वह कंपोनेंट ज़रूरी specifications पूरी करता है या नहीं। जाँच का यह रास्ता शायद स्पष्ट रूप से प्रोग्राम न किया गया हो।
इसका मतलब यह नहीं कि agents बिना किसी पाबंदी के काम करते हैं। डेवलपर उनके tools सीमित कर सकते हैं, अनुरोधों को validate कर सकते हैं और कुछ ऑपरेशनों के लिए मंज़ूरी अनिवार्य कर सकते हैं। agent किसी स्थापित workflow के भीतर भी काम कर सकता है, जहाँ वह लचीली जाँच संभालता है और आसपास का एप्लिकेशन बिज़नेस प्रक्रिया को संभालता है।
यह मेल एंटरप्राइज़ आर्किटेक्चर के लिए खास तौर पर प्रासंगिक है। संगठन को जानकारी जुटाने और सिफ़ारिशें तैयार करने के तरीके में लचीलापन मिलता है, और बिज़नेस ऑपरेशन कैसे चलाए जाएँ, इस पर नियंत्रण भी नहीं छोड़ना पड़ता।
जब सिफ़ारिश बिज़नेस एक्शन बन जाए
परचेज़िंग agent आखिरकार एक ऐसा सप्लायर ढूँढ लेता है जो दस दिन में डिलीवरी दे सकता है। कीमत मौजूदा समझौते से ज़्यादा है, लेकिन प्रोडक्शन में देरी की लागत के मुकाबले यह अतिरिक्त खर्च उचित लगता है।
agent ऑर्डर देने की सिफ़ारिश करता है।
यहाँ काम की प्रकृति बदल जाती है। उपयुक्त सप्लायर ढूँढना एक जाँच-पड़ताल की गतिविधि है, जबकि ऑर्डर देना वित्तीय प्रतिबद्धता पैदा करता है। agent के पास खरीद की सिफ़ारिश करने लायक जानकारी हो सकती है, फिर भी उसे उसे execute करने का अधिकार न हो।
कंपनी के परचेज़िंग सिस्टम को फिर भी सप्लायर की पात्रता verify करनी होगी, खर्च की सीमाएँ जाँचनी होंगी और तय करना होगा कि अतिरिक्त मंज़ूरी चाहिए या नहीं। ये नियंत्रण सिर्फ़ इस पर निर्भर नहीं होने चाहिए कि agent कंपनी की नीति को कैसे समझता है।
यह भेद तब और अहम हो जाता है जब agents कई एंटरप्राइज़ सिस्टम तक पहुँच सकते हैं। किसी agent को सप्लायर कॉन्ट्रैक्ट पढ़ने की अनुमति हो सकती है, पर उन्हें बदलने की नहीं। उसे ऑर्डर तैयार करने की इजाज़त हो सकती है, पर जमा करने की नहीं। भले ही वह किसी समर्पित identity के तहत काम करे, वह identity अपने आप हर कार्रवाई का अधिकार नहीं दे देती।
agent identity पर NIST का मार्गदर्शन इस बात को पुष्ट करता है कि जब agents उपयोगकर्ताओं और संगठनों की ओर से कार्रवाई करने लगें, तब स्थापित identity और authorization सिद्धांत कितने ज़रूरी हैं।
जब agents काम आगे सौंपें, तब भी यही सीमाएँ बनी रहनी चाहिए। अगर परचेज़िंग agent किसी दूसरे agent से कॉन्ट्रैक्ट की समीक्षा करवाता है, तो दूसरे agent को सिर्फ़ उतनी ही पहुँच मिलनी चाहिए जितनी उस समीक्षा के लिए ज़रूरी है। यह पता चल जाना कि कोई कॉन्ट्रैक्ट समाप्त किया जा सकता है, उसे समझौता समाप्त करने की अनुमति नहीं देता।
ये ज़रूरतें जानी-पहचानी एंटरप्राइज़ सुरक्षा पद्धतियों पर टिकी हैं, खासकर least privilege access और नियंत्रित delegation पर। अतिरिक्त चुनौती इन्हें तब लागू करने की है जब tool calls और सौंपे गए कामों का क्रम execution के दौरान तय हो सकता है।
इससे निकला डिज़ाइन सिद्धांत सीधा है: agent यह तय कर सकता है कि कौन-सी कार्रवाई प्रस्तावित करनी है, लेकिन उसे अंजाम देने वाले सिस्टमों को स्वतंत्र रूप से यह स्थापित करना होगा कि वह कार्रवाई अनुमत है या नहीं।
जब कार्रवाई सफल हो जाए पर agent को पता न चले
सप्लायर मंज़ूर हो जाने के बाद परचेज़िंग मैनेजर ऑर्डर को अधिकृत करता है। agent अनुरोध जमा करता है, और परचेज़िंग सिस्टम परचेज़ ऑर्डर सफलतापूर्वक बना देता है।
लेकिन पुष्टि agent तक पहुँचने से पहले कनेक्शन टूट जाता है।
जब agent दोबारा काम शुरू करता है, तो उसे एक अधूरा काम दिखता है। अगर वह यह जाँचे बिना कि क्या हुआ था, ऑर्डर फिर से जमा कर दे, तो कंपनी के पास दो परचेज़ ऑर्डर हो सकते हैं।
यह AI से पैदा हुई कोई नई समस्या नहीं है। distributed applications लंबे समय से ऐसी स्थितियों का सामना करते रहे हैं जहाँ ऑपरेशन सफल हो जाता है लेकिन उसकी पुष्टि खो जाती है। यहाँ इस समस्या को प्रासंगिक बनाने वाली बात यह है कि agent अधूरी जानकारी के आधार पर काम दोबारा शुरू कर सकता है और अपनी अगली कार्रवाई तय कर सकता है।
एक भरोसेमंद एप्लिकेशन agent की अनिश्चितता को इस बात का सबूत नहीं मान सकता कि ऑपरेशन विफल रहा। दोबारा कोशिश ज़रूरी है या नहीं, यह तय करने से पहले उसे प्रामाणिक बिज़नेस सिस्टम से जाँच करनी होगी।
एक स्थापित सुरक्षा उपाय idempotency key है, यानी एक स्थिर पहचानकर्ता जो सहायक सेवा को एक ही ऑपरेशन के दोहराए गए अनुरोधों को पहचानने देता है। सही ढंग से लागू होने पर यह किसी retry को डुप्लिकेट लेन-देन बनाने से रोक सकता है। अन्य उपायों में लेन-देन की स्थिति जाँचना और नतीजे का उस सिस्टम से मिलान करना शामिल है जिसने ऑपरेशन किया था।
आधुनिक agent प्लेटफ़ॉर्म sessions को सुरक्षित रखने और बाधित काम को बहाल करने की सुविधाएँ देते हैं। लेकिन agent के execution environment को बहाल करना और यह पुष्टि करना कि उसकी बाहरी कार्रवाइयाँ सही ढंग से पूरी हुईं, दो अलग बातें हैं। Microsoft का long-running agent resilience दस्तावेज़ इस भेद को स्पष्ट करता है, और प्रगति सुरक्षित रखने तथा duplicate-effect रोकने की अहम ज़िम्मेदारियाँ एप्लिकेशन पर छोड़ता है।
इसलिए परचेज़ ऑर्डर से मिली सीख बहाली से कहीं व्यापक है। agent को याद रह सकता है कि उसने क्या कोशिश की थी, लेकिन असल में क्या हुआ, यह एंटरप्राइज़ सिस्टम को ही स्थापित करना होगा।
एंटरप्राइज़ आर्किटेक्चर में जो बदलता है
सप्लायर का उदाहरण आर्किटेक्चर के फ़र्क को साफ़ कर देता है। agent ने एक अनजानी समस्या की जाँच की, tools चुने, विकल्पों को परखा और एक कार्रवाई सुझाई। फिर परचेज़िंग सिस्टम ने संगठन के नियम लागू किए, मंज़ूर ऑपरेशन को execute किया और उसके नतीजे को verify करने के लिए ज़रूरी रिकॉर्ड दिया।
फ़र्क लचीले निर्णय और नियंत्रित execution के बीच है। agent यह तय करने में मदद कर सकता है कि आगे क्या होना चाहिए, जबकि स्थापित एंटरप्राइज़ सेवाएँ अनुमतियाँ, बिज़नेस नियम और लेन-देन के सुरक्षा उपाय लागू करती हैं।
इसके लिए हर संगठन को अपना मौजूदा आर्किटेक्चर बदलने की ज़रूरत नहीं है। identity management, workflow engines, एप्लिकेशन इंटरफ़ेस और लेन-देन के नियंत्रण पहले की तरह ज़रूरी बने रहते हैं। बदलता यह है कि ये घटक ऐसे सॉफ़्टवेयर के साथ कैसे तालमेल बिठाते हैं जो अपने execution path के कुछ हिस्से गतिशील रूप से चुन सकता है।
इससे यह भी बदलता है कि आर्किटेक्ट को क्या मूल्यांकन करना होगा। सिर्फ़ यह परखना कि agent कोई काम सफलतापूर्वक पूरा कर सकता है, अब काफ़ी नहीं है। टीमों को समझना होगा कि तब क्या होता है जब agent कोई अनुपयुक्त tool चुन ले, अधूरी जानकारी से टकराए, काम किसी और को सौंपे, पहुँच खो दे या बाधित लेन-देन के बाद दोबारा शुरू हो। उचित नियंत्रण इस पर निर्भर करते हैं कि agent को जो कार्रवाइयाँ करने की अनुमति है उनके परिणाम क्या हैं।
कुछ एप्लिकेशनों के लिए, जैसे सार्वजनिक दस्तावेज़ों में खोज, ये नियंत्रण अपेक्षाकृत सरल हो सकते हैं। लेकिन जो एप्लिकेशन वित्तीय रिकॉर्ड, ग्राहक खाते या प्रोडक्शन इन्फ्रास्ट्रक्चर बदलते हैं, उनमें execution की सीमाओं पर कहीं ज़्यादा ध्यान चाहिए।
इसलिए AI agents एंटरप्राइज़ सॉफ़्टवेयर का एक अहम हिस्सा बदल रहे हैं: एप्लिकेशन यह कैसे तय करते हैं कि कौन-सी कार्रवाइयों का अनुरोध करना है। वे उन कार्रवाइयों को अंजाम देने से जुड़ी इंजीनियरिंग ज़िम्मेदारियाँ हटा नहीं रहे हैं।
अवसर यह है कि AI-निर्देशित जाँच के लचीलेपन को स्थापित एंटरप्राइज़ सिस्टमों की विश्वसनीयता के साथ जोड़ा जाए। आर्किटेक्चर की चुनौती इन दोनों क्षमताओं को साथ काम कराने की है, बिना agent की सिफ़ारिश को कार्रवाई की अनुमति समझ लिए।
इस श्रृंखला में आगे
लैपटॉप बंद करने के बाद: इंफ्रास्ट्रक्चर पर चलने वाले AI एजेंट को वास्तव में क्या चाहिए. लैपटॉप बंद करने से असाइनमेंट खोना नहीं चाहिए। जब AI एजेंट इंतज़ार करे, फेल हो या अपने बजट तक पहुँच जाए, तब एंटरप्राइज़ इंफ्रास्ट्रक्चर को क्या सुरक्षित रखना चाहिए?
और गहराई से जानें
हर स्रोत 9 October 2026 को खोलकर जाँचा गया था। Microsoft का पेज preview के रूप में चिह्नित सुविधाओं का वर्णन करता है, और Google Cloud का पेज vendor की घोषणा है।
- NIST: Why Agentic AI Needs a Strong Identity Foundation. प्रकाशित: 27 अगस्त 2026। उपयोगकर्ताओं और संगठनों की ओर से काम करने वाले AI agents के लिए प्रासंगिक identity और authorization सिद्धांत समझाता है।
- Temporal: Workflow Execution. टिकाऊ workflow execution और बहाली को समझाता है, जिससे यह समझने में मदद मिलती है कि पारंपरिक workflow सिस्टम पहले से क्या-क्या सँभाल सकते हैं।
- Microsoft: Long-Running Agent Resilience. बहाली की क्षमताओं का और बाहरी ऑपरेशन execute करते समय एप्लिकेशन के पास रहने वाली ज़िम्मेदारियों का वर्णन करता है।
- Google Cloud: Gemini at Work 2026. प्रकाशित: 8 अक्टूबर 2026। tool use, delegation और persistent work सहित एंटरप्राइज़-agent की क्षमताओं का संदर्भ देता है। यह किसी स्वतंत्र मूल्यांकन के बजाय vendor की घोषणा है।