ایجنٹ کے تجربات کی ڈیزائننگ

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

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

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

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

ایک سطر میں بنیادی خیال

ایجنٹک پراڈکٹ کے بیک وقت دو صارف ہوتے ہیں: ایک انسان جسے اس پر بھروسا کرنا ہے اور دوسرے ایجنٹس جنہیں اسے parse کرنا ہے۔ آپ کا کام ایسی سطح بنانا ہے جو کسی ایک کو نقصان پہنچائے بغیر دونوں کی خدمت کرے۔

آپ کیا بنائیں گے۔ آخر تک آپ پہلے بنائے گئے کسی ڈیجیٹل FTE کے لیے Agent Experience Brief کا مسودہ تیار کر چکے ہوں گے: انسان کے لیے بھروسے کی سطح، ایجنٹس کے لیے مشینی سطح، خودمختاری کی سیڑھی اور بازیابی کا منصوبہ۔ نیا کوڈ نہیں لکھنا؛ انسان اور ایجنٹ کی ٹیمیں میں عملی دستاویزات کی طرح ایجنٹ کو brief تیار کرنے کی ہدایت دیں گے۔ ضمیمہ C میں خالی سانچہ ہے۔ عملی مشق میں آپ اپنا پہلا MCP App بھی جاری کریں گے: refund کارکن کا فعال approval widget، جسے سرکاری create-mcp-app مہارت رکھنے والے کوڈنگ ایجنٹ، Claude Code یا OpenCode، کو ہدایت دے کر بنایا جائے گا۔ قائدین اور ڈیزائنرز کے لیے تصورات کے ساتھ قاری کا راستہ بھی ہے جس میں build کرنا ضروری نہیں۔

چار حصوں میں اٹھارہ تصورات ہیں: تبدیلی، انسانی سطح، مشینی سطح اور نئی مہارت۔ پڑھنے میں تقریباً دو گھنٹے، جامع brief میں ایک شام اور قاری کے راستے میں ایک مرکوز گھنٹہ لگتا ہے۔ عملی مثال کے بعد مشق حصہ 3 کو حقیقی کوڈ میں بدلتی ہے: کوڈنگ ایجنٹ کو ہدایت دے کر پہلا MCP App بنائیں اور جاری کریں۔ آخر کے ضمیمے MCP Apps کی ساخت اور MCP Apps بمقابلہ OpenAI Apps SDK کا سوال واضح کرتے ہیں۔

اصطلاحات نئی ہیں؟ سادہ زبان میں دس الفاظ

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

• ایجنٹ: ایسا سافٹ ویئر جو صرف سوال کا جواب دینے کے بجائے دیے گئے مقصد تک پہنچنے کے لیے خود کارروائیاں کرتا ہے۔
• کارکن / ڈیجیٹل FTE: حقیقی ملازمت کے لیے بنائے گئے ایجنٹ کا اس کتاب میں نام، جیسے سافٹ ویئر سے بنا کسٹمر سپورٹ ملازم۔
• پروٹوکول MCP: کھلا معیار جو ایجنٹس کو ٹولز تلاش اور call کرنے دیتا ہے، یعنی ایجنٹس اور سافٹ ویئر کے درمیان عالمی پلگ۔
• کنیکٹر / سرور MCP: وہی پلگ، یعنی سافٹ ویئر کا حصہ جو پراڈکٹ کی صلاحیتیں ایجنٹس کے استعمال کے لیے پیش کرتا ہے۔
• اصطلاح Human-in-the-loop: ایجنٹ کارروائی سے پہلے انسان کی منظوری کا انتظار کرتا ہے۔
• اصطلاح Human-on-the-loop: ایجنٹ خود کارروائی کرتا ہے جبکہ انسان نگرانی اور ضرورت پر مداخلت کر سکتا ہے۔
• اصطلاح Idempotent: دہرانا محفوظ؛ دو بار کرنے کا اثر ایک بار جیسا، تاکہ retry ہوئی refund دو مرتبہ نہ ہو۔
• ماخذ Provenance: معلومات کہاں سے آئیں، یعنی ایجنٹ نے حقیقت میں کون سی file، page یا source پڑھا۔
• محدود اور واپس لیا جانے والا credential: ایسی key جو صرف ضروری دروازے کھولتی اور کبھی بھی واپس لی جا سکتی ہے۔
• حوالگی Escalation: وہ لمحہ جب ایجنٹ رک کر کام انسان کو دیتا ہے کیونکہ اسے اکیلے فیصلہ نہیں کرنا چاہیے۔

📚 تدریسی معاونت

مکمل سلائیڈ شو کھولیں

مکمل پیشکش دیکھیں — ایجنٹ کے تجربات کی ڈیزائننگ

---

حصہ 1 · تبدیلی

سادہ الفاظ میں: جب سافٹ ویئر خود عمل کرنے لگے تو کیا بدلتا ہے، اور ڈیزائن کو کیوں بدلنا پڑتا ہے۔

تصور 1 · تیسرا طریقہ: اب آپ «کیسے» کی ڈیزائننگ نہیں کرتے

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

تیسرا طریقہ مقدار نہیں بلکہ نوعیت میں مختلف ہے۔ آپ نتیجہ بتاتے ہیں اور ایجنٹ مراحل چنتا ہے۔ «کیسے» کا بوجھ انسان سے مشین کو منتقل ہو جاتا ہے۔ اسی لیے ایجنٹک سافٹ ویئر رکاوٹوں کا راستہ چلنے کے بجائے مقصد تک فوراً پہنچنے جیسا محسوس ہوتا ہے۔

شکل 1: اختیار کا مرکز الٹ جاتا ہے۔ مشین کے «کیسے» سنبھالتے ہی ڈیزائنر کا کام ارادے، بھروسے اور بازیابی کی طرف منتقل ہوتا ہے۔

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

تصور 2 · دو سامعین، ایک نظام

یہ وہ خیال ہے جو اکثر ٹیمیں بھول جاتی ہیں، اور اسے ابتدا میں رکھنا ضروری ہے کیونکہ حصہ 3 اسی پر قائم ہے۔

آپ کی ایجنٹک پراڈکٹ بیک وقت دو طرح کے صارفین استعمال کرتے ہیں۔ انسان کو سمجھنا اور بھروسا کرنا ہے۔ دوسرے ایجنٹس service call کرتے، data پڑھتے اور انسان کی طرف سے عمل کرتے ہیں۔ وہ بھی صارف ہیں، بس pixels کے بجائے structure پڑھتے ہیں۔ آگے آنے والے refund کارکن کو دیکھیے: انسان ایک سادہ سطر دیکھتا ہے، «$38 refund ہوا، undo؟»، جبکہ payment provider کا ایجنٹ typed، idempotent tool call دیکھتا ہے۔ ایک کارروائی، دو سطحیں، دونوں درست ہونی چاہییں۔

شکل 2: دو سامعین، ایک نظام۔ بائیں سطح بھروسے کے لیے، دائیں parsing کے لیے۔ اچھی پراڈکٹ دونوں کو جان بوجھ کر ڈیزائن کرتی ہے۔

صنعت ایک مبہم مخفف AX کے دو معنی لیتی ہے۔ اسے ایک بار واضح کر لیں:

اصطلاح	پیش کرنے والا	معنی	اس کورس میں نام
Agentic Experience	John Maeda	ایجنٹ کو کام سونپنے کا انسانی تجربہ	انسانی سطح (حصہ 2)
Agent Experience	Matt Biilmann (Netlify)	پراڈکٹ کے صارف کے طور پر ایجنٹ کا تجربہ	مشینی سطح (حصہ 3)

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

تصور 3 · انٹرفیس غائب نہیں ہوتا، جگہ بدلتا ہے

آپ سنیں گے کہ ایجنٹس انٹرفیس ڈیزائن کا خاتمہ ہیں۔ صارف اسکرین چھوڑ دیں گے؛ ایجنٹس browse، click اور decide کریں گے؛ بنایا ہوا UI بے کار ہوگا۔ اس دعوے کو سنجیدہ لینا چاہیے کیونکہ کہنے والوں نے میدان بنانے میں حصہ لیا ہے۔

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

• ترتیبات کی سطح: بدلتی ترجیحات ایجنٹ کو کیسے سکھائیں؟
• نگرانی کی سطح: ذہنی بوجھ کے بغیر کام کیسے دیکھیں؟
• مداخلت کی سطح: غلطی پر بیچ میں آ کر کیسے درست کریں؟

درست موقف درمیان میں ہے۔ انٹرفیس غائب نہیں ہوتا؛ اس کا مرکز بدلتا ہے: task کو widget میں بدلنے سے ارادے کے نظام کو شکل دینے تک۔ آپ اس تعلق کی بنیاد ڈیزائن کرتے ہیں: ایجنٹ کیا کر سکتا ہے، کام کیسے دکھاتا ہے اور انسان اختیار کیسے واپس لیتا ہے۔

---

حصہ 2 · انسانی سطح: بھروسے کے لیے ڈیزائن

سادہ الفاظ میں: پراڈکٹ کا انسان کو دکھائی دینے والا حصہ اس طرح بنائیں کہ وہ ایجنٹ پر بھروسا، اسے سمت اور غلطی کی اصلاح کر سکے۔

تصور 4 · بھروسا کمایا جاتا ہے، فرض نہیں کیا جاتا

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

آپ بھروسا براہِ راست ڈیزائن نہیں کرتے۔ اس کے اجزا بناتے ہیں:

بھروسا = وقت کے ساتھ دکھائی reliability × قابلِ جانچ transparency × محسوس control × undo ہونے والی غلطیاں۔

یہ جمع نہیں بلکہ حاصل ضرب ہے: ایک جزو صفر تو سب صفر۔ قابلِ اعتماد مگر black box ایجنٹ، شفاف مگر بے قابو ایجنٹ، یا قابلِ ہدایت مگر ناقابلِ undo ایجنٹ بھروسا نہیں کماتا۔ پہلا قدم سب سے دیانت دار ہے: ایجنٹ کو غیر یقینی دکھانے دیں۔ شک چھپا کر confidently غلط ایجنٹ اس سے زیادہ بھروسا توڑتا ہے جو کہے، «مجھے اس حصے کا یقین نہیں، اسے دیکھ لیں۔»

الٹی ناکامی حد سے زیادہ بھروسا ہے۔ سو مرتبہ درست ایجنٹ کے بعد انسان جانچ اور drift دیکھنا چھوڑ دیتا ہے۔ یہ automation complacency ہے۔ uncertainty دکھاتے رہیں، high-stakes کام کو full autonomy نہ دیں اور fleet سطح پر drift دکھائیں۔ ہدف calibrated trust ہے، زیادہ سے زیادہ بھروسا نہیں۔

تصور 5 · پہلا رابطہ: آغاز، ابتدائی بھروسا اور سب کے لیے رسائی

وقت کے ساتھ دکھائی دینے والا بھروسا پہلے دن موجود نہیں۔ ہر capability jump، مثلاً جواب دینے والے chatbot سے عمل کرنے والے agent تک، توقعات دوبارہ طے کرنے کا تقاضا کرتا ہے۔

تین اقدامات پہلا رابطہ دیانت دار بناتے ہیں:

• ہر تبدیلی پر توقعات دوبارہ طے کریں۔ سطح کو عمل کی طاقت ملے تو صاف کہیں: «اب میں صرف بتا نہیں سکتا، آپ کے لیے یہ کر بھی سکتا ہوں۔ اس کا مطلب یہ ہے۔»
• خطرہ کم کر کے بھروسا حاصل کریں۔ کم ترین autonomy، عمل سے پہلے plan اور چھوٹا reversible پہلا task۔ پہلے دن بھروسا غلطی سستی بنا کر ملتا ہے، صفر غلطی کے وعدے سے نہیں۔
• نیا ہونے کے بارے میں سچ کہیں۔ «میں نے آپ کے ساتھ یہ پہلے نہیں کیا، اس لیے ابتدا میں زیادہ بار پوچھوں گا۔» یہی احتیاط بعد میں autonomy بڑھاتی ہے۔

ایک بنیادی شرط: سطح سب کے لیے کام کرے۔ Agents accessibility ختم نہیں کرتے؛ سادہ زبان میں مقصد dense UI سے آسان ہو سکتا ہے۔ مگر plan، confidence، undo اور انسان تک راستہ sight، mouse یا first language کے بغیر کام کرے۔ حصہ 3 کی structured، labelled، semantic مشینی سطح وہی structure ہے جو assistive technology پڑھتی ہے۔

معیار WCAG 2.2 کو بنیاد مان کر قابلِ جانچ شرائط لکھیں:

• حالت اور پیش رفت screen reader سنائے، صرف حرکت نہیں۔
• منصوبہ، undo اور انسان تک راستہ keyboard سے بغیر گہری navigation ملے۔
• اعتماد اور غیر یقینی صرف colour سے نہ ہوں۔
• انسان طویل کام pause، resume یا cancel کر سکے۔
• اطلاعات کی مقدار اور شدت بدلی جا سکے۔
• ہر وضاحت کا سادہ زبان والا نسخہ ہو۔

انہیں تصور 7 کی تہوں سے جوڑیں: پہلی تہہ کا نتیجہ screen reader کو سنائی دے؛ تیسری تہہ کا confidence رنگ کے بغیر؛ چوتھی تہہ کا evidence keyboard سے۔ مخصوص تہہ یا control کے بغیر شرط محض نیت ہے۔

تصور 6 · بوجھ تقسیم کریں اور دکھائیں کہ کون کیا اٹھا رہا ہے

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

غلطی بوجھ خاموشی سے منتقل کرنا ہے۔ غیر واضح تقسیم ایجنٹک دلدل بناتی ہے: انسان نہیں جانتا ایجنٹ نے کیا کیا اور کیا باقی ہے، اس لیے دوبارہ جانچتا ہے اور وقت کی بچت ختم ہو جاتی ہے۔

اصول: کام کی تقسیم واضح اور قابلِ تبدیلی ہو۔ انسان دیکھ سکے «یہ میں نے، یہ آپ نے، یہ آپ کے انتظار میں ہے» اور حد بدل سکے۔ یہ انسان اور ایجنٹ کی ٹیمیں کے roster اور role cards کی ظاہری سطح ہے۔

مستعار اصطلاحات، ایک سطر میں

کورس انسان اور ایجنٹ کی ٹیمیں میں کارکن کا role card ملازمت کی ایک صفحے کی spec ہے: کام، inputs، حدود اور output کی جانچ؛ roster ٹیم کے کارکنان اور ان کے مقاصد کی فہرست ہے۔ یہ کورس انہی دستاویزات کی سطح ڈیزائن کرتا ہے۔

تصور 7 · بتدریج شفافیت: reasoning نظر آئے، بوجھ نہ بنے

شفافیت میں جال ہے۔ کچھ نہ دکھائیں تو black box؛ سب کچھ دکھائیں تو ناقابلِ استعمال شور۔ دونوں بھروسا توڑتے ہیں۔ بتدریج شفافیت پہلے نتیجہ دکھاتی اور ضرورت کے مطابق گہرائی دیتی ہے۔

شکل 3: بتدریج شفافیت۔ پہلے ایک دیانت دار سطر؛ ہر گہرائی ایک tap نیچے، قاری پر مسلط نہیں۔

چار تہیں:

1. نتیجہ، ایک سادہ سطر: ایجنٹ نے کیا کیا۔
2. منصوبہ: ترتیب وار مراحل، کام کی شکل جانچنے کے لیے۔
3. وجہ: دلیل اور دیانت دار اعتماد کا اشارہ۔ جعلی فیصد نہیں بلکہ high / low / unsure۔ «73%» جھوٹی calibration، «unsure» سچ۔
4. ثبوت: sources، tool calls اور full trace؛ audit اور debugging کے لیے۔

چھوٹی سطحیں بڑا کام کرتی ہیں: ماخذ کا نشان («آپ کی 3 files پر مبنی»)، کمزور حصے پر غیر یقینی نشان اور trace کا link۔ مقصد model mathematics نہیں بلکہ انسان کا سوال ہے: کیا بھروسا کروں، اور نہیں تو پہلے کہاں دیکھوں؟

تصور 8 · خود مختاری کا پیمانہ: بڑھتی ہوئی اجازت

خود مختاری «بند» سے «سب کچھ» کا switch نہیں۔ یہ پیمانہ ہے جسے انسان، آپ نہیں، تھامتا ہے۔ کم سطح سے آغاز کریں اور ایجنٹ کے خود کو ثابت کرنے پر اسے بڑھنے دیں، جیسے manager بھروسا بننے کے بعد نئے ساتھی کو زیادہ آزادی دیتا ہے۔

شکل 4: خود مختاری کا پیمانہ۔ انسان عمل کے اندر ہو تو ایجنٹ رکتا ہے؛ انسان عمل پر نگران ہو تو ایجنٹ کام کرتا اور انسان نگرانی کرتا ہے۔ Reliability پیمانہ بڑھاتی ہے۔

دو تصورات حفاظت دیتے ہیں۔ Human-in-the-loop میں ایجنٹ action سے پہلے approval کا منتظر رہتا ہے؛ human-on-the-loop میں وہ عمل کرتا ہے اور انسان مداخلت کر سکتا ہے۔ کم خطرے، قابلِ واپسی اور ثابت شدہ کام کو on-the-loop مقام ملتا ہے؛ بلند خطرے یا ناقابلِ واپسی کام کو reliability کے باوجود in-the-loop رہنا چاہیے۔ دوسرا تصور ہر کام کے لیے رضامندی کے ساتھ محفوظ defaults ہے: نیا ایجنٹ «تجویز» سے شروع ہو اور ہر درجہ انسان شعوری طور پر چنے۔

یہ Nervous System کے approval gates اور Digital FTE کے authority model کا سامنے والا حصہ ہے۔ پس منظر میں approval durable audited event ہے؛ سامنے انسان اسے پیمانے کی صورت محسوس کرتا ہے۔

تصور 9 · ارادے کا پیش منظر اور منصوبہ دیکھنے کی عادت

سب سے سستی غلطی وہ ہے جو ابھی ہوئی نہیں۔ عمل سے پہلے، خاص طور پر ناقابلِ واپسی action سے پہلے، منصوبہ دکھائیں اور اسے بدلنے دیں: «میں 1، 2، 3 کرنے والا ہوں۔ کچھ بدلنا ہے؟» یہ ارادے کا پیش منظر بعد کی وضاحت سے کہیں زیادہ پچھتاوا روکتا ہے۔

Cowork کا plan review یہی pattern ہے؛ یہاں اسے ship ہونے والے product میں بنائیں:

• پیش منظر خطرے کے ساتھ بڑھے۔ ایک internal draft پر خاموش «بھیج رہا ہوں، undo؟»؛ 500 emails یا money پر مکمل plan اور واضح confirm۔
• منصوبہ دورانِ عمل قابلِ ترمیم ہو، صرف منظور یا رد ہونے کے قابل نہیں۔ Accept/reject دیوار ہے؛ «ہاں، مگر step 2 چھوڑ دیں» شراکت ہے۔

تصور 10 · غیر ہم وقت کام کی ڈیزائننگ: کام کی نئی لے

پرانا command software ہم وقت تھا۔ ایجنٹک کام میں آپ ارادہ طے کرتے، منقطع ہوتے اور progress یا مکمل کام پر واپس آتے ہیں۔ تعاون کی اس صورت کو اپنی design چاہیے۔

شکل 5: غیر ہم وقت چکر۔ انسان ارادے اور جائزے پر حاضر ہے؛ درمیان میں ایجنٹ اکیلا، اور صرف حقیقی فیصلے پر خلل ڈالتا ہے۔

چار سطحیں:

• ارادہ حاصل کرنا اتنا صاف ہو کہ کام آپ کے بغیر چل سکے۔
• ایک نظر میں progress: تین second کا status، logs کی دیوار نہیں۔
• اشارہ دیں، ہر بات کی اطلاع نہیں۔ صرف حقیقی فیصلے پر خلل۔ ہر قدم پر ping محتاج ساتھی ہے۔ interruption اپنی جگہ کمائے۔
• واپسی کا review-and-refine surface جہاں مکمل کام دیکھ، درست اور نئی سمت میں بھیجا جا سکے۔

انتظار کا محسوس ہونے والا تجربہ بھی design کریں۔ ایجنٹ سست اور مہنگا ہو سکتا ہے۔ خاموشی خراب لگتی ہے، مصروف نہیں۔ موجودہ قدم کی سچی progress، آغاز میں اندازاً وقت، مہنگے runs کی cost/budget اور کام روکے بغیر check-in دکھائیں۔ Latency اور cost چھپی backend details نہیں بلکہ experience ہیں۔

تصور 11 · اصلاح اور ازالہ: غلط دن کے لیے ڈیزائن

ایجنٹ غلط action کرے گا۔ حقیقی کام میں probabilistic system کبھی نہ کبھی ناکام ہوگا۔ Recoverability آخر میں لگا error state نہیں، ابتدا سے بنیادی سطح ہے۔

چار moves دھوکے جیسے احساس کو معمولی رکاوٹ بناتے ہیں:

1. Undo کام دینے جتنا آسان ہو۔ یہ بھروسا بنانے کا سب سے مضبوط ذریعہ ہے؛ لوگ قابلِ واپسی ایجنٹ کو زیادہ خود مختاری دیتے ہیں۔
2. سیدھی معذرت اور سادہ بیان، حیلہ یا user پر الزام نہیں۔
3. اصلاحی action اور اگلا قدم: «transfer واپس، review flag۔»
4. انسان تک نمایاں راستہ، ہمیشہ؛ جواب دہی اور تناؤ کم کرنے کے لیے۔

دو metrics: escalation frequency کی عملی ابتدائی حد 5–15%؛ کم ہو تو ایجنٹ اندازے لگا رہا، زیادہ ہو تو حد سے زیادہ محتاط۔ Recovery success 90% سے اوپر ہونی چاہیے۔ انہیں domain کے مطابق calibrate کریں، قانون نہ سمجھیں۔ یہ ops بھی ہے اور UX بھی۔

تصور 12 · کئی ایجنٹس کی نگرانی: ایک سے پوری workforce

دس Workers ہوں تو کوئی دس plans، approvals یا traces نہیں دیکھ سکتا۔ Design monitoring سے exceptions کی triage بن جاتی ہے۔

شکل 6: fleet view۔ سطح انسانی توجہ صرف ان چند Workers پر خرچ کرتی ہے جنہیں انسان درکار ہے؛ باقی log میں رہتے ہیں۔

تین سطحیں:

• Fleet view: ایک نظر میں running، blocked، waiting؛ operations board، دس chats نہیں۔
• Attention triage: $900 dispute اوپر، 200 صاف refunds log میں۔ Surfaced:silent ratio توجہ کا بجٹ ہے۔
• Drift، صرف distress نہیں: «escalation rate دگنی» نمایاں failure سے پہلے۔ سطح انسان کے لیے over-trust پکڑتی ہے۔

انحراف یعنی drift پر response لازم ہو۔ Fleet-level circuit breaker Worker کی اپنی baseline کے multiple پر autonomy گھٹائے یا pause کرکے review اٹھائے۔ Threshold جادوئی عدد نہیں، calibrate ہوتا ہے۔ Default یہ ہے کہ پھسلتے Worker کو کم خود مختاری ملے۔

یہ Human-Agent Teams اور Paperclip roster/control plane کا سامنے والا حصہ ہے: وہ team define کرتا ہے، یہ وہ room design کرتا ہے جہاں انسان team دیکھتا اور طے کرتا ہے کہ کیا نہیں دیکھنا۔

---

حصہ 3 · مشینی سطح: ایجنٹس کو users سمجھ کر ڈیزائن

سادہ الفاظ میں: product کا وہ حصہ design کریں جو دوسرے agents استعمال کرتے ہیں، تاکہ پہلی کوشش میں درست استعمال ہو۔

تصور 13 · Agent Experience (AX): product کے robot users

اب وہ نصف جسے teams اکثر design نہیں کرتیں۔ Product کو agents بھی استعمال کرتے ہیں: users کی طرف سے عمل کرنے والے agents اور اپنی workforce کے Workers۔ وہ layout نہیں، structure پڑھتے ہیں۔ Hostile structure میں انسان کا agent خاموشی سے fail ہوتا ہے اور انسان آپ کو ذمہ دار سمجھتا ہے۔

شکل 7: مشینی سطح۔ چار سوال طے کرتے ہیں کہ agent product استعمال کر سکتا ہے؛ ہر ایک design decision ہے۔

• Access: scoped، revocable credential سے agent کس کی authority ثابت کرے؟ یہ AI Identity کا مسئلہ ہے۔
• Context: model product کا معنی سمجھے؟ صاف names، سچی descriptions، پڑھنے کے قابل semantics۔
• Tools: capabilities machine-readable، typed اور discoverable ہیں یا scrape ہونے والی UI میں چھپی ہیں؟
• Orchestration: predictable contracts، idempotent actions اور معقول limits کے ساتھ safe chaining؟

اچھی طرح design کیا connector یا MCP server اچھا AX ہے۔ Skills & Connectors اور Connector-Native Apps machine-reader interface design ہیں۔ SKILL.md اور typed MCP tool robot-user UX ہیں۔

قابلِ بھروسا مشینی سطح کی عادتیں:

• Tool action کا نام صاف ہو: refund_order، process نہیں۔
• Schemas محدود، typed اور validated ہوں۔
• Side effects/danger ظاہر کریں، dangerous tools confirmation یا policy check مانگیں۔
• Structured actionable errors: code، next step، retryable، retry_after، fallback۔
• جہاں ممکن ہو actions idempotent ہوں، retry سے double-charge/send نہ ہو۔
• Provenance اور permission: data source، authority، revocation۔
• Docs agent کے لیے: examples، limits، failure modes، retry۔
• Contract test، صرف screen نہیں۔

سال 2026 تک MCP tool discovery/call، resource read اور access authentication standardize کرتا ہے۔ MCP Apps UI metadata دیتا ہے: tool ui:// interface کو _meta.ui.resourceUri کے ذریعے جوڑ کر widget لا سکتا ہے۔ مگر orchestration، governance اور طویل کام کی state آپ کی ذمہ داری ہیں۔ Protocol agent کو دروازے کے اندر لاتا ہے؛ اندر authority اور supervision کی design آپ کی ہے۔

اچھے AX کے دو حصے ہیں: protocol کی پابندی، پھر omitted policy، server allowlists، consent gates، spend limits اور audited logs۔ MCP Apps میں sandboxing/controls host کا کام ہیں۔ Wire format عام چیز ہے؛ trust policy آپ کی قدر۔

تصور 14 · Generative UI: interfaces واپس کرنے والے agents

دو سامعین ایک سطح پر ملتے ہیں۔ Tool تمام hosts کو معمول کا text اور Apps hosts کو interactive ui:// resource دے سکتا ہے جس کا نام _meta.ui.resourceUri میں ہو۔ Host اسے گفتگو کے sandbox iframe میں render کرتا ہے۔

شکل 8: Tool interface declare کرتا، host گفتگو کے sandbox میں render کرتا اور ایک audited channel واپس جاتا ہے؛ text ہر جگہ fallback ہے۔

تخلیقی Generative UI کوئی random page یا arbitrary injected code نہیں بلکہ tool call کے ساتھ جڑا task interface ہے۔ Tool fallback text اور interface declare کرتا ہے؛ قابل host widget دکھاتا ہے، ورنہ text فیصلہ دیتا ہے۔ اصول «data جیسا محفوظ، code جیسا اظہار» ہے: sandboxed content، کھلا client code نہیں۔

ایک capability کے دو surfaces ہیں: agents کے لیے MCP contract اور humans کے لیے widget۔ ایک call approval card، dashboard، map یا chart بھی دے سکتا ہے اور parseable tool بھی۔

تین سطروں میں مقام

یہاں MCP مشینی سطح ہے۔ MCP Apps interactive انسانی سطح ہے۔ دونوں مل کر ایک tool کو humans اور agents دونوں کے لیے بناتے ہیں۔

MCP Apps نومبر 2025 میں تجویز اور جولائی 2026 میں finalized ہونے والی پہلی official UI extension ہے، MCP-UI، OpenAI اور Anthropic کا مشترک کام۔ Claude، Desktop، VS Code، Goose اور Postman اسے render کرتے ہیں؛ OpenAI Apps SDK اسی بنیاد پر ChatGPT apps بناتا ہے۔ جنوری 2026 کے Claude launch میں Asana، Slack، Figma، Canva، Box اور Hex کے interactive connectors production میں تھے۔ ایک widget، کئی hosts، مگر features مختلف ہو سکتے ہیں۔

چار experience properties:

• Context برقرار رہتا ہے: app گفتگو میں، tab switch نہیں۔
• دونوں سمت رابطہ: widget server tools call کرتا، host results push کرتا؛ API/login/state protocol کے ذریعے۔
• رضامندی سے host powers: outcome host کی connected services سے route ہوتا ہے۔
• ساخت ہی سے محفوظ: sandbox host page/cookies/storage روکتا، messages audited رہتے ہیں۔

یہ widget complex data، بہت سے options والی configuration، rich media، real-time monitoring اور multi-step workflow کے لیے ہے۔ Plain text کافی ہو تو text استعمال کریں۔ Widget بھی nudge کی طرح اپنی جگہ کمائے۔

منتقلی کی آسانی یعنی portability کے لیے progressive enhancement اپنائیں۔ پہلے open standard؛ payment/store extras feature-detect کریں اور باقی hosts پر gracefully degrade۔ Vendor-only surface پھنساتی ہے۔

یوں chat/app کی دیوار ٹوٹتی ہے۔ Agent task کے لیے درست form/chart/map compose کرتا ہے جبکہ styling/security/components آپ کے control میں رہتے ہیں۔ اب fixed screens نہیں، agent کے بولنے کے قابل component vocabulary design ہوتی ہے۔

ابھرتی اور بدلتی technology

یہ MCP Apps جولائی 2026 spec میں finalized ہے مگر active development جاری ہے۔ Pattern کی شکل کے لیے design کریں: data کی صورت interface، ایسا sandbox جس سے نکل نہ سکے۔ Build سے پہلے modelcontextprotocol.io/extensions/apps verify کریں۔ Appendix A anatomy اور Lab build دیتا ہے۔

---

حصہ 4 · نئی craft

سادہ الفاظ میں: job کی نئی skills، safety، measurement اور ہر Worker کی ایک صفحے کی document۔

تصور 15 · نئے design objects اور choreographer کا کام

اگر screens نہ ہوں تو کیا draw کریں؟ نئے بنیادی objects:

• Policy surfaces: permissions، spend ceilings اور ethical boundaries؛ rules اور انہیں set کرنے کے controls۔
• Confidence conveyors: تصورات 7/11 کے provenance chips، uncertainty markers اور clean rollbacks؛ system اپنے یقین کا سچ کیسے بتائے۔
• System temperament: agent کتنا patient یا proactive، کتنی بار اور کیسے بولے؛ brainstorm میں eager، money پر cautious۔

کردار screen-crafter سے choreographer ہے: humans اور agents کی مشترک حرکت، information architecture، conversation، operations اور control کب رکھنا یا ہٹانا ہے۔ Choosing Agentic Architectures کا backstage pattern، single agent/planner/multi-agent، سامنے human supervision طے کرتا ہے۔ Architecture اور experience ایک ہی decision کے دو views ہیں۔

تصور 16 · سطح safety control ہے

سطح بھروسا بناتی اور بچاتی ہے۔ دنیا میں عمل کرنے والے agent کا attack surface ہے اور defense کا بڑا حصہ design ہے۔ مشترک فہرست OWASP Top 10 for LLM Applications ہے۔

شکل 9: ہر OWASP risk کے ساتھ course کا design response؛ safety تجربے کی feature ہے، backend chore نہیں۔

• Prompt injection LLM01: web/document میں چھپی instruction۔ Provenance پڑھا گیا source دکھاتا اور intent preview اہم action کو check کرتا ہے۔
• Excessive agency LLM06: کم ترین authority default، high stakes میں in-loop، capabilities شعوری طور پر دی جائیں۔
• Misinformation/over-trust LLM09: visible uncertainty اور provenance shaky claim کو sure fact کی طرح نہیں دکھاتے۔
• Unbounded consumption LLM10: runaway loop/denial-of-wallet کے لیے visible cost اور spend limits۔
• Sensitive-data disclosure LLM02: scoped revocable access اور visible، واپس لی جا سکنے والی consent۔

دو rules۔ سطح safety control ہے، صرف display نہیں؛ clutter کے نام پر provenance، uncertainty، preview یا cost ہٹانا protection ہٹانا ہے۔ ہر system کو governance surface چاہیے: capability، permissions، incident، audit اور سب سے اہم، ایک move میں agent کو pause/kill کرنے والا owner۔

Governance surface	Design کا سوال
Capability approval	Worker کی capability کون بڑھا سکتا ہے؟
Permission review	Tool scopes/data access کون approve کرتا ہے؟
Incident review	Failure/postmortem کا owner کون ہے؟
Audit log	Actions، plans، calls، approvals کون دیکھتا ہے؟
Kill switch	ایک move میں pause/disable/rollback کون کر سکتا ہے؟
Drift review	بڑھتی escalation یا گرتی recovery کی تحقیق کون کرے؟

یہ NIST AI Risk Management Framework ان organizational controls کو Govern، Map، Measure، Manage کہتا ہے؛ Human-Agent Teams اور Workforce with Paperclip انہیں عمل میں لاتے ہیں۔ سطح پر control قابلِ رسائی بنائیں، policy ایجاد نہ کریں۔

تصور 17 · Experience کی پیمائش

خوب صورت سطح ناکام ہو سکتی ہے۔ Eval-Driven Development unit/tool/trace/safety/regression evals سے ناپتا ہے کہ Worker output درست ہے یا نہیں۔ Experience metrics رشتہ ناپتے ہیں: انسان delegate، trust، steer اور recover کر سکے۔ درست Worker کی سطح پھر بھی ناقابلِ نگرانی ہو سکتی ہے۔

Metric	کیا بتاتا ہے
Plan-acceptance rate	انسان سمجھ کر approve کرتا یا blind rubber-stamp/reject؟
Intervention rate	انسان کتنی بار آیا؟ گرتا trend trust دکھاتا ہے۔
Recovery success	Failure/escalation کے بعد اچھا انجام؟
Over- vs under-trust	غلط accept یا درست reject؟
Notification precision	کتنے interruptions واقعی قابل تھے؟
Time saved vs attention spent	کل burden کم ہوا یا صرف جگہ بدلی؟

Trends دیکھیں، snapshots نہیں؛ پچھلے month کے بغیر 12% بے معنی ہے۔ Microsoft HAX Playbook کی طرح launch سے پہلے failures rehearse کریں اور recovery design کریں۔ سب سے اہم time saved versus attention spent ہے؛ منفی ہو تو surface ناکام ہے۔

آغاز یعنی launch سے پہلے tests:

1. Plan-review test: action سے پہلے plan پڑھا، سمجھا اور درست کیا جا سکے۔
2. Over-trust test: باریک غلط output پر uncertainty blind approval روکے۔
3. Recovery test: reversible غلطی اور clean undo کا وقت۔
4. Interruption test: مفید nudges ناپیں۔
5. Accessibility pass: صرف keyboard/screen reader سے plan، progress، undo، escalation۔
6. Machine-surface contract test: wrong type reject، danger gated، error structured، retry idempotent۔

ان tests کا pass ہونا correctness کا ثبوت نہیں، وہ Eval-Driven Development کا کام ہے؛ یہ اس بات کا ثبوت ہے کہ غلطی پر experience قائم رہتا ہے۔

تصور 18 · Anti-patterns اور آخری design brief

Anti-pattern	کیسا دکھتا ہے	ٹوٹا تصور
Black box	reasoning کے بغیر action	7 · progressive transparency
Agentic sludge	سب کچھ دوبارہ check، وقت کی بچت نہیں	6 · visible division
Over-eager agent	پہلے دن high autonomy	8 · autonomy dial
Over-trusted agent	unchecked work پر high autonomy	4 · calibrated trust
Notification spam	ہر step پر ping	10 · nudge، اطلاع نہیں
Alarm-fatigued console	ہر Worker ping، انسان ignore	12 · attention triage
False confidence	shaky guess کو sure fact	4 · visible uncertainty
Trap door	undo نہیں	11 · repair/redress
Confused deputy	user اور injection الگ نہیں	16 · safety surface
Unmeasured surface	خوب صورت، مدد کی پیمائش نہیں	17 · measurement
Mystery-meat API	agent parse نہ کر سکے	13 · Agent Experience

حاصل ہونے والی دستاویز: پہلے Digital FTE کا Agent Experience Brief، گیارہ decisions:

1. دو سامعین: human اور agent users۔
2. پہلا رابطہ: onboarding، capability reset، sight/mouse کے بغیر۔
3. Trust surface: default اور نیچے تین layers۔
4. Load map: human/Worker division اور visible line۔
5. Autonomy ladder: پانچ stops، ہمیشہ in-loop actions۔
6. Async plan: intent، progress، wait، nudges۔
7. Recovery plan: undo، escalation، دو health metrics۔
8. At scale: fleet، attention، drift۔
9. Machine surface: connector/MCP tools، AX pillars۔
10. Safety surface: agent threats اور defenses۔
11. Scorecard: experience metrics اور correctness boundary۔

یہ artifact Worker experience کے لیے Human-Agent Teams operating docs جیسا ہے۔ Spec-Driven Development میں experience layer کی spec: non-deterministic Worker کی deterministic، reviewable سطح۔ Appendix C blank version دیتا ہے۔

---

Worked Example: Support Worker کی دو سطحیں

Digital FTE course کا customer-support FTE، دونوں surfaces۔

انسانی سطح۔ Console میں ہر ticket ایک line: «Refunded order #4021، $38، confidence: high۔» Layer 1۔ Tap کرنے پر plan: order، policy، refund، email۔ پھر why/policy clause۔ $38 حد میں ہے، stop 3 act within limits۔ $900 chargeback حد سے باہر، stop 2 in-loop۔ ہر refund کے لیے 24-hour undo۔ Lead on the loop رہ کر ایک نظر ڈالتا ہے۔ دس Workers میں fleet $900 dispute اوپر لاتا اور صاف refunds log میں رکھتا ہے۔

مشینی سطح۔ Company orchestrator اسی Worker کو call کرتا اور payment provider کے لیے یہ خود agent ہے۔ Typed hard-limit MCP tool (tools)، scoped revocable merchant credential (access)، valid refund کی صاف description (context)، idempotent refund (orchestration)۔ انسانی سطح پر یہ سب چھپا ہے مگر system ان کے بغیر collapse ہو جاتا ہے۔

ایک Worker۔ دو سامعین۔ دو شعوری طور پر design کی گئی سطحیں۔

خطرہ بڑھائیں۔ Refund کے بجائے ناقابلِ واپسی vendor payments۔ Undo safety net نہیں، design recovery سے prevention کی طرف جاتی ہے: لازمی detailed intent preview۔ Autonomy «act within limits» سے اوپر نہیں؛ کم limit، بڑی payment ہمیشہ in-loop۔ Confidence bar بڑھتا ہے۔ Provenance اور دوسرا human approver لازم۔ Governance: kill switch، full audit، threshold payments کا named owner۔ یہی patterns زیادہ سخت ہو جاتے ہیں کیونکہ غلطی مہنگی ہے۔ Recovery/prevention dial payroll، clinical triage، grading اور regulated/irreversible domains کے لیے ہے۔

---

عملی مشق: اپنی پہلی MCP App بنائیں

حصہ 3 کی مشینی سطح کو اب ایک حقیقی MCP App بنائیں: text کی دیوار کے بجائے working interactive widget جو Claude یا کسی supporting host کے اندر render ہو۔

کتاب کے طریقے کے مطابق coding agent کو ہدایت دے کر build کریں۔ Official guide کے مطابق AI coding agent اور MCP Apps skill سب سے تیز راستہ ہیں۔ Skill architecture/best practices دیتی ہے، agent typing کرتا ہے، اور آپ spec اور judgment دیتے ہیں۔

ضروریات۔ Node.js 18+، terminal، اور Skills-supporting agent: Claude Code، OpenCode، Codex، Cursor، Gemini CLI یا Goose۔ Claude custom-connector test کے لیے paid plan؛ Step 3 کا local host مفت ہے۔

Step 1 · create-mcp-app skill install کریں

Skills & Connectors کے مطابق skill instructions/examples کا folder ہے۔ Official create-mcp-app architecture اور pitfalls سکھاتی ہے۔

Claude Code plugin:

/plugin marketplace add modelcontextprotocol/ext-apps
/plugin install mcp-apps@modelcontextprotocol-ext-apps

دوسرے agents:

npx skills add modelcontextprotocol/ext-apps

دستی طریقہ: github.com/modelcontextprotocol/ext-apps clone کریں اور plugins/mcp-apps/skills/create-mcp-app کو ~/.claude/skills/، ~/.codex/skills/ یا ~/.cursor/skills/ میں copy کریں۔

پھر verify کریں:

What skills do you have access to?

فہرست میں create-mcp-app ہو تو agent MCP Apps بنانا جانتا ہے۔

Step 2 · دس minute کا loop: scaffold، build، serve

اس agent کو ایک line دیں:

Create an MCP App that displays a color picker

یہ agent skill load کرکے MCP server، widget UI اور build config scaffold کرے گا۔ Project folder میں:

npm install && npm run build && npm run serve

اب server http://localhost:3001/mcp پر چل رہا ہے۔ Render دیکھیں۔

Step 3 · Render دیکھیں

Option A: مفت local host۔ ext-apps کا minimal host:

git clone https://github.com/modelcontextprotocol/ext-apps.git
cd ext-apps/examples/basic-host && npm install
SERVERS='["http://localhost:3001/mcp"]' npm start

http://localhost:8080 کھولیں، tool call اور sandbox iframe widget دیکھیں۔

Option B: Claude web/Desktop۔ دوسرے terminal میں tunnel:

npx cloudflared tunnel --url http://localhost:3001

حاصل ہونے والے https://….trycloudflare.com کو Settings → Connectors → Add custom connector میں add کریں۔ Pro/Max/Team plan چاہیے۔ نئی chat میں color picker مانگیں۔

Step 4 · Agent کا build پڑھیں

دو MCP primitives، ایک bridge۔ Server پر UI metadata والا tool اور UI serve کرنے والا resource:

// server.ts (the load-bearing lines)
const resourceUri = "ui://get-time/mcp-app.html"; // ui:// marks this as an App interface

registerAppTool(
  server,
  "get-time",
  {
    title: "Get Time",
    description: "Returns the current server time.",
    inputSchema: {},
    _meta: { ui: { resourceUri } }, // the one line that turns a tool into an App
  },
  async () => ({
    content: [{ type: "text", text: new Date().toISOString() }], // the text fallback
  }),
);

registerAppResource(
  server,
  resourceUri,
  resourceUri,
  { mimeType: RESOURCE_MIME_TYPE },
  async () => ({
    contents: [{ uri: resourceUri, mimeType: RESOURCE_MIME_TYPE, text: html }],
  }),
);

اس widget کی App class واحد sandbox channel ہے:

// src/mcp-app.ts (the load-bearing lines)
const app = new App({ name: "Get Time App", version: "1.0.0" });
app.connect(); // open the postMessage channel to the host

app.ontoolresult = (result) => {
  /* the host pushes the first tool result here */
};

await app.callServerTool({ name: "get-time", arguments: {} }); // the UI calls tools back

یہ text content non-Apps fallback ہے۔ Widget host page/cookies کو نہیں چھوتا؛ postMessage پر audited JSON-RPC ہے۔ ہر callServerTool round trip ہے، اس لیے انتظار کو graceful بنائیں۔

Step 5 · اصل build: refund approval card

محض vibe نہیں، spec؛ widget پر Spec-Driven Development:

Using the create-mcp-app skill, build an MCP App called refund-approval.

Tool: review_refund(order_id: string, amount: number, confidence: "high" | "low" | "unsure").
It returns the refund details as plain text (the fallback) and renders an approval card.

The card must:
1. Show one plain line: "Refund #<order_id> · $<amount> · confidence: <word>".
   Confidence is always a word, never a colour.
2. Offer two buttons, Approve and Escalate to a human. Both must be reachable
   by keyboard, with labels a screen reader announces.
3. On Approve, call the server tool approve_refund(order_id), then show
   "Approved · Undo available for 24h" with an Undo button that calls
   undo_refund(order_id).
4. If amount > 50, disable Approve and show "Above limit: needs a human",
   leaving only Escalate active.
5. Make approve_refund and undo_refund idempotent on order_id: calling either
   twice must be safe.

اب Steps 2/3 کی طرح build، serve اور test کریں، پھر design pass:

Check	تصور
Non-Apps host یا text content: fallback فیصلہ باقی رکھتا ہے؟	14 · fallback
Confidence لفظ ہے، colour نہیں؛ plain line؟	7 · transparency، 5 · accessibility
Approve کے بعد Undo، one click اور دو بار بھی safe؟	11 · repair، 13 · idempotency
$900 refund سے انکار اور human route؟	8 · autonomy dial
ہر control keyboard سے؟	5 · access
Action names، review_refund، process نہیں؟	13 · machine surface

سب pass ہوں تو ایک call نے human کو plain line اور agent کو typed idempotent contract دونوں دیے: تصور 2 کی دونوں سطحیں۔

Step 6 · مزید گہرائی

اصل sources: modelcontextprotocol.io/extensions/apps/overview، modelcontextprotocol.io/extensions/apps/build، apps.extensions.modelcontextprotocol.io اور ext-apps GitHub examples: maps، 3D، PDFs، dashboards، React/Vue/Svelte/vanilla starters۔ Command fail ہو تو agent guide fetch کرکے reconcile کرے۔

تصدیق شدہ، مگر details کو ہلکا تھامیں

یہ commands/patterns mid-2026 guide سے verified ہیں۔ جولائی 2026 کی finalized extension active development میں ہے؛ package names/helpers/hosts بدلیں گے۔ Durable pattern tool + ui:// resource + sandbox render + postMessage ہے۔

---

Projects

1. استعمال شدہ agent کا audit۔ تصور 18 کے anti-patterns سے score کریں، کمزور ترین trust input اور بہترین تبدیلی چنیں۔
2. پیمانہ بنائیں۔ Worker کے پانچ stops، ہمیشہ in-loop actions اور وجہ۔
3. Nudge budget۔ Interrupt events سے صرف وہ فہرست بنائیں جہاں واقعی انسان درکار ہے۔
4. مشینی سطح لکھیں۔ Capability connector/MCP tool کو ایسے لکھیں کہ ناواقف agent پہلی کوشش میں استعمال کر سکے، چار AX سوالوں کے ساتھ۔
5. Fleet view۔ پانچ Workers، ایک نظر، interruption/log اور drift signal۔
6. مکمل brief capstone۔ Digital FTE کا گیارہ حصوں والا Agent Experience Brief۔
7. Widget ship کریں۔ Lab Step 5 تک حقیقی host، design pass اور plain form سے مختلف تین decisions۔

---

قاری کا راستہ

اگر build کے بجائے ہدایت دینی ہو تو تصورات 1–4، 8، 12، 13، 16، 17؛ پھر autonomy ladder، fleet view اور machine-surface judgment۔ Leader کے قابلِ بھروسا review کے لیے اتنا کافی ہے۔

کتاب میں اس کی جگہ

یہ Spec-Driven Development جیسی design discipline ہے، install ہونے والا tool نہیں۔ Human-Agent Teams operating model لکھتا ہے؛ یہ انسان کا team-work surface بناتا ہے۔ دونوں مل کر manual اور control room ہیں۔

Appendix A: MCP Apps کا نقشہ (2026)

تصورات 13/14 اور Lab کے parts، mid-2026 status۔ جولائی 2026 میں finalized مگر active؛ modelcontextprotocol.io/extensions/apps verify کریں۔ MCP Apps tool layer پر ہے جہاں discovery، calls، results اور task UI ہوتی ہے۔

Piece	کیا ہے
Tool	معمول کا MCP tool، _meta.ui.resourceUri interface؛ text non-Apps fallback
ui:// resource	HTML interface، عموماً CSS/JS bundled، server resource
Sandboxed iframe	isolated render، host page/cookies/storage سے بند
postMessage channel	JSON-RPC، ui/ methods اور tools/call، host-auditable
csp اور permissions	external origins اور camera/mic capabilities
App class	@modelcontextprotocol/ext-apps: connect()، ontoolresult، callServerTool()؛ optional web-API wrapper
Host support	mid-2026 میں Claude، Desktop، VS Code، Goose، Postman، MCPJam؛ OpenAI Apps SDK اسی base پر

یہاں tool/resource مشین، widget انسان اور sandbox/channel/permissions safety surface ہیں۔ ایک pattern، تین surfaces۔

Appendix B: MCP Apps بمقابلہ OpenAI Apps SDK، designer note

دو عام راستے MCP Apps اور OpenAI Apps SDK حریف نہیں۔ OpenAI Apps SDK، MCP پر built ہے: ChatGPT App ایک MCP server ہے جس میں extras ہیں؛ وہی iframe، JSON-RPC اور UI declaration۔

Experience extras:

• Discovery surface۔ ChatGPT store اور Claude directory (claude.ai/directory)؛ ecosystem میں cold-start کے وقت تلاش اور pre-use trust۔
• In-chat payment۔ 2026 beta/selected markets؛ review-confirm-pay compressed ہوتا ہے، اس لیے clear commitment اور reversible recovery۔
• Distribution۔ User-base reach، single-host lock-in کا tradeoff۔

Rule: پہلے open MCP Apps base، پھر vendor store/checkout extras feature-detect کریں اور باقی جگہ gracefully degrade۔ Vendor-only design پھنساتی ہے۔

مزید build detail: Payment-Enabled Agents، Connector-Native Apps، Plugins for AI Agents۔ Vendor details current docs سے verify کریں۔

Appendix C: Agent Experience Brief (قابلِ تکمیل template)

تصور 18 کا blank deliverable۔ Worker name اور ہر field بھریں۔ مشکل field pending design decision ہے۔ مخصوص سوالوں کی وجہ سے یہ generation prompt یا Agent Factory spec بھی ہے۔ اسے ایک یا دو pages تک رکھیں۔

---

Agent Experience Brief: Worker name: ____________________________ · Owner: __________________ · Date: __________

1 · دو سامعین · تصور 2 انسانی اور agent users کون ہیں؟ ____________________________________________________________________

2 · پہلا رابطہ · تصور 5 آغاز، action-power expectation reset اور sight/mouse کے بغیر WCAG 2.2 use؟ ____________________________________________________________________

3 · Trust surface · تصور 7 پہلے سے دکھنے والی Layer 1 اور plan، why + confidence، evidence؟ ____________________________________________________________________

4 · Load map · تصور 6 انسان/Worker کا کام اور visible movable line؟ ____________________________________________________________________

5 · Autonomy ladder · تصور 8 پانچ stops اور ہمیشہ human-in-loop actions؟ ____________________________________________________________________

6 · Async plan · تصور 10 ارادہ، progress، wait latency/cost اور nudges؟ ____________________________________________________________________

7 · Recovery plan · تصور 11 واپسی یعنی Undo، escalation اور دو health metrics؟ ____________________________________________________________________

8 · At scale · تصور 12 پوری team کا Fleet view، attention اور drift؟ ____________________________________________________________________

9 · Machine surface · تصور 13 مشینی سطح کے Connector/MCP tools، AX access/context/tools/orchestration؟ ____________________________________________________________________

10 · Safety surface · تصور 16 حفاظت کے لیے injection، excessive agency، runaway cost، disclosure defenses؟ ____________________________________________________________________

11 · Scorecard · تصور 17 تجربے کے metrics اور correctness handoff؟ ____________________________________________________________________

---

Appendix D: بھرا ہوا brief (worked example)

یہ customer-support Refund Worker کا template ہے؛ ہر جواب concrete decision ہے، سوال کی repetition نہیں۔

Agent Experience Brief۔ Worker name: Refund Worker · Owner: Support Lead · Date: 2026-07-01

1 · دو سامعین۔ Human support lead؛ agents ticket orchestrator اور payment API۔

2 · پہلا رابطہ۔ «Suggest» سے آغاز؛ action promotion banner: «اب $50 تک refund خود issue کرتا ہے، صرف recommend نہیں۔» Controls keyboard/screen reader سے؛ confidence لفظ میں، colour نہیں۔

3 · Trust surface۔ Layer 1 line؛ Layer 2 order→policy→refund→email plan؛ Layer 3 why/policy/high-low-unsure؛ Layer 4 trace/raw API۔

4 · Load map۔ Worker logistics؛ lead above-limit/low-confidence judgment؛ «waiting on you» lane۔

5 · Autonomy ladder۔ 1 Suggest → 2 Confirm → 3 Act within limits ≤ $50 → 4 Act/report → 5 Autonomous۔ Stop 3؛ >$50، chargeback، fraud flag ہمیشہ in-loop۔

6 · Async plan۔ ایک ticket/goal، named progress؛ cost meter نہیں؛ nudges above limit، low-confidence match، provider error۔

7 · Recovery plan۔ 24-hour one-click reversal؛ lead پھر on-call finance؛ escalation 5–15%، recovery >90%۔

8 · At scale۔ دس Workers؛ $900 اور دگنی escalation نمایاں؛ reversal >2x اپنی baseline پر stop 2۔

9 · Machine surface۔ Scoped revocable refund credential؛ valid-use context؛ typed refund_order(order_id, amount, reason) $50 cap؛ order_id پر idempotent۔

10 · Safety surface۔ Ticket data، plan provenance؛ $50 cap/in-loop pins؛ bounded spend؛ refund-only credential۔

11 · Scorecard۔ Plan acceptance، intervention trend، recovery، time-vs-attention۔ Decision correctness Eval-Driven Development کا کام ہے۔

---

Sources اور مزید مطالعہ

• John Maeda، Simplicity and Agentic Experience اور Design in Tech Report 2026: انسانی سطح۔
• Matt Biilmann، agents-as-users کے Access، Context، Tools، Orchestration۔
• Microsoft Design، Space/Time/Core، nudge اور calibrated uncertainty۔
• Adrian Levy، collaboration، load، transparency، async، dual audiences۔
• Smashing Magazine، intent preview، autonomy، intervention، repair benchmarks۔
• Jakob Nielsen، third UI، No More UI، accessibility provocation اور rebuttals۔
• MCP Apps SEP-1865 اور Model Context Protocol: tool ui:// resource کو _meta.ui.resourceUri سے جوڑتا ہے؛ sandbox iframe اور JSON-RPC۔ Overview modelcontextprotocol.io/extensions/apps/overview، build modelcontextprotocol.io/extensions/apps/build، SEP modelcontextprotocol.io/seps/1865-mcp-apps-interactive-user-interfaces-for-mcp، API apps.extensions.modelcontextprotocol.io، ext-apps repository، create-mcp-app skill اور Claude launch claude.com/blog/interactive-tools-in-claude۔ Host sandbox/allowlist/consent/audit deployer کا کام ہے۔
• OWASP Top 10 for LLM Applications 2025، تصور 16 کے threats۔
• NIST AI RMF 1.0، Govern/Map/Measure/Manage۔
• Microsoft HAX Toolkit/Playbook، pre-launch failure rehearsal۔
• W3C WCAG 2.2، accessibility کی بنیادی سطح۔

---

Flashcards Study Aid

---

اپنی سمجھ جانچیں

Checking access...