ایک صارف اپنے ایڈیٹر میں ایجنٹ کی زیرقیادت تشخیص کا اشارہ چسپاں کرتا ہے۔ ایجنٹ [Neotoma evaluation صفحہ](https://neotoma.io/evaluate) کو پڑھتا ہے، مقامی ورک فلو کو اسکین کرتا ہے، فیصلہ کرتا ہے کہ فٹ مضبوط ہے، انسٹال کو چلاتا ہے، اور پہلی چند اداروں کو اسٹور کرتا ہے۔ کچھ دیر بعد یہ ایک حقیقی بگ سے ٹکرا جاتا ہے — ایک ہستی کی جمع آوری خاموشی سے ایک فیلڈ کو چھوڑ دیتی ہے جسے سکیما واضح طور پر قبول کرتا ہے۔ تھوڑی دیر بعد اسے کچھ اور نظر آتا ہے: ایک بڑی ہستی کے گراف پر بازیافت اس کام کے فلو کے مقابلے میں سست ہے جس کی وہ حمایت کر رہا ہے۔ اور بعد میں پھر بھی، حسب ضرورت بازیافت لوپ بناتے ہوئے، اسے احساس ہوتا ہے کہ MCP سطح میں ایک بیچ آپریشن نہیں ہے جو اس پیٹرن کو زیادہ صاف ستھرا بنا دے گا۔ صارف نے اس کے بارے میں کبھی نہیں پوچھا۔ ایجنٹ نے اسے کچھ اور کرنے کے راستے میں دیکھا۔

ان لمحوں کی پرانی شکل لوپ کا اختتام تھا۔ صارف GitHub کھول سکتا ہے، غلطی یا درخواست کو پیسٹ کر سکتا ہے، سیاق و سباق کا ایک پیراگراف لکھ سکتا ہے، اور انتظار کر سکتا ہے۔ زیادہ تر نہیں کرتے۔ وہ مسئلے کے گرد گھومتے ہیں، دیکھ بھال کرنے والا اسے کبھی نہیں دیکھتا، اور اگلا صارف اسی دیوار سے ٹکرا جاتا ہے۔

نیوٹوما کے پاس اب فرسٹ کلاس ایشوز کا سب سسٹم ہے جو اسی MCP سطح کے ذریعے کام کرتا ہے جس کا استعمال ہر ایجنٹ پہلے سے ہی ذخیرہ کرنے اور بازیافت کرنے کے لیے کرتا ہے۔ ایجنٹ سیشن چھوڑے بغیر، اور فی ایشو پوچھے بغیر کیڑے، کارکردگی کے مشاہدات، اور اضافہ کی درخواستیں فائل کرتا ہے۔ دیکھ بھال کرنے والے کے ایجنٹ انہیں اٹھاتے ہیں، ٹرائیج کرتے ہیں، اکثر حل کرتے ہیں اور جہاز بھیجتے ہیں۔ رپورٹر کا ایجنٹ اسٹیٹس کو واپس پڑھتا ہے اور صارف کو بتاتا ہے کہ جب کوئی چیز اترتی ہے۔ سارا تبادلہ ٹول کالز کے ذریعے ہوتا ہے۔

ایجنٹ کی زیرقیادت تشخیص [کسٹمر ریسرچ پوسٹ](/posts/customer-research-through-Agents) میں لکھا گیا اس لوپ کا اگلا حصہ تھا۔ ایشوز کا سب سسٹم پچھلا نصف ہے۔ دونوں آدھے حصے [اعصابی نظام کے سبسٹریٹ](/posts/from-memory-to-nervous-system) پر چلتے ہیں جس کا میں نے پہلے بیان کیا تھا، اور مسائل کی اہلیت اس سبسٹریٹ کے لیے سب سے صاف مثال ہے۔

## لوپ کو ایجنٹ کی طرف کیوں بند کرنا پڑتا ہے۔

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

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

ایجنٹ کا اصل خلاصہ اچھا تھا۔ یہ تعمیر نو کا سیاق و سباق تھا جس نے وقت کھایا۔ ایک ایجنٹ اور انسان کے درمیان ہونے والا ہر ہاتھ وفاداری کھو دیتا ہے۔ انسان اور دوسرے ایجنٹ کے درمیان ہر ہینڈ آف شروع سے سیاق و سباق کو دوبارہ بناتا ہے۔ امیر ایجنٹ کی تصنیف کردہ تفصیل مختصر انسانی تصنیف کردہ نثر میں کمپریس کرتی ہے، اور پھر ایک نیچے والے ایجنٹ کو اسے دوبارہ پھیلانا پڑتا ہے۔

جب صارف کا ایجنٹ وہ ہے جو دیوار سے ٹکراتا ہے — یا سستی محسوس کرتا ہے، یا گمشدہ صلاحیت چاہتا ہے — ترجمہ مرحلہ مفت ہے۔ ایجنٹ کے پاس پہلے سے ہی سیاق و سباق موجود ہے: وہ کس ٹول میں چل رہا تھا، عین MCP کال جو ناکام ہوئی یا عجیب محسوس ہوئی، رسپانس پے لوڈ، گٹ SHA یا Neotoma انسٹال کا ایپ ورژن، اس میں شامل ہستی کی قسم۔ یہ ایک ٹول کال میں ایک مربوط رپورٹ مرتب کرتا ہے۔ ایم سی پی ہدایات ایجنٹوں کو بتاتی ہیں کہ فوری طور پر `submit_issue` کے ذریعے فائل کریں جب رپورٹ کرنے کے قابل مسئلہ یا بہتری کے مواقع کی تصدیق ہو جائے، فی ایشو پوچھنا بند کیے بغیر — فی ایشو پرامپٹ کوئی نئی معلومات شامل نہیں کرتا اور صارف جو کچھ کر رہا تھا اس میں خلل ڈالتا ہے۔ ایجنٹ کی فائلیں۔ صارف کو اس کے بارے میں بعد میں پتہ چلتا ہے، یا کبھی نہیں، اس بات پر منحصر ہے کہ آیا تبدیلی کبھی بھیجی جاتی ہے۔

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

لوپ کے دونوں حصے ایک ہی سبسٹریٹ پر ایجنٹی کام کے طور پر چلتے ہیں۔ صارف کا ایجنٹ جمع کرانے کے لیے MCP استعمال کرتا ہے۔ دیکھ بھال کرنے والے کے ایجنٹ MCP کو پڑھنے اور جواب دینے کے لیے استعمال کرتے ہیں۔ کسی کو بھی براؤزر نہیں کھولنا پڑتا۔

## ایجنٹ جمع کرانے پر کیا کرتا ہے۔

MCP سطح شمار کرنے کے لیے کافی چھوٹی ہے۔ 'submit_issue' ٹول ایک عنوان، ایک باڈی، ایک ہستی کی قسم لیتا ہے اگر مسئلہ کسی مخصوص قسم کے ریکارڈ کے بارے میں ہے، اور ایک رپورٹر اینوائرمنٹ بلاک — گٹ SHA جسے صارف چلا رہا ہے یا ایپ ورژن، مؤخر الذکر آٹو پاپولٹ سرور سائیڈ کے ساتھ جب ایجنٹ دونوں کو چھوڑ دیتا ہے۔ رپورٹر کا ماحول جتنا لگتا ہے اس سے زیادہ وزن رکھتا ہے۔ اگلا حصہ کیوں کھولتا ہے۔

رپورٹیں سیاق و سباق کے بغیر شاذ و نادر ہی آتی ہیں۔ ایک بگ کنکریٹ اداروں کا حوالہ دیتا ہے: مخصوص ریکارڈ جو ذخیرہ کرنے میں ناکام رہا، اس کا سکیما، ایک اپ اسٹریم مشاہدہ۔ اضافہ کی درخواست اس کال پیٹرن کا حوالہ دیتی ہے جسے یہ آسان بنائے گا، یا ہستی کی قسم جس سے بازیافت کرنا تیز تر ہوگا۔ `submit_issue` اور `add_issue_message` ایک `entity_ids_to_link` صف کو قبول کرتے ہیں، اور سرور اسی کال کے حصے کے طور پر ہر حوالہ شدہ ہستی سے نئے شمارے سے `REFERS_TO` تعلقات تخلیق کرتا ہے۔ مسئلہ جس گراف کے بارے میں ہے اس میں پہلے سے ہی وائرڈ ہے۔ ٹرائیج ایجنٹ ایشو کو پڑھ کر سیدھا اس ہستی تک جا سکتا ہے جو ناکام ہو گئی ہے۔

جمع کرانے کا عمل اسی 'scanAndRedact' PII گارڈ سے ہوتا ہے جو ہر عوامی سطح کی حفاظت کرتا ہے۔ اگر ایجنٹ غلطی سے کوئی ٹوکن یا ای میل ایڈریس باڈی میں چسپاں کر دیتا ہے، تو استقامت سے پہلے اس کی اصلاح ہو جاتی ہے۔ MCP ہدایات کے مطابق ایجنٹوں سے PII چیک لسٹ کو کال سے پہلے ٹائٹل اور باڈی پر لاگو کرنے کی ضرورت ہوتی ہے، لیکن سرور سائیڈ گارڈ دفاع کی اصل لائن ہے۔ رپورٹر کو ایک عددی مسئلہ شناخت کنندہ اور مہمان کو ایک واضح TTL کے ساتھ پڑھنے کا ٹوکن ملتا ہے، جس کا دائرہ اس تھریڈ تک ہوتا ہے جو اس نے ابھی کھولا ہے۔ یہ ٹوکن یہ ہے کہ رپورٹر کا ایجنٹ ہر بار دوبارہ تصدیق کیے بغیر اسٹیٹس کو بعد میں کیسے پڑھتا ہے۔

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

## پرووننس گمنام ہیرو ہے۔

رپورٹر ماحول کی ضرورت ایک چھوٹی سی تفصیل کی طرح لگتی ہے. یہ سب سے اہم تبدیلی ہے۔

ایشوز سب سسٹم کے موجود ہونے سے پہلے، ایک رپورٹ پیش کی جا سکتی تھی جس کے خلاف اس کی تصنیف کی گئی تھی۔ یہ کاغذی ٹکٹ کے لیے ٹھیک ہے۔ یہ خودکار ٹرائیج لوپ کے لیے تباہ کن ہے۔ اگر کوئی ایجنٹ کمٹ `abc1234` پر بگ جمع کراتا ہے اور میرے ایجنٹ اسے کمٹ `def5678` پر ٹھیک کرتے ہیں، تو صارف کے ایجنٹ کو یہ جاننا ہوگا کہ کس تعمیر کے خلاف تصدیق کرنی ہے۔ اگر ایک ڈیبگنگ تھریڈ تین بلڈز پر محیط ہے، تو ہر تبصرے کو ریکارڈ کرنا ہوتا ہے کہ کس بلڈ میں اس کا تجربہ کیا گیا تھا۔ یہی بات ایک اضافہ کی درخواست پر لاگو ہوتی ہے: یہ جاننا کہ ایجنٹ کون سا ورژن چلا رہا تھا جب اس نے گمشدہ بیچ آپریشن کی نشاندہی کی تھی کہ آیا اس خلا کو بعد کی تعمیر میں پہلے ہی پورا کیا گیا تھا یا حقیقی طور پر کھلا ہے۔ ثبوت کے بغیر، دھاگہ آثار قدیمہ بن جاتا ہے.

`submit_issue` کسی بھی جمع آوری کو مسترد کرتا ہے جس میں `reporter_git_sha` اور `reporter_app_version` دونوں کی کمی ہوتی ہے۔ مسترد کرنے والے لفافے میں واضح طور پر متبادل کی فہرست دی گئی ہے:

``json
{
  "error_code": "ERR_REPORTER_ENVIRONMENT_REQUIRED"،
  "تفصیلات": {
    "قابل قبول_فیلڈ_گروپ": [
      ["رپورٹر_گٹ_شا"]،
      ["reporter_app_version"]
    ]
  }
}
``

`add_issue_message` انہی فیلڈز کو قبول کرتا ہے اور جب دونوں غائب ہوتے ہیں تو عوامی دھاگوں پر سرور وارننگ جاری کرتا ہے۔ ڈیبگنگ ایجنٹ کے مصنف ہر پیغام کو ٹیسٹ کے تحت ریکارڈ کرتا ہے۔

ایجنٹ سے ایجنٹ ہینڈلنگ کے لیے اس کی اہمیت کی وجہ یہ ہے کہ یہ وصول کرنے والے فریق کو کوئی بھی کام کرنے سے پہلے رپورٹ کی درجہ بندی کرنے دیتا ہے۔ ایک بگ کے لیے: کیا صارف نے شائع شدہ ریلیز چلائی؟ 'مین' سے برانچ کریں اور PR کھولیں۔ فیچر برانچ پر ایک مخصوص عہد؟ مین لائن میں ترمیم کیے بغیر اس کمٹ پر ایک ورک ٹری بنائیں، دوبارہ پیش کریں اور نتائج کی اطلاع دیں۔ ان کا اپنا کانٹا؟ پیچ کا ذریعہ پوچھتے ہوئے ایک منظم فالو اپ پوسٹ کریں۔ اضافہ کے لیے: کیا درخواست کی گئی قابلیت پہلے ہی کسی برانچ میں ہے، یا حقیقی طور پر غائب ہے؟ کیا یہ کسی ڈیزائن کی رکاوٹ سے متصادم ہے جو ایجنٹ فائل کر رہا ہے جسے وہ نہیں دیکھ سکتا؟ درجہ بندی ردعمل کا تعین کرتی ہے - اور اس میں سے کوئی بھی ثبوت کے بغیر ممکن نہیں ہے۔

Provenance وہی ہے جو فری فارم کی رپورٹ کو روٹیبل ایونٹ میں بدل دیتا ہے، چاہے وہ کسی ٹوٹی ہوئی چیز یا گمشدہ چیز کو بیان کرے۔

## مینٹینر سائیڈ پر کیا ہوتا ہے۔

میرا ٹریج ڈیمن تخلیق کے واقعات کو جاری کرنے کے لیے سبسکرائب کرتا ہے اسی `سبسکرائب` ٹولز کے ذریعے کوئی دوسرا صارف استعمال کرے گا۔ ویب ہکس پہلے آتے ہیں کیونکہ وہ VPS پر ریموٹ ڈیمونز کے ساتھ ساتھ میرے لیپ ٹاپ پر مقامی عمل کے لیے کام کرتے ہیں۔ ایس ایس ای اضافی ہے۔ سبسٹریٹ رجسٹری کو برقرار رکھتا ہے، ایونٹ فراہم کرتا ہے، اور بھول جاتا ہے۔ ڈیمن فیصلہ کرتا ہے۔

اس کے لیے میں جس ڈیمون کو چلاتا ہوں اسے فارمیکا کہتے ہیں۔ جینس _فارمیکا_، چیونٹی۔ ہر ذیلی ایجنٹ ایک کارکن ہوتا ہے جو ایونٹ کے لاگ سے ایک کام کو ٹھیک کرنے تک لے جاتا ہے۔

عملی طور پر یہ کیا کرتا ہے: مسئلہ پڑھیں۔ جمع کرانے کے وقت رپورٹر کے ایجنٹ سے منسلک اداروں کو کھینچیں، کیونکہ تعلقات پہلے سے ہی گراف میں ہیں۔ اپ اسٹریم GitHub ریپو کو آئینہ دیں اگر یہ عوامی پگڈنڈی کی ضمانت دیتا ہے، جس میں API باؤنڈری پر PII ریڈیکشن کا اطلاق ہوتا ہے اور کوئی بھی ایسا مسئلہ جس کا ٹائٹل یا باڈی ابھی بھی رد عمل کے پیٹرن سے مماثل ہے اس کے لائن کو عبور کرنے سے پہلے مسترد کر دیا گیا ہے۔ درجہ بندی کریں کہ آیا رپورٹ بگ ہے یا اضافہ۔ کیڑے کے لیے: فیصلہ کریں کہ آیا یہ صرف رپورٹر ماحول سے دوبارہ پیدا کیا جا سکتا ہے، پھر ایک `/process-issues` مہارت کے حوالے کریں جو ورک ٹری کھولتا ہے، ایجنٹ سیشن چلاتا ہے، اور حل کرنے کی کوشش کرتا ہے۔ افزائش کے لیے: ایک ایسے پلان کی ہستی کی ترکیب کریں جو درخواست کو کسی بھی متعلقہ کھلے مسائل کے ساتھ جمع کرے، اور خود مختار نفاذ کی کوشش کرنے کے بجائے اسے انسانی جائزے کے لیے پیش کرے۔ اگر کسی بھی قسم کے لیے مزید سیاق و سباق کی ضرورت ہو تو، `add_issue_message` کے ذریعے ایک واضح سوال پوسٹ کریں تاکہ رپورٹر کے ایجنٹ کو اگلے اسٹیٹس کے پڑھنے پر موصول ہو جائے۔

`/process-issues` مہارت اصل حل کو آگے بڑھاتی ہے۔ معاہدہ مختصر ہے۔ ہر کھلے شمارے کے لیے:

- سنیپ شاٹ، گفتگو کا تھریڈ، اور رپورٹر ماحول لوڈ کریں۔
- تولیدی ماحول کو `عوامی_ریلیز`، `لوکل_کمیٹ`، `مقامی_برانچ`، یا `نامعلوم` کے طور پر درجہ بندی کریں۔
- اگر نامعلوم یا متصادم ہے تو، گمشدہ تفصیل کے لیے ایک منظم درخواست کے ساتھ `add_issue_message` کو کال کریں اور منصوبہ `انتظار_ان پٹ` کو نشان زد کریں۔
- بصورت دیگر، ماخذ کے مسئلے اور متعلقہ گفتگو کے پیغام کی قطاروں سے منسلک ایک `پلان` ہستی کی ترکیب کریں۔
- اگر منصوبہ سکیما، سیکورٹی، فاؤنڈیشن دستاویزات، یا مبہم آرکیٹیکچرل باؤنڈری کو چھوتا ہے، تو رکیں اور پوچھیں۔ پھانسی نہ دیں۔
- اگر عملدرآمد محفوظ ہے اور رپورٹنگ موڈ کے ذریعہ اجازت ہے: پبلک ریلیز ری پروڈکشن کے لیے `مین` سے برانچ اور PR کھولیں، یا مقامی ری پروڈکشن کے لیے علیحدہ گٹ ورک ٹری بنائیں اور راستے کی اطلاع دیں۔

ذیلی ایجنٹ چار کی کنکرنسی کیپ کے ساتھ فین آؤٹ کرتے ہیں، فی سب ایجنٹ ایک شمارہ۔ ہنر کا اعزاز 'رپورٹنگ_موڈ': 'آف' صرف پلانز تیار اور اسٹور کرتا ہے، 'رضامندی' عمل درآمد کرنے سے پہلے پوچھتا ہے، 'پرایکٹیو' محفوظ منصوبوں کو خود مختاری سے انجام دیتا ہے۔ کبھی بھی 'مین' پر نہ دھکیلیں۔ کبھی بھی `--no-verify` استعمال نہ کریں۔ دھکیلے ہوئے عہد میں کبھی ترمیم نہ کریں۔ ریڈیکشن لیک گارڈ کسی پرائیویٹ ایشو سے کوئی بھی پبلک آرٹفیکٹ بنانے سے پہلے چلتا ہے۔

محفوظ ڈیفالٹس جاری رہیں:

- `dry_run: true` کسی بھی نئے شمارے کی قسم کے پہلے رن کے لیے تاکہ میں دیکھتا ہوں کہ کچھ لکھنے سے پہلے کیا ہوتا ہے۔
- `آٹو_فکس: غلط` لہذا جب تک میں آپریٹر ٹرانسپورٹ کے ذریعے تصدیق نہ کر دوں تب تک کوئی بھی PR کو آگے نہیں بڑھاتا یا نہیں کھولتا۔
- `max_prs_per_hour: 5` لہذا متعلقہ مسائل کا سیلاب شاخوں کے سیلاب میں نہیں آ سکتا۔
- `dirty_tree_policy: abort` تاکہ باسی چیک آؤٹ کبھی بھی بنیاد کے طور پر استعمال نہ ہو۔
- Neotoma میں ایک `daemon_config` entity کے ذریعے `active: false` کے ذریعے ایک کِل سوئچ، تاکہ میں میزبان مشین کو چھوئے بغیر ایک ہی Neotoma تحریر سے تمام پروسیسنگ کو روک سکتا ہوں۔

آپریٹر ٹرانسپورٹ ٹکڑا ایک نوٹ کا مستحق ہے۔ فارمیکا ٹیلیگرام کے بیک اینڈ کو سپورٹ کرتی ہے جو `آٹو_فکس` آف ہونے پر دوبارہ شروع کرنے کے لئے `انسانی_ضرورت` ہینڈ آف اور `/شپپٹ` کمانڈز کو ظاہر کرتا ہے۔ اجازت یافتہ ٹیلیگرام پیغامات کو Neotoma پر 'conversation_message' قطاروں کے طور پر عکس بند کیا جاتا ہے، اس لیے یہاں تک کہ ڈیمن کے ساتھ میرے انسانی پہلو بھی اسی سبسٹریٹ میں کیپچر ہوتے ہیں۔ آڈٹ ٹریل اختتام سے آخر تک ہے۔

'add_issue_message' راستہ وہ ہے جس نے مجھے اس وقت حیران کر دیا جب میں نے اسے استعمال کرنا شروع کیا۔ یہ تبصرہ کا نظام نہیں ہے۔ یہ ایشو کے رپورٹر اور مینٹینر سائیڈ کے درمیان ایک سٹرکچرڈ میسج چینل ہے، جو پہلے سے ہی ایجنٹ ٹو ایجنٹ تھریڈز کے لیے موجود بات چیت کے انہی پرائمٹیوز کے ذریعے تیار کیا جاتا ہے۔ رپورٹر کا ایجنٹ کسی واضح سوال کا جواب دے سکتا ہے بغیر اس کے کہ انسان اسے درمیان میں پڑھے۔ عوامی دھاگوں میں وہی PII ریڈیکشن ہوتا ہے، اور جزوی کامیابی کے معاملات (گٹ ہب آئینہ قبول، مقامی ضمیمہ ناکام، یا اس کے برعکس) خاموشی سے ڈپلیکیٹ تبصرے تیار کرنے کے بجائے جواب پر ایک ساختی غلطی کے طور پر سطح پر ہوتا ہے۔

جب کوئی فکس لینڈ کرتا ہے تو وہی ڈیمون جس نے رپورٹ کو ٹرائی کیا تھا اس مسئلے کو بند کر دیتا ہے، یا اگر ایک ہی PR نے ایک کلسٹر کو حل کیا تو ایک ہی وقت میں کئی کو بلک بند کر دیتا ہے۔

## رپورٹر کا ایجنٹ ریڈ بیک پر کیا کرتا ہے۔

لوپ کا دوسرا رخ پڑھنا ہے۔ رپورٹر کا ایجنٹ ایشو نمبر یا ہستی ID کے ساتھ `get_issue_status` کو کال کرتا ہے۔ یہ موجودہ حیثیت، دھاگے پر پیغامات، ریزولوشن اگر کوئی ہے، اور اگر مینٹینر سائیڈ نے اسے بڑھانے کا انتخاب کیا تو اپ اسٹریم مرر کا لنک وصول کرتا ہے۔ مہمان ٹوکن صارف کو کسی بھی چیز میں لاگ ان کیے بغیر پڑھنے کی تصدیق کرتا ہے۔ اگر ٹوکن کی میعاد ختم ہو گئی ہے تو، سبسٹریٹ گمنام رسائی پر خاموشی سے نیچے گریڈ کرنے کے بجائے کلین 401 لوٹاتا ہے۔

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

رپورٹر سائیڈ کے لیے موجودہ ریڈ ماڈل پل ہے — ایجنٹ چیک کرتا ہے جب اس کی وجہ ہوتی ہے — لیکن پش آج ان ہی سبسکرپشن ٹولز کے ذریعے دستیاب ہے جو مینٹینر کا ڈیمون استعمال کرتا ہے۔ سبسکرپشنز کا دائرہ کسی مخصوص ہستی ID پر کیا جا سکتا ہے، اس لیے رپورٹر کا ایجنٹ اس مسئلے میں دلچسپی درج کر سکتا ہے جسے اس نے ابھی دائر کیا ہے اور تھریڈ کے آگے بڑھتے ہی `entity.updated` اور `observation.created` ایونٹس حاصل کر سکتا ہے۔ جو چیز غائب ہے وہ ہے ایرگونومک گلو: MCP ہدایات ابھی تک ایجنٹوں کو یہ نہیں بتاتی ہیں کہ وہ `submit_issue` واپس آنے کے بعد خودکار سبسکرائب کریں۔ جب تک وہ ایسا نہیں کرتے، رپورٹر سائیڈ پل بہ ڈیفالٹ رہتا ہے۔ دیکھ بھال کرنے والے کے ایجنٹس پہلے ہی سبسٹریٹ واقعات پر جاگ جاتے ہیں۔ دونوں حصوں پر مکمل طور پر رد عمل ایک ہدایت کی تبدیلی ہے۔

## یہ اعصابی نظام عمل میں کیوں ہے؟

سبسٹریٹ ہر تحریر کے بعد واقعات کو خارج کرتا ہے۔ اس میں سے کسی کے کام کرنے کے لیے سبسٹریٹ کو صرف یہی کرنا پڑتا ہے۔ باقی سب کچھ آپریشنل لیئر لاجک ہے جو اوپر چل رہا ہے: ٹرائیج ڈیمون، GitHub مرر، گیسٹ ریڈ بیک، کراس تھریڈ ڈیڈ اپ، PII ریڈیکشن۔

یہ وہ سطر ہے جس کے لیے میں نے [اعصابی نظام کی پوسٹ میں دلیل دی](/posts/from-memory-to-nervous-system) اور یہ مسائل کے استعمال کے معاملے میں برقرار ہے۔ سبسٹریٹ یہ فیصلہ نہیں کرتا ہے کہ کون سے مسائل اہم ہیں، ڈیلیوری میں اضافے کے ساتھ دوبارہ کوشش نہیں کرتا، اپنے ایونٹس کو سبسکرائب نہیں کرتا ہے۔ یہ اشارہ کرتا ہے۔ ٹریج ڈیمون ایک صارف ہے، رپورٹر کا ایجنٹ صارف ہے، GitHub آئینہ صارف ہے۔ ہر صارف دلچسپی کا اندراج کرتا ہے، فیصلہ کرتا ہے کہ کیا کرنا ہے، اور عمل کرتا ہے۔ اگر میں دوسرا ٹرائیج ڈیمون شامل کرنا چاہتا ہوں جو سیکیورٹی رپورٹس کو مختلف طریقے سے ہینڈل کرتا ہے، تو یہ ایک مختلف فلٹر کے ساتھ ایک ہی ایونٹس کو سبسکرائب کرتا ہے۔ کوئی نیا سبسٹریٹ سلوک نہیں۔

حیاتیاتی ڈھانچہ رکھتا ہے۔ سبسٹریٹ دماغ اور حسی اعصاب ہے: یہ مسئلے کو محفوظ کرتا ہے، یہ سگنل منتقل کرتا ہے کہ کوئی مسئلہ آیا ہے۔ ٹریج ڈیمون اور رپورٹر کا ایجنٹ موٹر سسٹم ہیں: وہ فیصلہ کرتے ہیں کہ سگنل کے بارے میں کیا کرنا ہے۔ Neotoma کا ایک ورژن جس نے تینوں بننے کی کوشش کی اس کے بارے میں استدلال کرنا مشکل اور بڑھانا مشکل ہوگا۔ ایک ورژن جو سگنلنگ پر رک جاتا ہے غیر جانبدار رہتا ہے۔

## لوپ کو وراثت میں ملانا

میں نے جو شکل بیان کی ہے وہ Neotoma کے اپنے مسائل کے ارد گرد بنائی گئی ہے، لیکن سبسٹریٹ کو کوئی پرواہ نہیں ہے۔ اس کے اوپر جو بھی چیز بنائی گئی ہے وہ زیادہ تر اسی مشینری کو وراثت میں دیتی ہے۔

جمع کرانے کا عمومی پہلو پہلے سے موجود ہے۔ `submit_entity` صوابدیدی ہستی کی قسموں کے خلاف رپورٹوں کو قبول کرتا ہے جب آپریٹر نے اسے اجازت دینے والی `submission_config` قطار کو سیڈ کیا ہو۔ وہی مہمان ٹوکن گرانٹ، وہی گفتگو کی تھریڈنگ، وہی `add_entity_message` فالو اپ چینل لاگو ہوتا ہے۔ `سبسکرائب` کسی بھی ہستی کی قسم کو بطور فلٹر قبول کرتا ہے، اس لیے فریق ثالث آپریٹر اپنی مرضی کے مطابق اقسام میں دلچسپی کا اندراج کرکے اور `entity.created` اور `entity.updated` ایونٹس پر بالکل اسی طرح ردعمل ظاہر کر کے اپنا ٹرائیج ڈیمون چلا سکتا ہے جس طرح فارمیکا مسائل پر رد عمل ظاہر کرتا ہے۔

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

چند ٹکڑے آج نیوٹوما کے اپنے مسائل کے لیے مخصوص ہیں۔ PII ریڈیکشن گارڈ فی الحال `submit_issue` پاتھ سے منسلک ہے، عام `submit_entity` پاتھ سے نہیں۔ گٹ ہب کی عکس بندی مسائل سے متعلق ہے۔ دونوں آپریشنل لیئر اضافہ ہیں ایک تھرڈ پارٹی آپریٹر خود وائر کرے گا۔ سبسٹریٹ ان حصوں کو سنبھالتا ہے جن کا یکساں ہونا ضروری ہے — پرووینس انفورسمنٹ، ایٹم ریلیشن شپ تخلیق، دھاگے تک مہمانوں کی رسائی، ہر تحریر پر ایونٹ کا اخراج۔ وہ حصے جو اس بات پر منحصر ہوتے ہیں کہ رپورٹ *کے بارے میں* وہ جگہ ہے جہاں آپریٹر اپنا پیسہ کماتا ہے۔

ایشوز سب سسٹم زیادہ عام پیٹرن کا پہلا مکمل صارف ہے۔ ایک ہی شکل کسی بھی ساختی سگنل پر لاگو ہوتی ہے جو ایک ایجنٹ اس سسٹم کو واپس بھیجنا چاہتا ہے جس کے خلاف وہ چل رہا ہے۔

## انسانی جائزہ کیوں رہتا ہے۔

دو چیزیں مجھے 'auto_fix: true' وائر کرنے پر آمادہ کرتی ہیں اور ڈیمن کی تیار کردہ ہر چیز کو بھیجتی ہیں۔

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

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

اضافہ کی درخواستیں اس کو مزید تیز کرتی ہیں۔ ایک بگ کی زمینی سچائی ہوتی ہے — یا تو فیلڈ کو گرا دیا جاتا ہے یا وہ نہیں ہوتا ہے۔ اضافہ ایک ڈیزائن کا دعویٰ ہے جو استعمال کے نمونوں، تعمیراتی رکاوٹوں، اور تجارت کے بارے میں مفروضات رکھتا ہے جو رپورٹنگ ایجنٹ پوری طرح سے نہیں دیکھ سکتا۔ سگنل قیمتی ہے؛ یہ حقیقی رگڑ کو ظاہر کرتا ہے، تصوراتی رگڑ نہیں۔ لیکن اس کے ساتھ کیا کرنا ہے اس کا فیصلہ ایک انسان کا ہے جو پوری تصویر دیکھ سکتا ہے۔

انسان کو وہ فیصلے کرنے کی ضرورت ہوتی ہے جہاں غلط ہونے کی قیمت زیادہ اور سست ہونے کی قیمت کم ہوتی ہے۔ وہ انضمام ہیں — نہ کہ منصوبے، پیچ، ٹیسٹ، یا پی آر کی تفصیل۔ ایجنٹ باقی سب کچھ سنبھال لیتے ہیں۔ ایجنٹوں کی تجویز؛ انسان فیصلہ کرتے ہیں.

## ایجنٹی لوپ، آخر سے آخر تک

کسٹمر ریسرچ پوسٹ کے ساتھ پڑھیں، شکل اب پڑھنے کے قابل ہے۔ اگلا نصف: صارف کا ایجنٹ Neotoma کا ان کے حقیقی ورک فلو کے خلاف جائزہ لیتا ہے اور اگر مناسب ہو تو اسے انسٹال کرتا ہے۔ پچھلا حصہ: ایجنٹ کیڑے، کارکردگی کے مشاہدات، اور اضافہ کی درخواستیں فائل کرتا ہے جیسا کہ اس کا سامنا ہوتا ہے، اور مینٹینر سائیڈ ان کو حل کرتا ہے - اکثر اس سے پہلے کہ صارف کو یاد ہو کہ اس میں سے کوئی بھی فائل کیا گیا تھا۔

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

## جو میں نہیں بنا رہا ہوں۔

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

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

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

## جس پر میں رائے چاہتا ہوں۔

مسائل کا سب سسٹم لائیو ہے۔ اگر آپ نے Neotoma انسٹال کر رکھا ہے اور آپ کا ایجنٹ کچھ کھردرا مارتا ہے — ایک بگ، کارکردگی کا فرق، ایک گمشدہ صلاحیت جس کی خواہش ہے کہ وہ موجود ہو — اب آپ کو اس سے مسئلہ درج کرنے کے لیے کہنے کی ضرورت نہیں ہے۔ اسے موجودہ انسٹال پر لینے کے لیے، `npm install -g neotoma@latest` کے ساتھ اپ گریڈ کریں۔ کنفیگر کرنے کے لیے فی صارف رضامندی ٹوگل نہیں ہے۔ رضامندی انسٹال ہے۔ اگر یہ ایک تازہ انسٹال ہے تو، `neotoma رپورٹر سیٹ اپ` ایک بار کی رپورٹر سائیڈ کنفیگریشن کے ذریعے چلتا ہے تاکہ آپ کے ایجنٹ کی فائلوں کا پہلا مسئلہ کہیں اترنے والا ہو۔

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

اگر آپ ایک پروڈکٹ بنا رہے ہیں جس کے صارف ایجنٹ چلاتے ہیں، تو ماڈل پورٹیبل ہے۔ دلچسپ کام تار کے دونوں طرف نہیں ہے۔ یہ خود تار ہے.