جب Anthropic نے 2024 کے آخر میں Building Effective Agents شائع کیا، تو اس نے صنعت کے لیے ایک نایاب کام کیا: اس نے انجینئرز کو ایک مشترکہ اصطلاحات کا مجموعہ (shared vocabulary) فراہم کیا۔ مصنوعی عام ذہانت (AGI) کے بارے میں ایک اور منشور پیش کرنے کے بجائے، اس گائیڈ نے LLM سسٹمز کی ساخت کے لیے چھ واضح پیٹرنز پیش کیے۔ ڈیڑھ سال بعد، 2026 میں، منظرنامہ بالکل مختلف نظر آتا ہے۔ Model Context Protocol ایک عالمگیر معیار بن چکا ہے۔ Claude نے نئی صلاحیتیں حاصل کر لی ہیں۔ زیادہ تر تنظیموں کے پاس اب پروڈکشن میں کم از کم ایک ایجنٹ چل رہا ہے۔ اس پس منظر میں، یہ پوچھنا جائز ہے کہ آیا وہ چھ پیٹرنز اب بھی اہمیت رکھتے ہیں، یا وہ گزشتہ سال کے ماڈل ویٹس (model weights) کے ساتھ آرکائیو کا حصہ بن چکے ہیں۔

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

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

ان چھ پیٹرنز کو یاد رکھنا ضروری ہے: Prompt Chaining، Routing، Parallelization، Evaluator-Optimizer، Orchestrator-Workers، اور Autonomous Agents۔ آخری والا بنیادی طور پر ایک لوپ ہے جس میں ماڈل منصوبہ بندی کرتا ہے، عمل کرتا ہے، مشاہدہ کرتا ہے، اور اس وقت تک دہراتا ہے جب تک کہ کوئی شرط پوری نہ ہو جائے۔

گائیڈ کے آنے سے پہلے ہی بہت سے انجینئرز پرامپٹس کو چین (chaining) کر رہے تھے یا ٹاسک ورکر تھریڈز کو سونپ رہے تھے۔ Anthropic نے جو فراہم کیا وہ درجہ بندی (taxonomy) تھی۔ ایک شخص کا "agent" دوسرے کے لیے "workflow" تھا، اور تیسرے کے لیے "multi-step tool call" تھا۔ گائیڈ نے اس الجھن کو واضح حدود والے حصوں (buckets) میں تقسیم کر دیا۔ اس سے ایک دوسرے کی بات کو غلط سمجھے بغیر ٹریڈ آفز (trade-offs) پر بحث کرنا ممکن ہو گیا۔ ہائپ (hype) میں ڈوبے ہوئے اس شعبے میں، واضح زبان ایک طرح کا انفراسٹرکچر ہے۔

صنعت نے اس کے گرد نہیں بلکہ اس کے اوپر تعمیر کیا

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

وجہ سادہ ہے۔ صنعت نے فریم ورک کو تبدیل نہیں کیا۔ بلکہ اس کے اوپر تعمیر کیا۔ MCP اور نئے Agent Skills اسٹینڈرڈز جیسے نئے ٹولز پلمبنگ (plumbing) کے طور پر کام کرتے ہیں۔ وہ ماڈل کو ڈیٹا بیس سے جوڑنا، ٹول کو ظاہر کرنا، یا اسٹیٹ (state) کو مینیج کرنا آسان بناتے ہیں۔ لیکن وہ اس منطق کو نہیں بدلتے کہ ایک آرکیسٹریٹر کے بجائے راؤٹر کب استعمال کرنا ہے۔ ایک بہتر پائپ فلور پلان کو دوبارہ نہیں لکھتا۔

2026 کا پروڈکشن ڈیٹا اس کی تصدیق کرتا ہے۔ سب سے عام ڈیپلائمنٹ پیٹرن اب بھی انسانی نظرثانی کے ساتھ ایک سنگل ٹول-استعمال کال ہے۔ دوسرا سب سے عام پیٹرن ایک ملٹی سٹیپ ورک فلو ہے جس میں بالکل ایک بار انسان کو کام سونپا جاتا ہے۔ یہ دونوں Prompt Chaining اور Routing کے براہ راست وارث ہیں۔ لائیو سسٹمز میں مکمل خود مختار (autonomous) لوپس اب بھی استثنا ہیں، قاعدہ نہیں۔

ضبط نے مارکیٹ جیت لی

اصل گائیڈ کی بہترین نصیحت وہی تھی جسے 2024 میں سب سے زیادہ نظر انداز کیا گیا: وہ سادہ ترین پیٹرن استعمال کریں جو کام کر دے۔ اگر ایک ہارڈ کوڈڈ راستہ کام مکمل کر سکتا ہے تو مکمل خود مختار ایجنٹ ڈیپلائے نہ کریں۔

مارکیٹ نے آخر کار اسے اپنا لیا ہے۔ زیادہ تر ایجنٹ پائلٹ اب بھی ناکام ہو رہے ہیں، اور وہ اسی قابلِ پیش گوئی وجہ سے ناکام ہوتے ہیں۔ ٹیمیں ایک کے اوپر ایک ایبسٹریشن (abstraction) اس وقت تک لگاتی رہتی ہیں جب تک کہ کوئی بھی فیصلے کی حد (decision boundary) کا سراغ نہ لگا سکے۔ جب سسٹم بھٹک جاتا ہے، تو ڈی بگنگ (debugging) آثارِ قدیمہ کی کھدائی بن جاتی ہے۔ پروڈکشن میں کامیاب ہونے والی کمپنیاں وہی ہیں جنہوں نے ضبط کا مظاہرہ کیا۔ انہوں نے سنگل ٹرن ٹول استعمال کرنے کو ترجیح دی۔ انہوں نے راؤٹنگ لیئر صرف اس وقت شامل کی جب سنگل پرامپٹ غیر مستقل ثابت ہوا۔ انہوں نے خود مختاری کو ایک ایسی ذمہ داری کے طور پر لیا جسے ثابت کرنا ضروری ہو، نہ کہ ایک ایسی خصوصیت کے طور پر جسے جشن منایا جائے۔

یہ عزائم کے خلاف دلیل نہیں ہے۔ یہ ترکیب (composition) کے حق میں دلیل ہے۔ پیٹرنز اس وقت بہترین کام کرتے ہیں جب آپ انہیں مینو میں موجود سب سے پیچیدہ آپشن کی طرف بے اختیار جانے کے بجائے دانستہ طور پر آپس میں ملاتے ہیں۔

جہاں دراڑیں نظر آنا شروع ہوتی ہیں

یہ فریم ورک ہر مسئلے کا حل نہیں ہے۔ کچھ ایسی سخت حدود ہیں جو پروٹو ٹائپ مرحلے سے نکلتے ہی سامنے آ جاتی ہیں۔

For high-frequency, low-cost tasks, deterministic code still wins. An LLM should not be normalizing a CSV column when pandas can do it in milliseconds without hallucinating. Avoid autonomous loops if you cannot define a crisp evaluation goal. Without a clear stopping condition, the model will iterate until it invents a reason to stop. For high-stakes decisions that require external grounding, do not rely solely on the model’s internal knowledge. And watch for bottlenecks in data retrieval. Any pattern that depends on vector search or external APIs can choke if your database is slow or your context window is clogged with irrelevant chunks.

These are not hypothetical edge cases. They are the constraints that separate a working demo from a system that survives the weekend.

A Rigid Check and a Wrong Failure

I learned the practical value of this framework while building my test repository. I was implementing the Evaluator-Optimizer pattern. My evaluator started as a hardcoded regex that scanned the model’s output for specific keywords. The model returned a correct, well-reasoned answer that happened to use synonyms instead of the exact words I was hunting. The evaluator flagged it as a failure.

The model was right. My check was too rigid.

Fixing it required more than expanding a word list. I switched the evaluator itself to an LLM-based judgment. That cost extra tokens and a few more milliseconds, but it restored the evaluation to the right level of abstraction. The pattern itself was sound. I had simply chosen the wrong implementation for the task. That is exactly the kind of mistake the framework is meant to prevent. Some evaluations need code. Others need a model. Knowing which is which is the whole point.

How to Use Them Now

Treat these six patterns as a starting point, not absolute law. Begin with a single prompt. If quality is inconsistent across input types, add a routing layer to send different requests to specialized prompts. If you need multiple independent perspectives before making a call, use Parallelization. If the task is large and divisible, try Orchestrator-Workers. Only reach for the full autonomous loop when the problem space is too wide to pre-map and when you have a reliable