آج آپ جو بھی سافٹ ویئر استعمال کرتے ہیں، وہ ایک ہی مفروضے پر مبنی ہے۔ کہ اسکرین کے سامنے انگلیوں والا کوئی انسان بیٹھا ہے۔ بٹنوں سے ارادے کا پتہ چلتا ہے۔ Wizards پیچیدگیوں کو سنبھالتے ہیں۔ فارمز انسانی سوچ کو ایک ڈھانچہ فراہم کرتے ہیں۔ یہ آرکیٹیکچر دہائیوں سے پروڈکٹ ڈیزائن پر حاوی رہا ہے کیونکہ حال ہی تک صرف انسان ہی کلک کرتے تھے۔
اب وہ مفروضہ غلط ثابت ہو چکا ہے۔ AI ایجنٹس انٹرفیس نہیں پڑھتے۔ انہیں مددگار tooltips یا confirmation dialogs سے کوئی فائدہ نہیں ہوتا۔ جب کسی خود مختار (autonomous) سسٹم کو صارف کی طرف سے کام کرنے کی ضرورت ہوتی ہے، تو chrome رکاوٹ بن جاتا ہے۔ اس کا نتیجہ یہ نکلتا ہے کہ پروڈکٹس کے بنانے کے طریقے اور جدید کالرز کے اصل طرزِ عمل کے درمیان فرق بڑھتا جا رہا ہے۔
The Click Paradigm
روایتی سافٹ ویئر ایک بصری معاہدے (visual contract) پر انحصار کرتا ہے۔ ایک انسان بٹن دیکھتا ہے، اس کے لیبل کو سمجھتا ہے، اور فیصلہ کرتا ہے کہ اسے دبانا ہے یا نہیں۔ ورک فلو میں جان بوجھ کر رکاوٹیں (friction) رکھی جاتی ہیں۔ Multi-step wizards اس لیے ہوتے ہیں کیونکہ لوگ غلطیاں کرتے ہیں اور انہیں حفاظتی حصار (guardrails) کی ضرورت ہوتی ہے۔ Dropdowns اور radio buttons ان پٹ کو محدود کرتے ہیں کیونکہ آزادانہ تحریر (freeform text) افراتفری کا باعث بنتی ہے۔
یہ تب تو اچھا کام کرتا ہے جب آپریٹر ایک انسان ہو۔ لیکن جب آپریٹر ایک ایجنٹ ہو، تو یہ نظام ناکام ہو جاتا ہے۔ کسی سبسکرپشن کو منسوخ کرنے یا ریکارڈ میں تبدیلی کرنے کے لیے مشین کو پانچ مرحلہ وار wizard کی ضرورت نہیں ہوتی۔ اسے صرف اس بات کا واضح بیان چاہیے کہ کون سے آپریشنز موجود ہیں اور اس بات کا حتمی جواب کہ آیا اسے وہ کرنے کی اجازت ہے یا نہیں۔ جب ٹیمیں اس بات کو نظر انداز کرتی ہیں، تو وہ عام طور پر دو شارٹ کٹس کا سہارا لیتی ہیں۔
پہلا یہ کہ وہ ایجنٹ کو ایک API key دے دیتے ہیں۔ دوسرا یہ کہ وہ موجودہ یوزر انٹرفیس کو ایک chatbot کے اندر لپیٹ دیتے ہیں اور اسے مکمل انٹیگریشن قرار دے دیتے ہیں۔ ان میں سے کوئی بھی طریقہ اصل مسئلے کو حل نہیں کرتا۔
ایک API key اس سوال کا جواب دیتی ہے کہ "کیا یہ درخواست کسی قابلِ اعتماد ذریعے سے آئی ہے؟" لیکن یہ اس اہم سوال کا جواب کبھی نہیں دیتی: "کیا یہ مخصوص کالر اس مخصوص ریکارڈ کو پڑھ سکتا ہے؟" ایک key ایک skeleton key کی طرح ہے۔ ایک بار جاری ہونے کے بعد، یہ عام طور پر تمام وسائل اور سیاق و سباق تک وسیع رسائی فراہم کر دیتی ہے۔ اسے آپ کے سسٹم کے اندر انفرادی اقدامات کو کنٹرول کرنے والی پالیسی کے بارے میں کچھ معلوم نہیں ہوتا۔
GUI کو chatbot میں لپیٹنا اس سے بھی زیادہ کمزور طریقہ ہے۔ ایجنٹ انٹرفیس میں موجود ہر انسانی مرکزیت والے مفروضے کو اپنا لیتا ہے۔ وہ modals اور forms کے ذریعے کلکس کی نقل کرتا ہے جو انسانی آنکھوں کے لیے بنائے گئے ہیں، نہ کہ خود مختار منطق (autonomous logic) کے لیے۔ chatbot شاید chrome میں کامیابی سے کام کر لے، لیکن وہ یہ سب بغیر سمجھے کرتا ہے۔ یہ محض 'automation theater' ہے۔ حقیقت میں، اس کے نیچے اب بھی اس بارے میں کوئی مشین کے قابل (machine-readable) معاہدہ موجود نہیں ہوتا کہ کس چیز کی اجازت ہے۔
ایجنٹس کو سامنے کے دروازے کی ایک اور چابی نہیں چاہیے۔ انہیں gates کی ضرورت ہے۔
What Gates Actually Do
ایک gate ایک منظم ایگزیکیوشن لیئر (governed execution layer) ہے۔ کسی کریڈنشل پر بھروسہ کرنے اور اس امید پر کہ کالر صحیح برتاؤ کرے گا، اس کے بجائے gates والا سسٹم ہر درخواست کا اعلان کردہ قواعد کے مطابق جائزہ لیتا ہے۔ یہ قواعد کسی بھی انٹرفیس (چاہے وہ انسانی ہو یا کوئی اور) سے آزاد ہوتے ہیں۔
ایک مناسب gate چار چیزیں متعین کرتا ہے۔ یہ اعلان کرتا ہے کہ پروڈکٹ کے اندر کون سے اقدامات (actions) موجود ہیں۔ یہ بتاتا ہے کہ کون سے حالات میں انہیں کون استعمال کر سکتا ہے۔ یہ واضح کرتا ہے کہ کب ایک کالر کو side effects پیدا کرنے سے پہلے رکنا چاہیے اور واضح اجازت طلب کرنی چاہیے۔ اور یہ یقینی بناتا ہے کہ سسٹم ہر فیصلے کو ایک منظم اور قابلِ دریافت (queriable) ریکارڈ میں محفوظ کرے۔
یہ روایتی ایکسیس کنٹرول سے بنیادی طور پر مختلف ہے۔ Role-based سسٹم اکثر دروازے پر پوچھتے ہیں، "کیا آپ ایڈمن ہیں؟" اور پھر آپ کو عمارت میں گھومنے کی اجازت دے دیتے ہیں۔ Gates ہر موڑ پر پوچھتے ہیں، "کیا آپ کو اس وقت یہ مخصوص سوئچ دبانے کی اجازت ہے؟" یہاں شناخت (identity) کے مقابلے میں طرزِ عمل (behavior) کو اہمیت دی جاتی ہے۔ پالیسی عمل (action) کے ساتھ ساتھ چلتی ہے۔
اسے عملی طور پر سمجھنے کے لیے، ایک ایسے ایجنٹ کا تصور کریں جسے کسی صارف کو رقم واپس (refund) کرنی ہے۔ ایک key-based طریقہ کسی بھی ایسے شخص کو ریفنڈ کرنے کی اجازت دے سکتا ہے جس کے پاس وہ key ہو، بشرطیکہ endpoint تک رسائی ممکن ہو۔ جبکہ ایک gate-based طریقہ دستیاب اقدامات کی فہرست (manifest) کو چیک کرتا ہے، مخصوص کسٹمر ریکارڈ کے خلاف ایجنٹ کی اجازت کی تصدیق کرتا ہے، مالیاتی side effect کے لیے صارف کی واضح منظوری لیتا ہے، اور اس پورے عمل کو ایک audit log میں درج کرتا ہے۔ Gate صرف شناخت نہیں بلکہ پالیسی کو نافذ کرتا ہے۔
Testing It on Whistler
ہم نے اس ماڈل کو Whistler پر آزمایا۔ انسانوں اور مشینوں کے لیے الگ الگ پائپ لائنز بنانے کے بجائے، ہم نے ایک ہی پالیسی لیئر لکھی اور اس پر دو مختلف کالرز چلا کر دیکھے۔
ایک کالر وہ انسان تھا جو ایمبیڈڈ Shell استعمال کر رہا تھا۔ دوسرا ہماری ٹیم سے باہر تیار کردہ ایک تھرڈ پارٹی ایجنٹ تھا۔ دونوں ایک ہی manifest سے منسلک تھے۔ دونوں کو ہر مرحلے پر یکساں permission checks کا سامنا کرنا پڑا۔ جب بھی کسی بھی کالر نے ایسے عمل کی کوشش کی جس کے side effects ہوں، جیسے ڈیٹا میں تبدیلی یا کسی بیرونی ایونٹ کا آغاز، تو سسٹم نے واضح منظوری طلب کی۔ ہر درخواست، منظوری اور انکار نے ایک ہی طرح کا منظم audit trail تیار کیا۔
کسی بھی کالر نے ماسٹر API key استعمال نہیں کی۔ کوئی بیک ڈور نہیں تھا، کوئی ایسی اعلیٰ سطح کی شناخت (credential) نہیں تھی جس نے پالیسی کو نظر انداز کیا ہو۔ انسان کو اس لیے نرمی نہیں دی گئی کیونکہ اس کے پاس پاس ورڈ اور براؤزر تھا۔ ایجنٹ کو اس لیے بلاوجہ روکا نہیں گیا کیونکہ اس کے پاس انسانی نشان (fingerprint) نہیں تھا۔ گیٹ نے عمل، سیاق و سباق اور قواعد کا جائزہ لیا۔ یہی پورا لین دین تھا۔
اس کا نتیجہ ایک ایسا نظام تھا جہاں کسی نئے کالر، چاہے وہ انسان ہو یا مشین، کو شامل کرنے کے لیے ایکسیس لاجک (access logic) کی ری فیکٹرنگ (refactoring) کی ضرورت نہیں تھی۔ آپ نے پالیسی اپ ڈیٹ کی۔ گیٹ نے اسے نافذ کر دیا۔
پروڈکٹ کے سوال پر نظر ثانی
اگر آپ کی ٹیم اس وقت یہ سمجھنے کی کوشش کر رہی ہے کہ انسانوں کے بنائے ہوئے پروڈکٹ میں AI ایجنٹس کو کیسے شامل کیا جائے، تو غالباً آپ غلط سوال سے آغاز کر رہے ہیں۔ ٹیمیں فطری طور پر یہ پوچھتی ہیں کہ کیا انہیں API فراہم کرنی چاہیے یا نہیں۔ انہیں اس کے بجائے یہ پوچھنا چاہیے کہ کیا ان کے پاس ہر کالر کے لیے ایک منظم ایگزیکیوشن لیئر (governed execution layer) موجود ہے؟
گیٹ کے بغیر API محض ایک بڑا دروازہ ہے۔ اگر آپ کی اندرونی پالیسیاں صرف ویزرڈ لاجک (wizard logic)، فارم ویلیڈیشن، اور انسانوں کے پڑھنے کے قابل مددگار متن (help text) تک محدود ہیں، تو آپ جو بھی اینڈ پوائنٹ (endpoint) شائع کریں گے وہ خود مختار کالرز کے لیے محفوظ نہیں ہوگا۔ ایجنٹ یا تو کسی کی (key) کے ذریعے ضرورت سے زیادہ اعتماد حاصل کر لے گا یا پھر چیٹ بوٹ ریپر (chatbot wrapper) کے ذریعے کمزور کٹھ پتلی کی طرح کام کرے گا۔
پہلے گیٹس بنانے کا مطلب ہے اپنے پروڈکٹ میں ہر بامعنی عمل کو ایک اعلان کردہ آپریشن (declared operation) کے طور پر فہرست میں شامل کرنا۔ اس کا مطلب ہے اجازت کی جانچ (permission check) کو یوزر انٹرفیس سے الگ کرنا تاکہ Shell صارف اور بیرونی ایجنٹ دونوں کو ایک ہی رن ٹائم انفورسمنٹ (runtime enforcement) کا سامنا کرنا پڑے۔ اس کا مطلب ہے کہ تباہ کن آپریشنز (destructive operations) کے لیے رضامندی کے ہکس (consent hooks) ضرورت پڑنے سے پہلے ہی شامل کر دینا، نہ کہ اس کے بعد جب ایجنٹ غلط ڈیٹا سیٹ مٹا دے۔ اور اس کا مطلب ہے ایسے آڈٹ ٹریلز (audit trails) تیار کرنا جن کا سیکیورٹی اور کمپلائنس ٹیمیں معائنہ کر سکیں، اس بات کی پرواہ کیے بغیر کہ کالر کاربن (انسان) تھا یا سلیکون (مشین)۔
اس کے لیے ایک حقیقی آرکیٹیکچرل تبدیلی کی ضرورت ہے۔ انسانوں پر مرکوز ڈیزائن (Human-centric design) لاجک کو ہمدردی اور رکاوٹوں میں لپیٹ دیتا ہے۔ ایجنٹ کے لیے تیار ڈیزائن (Agent-ready design) لاجک کو واضح اور مشین کے قابلِ فہم معاہدوں (machine-readable contracts) کے ذریعے ظاہر کرتا ہے۔ انٹرفیس اب پالیسی نہیں رہتا، بلکہ مینی فیسٹ (manifest) پالیسی بن جاتا ہے۔
یہ تبدیلی انسانوں کو تبدیل کرنے کے بارے میں نہیں ہے۔ یہ اس بات کو تسلیم کرنے کے بارے میں ہے کہ آپ کے سافٹ ویئر کے پاس اب ایک سے زیادہ قسم کے کالرز ہیں۔ ہر ایک اسی سختی اور معیار کا مستحق ہے۔
اصل سبق
کلک کے لیے ڈیزائن کرنا چھوڑ دیں۔ اصول کے لیے ڈیزائن کرنا شروع کریں۔ اگر آپ کا نظام اعلان کردہ اعمال، سیاق و سباق کے مطابق اجازتوں، رضامندی کی جانچ، اور مشترکہ آڈٹ ٹریلز کے ذریعے ہر کالر کو کنٹرول کر سکتا ہے، تو اس سے کوئی فرق نہیں پڑتا کہ دوسری طرف کون یا کیا ہے۔ انسان ہو یا ایجنٹ، وہ سب ایک ہی گیٹ پر آتے ہیں۔ پہلے گیٹ بنائیں۔ API محض ایک دروازہ ہے۔ پالیسی ہی وہ چیز ہے جو کمرے کو محفوظ رکھتی ہے۔