कंट्रोल प्लेन: बड़े पैमाने पर एजेंटिक AI का संचालन

यह गाइड एक प्रमुख कनाडाई बैंक के इंजीनियरिंग लीडर्स के लिए एक श्वेतपत्र के रूप में शुरू हुई थी। वे शून्य से शुरुआत नहीं कर रहे थे। उनके पास LangGraph पर प्री-प्रोडक्शन में एजेंट्स थे: Postgres में चेकपॉइंटिंग, विशेषज्ञ भूमिकाओं के लिए सबग्राफ, मानवीय समीक्षा के लिए interrupt() तैयार। उन्होंने दस्तावेज़ पढ़े थे और वास्तविक चीजें बनाई थीं। इसलिए जब मैं ऑर्केस्ट्रेशन के बारे में बात करने गया, तो एक प्रिंसिपल इंजीनियर ने एकमात्र पूछने लायक सवाल पूछा: “हमारे पास पहले से ही LangGraph है। इसमें परसिस्टेंस है, इसमें ह्यूमन-इन-द-लूप है, इसमें स्टेट है। हम बीच में कुछ और क्यों डालें?”

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

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

इनर लूप और आउटर लूप

इनर लूप वह है जिसे एक फ्रेमवर्क एक कार्य प्राप्त करने और परिणाम उत्पन्न करने के बीच चलाता है। प्रॉम्प्ट को इकट्ठा करें, लक्ष्य के बारे में तर्क करें, एक टूल चुनें, उसे कॉल करें, आउटपुट पढ़ें, मेमोरी अपडेट करें, तय करें कि फिर से लूप करना है या नहीं। LangGraph, CrewAI, और OpenAI एजेंट्स SDK इसमें वास्तव में अच्छे हैं, और वे तेजी से सुधार कर रहे हैं। मुझे उन्हें बदलने में कोई दिलचस्पी नहीं है, और न ही आपको होनी चाहिए। यदि आपकी टीम LangGraph में उत्पादक है, तो यह एक संपत्ति है।

आउटर लूप वह सब कुछ है जिसे संस्था उस चक्र के चारों ओर लपेटने के लिए बाध्य है। यह बुद्धिमत्ता नहीं है। यह जवाबदेही है। दोनों लूप के अलग-अलग मालिक, अलग-अलग जीवनकाल और अलग-अलग दर्शक होते हैं।

इनर लूप (एजेंट फ्रेमवर्क के स्वामित्व में)	आउटर लूप (कंट्रोल प्लेन के स्वामित्व में)
तर्क और योजना	ऑडिट ट्रेल जो कस्टम लॉगिंग के बिना मौजूद है
टूल चयन और आह्वान	पहचान और प्राधिकरण के साथ मानवीय अनुमोदन
प्रॉम्प्ट असेंबली और कॉन्टेक्स्ट प्रबंधन	एसएलए, एस्केलेशन और ड्यूरेबल टाइमर
अल्पकालिक और प्रासंगिक मेमोरी	डेटा के रूप में नीति, कंप्लायंस के स्वामित्व में
खराब आउटपुट पर स्व-सुधार और पुनः प्रयास	लंबे समय तक चलने वाले काम का वर्जनिंग और माइग्रेशन
संरचित आउटपुट और आर्टिफैक्ट उत्पादन	एक ही स्थान पर घटना की जांच
मॉडल चयन और टोकन अर्थशास्त्र	एटॉमिक कैंसिलेशन और मुआवजा

महत्वपूर्ण दावा यह नहीं है कि फ्रेमवर्क में आज इन सुविधाओं की कमी है। यह है कि वे संरचनात्मक रूप से उनके लिए गलत घर हैं। एक फ्रेमवर्क आपके एप्लिकेशन प्रोसेस के अंदर चलता है। इसका स्टेट स्टोर इसलिए मौजूद है ताकि ग्राफ फिर से शुरू हो सके, न कि इसलिए कि एक ऑडिटर प्रमाणित कर सके। इसका प्राधिकरण संदर्भ वही है जो आपके एप्लिकेशन ने पास किया था। इसका जीवनकाल एक डिप्लॉय का जीवनकाल है। आउटर लूप की आवश्यकताएं संस्थागत हैं: उन्हें प्रोसेस, डिप्लॉय, टीम पुनर्गठन और कभी-कभी स्वयं फ्रेमवर्क से अधिक समय तक जीवित रहना पड़ता है। एक LangGraph चेकपॉइंटर फिर से शुरू करने के लिए इंजीनियरिंग का एक अच्छा टुकड़ा है। इसे कभी भी सबूत के रूप में डिजाइन नहीं किया गया था। OpenAI एजेंट्स SDK में गार्डरेल्स उसी प्रोसेस में चलते हैं जिस एजेंट की वे रक्षा करते हैं, जो ठीक वही जगह है जहाँ एक नियंत्रण नहीं रहना चाहिए। निष्पक्ष होने के लिए, इन फ्रेमवर्क (LangSmith, LangGraph Platform, और उनके समकक्ष) के आसपास के होस्टेड प्लेटफॉर्म वास्तविक ऑब्जर्वेबिलिटी और ऑप्स टूलिंग जोड़ते हैं। लेकिन वे जो जोड़ते हैं वह डेवलपर-उन्मुख और फ्रेमवर्क-बाउंड है। आउटर लूप के दर्शकों में ऐसे लोग शामिल हैं जो कभी ट्रेस व्यूअर नहीं खोलेंगे: कंप्लायंस अधिकारी, आंतरिक ऑडिट, ऑपरेशंस, और अंततः एक नियामक।

आउटर लूप के पांच दायित्व

जब मैंने मूल श्वेतपत्र लिखा था, तो मैंने सूची को तब तक छोटा करता रहा जब तक कि वास्तविक समीक्षाओं के संपर्क में आने वाले दायित्व ही नहीं बचे। पांच बचे।

1. एक ऑडिट ट्रेल जो कस्टम लॉगिंग के बिना मौजूद है

परीक्षण सरल है: क्या आप यह पुनर्निर्माण कर सकते हैं कि क्या हुआ था, बिना किसी डेवलपर के इसे लॉग करना याद रखे? यदि उत्तर एजेंट कोड में बिखरे हुए logger.info() कॉल्स पर निर्भर करता है, तो आपके पास ऑडिट ट्रेल नहीं है। आपके पास एक डायरी है, जिसे स्वयंसेवकों द्वारा रखा गया है।

एक ऑडिटर के प्रश्न विशिष्ट होते हैं। इस मामले की शुरुआत किसने की? सिस्टम को प्रत्येक चरण में क्या पता था? किस नीति का कौन सा संस्करण, किन इनपुट के साथ मूल्यांकन किया गया था? कार्रवाई को किसने मंजूरी दी, और किस अधिकार के तहत? एप्लिकेशन लॉग इनमें से किसी का भी विश्वसनीय रूप से जवाब नहीं देते हैं। उन्हें नमूना लिया जाता है, दिनों में मापी गई प्रतिधारण अनुसूचियों पर घुमाया जाता है, पाइपलाइन कॉन्फ़िग द्वारा उत्परिवर्तित किया जाता है, और एक डेवलपर ने गुरुवार को शाम 4 बजे जो दिलचस्प सोचा था, उसके अनुसार आकार दिया जाता है। उनसे एक मामले का पुनर्निर्माण पुरातत्व है, और पुरातत्व वह है जो आप तब करते हैं जब सभ्यता रिकॉर्ड रखने में विफल रही।

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

2. पहचान और प्राधिकरण के साथ ह्यूमन-इन-द-लूप

हर फ्रेमवर्क अब एक पॉज़ प्रिमिटिव भेजता है। LangGraph में interrupt() है। दूसरों के पास समकक्ष हैं। एक पॉज़ एक अनुमोदन नहीं है। एक अनुमोदन एक पॉज़ प्लस एक प्राधिकरण मॉडल है, और प्राधिकरण मॉडल मुश्किल हिस्सा है।

वास्तविक संस्थागत अनुमोदन का अर्थ है: लोगों का एक परिभाषित समूह जो इस विशिष्ट कार्रवाई को अनुमोदित कर सकता है, एक डायरेक्टरी से हल किया गया, हार्डकोडेड नहीं। फोर-आईज़ (मेकर-चेकर) जहाँ मामले की शुरुआत करने वाला व्यक्ति उसे अनुमोदित करने वाला व्यक्ति नहीं हो सकता। राशि-आधारित रूटिंग, जहाँ $2,000 का अपवाद एक टीम लीड के पास जाता है और $200,000 का अपवाद एक नामित अधिकारी के पास जाता है। जब अनुमोदक छुट्टी पर हो तो प्रत्यायोजन, और जब कोई कार्रवाई न करे तो एस्केलेशन। और ठीक किसने, कब, किस संस्करण के केस डेटा पर क्लिक किया, इसका एक अपरिवर्तनीय रिकॉर्ड।

इनमें से कोई भी फ्रेमवर्क का काम नहीं है, और फ्रेमवर्क सही ढंग से इसका प्रयास नहीं करते हैं। लेकिन यह किसी का काम होना चाहिए। खतरनाक मध्यवर्ती स्थिति एक पॉज़ प्रिमिटिव है जो जो भी चैनल सुविधाजनक था, उससे जुड़ा हुआ है, यही कारण है कि अनुमोदन स्लैक मैसेज के रूप में समाप्त होते हैं। मैं नीचे उस विफलता पर वापस आऊँगा, क्योंकि मैंने इसे होते हुए देखा है।

3. समय एक फर्स्ट-क्लास सिटिजन के रूप में

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

इसका मतलब है ड्यूरेबल टाइमर, न कि setTimeout() और न ही एक क्रॉन जॉब जो एक टेबल पढ़ रहा है जिसे आपने शुक्रवार को लिखा था। इसका मतलब है डेटा के रूप में मॉडल किए गए एसएलए जिनके साथ एस्केलेशन चेन जुड़ी हुई हैं: यदि 48 घंटों में अनुमोदन नहीं दिया जाता है, तो प्रबंधक को सूचित करें; 72 पर, फिर से रूट करें। इसका मतलब है कि एक मामला तीन सप्ताह तक शून्य लागत पर निष्क्रिय रह सकता है और ठीक वहीं जाग सकता है जहाँ वह था। ड्यूरेबल एग्जीक्यूशन इंजन और BPMN इंजन दोनों इसे मूल रूप से करते हैं, क्योंकि दोनों उन लोगों द्वारा बनाए गए थे जिन्हें घर के बने संस्करण के टूटने पर पेज किया गया था। फ्रेमवर्क परसिस्टेंस में बेहतर हो रहे हैं, लेकिन फिर से शुरू करने के लिए परसिस्टेंस एस्केलेशन सिमेंटिक्स के साथ मॉडलिंग प्रिमिटिव के रूप में समय से एक छोटा वादा है।

4. डेटा के रूप में नीति, कंप्लायंस के स्वामित्व में

यहाँ वह पंक्ति है जिसे मैंने किसी भी अन्य की तुलना में अधिक मीटिंग में दोहराया है: बजट चेक मॉडल के अंदर नहीं रहता है।

यदि आपकी खर्च सीमा एक सिस्टम प्रॉम्प्ट में एक वाक्य है (“कभी भी $500 से ऊपर के रिफंड को मंजूरी न दें”), तो आपके पास नियंत्रण नहीं है। आपके पास एक स्टोकेस्टिक सिस्टम से विनम्रतापूर्वक किया गया एक अनुरोध है, एक ऐसे चैनल में जिसमें प्रतिकूल इनपुट भी लिखता है। प्रॉम्प्ट इंजेक्शन नाटकीय विफलता है, लेकिन सामान्य विफलता बदतर है: भले ही मॉडल हर बार अनुपालन करता हो, आप इसे साबित नहीं कर सकते। “हमने मॉडल को बताया” एक ऐसा वाक्य नहीं है जिसे आप आंतरिक ऑडिट से कहना चाहते हैं।

समीक्षा टिप्पणी: एक नीति जिसे आप मूल्यांकन करते हुए नहीं दिखा सकते, वह एक ऐसी नीति से अप्रभेद्य है जो आपके पास नहीं है। ऑडिटर्स ने एलएलएम के अस्तित्व में आने से बहुत पहले ही यह पता लगा लिया था।

पैटर्न डेटा के रूप में नीति है, जिसका मूल्यांकन मॉडल के बाहर किया जाता है, एजेंट के कार्य करने से पहले या बाद में लेकिन कभी भी उसके अंदर नहीं। डिसीजन टेबल (यदि आप BPMN दुनिया में हैं तो DMN, लेकिन एक रूल्स सर्विस या एक अच्छी तरह से परीक्षण किया गया नीति मॉड्यूल भी योग्य है) जिसे कंप्लायंस बिना कोड डिप्लॉय के पढ़, संस्करणित और बदल सकता है। एजेंट प्रस्ताव करता है: “$650 का रिफंड, यहाँ मेरा तर्क है।” नीति निपटान करती है: राशि थ्रेशोल्ड से अधिक है, मानवीय अनुमोदन के लिए रूट करें। श्रम का विभाजन स्पष्ट है। मॉडल निर्णय प्रदान करता है। टेबल सीमाएं प्रदान करती है। जब सीमा बदलती है, तो कंप्लायंस एक पंक्ति को संपादित करता है, परिवर्तन संस्करणित होता है, और कोई प्रॉम्प्ट इंजीनियर शामिल नहीं होता है।

5. ऑपरेबिलिटी

सबसे कम आकर्षक दायित्व, और वह जो तय करता है कि सिस्टम दूसरे वर्ष तक जीवित रहता है या नहीं। चार क्षमताएं, सभी उबाऊ, सभी आवश्यक।

संदर्भ खोए बिना पॉज़ और फिर से शुरू करें: न केवल एजेंट की मेमोरी, बल्कि पूरा मामला, जिसमें उसके टाइमर और लंबित अनुमोदन शामिल हैं। इन-फ्लाइट इंस्टेंस का माइग्रेशन: आपने प्रोसेस का संस्करण 3 डिप्लॉय किया, लेकिन 4,000 मामले अभी भी संस्करण 1 पर मध्य-उड़ान में हैं, और उनमें से कुछ हफ्तों तक चलेंगे; आपको पुरानी स्थिति को नई परिभाषाओं पर मैप करने या संस्करणों को जानबूझकर साथ-साथ चलने देने के लिए टूलिंग की आवश्यकता है। एटॉमिक कैंसिलेशन: जब एक मामले को मरना चाहिए, तो सब कुछ उसके साथ मर जाता है, जो कदम पहले ही प्रतिबद्ध हो चुके थे उनके लिए क्षतिपूर्ति क्रियाएं ट्रिगर होती हैं, और कोई अनाथ एजेंट शून्य में टूल्स को कॉल नहीं करता रहता है। और जांच करने के लिए एक जगह: जब ऑपरेशंस पूछता है “केस 8842 कहाँ है और यह क्यों अटका हुआ है,” तो जवाब एक स्क्रीन होना चाहिए, न कि चार सेवाओं और एक स्लैक थ्रेड में ग्रेप करना।

फ्रेमवर्क में इनमें से किसी के बारे में भी कहने के लिए लगभग कुछ भी नहीं है, और यह ठीक है। यह उनकी चिंता नहीं है। यह आपकी होनी चाहिए।

कंट्रोल प्लेन एक भूमिका है, उत्पाद नहीं

ऊपर सब कुछ एक भूमिका का वर्णन करता है। प्रौद्योगिकी के कम से कम तीन परिवार इसे भर सकते हैं, और मैंने तीनों को काम करते देखा है। ईमानदार तुलना उस श्रेणी से अधिक मायने रखती है जिसमें मेरा नियोक्ता होता है।

विकल्प A: एक BPMN इंजन

Camunda, Flowable, और उनके रिश्तेदार। ताकतें पांच दायित्वों पर लगभग एक-से-एक मैप करती हैं, क्योंकि वर्कफ़्लो इंजन एजेंट्स के अस्तित्व में आने से दो दशक पहले ठीक इसी तरह की समस्या के लिए बनाए गए थे। निष्पादन इतिहास मूल और पूर्ण है। पहचान, कैंडिडेट ग्रुप्स और फोर-आईज़ के साथ मानवीय कार्य अंतर्निहित हैं। टाइमर और एस्केलेशन मॉडल तत्व हैं जिन्हें आप इंगित कर सकते हैं। नीति के बाह्यकरण का डिसीजन टेबल में एक फर्स्ट-क्लास जवाब है। इंस्टेंस माइग्रेशन टूलिंग मौजूद है क्योंकि लंबे समय तक चलने वाली प्रक्रियाओं ने इसे आवश्यक बना दिया था। और प्रोसेस मॉडल गैर-इंजीनियरों द्वारा पठनीय है, जो तब तक नरम लगता है जब तक कि कंप्लायंस वास्तविक निष्पादन योग्य आर्टिफैक्ट पर हस्ताक्षर नहीं करता, बजाय इसके कि एक कॉन्फ्लुएंस पेज जो इससे भटक गया था।

संस्थागत आकार में दो और गुण मायने रखते हैं, और वे यही कारण हैं कि यह श्रेणी उन विनियमित-उद्योग मूल्यांकनों में जीतती रहती है जिनमें मैं बैठता हूँ। पहला, यहाँ स्केल अनुमानित के बजाय सिद्ध है: इस परिवार के इंजन पहले से ही दुनिया के कुछ सबसे बड़े बैंकों, बीमाकर्ताओं और खुदरा विक्रेताओं में कोर प्रोसेस चलाते हैं, और वर्तमान पीढ़ी को क्षैतिज रूप से स्केल्ड, उच्च-थ्रूपुट वर्कलोड के लिए ठीक से पुनर्गठित किया गया था, जिसका अर्थ है कि आप जिस एजेंट ट्रैफिक की योजना बना रहे हैं वह उस भुगतान ट्रैफिक से छोटा है जिसे ये इंजन पहले से ही वहन करते हैं। दूसरा, गवर्नेंस सरफेस एक उत्पाद है, परियोजना नहीं: एक फंसे हुए इंस्टेंस की जांच करने, एक घटना को फिर से चलाने, या दस हजार इन-फ्लाइट मामलों को माइग्रेट करने के लिए ऑपरेशंस टूलिंग ऑफ-द-शेल्फ मौजूद है, जिसके लिए एक विक्रेता जिम्मेदार है। जब एक एजेंट सुबह 2 बजे दुर्व्यवहार करता है, तो “ऑपरेशंस कंसोल खोलें” और “इवेंट स्टोर को ग्रेप करें” के बीच का अंतर एक घटना और एक आउटेज के बीच का अंतर है।

लागतें वास्तविक हैं। आप एक इंजन चलाते हैं, और इंजनों का परिचालन भार होता है। BPMN का एक सीखने का वक्र है, और कुछ डेवलपर्स को डायग्राम-एज़-कोड जैसी किसी भी चीज़ से एलर्जी की प्रतिक्रिया होती है। मॉडलिंग अनुशासन आवश्यक है; एक ढीला BPMN मॉडल ठीक ढीले कोड की तरह ही सड़ता है, बस अधिक स्पष्ट रूप से।

विकल्प B: एक ड्यूरेबल एग्जीक्यूशन रनटाइम

Temporal, Restate, और क्लाउड-नेटिव समकक्ष। ये इंजीनियरिंग के उत्कृष्ट टुकड़े हैं जिनमें उद्योग में सबसे मजबूत ड्यूरेबिलिटी सिमेंटिक्स हैं: इवेंट-सोर्स्ड हिस्ट्री, नियतात्मक रीप्ले, टाइमर और कई सप्ताह की नींद फर्स्ट-क्लास प्रिमिटिव के रूप में, और वर्कफ़्लो विकसित करने के लिए वर्जनिंग एपीआई। यदि आपका संगठन कोड-फर्स्ट है और विज़ुअल मॉडल से एलर्जी है, तो यह भूमिका को भरने का एक वैध तरीका है, और जिन टीमों का मैं सम्मान करता हूँ उन्होंने इसे किया है।

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

विकल्प C: एक अनुशासित घरेलू स्टेट मशीन

Postgres, एक state कॉलम, वर्कर्स, एक आउटबॉक्स टेबल। किसी को यह न कहने दें कि यह हमेशा गलत है। मामूली वॉल्यूम और एक स्थिर टीम के साथ एक प्रक्रिया के लिए, यह अक्सर सही पहला कदम होता है, और मैंने इसे अच्छी तरह से होते देखा है। कोई नया इंफ्रास्ट्रक्चर नहीं, पूर्ण नियंत्रण, हर पंक्ति समझी गई।

ट्रेड-ऑफ यह है कि अनुशासन भार-वहन करने वाला है और अनुशासन क्षय होता है। आप ड्यूरेबल टाइमर, एस्केलेशन और वर्जनिंग को फिर से लागू करेंगे, प्रत्येक लगभग 80% सही ढंग से। ऑडिट ट्रेल केवल आपके सबसे कमजोर कोड समीक्षक जितना अच्छा है। और किलर इन-फ्लाइट माइग्रेशन है: विफलता मोड पहले दिन नहीं, बल्कि अठारहवें महीने में है, जब प्रोसेस का संस्करण 3 संस्करण 1 पर चल रहे 4,000 इंस्टेंस से मिलता है और कोई टूलिंग नहीं है, केवल एक बहुत लंबा इंसिडेंट चैनल है।

दायित्व	BPMN इंजन	ड्यूरेबल एग्जीक्यूशन	घरेलू
कस्टम लॉगिंग के बिना ऑडिट ट्रेल	मूल	आंशिक (रीप्ले हिस्ट्री, डेवलपर-उन्मुख)	इसे बनाएं
पहचान, फोर-आईज़ के साथ मानवीय कार्य	मूल	इसे बनाएं	इसे बनाएं
ड्यूरेबल टाइमर, एसएलए, एस्केलेशन	मूल	मूल (एस्केलेशन: इसे बनाएं)	इसे बनाएं
डेटा के रूप में नीति, गैर-देव संपादन योग्य	मूल (डिसीजन टेबल)	जोड़ें (ओपा, रूल्स सर्विस)	इसे बनाएं
इन-फ्लाइट इंस्टेंस माइग्रेशन	टूलिंग मौजूद है	एपीआई मौजूद हैं, प्रयास आवश्यक है	अठारहवें महीने की घटना
कंप्लायंस द्वारा पठनीय	हाँ	नहीं	नहीं
परिचालन और सीखने की लागत	इंजन + BPMN वक्र	क्लस्टर + नियतात्मकता नियम	शुरू करने के लिए सबसे कम, बढ़ता है

अपनी संस्था कौन है, इसके आधार पर चुनें, न कि केवल इस टेबल के आधार पर। लेकिन जानबूझकर चुनें, क्योंकि डिफ़ॉल्ट (आउटर लूप कहीं नहीं, एप्लिकेशन कोड में फैला हुआ) एकमात्र विकल्प है जो हमेशा विफल रहता है।

एकीकरण पैटर्न: ऑर्केस्ट्रेट करें, बदलें नहीं

बैंक का डर, जो पहली नज़र में उचित था, यह था कि एक कंट्रोल प्लेन जोड़ने का मतलब उनके एजेंट्स को फिर से लिखना था। ऐसा नहीं है, और कोई भी आर्किटेक्चर जिसकी आवश्यकता होती है वह गलत है। जो पैटर्न काम करता है वह हर एजेंट को उसके मूल फ्रेमवर्क में रखता है और प्रोसेस मॉडल को उनके ऊपर रखता है।

प्रक्रिया ही एजेंट है, न कि किसी एक को साइड में कॉल करना।

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

विशेष रूप से, एक विवाद के मामले के लिए:

1. कंट्रोल प्लेन एक बिजनेस की और कोरिलेशन आईडी के साथ एक केस इंस्टेंस शुरू करता है। इस क्षण से एक इतिहास होता है।
2. एक नियतात्मक कदम खाता डेटा एकत्र करता है। कोई एजेंट नहीं। यह एक लुकअप है।
3. कंट्रोल प्लेन ट्रायज एजेंट को एक कार्य के रूप में आमंत्रित करता है। एजेंट अपने स्वयं के रनटाइम (LangGraph, CrewAI, जो भी टीम ने चुना) में रहता है और A2A पर एक पीयर एजेंट के रूप में पहुंचा जाता है, या इसकी क्षमताएं MCP पर टूल्स के रूप में उजागर होती हैं। इनर लूप पूरी तरह से फ्रेमवर्क के अंदर चलता है: तर्क, टूल कॉल, मेमोरी। कंट्रोल प्लेन प्रगति में एक कार्य देखता है, फिर एक आर्टिफैक्ट वापस आता है।
4. एजेंट का प्रस्ताव प्रोसेस वेरिएबल्स में आता है। एक डिसीजन टेबल इसका मूल्यांकन करती है: राशि, ग्राहक टियर, धोखाधड़ी स्कोर। थ्रेशोल्ड से नीचे, स्वतः आगे बढ़ें। इससे ऊपर, सही अनुमोदक समूह के लिए एक मानवीय कार्य बनाया जाता है, जिसमें फोर-आईज़ लागू और 48 घंटे का एस्केलेशन टाइमर सक्रिय होता है।
5. अनुमोदित होने पर, निष्पादन चरण चलता है। एजेंट के कार्य और अनुमोदक की पहचान सहित हर ट्रांजिशन पहले से ही इतिहास में है। किसी ने कुछ भी लॉग नहीं किया।

प्रोटोकॉल बाउंड्री ही इसे फ्रेमवर्क-अज्ञेयवादी बनाती है। A2A कंट्रोल प्लेन को एक एजेंट को कार्य सौंपने का एक मानक तरीका देता है जिसे वह होस्ट नहीं करता है और आर्टिफैक्ट वापस प्राप्त करता है, जिसमें एजेंट की टीम अपने स्टैक का पूर्ण स्वामित्व रखती है; मैंने A2A फील्ड गाइड में यांत्रिकी, कार्ड खोज और विफलता मोड लिखे हैं। MCP टूल-आकार के मामलों को कवर करता है। टीमें अपने फ्रेमवर्क, अपने मूल्यांकन, अपने डिप्लॉय पाइपलाइन रखती हैं। संस्था को एक रीढ़ मिलती है।

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

जब आपको कंट्रोल प्लेन की आवश्यकता नहीं होती है

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

आपको कंट्रोल प्लेन की आवश्यकता नहीं होती है जब एक मानव कुछ भी होने से पहले 100% आउटपुट की समीक्षा करता है (एक ड्राफ्टिंग असिस्टेंट एक स्वायत्त प्रणाली नहीं है, चाहे पिच डेक कुछ भी कहे)। आपको आंतरिक डेवलपर टूलिंग, प्रोटोटाइप, या किसी भी चीज़ के लिए इसकी आवश्यकता नहीं होती है जिसकी सबसे खराब विफलता एक खराब पैराग्राफ है। आपको बिना किसी साइड इफेक्ट के सिंगल-शॉट जनरेशन के लिए इसकी आवश्यकता नहीं होती है। इन सभी में, केवल फ्रेमवर्क, या कोई फ्रेमवर्क नहीं, आर्किटेक्चर की सही मात्रा है।

एक कदम पहले, पूछें कि क्या आपको पहले स्थान पर एक एजेंट की आवश्यकता है। मेरा अनुमानी, ओपन बैंकिंग पर लिखे गए एक लेख से, टूल्स और पाथ में विचलन की गणना करना है: “जब आपके पास विचलन का वह स्तर होता है जहाँ आप तीन टूल्स बनाम 10 टूल्स का उपयोग कर सकते हैं, तो वहीं एजेंटिक एआई एक बेहतर फिट है।” तीन टूल्स और एक अनुमानित पाथ एक प्रोग्राम है। कोड लिखें, या एक नियतात्मक वर्कफ़्लो मॉडल करें, और मुफ्त में नियतात्मकता प्राप्त करें। दस टूल्स, प्रत्येक मामले को क्या चाहिए, इसमें उच्च भिन्नता, किस क्रम में किसका उपयोग करना है, इसके बारे में निर्णय: वहीं इनर लूप अपने टोकन कमाता है। मैंने टीमों को एक एजेंट डिप्लॉय करते देखा है, उसके सभी मूल्यांकन बोझ के साथ, एक ऐसे प्रवाह पर जो ट्रेंच कोट पहने हुए तीन if स्टेटमेंट थे।

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

जब आउटर लूप फ्रेमवर्क के अंदर रहता है तो क्या टूटता है

तीन विफलताएं, मेरे द्वारा समीक्षा किए गए वास्तविक सिस्टम से सामान्यीकृत। विवरण बदले गए, संरचना बरकरार।

पॉड के साथ मरने वाला ऑडिट ट्रेल

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

स्लैक इमोजी के रूप में अनुमोदन

ह्यूमन-इन-द-लूप, एक चैनल को एक संदेश के रूप में लागू किया गया; चैनल में किसी से भी थम्स-अप ने ग्राफ को फिर से शुरू कर दिया। इसने खूबसूरती से डेमो किया। फिर सवाल: केस 4417 को किसने मंजूरी दी? क्या वह व्यक्ति उस राशि पर अधिकृत था? क्या प्रतिक्रिया के बाद संदेश संपादित किया गया था? जब अनुमोदक छोड़ देता है और उसका खाता निष्क्रिय हो जाता है तो क्या होता है? और जिसने डिजाइन समीक्षा समाप्त की: वर्कस्पेस प्रतिधारण नीति ने 90 दिनों के बाद संदेशों को हटा दिया, जिसका मतलब था कि अनुमोदन साक्ष्य का जीवनकाल उन ऋणों से कम था जिन्हें उसने अनुमोदित किया था। अनुमोदन पहचान संलग्न के साथ एक प्राधिकरण घटना है। एक प्रतिक्रिया इमोजी दोनों में से कोई नहीं है।

सिस्टम प्रॉम्प्ट में रहने वाला बजट चेक

एक रिफंड एजेंट जिसकी सीमा एक सिस्टम-प्रॉम्प्ट निर्देश के रूप में व्यक्त की गई थी। एक रेड-टीम अभ्यास ने एक दिन के भीतर एक सामान्य इंजेक्शन के साथ इसे पार कर लिया। लेकिन महत्वपूर्ण खोज प्रति-तथ्यात्मक थी: भले ही मॉडल ने हर बार लाइन को बनाए रखा हो, संस्था प्रवर्तन का प्रदर्शन नहीं कर सकी। दिखाने के लिए कोई आर्टिफैक्ट नहीं, कोई मूल्यांकन लॉग नहीं, कोई संस्करणित नीति नहीं। एजेंट के प्रस्ताव के बाद मूल्यांकन की गई डिसीजन टेबल में सीमा को ले जाने से एक अप्रमाणित व्यवहार को सबूत के साथ एक नियंत्रण में बदल दिया गया। प्रॉम्प्ट अभी भी सीमा का उल्लेख करता है, मॉडल के प्रति शिष्टाचार के रूप में। टेबल ही इसे लागू करती है।

समीक्षा टिप्पणी: इनमें से हर एक सिस्टम डेमो में काम करता था। आउटर लूप डेमो में अदृश्य होता है, क्योंकि डेमो क्रैश नहीं होते, ऑडिट नहीं होते और तीन सप्ताह तक नहीं चलते।

नियामक वास्तव में क्या मांग रहे हैं

यहां जो दस्तावेज़ मायने रखते हैं उनमें से कोई भी “एजेंट” नहीं कहता है। उन्हें कहने की आवश्यकता नहीं है। उन्हें आउटर लूप पर आवश्यकताओं के रूप में पढ़ें और मैपिंग सीधी है। यह एक मापी गई रीडिंग है, डरावनी नहीं; इनमें से अधिकांश अपेक्षाएं ऐसी हैं जो एक अच्छी तरह से चलने वाला सिस्टम वैसे भी चाहता है।

मॉडल जोखिम प्रबंधन पर OSFI का अद्यतन दिशानिर्देश E-23 (सितंबर 2025 में अंतिम, 1 मई, 2027 से कनाडा में सभी संघीय रूप से विनियमित वित्तीय संस्थानों के लिए प्रभावी) स्पष्ट रूप से एआई और मशीन लर्निंग को दायरे में लाता है और जीवनचक्र शासन की मांग करता है: इन्वेंट्री, डिजाइन, समीक्षा, डिप्लॉयमेंट, निगरानी, और स्पष्ट जवाबदेही, जोखिम के अनुपात में। एक एजेंटिक सिस्टम जो पूरी तरह से एप्लिकेशन कोड के अंदर रहता है, इनमें से लगभग हर एक अपेक्षा को एक मैनुअल डॉक्यूमेंटेशन प्रोजेक्ट बनाता है। एक कंट्रोल प्लेन उनमें से अधिकांश को एक उप-उत्पाद बनाता है: इन्वेंट्री डिप्लॉय किए गए प्रोसेस और डिसीजन डेफिनिशन का सेट है, जीवनचक्र संस्करणित आर्टिफैक्ट इतिहास है, निगरानी इंजन का अपना परिचालन डेटा है।

यूरोपीय संघ एआई अधिनियम प्राकृतिक व्यक्तियों के क्रेडिट योग्यता मूल्यांकन को अनुलग्नक III में रखता है, जो एक क्रेडिट-निर्णय लेने वाले एजेंट को एक उच्च-जोखिम प्रणाली बनाता है; वे दायित्व 2 अगस्त, 2026 से लागू हो गए। अनुच्छेद 12 स्वचालित रूप से उत्पन्न इवेंट लॉग की आवश्यकता है, जो नियामक भाषा में इस गाइड का दायित्व एक है (“स्वचालित” क्रियात्मक शब्द है; स्वयंसेवी लॉगिंग योग्य नहीं है)। अनुच्छेद 14 प्रभावी मानवीय निरीक्षण की आवश्यकता है, जो दायित्व दो है, जिसमें वह हिस्सा भी शामिल है जहाँ निरीक्षण का अर्थ है अधिकार और हस्तक्षेप करने की क्षमता वाला व्यक्ति, न कि चैनल पर सीसी किया गया व्यक्ति।

SR 11-7, फेडरल रिजर्व का मॉडल जोखिम मार्गदर्शन, 2011 से अमेरिकी बैंकों के लिए आधारभूत रहा है, और एक मॉडल की इसकी परिभाषा (एक मात्रात्मक दृष्टिकोण जो इनपुट को अनुमानों में संसाधित करता है, निर्णयों पर लागू होता है) एक एलएलएम-संचालित एजेंट को आराम से कवर करता है। इसकी मुख्य मांग प्रभावी चुनौती है: स्वतंत्र सत्यापन, दस्तावेज़ीकरण और इन्वेंट्री। आप एक ऐसी प्रणाली को प्रभावी ढंग से चुनौती नहीं दे सकते जिसका निर्णय पथ केवल एप्लिकेशन लॉग और प्रॉम्प्ट फ़ाइलों में मौजूद है। आप एक प्रोसेस मॉडल, एक डिसीजन टेबल और एक निष्पादन इतिहास को चुनौती दे सकते हैं, क्योंकि वे संस्करणों के साथ निरीक्षण योग्य वस्तुएं हैं।

तीनों में पैटर्न: नियामक जीवनचक्र शासन, स्वचालित रिकॉर्ड और जवाबदेह मानवीय निरीक्षण पर अभिसरण कर रहे हैं। वे ठीक वही चीजें हैं जो इनर लूप प्रदान नहीं कर सकता है और आउटर लूप प्रदान करने के लिए मौजूद है। जो संस्थाएं लूप को अलग करती हैं, उन्हें कंप्लायंस ज्यादातर आर्किटेक्चर से बाहर होता हुआ मिलेगा। जो संस्थाएं ऐसा नहीं करती हैं, वे एक समानांतर कागजी कार्रवाई प्रक्रिया चलाएंगी जो एक ऐसी प्रणाली का वर्णन करती है जिसे वह वास्तव में नहीं देख सकती।

एक-पैराग्राफ संस्करण

एजेंट फ्रेमवर्क (LangGraph, CrewAI, OpenAI एजेंट्स SDK) इनर लूप में उत्कृष्ट हैं: तर्क, टूल चयन, प्रॉम्प्ट असेंबली, मेमोरी। वे आउटर लूप के मालिक होने के लिए संरचनात्मक रूप से अनुपयुक्त हैं: ऑडिट ट्रेल जो कस्टम लॉगिंग के बिना मौजूद है, पहचान और फोर-आईज़ के साथ मानवीय अनुमोदन, समय एक फर्स्ट-क्लास सिटिजन के रूप में, कंप्लायंस के स्वामित्व में डेटा के रूप में नीति, और लंबे समय तक चलने वाले काम की संचालन क्षमता। जवाब रिप-एंड-रिप्लेस नहीं है; यह एक कंट्रोल प्लेन है जो एजेंट्स को किसी भी फ्रेमवर्क में ऑर्केस्ट्रेट करता है जिसमें वे बनाए गए थे, A2A या MCP पर पहुंचा जाता है, जिसमें प्रोसेस मॉडल शासित आर्टिफैक्ट के रूप में होता है। प्रक्रिया ही एजेंट है, न कि किसी एक को साइड में कॉल करना। इस भूमिका को एक BPMN इंजन, एक ड्यूरेबल एग्जीक्यूशन रनटाइम, या एक अनुशासित घरेलू स्टेट मशीन से भरें, इस बारे में आंखें खुली रखें कि प्रत्येक क्या मूल बनाता है और प्रत्येक आपकी समस्या क्या बनाता है। प्रोटोटाइप और मानवीय-समीक्षित टूल्स के लिए यह सब छोड़ दें, और एजेंट को पूरी तरह से छोड़ दें जब तीन टूल्स और एक अनुमानित पाथ का मतलब है कि आपको बस कोड लिखना चाहिए। इसे पहली बार अपनाने से पहले जब कोई ऑडिटर, नियामक, या आपकी अपनी घटना समीक्षा एक ऐसा प्रश्न पूछती है जिसका आपके लॉग उत्तर नहीं दे सकते।

संदर्भ

• OSFI, दिशानिर्देश E-23: मॉडल जोखिम प्रबंधन (2027), सितंबर 2025 में अंतिम, 1 मई, 2027 से प्रभावी।
• यूरोपीय संघ एआई अधिनियम, अनुलग्नक III: उच्च-जोखिम एआई सिस्टम और अनुच्छेद 12: रिकॉर्ड-कीपिंग; अनुलग्नक III दायित्व 2 अगस्त, 2026 से लागू।
• फेडरल रिजर्व, SR 11-7: मॉडल जोखिम प्रबंधन पर मार्गदर्शन (2011)।
• Camunda ब्लॉग, एजेंटिक एआई ओपन बैंकिंग को काम पर लगाता है, ऊपर उद्धृत तीन-टूल्स-बनाम-दस अनुमानी का स्रोत।
• Camunda ब्लॉग, अपने व्यावसायिक लक्ष्यों को प्राप्त करने के लिए A2A का उपयोग करना, भाग 1 और भाग 2, एजेंट-टू-एजेंट एकीकरण पैटर्न पर मेरा सह-लेखक लेखन।
• A2A प्रोटोकॉल स्पेसिफिकेशन और मॉडल कॉन्टेक्स्ट प्रोटोकॉल, एकीकरण पैटर्न में संदर्भित दो इंटरऑप परतें।
• LangGraph डॉक्यूमेंटेशन (परसिस्टेंस और interrupt()), OpenAI एजेंट्स SDK, और Temporal डॉक्यूमेंटेशन, चर्चा की गई इनर-लूप और ड्यूरेबल-एग्जीक्यूशन क्षमताओं के लिए।
• इस साइट पर संबंधित: A2A फील्ड गाइड।