लॉन्ग-होराइजन AI एजेंट्स के लिए कॉन्टेक्स्ट इंजीनियरिंग

कुल मिलाकर, Arize का विश्लेषण, कॉन्टेक्स्ट विंडो ओवरफ़्लो पर arXiv पेपर, Redis का प्रोडक्शन explainer, और Atlan की हॉर्नेस-इंजीनियरिंग तुलना एजेंट डिज़ाइन में एक व्यावहारिक बदलाव की ओर इशारा करते हैं। लंबे समय तक चलने वाले एजेंट्स को अब मॉडल की context window के आकार से कम और उसके आसपास की control layer से ज़्यादा आंका जा रहा है। Arize इस बदलाव को ठोस बनाता है। यह Pi, OpenClaw, Claude Code और Letta सहित shipped agent tools और memory/harness systems को harness-level context engineering के उदाहरणों के रूप में नामित करता है, और एक interactive simulator का वर्णन करता है जो 200K-token window को भरते हुए दिखाता है।

उद्धृत स्रोतों में उपलब्ध सार्वजनिक विवरण असमान हैं। Arize Pi, OpenClaw, Claude Code और Letta के लिए ठोस implementation numbers देता है। AI एजेंट्स में कॉन्टेक्स्ट विंडो ओवरफ़्लो हल करने पर एक research paper ऐसे tool outputs को संभालने के लिए अधिक सामान्य mechanism देता है जो किसी भी व्यावहारिक window से बड़े हो सकते हैं। Redis का कॉन्टेक्स्ट विंडो ओवरफ़्लो पर explainer production symptoms का सार देता है: hard API errors, silent quality degradation, tool output accumulation, और prompts बढ़ने पर longer latency। Atlan की prompt, context और harness engineering की तुलना उपयोगी stack metaphor देती है: prompt engineering message को आकार देती है, context engineering यह आकार देती है कि model क्या देखता है, और harness engineering पूरे agent environment को आकार देती है।

महत्वपूर्ण खबर यह नहीं है कि context windows बहुत छोटी हैं। Builders यह पहले से जानते हैं। अधिक उपयोगी बात यह है कि उद्धृत agent systems चार harness mechanisms पर converge कर रहे हैं, जो transcript के safe source of truth न रहने के बाद भी काम को ज़िंदा रखते हैं।

एक shallow agent फ़ाइलें पढ़ता है, tools call करता है, result append करता है, और उम्मीद करता है कि model संभाल लेगा। Harness-first agent बड़े inputs को model तक पहुँचने से पहले block या reshape करता है।

limits के पहले set को पढ़ने का साफ़ तरीका यह है:

• Pi: file reads 2,000 lines या 50KB पर रुक जाते हैं, जो भी पहले आए। लौटाए गए content में एक continuation hint शामिल होता है, जो model को बताता है कि कौन-सी line range दिखाई गई और offset और limit के साथ कैसे जारी रखना है। OpenClaw यह behavior inherit करता है, फिर अलग caps जोड़ता है: bootstrap files प्रति file 12,000 characters और कुल 60,000 characters तक सीमित हैं। Tool results को 16,000 characters या context window के 30% का एक और budget मिलता है, जो भी छोटा हो।

Claude Code दो-gate design का उपयोग करता है। Arize के अनुसार, यह file खोलने से पहले 256KB byte cap check करता है, फिर read के बाद result को 25,000-token budget के विरुद्ध token-count करता है। Cap के अंदर की files के लिए भी, यह default रूप से शुरुआत से 2,000 lines लौटाता है, और 2,000 characters से लंबी lines को truncate करता है। यदि model वही file range दोबारा पढ़ता है और file बदली नहीं है, तो Claude Code full content दोहराने के बजाय stub लौटा सकता है।

यह सिर्फ optimization नहीं है। यह failure mode बदल देता है। एक बड़े read को task को crowd out करने देने के बजाय, harness “सब कुछ पढ़ो” को “एक controlled slice पढ़ो” में बदल देता है। अगर model को और चाहिए, तो वह मांग सकता है। शुरुआत से agent harnesses design कर रहे builders के लिए यह defense की पहली line है: raw external data को default रूप से transcript कभी न बनने दें।

अगला pattern यह है कि context को storage नहीं, viewport की तरह treat किया जाए।

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 के बाहर रखकर और आगे जाता है। Uploaded files parse, chunk और vector store में embed की जाती हैं, जिससे agent को 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 करती है, small models के लिए 3 से लेकर बहुत बड़े models के लिए 15 तक, जहाँ LRU policy least recently accessed files को evict करती है।

Production RAG के पीछे भी यही design idea है: पूरे corpus को prompt में न भरें; वह हिस्सा retrieve करें जो मायने रखता है। फर्क यह है कि agent harnesses को यह लगातार करना पड़ता है — files, tool outputs, memory और intermediate plans के across। वही constraint RAG systems पर भी लागू होती है: retrieval सिर्फ relevance के बारे में नहीं है, बल्कि actual reasoning step के लिए पर्याप्त context budget बचाए रखने के बारे में भी है।

Redis एक संबंधित बात करता है: bigger 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 ज़्यादा शांत होता है। Agent के पास respond करने की जगह अभी भी होती है, लेकिन वह original objective भूल जाता है, कोई constraint miss कर देता है, या local subtask को optimize करना शुरू कर देता है।

यहीं compaction मायने रखता है। खराब तरीके से किया गया summarization messy लेकिन faithful history को neat लेकिन lossy story से replace कर देता है। अच्छे तरीके से किया गया compaction task state, recent work, pending items और tool-call integrity को preserve करता है।

Arize report करता है कि Pi compaction तब trigger करता है जब estimated context tokens, context window minus reserve tokens से अधिक हो जाते हैं, जहाँ default reserve 16,384 tokens है। यह सबसे recent लगभग 20,000 tokens रखता है और पुराने content को kept tail से पहले prepended synthetic user message में summarize करता है। यह tool-call/tool-result pairs के बीच cut करने से भी बचता है।

OpenClaw एक अधिक aggressive history policy जोड़ता है। जब history context window के 50% से अधिक हो जाती है, तो यह messages को equal-mass token chunks में split करता है, oldest chunk drop करता है, dropped content को staged multi-pass summarization से summarize करता है, और tool-call/result pairing repair करता है। यह pre-compaction flush भी करता है: एक silent agentic turn agent को history गायब होने से पहले state को memory files में persist करने का मौका देता है। अलग से, यह 5-minute cache TTL पर soft-trim और hard-clear behavior के साथ memory में tool results prune करता है।

Claude Code window के अंत के करीब compact करता है। Arize कहता है कि इसका trigger effective context window minus 13,000-token buffer है, जो 200K-context model के लिए compaction को करीब 167K tokens पर रखता है। इसका summarization prompt primary request, technical concepts, files और code, errors और fixes, problem solving, user messages, pending tasks, current work और next step को cover करने वाले structured sections मांगता है। Compaction के बाद, यह token budget के भीतर up to 5 recently read files reattach कर सकता है।

Pattern साफ़ है: compaction “chat को summarize” करना नहीं है। यह checkpointing है। एक long-running agent को save file के equivalent की ज़रूरत होती है: goal, constraints, decisions, open handles, recent evidence और next action।

कुछ outputs को context window में कभी रखा ही नहीं जाना चाहिए।

arXiv paper इसे materials-science workflow के साथ ठोस बनाता है। एक tool molecule के लिए electronic grid structure generate करता है: 128 × 128 × 128 dimensions वाली 3D matrix, कुल 2,097,152 float32 elements। यह output widely used LLMs की context window से कहीं अधिक है। लेकिन अगले tool को input के रूप में grid चाहिए।

Proposed solution यह है कि 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 कर सकते हैं। Model references manipulate करता है, जबकि harness complete data preserve करता है। Paper के अनुसार, एक comparative experiment में जहाँ दोनों methods सफल रहे, pointer-based approach ने traditional workflow की तुलना में लगभग सात गुना fewer tokens इस्तेमाल किए।

यह reasoning और data transport के बीच सबसे साफ़ separation है। Model को 2-million-element matrix को दूसरे tool को pass करने के लिए उसे “देखने” की ज़रूरत नहीं है। उसे यह जानना होता है कि matrix मौजूद है, वह क्या represent करती है, और अगला कौन-सा operation उसे consume करे।

यही logic scientific arrays से आगे भी लागू होता है। Large JSON responses, PDFs, logs, embeddings, media files और database exports अक्सर prompt में नहीं, storage में होने चाहिए। MCP tools या custom API connectors के आसपास बने systems के लिए, pointer passing first-class design choice होना चाहिए, पहले overflow के बाद का patch नहीं।

200K-token context window तब तक बड़ी लगती है जब तक agent act करना शुरू नहीं करता। एक system prompt, tool definitions, कुछ retrieved documents, file reads, logs, error traces और summaries इसे उम्मीद से तेज़ consume कर सकते हैं। Practical frame यह नहीं है कि window paper पर कितनी बड़ी दिखती है, बल्कि यह है कि agents runtime पर इसे कितनी तेज़ी से spend करते हैं। Redis की agent-memory guidance ऐसी state के लिए external, durable memory की ओर इशारा करती है जिसे calls के across survive करना चाहिए, जबकि Atlan की context-engineering framing better prompts को better context assembly से अलग करती है। साथ मिलकर, वे context window को warehouse की तरह कम और constrained working set की तरह ज़्यादा treat करते हैं।

गहरी सीख यह है कि context window एक scarce runtime resource है। इसे “memory” मानना helpful है, लेकिन केवल तभी जब harness operating system की तरह behave करे: allocate, evict, page, compact, deduplicate और persist। Atlan का layer distinction यहाँ उपयोगी है। Prompt engineering उस file reader को ठीक नहीं कर सकती जो next call में 80,000 irrelevant tokens dump कर देता है। Context engineering working set को improve कर सकती है। 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 शामिल होने चाहिए जहाँ सही next step किसी early constraint पर निर्भर करता हो। एजेंट्स के लिए कॉन्टेक्स्ट इंजीनियरिंग पर हमारी guide उस समस्या के model-side version को cover करती है; harness layer वह जगह है जहाँ यह operational बनती है।

पहले, हर context source पर budgets लगाएँ। Files, tool outputs, retrieved chunks, memory inserts और conversation history — हर एक की explicit limits होनी चाहिए। एक single global max token count बहुत blunt है।

दूसरे, truncation को actionable बनाएँ। अगर harness content काटता है, तो model को पता होना चाहिए कि उसने कौन-सी range देखी और और कैसे request करना है। Silent truncation rejection से भी बुरा है, क्योंकि यह missing data पर confident work बनाता है।

तीसरे, prose नहीं, state के आसपास compact करें। Summaries में user का goal, constraints, decisions, pending tasks, touched files, मायने रखने वाले tool results और immediate next step preserve होने चाहिए। Tool-call pairs intact रहने चाहिए।

चौथे, large values को prompt से बाहर ले जाएँ। उन्हें store करें, name दें, और tools के through pointers pass करें। यह उन agents के लिए खास तौर पर महत्वपूर्ण है जो APIs call करते हैं, documents process करते हैं, या multi-agent systems coordinate करते हैं।

अंत में, goal loss को overflow से अलग test करें। Agent hard window के अंदर रहकर भी drift कर सकता है। सही सवाल सिर्फ “क्या API ने prompt accept किया?” नहीं है। यह है: “क्या next action अभी भी original task को serve करता है?”

नीचे दिया गया summary FAQ से पहले इन patterns को quick checklist में बदलता है।

• Long-horizon agents context overflow और goal loss दोनों के कारण fail करते हैं, इसलिए harness को prompt length से ज़्यादा manage करना होता है।
• Production agent systems raw data के model तक पहुँचने से पहले files, tool outputs और history पर hard budgets लगाते हैं।
• Pagination, search और managed views context को permanent storage के बजाय limited viewport की तरह treat करते हैं।
• Compaction checkpointing के रूप में सबसे अच्छा काम करता है: यह goals, constraints, decisions, pending work और tool-call integrity को preserve करता है।
• Large tool outputs अक्सर prompt में full values के बजाय external storage में होने चाहिए, जहाँ tools के बीच short pointers pass किए जाएँ।

यह section long-horizon agents के लिए context engineering के पीछे के practical questions के जवाब देता है: क्या overflow होता है, goals कैसे खो जाते हैं, और कौन-से harness patterns काम को track पर रखते हैं।

Context overflow तब होता है जब agent का accumulated prompt, history, retrieved data, files और tool outputs model की 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 के around history compact करते हैं, repeated reads deduplicate करते हैं और large outputs को prompt के बाहर store करते हैं।

Pointers model को runtime memory में stored large values, जैसे matrices, logs या PDFs, को refer करने देते हैं, जबकि downstream tools full data को context window में रखे बिना resolve करते हैं।

नहीं। Larger windows मदद करती हैं, लेकिन system prompts, tool definitions, retrieved documents, logs और history फिर भी space के लिए compete करते हैं, और hard limit hit होने से पहले relevant information दब सकती है।