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

एक विशिष्ट खरेदी-देयक वर्कफ्लो एक डझन प्रणालींना स्पर्श करतो. खरेदी विनंती एका प्लॅटफॉर्ममध्ये सुरू होते, दुसऱ्यामध्ये मंजुरी साखळीकडे पाठवली जाते, तिसऱ्यामध्ये विक्रेता लुकअप ट्रिगर करते, चौथ्यामध्ये खरेदी आदेश तयार करते, पाचव्यामध्ये प्राप्ती प्रक्रिया सुरू करते, सहाव्यामध्ये इनव्हॉइस जुळवते, सातव्यामध्ये देयक निर्धारित करते, आणि आठव्यामध्ये सर्व काही नोंदवते. प्रत्येक प्रणालीचे स्वतःचे API, स्वतःचे अपडेट वेळापत्रक, स्वतःचे प्रमाणीकरण मॉडेल आणि स्वतःचे अपयश मोड असतात.

पारंपारिक स्वयंचलन हे कठोर पाइपलाइनसह हाताळते. चरण एक API A ला कॉल करतो, प्रतिसाद पार्स करतो, चरण दोनला फील्ड पाठवतो. जोपर्यंत काम होते तोपर्यंत काम होते. विक्रेत्याचा रेकॉर्ड अपेक्षित स्वरूपापेक्षा थोडा वेगळा असतो. पाइपलाइन डिझाइन केलेली नसलेल्या स्टेटस कोडसह मंजुरी परत येते. 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 स्वयंचलितपणे वाढतो आणि मूळ वर्कफ्लोमध्ये परत पसरतो.

वास्तविक संदर्भावर आधारित अटीबद्ध शाखा

वर्कफ्लो DSL अटीबद्ध रूटिंगसाठी switch ब्लॉक्स, बॅच प्रक्रियेसाठी for लूप आणि वर्कफ्लो स्थिती अपडेट करण्यासाठी set ऑपरेशन्स समर्थन करते. जटिल अटींचे मूल्यमापन करू शकणाऱ्या LLM उप-एजंट चरणांसह एकत्रित, वर्कफ्लो फक्त फील्ड मूल्यांऐवजी वास्तविक व्यावसायिक संदर्भावर आधारित शाखा करू शकते.

प्रणाली बदलल्यावर स्व-उपचार

जेव्हा API ने त्याचे प्रतिसाद स्वरूप बदलल्यामुळे निश्चयात्मक चरण अयशस्वी होतो, तेव्हा वर्कफ्लो थांबत नाही. इंजिन अयशस्वी चरण LLM उप-एजंटकडे सोपवू शकते जो त्रुटी वाचतो, प्रतिसाद तपासतो आणि पर्यायी दृष्टिकोनाचा प्रयत्न करतो. नवीन आवश्यक फील्ड जोडलेल्या API ला उप-एजंट त्रुटी संदेश वाचून आणि विनंती समायोजित करून हाताळतो.

संपूर्ण साखळीत सुरक्षा

Triggerfish वर्कफ्लोमधील प्रत्येक चरण त्याच धोरण अंमलबजावणी hooks मधून जातो जसे कोणताही थेट टूल कॉल. PRE_TOOL_CALL कार्यान्वयनापूर्वी परवानग्यांची पडताळणी करतो. POST_TOOL_RESPONSE परत आलेल्या डेटाचे वर्गीकरण करतो. PRE_OUTPUT सुनिश्चित करतो की काहीही लक्ष्य परवानगी देत असलेल्या वर्गीकरण स्तरापेक्षा जास्त वर्गीकरणावर प्रणाली सोडत नाही.

वर्कफ्लो व्याख्या स्वतः classification_ceiling सेट करू शकते. INTERNAL वर वर्गीकृत साप्ताहिक सारांश वर्कफ्लो CONFIDENTIAL डेटामध्ये प्रवेश करू शकत नाही, त्यासाठी क्रेडेन्शियल असले तरीही. मर्यादा कोडमध्ये लागू होते, LLM प्रॉम्प्ट निर्देशनाचे पालन करेल अशी आशा ठेवून नाही.

Cron आणि Webhook ट्रिगर

वर्कफ्लोंना कोणीतरी त्यांना मॅन्युअली सुरू करण्याची आवश्यकता नाही. शेड्यूलर आवर्ती वर्कफ्लोंसाठी cron-आधारित ट्रिगर आणि इव्हेंट-चालित कार्यान्वयनासाठी webhook ट्रिगर समर्थन करते.

व्यवहारात हे कसे दिसते

NetSuite, Coupa, DocuSign आणि Slack मध्ये खरेदी-देयक चालवणारी मध्यम-बाजार कंपनी संपूर्ण चक्र हाताळणारी Triggerfish वर्कफ्लो परिभाषित करते. निश्चयात्मक चरण खरेदी आदेश तयार करण्यासाठी, मंजुरी रूट करण्यासाठी आणि इनव्हॉइस जुळवण्यासाठी API कॉल हाताळतात. LLM उप-एजंट चरण अपवाद हाताळतात.

Coupa त्याचे API अपडेट करून फील्ड नाव बदलते तेव्हा, वर्कफ्लोचा निश्चयात्मक HTTP चरण अयशस्वी होतो. इंजिन उप-एजंटकडे सोपवते जो त्रुटी वाचतो, बदललेले फील्ड ओळखतो आणि योग्य पॅरामीटरसह पुनःप्रयत्न करतो. मानवी हस्तक्षेपाशिवाय वर्कफ्लो पूर्ण होते.