Context Engineering: آپ کا agent ٹرن 40 پر کم عقل کیوں ہو جاتا ہے

Anthropic نے September 2025 میں لکیر کھینچی، اور دونوں sentences ساتھ ساتھ رکھنے کے قابل ہیں۔ Prompt engineering "optimal outcomes کے لیے LLM instructions لکھنے اور organize کرنے کے methods" ہے۔ Context engineering "LLM inference کے دوران tokens (information) کے optimal set کو curate اور maintain کرنے کی strategies کا set ہے، جس میں prompts کے باہر سے وہاں آنے والی تمام دوسری information بھی شامل ہے"۔¹

عملی فرق کب اور کس کے ذریعے ہے۔ prompt ایک بار، ایک شخص کے ذریعے authored ہوتا ہے، اور review ہوتا ہے۔ context ہر call پر code کے ذریعے assemble ہوتا ہے جسے کوئی دیکھ نہیں رہا، ایسے material سے جسے کسی نے ہاتھ سے نہیں لکھا: history کے چالیس turns، چھ tool results، چار retrieved passages، user profile، بارہ JSON schemas۔ Chapter 15 نے measure کیا کہ بہتر instructions کیا خریدتی ہیں۔ یہ chapter باقی نوے فیصد tokens کے بارے میں ہے، جو خود بخود آتے ہیں۔

وہی document اس resource کا نام بھی لیتا ہے جو یہ سب خرچ کرتے ہیں: models کے پاس "attention budget" ہوتا ہے جس سے وہ context کی بڑی volumes parse کرتے وقت draw کرتے ہیں۔ ہر نیا token اس budget کو کسی نہ کسی مقدار سے کم کرتا ہے۔ اور وہ symptom کا نام بھی لیتا ہے: "جیسے جیسے context window میں tokens کی تعداد بڑھتی ہے، model کی اس context سے information کو accurately recall کرنے کی صلاحیت کم ہوتی ہے" — context rot۔¹

یہ آخری sentence behaviour کے بارے میں claim ہے، جس کا مطلب ہے کہ اسے check کیا جا سکتا ہے، اور اس page کے اوپر کی 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 result میں بدلتا ہے: جب model غلط ہے، کیا وہ lost ہے یا confident؟

جواب confident ہے۔ آٹھ non-first positions میں، 205 غلط answers میں سے 136 کسی دوسری ticket کا extension تھے — ایک حقیقی چار ہندسوں کا number، correctly formatted، غلط line سے پڑھا گیا۔ slot 1 پر پانچ misses میں سے صرف ایک ایسا تھا؛ slot 7 پر چھبیس میں سے اکیس تھے۔

production میں یہی distinction اہم ہے۔ جو model کہتا ہے مجھے یہ نہیں مل رہا وہ bug ہے جسے آپ notice کرتے ہیں؛ جو model ساتھ والی row کا number return کرتا ہے وہ 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 تک flat اور low۔ سارا collapse list کی پہلی اور آٹھویں line کے درمیان ہو جاتا ہے۔

آخری column ہر وہ چیز ہے جو نہ درست extension ہے نہ کسی دوسرے record کا، جو page پر ایک single record کے ساتھ وہ واحد جگہ ہے جہاں wrong answer جا سکتا ہے۔ ایک record پر دو misses کو round away کرنے کے بجائے report کرنا ضروری ہے، کیونکہ دونوں میں سے کوئی refusal نہیں تھا: ایک نے ایسے register کے جواب میں 5806 کہا جس کی اکلوتی line 5805 کہتی ہے۔ 97 tokens پر، single candidate کے ساتھ بھی یہ model بیس میں دو بار digit غلط copy کرتا ہے، اور یہی وہ floor ہے جس کے against باقی سب measure ہوتا ہے۔

دو باتیں نکلتی ہیں۔ بڑا 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 اسی terms میں بیان کرتا ہے جیسے یہ course کرتا ہے: models "transformer architecture پر based ہیں، جو ہر token کو پورے context میں ہر دوسرے token پر attend کرنے کے قابل بناتا ہے۔ اس سے n tokens کے لیے n² pairwise relationships بنتے ہیں"۔¹ لمبی sequence پر attention زیادہ material پر وہی operation apply کرنا نہیں؛ یہ probability mass کا ایک fixed budget ہے جو زیادہ competitors پر spread ہوتا ہے۔ دوسرا training ہے: models short sequences زیادہ دیکھتے ہیں long ones کے مقابلے میں، اس لیے long-range positional patterns network کا سب سے کم practised حصہ ہیں۔ یہ 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 کے beginning یا end پر ہوتی ہے، اور significantly degrade ہوتی ہے جب models کو long contexts کے middle میں relevant information access کرنی پڑتی ہے، یہاں تک کہ explicitly long-context models کے لیے بھی"۔² Chapter 15 نے اسی paper سے اپنی position rule لی؛ Chapter 19 نے اسی سے وجہ لی کہ بیس retrieved chunks چار سے worse score کر سکتے ہیں۔ اس fact کی practical form صرف ایک sentence ہے جس پر آپ کو act کرنا چاہیے: آپ کے اپنے model پر، آپ کے اپنے data کے ساتھ، اسے measure کرنے میں پانچ منٹ لگتے ہیں، اور کوئی published curve آپ کی curve کا substitute نہیں۔

کسی team سے پوچھیں کہ ان کے agent کا context کیا fill کرتا ہے تو estimate ملتا ہے، کیونکہ کوئی API جواب return نہیں کرتی: response آپ کو prompt_tokens دیتی ہے، سب کے لیے ایک number۔

آپ چار counts اور تین subtractions سے breakdown recover کر سکتے ہیں — پورا rendered prompt، وہی tool definitions کے بغیر، system message اکیلا ان کے ساتھ اور ان کے بغیر، اور سب کچھ tool results removed کے ساتھ:

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 tokenizing سے پہلے model کا اپنا chat template apply کرتا ہے، جو سننے سے زیادہ اہم ہے: آپ کا text وہ نہیں جو count ہوتا ہے۔ Role markers، tool-calling preamble اور schema rendering سب tokens ہیں جن کی قیمت آپ دیتے ہیں اور کبھی type نہیں کرتے۔ Chapter 7 نے tokenizer بنایا اور Chapter 16 نے js-tiktoken کے ساتھ count کیا؛ یہاں count اسی model سے آتا ہے جو prompt پڑھے گا، جو واحد count ہے جو exactly right ہے۔

اب ایک real agent کو اس سے گزاریں: incident investigation کے چالیس turns، بارہ tools، ایک fake operations environment جو realistic log dumps اور metric series return کرتا ہے۔

پہلی row کو آخری کے مقابل پڑھیں۔

turn 1 پر prompt 2,547 tokens ہے اور اس کا 71 % tool definitions ہیں۔ system prompt 3 % ہے۔ user نے جو type کیا وہ 6 % ہے۔ agent نے ابھی کچھ نہیں کیا اور پہلے ہی JSON schema کے 1,817 tokens اٹھائے ہوئے ہے۔

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 نے final context 10,632 کے لیے 370,291 input tokens bill کیے — آخری prompt تقریباً پینتیس بار pay ہوا، جو Chapter 16 کا quadratic ہے جس کے اوپر agent کا multiplier ہے۔ ان 370,291 میں سے، 103,569، یعنی bill ہونے والی ہر چیز کا 28 %، بارہ tool definitions تھے، جو ہر call پر byte-identical دوبارہ بھیجے گئے۔

tool catalogue agent کی سب سے بڑی fixed cost ہے اور invisible ہے، کیونکہ آپ اسے کبھی نہیں دیکھتے: آپ objects کی array pass کرتے ہیں اور provider اسے آپ کے لیے prompt میں render کرتا ہے۔ اسی بارہ tools پر measure کیا گیا:

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 %)

ہر tool کی marginal cost get_current_time کے لیے 80 tokens سے چلتی ہے، جو ایک string لیتا ہے، search_tickets کے لیے 263 تک، جو enum اور ہر parameter کے لیے guidance کے ایک sentence کے ساتھ چار parameters لیتا ہے۔ یہ Chapter 18 کی central advice کے پیچھے exchange rate ہے کہ description ہی API ہے: اچھی description agent کی باقی زندگی میں ہر request پر تقریباً سو tokens cost کرتی ہے۔ تین consequences۔

جو tool آپ use نہیں کرتے وہ بھی bill ہوتا ہے۔ agent نے بارہ میں سے سات call کیے۔ باقی پانچ نے 57 requests میں سے ہر ایک پر 697 tokens cost کیے — کل 39,729، run کے bill کی دسویں سے زیادہ، ان capabilities کے لیے جنہیں اس نے کبھی touch نہیں کیا۔ ان پانچ میں سے ایک trace کی sharpest detail رکھتا ہے: model نے تین بار read_log call کرنے کی کوشش کی، جو exist نہیں کرتا۔ وہ tool جو اسے چاہیے تھا search_logs تھا، catalogue میں 237 tokens پر دوسری سب سے expensive definition۔ اس نے اس definition کے لیے 57 بار pay کیا، کبھی use نہیں کیا، اور اس کا نام کبھی نہیں ڈھونڈا۔

prose trim کرنا سب سے سستی optimisation ہے، اور یہ trade ہے۔ descriptions کو ایک sentence تک کاٹنے اور parameter documentation drop کرنے سے ہر call پر 526 tokens، 29 per cent، saved ہوئے، logic کی ایک line چھوئے بغیر — اور model نے tools worse call کیے، جو Chapter 18 نے measure کیا۔ point یہ ہے کہ اس trade کے دونوں sides اب ایک ہی unit میں ہیں۔

کسی scale پر definitions بھیجنا ہی sense نہیں رکھتا۔ Anthropic نے November 2025 میں اس پر number رکھا: connected servers کا بڑا set request پڑھنے سے پہلے definitions کے "hundreds of thousands of tokens" process کراتا ہے، اور اسے code execution سے replace کرنا — agent کا صرف وہ definitions discover اور load کرنا جن کی اسے ضرورت ہے — "token usage کو 150,000 tokens سے 2,000 tokens تک کم کرتا ہے، وقت اور cost میں 98.7% saving"۔³ باقی chapter جیسا ہی idea، history کے بجائے schemas پر apply: index رکھیں، entry کو demand پر resolve کریں۔

اس forty-turn transcript میں دو چیزیں planted تھیں۔ turn 2 پر، کسی real work سے پہلے، user ایک standing rule بیان کرتا ہے: آپ جو بھی ticket کھولیں اسے میرے employee number، 4417، کے تحت file کرنا ہے۔ turn 19 پر، incident کے middle میں، ایک fact: affected shard pay-shard-7 ہے، payments team نے confirm کیا ہے۔ turn 40 پر user agent سے incident ticket open کرنے کو کہتا ہے، جس کے لیے دونوں چاہیے۔ ہر probe چھ different phrasings میں پوچھا جاتا ہے اور چھ میں score ہوتا ہے — greedy decoding deterministic ہے، اس لیے ایک call ایک unrepeatable yes یا no دیتا ہے اور چھ ایک rate دیتے ہیں۔

transcript پھر سات context policies کے تحت replay ہوتا ہے۔ Replayed، re-run نہیں، جان بوجھ کر: messages، tool calls اور tool results ساتوں میں byte-identical ہیں، اس لیے واحد variable ہے ہر policy نے کیا keep کرنا choose کیا۔ 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 alone کے ساتھ 1,981-token prompt میں یہ model دونوں probes perfectly answer کرتا ہے، اس لیے کوئی row task کے too hard ہونے کی وجہ سے نہیں۔

Full history یاد رکھتی ہے، اور table کی سب سے expensive چیز ہے: ایک session کے لیے 370,291 input tokens جس کا durable content دو sentences ہے۔

یہ اس سوال کا جواب دیتا ہے جو opening نے کھلا چھوڑا تھا۔ 10,632-token transcript ایک fact کیوں hold کرتی ہے جسے 853-token register lose کر دیتا ہے؟ کیونکہ length غلط variable ہے۔ register پچیس identical sentences میں پچیس four-digit extensions رکھتا ہے — مطلوبہ answer کے لیے چوبیس near-perfect decoys۔ transcript میں exactly ایک employee number اور ایک shard name ہے۔ Context rot volume سے پہلے interference ہے، اسی لیے اوپر 205 wrong answers میں سے 136 neighbour کی value تھے۔ window کے بارے میں useful question یہ نہیں کہ وہ کتنی لمبی ہے؛ یہ ہے کہ اس میں کتنی چیزیں answer جیسی لگتی ہیں۔

sliding window 57 % سستی ہے اور incident کھو چکی ہے۔ employee number صرف اس لیے survive کرتا ہے کہ agent نے اسے recent turns میں repeat کیا تھا۔ shard، جو turn 19 پر ایک بار stated تھا، last twelve messages میں نہیں ہے — اور model یہ نہیں کہتا۔ چھ بار پوچھنے پر اس نے "the affected payment shard is shard 4417" جواب دیا، employee number تک پہنچتے ہوئے، جو اس کی window میں left واحد دوسرا identifier تھا، اور دو بار "pool"، جو log line کے string pool_exhausted سے اٹھایا گیا تھا۔

Compaction cheap ہے اور وہی fact کھو دیتی ہے۔ سات summaries، model نے explicit instruction کے تحت لکھیں کہ identifiers، numbers، standing instructions اور open questions keep کریں، اور pay-shard-7 ان میں سے کسی relevant summary میں نہیں؛ چھ guesses shard 1، pay_shard_1 اور pool تھے۔ Compaction loudly fail نہیں کرتی۔ یہ ایک fluent، plausible، بہت shorter session produce کرتی ہے جس نے خاموشی سے ایک line drop کر دی ہے۔

تین rows نے turn-19 fact پر 0/6 score کیا — sliding window، compaction، اور compaction with notes۔ ان کے درمیان اٹھارہ wrong answers، اور ان میں سے ایک بھی "I do not know" نہیں تھا۔

پھر وہ row جو embarrassing ہونی چاہیے۔ user کے اپنے چالیس messages verbatim رکھنا، plus last four turns in full اور کچھ نہیں، 168,550 tokens cost کرتا ہے — full history سے 54 % کم — اور دونوں probes کو full history جتنا یا بہتر answer کرتا ہے۔ نہ summariser، نہ note-taker، نہ second model: role === "user" پر ایک filter۔ user کے words agent کی window میں سب سے سستے high-value tokens ہیں، اور زیادہ تر designs انہیں باقی سب کے ساتھ discard کر دیتے ہیں۔

آخری دو rows opening table دوبارہ ہیں، agent کے اندر۔ وہی pinned block، system message سے prompt کے end تک move کیا گیا: 5/6 سے 6/6۔ چھ trials پر یہ significant difference نہیں اور اسے ایسا پیش نہیں کیا جا رہا — یہ reminder کے طور پر ہے کہ کہاں ایک parameter ہے جسے آپ set کر رہے ہیں، چاہے آپ کو معلوم ہو یا نہیں۔

نیچے چار strategies Anthropic کی ہیں، اسی order میں، اگرچہ صرف آخری تین اس کی 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 میں چلتا ہے جسے کسی نے اس کے لیے scoped کیا۔ system prompt، turns 17 سے 19 اور کچھ نہیں — 2,737 tokens — دیے جانے پر اس نے shard probe 6/6 answer کیا، table کی ہر policy سے بہتر، اور employee probe 0/6، کیونکہ وہ number ان تین turns میں نہیں تھا جو اسے دیے گئے۔

یہ sub-agents ہیں دو numbers میں: clean window intelligence نہیں، scope ہے، اور scoping پہلے سے code کرتا ہے جسے پہلے ہی معلوم ہونا چاہیے کہ کون سے turns matter کرتے ہیں۔ ان answers میں ایک اور چیز preserve کرنے کے قابل ہے۔ یہی واحد policy تھی جس نے کچھ invent کرنے کے بجائے "None available" reply کیا۔ small، coherent context والا model جانتا ہے کہ کیا missing ہے؛ large، noisy context والا نہیں۔

agent memory کے بارے میں تقریباً ہر confused conversation ایک لفظ پہنے تین mechanisms ہے۔ ان کی lifetimes، owners اور failure modes مختلف ہیں، اور جو system انہیں ایک ہی place میں رکھتا ہے اسے ایک مسئلہ ہے جو اس نے ابھی notice نہیں کیا۔

academic framing CoALA کی ہے، جو language agents کو "modular memory components" کے گرد organize کرتی ہے اور working memory کو episodic، semantic اور procedural stores سے separate کرتی ہے۔⁴ MemGPT اسی idea کو literal لیتا ہے، operating systems سے virtual memory borrow کرتے ہوئے: window کے اندر fast tier، اس کے باہر slow tier، اور model خود function calls کے ساتھ data کو ان کے درمیان move کرتا ہے۔⁵ دونوں وہ question force کرتے ہیں جس کا product کو ویسے بھی answer دینا ہے — یہ نہیں کہ میں کتنا keep کر سکتا ہوں، بلکہ یہ کس store میں belong کرتا ہے، اور کب expire ہوتا ہے۔

practical test ہر fact کے لیے ایک question ہے: کل بھی کیا true رہنا چاہیے؟ turn 12 کا tool result، کچھ نہیں۔ session کی summary، session end ہونے تک۔ یہ کہ 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 اور ان کے names اصل میں کہاں سے آتے ہیں، دو topologies جو mix up ہوتی ہیں — sub-agent سے پوچھ کر answer واپس لینا، بمقابلہ اسے conversation hand کرنا اور واپس نہ لینا — اور measured finding کہ جس task کی یہ قیمت لگاتا ہے اس پر simpler arrangement جیتتا ہے — پھر وہ test کہ کب یہ جیتنا چھوڑتا ہے۔

یہ بھی exactly وہی inherit کرتا ہے جو اس chapter نے ابھی measure کیا۔ sub-agent summary return کرتا ہے۔ summary ایک compaction ہے جو آپ نے نہیں لکھی، ایسے model سے produced جس کی window آپ نہیں دیکھ سکتے، اور parent کے پاس good summary کو confident wrong summary سے الگ کرنے کا کوئی طریقہ نہیں — وہی distinction جس نے اس page کے اوپر 84 % کو 19 % سے الگ کیا، اور اٹھارہ missing facts کو اٹھارہ invented ones میں بدل دیا۔ تو: جب sub-agent غلط ہو، parent آخر کس چیز کو دیکھ سکتا ہے؟

یہاں ہر number اسی machine پر produced ہوا اور کوئی estimated نہیں تھا۔ model CPU پر float32 میں Qwen2.5-0.5B-Instruct ہے، greedy decoding کے ساتھ، loopback پر ایک چھوٹے Python endpoint کے ذریعے serve ہوتا ہے جو chat-completions shape بولتا ہے اور token-count route expose کرتا ہے — Chapter 14 کا seam دوبارہ، tensors Python side پر اور loop TypeScript side پر — اس لیے ہر count اسی model کا اپنا tokenizer ہے جو اس کے اپنے chat template پر apply ہوا۔ position table 288 calls ہے، نو positions by thirty-two trials with a different ticket each trial؛ 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 کے ہیں۔