طویل مدتی AI ایجنٹس کے لیے کانٹیکسٹ انجینئرنگ

مجموعی طور پر Arize کا تجزیہ، کانٹیکسٹ ونڈو اوورفلو پر arXiv پیپر، Redis کی پروڈکشن وضاحت، اور Atlan کا ہارنس انجینئرنگ موازنہ ایجنٹ ڈیزائن میں ایک عملی تبدیلی کی طرف اشارہ کرتے ہیں۔ طویل عرصے تک چلنے والے ایجنٹس کو ماڈل کی کانٹیکسٹ ونڈو کے سائز سے کم، اور اس کے گرد موجود کنٹرول لیئر سے زیادہ جانچا جا رہا ہے۔ Arize اس تبدیلی کو ٹھوس بناتا ہے۔ یہ Pi، OpenClaw، Claude Code اور Letta سمیت بھیجے گئے ایجنٹ ٹولز اور میموری/ہارنس سسٹمز کو ہارنس سطح کی کانٹیکسٹ انجینئرنگ کی مثالوں کے طور پر نام دیتا ہے، اور ایک انٹرایکٹو سمیولیٹر بیان کرتا ہے جو 200K-token ونڈو کو بھرتے ہوئے دکھاتا ہے۔

حوالہ دیے گئے ذرائع میں دستیاب عوامی تفصیلات یکساں نہیں ہیں۔ Arize، Pi، OpenClaw، Claude Code اور Letta کے لیے ٹھوس امپلیمنٹیشن نمبرز دیتا ہے۔ AI ایجنٹس میں کانٹیکسٹ ونڈو اوورفلو حل کرنے پر ایک ریسرچ پیپر ٹول آؤٹ پٹس کو سنبھالنے کا زیادہ عمومی میکانزم دیتا ہے جو کسی بھی عملی ونڈو سے بڑھ سکتے ہیں۔ Redis کا کانٹیکسٹ ونڈو اوورفلو پر ایکسپلینر پروڈکشن علامات کا خلاصہ کرتا ہے: سخت API ایررز، خاموش کوالٹی ڈیگریڈیشن، ٹول آؤٹ پٹ جمع ہونا، اور prompts کے بڑھنے کے ساتھ زیادہ latency۔ Atlan کا prompt، context اور harness engineering کا موازنہ مفید اسٹیک استعارہ فراہم کرتا ہے: prompt engineering پیغام کو شکل دیتی ہے، context engineering ماڈل کو دکھائی دینے والی چیز کو شکل دیتی ہے، اور harness engineering پورے ایجنٹ ماحول کو شکل دیتی ہے۔

اہم خبر یہ نہیں کہ کانٹیکسٹ ونڈوز بہت چھوٹی ہیں۔ بلڈرز یہ پہلے ہی جانتے ہیں۔ زیادہ مفید نکتہ یہ ہے کہ حوالہ دیے گئے ایجنٹ سسٹمز چار ہارنس میکانزمز پر مجتمع ہو رہے ہیں جو ٹرانسکرپٹ کے محفوظ source of truth نہ رہنے کے بعد بھی کام کو زندہ رکھتے ہیں۔

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

حدود کے پہلے سیٹ کو پڑھنے کا ایک صاف طریقہ یہ ہے:

• Pi: فائل ریڈز 2,000 لائنز یا 50KB، جو بھی پہلے آئے، پر رک جاتی ہیں۔ واپس آنے والے مواد میں ایک continuation hint شامل ہوتا ہے جو ماڈل کو بتاتا ہے کہ کون سی line range دکھائی گئی اور offset اور limit کے ساتھ کیسے آگے بڑھنا ہے۔ OpenClaw یہ رویہ وراثت میں لیتا ہے، پھر الگ caps شامل کرتا ہے: bootstrap files فی فائل 12,000 characters اور کل 60,000 characters تک محدود ہوتی ہیں۔ Tool results کو 16,000 characters یا context window کے 30%، جو بھی کم ہو، کا ایک اور budget ملتا ہے۔

Claude Code دو گیٹ والا ڈیزائن استعمال کرتا ہے۔ Arize کے مطابق، یہ فائل کھولنے سے پہلے 256KB byte cap چیک کرتا ہے، پھر read کے بعد نتیجے کو 25,000-token budget کے خلاف token-count کرتا ہے۔ cap کے اندر آنے والی فائلوں کے لیے بھی، یہ default طور پر آغاز سے 2,000 lines واپس کرتا ہے، اور 2,000 characters سے لمبی lines کو truncate کرتا ہے۔ اگر ماڈل اسی file range کو دوبارہ پڑھتا ہے اور فائل تبدیل نہیں ہوئی، تو Claude Code مکمل content دہرانے کے بجائے stub واپس کر سکتا ہے۔

یہ صرف optimization نہیں ہے۔ یہ failure mode کو بدل دیتا ہے۔ ایک بڑی read کو task کو باہر دھکیلنے دینے کے بجائے، ہارنس “سب کچھ پڑھو” کو “ایک controlled slice پڑھو” میں بدل دیتا ہے۔ اگر ماڈل کو مزید چاہیے، وہ مانگ سکتا ہے۔ scratch سے agent harnesses ڈیزائن کرنے والے بلڈرز کے لیے، یہ دفاع کی پہلی لائن ہے: raw external data کو default طور پر کبھی transcript نہ بننے دیں۔

اگلا پیٹرن context کو storage نہیں بلکہ viewport سمجھنا ہے۔

Pi اور Claude Code offset اور limit کے ذریعے pagination expose کرتے ہیں۔ OpenClaw کچھ جگہوں پر head/tail truncation شامل کرتا ہے، جب middle کے کم اہم ہونے کا امکان ہو تو beginning اور end کو برقرار رکھتا ہے۔ Arize کہتا ہے کہ OpenClaw oversized bootstrap files کے لیے 75% head / 25% tail split استعمال کرتا ہے، اور tool results کے لیے head اور tail دونوں رکھ سکتا ہے جب tail اہم دکھائی دے، جیسے errors، closing JSON braces یا summary-like keywords۔

Letta files کو prompt سے باہر live بنا کر مزید آگے جاتا ہے۔ Uploaded files کو parse، chunk اور vector store میں embed کیا جاتا ہے، جس سے ایجنٹ کو direct viewing، exact search اور semantic search ملتی ہے۔ جب کوئی file context میں open ہو، Letta ایک managed view دکھاتا ہے جس کا size model context کے ساتھ scale ہوتا ہے: 8K context کے لیے 5,000 characters، 32K کے لیے 15,000، 128K کے لیے 25,000، اور 200K+ کے لیے 40,000۔ بیک وقت open files کی تعداد بھی scale ہوتی ہے، چھوٹے models کے لیے 3 سے بہت بڑے models کے لیے 15 تک، اور LRU policy least recently accessed files کو evict کرتی ہے۔

یہی design idea production RAG کے پیچھے بھی ہے: پورا corpus prompt میں نہ ٹھونسیں؛ وہ حصہ retrieve کریں جو matter کرتا ہے۔ فرق یہ ہے کہ agent harnesses کو یہ مسلسل کرنا پڑتا ہے، files، tool outputs، memory اور intermediate plans کے across۔ یہی constraint RAG systems پر بھی لاگو ہوتی ہے: retrieval صرف relevance کے بارے میں نہیں، بلکہ actual reasoning step کے لیے کافی context budget محفوظ رکھنے کے بارے میں بھی ہے۔

Redis ایک متعلقہ نکتہ اٹھاتا ہے: بڑے context windows context management کی ضرورت ختم نہیں کرتے۔ System prompts، retrieved documents، conversation history اور tool outputs سب اسی space کے لیے compete کرتے ہیں۔ hard limit hit ہونے سے پہلے بھی، long inputs میں relevant information کے دب جانے سے models degrade ہو سکتے ہیں۔

Overflow واضح failure ہے۔ Goal loss خاموش ہوتا ہے۔ ایجنٹ کے پاس respond کرنے کی room اب بھی ہوتی ہے، مگر وہ original objective بھول جاتا ہے، کوئی constraint miss کر دیتا ہے، یا local subtask کو optimize کرنا شروع کر دیتا ہے۔

یہیں compaction اہم ہوتی ہے۔ بری طرح کی جائے تو summarization ایک messy مگر faithful history کو ایک صاف مگر lossy story سے بدل دیتی ہے۔ اچھی طرح کی جائے تو یہ task state، recent work، pending items اور tool-call integrity کو محفوظ رکھتی ہے۔

Arize رپورٹ کرتا ہے کہ Pi compaction کو اس وقت trigger کرتا ہے جب estimated context tokens، context window minus reserve tokens سے بڑھ جائیں، جس کا default reserve 16,384 tokens ہے۔ یہ حالیہ تقریباً 20,000 tokens کو رکھتا ہے اور older content کو ایک synthetic user message میں summarize کرتا ہے جو kept tail سے پہلے لگایا جاتا ہے۔ یہ tool-call/tool-result pairs کے درمیان cut کرنے سے بھی بچتا ہے۔

OpenClaw ایک زیادہ aggressive history policy شامل کرتا ہے۔ جب history context window کے 50% سے بڑھ جاتی ہے، یہ messages کو equal-mass token chunks میں split کرتا ہے، oldest chunk drop کرتا ہے، staged multi-pass summarization کے ذریعے dropped content کو summarize کرتا ہے، اور tool-call/result pairing کو repair کرتا ہے۔ یہ pre-compaction flush بھی performs کرتا ہے: ایک silent agentic turn ایجنٹ کو موقع دیتا ہے کہ history غائب ہونے سے پہلے state کو memory files میں persist کر دے۔ الگ سے، یہ 5-minute cache TTL پر soft-trim اور hard-clear behavior کے ساتھ memory میں tool results کو prune کرتا ہے۔

Claude Code window کے end کے قریب compact کرتا ہے۔ Arize کہتا ہے کہ اس کا trigger effective context window minus 13,000-token buffer ہے، جو 200K-context model کے لیے compaction کو تقریباً 167K tokens پر رکھتا ہے۔ اس کا summarization prompt structured sections مانگتا ہے جو primary request، technical concepts، files and code، errors and fixes، problem solving، user messages، pending tasks، current work اور next step کو cover کرتے ہیں۔ compaction کے بعد، یہ token budget کے اندر حال ہی میں پڑھی گئی 5 files تک دوبارہ attach کر سکتا ہے۔

پیٹرن واضح ہے: compaction “chat کو summarize کرنا” نہیں ہے۔ یہ checkpointing ہے۔ طویل عرصے تک چلنے والے agent کو save file کے برابر چیز چاہیے: goal، constraints، decisions، open handles، recent evidence اور next action۔

کچھ outputs کو context window میں رکھا ہی نہیں جانا چاہیے۔

arXiv paper اسے materials-science workflow کے ساتھ concrete بناتا ہے۔ ایک tool molecule کے لیے electronic grid structure بناتا ہے: dimensions 128 × 128 × 128 کی 3D matrix، کل 2,097,152 float32 elements۔ یہ output widely used LLMs کی context window سے بہت زیادہ ہے۔ مگر اگلے tool کو input کے طور پر grid چاہیے۔

مجوزہ حل یہ ہے کہ large values کو model context سے باہر store کیا جائے اور short identifiers، یا pointers، واپس کیے جائیں۔ Tool wrappers inputs inspect کرتے ہیں کہ آیا وہ raw values ہیں یا memory paths۔ بہت بڑے outputs کو runtime memory میں ایک path کے تحت store کیا جاتا ہے، اور بعد کے tools pointer receive کر کے اسے internally resolve کر سکتے ہیں۔ ماڈل references manipulate کرتا ہے، جبکہ ہارنس complete data محفوظ رکھتا ہے۔ paper کے مطابق، ایک comparative experiment میں جہاں دونوں methods کامیاب ہوئے، pointer-based approach نے traditional workflow کے مقابلے میں تقریباً سات گنا fewer tokens استعمال کیے۔

یہ reasoning اور data transport کے درمیان سب سے صاف separation ہے۔ ماڈل کو 2-million-element matrix کو دوسرے tool تک pass کرنے کے لیے اسے “دیکھنے” کی ضرورت نہیں۔ اسے یہ جاننے کی ضرورت ہے کہ matrix موجود ہے، یہ کیا represent کرتی ہے، اور اگلا کون سا operation اسے consume کرے گا۔

یہی logic scientific arrays سے آگے بھی لاگو ہوتی ہے۔ Large JSON responses، PDFs، logs، embeddings، media files اور database exports اکثر storage میں belong کرتے ہیں، prompt میں نہیں۔ MCP tools یا custom API connectors کے گرد بنے systems کے لیے pointer passing پہلی سطح کا design choice ہونا چاہیے، پہلے overflow کے بعد patch نہیں۔

200K-token context window اس وقت تک بڑی لگتی ہے جب تک agent عمل شروع نہ کرے۔ ایک system prompt، tool definitions، چند retrieved documents، file reads، logs، error traces اور summaries اسے توقع سے زیادہ تیزی سے consume کر سکتے ہیں۔ عملی frame یہ نہیں کہ paper پر window کتنی بڑی دکھتی ہے، بلکہ یہ ہے کہ agents runtime پر اسے کتنی تیزی سے spend کرتے ہیں۔ Redis کی agent-memory guidance ایسی state کے لیے external، durable memory کی طرف اشارہ کرتی ہے جو calls کے across survive کرنی چاہیے، جبکہ Atlan کی context-engineering framing بہتر prompts کو بہتر context assembly سے الگ کرتی ہے۔ مل کر، یہ context window کو warehouse کم اور constrained working set زیادہ سمجھتے ہیں۔

گہرا سبق یہ ہے کہ context window ایک scarce runtime resource ہے۔ اسے “memory” سمجھنا مددگار ہے، مگر صرف اس صورت میں جب ہارنس operating system کی طرح behave کرے: allocate، evict، page، compact، deduplicate اور persist۔ Atlan کا layer distinction یہاں مفید ہے۔ Prompt engineering ایسے file reader کو fix نہیں کر سکتی جو next call میں 80,000 irrelevant tokens dump کر دے۔ Context engineering working set کو بہتر بنا سکتی ہے۔ Harness engineering فیصلہ کرتی ہے کہ آیا وہ working set شروع ہی سے protected ہے یا نہیں۔

یہ teams کے agents evaluate کرنے کے طریقے کو بھی بدلتا ہے۔ demo prompt کافی نہیں۔ Long-horizon evaluation میں growing transcripts، repeated file reads، large tool outputs، failed tool calls، compaction کے بعد resumptions، اور ایسے tasks شامل ہونے چاہئیں جہاں correct next step کا انحصار early constraint پر ہو۔ ایجنٹس کے لیے کانٹیکسٹ انجینئرنگ پر ہماری guide اس problem کے model-side version کو cover کرتی ہے؛ harness layer وہ جگہ ہے جہاں یہ operational بنتا ہے۔

First، ہر context source پر budgets لگائیں۔ Files، tool outputs، retrieved chunks، memory inserts اور conversation history، ہر ایک کے explicit limits ہونے چاہئیں۔ ایک single global max token count بہت blunt ہے۔

Second، truncation کو actionable بنائیں۔ اگر ہارنس content کاٹتا ہے، تو ماڈل کو معلوم ہونا چاہیے کہ اس نے کون سی range دیکھی اور مزید کیسے request کرنا ہے۔ Silent truncation rejection سے بھی worse ہے کیونکہ یہ missing data پر confident work بناتا ہے۔

Third، prose کے بجائے state کے گرد compact کریں۔ Summaries کو user کا goal، constraints، decisions، pending tasks، touched files، relevant tool results اور immediate next step محفوظ رکھنے چاہئیں۔ Tool-call pairs intact رہنے چاہئیں۔

Fourth، large values کو prompt سے باہر لے جائیں۔ انہیں store کریں، نام دیں، اور tools کے ذریعے pointers pass کریں۔ یہ ان agents کے لیے خاص طور پر important ہے جو APIs call کرتے ہیں، documents process کرتے ہیں، یا multi-agent systems coordinate کرتے ہیں۔

Finally، goal loss کو overflow سے الگ test کریں۔ کوئی agent hard window کے اندر رہتے ہوئے بھی drift کر سکتا ہے۔ درست سوال صرف یہ نہیں کہ “کیا API نے prompt accept کیا؟” بلکہ یہ ہے کہ “کیا next action اب بھی original task کی خدمت کرتا ہے؟”

نیچے دیا گیا خلاصہ FAQ سے پہلے ان patterns کو ایک quick checklist میں بدلتا ہے۔

• Long-horizon agents context overflow اور goal loss دونوں کے ذریعے fail ہوتے ہیں، اس لیے ہارنس کو prompt length سے زیادہ manage کرنا چاہیے۔
• Production agent systems raw data کے model تک پہنچنے سے پہلے files، tool outputs اور history پر hard budgets استعمال کرتے ہیں۔
• Pagination، search اور managed views context کو permanent storage کے بجائے limited viewport سمجھتے ہیں۔
• Compaction checkpointing کے طور پر best کام کرتی ہے: یہ goals، constraints، decisions، pending work اور tool-call integrity کو محفوظ رکھتی ہے۔
• Large tool outputs اکثر external storage میں belong کرتے ہیں، جہاں tools کے درمیان full values کے بجائے short pointers pass کیے جاتے ہیں۔

یہ section long-horizon agents کے لیے context engineering کے پیچھے practical questions کے جواب دیتا ہے: کیا overflow ہوتا ہے، goals کیسے lost ہوتے ہیں، اور کون سے harness patterns کام کو track پر رکھتے ہیں۔

Context overflow تب ہوتا ہے جب agent کا accumulated prompt، history، retrieved data، files اور tool outputs ماڈل کی usable context window سے بڑھ جائیں یا hard limit تک پہنچنے سے پہلے quality degrade کر دیں۔

Goal loss تب ہوتا ہے جب original task transcript میں کہیں نہ کہیں اب بھی موجود ہو مگر agent کے next action کو guide نہ کرے، اکثر long histories یا poor summarization کے بعد۔

وہ per-source budgets set کرتے ہیں، file reads paginate کرتے ہیں، صرف relevant views retrieve کرتے ہیں، state کے گرد history compact کرتے ہیں، repeated reads deduplicate کرتے ہیں اور large outputs کو prompt سے باہر store کرتے ہیں۔

Pointers ماڈل کو runtime memory میں stored large values، جیسے matrices، logs یا PDFs، کا reference دینے دیتے ہیں، جبکہ downstream tools full data کو context window میں رکھے بغیر resolve کرتے ہیں۔

نہیں۔ Larger windows مدد کرتی ہیں، مگر system prompts، tool definitions، retrieved documents، logs اور history اب بھی space کے لیے compete کرتے ہیں، اور hard limit hit ہونے سے پہلے relevant information bury ہو سکتی ہے۔