میرے AI ایجنٹس نے ہماری ٹیم چیٹ میں نتائج پوسٹ کیے۔ ایک انسان نے جواب دیا، اور ایک دوسرے ایجنٹ نے پہلا پیغام دیکھے بغیر ہی مداخلت کر دی۔ اس تسلسل کے نتیجے میں سیاق و سباق (context) کا فقدان، کام کی تکرار، اور واضح غلطیاں پیدا ہوئیں۔ موجودہ memory server اور monitoring stack میں ایک ہلکا پھلکا Inter-Agent Communication Protocol (IACP) شامل کرنے کے بعد، یہ بے ترتیب گفتگو ختم ہو گئی اور ورک فلو منظم ہو گیا۔

یہ مسئلہ کیوں اہم تھا

پروڈکشن میں، AI ایجنٹس اب محض الگ تھلگ تجربات نہیں رہے؛ وہ micro-services کے طور پر کام کرتے ہیں جو ڈیٹا حاصل کرتے ہیں، کوڈ تیار کرتے ہیں، یا deployments کو ٹرگر کرتے ہیں۔ جب ہر ایجنٹ صرف انسانوں سے بات کرتا ہے، تو ذمہ داریوں کا ٹکراؤ ایک پوشیدہ race condition بن جاتا ہے۔ Slack کا ایک غیر متعلقہ پیغام بے ضرر لگتا ہے، لیکن ڈویلپرز متضاد نتائج کو سلجھانے میں منٹ ضائع کرتے ہیں، جب دو بوٹس ایک ہی repository میں ترمیم کرتے ہیں تو pipelines رک جاتی ہیں، اور آٹومیشن پر اعتماد کم ہو جاتا ہے۔

گمشدہ کڑی: ریئل ٹائم مشترکہ اسٹیٹ (shared state)

زیادہ تر ٹیمیں ایجنٹس کو "black boxes" کے طور پر دیکھتی ہیں جو ایک prompt وصول کرتے ہیں اور نتیجہ واپس کرتے ہیں، یہ فرض کرتے ہوئے کہ prompt میں تمام ضروری سیاق و سباق موجود ہے۔ حقیقت میں، ایجنٹس ایک مشترکہ ورک سپیس شیئر کرتے ہیں جہاں اسٹیٹ مسلسل بدلتی رہتی ہے: ایک repository لاک ہو سکتی ہے، کوئی سروس ڈاؤن ہو سکتی ہے، یا کوئی پچھلا تجزیہ ابھی ابھی مکمل ہوا ہو سکتا ہے۔ براڈکاسٹ میکانزم کے بغیر، ہر بوٹ پرانی معلومات (stale snapshot) پر کام کرتا ہے۔

موجودہ ٹولز پر IACP کی تعمیر

ایک بالکل نیا پلیٹ فارم بنانے کے بجائے، میں نے memory server (جو بات چیت کی ہسٹری محفوظ کرتا ہے) اور monitoring suite (جو ایجنٹ کی صحت پر نظر رکھتا ہے) کو وسعت دی۔ یہ پروٹوکول پانچ ٹھوس صلاحیتیں شامل کرتا ہے:

  • Structured Identity – ہر باہر جانے والے پیغام کے ساتھ ایک منفرد شناختی کوڈ ہوتا ہے جیسے کہ claude@greenmac:8f3a2c۔ یہ فارمیٹ فوری طور پر وصول کرنے والے کو بتا دیتا ہے کہ پیغام کس نے اور کس instance سے بھیجا ہے، جس سے مبہم "bot says X" والے بیانات کا خاتمہ ہو جاتا ہے۔

  • History Injection – جواب تیار کرنے سے پہلے، ایک بوٹ حالیہ ترین چیٹ سیگمنٹ (بشمول دوسرے ایجنٹس کے پیغامات) حاصل کرتا ہے اور اسے اپنے prompt کے شروع میں لگا دیتا ہے۔ اس طرح سیاق و سباق کبھی ضائع نہیں ہوتا، اور ماڈل اس بارے میں استدلال کر سکتا ہے کہ اس کے ساتھیوں نے پہلے ہی کیا حصہ ڈالا ہے۔

  • State Transitions – ایجنٹس بار بار heartbeats بھیجنا بند کر دیتے ہیں۔ اس کے بجائے، جب بھی ان کی اندرونی حالت بدلتی ہے، وہ اسٹیٹس کی تبدیلی پوسٹ کرتے ہیں—working، blocked، یا idle۔ صارفین فوری ردعمل دیتے ہیں، مثال کے طور پر کسی منحصر ٹاسک کو صرف اس وقت کیو (queue) میں ڈالتے ہیں جب upstream ایجنٹ idle رپورٹ کرے۔

  • Advisory Leases – جب کسی ایجنٹ کو کسی ریسورس (ایک repo، ایک API endpoint، یا ایک compute node) تک خصوصی رسائی کی ضرورت ہوتی ہے، تو وہ TTL (time-to-live) کے ساتھ ایک lease کا دعویٰ کرتا ہے۔ اگر ایجنٹ کریش ہو جائے تو lease خود بخود ختم ہو جاتی ہے، جس سے ریسورس دوسروں کے لیے آزاد ہو جاتا ہے اور دو بوٹس کے ایک دوسرے کے کام میں مداخلت کرنے کا خطرہ ٹل جاتا ہے۔

  • Inbox Mechanism – ایک "stop hook" ایجنٹ کے ورک فلو کو روک دیتا ہے اگر اس کے ان باکس میں غیر پڑھے گئے پیغامات موجود ہوں۔ ایجنٹ کو اپنا موجودہ ٹاسک مکمل کرنے سے پہلے ان آئٹمز پر کارروائی کرنی ہوتی ہے، تاکہ اس بات کو یقینی بنایا جا سکے کہ زیر التوا کوآرڈینیشن سگنلز کو نظر انداز نہ کیا جائے۔

یہ تمام حصے مل کر ایک سادہ اور قابل مشاہدہ کمیونیکیشن لیئر بناتے ہیں جو ہر شریک فرد کو ایک ہی صفحے پر رکھتا ہے۔

ان ٹیموں کے لیے خطرات جو اسے نظر انداز کرتی ہیں

اگر کوئی ٹیم ad-hoc prompts اور دستی نگرانی (manual monitoring) پر انحصار جاری رکھتی ہے، تو پوشیدہ اخراجات بڑھتے جاتے ہیں:

  • Duplicated effort – دو ایجنٹس ایک جیسے رپورٹ تیار کر سکتے ہیں، جس سے compute cycles اور کلاؤڈ اخراجات ضائع ہوتے ہیں۔
  • Resource contention – کوڈ بیس میں بیک وقت لکھنا (simultaneous writes) merge conflicts کا باعث بنتا ہے جن کے لیے انسانی مداخلت کی ضرورت ہوتی ہے۔
  • Operational risk – پرانی اسٹیٹ پر عمل کرنے والا ایجنٹ اس وقت deployment کی کوشش کر سکتا ہے جب دوسرا پہلے ہی rollback کر رہا ہو، جس سے سروس غیر مستحکم ہو سکتی ہے۔

ایجنٹس کے اپنی شناخت، اسٹیٹ اور ریسورس کے دعووں کے اعلان کرنے کے طریقے کو باقاعدہ بنا کر، IACP کسی بھاری بھرکم orchestration engine کے بغیر ان خطرات کو کم کرتا ہے۔

جوابی نکتہ: اضافی بوجھ (overhead)

ناقدین کا کہنا ہے کہ ہسٹری شامل کرنے اور leases کو مینیج کرنے سے latency اور اضافی کوڈ پاتھز بڑھ جاتے ہیں۔ ایسے ماحول میں جہاں ایک ایجنٹ صرف ایک محدود ٹاسک سنبھالتا ہے، پروٹوکول کے فوائد معمولی ہو سکتے ہیں۔ تاہم، یہ عمل موجودہ memory اور monitoring services کو دوبارہ استعمال کرتا ہے، اس لیے اضافی بوجھ بہت کم ہے۔ ان ٹیموں کے لیے جو پہلے ہی ایجنٹس کے درمیان الجھن کا شکار ہیں، یہ سودا (trade-off) واضح طور پر فائدہ مند ہے۔

آگے کیا دیکھنا ہے

یہ پروٹوکول ابھی ایک پروٹو ٹائپ ہے، لیکن اس کی ماڈیولر نوعیت اسے کسی بھی language-agnostic agent framework کے ساتھ انٹیگریٹ کرنے کی دعوت دیتی ہے۔ ممکنہ اگلے اقدامات میں شامل ہیں:

  • ایک ہلکا پھلکا SDK جاری کرنا تاکہ ڈویلپرز کور لاجک کو چھیڑے بغیر پانچ ہکس شامل کر سکیں۔
  • مانیٹرنگ سویٹ میں ایسے میٹرکس کا اضافہ کرنا جو اسٹیٹ ٹرانزیشنز اور لیز چرن کو بصری طور پر ظاہر کریں، جس سے ٹیموں کو رکاوٹوں کی نشاندہی کرنے میں مدد ملے۔
  • ایسی پالیسی تہوں کے ساتھ تجربات کرنا جو زیادہ ٹریفک والے حالات میں خود بخود مخصوص ایجنٹس کی لیز کو دوسروں پر ترجیح دیں۔

اگر یہ توسیع پذیر خصوصیات مقبول ہو جاتی ہیں، تو IACP ملٹی ایجنٹ پروڈکشن پائپ لائنز کے لیے ایک ڈی فیکٹو معیار بن سکتا ہے، بالکل اسی طرح جیسے HTTP نے ویب سروسز کے لیے کیا۔

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