انسانی پالیسی کے تحت ایجنٹک ادائیگیاں
ایجنٹک ادائیگیاں وہ ادائیگیاں ہیں جو چیک آؤٹ پر کسی شخص کے بجائے سافٹ ویئر شروع کرتا ہے۔ ایک AI ایجنٹ کے پاس کریڈنشلز ہوتے ہیں، وہ فیصلہ کرتا ہے کہ خریداری ہونی چاہیے، اور رقم خود منتقل کرتا ہے — انوائس ادا کرتا ہے، سبسکرپشن تجدید کرتا ہے، چارٹر بک کرتا ہے — بغیر اس کے کہ کوئی انسان آخری بٹن دبائے۔ امتیازی بات شروع کرنے والا ہے۔ کسی شخص کا خریدیں پر کلک کرنا سامنے چیٹ بوٹ والی عام کارڈ ادائیگی ہے؛ ایجنٹک ادائیگی میں فیصلہ، اجازت اور سیٹلمنٹ، عین اس لمحے جب رقم حرکت کرتی ہے، سافٹ ویئر کرتا ہے۔ اس زمرے کی ہر مشکل اسی ایک خصوصیت سے نکلتی ہے: خرچ کرنے والا انسان نہیں، اور وہ اجنبی کو رقم بھیجنے سے پہلے انسان کی طرح تھکتا، شک کرتا یا گھبراتا نہیں۔
اسی لیے دلچسپ سوال کبھی یہ تھا ہی نہیں کہ ایجنٹ پیسہ خرچ کریں گے یا نہیں — وہ پہلے ہی کر سکتے ہیں۔ سوال یہ ہے کہ وہ کن قواعد کے تحت خرچ کریں، اور آیا یہ قواعد پلیٹ فارم نافذ کرتا ہے یا ایجنٹ صرف وعدہ کرتا ہے۔
ناکامی کی صورت واضح ہے، اور یہی اصل بات ہے
ایجنٹ کو لائیو پیمنٹ کریڈنشل دے دیں اور کوئی حد نہ رکھیں، تو آپ نے ایک ایسا وائر فراڈ واقعہ بنا لیا ہے جو ابھی ہوا نہیں۔ خرابی کا طریقہ انوکھا نہیں۔ ویب پیج میں چھپا پرامپٹ انجیکشن ایجنٹ کو حملہ آور کو ادائیگی کا کہتا ہے۔ غلط ٹول ڈسکرپشن جائز خریداری کو غلط وصول کنندہ کی طرف موڑ دیتی ہے۔ ری ٹرائی لوپ ایک ہی چارج ہزار بار کرتا ہے کیونکہ کامیابی کا سگنل کبھی واپس نہیں آیا۔ ان میں سے کسی کو چالاک مخالف درکار نہیں — یہ خودمختار سافٹ ویئر کے عام بگز ہیں، فرق یہ کہ نتیجہ آپ کے اکاؤنٹ سے نکلتی رقم ہے۔
پرکشش حل یہ ہے کہ ایجنٹ کو زیادہ محتاط بنایا جائے: بہتر سسٹم پرامپٹ، سخت ہدایت، ایسا ماڈل جو خرچ کے بارے میں زیادہ سوچے۔ یوں کنٹرول سسٹم کی سب سے کم قابلِ اعتماد جگہ پر چلا جاتا ہے — ایجنٹ کی اپنی منطق، یعنی وہی چیز جسے قائل کر کے ہٹایا جا سکتا ہے۔ جس بجٹ سے ایجنٹ بحث کر کے نکل سکے وہ بجٹ نہیں۔ کنٹرول ایسی جگہ رہنا چاہیے جہاں ایجنٹ پہنچ نہ سکے، یعنی ایجنٹ سے بالکل باہر۔
پالیسی پروڈکٹ ہے، پرامپٹ نہیں
روک تھام کا ماڈل ایسی پالیسی ہے جسے پلیٹ فارم رقم حرکت کرنے سے پہلے نافذ کرتا ہے، ایجنٹ کے فیصلے کے بعد نہیں۔ ہر ایجنٹ کو فی ٹرانزیکشن حد اور یومیہ حد ملتی ہے — ہماری ڈیمو پالیسی میں €150.00 فی ادائیگی، €500.00 فی دن — اور اس کے اوپر €6,000.00 کی ماہانہ حد۔ یہ پلیٹ فارم کی جانچی ہوئی سخت دیواریں ہیں، ایجنٹ کے نبھائے ہوئے وعدے نہیں۔ جب ڈیمو کے ٹریول بوٹ نے €640.00 کا چارٹر کرنا چاہا تو ادائیگی موقع پر مسترد ہو گئی: حد سے زیادہ، ایک سینٹ حرکت کرنے سے پہلے۔ جو ایجنٹ روز بالکل درست چلتا ہو وہ بھی مہینے کی گنجائش سے آگے نہیں جا سکتا۔
بجٹ بتاتا ہے کتنا؛ الاؤ لسٹ بتاتی ہے کہاں۔ ایجنٹ صرف انہی مرچنٹس کو ادا کرتے ہیں جن کے نام آپ نے پہلے دیے ہوں۔ ڈیمو Ops Agent بالکل چار کو جانتا ہے، اور غیر فہرست وینڈر کو €180.00 کی کوشش not-listed کہہ کر رد ہوئی۔ دونوں مل کر ایک خانہ بناتے ہیں: اتنی رقم، صرف ان وصول کنندگان کو۔ خانے کے اندر ایجنٹ پوری رفتار سے چلتا ہے اور اسے پوچھنا نہیں پڑتا؛ خانہ وہ چیز ہے جس کا مالک انسان ہے۔
سوال کبھی یہ نہیں کہ AI ایجنٹ پیسہ خرچ کرے گا یا نہیں۔ سوال یہ ہے کہ جن قواعد کے تحت وہ خرچ کرتا ہے وہ کس نے لکھے — اور جواب ہمیشہ یہی ہونا چاہیے: کسی انسان نے، پہلے سے، تحریری طور پر۔
لکیر کے اوپر ایک انسان
کچھ فیصلے کسی خانے کے سپرد کرنے کے لیے بہت بڑے ہوتے ہیں۔ اس لیے پالیسی میں ایک حد ہوتی ہے: طے شدہ رقم جس سے اوپر ادائیگی ہونے سے پہلے انسان کی منظوری لازم ہے۔ ڈیمو میں یہ لکیر €100.00 پر ہے۔ جب Ops Agent نے Nord Logistics کی انوائس #088 کو نشان زد کیا — €120.00، €500.00 کے یومیہ بجٹ کے اندر مگر منظوری کی لکیر سے اوپر — تو اس نے ادائیگی نہیں کی۔ وہ رکا، تجویز کسی شخص کے سامنے رکھی، اور انتظار کیا۔ ایک سطر کے جواب سے منظوری ملی؛ ادائیگی ریفرنس 9F21-0716 کے ساتھ سیٹل ہوئی اور 09:41 پر آڈٹ لاگ میں درج ہو گئی۔ لکیر سے نیچے ایجنٹ خود چلتا ہے؛ اس سے اوپر پہلے انسان جواب دیتا ہے۔
منظوری ایسا چیک باکس نہیں جو غائب ہو جائے۔ اس میں درج ہوتا ہے کس نے منظور کیا، کس ڈیوائس سے، کس وقت، دستخط کے ساتھ — ایپ میں منظور، فون کی، 09:41:12۔ بعد میں جب کوئی پوچھے کہ ادائیگی کیوں ہوئی تو جواب ایک نامزد شخص اور ٹائم اسٹیمپ ہے، کندھے اچکانا نہیں۔
کِل سوئچ، اور ایسا لاگ جو چپکے سے ایڈٹ نہ ہو سکے
اچھی دیواروں کے اندر بھی ایجنٹ بگڑتے ہیں اور پالیسیاں غلط نکلتی ہیں۔ دو کنٹرول اسے سنبھالتے ہیں۔ پہلا کِل سوئچ ہے: ایک ٹیپ ایجنٹ کو روک دیتا ہے اور اس کی شروع کی جانے والی ہر ادائیگی فوراً بند ہو جاتی ہے۔ کیز درست رہتی ہیں تاکہ کچھ اور نہ ٹوٹے — ایجنٹ بس اس وقت تک خرچ نہیں کر سکتا جب تک انسان اسے دوبارہ آن نہ کرے، اور اس کی زیرِ التوا تجاویز غائب ہونے کے بجائے وہیں منجمد رہتی ہیں۔ ڈیمو فلیٹ میں ٹریول بوٹ €0.00 خرچ کے ساتھ رکا ہوا ہے، اس کی قطار جوں کی توں۔
دوسرا جزو صرف اضافے والا (append-only) آڈٹ لاگ ہے۔ ہر فیصلہ ریکارڈ پر ہوتا ہے: ایجنٹ نے کیا کرنے کی کوشش کی، کون سا پالیسی چیک پاس یا فیل ہوا، کس نے کیا منظور کیا، یہاں تک کہ key rotations بھی۔ ایک ریکارڈ سے پوری ادائیگی دوبارہ بنائی جا سکتی ہے — فیصلہ DEC-4471 میں درخواست، ہر پالیسی چیک اپنے نتیجے کے ساتھ (allowlist پاس، cap پاس، threshold ایسکلیٹ)، انسانی دستخط، اور طے شدہ رقم اپنے rail اور حوالہ نمبر کے ساتھ نظر آتی ہے۔ ہر اندراج اپنا hash، پچھلے اندراج کا hash اور زنجیر میں اپنی جگہ رکھتا ہے — ڈیمو میں #4,471 — اس لیے کوئی بھی فیلڈ بدلنے سے اس کے بعد کا ہر ریکارڈ ٹوٹ جاتا ہے۔ لاگ hash سمیت JSON میں ایکسپورٹ ہوتا ہے: یہ آپ کا ہے کہ آڈیٹر کے حوالے کریں، ہمارا نہیں کہ اپنے پاس رکھیں۔
سیٹلمنٹ سادہ رکھیں؛ جدت اتھارائزیشن میں رکھیں
ایجنٹک ادائیگیوں کو ہر سطح پر نیا بنانے کی ترغیب ہوتی ہے — نیا rail، نیا انسٹرومنٹ، رقم کے سفر کا نیا طریقہ۔ اس سے بچیں۔ حقیقی طور پر نیا حصہ اتھارائزیشن ہے: ایجنٹ کیسے ثابت کرے کہ اسے ادائیگی کی اجازت ہے، کس کی پالیسی کے تحت، اور کس منظوری کے ساتھ۔ ادائیگی یہ دروازہ پار کر لے تو اسے ان rails پر سیٹل ہونا چاہیے جو برسوں سے سادہ اور آزمودہ ہیں۔ ڈیمو میں منظور شدہ €120.00 کی تجویز ایک عام SEPA کریڈٹ ٹرانسفر بن جاتی ہے — منظوری کے چند منٹ بعد SEPA Instant کے ذریعے سیٹل — اور آگے چل کر اس ادائیگی سے الگ پہچانی نہیں جاتی جو کسی انسان نے کی ہو۔ بینک کو نہ معلوم ہوتا ہے نہ پروا کہ اسے ایجنٹ نے شروع کیا تھا۔
یہ تقسیم سوچی سمجھی ہے۔ سادہ rails قابلِ پیش گوئی ہوتے ہیں، جہاں اسکیم اجازت دے وہاں واپس ہو سکتے ہیں، اور ہر ٹریژری اور آڈیٹر انہیں سمجھتا ہے۔ جدت کو پالیسی میں اور ادائیگی کو سیٹل شدہ rail پر رکھنے کا مطلب ہے کہ خطرناک اور تیزی سے بدلنے والا حصہ وہ ہے جو پوری طرح آپ کے کنٹرول میں ہے، اور جو حصہ دوسروں کے بینکوں کو چھوتا ہے اسے کسی کو نئے سرے سے سیکھنا نہیں پڑتا۔ ایجنٹ اسی کور سے خرچ کرتے ہیں جس پر باقی Pay فیملی چلتی ہے — جس کا بیان /products/pay پر ہے — روبوٹس کے لیے بنائی گئی کسی الگ دنیا سے نہیں۔
پروٹوکول کا منظرنامہ ابھی طے نہیں ہوا — اسی کو سامنے رکھ کر بنائیں
ایجنٹ کو اپنی شناخت اور اپنا مینڈیٹ مرچنٹ کے سامنے کیسے پیش کرنا چاہیے، یہ ایک کھلا سوال ہے۔ کئی تجاویز مقابلے میں ہیں کہ ایجنٹ کیسے ثابت کرے وہ کون ہے، اسے کیا خریدنے کا اختیار ہے، اور مرچنٹ رقم قبول کرنے سے پہلے یہ کیسے جانچے۔ کوئی بھی جیت نہیں پائی، اور آج کسی ایک پر سب کچھ لگا دینا قبل از وقت ہوگا۔ محتاط طرزِ عمل یہ ہے کہ اتھارائزیشن پروٹوکول کو بدلنے کے قابل رکھیں اور اس کے پیچھے سب کچھ مستحکم: پالیسی انجن، آڈٹ ماڈل اور سیٹلمنٹ rail اس وقت نہیں بدلتے جب سامنے کا wire format بدلتا ہے۔
عملاً اس کا مطلب ہے ایک چھوٹی اور سادہ انٹیگریشن سطح۔ ایجنٹ mcp.protocore.io/agents پر MCP کے ذریعے جڑتے ہیں؛ جو بھی فریم ورک یہ پروٹوکول بولتا ہے وہ والیٹ رکھ سکتا ہے۔ انٹرفیس جان بوجھ کر محدود ہے — ادائیگی تجویز کریں، فیصلہ وصول کریں — کیونکہ دلچسپ منطق پلیٹ فارم پر رہتی ہے، پرامپٹ میں نہیں۔ جب انڈسٹری طے کر لے گی کہ ایجنٹ مرچنٹس کے سامنے خود کو کیسے ثابت کریں، تو سامنے کا حصہ بدلے گا اور اس کے پیچھے کی دیواریں ٹھیک وہیں رہیں گی جہاں تھیں۔
اس کا مقام
ایجنٹک ادائیگیاں اس بات کی شرط نہیں کہ خودمختار سافٹ ویئر بلا حد خرچ کرے۔ وہ اس کے برعکس ہیں: شرط یہ ہے کہ سافٹ ویئر خرچ کرے گا، اس لیے حدیں حقیقی، بیرونی اور واضح ہونی چاہئیں۔ بجٹ اور allowlists دائرہ کھینچتے ہیں، threshold بڑے فیصلے کسی انسان تک پہنچاتا ہے، kill-switch سب کچھ روک دیتا ہے، اور append-only لاگ کا مطلب ہے کہ ہر ادائیگی بعد میں دوبارہ بنائی جا سکتی ہے۔ /products/agents پر پروڈکٹ پیج یہاں استعمال ہونے والے ڈیمو ڈیٹا پر پورا چکر دکھاتا ہے — ایجنٹ بنائیں، پالیسی طے کریں، ادائیگی کو ایسکلیٹ اور سیٹل ہوتے دیکھیں — اور /products/pay وہ کور ہے جس پر یہ ادائیگیاں چلتی ہیں۔ خودمختاری حقیقی ہے؛ پٹہ بھی حقیقی ہے، اور اسے انسان تھامے ہوئے ہے۔
کوئی سسٹم بنوانا ہے؟
ہمیں مسئلہ بتائیں۔ ہم آرکیٹیکچر اور منصوبے کے ساتھ واپس آئیں گے۔