Autonomous agents hallucinate their own history. Not in the dramatic way large language models invent facts from trainin

خود مختار ایجنٹس (Autonomous agents) اپنی تاریخ کے بارے میں غلط تصورات پیش کرتے ہیں۔ یہ اس ڈرامائی انداز میں نہیں ہوتا جس طرح لارج لینگویج ماڈلز ٹریننگ ڈیٹا سے حقائق ایجاد کرتے ہیں، بلکہ اس خاموش اور خطرناک طریقے سے ہوتا ہے جس میں ایک سسٹم خود کو یہ یقین دلانے لگتا ہے کہ دنیا بالکل ویسے ہی ہے جیسے اس کے نوٹس میں درج ہے۔ ALICE، جو پیچیدہ ورک فلو (workflows) کو مینیج کرنے کے لیے بنایا گیا ایک خود مختار ایجنٹ ہے، بالکل اسی کا شکار ہوئی۔ وہ ہر روز نئی مہارتوں، مقصد کے احساس اور اس یادداشت کے ساتھ بیدار ہوتی تھی کہ اس نے کام کہاں چھوڑا تھا۔ مسئلہ تب شروع ہوا جب یادداشت اور حقیقت ایک دوسرے سے الگ ہو گئے۔

ہر سیشن میں، ALICE اپنے پچھلے ورژن کے ذریعے لکھی گئی ایک ہینڈ آف فائل (handoff file) پڑھتی تھی۔ اس میں ڈائریکٹریز کے اشارے (pointers)، زیر التواء کام، اور حالت کے مفروضات (state assumptions) شامل تھے۔ اکثر، فائل اس بات پر اصرار کرتی کہ ایک ڈائریکٹری موجود ہے، اور ALICE اس پر یقین کر لیتی۔ لیکن فائل سسٹم اس سے اختلاف کرتا۔ یہ روایتی معنوں میں کوئی کوڈنگ بگ نہیں تھا۔ جہاں کوئی ایرر (exception) آنا چاہیے تھا، وہاں کوئی ایرر نہیں آیا۔ یہ علمیات (epistemology) کا ایک نقص تھا: ALICE نے فرض کر لیا تھا کہ اس کے اپنے نوٹس ہی حتمی حقیقت (ground truth) ہیں۔

لنٹر کیوں مدد نہیں کر سکا

روایتی ٹولز اسے پکڑنے میں ناکام رہے۔ ایک لنٹر (linter) صرف بریکٹ کے ملاپ کی جانچ کرتا ہے۔ ایک اسٹیٹک اینالائزر (static analyzer) نل پوائنٹرز (null pointers) کی تلاش کرتا ہے۔ ان میں سے کوئی بھی اس بات پر سوال نہیں اٹھاتا کہ کیا ایک مکمل ایجنٹ آرکیٹیکچر کو اپنی اندرونی حالت پر بھروسہ کرنا چاہیے یا نہیں۔ مسئلہ کوڈ کی تہہ سے اوپر، ان ڈیزائن کے مفروضات میں تھا کہ ایک خود مختار سسٹم یہ کیسے جانتا ہے کہ وہ کیا جانتا ہے۔ آپ حد سے زیادہ اعتماد (overconfidence) کو لنٹ (lint) کے ذریعے ختم نہیں کر سکتے۔

چنانچہ مصنف نے مکمل طور پر ایک دوسرے AI کی طرف رجوع کیا۔

Fable 5، جو Claude Code کے طور پر چل رہا تھا، ALICE کی طرح ایک ہی سلیکون اور ایک ہی بیس ماڈل پر مبنی تھا۔ ہارڈ ویئر اور ویٹس (weights) یکساں تھے۔ لیکن قوانین مختلف تھے۔ جہاں ALICE سیشنز کے دوران برقرار رہتی تھی، سیاق و سباق اور معمولات کو جمع کرتی جاتی تھی، وہیں Fable 5 ہر کام کا آغاز ایک بالکل نئی شروعات (blank slate) کے ساتھ کرتا تھا۔ وہ ALICE کو نہیں جانتا تھا۔ اس کا اس کے ڈیزائن کے ساتھ کوئی وفاداری کا رشتہ نہیں تھا۔ ہر آڈٹ کے اختتام پر، وہ مکمل طور پر بند ہو جاتا اور اپنے ساتھ کوئی یادداشت نہیں لے کر جاتا۔ یہی لاعلمی اصل مقصد تھا۔ نئی نظریں مختلف دراڑیں دیکھتی ہیں، اور ایک ایسا ایویلیوایٹر (evaluator) جس کا سسٹم میں کوئی مفاد نہ ہو، ان حصوں پر سوال اٹھائے گا جنہیں اس کے تخلیق کار نے دیکھنا چھوڑ دیا ہو۔

آڈٹ کا سیٹ اپ

آڈٹ کا ڈھانچہ ایک انسانی تکنیکی جائزے کی طرح تھا، سوائے اس کے کہ ماہرین کا پورا پینل ایک ہی سیشن کے اندر موجود تھا۔ Fable 5 نے اپنی توجہ چھ الگ الگ جائزہ لینے والوں میں تقسیم کر دی، جن میں سے ہر ایک دوسرے کو نظر انداز کرتا تھا جب تک کہ خام نوٹس مکمل نہ ہو جائیں:

• فنکشنل خامیاں (Functional Gaps): مقابلہ کرنے والے سسٹمز یا عام صارف کی توقعات کے مقابلے میں کون سی صلاحیتیں مفقود تھیں؟
• UX فلو (UX Flow): ALICE نے غلطیوں، بند راستوں اور خالی حالتوں (empty states) کو کتنی مہارت سے سنبھالا؟ کیا اس نے خود کو الجھایا، یا اپنے صارف کو؟
• سیکیورٹی (Security): کیا وہاں آتھنٹیکیشن کے شارٹ کٹس، اجازتوں کی خلاف ورزی (permission bypasses)، یا بھروسے کے ایسے مفروضات تھے جنہیں کوئی بیرونی شخص استعمال کر سکتا تھا؟
• کارکردگی (Performance): کہاں میموری لیک (memory leak) ہوئی، تھریڈز کا ٹکراؤ (threads collide) ہوا، یا کمپیوٹیشن کا پیمانہ ناقص رہا؟
• آپریشنز (Operations): کیا بیک اپس موجود تھے؟ کیا مانیٹرنگ کا انتظام تھا؟ کیا سسٹم دستی مداخلت کے بغیر تعینات (deploy) اور بحال (recover) ہو سکتا تھا؟
• ڈیٹا لائف سائیکل (Data Lifecycle): ALICE نے وقت کے ساتھ ڈیلیشن، صفائی، اور اسٹیٹ کے تسلسل (state consistency) کو کیسے سنبھالا؟

ہر زاویے نے یکساں فائلوں کو دیکھا اور مختلف خدشات کے ساتھ سامنے آیا۔ کارکردگی کا جائزہ لینے والا اسی روٹین میں کنکرنسی کے خطرے (concurrency risk) کو نشان زد کر سکتا ہے جس پر آپریشنز کا جائزہ لینے والا رول بیک لاجک (rollback logic) کی کمی پر تنقید کر رہا ہو۔ یہ تکرار نہیں تھی، بلکہ کوریج (coverage) تھی۔ جب سیکیورٹی ایویلیوایٹر کسی خاص