निर्णय क्षमता के साथ क्रॉस-सिस्टम ऑर्केस्ट्रेशन

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

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

गहरी समस्या तकनीकी नाजुकता नहीं है। यह है कि वास्तविक व्यावसायिक प्रक्रियाओं को निर्णय की आवश्यकता है। क्या इस इनवॉइस विसंगति को बढ़ाया जाना चाहिए या स्वतः हल किया जाना चाहिए? क्या इस विक्रेता के देर से डिलीवरी के पैटर्न से अनुबंध समीक्षा की आवश्यकता है? क्या यह अनुमोदन अनुरोध मानक रूटिंग को छोड़ने के लिए पर्याप्त जरूरी है? ये निर्णय वर्तमान में लोगों के दिमाग में रहते हैं, जिसका मतलब है कि स्वचालन केवल सामान्य मार्ग को संभाल सकता है।

Triggerfish इसे कैसे हल करता है

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

नियतात्मक कार्य के लिए नियतात्मक चरण

जब एक वर्कफ़्लो चरण का एक ज्ञात इनपुट और ज्ञात आउटपुट होता है, तो यह एक मानक HTTP कॉल, शेल कमांड, या MCP टूल इनवोकेशन के रूप में चलता है। कोई LLM भागीदारी नहीं, कोई लेटेंसी पेनल्टी नहीं, कोई अनुमान लागत नहीं। वर्कफ़्लो इंजन REST APIs के लिए call: http, किसी भी जुड़े MCP सर्वर के लिए call: triggerfish:mcp, और कमांड-लाइन टूल के लिए run: shell का समर्थन करता है। ये चरण पारंपरिक स्वचालन की तरह ही निष्पादित होते हैं, क्योंकि पूर्वानुमानित कार्य के लिए, पारंपरिक स्वचालन सही दृष्टिकोण है।

निर्णय के लिए LLM सब-एजेंट

जब एक वर्कफ़्लो चरण को प्रासंगिक तर्क की आवश्यकता होती है, तो इंजन call: triggerfish:llm का उपयोग करके एक वास्तविक LLM सब-एजेंट सत्र उत्पन्न करता है। यह एक एकल प्रॉम्प्ट/प्रतिक्रिया नहीं है। सब-एजेंट के पास Triggerfish में पंजीकृत प्रत्येक टूल तक पहुँच है, जिसमें वेब खोज, मेमोरी, ब्राउज़र स्वचालन, और सभी जुड़े इंटीग्रेशन शामिल हैं। यह दस्तावेज़ पढ़ सकता है, डेटाबेस क्वेरी कर सकता है, रिकॉर्ड की तुलना कर सकता है, और अपनी खोज के आधार पर निर्णय ले सकता है।

सब-एजेंट का आउटपुट सीधे वर्कफ़्लो के अगले चरण में जाता है। यदि इसने अपने तर्क के दौरान वर्गीकृत डेटा तक पहुँच की, तो सत्र taint स्वचालित रूप से बढ़ता है और मूल वर्कफ़्लो में वापस प्रचारित होता है। वर्कफ़्लो इंजन इसे ट्रैक करता है, इसलिए एक वर्कफ़्लो जो PUBLIC पर शुरू हुई लेकिन निर्णय के दौरान CONFIDENTIAL डेटा को हिट किया, उसका पूरा निष्पादन इतिहास CONFIDENTIAL स्तर पर संग्रहीत हो जाता है।

वास्तविक संदर्भ पर आधारित सशर्त शाखाएँ

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

एक खरीद वर्कफ़्लो सब-एजेंट के विक्रेता जोखिम मूल्यांकन के आधार पर अलग तरह से रूट हो सकती है। एक ऑनबोर्डिंग वर्कफ़्लो किसी विशेष भूमिका के लिए अप्रासंगिक चरणों को छोड़ सकती है। एक घटना प्रतिक्रिया वर्कफ़्लो सब-एजेंट के मूल कारण विश्लेषण के आधार पर विभिन्न टीमों के पास बढ़ा सकती है।

सिस्टम बदलने पर स्व-उपचार

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

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

पूरी श्रृंखला में सुरक्षा

Triggerfish वर्कफ़्लो में प्रत्येक चरण उसी नीति प्रवर्तन hooks से गुजरता है जैसे कोई भी सीधा टूल कॉल। PRE_TOOL_CALL निष्पादन से पहले अनुमतियाँ मान्य करता है और दर सीमाएं जाँचता है। POST_TOOL_RESPONSE लौटाए गए डेटा को वर्गीकृत करता है और सत्र taint अपडेट करता है। PRE_OUTPUT सुनिश्चित करता है कि कुछ भी ऐसे वर्गीकरण स्तर पर सिस्टम न छोड़े जो लक्ष्य से अधिक हो।

इसका मतलब है कि एक वर्कफ़्लो जो आपके CRM (CONFIDENTIAL) से पढ़ती है, LLM के माध्यम से डेटा प्रोसेस करती है, और Slack को एक सारांश भेजती है, वह गलती से एक PUBLIC चैनल में गोपनीय विवरण लीक नहीं करती। PRE_OUTPUT hook पर write-down प्रतिबंध नियम इसे पकड़ता है, चाहे डेटा कितने मध्यवर्ती चरणों से गुजरा हो।

वर्कफ़्लो परिभाषा स्वयं एक classification_ceiling सेट कर सकती है जो वर्कफ़्लो को एक निर्दिष्ट स्तर से ऊपर डेटा छूने से रोकती है। INTERNAL पर वर्गीकृत एक साप्ताहिक सारांश वर्कफ़्लो CONFIDENTIAL डेटा तक नहीं पहुँच सकती, भले ही उसके पास ऐसा करने के लिए क्रेडेंशियल हों। यह कोड में लागू होता है, न कि यह उम्मीद करके कि LLM एक प्रॉम्प्ट निर्देश का पालन करेगा।

Cron और Webhook ट्रिगर

वर्कफ़्लो को किसी के मैन्युअल रूप से शुरू करने की आवश्यकता नहीं है। शेड्यूलर आवर्ती वर्कफ़्लो के लिए cron-आधारित ट्रिगर और इवेंट-संचालित निष्पादन के लिए webhook ट्रिगर का समर्थन करता है। एक सुबह की ब्रीफिंग वर्कफ़्लो सुबह 7 बजे चलती है। एक PR समीक्षा वर्कफ़्लो तब चालू होती है जब GitHub एक webhook भेजता है। एक इनवॉइस प्रोसेसिंग वर्कफ़्लो तब ट्रिगर होती है जब एक साझा ड्राइव में एक नई फ़ाइल दिखाई देती है।

Webhook इवेंट अपना स्वयं का वर्गीकरण स्तर वहन करते हैं। एक निजी रिपॉजिटरी के लिए GitHub webhook सुरक्षा कॉन्फ़िग में डोमेन वर्गीकरण मैपिंग के आधार पर स्वचालित रूप से CONFIDENTIAL के रूप में वर्गीकृत होता है। वर्कफ़्लो उस वर्गीकरण को इनहेरिट करती है और सभी डाउनस्ट्रीम प्रवर्तन लागू होते हैं।

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

NetSuite, Coupa, DocuSign, और Slack में खरीद-से-भुगतान चला रही एक मिड-मार्केट कंपनी एक Triggerfish वर्कफ़्लो परिभाषित करती है जो पूरे चक्र को संभालती है। नियतात्मक चरण खरीद आदेश बनाने, अनुमोदन रूट करने, और इनवॉइस का मिलान करने के लिए API कॉल संभालते हैं। LLM सब-एजेंट चरण अपवाद संभालते हैं: ऐसे इनवॉइस जिनकी लाइन आइटम PO से मेल नहीं खाती, विक्रेता जिन्होंने अप्रत्याशित प्रारूप में दस्तावेज़ीकरण जमा किया, अनुमोदन अनुरोध जिन्हें अनुरोधकर्ता के इतिहास के बारे में संदर्भ चाहिए।

वर्कफ़्लो एक सेल्फ-होस्टेड Triggerfish इंस्टेंस पर चलती है। कोई डेटा कंपनी के इंफ्रास्ट्रक्चर से बाहर नहीं जाता। वर्गीकरण प्रणाली सुनिश्चित करती है कि NetSuite से वित्तीय डेटा CONFIDENTIAL पर रहे और INTERNAL पर वर्गीकृत Slack चैनल में नहीं जा सके। ऑडिट ट्रेल हर निर्णय को कैप्चर करता है जो LLM सब-एजेंट ने किया, हर टूल जो उसने कॉल किया, और हर डेटा जो उसने एक्सेस किया, अनुपालन समीक्षा के लिए पूर्ण वंशावली ट्रैकिंग के साथ संग्रहीत।

जब Coupa अपना API अपडेट करता है और एक फील्ड नाम बदलता है, तो वर्कफ़्लो का नियतात्मक HTTP चरण विफल हो जाता है। इंजन एक सब-एजेंट को सौंपता है जो त्रुटि पढ़ता है, बदले हुए फील्ड की पहचान करता है, और सही पैरामीटर के साथ पुनः प्रयास करता है। वर्कफ़्लो मानव हस्तक्षेप के बिना पूर्ण होती है, और घटना लॉग की जाती है ताकि एक इंजीनियर आगे चलकर नए प्रारूप को संभालने के लिए वर्कफ़्लो परिभाषा अपडेट कर सके।