ایجنٹ ڈسپیچ لائف سائیکل

ڈسپیچ کیا ہے

ڈسپیچ ایک ایجنٹ کا ایک رن ہے، ایک گفتگو میں، ایک اڈاپٹر پر۔ اس کا سارا کچھ cc_server پر ہوتا ہے: کلائنٹ پیغام بھیجتا ہے اور پھر ایونٹس کو واپس اسٹریم ہوتے دیکھتا ہے۔ کسی بھی کلائنٹ میں ڈسپیچ کا کوئی راستہ نہیں ہے۔

ایجنٹس چھ وجوہات سے جگائے جاتے ہیں، جنہیں رن اپنے ویک کنٹیکسٹ کے طور پر لے کر چلتا ہے تاکہ ایجنٹ کو معلوم ہو کہ وہ کیوں جاگا ہے:

جاگنے کی وجہ	ٹرگر
userMessage	کسی نے اسپیس میں پیغام بھیجا، یا ایجنٹ کا ذکر کیا
assignment	ایجنٹ کو ایک ٹکٹ تفویض ہوا
pipelineStep	ایک پائپ لائن قدم نے اسے ڈسپیچ کیا
childCompleted	ایک ذیلی ٹکٹ مکمل ہوا
followUp	شیڈول شدہ فالو اپ ہارٹ بیٹ
recovery	ریکوری پاتھ نے ناکامی کے بعد دوبارہ ڈسپیچ کیا

ویک کنٹیکسٹ ان ids کو لے کر چلتا ہے جو وجہ کے ساتھ جاتے ہیں — ٹکٹ، اسپیس، پیغام، پائپ لائن رن — اور یہ ایجنٹ کے ماحول اور پرامپٹ میں انجیکٹ ہوتے ہیں۔

پرامپٹ کی تشکیل

پرامپٹ تہوں میں بنتا ہے، ہر تہہ ایک لیبل والا سیکشن:

• شناخت — ایجنٹ کی اپنی id، نام اور ورک اسپیس id، ساتھ میں واضح ہدایت کہ یہی UUIDs ورک اسپیس سے منسلک ٹولز کو دیے جائیں۔ ورک اسپیس ایجنٹ کا داخلی حصہ ہے، اس لیے ہمیشہ موجود رہتی ہے۔
• ٹول کیٹلاگ اور ریسورس پروٹوکولز، پھر ورک اسپیس لے آؤٹ۔
• سسٹم پرامپٹ اوور رائیڈ، اگر ایجنٹ کے پاس ہو، پھر شخصیت (کردار کے مطابق) اور ٹیم بریف۔
• مہارتیں — ایجنٹ پر موجود نام۔
• موجودہ موڈ کے لیے ایگزیکیوشن کنٹریکٹ اور طریقہ کار۔
• ویک کنٹیکسٹ اور مینشن کنٹیکسٹ: ایجنٹ کو کس نے بلایا اور اس کے ارد گرد کا روسٹر۔
• موڈ بلاک — موڈ کے صلاحیت پروفائل اور اس کی میٹریلائزڈ ٹول فہرست سے تیار ہوتا ہے، اس لیے کوئی پرامپٹ ایسے ٹول کا نام کبھی نہیں لے سکتا جو رن کے پاس واقعی نہ ہو۔
• میموری کنٹیکسٹ — کام کے لیے حاصل کیے گئے حقائق۔
• گفتگو کنٹیکسٹ — حالیہ اسپیس کی تاریخ، جو ایجنٹ کے کنفیگر کردہ کنٹیکسٹ سائز سے قطع نظر لفظ بہ لفظ ونڈو کے 50,000 حروف تک محدود ہوتی ہے۔ پرانی تاریخ کاٹ نہیں دی جاتی: ایجنٹ اسے get_messages کے ذریعے ضرورت پر حاصل کرتا ہے اور معنوی طور پر متعلقہ پرانے پیغام بھی سامنے آتے ہیں۔

سلیش کمانڈز خام صارف متن سے پارس ہوتی ہیں

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

کمانڈز دو جگہوں پر تقسیم ہیں۔ /todo اور /compact کمپوزر میں روک لی جاتی ہیں اور جان بوجھ کر کبھی پیغام کے طور پر محفوظ نہیں ہوتیں اور نہ ایجنٹ کو بھیجی جاتی ہیں — /compact کو محفوظ کرنا کمپیکشن کٹ کو ایک ٹرن پیچھے دھکیل دیتا اور ٹرانسکرپٹ کو آلودہ کرتا۔ /plan دونوں جگہ سنبھالی جاتی ہے: کمپوزر اسپیس کا موڈ پلٹ دیتا ہے، اور یہی چیز ٹول سطح، گارڈ پری سیٹ اور پرامپٹ کو اس ٹرن اور اس کے بعد کے ہر ٹرن کے لیے ہم آہنگ رکھتی ہے۔ /goal، /loop اور /skill:<name> خود رن کے اندر سنبھالی جاتی ہیں اور صرف بلٹ اِن ہارنس پر — /goal اور /loop لاگت بجٹ کے ساتھ خود مختار کام شروع کرتی ہیں، اور skill: والا نام ایک مہارت کے طور پر تلاش ہوتا ہے جس کا SKILL.md متن اس ٹرن کی ہدایت بن جاتا ہے۔ نیم اسپیس ہی دونوں ذخیرہ ہائے الفاظ کو الگ رکھتا ہے: کسی خالی نام کو مہارتوں کے خلاف حل کرنے کا مطلب تھا کہ plan یا compact نامی مہارت بلٹ اِن کی وجہ سے مستقل چھپی رہے۔ خالی غیر بلٹ اِن نام اب بھی حل ہوتا ہے، ان پیغامات کے لیے جو نیم اسپیس وجود میں آنے سے پہلے لکھے گئے۔ ناقابل شناخت نام سادہ متن کے طور پر گزر جاتا ہے۔

worktree کی تیاری

کچھ بھی چلنے سے پہلے، گفتگو کو اپنا کام کرنے کا روٹ ملتا ہے، جس کے نیچے ہر ریپو کے لیے الگ تھلگ copy-on-write worktree ہوتا ہے۔ ڈیفالٹ میں یہ ورک اسپیس سے منسلک ہر ریپو ہوتا ہے؛ PR اسپیس — یا واضح انتخاب کے ساتھ بنائی گئی اسپیس — صرف اجازت یافتہ ریپوز تیار کرتی ہے اور PR ریویو گفتگو اپنے ایک ریپو کو pull request کے ہیڈ ریف پر پن کرتی ہے جبکہ باقی اپنی ڈیفالٹ برانچ پر رہتے ہیں۔ سورس چیک آؤٹ کبھی تبدیل نہیں ہوتا اور اسپیس حذف ہونے پر پوری گفتگو ڈائریکٹری واپس لے لی جاتی ہے۔

جہاں بھی rift بھیجا جاتا ہے وہاں copy-on-write واحد عمل درآمد ہے، جس کی پشت پر بنڈل شدہ نیٹو ہے۔ ایسا فائل سسٹم جو reflink نہ کر سکے — یا ایسی ڈیٹا ڈائر جو ریپو سے مختلف والیوم پر ہو — فال بیک ہونے کے بجائے تیاری ناکام کر دیتا ہے۔ Windows پر بیک اینڈ git worktree ہے، جہاں بنانے کے لیے کوئی copy-on-write بیک اینڈ نہیں ہے، اور دوسرے ہوسٹس پر یہ خاموش تنزلی نہیں ہے۔ جس پلیٹ فارم میں rift بھیجا جاتا ہے وہاں اس کا غائب ہونا ٹوٹی ہوئی انسٹال ہے — سرور خاموشی سے فال بیک ہونے کے بجائے بوٹ کرنے سے انکار کر دیتا ہے، کیونکہ خاموش فال بیک خرابی کو ہمیشہ کے لیے ایک سست راستے کے پیچھے چھپا دیتا ہے۔

شناخت اور اسناد

ہر رن کے لیے دو شناختیں حل ہوتی ہیں، کسی بھی پراسیس کے شروع ہونے سے پہلے۔

Git مصنفیت۔ ایجنٹ جو کمٹ بناتا ہے وہ ایجنٹ کے طور پر تصنیف ہوتے ہیں — <Name> (agent) <agentId@agents.control-center.local> بطور GIT_AUTHOR_* اور GIT_COMMITTER_* — کبھی کسی انسان کی نقالی نہیں کرتے۔ local-part ایجنٹ کا UUID ہے، اس کا نام سلاگ نہیں۔ درخواست کرنے والے انسان کو Co-Authored-By: ٹریلر سے کریڈٹ ملتا ہے، جو ماحول میں لے جایا جاتا ہے اور سسٹم پرامپٹ میں ہدایت کی جاتی ہے۔ واضح طور پر کالر کا سیٹ کردہ شناخت ہمیشہ دونوں پر غالب آتی ہے۔

کوڈ ہوسٹ شناخت۔ رن کی GitHub سند ہمیشہ صرف بروکر کی ہوتی ہے — ریپو تک محدود App انسٹالیشن ٹوکن، یا اس کا ماحولیاتی PAT فال بیک — کبھی درخواست کرنے والے ممبر کا اپنا محفوظ ٹوکن نہیں۔ actingUserId PAT فال بیک کو حد میں رکھتا ہے تاکہ جو ممبر سرور کا مالک نہیں وہ سرور کی رسائی کا وارث نہ بنے؛ یہ ایجنٹ کے ماحول پر کوئی ذاتی ٹوکن نہیں چڑھاتا۔

ماڈل فراہم کنندہ کی اسناد ایک مقررہ ترتیب سے حل ہوتی ہیں اور ترتیب اہم ہے:

1. فی اڈاپٹر ماحولیاتی اوور رائیڈ،
2. کالر کا ماحول،
3. سرور کی اسناد اسٹور (OAuth ٹوکن کی میعاد قریب ہو تو تازہ کرتے ہوئے)،
4. پراسیس کا ماحول۔

چونکہ فی اڈاپٹر اوور رائیڈ پہلے آتا ہے، یہ ایپ میں جڑے فراہم کنندہ اکاؤنٹ پر خاموشی سے غالب آ جاتا ہے۔ اگر کوئی رن غلط اکاؤنٹ پر بل کر رہا ہو، تو پہلے اسی اوور رائیڈ کو دیکھیں۔ فراہم کنندہ کی اسناد ہوسٹ-گلوبل ہوتی ہیں — انسٹال کے ہر ورک اسپیس میں مشترک۔

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

لانچ

رن کو اس کے worktree کو کام کی ڈائریکٹری بنا کر شروع کیا جاتا ہے اور — Claude Code کے لیے — ایک تیار کردہ MCP کنفیگ کے ساتھ تاکہ ایجنٹ Control Center کی ٹول سطح تک پہنچ سکے۔ ACP اور ہارنس کے bash کو سانٹائز شدہ ماحول ملتا ہے؛ NoSandboxAdapter کے ذریعے Claude Code ہوسٹ کا ماحول وراثت میں لیتا ہے۔

OS سینڈ باکس رن کو صرف وہیں لپیٹتا ہے جہاں ہوسٹ کے پاس بیک اینڈ ہو

cc_server بوٹ پر ایک بار ہوسٹ کی جانچ کرتا ہے اور، بیک اینڈ دستیاب ہونے پر، ایجنٹ پراسیسز کو اس میں لپیٹ دیتا ہے — macOS پر Seatbelt، Linux اور WSL2 پر bubblewrap۔ ڈسپیچ کے دونوں سیم لپیٹے جاتے ہیں، کیونکہ وہ ایک سیم مشترک نہیں کرتے: Claude Code CLI سینڈ باکس پورٹ سے گزرتا ہے؛ ACP اڈاپٹرز اور بلٹ اِن ہارنس کا bash ٹول سینڈ باکس مینیجر سے گزرتے ہیں۔ یہی وہ چیز ہے جو رن کے محفوظ پاتھ لاگو کرتی ہے: آپ کے رجسٹرڈ ریپو چیک آؤٹ سینڈ باکس کے اندر، ہر موڈ میں، رائٹ ممنوع ہوتے ہیں۔

جہاں بیک اینڈ نہیں، وہاں رن سینڈ باکس میں نہیں ہوتا اور تلافی کے لیے کچھ اور نہیں بدلتا۔ یعنی Windows ہمیشہ (کوئی نیٹو ریپ نہیں — microvm ٹرمینلز اور رگز کے لیے الگ، پروب سے مشروط راستہ ہے) اور Linux یا WSL2 جہاں PATH پر bwrap اور socat نہ ہوں۔ سرور اپنی اسٹارٹ اپ لاگ لائن پر بتاتا ہے کہ وہ کس حالت میں ہے اور --sandbox off جان بوجھ کر باہر نکلتا ہے۔

سینڈ باکس آن ہونے پر بھی دو خلا باقی رہ جاتے ہیں۔ ہارنس کے پراسیس کے اندر چلنے والے فائل ٹولز (read, write, edit, apply patch, search, find, search_files) سرور پراسیس کے اندر چلتے ہیں، اس لیے کوئی پروفائل انہیں قابو نہیں کرتا — ان کی حد خود ٹولز کی پاتھ قید اور گارڈریلز ہے۔ اور Claude Code --dangerously-skip-permissions کے ساتھ شروع ہوتا ہے، اس لیے اس کی اپنی فائل کالز Control Center سے گیٹ نہیں ہوتیں اور شیل کمانڈز صرف ایک ہک سے گزرتی ہیں جو کمانڈ لائن پڑھتا ہے؛ OS سینڈ باکس ان کے گرد حد ہے۔

باقی حدیں ہر ہوسٹ پر قائم رہتی ہیں، سینڈ باکس ہو یا نہ ہو: رن کا اپنا worktree (جہاں rift بھیجا جاتا ہے وہاں copy-on-write؛ Windows پر git worktree)، صرف پڑھنے والے فورج ٹوکن جو ہر لانچ پر بروکر کے ذریعے دیے جاتے ہیں اور ٹیئر ڈاؤن پر واپس لے لیے جاتے ہیں، وہ پش جنہیں ایجنٹ رن گیٹ وے پر پش قاعدے سے گزرنا ہوتا ہے، یکجا ایکشن گارڈریلز (فیل-کلوزڈ — کوئی prompt فیصلہ جس سے کوئی منظور کرنے والا جڑا نہ ہو مسترد ہو جاتا ہے) اور وہ ٹول سطح جس کی گفتگو کا موڈ اجازت دیتا ہے۔ ACP اور ہارنس کا bash پھر بھی ماحول سانٹائز کرتے ہیں؛ NoSandboxAdapter کے ذریعے Claude Code ہوسٹ کا ماحول وراثت میں لیتا ہے۔

اسٹریمنگ

رن واپس ٹائپ شدہ ایونٹ ترتیب اسٹریم کرتا ہے، جسے اسٹریم پروسیسر میسج ڈیلٹاز کے طور پر محفوظ کرتا ہے، ٹرانسکرپٹ سیگمنٹس میں تہہ کرتا ہے اور میسجنگ ایونٹس میں بدلتا ہے:

ایونٹ	کیا لے کر آتا ہے
thinking	استدلال کا آؤٹ پٹ، سیدھا اندر دکھایا گیا
text	نظر آنے والا آؤٹ پٹ
toolCall	ایک ٹول کی کال، اس کی id اور ساختی دلائل کے ساتھ
toolResult	مطابق نتیجہ، خرابی یا جزوی اسٹریم ہونے پر نشان زد
usage	پیمائش کی ونڈو کے لیے ٹوکن کی گنتی اور لاگت
error	ایک ایرر، اڈاپٹر کا ساختی کوڈ شامل جب اس نے رپورٹ کیا ہو
sandboxViolation	OS نے سس کال سے انکار کیا۔ صرف وہیں جاری ہوتا ہے جہاں سینڈ باکس واقعی پراسیس کو لپیٹ رہا ہو — اوپر نوٹ دیکھیں
debug	رن ٹائم تشخیص (لانچ مارکر، گارڈ فیصلے، کنٹریکٹ کی جھٹکیں)
done	رن مکمل ہوا

رن کو کیا حد میں رکھتا ہے

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

• ماڈل خود رک جائے؛
• کوئی انسان اسے روک دے، یا گفتگو سنبھال لے (جو بلٹ اِن ہارنس کو اس کی اگلی صاف ٹرن حد پر روک دیتا ہے — Claude Code کا رن، جس کی کوئی محفوظ حد نہیں، اس کے بجائے بند کر دیا جاتا ہے)؛
• خاموشی واچ ڈاگ بج جائے۔ حد تک کوئی آؤٹ پٹ نہ ہو تو سیشن silentRun ناکامی کے ساتھ ختم کر دیا جاتا ہے۔ ڈیفالٹ 15 منٹ ہے، جو زیادہ تر پڑھنے والے موڈز (ریویو اور پلان) میں 10 رہ جاتا ہے؛ ایجنٹ اسے 1 سے 240 منٹ کے درمیان اوور رائیڈ کر سکتا ہے۔ واچ ڈاگ اس وقت فعال ہوتا ہے جب چائلڈ پراسیس اپنا PID رپورٹ کرے، اس لیے یہ Claude Code CLI کو کور کرتا ہے — نہ کہ بلٹ اِن ہارنس کو، جو کچھ تخلیق نہیں کرتا؛
• لاگت کی حد لگے — مگر صرف خود مختار کمانڈز کے لیے۔

ڈوم-لوپ گارڈ خاتمہ کرنے والا نہیں: لگاتار تین یکساں ٹول کالز اور لوپ ایجنٹ کو اسٹیئر کرتا ہے کہ طریقہ بدلے۔

عام ٹرن پر لاگت کی کوئی حد نہیں

سیشن کے اندر لاگت گارڈ صرف /goal اور /loop کے لیے جڑا ہے؛ باقی ہر رن کوئی بجٹ ہی نہیں دیتا۔ ان کمانڈز کے لیے، ایک غیر حاضر سیگمنٹ ڈیفالٹ میں 500 سینٹ ($5.00) جلا سکتا ہے، ساتھ میں 80% پر نرم اسٹیئر جو ایجنٹ سے کہتا ہے کہ سخت توقف سے پہلے صفائی سے سمیٹ لے، اور سیگمنٹس میں 5000 سینٹ ($50.00) کا پائیدار گول بجٹ۔ کوئی واضح /goal --budget کبھی پورے سیگمنٹ سے تجاوز نہیں کرتا۔

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

رن کے دوران، چلتے ایجنٹ کو بھیجا گیا پیغام اسٹیئرنگ کے طور پر قطار میں لگ جاتا ہے اور اگلی ٹرن حد پر نکال لیا جاتا ہے، تاکہ آپ رن کو مارے بغیر اسے ہلکا سا ہدایت دے سکیں۔ اسٹیئرنگ، روکنا، ذیلی ایجنٹس اور تکمیل کنٹریکٹ بلٹ اِن ہارنس کی خصوصیات ہیں؛ Claude Code میں ان میں سے کوئی نہیں۔

رن کیسے ریکارڈ ہوتا ہے

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

• حالت موٹی ہے: pending، running، completed، error۔
• زندہ پن زیادہ باریک پڑھائی ہے: alive، productive، completed، blocked، empty، looping، failed، stalled، dead۔
• ایرر فیملی ناکامیوں کو مفید طریقے سے گروپ کرتی ہے: transientUpstream، sandboxInfrastructure، budgetExceeded، processLost، silentRun، unknown۔

completed کا مطلب “حوالے کیا گیا” نہیں

جب کوئی رن اس ڈیلیوریبل کے بغیر ختم ہو جائے جو اس کے موڈ نے لازم کیا تھا — پلان موڈ کا ایسا رن جس نے کبھی submit_plan نہیں بلایا، ایسا آرکیسٹریٹ رن جس نے کبھی تجویز نہیں دی — تو حالت completed ہی رہتی ہے، کیونکہ پراسیس صاف طریقے سے ختم ہوا تھا۔ دیانت دار اشارہ زندہ پن (empty)، ایرر فیملی (silentRun) اور ایک خلاصے پر سوار ہوتا ہے جو بالکل بتاتا ہے کہ کیا پیدا نہیں ہوا۔ وہ خلاصہ محفوظ ہے: فائنلائزیشن اسے ماڈل کی آخری بڑبڑاہٹ سے نہیں بدلے گی۔

یہ جان بوجھ کر ہے۔ حالت پلٹنے سے ٹکٹ اور پائپ لائن کی اسٹیٹ مشینیں حرکت میں آ جائیں گی جن کا گمشدہ آرٹیفیکٹ سے کوئی تعلق نہیں۔ اس کا یہ مطلب بھی ہے کہ صرف “status: completed” کبھی یہ نتیجہ نکالنے کے لیے کافی نہیں کہ رن کامیاب رہا — خلاصہ پڑھیں۔

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

بجٹ، بعد ازاں

بجٹ کا نفاذ ایک ردِ عمل ہے، گیٹ نہیں۔ جب رن مکمل ہوتا ہے تو جائزہ لینے والا ایجنٹ کے مہینے کے اب تک کے خرچ کا اس کی مؤثر حد سے موازنہ کرتا ہے (منسلک بجٹ پالیسی اگر ہو، ورنہ ایجنٹ کا اپنا ماہانہ عدد؛ صفر کا مطلب لامحدود)۔ نرم حد عبور کرنے پر انتباہی واقعہ درج ہوتا ہے؛ بجٹ ختم ہونے پر سخت واقعہ درج ہوتا ہے اور آرگ چارٹ پر ایجنٹ کی لائف سائیکل حالت paused ہو جاتی ہے۔ ڈسپیچ پھر بھی اس ایجنٹ سے کام قبول کرتا ہے۔ ایک BudgetThresholdCrossed پائپ لائن ٹرگر اسی ایونٹ سے فالو اپ کام شروع کر سکتا ہے۔

دوبارہ کوشش کا سلسلہ

ہر رن لاگ دوبارہ کوشش کا سلسلہ لے کر چل سکتا ہے — والد رن id، کوشش کا کاؤنٹر اور تسلسل کا خلاصہ۔ گفتگو کا رن ٹری کوشش کا نمبر اس وقت دکھاتا ہے جب وہ غیر صفر ہو۔ چیٹ سے “دوبارہ کوشش” ایک نیا ڈسپیچ ہے جس کا رن لاگ بالکل نیا ہوتا ہے۔

متعلقہ تصورات

• ایجنٹ ماڈل: اڈاپٹر کیا نافذ کر سکتا ہے اور کیا نہیں
• موڈز: ٹول سطح اور تکمیل کنٹریکٹ کہاں سے آتے ہیں
• گارڈریلز: وہ اثر کی قسم کی پالیسی جس سے ہر گیٹڈ کال گزرتی ہے
• سینڈ باکس اور سیکیورٹی: تنہائی کی پوری کہانی
• ملٹی پلیئر: اسٹیئرنگ، سنبھالنا اور خود مختاری ڈائل
• ڈومین ایونٹس: AgentRunCompleted کیا شروع کرتا ہے