فیصلوں کے ساتھ کراس سیستم آرکسٹریشن

ایک عام پروکیور ٹو پے ورک فلو بارہ سسٹمز کو چھوتا ہے۔ ایک خریداری کی درخواست ایک پلیٹ فارم میں شروع ہوتی ہے، دوسرے میں ایک منظوری کی زنجیر کو بھیجی جاتی ہے، تیسرے میں وینڈر تلاش شروع کرتی ہے، چوتھے میں خریداری کا آرڈر بناتی ہے، پانچویں میں موصولی عمل شروع کرتی ہے، چھٹے میں انوائسز سے میل کھاتی ہے، ساتویں میں ادائیگی شیڈول کرتی ہے، اور آٹھویں میں سب کچھ ریکارڈ کرتی ہے۔ ہر سسٹم کا اپنا 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 سب ایجنٹ سیشن بناتا ہے۔ یہ ایک prompt/جواب کا تبادلہ نہیں ہے۔ سب ایجنٹ کو Triggerfish میں رجسٹرڈ ہر ٹول تک رسائی ہے، بشمول ویب سرچ، میموری، براؤزر آٹومیشن، اور تمام جڑے انٹیگریشنز۔ یہ دستاویزات پڑھ سکتا ہے، ڈیٹا بیس کو کوئری کر سکتا ہے، ریکارڈز کا موازنہ کر سکتا ہے، اور جو کچھ پاتا ہے اس کی بنیاد پر فیصلہ کر سکتا ہے۔

سب ایجنٹ کا آؤٹ پٹ براہ راست ورک فلو کے اگلے قدم میں جاتا ہے۔ اگر اس نے استدلال کے دوران درجہ بند ڈیٹا تک رسائی کی، تو سیشن taint خود بخود ایسکلیٹ ہوتا ہے اور پیرنٹ ورک فلو میں واپس آتا ہے۔ ورک فلو انجن اسے ٹریک کرتا ہے، اس لیے ایک ورک فلو جو PUBLIC پر شروع ہوا لیکن فیصلے کے دوران CONFIDENTIAL ڈیٹا سے ٹکرایا، اس کی پوری عمل کاری تاریخ CONFIDENTIAL سطح پر محفوظ ہوتی ہے۔ کم درجہ بند سیشن جان بھی نہیں سکتا کہ ورک فلو چلا۔

حقیقی سیاق پر مبنی مشروط برانچنگ

ورک فلو DSL مشروط روٹنگ کے لیے switch بلاکس، بیچ پروسیسنگ کے لیے for لوپس، اور ورک فلو اسٹیٹ اپ ڈیٹ کرنے کے لیے set آپریشنز کو سپورٹ کرتا ہے۔ LLM سب ایجنٹ قدموں کے ساتھ مل کر جو پیچیدہ شرائط کا جائزہ لے سکتے ہیں، اس کا مطلب ہے کہ ورک فلو صرف فیلڈ ویلیوز کی بجائے حقیقی کاروباری سیاق کی بنیاد پر برانچ کر سکتا ہے۔

ایک پروکیورمنٹ ورک فلو وینڈر رسک کے سب ایجنٹ کے جائزے کی بنیاد پر مختلف طریقے سے روٹ کر سکتا ہے۔ ایک آن بورڈنگ ورک فلو کسی خاص کردار کے لیے غیر متعلقہ قدموں کو چھوڑ سکتا ہے۔ ایک انسیڈنٹ رسپانس ورک فلو سب ایجنٹ کی روٹ کاز تجزیے کی بنیاد پر مختلف ٹیموں کو ایسکلیٹ کر سکتا ہے۔ برانچنگ لاجک ورک فلو تعریف میں رہتی ہے، لیکن فیصلے کے ان پٹ AI استدلال سے آتے ہیں۔

سسٹمز کے بدلنے پر خود ترمیم

جب کوئی قطعی قدم اس لیے ناکام ہو جاتا ہے کیونکہ کسی API نے اپنا جواب فارمیٹ بدل دیا یا کسی سسٹم نے غیر متوقع خرابی لوٹائی، ورک فلو صرف رک نہیں جاتا۔ انجن ناکام قدم کو ایک LLM سب ایجنٹ کو سونپ سکتا ہے جو خرابی پڑھتا ہے، جواب کا معائنہ کرتا ہے، اور متبادل طریقہ آزماتا ہے۔ ایک API جس نے نئی مطلوبہ فیلڈ شامل کی اسے سب ایجنٹ خرابی پیغام پڑھ کر اور درخواست ایڈجسٹ کر کے سنبھال لیتا ہے۔ ایک سسٹم جس نے اپنا تصدیقی بہاؤ بدل دیا اسے براؤزر آٹومیشن ٹولز نیوی گیٹ کر لیتے ہیں۔

اس کا مطلب نہیں کہ ہر ناکامی جادوئی طریقے سے حل ہو جاتی ہے۔ لیکن اس کا مطلب ہے کہ ورک فلو خاموشی سے ناکام ہونے کی بجائے احسن طریقے سے خراب ہوتا ہے۔ سب ایجنٹ یا تو آگے کا راستہ تلاش کرتا ہے یا اس بات کی واضح وضاحت تیار کرتا ہے کہ کیا بدلا اور دستی مداخلت کی ضرورت کیوں ہے، بجائے کسی لاگ فائل میں دفن ایک مبہم خرابی کوڈ کے جسے کوئی نہیں دیکھتا۔

پوری زنجیر میں سیکیورٹی

Triggerfish ورک فلو میں ہر قدم اسی پالیسی نفاذ hooks سے گزرتا ہے جیسے کوئی بھی براہ راست ٹول کال۔ PRE_TOOL_CALL عمل سے پہلے اجازتیں تصدیق کرتا ہے اور ریٹ کی حدود جانچتا ہے۔ POST_TOOL_RESPONSE واپس آئے ڈیٹا کو درجہ بند کرتا ہے اور سیشن taint کو اپ ڈیٹ کرتا ہے۔ PRE_OUTPUT یقینی بناتا ہے کہ ہدف کی اجازت سے زیادہ درجہ بندی سطح پر کچھ بھی سسٹم سے نہ نکلے۔

اس کا مطلب ہے کہ ایک ورک فلو جو آپ کے CRM (CONFIDENTIAL) سے پڑھتا ہے، LLM کے ذریعے ڈیٹا پروسیس کرتا ہے، اور Slack کو خلاصہ بھیجتا ہے، اتفاقاً عوامی چینل میں خفیہ تفصیلات لیک نہیں کرتا۔ رائٹ ڈاؤن روک تھام کا اصول اسے PRE_OUTPUT hook پر پکڑتا ہے، اس بات سے قطع نظر کہ ڈیٹا کتنے درمیانی قدموں سے گزرا۔ درجہ بندی پوری ورک فلو میں ڈیٹا کے ساتھ سفر کرتی ہے۔

ورک فلو تعریف خود classification_ceiling مقرر کر سکتی ہے جو ورک فلو کو متعین سطح سے اوپر ڈیٹا کو چھونے سے روکتی ہے۔ INTERNAL پر درجہ بند ہفتہ وار خلاصہ ورک فلو CONFIDENTIAL ڈیٹا تک رسائی نہیں کر سکتا چاہے اس کے پاس اس کے اسناد ہوں۔ چھت کوڈ میں نافذ ہے، اس امید پر نہیں کہ LLM ایک prompt ہدایت کا احترام کرے گا۔

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 قدم ناکام ہو جاتا ہے۔ انجن ایک سب ایجنٹ کو سونپتا ہے جو خرابی پڑھتا ہے، بدلی ہوئی فیلڈ کی شناخت کرتا ہے، اور درست پیرامیٹر کے ساتھ دوبارہ کوشش کرتا ہے۔ ورک فلو انسانی مداخلت کے بغیر مکمل ہو جاتا ہے، اور واقعہ لاگ ہو جاتا ہے تاکہ ایک انجینئر ورک فلو تعریف کو آگے چل کر نئے فارمیٹ کو سنبھالنے کے لیے اپ ڈیٹ کر سکے۔