ہر چند ماہ بعد، صنعت ایسے سافٹ ویئر کے لیے ایک نئی اصطلاح ایجاد کرتی ہے جو مبینہ طور پر خود سے سوچ سکتا ہے۔ اس وقت وہ لفظ "Agentic AI" ہے۔ وینڈرز اسے لینڈنگ پیجز اور پچ ڈیکس پر لگانے میں جلدی کرتے ہیں۔ لیکن ایک لیبل صرف مارکیٹنگ کا مواد ہے جب تک کہ سسٹم آپ کے ماحول، آپ کے ڈیٹا، اور آپ کے فیل ہونے کے طریقوں (failure modes) کا سامنا نہ کر لے۔ یہ لفظ خود آپ کو حفاظت، بھروسہ مندی، یا مطابقت کے بارے میں کچھ نہیں بتاتا۔

اب وقت آگیا ہے کہ فیچرز کی فہرستیں پڑھنا بند کریں اور صلاحیتوں (capabilities) کی پیمائش شروع کریں۔

لیبل کا مسئلہ

سیلز انجینئرز آپ کو "agentic" آرکیٹیکچر کے ثبوت کے طور پر ڈیش بورڈز، ملٹی ماڈل ڈراپ ڈاؤن مینیو، اور موبائل رسائی دکھائیں گے۔ یہ صرف انٹرفیس کے انتخاب ہیں، طرزِ عمل (behavioral) کی ضمانت نہیں۔ ایک پروڈکٹ جدید ترین نظر آ سکتی ہے لیکن جیسے ہی API timeout کے بعد اسے اپنے منصوبے پر نظر ثانی کرنے کی ضرورت پڑتی ہے، وہ ناکام ہو سکتی ہے۔

اصل اہمیت اس بات کی ہے کہ کیا سسٹم واقعی ایک خود مختار ایجنٹ (autonomous agent) کی طرح کام کرتا ہے۔ کیا یہ کام کو مختلف مراحل میں تقسیم کرتا ہے؟ کیا یہ سخت حدود کے اندر رہتے ہوئے حقیقی سسٹمز کو استعمال کرتا ہے؟ جب کچھ خراب ہوتا ہے، تو کیا یہ خود کو ڈھال لیتا ہے، یا صرف ناکام ہو کر انتظار کرتا ہے؟ جب تک آپ اپنے اسٹیک (stack) سے متعلقہ شواہد کے ساتھ ان سوالات کے جواب نہیں دیتے، آپ ایک تصور خرید رہے ہیں، پروڈکٹ نہیں۔

صلاحیتوں کے پانچ ٹیسٹ جو حقیقت میں اہمیت رکھتے ہیں

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

Planning (منصوبہ بندی)۔ کیا سسٹم ایک مبہم مقصد کو ترتیب وار اور قابلِ تصدیق مراحل میں تقسیم کرتا ہے؟ کوئی بھی ٹو-ڈو لسٹ (to-do list) بنا سکتا ہے۔ اصل امتحان ایک پیچیدہ مقصد کو سنبھالنا ہے جیسے کہ "اس سہ ماہی میں اپنے کلاؤڈ اخراجات میں پندرہ فیصد کمی لائیں"۔ ایک حقیقی ایجنٹ موجودہ استعمال کا آڈٹ تیار کرتا ہے، غیر استعمال شدہ وسائل (idle resources) کی نشاندہی کرتا ہے، درست سائزنگ (rightsizing) کی سفارشات کا مسودہ تیار کرتا ہے، اور مناسب ترتیب میں تبدیلی کی درخواستوں (change requests) کا شیڈول بناتا ہے۔ اگر یہ آپ کو محض پانچ نکات پر مشتمل ایک عام سا مضمون دے دے اور کام مکمل قرار دے دے، تو یہ منصوبہ بندی نہیں ہے۔ یہ صرف خلاصہ کرنا ہے۔

Tools (اوزار)۔ کیا یہ مقررہ دائرہ کار کے اندر رہتے ہوئے حقیقی سسٹمز پر عمل کرتا ہے؟ ایک بہترین ڈیمو میں موک API (mock API) کو کال کرنا آسان ہے۔ آپ کے پروڈکشن CRM تک کم از کم اختیارات (least-privilege credentials) کے ساتھ رسائی حاصل کرنا، ایک ریکارڈ لکھنا، اور ٹرانزیکشن کو لاگ کرنا مشکل ہے۔ آپ کو بالکل معلوم ہونا چاہیے کہ یہ کن سسٹمز کو چھوتا ہے، اس کے پاس کون سی چابیاں (keys) ہیں، اور اس کے اثرات کا دائرہ (blast radius) کہاں ختم ہوتا ہے۔ دائرہ کار محدود ہونا چاہیے۔ اگر ایجنٹ کے پاس ڈیفالٹ طور پر پروڈکشن تک لکھنے (write access) کا اختیار ہے، تو آپ کے پاس ایجنٹ نہیں ہے۔ آپ کے پاس ایک ذمہ داری (liability) ہے۔

Correction (اصلاح)۔ کیا یہ ناکامی کے بعد اپنا اگلا قدم تبدیل کرتا ہے؟ زیادہ تر پروٹو ٹائپس یہیں دم توڑ دیتے ہیں۔ جب تیسرا مرحلہ 503 error یا schema mismatch دکھاتا ہے، تو کیا ایجنٹ ہمیشہ کے لیے لوپ (loop) میں پھنس جاتا ہے، کامیابی کا جھوٹا پیغام (hallucinate) دیتا ہے، یا اپنا راستہ درست کرتا ہے؟ حقیقی اصلاح کا مطلب ہے ناکامی کا مشاہدہ کرنا، ورک فلو کے باقی حصے کی دوبارہ منصوبہ بندی کرنا، اور پابندیوں (constraints) کو برقرار رکھتے ہوئے ایک نیا راستہ اختیار کرنا۔ محض امید پر مبنی ری ٹرائی لوپ (retry loop) اصلاح نہیں ہے۔

Context (سیاق و سباق)۔ کیا یہ ہر مرحلے پر پابندیوں کو فعال رکھتا ہے؟ صرف میموری (memory) کافی نہیں ہے۔ اگر پہلا مرحلہ ایک سخت اصول طے کرتا ہے جیسے کہ "پانچ سو ڈالر کے بجٹ سے تجاوز نہ کریں" یا "EU کسٹمر ڈیٹا کو شامل نہ کریں،" تو ساتواں مرحلہ اس حد کو نظر انداز نہیں کر سکتا صرف اس لیے کہ پرامپٹ (prompt) کا سیاق و سباق بدل گیا ہے۔ یہ اصول تعمیل کے قواعد (compliance rules)، برانڈ کی آواز (brand voice)، منظوری کے درجات (approval hierarchies)، اور رسائی کے کنٹرولز پر بھی لاگو ہوتا ہے۔ سیاق و سباق کو برقرار رکھنا وہ مقام ہے جہاں long-context ماڈلز اور کلاسیکل اسٹیٹ مینجمنٹ (state management) کو ملنا چاہیے۔

Oversight (نگرانی)۔ کیا کوئی انسان عمل کو روک یا دوبارہ شروع کر سکتا ہے؟ آپ کو ایسے سرکٹ بریکرز (circuit breakers) کی ضرورت ہے جو باریک بینی سے کام کریں، نہ کہ صرف ورچوئل مشین پر ایک 'کل سوئچ' (kill switch)۔ کیا کوئی شخص دوسرے مرحلے کے بعد منصوبے کا معائنہ کر سکتا ہے اور تیسرے مرحلے کی منظوری دے سکتا ہے؟ اگر کوئی بیرونی انحصار (external dependency) ناکام ہو جائے، تو کیا کوئی انسان اسے ٹھیک کر کے اسٹیٹ (state) کھوئے بغیر ورک فلو کو دوبارہ شروع کر سکتا ہے؟ نگرانی کوئی ایسا آڈٹ لاگ نہیں ہے جسے آپ تباہی آنے کے بعد پڑھتے ہیں۔ یہ مداخلت کے لیے ایک لائیو میکانزم ہے۔

شواہد چیک باکسز سے بہتر ہیں

ایک ڈیمو بھروسہ مندی کی شرح نہیں ہے۔ وینڈر موازنہ شیٹ پر ایک چیک باکس ثبوت نہیں ہے۔ جب کوئی اکاؤنٹ ایگزیکٹو کہتا ہے کہ پروڈکٹ "ٹیسٹ کی ناکامی کے بعد نظر ثانی کرتی ہے،" تو آپ کا اگلا قدم 'ایویڈنس کارڈ' (evidence card) مانگنا ہونا چاہیے۔

ایک ایویڈنس کارڈ چیک باکس کی جگہ مخصوص معلومات فراہم کرتا ہے۔ یہ کچھ اس طرح نظر آتا ہے:

  • Capability (صلاحیت): Correction
  • Claim (دعویٰ): Revises after a test failure
  • Evidence (شواہد): Pending controlled fixture
  • Owner (ذمہ دار): Developer-experience team
  • Stop if (اگر یہ ہو تو روک دیں): Revision changes an approved interface

یہ فارمیٹ وضاحت کو لازمی بناتا ہے۔ یہ مارکیٹنگ کے دعوے کو ثبوت سے الگ کرتا ہے۔ یہ ذمہ داری (ownership) تفویض کرتا ہے تاکہ جب ایجنٹ اپنی نظرثانی کی کوشش کے دوران کسی منظور شدہ انٹرفیس کو خراب کرے، تو آپ کو معلوم ہو کہ کس ٹیم کو پینج (page) کیا جانا ہے۔ مالک کے بغیر، کوئی جوابدہی نہیں ہوتی۔ رکنے کی شرائط (stop conditions) کے بغیر، کوئی حفاظتی رکاوٹ نہیں ہوتی۔

کسی بھی پائلٹ (pilot) کو شروع کرنے سے پہلے، تین چیزوں کو تحریری طور پر متعین کریں۔ پہلا، آپ کے ٹاسک (tasks)۔ یہ حقیقی کاروباری منطق (business logic) سے ماخوذ ہونے چاہئیں، نہ کہ مصنوعی بینچ مارکس (synthetic benchmarks) سے۔ دوسرا، آپ کے فیلئیر ٹیسٹ (failure tests)۔ عمل کے دوران کسی API key کو منسوخ کر دیں، ایک غلط JSON رسپانس شامل کریں، یا متوقع لیٹنسی (latency) کو دوگنا کر دیں۔ تیسرا، آپ کی رکنے کی شرائط (stop conditions)۔ یہ خودکار ہونی چاہئیں، نہ کہ کوئی دستی پینک بٹن جس کے بارے میں آپ امید کریں کہ کوئی اسے نوٹ کر لے گا۔

وینڈرز کے دعووں کا جائزہ کیسے لیا جائے

OpenAI تجویز کرتا ہے کہ ایجنٹس کو پانچ اجزاء کی ضرورت ہوتی ہے: models، tools، instructions، guardrails، اور human intervention۔ آپ اس فہرست کو وینڈرز سے سوال کرنے کے لیے ایک ذخیرہ الفاظ کے طور پر استعمال کر سکتے ہیں بغیر ان کے مخصوص آرکیٹیکچر کو اپنائے ہوئے۔

پوچھیں کہ کون سا model محض جنریشن کے بجائے پلاننگ کو سنبھالتا ہے۔ پوچھیں کہ کن tool permissions کو hardcoded کیا گیا ہے اور کون سی dynamic ہیں۔ پوچھیں کہ guardrails کہاں نافذ کیے جاتے ہیں، prompt layer میں یا orchestration engine میں۔ پوچھیں کہ کیا human intervention ایک بلٹ ان چیک پوائنٹ ہے یا ایجنٹ کے آپ کے ڈیٹا بیس کو خراب کرنے کے بعد بھیجا جانے والا ایک post-mortem ای میل ہے۔ آپ OpenAI کے stack کی خریداری نہیں کر رہے ہیں۔ آپ کسی دوسرے کے سسٹم میں خامیوں کو بے نقاب کرنے کے لیے ان کے فریم ورک کا استعمال کر رہے ہیں۔

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

خریداری کا ایک اصول جو بجٹ بچاتا ہے

ایک agentic پائلٹ کو پروڈکشن کی ذمہ داری میں تبدیل کرنے کے لیے میرا اصول سادہ ہے۔ میں اسکوپ اور بجٹ میں اضافہ صرف تب کرتا ہوں جب اہم صلاحیتوں کا ثبوت موجود ہو اور ناکامیوں کے لیے ایک واضح ذمہ دار (owner) ہو۔ کوئی روڈ میپ سلائیڈ نہیں۔ کوئی سپورٹ ٹکٹ کی قطار نہیں۔ ثبوت کا مطلب ہے آپ کے ماحول (environment) سے حاصل کردہ logs۔ ذمہ دار کا مطلب ہے ایک نامزد انسان جو اس مخصوص ناکامی کے لیے جوابدہ ہو۔

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

یاد رکھنے والی بات: لفظ "Agentic" آپ کے جائزے کے لیے ایک آغاز کا نشان (starting pistol) ہے۔ یہ فنش لائن نہیں ہے۔ اسے مزید مشکل سوالات پوچھنے، سخت ترین پائلٹ چلانے، اور ایسے ثبوت مانگنے کے ایک اشارے کے طور پر لیں جو آپ کے اپنے ادارے کے اندر اہمیت رکھتے ہوں۔ اگر پروڈکٹ آپ کے اپنے ماحول میں، آپ کی اپنی ناکامیوں کے ساتھ، پانچ صلاحیتوں کے ٹیسٹ پاس نہیں کر سکتا، تو وہ واقعی agentic نہیں ہے۔ وہ محض ایک اور ڈیمو ہے۔

Source: https://dev.to/bestbee/is-it-really-agentic-ai-use-a-five-capability-product-gate-1c0h

Optional learning community: https://t.me/GyaanSetuAi