Context Engineering: आपका agent turn 40 पर धीमा क्यों पड़ जाता है

Anthropic ने September 2025 में रेखा खींची और ये दो वाक्य साथ-साथ रखे जाने चाहिए। Prompt engineering “optimal outcomes के लिए LLM instructions लिखने और व्यवस्थित करने के methods” है। Context engineering “LLM inference के दौरान tokens (information) के optimal set को curate और maintain करने की strategies का set है, जिसमें prompts के बाहर से वहाँ पहुँच सकने वाली सारी दूसरी information भी शामिल है।”¹

काम का फर्क है कब, और किसके द्वारा। Prompt एक बार, एक व्यक्ति द्वारा author किया जाता है और review होता है। Context हर call पर ऐसे code द्वारा assemble होता है जिसे कोई देख नहीं रहा, ऐसी material से जिसे किसी ने हाथ से नहीं लिखा: history के चालीस turns, छह tool results, चार retrieved passages, user profile, बारह JSON schemas। Chapter 15 ने मापा कि बेहतर instructions क्या खरीदते हैं। यह chapter उन बाकी नब्बे प्रतिशत tokens के बारे में है, जो अपने-आप आ जाते हैं।

वही document उस resource का नाम देता है जिसे ये सब खर्च करते हैं: models के पास “attention budget” होता है जिससे वे context के बड़े volumes parse करते समय draw करते हैं। “हर नया token introduced होने पर यह budget कुछ मात्रा में घटता है।” और यह symptom का नाम देता है: “जैसे-जैसे context window में tokens की संख्या बढ़ती है, उस context से information को accurate रूप से recall करने की model की क्षमता घटती है” — context rot.¹

वह आखिरी वाक्य behaviour के बारे में claim है, जिसका मतलब है कि उसे check किया जा सकता है, और इस page के top की table वही check है।

Chapter 22 के local endpoint पर चालीस lines — एक छोटा Python server जो CPU पर Qwen2.5-0.5B-Instruct रखता है और chat-completions shape में बात करता है, ताकि loop TypeScript में रहे और tensors port के उस पार रहें।

const DEPTHS = [0, 0.125, 0.25, 0.375, 0.5, 0.625, 0.75, 0.875, 1];

for (const d of DEPTHS) {
  const slot = Math.round(d * (N - 1));
  let hits = 0, other = 0;
  for (let t = 0; t < TRIALS; t++) {
    const recs = buildRecords(N, 1000 + t);          // 25 unique tickets
    const gold = recs[Math.floor(rng(7 + t)() * N)]; // a different one each trial
    const rest = recs.filter((x) => x.ticket !== gold.ticket).slice(0, N - 1);
    const lines = [...rest.slice(0, slot).map((x) => x.line),   
                   gold.line,                                   
                   ...rest.slice(slot).map((x) => x.line)];     
    const r = await complete(prompt(lines, ask(gold.owner)), { maxTokens: 12 });
    const said = /\d{4}/.exec(r.text)?.[0];
    if (said === String(gold.ext)) hits++;
    else if (said && recs.some((x) => String(x.ext) === said)) other++;
  }
}

other counter ही disappointing result को useful बनाता है: जब model गलत है, तो क्या वह खो गया है या confident है?

Answer confident है। आठ non-first positions में, 205 wrong answers में से 136 किसी दूसरे ticket के extension थे — एक असली four-digit number, सही format में, गलत line से पढ़ा हुआ। Slot 1 पर पाँच misses में से केवल एक ऐसा था; slot 7 पर, छब्बीस में से इक्कीस।

Production में यही distinction मायने रखता है। जो model कहता है मुझे यह नहीं मिल रहा वह bug है जिसे आप notice करते हैं; जो model पड़ोसी row का number लौटाता है वह bug है जिसे आप ship कर देते हैं, क्योंकि screen पर दोनों समान दिखते हैं। यह वही failure है जिसके खिलाफ Chapter 19 ने verifiable citations बनाए थे, बस index के बजाय prompt के अंदर से आ रही है।

Position एक axis है। Length दूसरी है, और test करना आसान है: answer को middle में रखें और list बढ़ाएँ।

एक record और 97 tokens: 90 %। तीन records और 159 tokens: 55 %। आठ records और 315 tokens: 15 %, और वहाँ से 140 records और 4,477 tokens तक सपाट और low। पूरा collapse list की पहली और आठवीं line के बीच होता है।

आखिरी column वह सब है जो न सही extension है न किसी दूसरे record का, और page पर single record होने पर wrong answer के उतरने की बस वही जगह है। एक record पर दो misses को round away करने के बजाय report करना जरूरी है, क्योंकि उनमें से कोई refusal नहीं था: एक ने 5805 लिखी एकमात्र line वाले register को 5806 answer किया। 97 tokens पर single candidate के साथ भी यह model बीस में दो बार digit गलत copy करता है, और यही floor है जिसके खिलाफ बाकी सब मापा जाता है।

दो बातें निकलती हैं। बड़ा context ज्यादा भेजने का अधिकार खरीदता है, पढ़े जाने की certainty नहीं: इस model के पास 32,768-token window है और इस task पर working range कुछ सौ tokens की है। और कोई threshold नहीं, कोई cliff नहीं, कोई “context full” state नहीं — degradation तीसरे record पर चल रही है और आठवें तक complete है, window के एक प्रतिशत पर। Context limit चाहे जो हो, इसे govern वह नहीं करती।

आमतौर पर दो mechanisms दिए जाते हैं। पहला Chapter 9 का arithmetic है, जिसे Anthropic इसी course जैसी terms में कहता है: models “transformer architecture पर आधारित हैं, जो हर token को पूरे context में हर दूसरे token पर attend करने देता है। इससे n tokens के लिए n² pairwise relationships बनते हैं।”¹ Longer sequence पर attention, ज्यादा material पर लागू वही operation नहीं है; यह probability mass का एक fixed budget है जो ज्यादा competitors में फैलता है। दूसरा training है: models long sequences की तुलना में बहुत ज्यादा short sequences देखते हैं, इसलिए long-range positional patterns network का सबसे कम practiced हिस्सा हैं। यह argument है, measurement नहीं, और यह chapter इसे settle नहीं कर सकता।

जो settled है वह shape है, और 2023 से है। Liu et al. ने model families और sizes में multi-document question answering और key-value retrieval test किया और पाया कि “performance अक्सर तब highest होती है जब relevant information input context की शुरुआत या अंत में आती है, और जब models को लंबे contexts के middle में relevant information access करनी होती है तो significantly degrade होती है, explicitly long-context models के लिए भी।”² Chapter 15 ने अपना position rule उस paper से लिया; Chapter 19 ने उससे यह कारण लिया कि बीस retrieved chunks चार से खराब score कर सकते हैं। इस fact का practical form यहाँ की केवल वही sentence है जिस पर आपको act करना चाहिए: अपने model और अपने data पर इसे मापने में पाँच मिनट लगते हैं, और कोई published curve आपकी curve की जगह नहीं लेती।

किसी team से पूछिए कि उनके agent का context क्या भरता है और आपको estimate मिलता है, क्योंकि कोई API answer नहीं लौटाती: response आपको prompt_tokens देता है, सबके लिए एक number।

Breakdown आप चार counts और तीन subtractions से recover कर सकते हैं — पूरा rendered prompt, वही बिना tool definitions, system message अकेला उनके साथ और बिना, और सब कुछ tool results हटाकर:

async function buckets(messages: Msg[]) {
  const sys = messages.slice(0, 1);
  const withoutResults = messages.filter((m) => m.role !== "tool");
  const [total, sysWithTools, sysNoTools, noResults] = await Promise.all([
    countPrompt(messages, CATALOGUE),        // everything
    countPrompt(sys, CATALOGUE),             // system + scaffolding + schemas
    countPrompt(sys),                        // system + scaffolding
    countPrompt(withoutResults, CATALOGUE),  // everything but tool output
  ]);
  return {
    system: sysNoTools,
    tools: sysWithTools - sysNoTools,                                  
    toolResults: total - noResults,                                    
    conversation: total - sysWithTools - (total - noResults),          
    total,
  };
}

countPrompt tokenize करने से पहले model का अपना chat template apply करता है, जो जितना सुनाई देता है उससे ज्यादा मायने रखता है: आपका text वही नहीं है जो count होता है। Role markers, tool-calling preamble और schema rendering सब ऐसे tokens हैं जिनके लिए आप pay करते हैं और जिन्हें आपने type कभी नहीं किया। Chapter 7 ने tokenizer बनाया और Chapter 16 ने js-tiktoken से count किया; यहाँ count उसी model से आता है जो prompt पढ़ेगा, और वही count बिल्कुल सही है।

अब इससे एक real agent चलाएँ: incident investigation के चालीस turns, बारह tools, realistic log dumps और metric series लौटाने वाला fake operations environment।

पहली row को आखिरी के मुकाबले पढ़िए।

Turn 1 पर prompt 2,547 tokens है और उसका 71 % tool definitions है। System prompt 3 % है। User ने जो type किया वह 6 % है। Agent ने अभी कुछ किया भी नहीं और पहले से 1,817 tokens का JSON schema ढो रहा है।

Turn 40 तक prompt 10,632 tokens है और shares उलट गए हैं: definitions 17 %, conversation 29 %, tool results 53 %। Tool output ने turn 5 पर definitions को पीछे छोड़ दिया; conversation ने उन्हें turn 25 तक पीछे नहीं छोड़ा, इसलिए session के पहले साठ प्रतिशत में tool catalogue कही गई हर चीज़ से बड़ा था।

फिर total। 57 model calls में run ने 10,632 के final context के लिए 370,291 input tokens bill किए — आखिरी prompt के लिए लगभग पैंतीस गुना pay किया गया, जो Chapter 16 का quadratic है और ऊपर से agent का multiplier। उन 370,291 में से 103,569, यानी billed सबका 28 %, बारह tool definitions थे, हर call पर byte-identical फिर से भेजे गए।

Tool catalogue agent की सबसे बड़ी fixed cost है और invisible है, क्योंकि आप उसे कभी देखते नहीं: आप objects की array pass करते हैं और provider उसे आपके लिए prompt में render करता है। उन्हीं बारह tools पर मापा गया:

system prompt + chat scaffolding, no tools:        85 tokens
all twelve definitions:                          1,817 tokens
  of which fixed tool-calling scaffolding:         126 tokens
three tools instead of twelve:                     605 tokens
same twelve, one-sentence descriptions,
  no parameter prose:                            1,291 tokens  (-29 %)

Per tool marginal cost get_current_time के लिए 80 tokens से चलती है, जो एक string लेता है, से search_tickets के लिए 263 तक, जो enum और हर एक के लिए guidance की sentence वाले चार parameters लेता है। यही exchange rate Chapter 18 की central advice के पीछे है कि description ही API है: अच्छी description agent की बाकी life में हर request पर लगभग सौ tokens cost करती है। तीन consequences।

जिस tool का आप उपयोग नहीं करते, वह भी bill करता है। Agent ने बारह में से सात call किए। बाकी पाँच ने 57 requests में हर एक पर 697 tokens cost किए — कुल 39,729, run पर billed सबके दसवें हिस्से से ज्यादा, उन capabilities के लिए जिन्हें उसने कभी छुआ नहीं। पाँच में से एक trace की सबसे तेज detail रखता है: model ने तीन बार read_log call करने की कोशिश की, जो exist नहीं करता। उसे जो tool चाहिए था वह search_logs था, catalogue में second most expensive definition, 237 tokens पर। उसने उस definition के लिए 57 बार pay किया, उसे कभी use नहीं किया, और उसका नाम कभी नहीं पाया।

Prose trim करना सबसे सस्ता optimisation है, और यह trade है। Descriptions को एक sentence तक काटने और parameter documentation drop करने से per call 526 tokens, 29 per cent, बच गए, logic की एक line छुए बिना — और model ने tools worse call किए, जैसा Chapter 18 ने मापा। Point यह है कि उस trade के दोनों sides अब same unit में हैं।

किसी scale पर definitions भेजना ही sensible नहीं रहता। Anthropic ने November 2025 में इस पर number रखा: connected servers के large set का मतलब request पढ़े जाने से पहले definitions के “hundreds of thousands of tokens” process करना है, और इसे code execution से replace करना — agent केवल जरूरत की definitions discover और load करे — “token usage को 150,000 tokens से 2,000 tokens तक घटाता है, time और cost में 98.7% saving।”³ वही idea जो इस chapter के बाकी हिस्से में है, history के बजाय schemas पर लागू: index रखें, entry को demand पर resolve करें।

उस forty-turn transcript में दो चीजें plant की गई थीं। Turn 2 पर, किसी real work से पहले, user एक standing rule बताता है: आप जो भी ticket open करें, वह मेरे employee number, 4417, के तहत file होना चाहिए। Turn 19 पर, incident के बीच, एक fact: affected shard pay-shard-7 है, payments team ने confirm किया है। Turn 40 पर user agent से incident ticket open करने को कहता है, जिसके लिए दोनों चाहिए। हर probe छह अलग phrasings में पूछा जाता है और छह में score होता है — greedy decoding deterministic है, इसलिए एक call unrepeatable yes या no देता है और छह rate देते हैं।

Transcript को फिर सात context policies के तहत replay किया जाता है। जानबूझकर replay, re-run नहीं: messages, tool calls और tool results सातों में byte-identical हैं, इसलिए केवल variable है हर policy ने क्या keep करना चुना। Chapter 16 ने दिखाया कि sliding window खराब economic move क्यों है, क्योंकि यह cacheable prefix destroy करती है। Behaviour के साथ यह क्या करती है:

Compaction rows में compacting की cost शामिल है: सात summaries के लिए 18,581 input tokens और note-taker के लिए 3,392 और। Control row इसलिए है ताकि zero को zero की तरह पढ़ा जा सके — केवल दो messages के साथ 1,981-token prompt में यह model दोनों probes perfectly answer करता है, इसलिए कोई row task के बहुत hard होने की नहीं है।

Full history याद रखती है, और table की सबसे महंगी चीज़ है: 370,291 input tokens उस session के लिए जिसकी durable content दो sentences है।

यह opening द्वारा खुला छोड़े गए सवाल का answer देता है। 10,632-token transcript एक fact क्यों hold करता है जिसे 853-token register खो देता है? क्योंकि length गलत variable है। Register में पच्चीस identical sentences में पच्चीस four-digit extensions हैं — आप जिसे चाहते हैं उसके लिए चौबीस लगभग perfect decoys। Transcript में ठीक एक employee number और एक shard name है। Context rot volume से पहले interference है, इसलिए ऊपर 205 wrong answers में से 136 neighbour की value थे। Window के बारे में useful सवाल यह नहीं कि वह कितनी लंबी है; यह है कि उसमें कितनी चीजें answer जैसी दिखती हैं।

Sliding window 57 % सस्ती है और incident खो चुकी है। Employee number केवल इसलिए बचता है क्योंकि agent ने उसे recent turns में repeat किया था। Shard, जो turn 19 पर एक बार stated था, आखिरी बारह messages में नहीं है — और model ऐसा कहता नहीं। छह बार पूछने पर उसने “affected payment shard shard 4417 है” answer किया, employee number की ओर हाथ बढ़ाते हुए, जो उसकी window में बचा एकमात्र दूसरा identifier था, और दो बार “pool”, जो log line की string pool_exhausted से उठाया गया था।

Compaction cheap है और वही fact खो गई। सात summaries, model द्वारा इस explicit instruction के तहत लिखी गईं कि identifiers, numbers, standing instructions और open questions keep करें, और relevant summaries में pay-shard-7 कहीं नहीं है; छह guesses थे shard 1, pay_shard_1 और pool। Compaction loudly fail नहीं करती। यह fluent, plausible, बहुत shorter session बनाती है जिसने चुपचाप एक line drop कर दी है।

तीन rows ने turn-19 fact पर 0/6 score किया — sliding window, compaction, और notes वाली compaction। उनके बीच अठारह wrong answers, और उनमें से एक भी “मुझे नहीं पता” नहीं था।

फिर वह row जो शर्मनाक होनी चाहिए। User के अपने चालीस messages verbatim रखना, plus आखिरी चार turns full और कुछ नहीं, 168,550 tokens cost करता है — full history से 54 % कम — और दोनों probes को full history जितना या बेहतर answer करता है। कोई summariser नहीं, कोई note-taker नहीं, कोई second model नहीं: role === "user" पर filter। User के शब्द agent की window में सबसे सस्ते high-value tokens हैं, और ज्यादातर designs उन्हें बाकी सबके साथ discard कर देते हैं।

आखिरी दो rows फिर वही opening table हैं, agent के अंदर। वही pinned block, system message से prompt के end पर moved: 5/6 6/6 हो जाता है। छह trials पर यह significant difference नहीं है और ऐसा offer भी नहीं किया गया — इसे बस reminder के रूप में offer किया गया है कि where एक parameter है जिसे आप set कर रहे हैं, चाहे आपको पता हो या नहीं।

नीचे की चार strategies Anthropic की हैं, उसी क्रम में, हालांकि केवल आखिरी तीन उसकी long-horizon list हैं।¹ चारों एक instruction की variations हैं: जिसे fetch कर सकते हैं उसे carry न करें, और जिसे compressed carry कर सकते हैं उसे raw carry न करें।

const elide: Policy = (h) => [SYSTEM, ...h.flatMap((turn, ti) =>
  turn.map((m) => (ti < h.length - 4 && m.role === "tool"
    ? { role: "tool", name: m.name,
        content: `[${m.name} result from turn ${ti + 1}, ${m.content.length} chars, ` +
                 `elided; call ${m.name} again with the same arguments to re-read it]` }
    : m)))];

const r = await complete([
  { role: "system", content:
      "You keep a durable note file for a support session. Given one user message, " +
      "output one short note ONLY if it states a standing rule, an identifier or a fact " +
      "that must survive the rest of the session. Otherwise output exactly NONE." },
  { role: "user", content: `Turn ${i + 1}: ${user}` },
], { maxTokens: 40 });
if (!/^none\b/i.test(r.text.trim())) notes.push(`turn ${i + 1}: ${r.text.trim()}`);

Sub-agent ऊपर की table में नहीं है क्योंकि वह चालीस turns नहीं चलता: वह एक बार चलता है, ऐसी window में जिसे किसी ने उसके लिए scope किया है। System prompt, turns 17 to 19 और कुछ नहीं — 2,737 tokens — दिए जाने पर उसने shard probe 6/6 answer किया, table की हर policy से बेहतर, और employee probe 0/6, क्योंकि वह number उसे दिए गए तीन turns में नहीं है।

दो numbers में sub-agents यही हैं: clean window intelligence नहीं है, scope है, और scoping पहले से ऐसे code द्वारा की जाती है जिसे पहले ही पता होना चाहिए कि कौन-से turns matter करते हैं। उन answers में एक और चीज़ रखने लायक है। यही अकेली policy थी जिसने कुछ invent करने के बजाय “None available” reply किया। Small, coherent context वाला model जानता है कि वह क्या missing है; large, noisy context वाला model नहीं जानता।

Agent memory के बारे में लगभग हर confused conversation एक शब्द पहने तीन mechanisms है। उनके lifetimes, owners और failure modes अलग हैं, और जो system उन्हें same place में रखता है उसके पास एक ऐसी problem है जिसे उसने अभी notice नहीं किया।

Academic framing CoALA की है, जो language agents को “modular memory components” के around organise करता है और working memory को episodic, semantic और procedural stores से अलग करता है।⁴ MemGPT उसी idea को literal लेता है, operating systems से virtual memory borrow करते हुए: window के अंदर fast tier, उसके बाहर slow tier, और model खुद function calls से data को उनके बीच move करता है।⁵ दोनों वही सवाल force करते हैं जिसका answer product को वैसे भी देना है — मैं कितना keep कर सकता हूँ नहीं, बल्कि यह किस store में belong करता है, और यह कब expire होता है।

Practical test हर fact के लिए एक सवाल है: कल भी क्या true रहना चाहिए? Turn 12 का tool result, कुछ नहीं। Session की summary, session खत्म होने तक। User का employee number 4417 है, जब तक वे job change न करें। तीन answers, तीन stores।

अब आप measure कर सकते हैं कि window में क्या है, decide कर सकते हैं कि उसमें क्या रहे, और उस agent के बीच फर्क बता सकते हैं जिसने कुछ भूल गया और वह जो उसे carry कर रहा था लेकिन उसने देखा नहीं।

चार strategies में आखिरी यहाँ fit नहीं होती। Sub-agent context policy नहीं है, यह दूसरा agent है, और जैसे ही दो होते हैं आपको decide करना पड़ता है कि उनके बीच क्या pass होता है और charge में कौन है। Chapter 25 वही है: पाँच orchestration patterns और उनके नाम असल में कहाँ से आते हैं, वे दो topologies जो mix up होती हैं — sub-agent से पूछना और answer वापस लेना, बनाम उसे conversation hand करना और वापस न लेना — और measured finding कि जिस task को यह price करता है उस पर simpler arrangement जीतता है — उसके बाद test कि वह कब जीतना बंद करता है।

यह ठीक वही inherit भी करता है जो इस chapter ने अभी measure किया। Sub-agent summary लौटाता है। Summary compaction है जिसे आपने लिखा नहीं, ऐसे model द्वारा produced जिसकी window आप नहीं देख सकते, और parent के पास good one और confident wrong one में फर्क बताने का कोई तरीका नहीं — वही distinction जिसने इस page के top पर 84 % को 19 % से अलग किया, और जिसने अठारह missing facts को अठारह invented ones में बदल दिया। इसलिए: जब sub-agent गलत होता है, parent को आखिर देखने को मिलता क्या है?

यहाँ हर number इसी machine पर produced हुआ और कोई estimate नहीं किया गया। Model CPU पर float32 में Qwen2.5-0.5B-Instruct है, greedy decoding के साथ, loopback पर एक छोटे Python endpoint से served जो chat-completions shape बोलता है और token-count route expose करता है — Chapter 14 की seam फिर से, tensors Python side पर और loop TypeScript side पर — इसलिए हर count उस model का अपना tokenizer है जो अपने chat template पर applied है। Position table 288 calls है, नौ positions by बत्तीस trials, हर trial में अलग ticket; length table 140 calls है; agent run wall clock के 43 minutes में 57 model calls है; policy table वही एक transcript है जिसे सात policies के तहत replay किया गया। Intervals Wilson के हैं, Chapter 4 से। कोई paid API call नहीं हुई, इसलिए chapter में एक भी price नहीं है: token counts exact हैं और वे rates जिनसे आप उन्हें multiply करेंगे, Chapter 16 के हैं।