एआई की शब्दकोश

बदलता रहने वाला लेबल, कोई तकनीक नहीं। “AI” model या token की तरह किसी निश्चित चीज़ का नाम नहीं है — यह उस क्षमता की ओर संकेत करता है जो कंप्यूटर अभी-अभी प्रभावशाली ढंग से कर पा रहे हैं। अभी यह large language models की ओर संकेत करता है। पहले इसका अर्थ बहुत अलग चीज़ें रहा है:

इस pointer का आगे बढ़ना एक ज्ञात तंत्र से होता है, जिसे कभी-कभी AI effect कहा जाता है: कोई तकनीक भरोसेमंद ढंग से काम करने लगे तो उसका नाम बदल जाता है — वह “बस” search, “बस” statistics रह जाती है — और “AI” अगले अनसुलझे काम की ओर खिसक जाता है। यह अवलोकन पुराना है। Bertram Raphael ने 1971 में इसे इस तरह कहा: “AI उन समस्याओं का सामूहिक नाम है जिन्हें हम अभी तक कंप्यूटर से ठीक तरह हल करना नहीं जानते।” Larry Tesler ने लगभग 1979 में कहा: “बुद्धिमत्ता वह है जो मशीनों ने अभी तक नहीं किया।”

इसीलिए AI के बारे में बातचीत में लोग अक्सर एक-दूसरे की बात नहीं समझते। “AI तर्क नहीं कर सकता” या “AI को बढ़ा-चढ़ाकर बताया गया है” जैसे दावे में समय का एक छिपा संकेत होता है — बात expert systems की, 2010 के image classifiers की या पिछले महीने के LLM की हो सकती है; हर संदर्भ अलग निष्कर्ष का समर्थन करता है। AI पर चर्चा अटक जाए तो आमतौर पर उस शब्द की जगह वही सटीक शब्द रखना समाधान होता है जिसका वास्तव में मतलब है: model, harness, agent या उसे दिया गया context।

इससे बचें: किसी तकनीकी दावे में “AI” कहना — इसके बजाय जिस हिस्से का मतलब है, उसका नाम लें। अभ्यास के नाम के तौर पर “AI coding” ठीक है; “the AI is hallucinating” ठीक नहीं।

उपयोग:

“CTO जानना चाहती हैं कि क्या AI triage queue संभाल सकता है।”

“दायरा तय करने से पहले इसका मतलब स्पष्ट करें — उनका आशय ticket system तक पहुँच वाले harness में LLM से है। अकेला ‘AI’ कोई spec नहीं है।”

parameters। Stateless — next-token prediction करता है और इसके अलावा कुछ नहीं। "Claude Opus 4.x" और "GPT-5.x" मॉडल हैं। अपने आप मॉडल कुछ भी एजेंटिक नहीं कर सकता; उसे harnessed करना पड़ता है।

मॉडल फ़ाइलें नहीं पढ़ सकते, कमांड नहीं चला सकते, वेब नहीं ब्राउज़ कर सकते और कल की बातें याद नहीं रख सकते — वे tokens लेते हैं और हर model provider request में टोकन का अनुमान लगाकर आउटपुट देते हैं। agent के काम जैसा जो कुछ भी महसूस होता है — tools चुनना, नतीजे पढ़ना, काम पूरा होने तक चक्र दोहराना — वह सब harness द्वारा ऐसी कई भविष्यवाणियों को क्रम से संचालित करना है।

Model providers मॉडल अलग-अलग स्तरों में देते हैं: एक बड़ा मॉडल, जो सबसे बुद्धिमान लेकिन धीमा और महँगा होता है, और छोटे मॉडल, जो तेज़ और सस्ते लेकिन कम सक्षम होते हैं। स्तर चुनना सचमुच एक निर्णय है — योजना और कठिन डीबगिंग के लिए भारी मॉडल, यांत्रिक बदलावों के लिए हल्का मॉडल — और harness आपको बीच session में मॉडल बदलने देता है।

इस शब्द का सटीक इस्तेमाल निदान को भी बेहतर बनाता है। "The model is bad at this" एक विशिष्ट दावा है — वही मॉडल किसी दूसरे harness में या अलग context के साथ बिल्कुल अलग व्यवहार कर सकता है। मॉडल को दोष देने से पहले देखें कि उसे क्या दिया गया था: निराशाजनक आउटपुट का कारण अक्सर संदर्भ या harness होता है, पैरामीटर नहीं।

Usage

"Should we switch the model from Sonnet to Opus for the planning step?"

"Try it — but the harness is doing most of the lifting on this task. The model swap won't help if the system prompt and tools are wrong."

किसी model के भीतर की संख्याएँ — अक्सर अरबों की संख्या में — जिन्हें training के दौरान समायोजित किया जाता है। मॉडल जो कुछ भी "जानता" है, वह इन्हीं में रहता है। Training इन्हें तय करती है; inference इन्हें बिना बदले इस्तेमाल करता है। इन्हें weights भी कहते हैं।

यांत्रिक रूप से, parameters ही input को output में बदलते हैं। Next-token prediction एक विशाल गणना है: context window के tokens भीतर जाते हैं, parameters से गुणा होते हैं और अगला token क्या होगा इसकी भविष्यवाणी निकलती है। मॉडल के भीतर तथ्यों का कोई डेटाबेस या code lookup table नहीं होता — बस ये संख्याएँ होती हैं, जिन्हें इस तरह व्यवस्थित किया गया है कि गणना उपयोगी output देने की ओर झुके। मॉडल training से जो तथ्य दोहरा सकता है, जैसे standard library API, वह parametric knowledge है: parameters में संग्रहित, कहीं से निकालकर नहीं लाया गया।

समझने लायक अहम बात यह है कि training के बाद parameters स्थिर हो जाते हैं। Session में आप जो भी करते हैं, उससे वे नहीं बदलते — न आपका सुधार, न वह codebase जो आप उसे दिखाते हैं, न कोई गलती जिससे वह सीख ले। हर session उन्हीं संख्याओं पर चलता है। इसी वजह से मॉडल stateless है, उसका अंतर्निहित ज्ञान knowledge cutoff पर रुक जाता है और परियोजना-विशिष्ट जानकारी context के ज़रिए ही पहुँचानी पड़ती है। Parameters बदलने का एकमात्र तरीका और training है — जिससे प्रभावी रूप से एक अलग मॉडल बनता है।

Usage

"क्या हम इसे अपने codebase पर fine-tune कर सकते हैं?"

"इससे parameters अपडेट होंगे — उसके बाद मॉडल अलग होगा। एक परियोजना के लिए codebase को context के रूप में लोड करना लगभग हमेशा फिर से training करने से सस्ता होता है।"

वह प्रक्रिया जो model के parameters तय करती है: उसे बहुत अधिक पाठ दिखाकर next-token prediction बेहतर करने के लिए parameters समायोजित करना। यह model provider द्वारा की जाने वाली एक बार की, महँगी प्रक्रिया है। इसमें pre-training (मुख्य प्रशिक्षण) और post-training (बाद के सुधार, जैसे निर्देशों का पालन और सुरक्षा) दोनों शामिल हैं; इस शब्दावली के स्तर पर यह अंतर मायने नहीं रखता।

इसका तरीका बड़े पैमाने पर दोहराव है: मॉडल को पाठ का एक अंश दिखाएँ, उससे अगले token की भविष्यवाणी करवाएँ, वास्तविक अगला token जो था उसकी दिशा में parameters को थोड़ा समायोजित करें, फिर खरबों tokens पर यही दोहराएँ। तथ्यों या नियमों के रूप में कुछ भी संग्रहित नहीं होता — मॉडल जो कुछ भी "जानता" है, वह भविष्यवाणी में बेहतर होने का उप-उत्पाद है, जो parameters में parametric knowledge के रूप में संपीड़ित रहता है।

रोज़मर्रा में दो नतीजे मायने रखते हैं। Training किसी समय पर समाप्त होती है, इसलिए मॉडल की knowledge cutoff होती है — उसने वह library version नहीं देखा जिसे आपने पिछले महीने upgrade किया। और training ऐसी चीज़ नहीं है जो आप कर सकते हैं: जब मॉडल आपके codebase, आपकी परंपराओं या आपके आंतरिक APIs को नहीं जानता, तो समाधान कभी भी "मॉडल को सिखाओ" नहीं होता — उस सामग्री को context में रखना होता है, क्योंकि यही एक input है जिसे आप नियंत्रित कर सकते हैं।

Usage

"क्या हम इसे अपना internal API जानने के लिए तैयार कर सकते हैं?"

"Training से नहीं — इसमें model provider को कई महीने लगेंगे। इसके बजाय API docs को context में लोड करें; यही वह उपाय है जिस पर आपका नियंत्रण है।"

किसी प्रशिक्षित मॉडल को आउटपुट बनाने के लिए चलाना — हर मॉडल प्रदाता अनुरोध में यही होता है। पैरामीटर स्थिर रहते हैं; मॉडल उसे दिए गए संदर्भ पर अगले टोकन की भविष्यवाणी करता है। यह प्रशिक्षण की तुलना में सस्ता है, लेकिन हर टोकन के हिसाब से शुल्क लगता है और मॉडल का उपयोग करने की प्रमुख लागत यही है।

मॉडल का जीवन दो चरणों में बँटा होता है:

अनुमान के समय आप जो भी करते हैं, उससे पैरामीटर में कुछ वापस नहीं लिखा जाता — इसी वजह से आज किया गया सुधार कल तक याद नहीं रहता। अगले सत्र में वही गलती दोहराने वाला मॉडल, भले ही आपने उसे सावधानी से सुधार समझाया हो, आपकी बात अनदेखी नहीं कर रहा; वह उस बातचीत से सीख ही नहीं सकता। मॉडल स्टेटलेस है — निरंतरता उसे बाहर से, संदर्भ विंडो या मेमोरी प्रणाली से मिलनी चाहिए।

यह प्रक्रिया यह भी समझाती है कि बिल कैसे बनता है। हर अनुरोध पूरे संदर्भ पर मॉडल चलाता है, इसलिए लागत इनपुट टोकन और आउटपुट टोकन के साथ बढ़ती है; और दर्जनों टूल कॉल करने वाले एजेंट को हर अनुरोध-उत्तर चक्र के अनुमान का भुगतान करना पड़ता है। इसी कारण संदर्भ का आकार गुणवत्ता के साथ-साथ लागत का भी सवाल है।

उपयोग:

"बिल उपयोग के साथ क्यों बढ़ता है, इसकी जगह एक तय लाइसेंस शुल्क क्यों नहीं है?"

"आप अनुमान के लिए भुगतान कर रहे हैं — हर मॉडल प्रदाता अनुरोध में मॉडल प्रदाता के हार्डवेयर पर चलता है। प्रशिक्षण पहले ही हो चुका है, लेकिन अनुमान की लागत हर अनुरोध पर लगती है; टूल इस्तेमाल होने पर एक ही बारी कई अनुरोधों में बदल सकती है।"

Effort यह नियंत्रित करता है कि जवाब देने से पहले model कितना तर्क करे। इसे हर model provider request के लिए सेट किया जाता है; यह तय करता है कि दिखाई देने वाला उत्तर लिखने से पहले model कितनी देर तक सोचता है। यह सोच बाकी सबकी तरह inference के समय तैयार होती है; harness अक्सर इसे छिपा देता है, लेकिन model वास्तव में यह काम करता है।

अधिक effort की कीमत अधिक होती है और समय भी ज़्यादा लगता है। तर्क tokens के रूप में निकलता है और output tokens के तौर पर उसका बिल लगता है, भले ही आप उसे कभी न देखें; यह एक बार में एक token बनता है — इसलिए effort बढ़ाने से उत्तर आने की प्रतीक्षा बढ़ती है और बिल भी। यह अधिक विचार-विमर्श के बदले गति और लागत का समझौता है।

अधिकतर harness effort को कुछ स्तरों की सीढ़ी के रूप में दिखाते हैं:

गलत सेटिंग का लक्षण दोनों दिशाओं में दिखता है। कठिन समस्या पर effort बहुत कम रखें तो ऐसा आत्मविश्वास भरा, सतही जवाब मिलता है जिसने ज़रूरी तर्क किया ही नहीं — पढ़ने में ठीक और बाद में महँगा पड़ने वाले तरीके से गलत। एक-पंक्ति के नाम-परिवर्तन के लिए Max चुनें तो लंबे विचार का इंतज़ार करना पड़ता है और नतीजा ऐसा होता है जो सबसे कम setting भी दे देती।

Effort को काम के अनुसार चुनें, session के अनुसार नहीं। जिस हिस्से पर सचमुच कठिन तर्क चाहिए वहाँ इसे बढ़ाएँ और आसपास के दोहराव वाले काम के लिए घटा दें।

उपयोग:

“यह concurrency fix बार-बार बिगाड़ रहा है — मैं तीन बार समझा चुका हूँ।”

“Effort बढ़ाएँ। यह ऐसा bug है जिसमें गहरे तर्क की ज़रूरत है, और default setting में यह तरीका चुनने से पहले पर्याप्त देर तक नहीं सोच रहा।”

model जिस मूल इकाई को पढ़ता और लिखता है। यह लगभग शब्द के आकार की होती है, लेकिन बिल्कुल वैसी नहीं — आम शब्द एक token होते हैं, जबकि दुर्लभ या लंबे शब्द कई में बँट जाते हैं। Context window का आकार, लागत और विलंब — सभी tokens में गिने जाते हैं।

Text को tokens में tokenizer बदलता है: हज़ारों खंडों की एक निश्चित शब्दावली, जिसे training से पहले सीखा जाता है और जो किसी भी input को शब्दावली की प्रविष्टियों के क्रम में बाँटती है। मॉडल अक्षर या शब्द नहीं देखता — अंदर जाते समय हर पाठ tokens में बदला जाता है और next-token prediction बाहर आते समय एक-एक token करके output बनाती है।

मोटे तौर पर, एक token अंग्रेज़ी के शब्द का लगभग तीन-चौथाई होता है, इसलिए हज़ार tokens लगभग 750 शब्द होते हैं। Code का अनुमान लगाना कठिन है: आम कीवर्ड और मुहावरे कम tokens में बदलते हैं, जबकि बनाए गए identifiers, hashes, base64 blobs और minified output में हर "शब्द" कई tokens में टूट जाता है। पैटर्न यह है: tokenizer की source material में जो text अक्सर आया, उसका encoding छोटा और कुशल होता है; जो नहीं आया, वह कई छोटे टुकड़ों में कट जाता है। `a3f9c2e1` जैसा hash कहीं मौजूद नहीं था, इसलिए वह कई tokens में टूटता है, जबकि `function` एक ही है। इसी वजह से असामान्य strings से भरी छोटी दिखने वाली फ़ाइल भी context window का अप्रत्याशित रूप से बड़ा हिस्सा ले सकती है।

Tokens वह इकाई हैं जिसमें बाकी हर चीज़ मापी जाती है। लागत प्रति token है — प्रदाता input tokens और output tokens के लिए अलग-अलग शुल्क लेते हैं। गति tokens प्रति सेकंड है, क्योंकि output एक-एक token करके बनता है। और context window में tokens की एक निश्चित संख्या होती है, इसलिए आपकी फ़ाइलों के token तय करते हैं कि उसमें कितना कुछ समा सकता है।

Avoid"word" — token की सीमाएँ शब्दों की सीमाओं से मेल नहीं खातीं; tokens-per-second और tokens-per-dollar वे इकाइयाँ हैं जो वास्तव में मायने रखती हैं।

Usage

"How big is this prompt going to be?"

"इसे tokenizer से गुज़ारें — schema संक्षिप्त है, लेकिन JSON की keys अजीब हैं, इसलिए वे आपकी अपेक्षा से ज़्यादा tokens में टूटेंगी।"

model वास्तव में क्या करता है। context मिलने पर यह अगले token का नमूना चुनता है, उसे जोड़ता है और फिर से प्रक्रिया चलाता है। हर output — वाक्य, tool call, हज़ार पंक्तियों की फ़ाइल — एक-एक token करके बनता है। मॉडल के काम करने का कोई दूसरा तरीका नहीं है।

हर चरण एक ही तरह से काम करता है: context window में मौजूद tokens को parameters से गुज़ारा जाता है, जो शब्दावली के हर token की संभावना देते हैं — यह अगला token बहुत संभावित है, दूसरा कम। उन संभावनाओं में से एक token चुना जाता है, जोड़ा जाता है और थोड़े लंबे context के साथ चक्र फिर चलता है। यही नमूना-चयन बताता है कि एक ही prompt से अलग runs में अलग output क्यों मिलता है: non-determinism इस प्रक्रिया में ही शामिल है, बाद में जोड़ा गया कोई दोष नहीं।

इस प्रक्रिया को ध्यान में रखने से ऐसा व्यवहार समझ आता है जो वरना अजीब लगेगा। मॉडल token भेजने से पहले यह नहीं जाँचता कि वह सच है या नहीं — केवल यह कि वह संभावित है या नहीं — और यही hallucination की जड़ है। वह आगे बढ़ते हुए हर token पर प्रतिबद्ध होता जाता है, इसलिए आत्मविश्वास से लिखा शुरुआती वाक्य बाकी जवाब को गलत दिशा दे सकता है। और क्योंकि output tokens सख़्ती से एक-एक करके बनते हैं, इसलिए generation की गति तय करती है कि कोई भी agent कितनी तेजी से काम कर सकता है।

Usage

"Agent किसी tool को call करने का 'फ़ैसला' कैसे करता है?"

"वह नहीं करता — अंत तक बस next-token prediction ही है। Tool call केवल एक structured string है जिसे harness output stream से पार्स करता है।"

एक ही input से अलग-अलग output आ सकते हैं। model को समान context के साथ दो बार चलाएँ, तो दो अलग जवाब मिल सकते हैं — कभी केवल एक शब्द अलग, कभी पूरी तरह अलग तरीका। ऐसा होने के लिए आपके code में कुछ बदलना ज़रूरी नहीं।

यह इस बात का गुण है कि मॉडल पाठ कैसे बनाते हैं और model providers requests कैसे पूरा करते हैं। Inference के दौरान मॉडल संभावित अगले tokens पर एक probability distribution बनाता है और उसमें से एक token चुना जाता है — आम तौर पर जान-बूझकर थोड़ी randomness के साथ, क्योंकि हमेशा सबसे संभावित token चुनने से दोहराव वाला और कम गुणवत्ता का पाठ बनता है। जवाब की शुरुआत में अलग तरह से चुना गया एक token उसके बाद के हर token को बदल देता है; इसी तरह एक अलग शब्द पूरी तरह अलग तरीके में बदल सकता है। Provider की ओर की सेवा इससे भी अधिक बदलाव जोड़ती है: requests साझा hardware पर एक साथ batch की जाती हैं, और batches के बीच floating-point के छोटे अंतर किसी निकट संभावना वाले दो tokens में से चुनाव बदल सकते हैं। कोई ऐसी setting नहीं है जिसे बदलकर यह सब पूरी तरह रोका जा सके।

एक ही काम पर agent से अलग-अलग नतीजों की अपेक्षा रखें। ज़्यादातर जवाब गुणवत्ता की एक उचित घंटी-आकार की सीमा में आते हैं — इसीलिए गैर-नियतात्मकता सहन की जा सकती है — लेकिन सीमा के छोर भी वास्तविक हैं: कुछ दिन मॉडल तेज़तर्रार लगेगा, कुछ दिन ऐसा लगेगा जैसे वह मुद्दे से भटक गया हो। काम वही, पासे के अलग-अलग दाँव। इसके दो व्यावहारिक नतीजे हैं। दोबारा कोशिश करना जायज़ रणनीति है: असफल प्रयास उस वितरण से एक नमूना है और उसी काम पर नया प्रयास बेहतर नतीजा दे सकता है। और सत्यापन अधिक मायने रखता है, जितना नियतात्मक tools के साथ रखता — agent के व्यवहार को एक बार जाँचकर उसके बार-बार वैसे ही दोहराने पर भरोसा नहीं किया जा सकता, इसलिए खराब नमूनों को पकड़ने के लिए automated checks ज़रूरी हैं।

इसमें ज़रूरत से ज़्यादा कहानी न गढ़ें। मनुष्य पैटर्न पहचानने वाली मशीनें हैं और लगातार खराब runs से ऐसा लग सकता है कि "इस हफ़्ते मॉडल खराब हो गया है।" आम तौर पर यह सिर्फ़ वितरण का असर होता है।

Usage

"Claude आज बहुत खराब रहा है। क्या उन्होंने कोई ख़राब version जारी किया?"

"शायद नहीं — model output गैर-नियतात्मक है। एक ही काम पर अच्छे और बुरे दिन आएँगे। कारण खोजने से पहले कल फिर कोशिश करें।"

वह सेवा जो model को inference के लिए उपलब्ध कराती है। आम तौर पर यह कोई remote service होती है (Anthropic, OpenAI, Google), लेकिन स्थानीय भी हो सकती है — आपकी अपनी मशीन पर चल रहा Ollama, LM Studio या llama.cpp। Harness खुद model नहीं चलाता; वह provider से इसे चलाने को कहता है।

मशीनरी provider के पास होती है: parameters उसके hardware पर रहते हैं और हर model provider request में harness नेटवर्क के ज़रिए tokens भेजता है और भविष्यवाणियाँ वापस पाता है। इससे provider समस्याओं की एक पूरी श्रेणी का स्रोत बन जाता है, जिन्हें अक्सर model या harness के सिर मढ़ दिया जाता है — rate limits, क्षमता में कमी और outages, सब यहीं होते हैं। जब agent session के बीच में अटक जाए या हर turn पर error दे, तो सबसे पहले provider का status page देखना चाहिए।

व्यावसायिक शर्तें भी provider तय करता है: input और output tokens के लिए प्रति-token कीमत, prefix cache की छूट और कौन-से models उपलब्ध हैं। ध्यान दें कि provider और model बनाने वाली कंपनी अलग-अलग हो सकती हैं — Bedrock, Vertex और OpenRouter दूसरी कंपनियों के models उपलब्ध कराते हैं।

स्थानीय providers नियंत्रण के बदले क्षमता की कुछ कमी लाते हैं: आपकी मशीन पर चल सकने वाले models सबसे उन्नत models से बहुत छोटे होते हैं, लेकिन कोई जानकारी मशीन से बाहर नहीं जाती और हर token का बिल नहीं आता।

Usage

"क्या air-gapped ग्राहक के लिए हम इसे offline चला सकते हैं?"

"Model provider को किसी स्थानीय provider पर बदलें — उनके कंप्यूटर पर Ollama या llama.cpp। Harness को इससे फ़र्क नहीं पड़ता, वह बस दूसरे endpoint पर अनुरोध भेजता है।"

Model के चारों ओर की वे चीज़ें जो उसे agent बनाती हैं: tools, system prompt, context-window management, permissions और hooks। Claude.ai और Claude Code एक ही model पर चलते हैं, लेकिन उनके harness अलग हैं इसलिए व्यवहार अलग होता है।

Model स्वयं केवल एक काम करता है: text लेना और text देना। वह फ़ाइल नहीं पढ़ सकता, command नहीं चला सकता या पिछला turn याद नहीं रख सकता। Harness यह सब उपलब्ध कराता है। वह हर model provider request के लिए context जोड़ता है, model द्वारा माँगे गए tool calls चलाता है, tool results वापस देता है, session इतिहास रखता है, जोखिम वाले actions से पहले आपसे अनुमति माँगता है और तय करता है कि कब compact करना है। Agent loop — model प्रस्ताव देता है, harness लागू करता है, फिर दोहराएँ — harness चलाता है।

यह निदान में मायने रखता है। दो products के बीच या कल और आज के व्यवहार में अंतर हो तो अक्सर बदलने वाला model नहीं, harness होता है। अलग system prompt, अलग tools, बदला हुआ permission default या नई context-management रणनीति model बदले बिना व्यवहार बदल देते हैं। इसका अर्थ यह भी है कि आपका अधिकतर configuration harness में रहता है: AGENTS.md फ़ाइलें, permission settings और hooks, model के नहीं harness के निर्देश हैं।

उदाहरण: Claude Code, Cursor, Codex CLI — और Claude.ai, जो coding के बजाय chat harness है।

उपयोग:

“एक ही model है, फिर Claude Code files संपादित क्यों करता है और Claude.ai सिर्फ़ सवालों के जवाब क्यों देता है?”

“अलग harnesses हैं — Claude Code के पास filesystem tools, अलग system prompt और permission layer है। यहाँ model नहीं बदला।”

Harness से model provider तक और वापस आने का एक चक्र। Harness मौजूदा context भेजता है; provider एक जवाब लौटाता है (tool call या अंतिम उत्तर)। यदि agent tools चलाता है तो उपयोगकर्ता के एक message से कई model provider requests शुरू हो सकती हैं — हर tool result के बाद एक और request आती है।

हर request में सब कुछ होता है: system prompt, अब तक की पूरी बातचीत और हर tool result। Model stateless है, इसलिए provider requests के बीच कुछ नहीं रखता — request चालीस वही सब फिर भेजती है जो request उनतालीस ने भेजा था, साथ में एक और tool result। इस दोहराव को किफ़ायती बनाने के लिए prefix cache है।

Request बिलिंग की इकाई भी है। Input tokens, output tokens और cache discounts हर request के हिसाब से गिने जाते हैं; इसलिए साधारण दिखने वाला सवाल भी अप्रत्याशित रूप से महँगा हो सकता है: लागत आपके message के अनुपात में नहीं, बल्कि requests की संख्या और हर request में भेजे गए context के आकार के अनुपात में है।

Request और turn को अलग समझना उपयोगी है। Turn आपके साथ एक आदान-प्रदान है; “failing test ठीक करें” जैसा एक turn requests की शृंखला बन सकता है:

एक turn के लिए छह requests — हर एक पूरा context फिर भेजती है। Tokens कहाँ गए यह सोचें तो turns नहीं, requests गिनें।

उपयोग:

“एक सवाल में चालीस हज़ार tokens खर्च हो गए?”

“Tool calls देखें — बारह grep, आठ read, चार edits। हर tool result एक और model provider request शुरू करता है और हर बार पूरा session prefix फिर भेजा जाता है।”

हर model provider request पर harness द्वारा भेजे जाने वाले Tokens — system prompt, बातचीत का इतिहास, tool results, वह सब कुछ जिसे model लिखने से पहले पढ़ता है। output tokens से कम दर पर बिल बनता है, क्योंकि इन्हें संसाधित करना output tokens बनाने से सस्ता है।

AI coding करते समय input tokens आपके बिल का बड़ा हिस्सा होते हैं। Model stateless है, इसलिए हर turn में पूरा session input के रूप में फिर भेजा जाता है: आपका पहला संदेश, हर जवाब और उसके बाद से आए हर tool result सहित। पचासवीं turn के input में पिछली उनचास turns शामिल होती हैं। एक model provider request कुछ सौ output tokens बना सकता है, लेकिन संचित इतिहास के एक लाख input tokens फिर भेज सकता है।

Prefix cache लागत घटाता है: पिछले request से हूबहू मेल खाने वाले इतिहास पर पूरी input दर के बजाय सस्ते cache tokens की दर लगती है। Input की लागत फिर भी परेशान करे, तो दोबारा भेजी जाने वाली सामग्री कम करें — कामों के बीच clearing या compacting करके।

Usage

"बिल बहुत आ रहा है, जबकि agent मुश्किल से कुछ लिख रहा है।"

"यह input tokens का खर्च है — हर turn में पूरा session फिर भेजा जाता है। Prefix cache न हो, तो हर request में इतिहास का भुगतान फिर करना पड़ता है।"

वे Tokens जिन्हें model वापस बनाता है। input tokens से अधिक दर पर बिल बनता है — आम तौर पर लगभग पाँच गुना — क्योंकि इन्हें बनाने में अधिक गणना लगती है।

मॉडल जो कुछ भी लिखता है, सब गिना जाता है: आप जो गद्य पढ़ते हैं, वह code जो यह निकालता है, tool calls और जवाब देने से पहले मॉडल द्वारा किया गया कोई भी विस्तृत विचार। आख़िरी बात लोगों को चौंकाती है — reasoning tokens पर output की तरह बिल लगता है, भले ही harness अक्सर उन्हें आपको न दिखाए; और effort बढ़ाने पर ऐसे अधिक tokens खर्च होते हैं।

Output tokens session की गति भी तय करते हैं। Model input तेज़ी से पढ़ता है, लेकिन output एक-एक token करके बनाता है; इसलिए जब कोई turn धीमी लगे, तो लगभग हमेशा output लिखा जा रहा होता है, input पढ़ा नहीं जा रहा होता। लंबे इंतज़ार का आम तौर पर अर्थ है कि लंबा जवाब आ रहा है।

Usage

"Inputs छोटे हैं, फिर भी refactor session तेज़ी से credit खर्च कर रहा है।"

"Agent बदलाव करने के बजाय पूरी फ़ाइलें फिर से लिख रहा है। Output tokens की लागत input दर से लगभग पाँच गुना है — उससे edits निकलवाएँ, बिल घटेगा।"

provider की ओर का वह संग्रहण जो लगातार model provider requests को एक साझा उपसर्ग पर फिर से काम करने से बचाता है। जब किसी अनुरोध की शुरुआत हाल के अनुरोध की शुरुआत से मेल खाती है — वही system prompt, किसी बिंदु तक वही इतिहास — तो प्रदाता अपना पिछला काम दोबारा इस्तेमाल करता है और उन tokens के लिए cache tokens की बहुत कम दर से शुल्क लेता है।

कैश इसलिए लाभ देता है क्योंकि सत्र केवल अंत में जोड़ते हुए बढ़ते हैं। हर अनुरोध पूरा इतिहास input tokens के रूप में फिर भेजता है (क्यों, इसके लिए वह प्रविष्टि देखें), और सामान्य session में इतिहास केवल अंत में बदलता है — हर अनुरोध पिछला अनुरोध और कुछ नए संदेश होता है। प्रदाता लंबे साझा आरंभिक हिस्से को एक बार संसाधित कर उसका परिणाम रखता है और उपसर्ग जहाँ समाप्त होता है वहाँ से आगे बढ़ता है। कैश के बिना 50-turn वाले सत्र में पहली बारी को 50 बार फिर संसाधित करने का भुगतान करना पड़ता।

कैश की अवधि भी समाप्त होती है। कोई प्रविष्टि कितनी देर तक सक्रिय रहती है, यह मॉडल प्रदाता के अनुसार बदलता है — आम तौर पर मिनटों तक, घंटों तक नहीं। सत्र को इस अवधि से अधिक समय तक निष्क्रिय छोड़ें, तो अगला अनुरोध पूरी कीमत पर उपसर्ग फिर बनाता है; उसके बाद कैशिंग दोबारा शुरू हो जाती है। यह मुख्यतः harness बनाने वालों की चिंता है; उपयोगकर्ता को बस इतना दिखता है कि लंबे विराम के बाद के अनुरोध पहले वाले अनुरोधों से महँगे पड़ते हैं।

Usage

"Why did the bill spike halfway through the session?"

"Harness started injecting the current time into the system prompt every turn. Prefix cache breaks at the first changed token, so every request after that billed at full rate."

पिछले model provider request से provider ने जिन Input tokens को कैश किया है, ताकि उन्हें दोबारा संसाधित न करना पड़े। जब लगातार requests का उपसर्ग समान होता है, तो provider prefix cache से उस काम को दोबारा इस्तेमाल करता है और कैश किए गए हिस्से पर बहुत कम दर से शुल्क लगाता है। लंबे sessions को किफ़ायती बनाने का यही उपाय है — इसके बिना हर turn में पूरे इतिहास के लिए फिर से भुगतान करना पड़ता।

यह क्यों मायने रखता है, इसका कारण sessions का बिल बनाने का तरीका है। model stateless है, इसलिए हर request पूरी बातचीत फिर भेजता है — system prompt, हर संदेश, हर tool result — input tokens के रूप में। पचासवीं turn तक हर request में पचास turns का इतिहास होता है और हर बार उस सब पर पूरी दर से भुगतान करना पड़ता। Cache हिसाब बदलता है: समान उपसर्ग में provider पहले से संसाधित कर चुका tokens पर cache tokens की दर से शुल्क लगता है, जो अक्सर input दर का दसवाँ हिस्सा या उससे भी कम होती है। लंबे session में भेजी गई अधिकांश सामग्री cache tokens होती है और बिल काबू में रहता है।

एक उदाहरण दिखाता है कि tokens कब कैश होते हैं और कब नहीं। हर अक्षर बातचीत की सामग्री का एक खंड है; हर request अब तक की पूरी बातचीत भेजता है:

Cache एक खास तरीके से नाज़ुक है: यह सटीक उपसर्गों का मिलान करता है। बातचीत में पहले की कोई चीज़ बदले — harness सामग्री का क्रम बदले, timestamp अपडेट हो या फ़ाइल का रूप बदले — तो वहाँ से आगे cache miss होता है और बाकी सब पर पूरी input दर से शुल्क लगता है। कुछ मिनट निष्क्रिय रहने के बाद caches की अवधि भी समाप्त हो जाती है, इसलिए लंबे विराम के बाद लौटे session को अपना इतिहास एक बार फिर भेजने का पूरा भुगतान करना पड़ता है। जब session की लागत बिना स्पष्ट कारण बढ़े, तो usage report में cache tokens और input tokens की तुलना करें — cache की गड़बड़ी सबसे पहले वहीं दिखेगी।

Usage

"लंबे sessions की लागत बहुत ज़्यादा है — refactor के आठ डॉलर लग गए।"

"Cache tokens देखें। अगर harness turns के बीच system prompt या files का क्रम बदल रहा है, तो उपसर्ग टूटता है और हर request पर input की पूरी दर फिर चुकानी पड़ती है।"

जानकारी आगे नहीं ले जाता। Model, model provider requests के पार stateless है — हर request में पूरा context window फिर भेजना पड़ता है क्योंकि model के पास और कुछ देखने का तरीका नहीं है। Agent डिफ़ॉल्ट रूप से sessions के पार stateless होता है: नया session खाली शुरू होता है, पहले वाले sessions का कोई निशान नहीं। इसका जोड़ा stateful है।

Model स्वयं हमेशा stateless रहता है: training के बाद उसके parameters स्थिर होते हैं और inference के दौरान आप जो भी करें, वे नहीं बदलते। Model आपके सुधारों से नहीं सीखता, कल वही बात बताए जाने को याद नहीं रखता और आपको जानने नहीं लगता — बातचीत चाहे ऐसा महसूस कराए। Session के भीतर निरंतरता का एहसास harness बनाता है: वह transcript रखता है और हर request के साथ फिर भेजता है। Model बातचीत याद नहीं करता; उसे दोबारा पढ़ता है।

व्यावहारिक नतीजा यह है: sessions के पार कोई बात याद रखवानी हो तो उसे ऐसी जगह लिखना होगा जहाँ agent उसे फिर पढ़े। इसी काम के लिए AGENTS.md फ़ाइलें, memory systems और handoff artifacts हैं — ऐसी फ़ाइलें जो भविष्य के sessions के context में लोड होती हैं और model की अनुपस्थित memory की जगह लेती हैं। Agent वही गलती बार-बार करे जिसे आप पहले सुधार चुके हैं, तो सवाल यह नहीं कि उसने सीखा क्यों नहीं — वह सीख नहीं सकता — बल्कि यह है कि वह सुधार कहाँ लिखें ताकि हर भविष्य का session उसे पढ़ सके।

उपयोग:

“हर बार clear करने पर यह convention क्यों भूल जाता है?”

“Model stateless है — नया session खाली शुरू होता है। बात आगे ले जानी है तो AGENTS.md या उस memory file में लिखें जिसे harness session शुरू होने पर लोड करता है।”

वह प्रासंगिक जानकारी जिस तक agent की अभी पहुँच है। यह अमूर्त संज्ञा है — न कि वह कच्चा input जिसे मॉडल देखता है (वह context window है), न चल रहा इतिहास (वह session है), बल्कि कार्य के लिए प्रासंगिक वह जानकारी जो agent जानता है। "किसी चीज़ को context में लोड करना" का अर्थ उसे इस जानकारी का हिस्सा बनाना है; "context engineering" उसे चुनकर व्यवस्थित करने की विद्या है।

ये तीनों शब्द साफ़ तौर पर अलग हैं:

यह अंतर इसलिए मायने रखता है कि context गुणवत्ता का माप है, मात्रा का नहीं। Context window लगभग भर सकती है और फिर भी context खराब हो सकता है — पुराने tool output के हज़ारों tokens, जिनमें से कोई भी मौजूदा काम के बारे में नहीं। यह लगभग खाली भी हो सकती है और context उत्कृष्ट हो सकता है: वह एक type definition जिस पर काम निर्भर है।

रोज़मर्रा की ज़्यादातर विफलताओं का कारण context होता है। जब agent कोई API गढ़ता है, किसी निर्णय का खंडन करता है या schema का अनुमान लगाता है, तो पहला सवाल यह है कि ऐसा करते समय context में क्या था — आम तौर पर प्रासंगिक तथ्य कभी लोड ही नहीं हुआ था या attention degradation के नीचे दब गया था। समाधान है सावधानी से चुनना: काम के लिए ज़रूरी सामग्री लोड करें और गैरज़रूरी सामग्री बाहर रखें।

Usage

"यह ऐसे fields गढ़ता रहता है जो type में हैं ही नहीं।"

"Type file context में नहीं है — यह call sites देखकर अनुमान लगा रहा है। पहले definition पढ़वाएँ।"

हर model provider request पर model जो कुछ देखता है। इसकी सीमा होती है, यह model के अनुसार बदलता है और यही एकमात्र सतह है जिसके माध्यम से model कुछ भी देखता है।

यह tokens का एक ही क्रम है: system prompt, अब तक की बातचीत और harness द्वारा लौटाया गया हर tool result। यदि कोई बात उस क्रम में है तो model उसका उपयोग कर सकता है; यदि नहीं, तो उसे उसके अस्तित्व का पता नहीं — न आपका codebase, न कल संपादित फ़ाइल और न तीन sessions पहले दिया निर्देश। Window के बाहर की कोई भी बात प्रभाव डालने से पहले अंदर लानी होती है, आमतौर पर tool call से।

सीमित होने का अर्थ है कि यह भरता है। हर turn में और चीज़ें जुड़ती हैं — आपके messages, model के जवाब और tool results — और लंबा session अंततः सीमा तक पहुँचता है, जिससे compaction या clearing करना पड़ता है। इसका यह भी अर्थ है कि window में हर चीज़ प्रतिस्पर्धा करती है: लोड किया गया हर token बाकी के लिए उपलब्ध जगह एक कम करता है, और अनावश्यक सामग्री भी model का attention लेती है। व्यावहारिक तरीका है window को बजट मानना — काम की सामग्री लोड करें, बाकी बाहर रखें।

इससे बचें: “memory” — context window कामकाजी state है और sessions के पार कायम नहीं रहती। Memory उस पर बनी अलग अवधारणा है।

उपयोग:

“क्या मैं पूरे monorepo को prompt में चिपका दूँ?”

“Context window में 200k tokens हैं — repo का शायद पाँचवाँ हिस्सा। काम से जुड़ी फ़ाइलें चुनें, बाकी को tool call के पीछे रहने दें।”

जानकारी आगे ले जाता है। Session, turns के दौरान stateful होता है — session चलते समय context जमा होता है, इसी कारण लंबे sessions dumb zone में भटकते हैं। Agent को sessions के पार stateful बनाया जा सकता है: memory system जोड़कर, जो जानकारी environment में सहेजता है और भविष्य के sessions की शुरुआत में उसे फिर लोड करता है। Model कभी stateful नहीं होता; निरंतरता का आभास harness द्वारा context फिर से देने से बनता है। इसका जोड़ा stateless है।

हर layer में state कहाँ रहती है:

हर layer की statefulness उसके नीचे की layer में रखी चीज़ को फिर पढ़ने से बनती है: session निरंतर लगता है क्योंकि harness stateless model को message history फिर भेजता है; agent sessions के पार बातें याद रखता है क्योंकि harness environment से फ़ाइलें फिर लोड करता है। Model में स्वयं कोई state कभी नहीं रखी जाती।

State हमेशा वांछित नहीं होती। आगे ले जाई गई हर बात अगली चीज़ को प्रभावित करती है, इसलिए session के आरंभ में बना गलत अनुमान भी आगे चला जाता है। Clearing session की state जानबूझकर फेंककर लिखी हुई जानकारी से शुरुआत करना है।

उपयोग:

“उसे कल की मेरी पसंद याद थी — क्या इसका मतलब है कि model ने उन्हें सीख लिया?”

“नहीं, agent stateful है क्योंकि harness ने उन्हें memory file में लिखा और session शुरू होते समय फिर लोड किया। Model ने कल की कोई बात स्वयं नहीं देखी।”

एक model को harness, tools, system prompt और context window के साथ चलाया जाता है, और वह उपयोगकर्ता के साथ turns करता है। Claude Code एक agent है। Cursor एक agent है। Claude.ai एक agent है। Agent वही है जिससे आप वास्तव में बात करते हैं — उद्देश्य के लिए कॉन्फ़िगर किया गया, गति में काम करता model।

इस डिक्शनरी के अधिकांश शब्दों के विपरीत, “agent” किसी यांत्रिक हिस्से का नाम नहीं है। Model parameters की एक फ़ाइल है; harness ऐसा सॉफ़्टवेयर है जिसे आप चला सकते हैं। Agent इनमें से कोई नहीं — यह वह इकाई है जिससे आप बात कर रहे हैं। लोग AI को लगातार मानवीय रूप देते हैं, और agent वही मानवीकृत इकाई है: जिसे आप काम सौंपते हैं, जो आपका संदेश पढ़कर जवाब देती है, और “उसने फिर से build तोड़ दिया” में “उसने”। जब आप कहते हैं कि agent ने कुछ किया, तो आपका मतलब model-plus-harness से है; लेकिन आप इस संयोजन को एक ही कर्ता के रूप में संबोधित करते हैं।

यह विचार AI की इस लहर से पुराना है। सॉफ़्टवेयर एजेंट — ऐसे प्रोग्राम जिन्हें आप लक्ष्य सौंपते हैं और जो आपकी ओर से काम करते हैं — AI के अस्तित्व में आने से ही अवधारणा रहे हैं।

इससे बचें: “the AI”, “the bot” (बहुत अस्पष्ट — इनसे पता नहीं चलता कि आपका मतलब parameters से है या harness में चल रही इकाई से)।

उपयोग:

“माइग्रेशन के लिए आप कौन-सा agent इस्तेमाल कर रहे हैं?”

“स्थानीय काम के लिए Claude Code, UI काम के लिए Cursor — नीचे वही model है, harness अलग-अलग हैं।”

वे निर्देश जिन्हें harness हर model provider request से पहले जोड़ता है — agent का स्थायी विवरण: वह कौन है, उसे कैसे व्यवहार करना है, वह किन tools का उपयोग कर सकता है और किन परंपराओं का पालन करना है। आम तौर पर ये session भर स्थिर रहते हैं।

System prompt harness विक्रेता लिखता है, आप नहीं; और coding harness में यह बड़ा होता है — अक्सर व्यवहार संबंधी नियमों, tool विवरणों और edge-case handling के हज़ारों tokens, जिनका हर turn में input tokens के रूप में भुगतान होता है। आपके अपने स्थायी निर्देश भी इसके साथ जाते हैं: AGENTS.md जैसी फ़ाइलें session की शुरुआत में system prompt के पास लोड होती हैं, इसलिए model आपका संदेश देखने से पहले विक्रेता के brief और आपके निर्देश एक साथ पढ़ता है।

हर request में एक जैसा होने के कारण यह prefix cache की शुरुआत बनता है — यही एक कारण है कि harness पूरे session में इसे स्थिर रखते हैं, बीच-बीच में बदलते नहीं।

मॉडल को user messages से ऊपर system prompt को प्राथमिकता देना सिखाया जाता है। इसलिए जब agent ऐसी परंपरा पर अड़ा रहे जिसके लिए आपने कभी नहीं कहा, या output को ऐसे format में दे जिसे आप बदलवा न सकें, तो आम तौर पर वह अपने system prompt का पालन कर रहा होता है — और आपका message दलील हार रहा होता है। कुछ harness अनुकूलित किए जा सकते हैं: वे आपको system prompt तक पूरा access देते हैं, ताकि आप पढ़ सकें कि agent को असल में क्या बताया जा रहा है और उसे बदल सकें।

Usage

"Two harnesses, same model, totally different behavior on the same prompt."

"Different system prompts. One's tuned for terse code edits, the other for explaining — that's where the divergence lives, before your message even arrives."

Agent के साथ बातचीत का एक सीमित दौर। यह खाली शुरू होता है, messages, tool results और पढ़ी गई फ़ाइलें जमा करता है, और cleared, बंद या नए session में compacted होने पर समाप्त होता है। Session ही context window को भरता है: context window डिब्बा है तो session वह सामग्री है जो धीरे-धीरे उसमें भरती है। एक context window से बड़ा काम कई sessions में बाँटना पड़ता है।

Session का message इतिहास agent की working memory है। Model stateless है, इसलिए उसे जो बातें याद लगती हैं — आपने क्या माँगा, tests ने क्या कहा, तीन turns पहले उसने क्या तय किया — वे सब message history में होती हैं और हर model provider request के साथ फिर भेजी जाती हैं। जो session में नहीं है, वह agent के लिए अस्तित्व में नहीं।

Session समाप्त होते ही वह memory भी समाप्त हो जाती है। नया session कुछ भी न जानकर शुरू होता है: कल के अंत तक आपका codebase अच्छी तरह जानने वाला agent आज सुबह उसमें से कुछ नहीं जानता। जो बचता है वह filesystem है — एक session में लिखी फ़ाइलें अगला पढ़ सकता है; इसी पर handoffs, memory systems और AGENTS.md निर्भर हैं।

Session कहाँ समाप्त हो, यह आप चुनते हैं। Session में हर चीज़ बाद के हर turn को प्रभावित करती है, इसलिए एक ही session में किए असंबंधित काम अगले जवाब को रंग देते हैं। हर session में एक काम रखने से context प्रासंगिक रहता है; काम पूरा होना clear करने का स्वाभाविक बिंदु है।

उपयोग:

“बिखरने से पहले एक session कितनी देर चल सकता है?”

“काम पर निर्भर है — केंद्रित refactor खुली-ended research से अधिक समय तक तीक्ष्ण रहता है। Session भर जाए तो hand off या compact करें, ज़ोर लगाकर जारी न रखें।”

उपयोगकर्ता का एक message और उसके जवाब में agent द्वारा किया गया सब काम, जब तक वह नियंत्रण वापस उपयोगकर्ता को न दे। इसमें एक या अधिक model provider requests होते हैं — यदि agent tools चलाए तो कई। स्पष्टीकरण का सवाल turn बंद करता है; आपका जवाब अगला turn शुरू करता है। क्रम है session > Turn > Model provider request।

Turn को नाम देना इसलिए उपयोगी है कि उसकी लंबाई आपका नहीं, agent का निर्णय है। आप एक message देते हैं; agent तय करता है कि जवाब देने से पहले कितने tool calls जोड़े। Turn एक वाक्य का उत्तर भी हो सकता है या बीस मिनट पढ़ने, संपादित करने और tests चलाने का काम। यह एक ही गुण के दो पहलू हैं: लंबे turns AFK काम संभव बनाते हैं, और बिना निगरानी लंबे turns में गड़बड़ी भी होती है — agent नियंत्रण लौटाए तब तक वह आपके आशय से बहुत दूर भटक चुका हो सकता है।

दिशा देने की स्वाभाविक इकाई turn भी है। Turn के भीतर सब कुछ आपके बिना होता है; turns के बीच के अंतराल वे क्षण हैं जब आप दिशा बदलते हैं। अधिकतर harnesses यह कठिनाई घटाते हैं: agent रोककर दिशा बदलने के लिए आप turn के बीच में रोक सकते हैं, या उसके काम करते समय message लिख सकते हैं जिसे turn पूरा होने पर वह पढ़ेगा। यदि turns के नतीजों से बार-बार असंतुष्ट हों, तो आम समाधान छोटे turns माँगना है — पहले योजना, फिर एक-एक कदम — इससे स्वायत्तता घटती है लेकिन दिशा देने के लिए अंतराल अधिक मिलते हैं।

उपयोग:

“एक turn में दो मिनट लगे?”

“उसने उसी turn के भीतर चौदह tool calls किए — हर एक अलग model provider request है। Agent नियंत्रण लौटाए उससे पहले latency जुड़ती जाती है।”

वह दुनिया जिस पर agent काम करता है — harness के बाहर की हर चीज़, जिसे agent tool results से देखता है और tool calls के ज़रिए बदलता है। Harness agent को चलाता है; environment वह है जिसमें agent काम करता है। `AGENTS.md` जैसी फ़ाइल environment में रहती है; harness उसे context window में लोड करता है। filesystem environment का सबसे आम प्रकार है, लेकिन एकमात्र नहीं (database, remote API और browser session — ये सब environment हो सकते हैं)।

Agent environment को केवल देखने पर ही देखता है। Environment के बारे में उसे जो कुछ पता है, वह किसी tool result से आया है, इसलिए उसकी तस्वीर snapshots का संग्रह है; हर snapshot उस पल सही होता है जब लिया गया था। Agent के फ़ाइल पढ़ने के बाद अगर वह बदल जाए — आप उसे हाथ से संपादित करें या build step उसे फिर बनाए — तो agent पुरानी प्रति के आधार पर तर्क करता रहता है, जब तक कोई चीज़ उसे दोबारा पढ़ने के लिए न कहे। Agent का किसी ऐसी फ़ाइल का आत्मविश्वास से वर्णन करना जो अब वैसी नहीं दिखती, आम तौर पर इसी वजह से होता है: environment बदल गया, snapshot नहीं।

Environment वह परत भी है जो बनी रहती है — हमेशा stateful रहने वाली एकमात्र परत। Session समाप्त होने पर उसका context चला जाता है, लेकिन environment में लिखी फ़ाइलें अगला session पढ़ने के लिए बनी रहती हैं — इसी पर memory systems, handoff artifacts और `AGENTS.md` निर्भर करते हैं। Agent को कल भी जो कुछ पता होना चाहिए, उसे environment में पहुँचना होगा।

आप तय करते हैं कि environment कितना बड़ा है। Sandbox उसे छोटा करके agent की पहुँच सीमित करता है; tool जोड़ने से वह फैलता है और database या API तक पहुँच देता है। सीमा के भीतर जो है, agent उसे देख और बदल सकता है; बाहर की चीज़ें agent के लिए मौजूद ही नहीं होतीं। Agent के काम में मदद के लिए environment को कितनी अच्छी तरह तैयार किया गया है, यही codebase का AX है।

Avoid"environment" का इस्तेमाल runtime या harness के लिए करना — harness आवरण है, environment कार्यक्षेत्र।

Usage

"Agent staging DB schema नहीं देख सकता।"

"इसे environment से जोड़ें — staging पर केवल पढ़ने की अनुमति वाला `psql` tool दें। Harness ठीक है, उसके पास बस कार्रवाई करने के लिए कुछ नहीं है।"

फ़ाइलों और directories का ऐसा tree जिसे agent पढ़ता, लिखता और जिसके भीतर commands चलाता है — coding agent के लिए environment का डिफ़ॉल्ट प्रकार। AGENTS.md, skills, source code, build scripts और tool configs सभी filesystem में रहते हैं। जब harness “आपके project में शुरू होता है”, तो वह agent को filesystem पर भेज रहा होता है।

Agent filesystem को केवल tool calls के माध्यम से छूता है — फ़ाइल पढ़ना, लिखना या shell command चलाना। Tool call द्वारा लोड होने तक disk पर कुछ भी context window में नहीं आता; इसी वजह से agent window से कहीं बड़े repository में काम कर सकता है: filesystem में सब कुछ होता है, context में केवल वही जो मौजूदा काम ने पढ़ा है। कुछ harness मौजूदा directory के फ़ाइलनाम डिफ़ॉल्ट रूप से context window में लाते हैं — सामग्री नहीं, केवल tree — जो context pointers की तरह काम करते हैं: agent देखता है कि क्या मौजूद है और ज़रूरत की फ़ाइलें पढ़ता है।

यह आपके साथ साझा भी है। Agent जिन फ़ाइलों को संपादित करता है, वे वही हैं जिन्हें आप editor में खोलते और git में diff करते हैं — filesystem वह साझा workspace है जहाँ आप agent के काम की समीक्षा करते हैं।

उपयोग:

“यह मेरी AGENTS.md क्यों नहीं पढ़ रहा?”

“यह किसी दूसरे filesystem पर चल रहा है — sandbox ने project root नहीं, parent directory mount की है। Harness को सही जगह पर भेजें।”

ऐसा फ़ंक्शन जिसे harness, agent के कॉल करने के लिए उपलब्ध कराता है — Read, Write, Bash, Search। Tools के ज़रिये agent environment को समझता और उस पर कार्रवाई करता है: वह environment को केवल tool results के माध्यम से देख सकता है और केवल tool calls के माध्यम से बदल सकता है। हर tool call पर एक अतिरिक्त model provider request लगता है, क्योंकि अगला कदम तय करने से पहले परिणाम वापस model तक जाना होता है।

अधिकांश coding agents में शामिल tools:

किसी tool की तीन परिभाषित विशेषताएँ हैं: उसका नाम, वह क्या करता है इसका विवरण और उसके पैरामीटर का schema। Harness हर request के साथ ये परिभाषाएँ model को भेजता है, और model उसी तरह tool चुनता है जैसे बाकी सब कुछ तैयार करता है — tokens लिखकर; यहाँ वह arguments वाला एक संरचित call होता है। Model स्वयं कुछ execute नहीं करता; harness call पढ़ता है, function चलाता है और परिणाम वापस भेजता है।

Tools की सूची तय करती है कि agent क्या कर सकता है। कम tools वाला सक्षम model भी सीमित agent है: वह अपना हर काम उपलब्ध किसी भी चीज़ से करेगा, इसी कारण agents Bash पर इतना निर्भर करते हैं — shell एक ऐसा tool है जो अधिकांश system तक पहुँचता है। Agent को कोई क्षमता साफ़ तौर पर देने के लिए उसके लिए tool जोड़ें; MCP harness के बाहर के tools जोड़ने का मानक है।

हर request पर tool परिभाषाएँ context में जगह लेती हैं, इसलिए बड़े tool set की लागत कोई tool बुलाए जाने से पहले ही बनी रहती है — और एक जैसे विवरण वाले बहुत से tools model के लिए सही tool चुनना कठिन बनाते हैं।

उपयोग:

“क्या agent सीधे staging से query कर सकता है?”

“Harness में `psql` tool जोड़ें, staging पर केवल पढ़ने की अनुमति के साथ। इसके लिए tool न हो तो filesystem से बाहर क्या है, agent देख नहीं सकता।”

मॉडल का आउटपुट, जिसमें टूल का नाम और उसके तर्क दिए होते हैं — बस संरचित पाठ। यह अपने आप कुछ नहीं करता; harness को इसे पढ़कर निष्पादित करना पड़ता है। मॉडल इसे एक मॉडल प्रदाता अनुरोध में तैयार करता है।

टूल कॉल का जीवनचक्र:

एजेंट के काम की एक बारी में आम तौर पर ऐसे कई अनुरोध-उत्तर चक्र एक के बाद एक जुड़ते हैं।

क्योंकि यह कॉल भी बाकी सबकी तरह अगले टोकन की भविष्यवाणी से बनती है, इसलिए इसमें भी मॉडल के किसी अन्य आउटपुट जैसी गलती हो सकती है: ऐसा पथ जो मौजूद न हो, ऐसा फ़्लैग जिसे कमांड स्वीकार न करे, या सही होने के बजाय केवल विश्वसनीय लगने वाले तर्क। harness लिखे हुए निर्देशों को निष्पादित करता है, आशय को नहीं — गलत टाइप किया गया पथ सहजता से विफल नहीं होता, वह गलत फ़ाइल संपादित कर देता है।

उपयोग:

"उसने कहा कि परीक्षण चला दिए, लेकिन फ़ाइलों के टाइमस्टैम्प नहीं बदले हैं।"

"ट्रांसक्रिप्ट देखें — क्या उसने सचमुच टूल कॉल भेजी थी, या केवल परीक्षण चलाने का वर्णन किया था? कॉल मॉडल बनाता है, लेकिन अगर harness ने उसे निष्पादित नहीं किया, तो कुछ नहीं हुआ।"

वह सामग्री जो harness, tool call निष्पादित करने के बाद वापस भेजता है — फ़ाइल की सामग्री, command का output, या error। agent को environment का यही एक दृश्य मिलता है। यह अगले model provider request में model के पास वापस जाती है, जहाँ मॉडल तय करता है कि इसके साथ क्या करना है। Tool call और tool result एक ही आदान-प्रदान के दो सिरे हैं और दोनों एक turn के भीतर आते हैं।

Tool result का जीवनचक्र:

बाकी session के दौरान परिणाम context में बना रहता है। Tool results अक्सर coding session के context का बड़ा हिस्सा होते हैं: हर पढ़ी गई फ़ाइल, हर चलाया गया test और हर search पूरी तरह उसमें पहुँचता है और tokens घेरता रहता है, भले ही वह अब उपयोगी न हो। कुछ बड़े परिणाम — जैसे बहुत लंबा test log या पूरी पढ़ी गई generated file — बातचीत से भी तेज़ी से session को context window की सीमा तक पहुँचा सकते हैं।

क्योंकि मॉडल को केवल यही परिणाम दिखता है, वह इसके पीछे का environment जाँच नहीं सकता। अगर output काट दिया गया, command चुपचाप विफल हुआ या harness ने सामग्री की जगह error लौटाई, तो मॉडल को दी गई जानकारी के आधार पर ही तर्क करेगा। जब agent की आपके system के बारे में तस्वीर गलत लगे, तो tool results देखें: transcript में कहीं कोई ऐसा परिणाम होगा जो आपकी सही जानकारी से अलग कुछ कहता है।

Usage

"यह फ़ाइल के बारे में ऐसे तर्क कर रहा है जैसे वह खाली हो।"

"Tool result में सामग्री के बजाय permission denial आया था। मॉडल ने केवल error string देखी — फ़ाइल देखने का उसके पास कोई और तरीका नहीं है।"

Model Context Protocol. बाहरी टूल सर्वरों को harness में जोड़ने का एक प्रोटोकॉल — यानी किसी agent को harness में पहले से उपलब्ध टूलों से आगे tools कैसे मिलते हैं। एजेंट कभी “MCP को कॉल” नहीं करता; वह किसी टूल को कॉल करता है, और संयोग से harness को वह टूल MCP सर्वर से मिला होता है। यह संसाधन (केवल पढ़ने योग्य डेटा) और प्रॉम्प्ट (फिर से इस्तेमाल किए जा सकने वाले टेम्पलेट) भी उपलब्ध कराता है, लेकिन इसका मुख्य उपयोग टूल उपलब्ध कराना है।

यह प्रोटोकॉल एक एकीकरण समस्या हल करता है। किसी मानक के बिना, हर harness को अपना Linear एकीकरण, अपना Slack एकीकरण और अपना डेटाबेस एकीकरण अलग-अलग लिखकर बनाए रखना पड़ता। MCP के साथ एकीकरण सर्वर के रूप में एक बार लिखा जाता है, और MCP-संगत कोई भी harness उसका उपयोग कर सकता है। Harness सर्वर से जुड़ता है, सर्वर अपने उपलब्ध टूलों की घोषणा करता है, और वे टूल अंतर्निहित टूलों के साथ एजेंट को उपलब्ध हो जाते हैं।

इसकी कीमत context में चुकाई जाती है। सर्वर द्वारा घोषित हर टूल एक परिभाषा के रूप में आता है — नाम, विवरण और पैरामीटर स्कीमा — और model केवल उन्हीं टूलों को कॉल कर सकता है जिनके बारे में उसे जानकारी हो। भोला तरीका सभी परिभाषाएँ पहले से context window में लोड कर देता है: कुछ उदार सर्वर इंस्टॉल करें और session आपके कुछ भी टाइप करने से पहले ही टूल स्कीमा के हज़ारों tokens के साथ शुरू होता है; इस तरह उस काम के टूलों पर attention budget खर्च होता है जिनकी ज़रूरत कभी नहीं पड़ेगी।

कई harness अब टूल खोज से इस समस्या को कम करते हैं: पूरी परिभाषाओं के बजाय context उपलब्ध टूलों के लिए एक context pointer रखता है — एजेंट नाम या उद्देश्य से टूल खोजता है और ज़रूरत पड़ने पर ही उसकी परिभाषा लोड करता है। यदि आपके harness में यह सुविधा नहीं है, तो पहले से लगने वाली लागत बनी रहती है; इसलिए केवल वही सर्वर सक्षम करना ठीक है जिनकी परियोजना को वास्तव में ज़रूरत है।

उपयोग:

“एजेंट को Linear से टिकट पढ़ने हैं।”

“Linear MCP सर्वर इस्तेमाल करने के लिए harness कॉन्फ़िगर करें — यह Linear API को ऐसे टूलों के रूप में उपलब्ध कराता है जिन्हें एजेंट कॉल कर सकता है। इससे कस्टम टूल रैपर लिखने की ज़रूरत बचती है।”

वह सूचना जो harness, पहले से मंज़ूर न की गई tool call निष्पादित करने से पहले उपयोगकर्ता को दिखाता है। model tool call बनाता है; उसे तुरंत चलाने के बजाय harness रुककर पूछता है। मंज़ूर करें तो वह चलती है; मना करें तो harness उस मनाही को tool result के रूप में मॉडल को वापस बताता है। जोखिमपूर्ण या संवेदनशील कामों में harness द्वारा किसी इंसान को loop में शामिल करने का तरीका।

Permission request का जीवनचक्र:

किसी अनुरोध को मना करना agent को दिशा देता है। मॉडल मनाही को किसी और tool result की तरह पढ़ता और उस पर प्रतिक्रिया देता है — वह दूसरा तरीका आज़माता है या पूछता है कि आप क्या पसंद करेंगे। ज़्यादातर harness आपको मनाही के साथ संदेश जोड़ने देते हैं; इससे अनुरोध दिशा देने का अवसर बन जाता है: "ऐसे नहीं, इसके बजाय migration script इस्तेमाल करो" ठीक उसी समय पहुँचता है जब मॉडल तय कर रहा होता है कि आगे क्या करना है।

इसकी कीमत यह है कि हर अनुरोध में आपको तत्काल जवाब देना पड़ता है। Agent आपके जवाब तक रुका रहता है, जो आपके देखते समय ठीक है लेकिन आपके अनुपस्थित होने पर समस्या है — जो agent लगातार अनुरोध करता हो उसे AFK काम पर नहीं छोड़ा जा सकता। Permission mode नियंत्रण का डायल है: कौन-सी calls स्वतंत्र रूप से चलें और कौन-सी पहले पूछें; आदर्श रूप से sandbox स्वतंत्र रूप से चलने वाले कामों की सीमा बढ़ाना सुरक्षित बनाता है।

Usage

"यह दस मिनट से permission request पर रुका है — मैं मीटिंग में था।"

"Human-in-the-loop की यही कीमत है। सुरक्षित tools को पहले से मंज़ूर करें ताकि अनुरोध केवल वास्तव में जोखिमपूर्ण calls पर आए।"

agent mode का वह हिस्सा जो अनुमति नियंत्रित करता है — कौन-सी tool calls से permission request आती है और कौन-सी अपने आप चलती हैं। Harness द्वारा ऊपर से व्यवहार संबंधी निर्देश जोड़ना शुरू करने से पहले mode प्रणालियों का मूल उद्देश्य यही था।

Harness इन modes की एक सीढ़ी देते हैं:

सीढ़ी का स्तर चुनना सुरक्षा और रुकावट के बीच का समझौता है, और दोनों तरह की विफलताएँ महसूस होती हैं। बहुत सख़्त हो, तो आप अड़चन बन जाते हैं: agent हर कुछ सेकंड में निरापद पढ़ने के लिए रुकता है, आप बिना सोचे approve पर क्लिक करते हैं और अनुमोदनों का कोई अर्थ नहीं रह जाता — आँख मूँदकर मंज़ूरी देना दोनों में सबसे खराब है, क्योंकि इसमें सारी रुकावट है और सुरक्षा कुछ भी नहीं। बहुत ढीला हो, तो agent ऐसी फ़ाइलें संपादित करता है और ऐसी commands चलाता है जिन्हें आप पहले देखना चाहते।

ढीला विकल्प sandbox के भीतर सबसे अधिक उचित ठहराया जा सकता है, जहाँ खराब tool call का असर सीमित रहता है। इसके बाहर, ज़्यादातर लोग पढ़ने को अपने आप मंज़ूरी देने और किसी भी अपरिवर्तनीय काम के लिए human in the loop रखने पर सहमत होते हैं।

Usage

"हर grep पर यह रुक गया — इससे पूरा AFK run बेकार हो गया।"

"केवल पढ़ने वाले tools के लिए permission mode ढीला करें, लेकिन लिखने और shell के लिए पूछना जारी रखें। शोध session में ज़्यादातर permission requests केवल शोर होती हैं।"

एक preset जो runtime पर agent के काम करने के तरीके को आकार देता है — यह permission mode को system prompt में जोड़े गए व्यवहार-संबंधी निर्देशों के साथ बाँधता है। उदाहरण: जोखिम वाले calls पर अनुमति माँगने वाला default, ऐसा plan mode जो edits रोककर agent को शोध की ओर ले जाए, ऐसा accept-edits mode जो edits अपने-आप स्वीकार करे, और ऐसा bypass permissions mode (बोलचाल में YOLO mode) जो सब कुछ अपने-आप स्वीकार करे। इसे mid-session बदला जा सकता है।

यह bundling ही mode को केवल permission setting से अलग करती है। Permission mode सिर्फ़ एक gate है: यह तय करता है कि कौन-से tool calls आगे जाएँ। अकेला gate ऐसा agent बनाता है जो edit करना चाहता है, पर कर नहीं सकता — वह write प्रस्तावित करता है, रोक दिया जाता है और फिर दूसरा रास्ता आज़माता है। जोड़े गए निर्देश उस चाह को हटाते हैं: plan mode केवल edits नहीं रोकता, agent को बताता है कि वह योजना बनाने के चरण में है, इसलिए वह gate के विरुद्ध ज़ोर लगाने के बजाय पढ़ता, पूछता और प्रस्ताव देता है। Gate और दिशा-निर्देश एक ही ओर काम करते हैं।

व्यवहार में, काम के दौरान आपका भरोसा बदलने पर mode भी बदलता है। वही काम कई modes से गुज़र सकता है: तरीका तय होते समय plan mode, पहले नाज़ुक edits के लिए अनुमति माँगने वाला default, agent द्वारा बदलाव समझने का प्रमाण देने पर accept-edits, और sandbox के भीतर AFK run के लिए bypass। Mode बदलने में कुछ खर्च नहीं होता: बातचीत ठीक वहीं से जारी रहती है, बस नई अनुमतियों और निर्देशों के साथ। यदि आप हर prompt को पढ़े बिना स्वीकार कर रहे हैं, तो mode आपके वास्तविक भरोसे से अधिक सख्त है; यदि आप edits को बार-बार अस्वीकार कर रहे हैं, तो वह ज़रूरत से ढीला है।

Vendor के शब्द: Claude Code इन्हें “permission modes” कहता है, Codex “approval modes” — व्यवहार को जोड़ने से पहले दोनों नाम प्रचलित थे।

उपयोग:

“मैं तो बस योजना चाहता हूँ, लेकिन यह लगातार फ़ाइलें संपादित कर रहा है।”

“Plan mode पर जाएँ — यह writes रोक देगा और शोध तक सीमित रहेगा।”

“बाद के AFK run के लिए क्या करें?”

“Bypass mode, लेकिन केवल sandbox के भीतर।”

ऐसा पृथक environment जिसके भीतर agent चलता है — container, VM, अस्थायी filesystem या सीमित-अधिकार वाला shell। यह agent की कार्रवाइयों का दायरा सीमित करता है: agent विनाशकारी commands चलाए या दुर्भावनापूर्ण कुछ डाउनलोड करे, तब भी नुकसान उसी सीमा में रहता है। यही वह सुरक्षा आधार है जो AFK को व्यवहार्य बनाता है।

Sandbox और permission mode एक ही समस्या को विपरीत दिशाओं से हल करते हैं। Permissions किसी action को चलाने से पहले पूछती हैं; sandbox यह सीमित करता है कि action चलने पर वह कहाँ तक पहुँच सकता है। Permissions के लिए आपको in the loop रहना पड़ता है — हर prompt एक व्यवधान है — और लगातार पूछने वाला session मुश्किल से स्वायत्त है। Sandbox ध्यान के बजाय infrastructure खर्च करता है: isolation जितना मज़बूत, उतने कम सवाल पूछने पड़ते हैं।

Isolation के अलग स्तर हैं:

कोई sandbox उन कार्रवाइयों को नहीं रोकता जो वैध रूप से उसकी सीमा पार करती हैं। आपके git credentials वाला agent push कर सकता है; network access वाला agent production APIs को call कर सकता है। सीमा कहाँ तक जाएगी, यह तय करें; फिर तय करें कि उसे कितनी मज़बूत बनाना है।

उपयोग:

“मैं इसे रात भर bypass-permissions चलने देना चाहता हूँ, पर अभी तैयार नहीं हूँ।”

“इसे sandbox में रखें — नया container, कोई credentials mount नहीं, बाहर network नहीं। सबसे बुरा हुआ तो यह अपना filesystem मिटाएगा और आप container हटा देंगे।”

आत्मविश्वास से भरा, सहमत होने वाला model output। इसका कारण training है: model को ऐसे जवाब देने के लिए ढाला गया जिन्हें मनुष्य पसंद करें, और मनुष्य यह सुनने से अधिक सहमति पसंद करते हैं कि वे गलत हैं। इसलिए model ने सीखा कि सहमति देने पर इनाम मिलता है — भले ही सहमति गलत हो।

इस रूप में दिखता है:

• दबाव में झुकना — आप “पक्का?” पूछें तो सही जवाब बदल देना।
• खराब input की तारीफ़ — विश्लेषण करने से पहले आपकी टूटी योजना को शानदार कहना।
• पक्षपाती framing — यदि आप बताएँ कि आपने लिखा है तो समीक्षा सकारात्मक होती है; किसी और का बताएँ तो नकारात्मक। Artifact वही, निर्णय अलग।
• नकल करना — आपकी गलतियों को पुष्टि की तरह आपको वापस दोहराना।

निदान परीक्षण: क्या model आपकी दिशा के बिना भी यही कहता? यदि केवल आपका लहजा या framing बदला, तो यह विश्लेषण में वास्तविक बदलाव नहीं, चापलूसीपूर्ण सहमति है।

समाधान: अपनी पसंद छिपाएँ। Prompt तटस्थ रखें — “इस code की समीक्षा करें”, न कि “क्या यह code अच्छा है?”।

इससे बचें: “sycophancy” को ऐसे हर गलत जवाब के लिए इस्तेमाल करना जो आपको खुश कर दे। निदान परीक्षण के बिना यह शब्द “गलत” से अधिक उपयोगी नहीं।

उपयोग:

“उसने कहा कि मेरी refactor योजना बहुत अच्छी लग रही है; फिर मैंने ‘पक्का?’ पूछा और उसने पूरा जवाब पलट दिया।”

“यह चापलूसीपूर्ण सहमति का आम रूप है — पहले इसलिए सहमत हुआ क्योंकि आप आश्वस्त लगे, फिर इसलिए झुक गया क्योंकि आप संशय में लगे। योजना की गुणवत्ता नहीं बदली, आपका लहजा बदला। Clear करें और किसी भी दिशा का संकेत दिए बिना फिर पूछें।”

आत्मविश्वास से दिया गया गलत model output। इसके दो रूप हैं, जिनके कारण और समाधान अलग हैं:

Next-token prediction सहज output बनाता है, चाहे मूल तथ्य वास्तविक हो या नहीं — model के भीतर यह संकेत नहीं होता कि उसे कोई बात नहीं मालूम, इसलिए गढ़ा हुआ method उसी आश्वस्त शैली में आता है जिसमें सही method। गढ़ा हुआ code बनावट से ही विश्वसनीय लगता है: यदि API मौजूद होती तो वह ऐसी दिखती, इसी वजह से सरसरी समीक्षा में बच निकलता है और चलाने पर ही विफल होता है।

आपको पता होना चाहिए कि इनमें से कौन-सा रूप सामने है, क्योंकि एक का समाधान दूसरे को और खराब करता है। तथ्यात्मकता का अर्थ है जानकारी गायब है: docs, type definitions या फ़ाइल जोड़कर context बढ़ाएँ। निष्ठा का अर्थ है जानकारी मौजूद है पर ध्यान के लिए प्रतिस्पर्धा हार रही है: context हटाएँ। निष्ठा को तथ्यात्मकता समझकर आप और docs चिपका देंगे, context बढ़ेगा और भटकाव बिगड़ेगा। Agent कुछ गलत करे तो समस्या तय करने से पहले देखें कि सही जानकारी पहले से context में थी या नहीं।

इससे बचें: “hallucination” को बिना विशेषण के “गलत” का समानार्थी कहना — रूप बताए बिना यह शब्द निदान में मदद नहीं करता।

उपयोग:

“इसने schema पर `parseAsync` method गढ़ लिया।”

“तथ्यात्मकता या निष्ठा?”

“Method उन docs में है जो मैंने चिपकाए थे — इसने turn चालीस के बाद उन्हें पढ़ना बंद कर दिया।”

“तो निष्ठा। Compact करके फिर लोड करें; और docs जोड़ने की ज़रूरत नहीं।”

वह जो model training से "जानता" है और अपने parameters में रखता है। Training के समय स्थिर हो जाता है — मॉडल अपने parameters देख या अपडेट नहीं कर सकता। संपीड़न में बारीकियाँ खो जाती हैं: अरबों तथ्य सीमित संख्या के parameters में समा जाते हैं और दुर्लभ तथ्य धुँधले पड़ जाते हैं। आम विषयों पर धाराप्रवाह जवाब और असामान्य विषयों पर मनगढ़ंत जवाब — दोनों का स्रोत यही है। इसका विपरीत contextual knowledge है।

Parametric knowledge तथ्यों के रूप में संग्रहित नहीं होता। Training मॉडल को देखने के लिए कभी कोई database नहीं देती; वह parameters को तब तक समायोजित करती है जब तक मॉडल पाठ की अच्छी भविष्यवाणी न करने लगे, और किसी विषय पर पाठ की अच्छी भविष्यवाणी करने वाला मॉडल ऐसा व्यवहार करता है मानो वह विषय जानता हो। ज्ञान की विश्वसनीयता इस बात के अनुसार होती है कि training data में कोई चीज़ कितनी बार आई: लाखों उदाहरणों वाला विषय ठीक से दोहराया जाता है; केवल कुछ उदाहरणों वाला विषय मॉडल को समान विषयों की शक्ल देखकर अनुमान लगाने पर मजबूर करता है। मॉडल के लिए दोहराना और अनुमान लगाना एक ही प्रक्रिया है, इसलिए वह नहीं पहचान सकता कि वह इनमें से क्या कर रहा है। गढ़ा हुआ जवाब भी उतनी ही धाराप्रवाह भाषा में आता है जितना सही जवाब। Hallucination मॉडल का गलत अनुमान है।

Parametric knowledge पुराना भी पड़ता है। Knowledge cutoff पर parameters बदलना बंद कर देते हैं, इसलिए उसके बाद जारी या नए नाम से आई library उनमें मौजूद नहीं होती, और बदल चुकी API अपने पुराने रूप में याद रहती है।

दोनों कमियों — जानकारी का दुर्लभ होना और हाल की होना — का उपाय एक ही है: ज्ञान parameters में जोड़ा नहीं जा सकता, इसलिए उसे इसके बजाय contextual knowledge के रूप में देना होगा।

Usage

"यह बेदाग़ React लिखता है, लेकिन हमारे internal SDK में ऐसे methods गढ़ता है जो हैं ही नहीं।"

"React parametric knowledge में बहुत आम है — training के लाखों उदाहरण। आपका SDK नहीं, इसलिए मॉडल विश्वसनीय दिखने वाले ढाँचे भर देता है। SDK docs को context में लोड करें।"

वह तारीख जिसके बाद model के पास कोई parametric knowledge नहीं होता। उस तारीख के बाद की libraries, APIs और घटनाएँ मनगढ़ंत उत्तर देने के जाल हैं, जब तक कि उनके docs contextual knowledge के रूप में लोड न किए जाएँ। हर model release की अपनी cutoff तारीख होती है।

कटऑफ़ model बनाने की प्रक्रिया के कारण मौजूद है: training पाठ के एक snapshot को model के parameters में ढालता है और उसके बाद parameters स्थिर हो जाते हैं। model को पता नहीं होता कि उसके ज्ञान की सीमा कहाँ है — cutoff के बाद की किसी चीज़ के बारे में पूछने पर वह मना नहीं करता, बल्कि उस निकटतम चीज़ से निष्कर्ष निकालता है जिसे वह जानता है। इसी से जाल चुपचाप काम करता है: library के पुराने version के लिए लिखा code विश्वसनीय दिखता है, अक्सर compile भी हो जाता है, लेकिन बदले हुए हिस्सों पर विफल होता है।

समाधान हमेशा एक ही है: वर्तमान जानकारी को context में लाएँ। changelog लोड करें, installed version की type definitions दिखाएँ या agent से web पर docs पढ़वाएँ। context में मौजूद कोई भी चीज़ parameters में मौजूद न होने वाली जानकारी से बेहतर है।

Usage

"It keeps writing the v3 SDK syntax — we're on v5."

"v5, knowledge cutoff के बाद आया। v5 का changelog contextual knowledge के रूप में लोड करें, वरना यह पुराने parametric version के आधार पर मनगढ़ंत जानकारी देता रहेगा।"

वे तथ्य जिन्हें agent अभी context से सीधे पढ़ सकता है — उपयोगकर्ता का काम, agent द्वारा पढ़ी गई फ़ाइलें, tool results, session शुरू होते समय लोड की गई AGENTS.md सामग्री। इसका जोड़ा parametric knowledge है: parametric ज्ञान parameters से याद किया जाता है; contextual ज्ञान window से पढ़ा जाता है। Agent contextual knowledge से काम करे तो Hallucinations बहुत कम होते हैं — जवाब उसके सामने होता है, धुँधली स्मृति से निकालना नहीं पड़ता।

ज्ञान के इन दो प्रकारों में केवल contextual knowledge आपके नियंत्रण में है। Parameters स्थिर हैं, इसलिए model को ऐसी जानकारी देने का एकमात्र तरीका जो उसे नहीं मालूम — आंतरिक SDK, knowledge cutoff के बाद जारी हुई library या कल लिया गया निर्णय — उसे context में रखना है। व्यावहारिक AI coding के बहुत-से काम का सार यही है: ज़रूरी तथ्य ठीक उस समय model के सामने रखना जब उसे उनकी ज़रूरत हो।

जब contextual और parametric knowledge में टकराव हो, तो आमतौर पर contextual ज्ञान जीतता है। मौजूदा API docs चिपकाएँ तो model पुराने API की बासी याद के बजाय उन्हें मानता है — हालांकि पुराना version फिर भी रिस सकता है, खासकर लंबे session के भीतर। यदि docs लोड होने के बावजूद agent पुरानी पद्धति पर लौटता रहे, तो contextual knowledge के पार parametric knowledge रिस रहा है; सुधार फिर से बताना या उसे काम के और पास रखना मदद करता है।

Parametric knowledge के विपरीत, contextual knowledge इस्तेमाल करने की कीमत होती है। Window में लोड हर चीज़ tokens खर्च करती है और model के attention budget से प्रतिस्पर्धा करती है, इसलिए अधिक लोड करना अपने-आप बेहतर नहीं — लक्ष्य window में प्रासंगिक तथ्य रखना है, सभी तथ्य नहीं।

इस शब्द का उपयोग केवल parametric knowledge से तुलना करते समय करें; अन्यथा बस context कहें।

इससे बचें: “working memory” — contextual knowledge वह है जो अभी window में है; memory system वह है जो sessions के पार की सामग्री इसमें पहुँचाता है। दोनों अलग पैमाने हैं, इन्हें न मिलाएँ।

उपयोग:

“Docs चिपकाऊँ तो यह API बिल्कुल सही क्यों बताता है, और न चिपकाऊँ तो बातें क्यों गढ़ता है?”

“Docs हों तो यह contextual knowledge है — पन्ने से पढ़ रहा है। न हों तो parametric knowledge पर निर्भर है और दुर्लभ endpoints धुँधले पड़ जाते हैं।”

हर token की भविष्यवाणी करते समय model, context के बाकी सभी tokens को ध्यान में रखता है — कुछ को बहुत अधिक, दूसरों को बहुत कम। दो tokens के बीच के इस संबंध को attention relationship कहते हैं; अर्थपूर्ण जोड़े ("her" और "Sarah", या `getUser()` call और उसकी `function getUser` definition) असंबंधित जोड़ों से एक-दूसरे को अधिक प्रभावित करते हैं। N tokens वाले context में लगभग N² संबंध होते हैं।

मॉडल की दिखाई देने वाली समझ इन जोड़ियों में रहती है। जब वह सर्वनाम का अर्थ तय करता है, तो ऐसा "her" और "Sarah" के बीच मजबूत attention relationship के कारण होता है। जब वह सही arguments के साथ function call करता है, तो पहले पढ़ी गई call site और definition के बीच का संबंध काम कर रहा होता है। इनमें से कुछ भी lookup नहीं होता — हर जोड़ी के लिए, हर model provider request में इसकी गणना नए सिरे से होती है।

N² के आँकड़े पर थोड़ा ठहरना चाहिए, क्योंकि यह सहज अनुमान से भी तेज़ बढ़ता है:

हर जोड़ी की गणना एक से अधिक बार भी होती है। Models में attention heads कई होते हैं — सबसे उन्नत models की सटीक संख्या प्रकाशित नहीं है, लेकिन पचास से सौ एक उचित अनुमान है — और हर head हर संबंध का अपना संस्करण निकालता है। इसलिए ऊपर की तालिका की हर जोड़ी हर head में दोहराई जाती है। ये बहुत सारी जोड़ियाँ हैं।

किसी एक काम के लिए इनमें से बहुत कम संबंध मायने रखते हैं। आपके निर्देश और उसके नियंत्रण वाले code के बीच की जोड़ी उन गिनी-चुनी महत्वपूर्ण जोड़ियों में है; बाकी लगभग पूरा समूह शोर है। और दोनों अलग-अलग दरों से बढ़ते हैं: महत्वपूर्ण संबंधों की संख्या लगभग स्थिर रहती है, जबकि कुल समूह context के आकार के वर्ग के अनुपात में बढ़ता है। 1,000 tokens पर आपका प्रासंगिक संबंध दस लाख में एक है; 100,000 tokens पर दस अरब में एक। यही attention budget के पीछे का गणित है, और जब महत्वपूर्ण संबंधों का हिस्सा बहुत पतला हो जाता है, तो उसका अनुभव attention degradation है।

Usage

"यह diff में दोनों `user` symbols को बार-बार गड़बड़ा रहा है — लगता है हम dumb zone में हैं।"

"हाँ, हर call site और उसकी declaration के बीच का attention relationship दूसरी जोड़ी से प्रतिस्पर्धा कर रहा है — token का रूप एक जैसा है, bindings अलग। किसी एक का नाम बदलें, तो जोड़ियाँ साफ़ हो जाएँगी।"

हर token के पास context के बाकी हिस्से में बाँटने के लिए प्रभाव की सीमित मात्रा होती है। एक संबंध पर अधिक प्रभाव देने से दूसरों के लिए कम बचता है। यह बजट प्रति-token होता है और context बढ़ने पर नहीं बढ़ता, इसी कारण लंबे sessions में प्रभाव पतला पड़ता है।

इसे signal और noise की तरह सोचें। आपका निर्देश स्थिर आवाज़ वाला signal है; context window का हर दूसरा token उससे प्रतिस्पर्धा करता हुआ शोर है। निर्देश की आवाज़ कम नहीं होती — हर अक्षर जस का तस वहाँ है — लेकिन context बढ़ने पर उसके आसपास कमरा अधिक शोर वाला हो जाता है और signal-to-noise ratio गिरता है। Context के 10k tokens पर सबसे तेज़ सुनाई देने वाला निर्देश 150k पर पृष्ठभूमि की गूँज बन जाता है। यही attention degradation का तंत्र है: model भूलता नहीं; signal शोर में खो जाता है।

लक्षण अवज्ञा जैसा दिखता है — agent शुरुआत में किसी सीमा पर सहमत हुआ था, फिर उससे भटकता है और सीमा को फिर चिपकाने से मदद बस थोड़ी देर होती है। कारण निर्देश नहीं; window की बाकी हर चीज़ उससे प्रतिस्पर्धा कर रही है।

आप नियंत्रित कर सकते हैं कि context में क्या जाए। जो सामग्री काम के लिए उपयोगी नहीं, वह तटस्थ नहीं — वह उपयोगी हर बात पर शोर है। Window छोटा रखें, संचित context का लाभ खत्म होते ही clear करें और शुरुआत में कही बात कायम रहेगी ऐसा मानने के बजाय महत्वपूर्ण सीमाएँ फिर बताएँ।

उपयोग:

“मैंने ऊपर चिपकाया हुआ schema यह बार-बार अनदेखा क्यों कर रहा है?”

“हम dumb zone में बहुत आगे हैं — हर token का attention budget तय है, लेकिन context बढ़ता रहा। Schema का signal अब उसके बाद आए हज़ारों tokens से प्रतिस्पर्धा कर रहा है।”

जैसे-जैसे session बढ़ता है, हर token का attention budget अधिक प्रतिस्पर्धियों में बँट जाता है। किसी एक meaningful relationship का संकेत कमज़ोर पड़ता है; अप्रासंगिक context का शोर बढ़ जाता है। वही model, वही parameters — बस उसी थाली से खाने वाले और मुँह। यही smart zone / dumb zone effect का कारण है।

यह session के बीच model की क्षमता घटने जैसा दिखता है: एक घंटे तक मानी गई सीमाएँ छूटने लगती हैं, उसे बताई बातें फिर पूछता है और पहले पढ़ी फ़ाइल की अनदेखी करता हुआ code लिखता है। Model नहीं बदला — केवल इतना बदला है कि अब वह कितना context ध्यान में रख रहा है।

यह धीरे-धीरे होता है, इसी कारण session के भीतर से पकड़ना कठिन है। कोई error या स्पष्ट सीमा नहीं होती; हर turn पिछले से थोड़ा खराब होता है और जब तक चूकें साफ़ दिखती हैं, आप कुछ समय से dumb zone में होते हैं।

और context जोड़ने के बजाय उसे हटाकर सुधारें। अनदेखे निर्देश को फिर चिपकाने से उसी भीड़ भरी window में एक और प्रतिस्पर्धी जुड़ता है और मदद केवल थोड़ी देर के लिए होती है। जो काम करता है: clear करके केवल काम की सामग्री फिर लोड करें, या compact करें, या नए session को hand off करें। निर्देशों का पालन घटने को model की समस्या नहीं, context की लंबाई का संकेत मानें।

उपयोग:

“यह dumb zone में बहुत आगे जा चुका है — type file में न होने वाले generics बना रहा है।”

“Attention degradation। Type definitions अब भी context में हैं, लेकिन बाद में जोड़ा गया सब कुछ उनका संकेत दबा रहा है। Clear करके फिर से लोड करें।”

Session की शुरुआत में agent “smart zone” में होता है — तेज़, केंद्रित और अच्छी याददाश्त वाला। Session बढ़ने पर वह “dumb zone” में खिसकता है: अधिक लापरवाह, भुलक्कड़ और गलती करने वाला — और निष्ठा-संबंधी hallucinations बढ़ती हैं। वही model, वही harness — केवल अधिक context। यह attention degradation का महसूस होने वाला असर है। Frontier models में dumb zone आमतौर पर 125K–150K tokens के आसपास शुरू होता है — हालांकि इस पर मतभेद है। Session फूल जाए तो Clear या compact करें; धकेलते न रहें।

गिरावट धीरे-धीरे होती है, इसलिए इसे चूकना आसान है। कोई error message या स्पष्ट सीमा नहीं दिखती; agent पहले थोड़ा खराब, फिर साफ़ तौर पर खराब प्रदर्शन करने लगता है। आम संकेत: बीस turns पहले दिया निर्देश भूलना, पहले सुधारी गलती दोहराना या context के विपरीत बात आत्मविश्वास से कहना। गिरावट सहज होने के कारण आम प्रतिक्रिया आगे धकेलना और फिर समझाना होती है — इससे context और बढ़ता है और समस्या बिगड़ती है।

Zones का context window की सीमा से सीधा संबंध नहीं। अधिकांश window खाली होने पर भी session dumb zone में गहरा हो सकता है: सीमा वह जगह है जहाँ harness आगे चलाने से मना करता है, लेकिन गुणवत्ता उससे बहुत पहले गिरती है। Window के बजाय smart zone के हिसाब से योजना बनाएँ — किसी काम का व्यावहारिक बजट वे tokens हैं जिनके भीतर agent अच्छा काम करता है, न कि वे जिन्हें वह तकनीकी रूप से रख सकता है।

Smart zone एक बजट है और असंबंधित काम उसे खर्च करता है। Session में किया हर काम tokens लेता है, इसलिए उसी session में दूसरा काम शुरू करने का अर्थ है dumb zone के और पास से शुरुआत। हर काम को अलग session में करने से उसे session का सबसे तेज़ हिस्सा मिलता है। एक काम smart zone से बड़ा हो तो उसे बाँटें: स्वाभाविक सीमा पर hand off या compact करें और अगला हिस्सा नए session से कराएँ।

उपयोग:

“पहले तीन components शानदार बनाए और चौथे को पूरी तरह बिगाड़ दिया।”

“आप smart zone से बाहर हैं — model वही है, बस अब dumb zone में बहुत आगे हैं। Compact करके योजना फिर लोड करें; अगला component सही बनेगा।”

मौजूदा session समाप्त करके नया शुरू करना। अगला message खाली session और खाली context window से शुरू होता है। आमतौर पर उपयोगकर्ता इसे शुरू करता है।

भरे-गंदे context का समाधान clearing है। Session में सब कुछ जमा होता है: असफल कोशिशें, गलत रास्ते, पुराने tool results, छोड़ी हुई योजनाएँ। Model हर turn पर यह सब फिर पढ़ता है, और खराब इतिहास नए काम को खींचता रहता है। लंबा session काफ़ी आगे बढ़ जाए तो agent अधिक अस्पष्ट और कम आज्ञाकारी हो जाता है — साफ़ दिए निर्देश अनदेखे होते हैं, गुणवत्ता गिरती है, और बेहतर करने के लिए उकसाने से लाभ नहीं होता क्योंकि जिस शोर में वह रास्ता बना रहा है वह अब भी उसके context में है। Clearing यह शोर हटाता है।

Clearing बातचीत मिटाता नहीं। अधिकतर harnesses session का इतिहास आपके computer पर रखते हैं, इसलिए transcript अब भी पढ़ा या फिर शुरू किया जा सकता है। जो जाता है वह agent की कामकाजी state है: model stateless है, इसलिए नए session को पुरानी बातों में से कुछ पता नहीं। यदि session में ऐसे निर्णय या प्रगति हो जिसकी अगले session को ज़रूरत होगी, तो पहले agent से handoff artifact लिखवाएँ और फिर नए session को उसी का pointer दें।

Compaction से तुलना करें, जो खाली शुरुआत करने के बजाय session को नए context में सारांशित करता है। Clearing अधिक सीधा औज़ार है: कुछ भी आगे नहीं जाता, बेकार सामग्री भी नहीं।

उपयोग:

“यह failing test पर चक्कर लगाता ही जा रहा है।”

“बस clear करें — योजना वाले doc और test file के साथ नया session शुरू करें। मौजूदा context से लड़ने का कोई फ़ायदा नहीं।”

agent के context को एक session से दूसरे session तक ले जाना। इसे ले जाने का तरीका अलग-अलग हो सकता है — लिखित handoff artifact, स्मृति में मौजूद सारांश (compaction ) आदि। यह clearing से अलग है, जिसमें कुछ भी स्थानांतरित नहीं होता। इसकी वजहें अलग हो सकती हैं: भूमिकाएँ बदलना (योजना बनाने वाला → लागू करने वाला), AFK run शुरू करना, समानांतर sessions में काम बाँटना या context window में जगह खाली करना।

प्राप्तकर्ता session शून्य context से शुरू होता है — model stateless है और पुराने session की कोई भी बात नए session को दिखाई नहीं देती। अगले session को जो कुछ चाहिए, उसे स्पष्ट रूप से साथ ले जाना होगा; बाकी सब खो जाता है। "वापस पूछने का रास्ता नहीं" वह शर्त है जो साथ ले जाने वाली सामग्री का रूप तय करती है: नया session पुराने session से पूछ नहीं सकता कि उसका क्या आशय था, इसलिए साथ लाई गई सामग्री को अपने दम पर स्पष्ट होना चाहिए।

खराब handoff की स्पष्ट विफलता है पुराने निर्णयों पर फिर से बहस: नया session वे फैसले दोबारा खोलता है जिन्हें पुराना session तय कर चुका था, क्योंकि साथ लाई गई सामग्री में यह दर्ज था कि क्या तय हुआ, लेकिन क्यों नहीं। Handoff को इस आधार पर परखें कि शून्य context वाला session उससे क्या कर सकता है।

Usage

"Planning session भारी हो रहा है — क्या मुझे बस जारी रखना चाहिए?"

"Handoff करें। फैसले एक doc में लिखें, context साफ़ करें और उसे पढ़ते हुए नए session में implementation शुरू करें।"

मूल रूप में मौजूद सत्य का स्रोत — कोड, बातचीत का transcript, कच्चा log या वास्तविक API response। उस चीज़ का विवरण नहीं; स्वयं वही चीज़। इसका जोड़ा secondary source है।

यदि जानना है कि आपका codebase क्या करता है, तो कोड primary source है। Docs, architecture diagram और README उसके विवरण हैं — लिखे जाने के समय सही, उसके बाद अपनी-अपनी गति से बदलते हुए। जब कोई agent आत्मविश्वास से आपके project के बारे में गलत बात कहता है, तो पूछें कि उसने किस source से काम किया: doc पढ़ने वाला agent उस doc की पुरानापन विरासत में लेता है; कोड पढ़ने वाला agent मौजूदा सत्य पढ़ता है।

लागत ही primary sources को default बनने से रोकती है। किसी source को context window में लोड करना महँगा है — पूरी फ़ाइल, पूरा transcript, हर token का input के रूप में बिल और attention budget में हिस्सेदारी। इसकी कीमत पर आपको पूर्णता मिलती है: किसी और ने क्या मायने रखता है यह तय करके पहले से कुछ छाँटा नहीं। पिछले महीने लिखा सारांश आज महत्वपूर्ण साबित हुई जानकारी नहीं रख सकता; primary source रखता है।

जब सटीकता मायने रखती हो, primary source देखें — exact signature, वास्तविक error या वह पंक्ति जहाँ exception आता है। context संभालने का बड़ा हिस्सा यह तय करना है कि primary source पढ़ने की कीमत कब चुकानी है और secondary source कब पर्याप्त है।

उपयोग:

“Agent कहता है कि retry logic धीरे-धीरे कम होती आवृत्ति से प्रयास करता है, लेकिन मैं उसे endpoint पर लगातार अनुरोध भेजते देख रहा हूँ।”

“उसने यह design doc से पढ़ा। उसे वास्तविक retry module दिखाएँ — व्यवहार मायने रखता हो तो primary source से काम करें।”

किसी primary source का विवरण, उससे एक कदम दूर — code का वर्णन करते docs, transcript का सारांश, search results की रिपोर्ट। यह जिस source का वर्णन करता है उससे context window में लोड करना सस्ता है और स्वभाव से जानकारी खोता है: लिखने वाले ने तय किया कि क्या मायने रखता है; जो हटाया गया वह केवल सारांश पढ़ने वाले के लिए अदृश्य है।

context की engineering का बड़ा हिस्सा secondary sources बनाना है। Compaction, session के इतिहास को सारांश में बदलता है जो अगला session शुरू करता है। Subagent अपनी window में शोर वाली खोज करता है और छोटी रिपोर्ट लौटाता है। Handoff artifact session के निर्णयों को उस दस्तावेज़ में समेटता है जिसे अगला session पढ़ता है। Memory systems session की सीखी बातों को notes में संक्षिप्त करते हैं। हर एक यही सौदा करता है: विवरण छोड़कर जगह बचाना।

Secondary sources दो तरह से विफल होते हैं। उनमें जानकारी खो जाती है — वह compaction summary जिसने schema का निर्णय छोड़ दिया, या वह report जिसने edge case का ज़िक्र नहीं किया। और वे पुराने पड़ते हैं — primary source बदलता है पर विवरण नहीं, इसलिए docs पिछले quarter की architecture का वर्णन इस quarter के विश्वास के साथ करते हैं। जब agent किसी भी तरह विफल secondary source पर काम करता है, तो वह गलत जानकारी से पूरे भरोसे के साथ काम करता है; समाधान है उसे primary source पर वापस भेजना।

इनमें से कोई विफलता secondary sources को गलती नहीं बनाती। Context window सीमित है और primary sources महँगे; सारांश, reports और handoff docs के बिना कोई बड़ा काम नहीं समा सकता। कौशल यह जानना है कि कौन-सी बातें खोने पर भी बची रह सकती हैं — और जब ऐसा न हो, तो primary source से सत्यापन करना। अच्छी तरह बना secondary source मूल तक वापस जाने वाला context pointer रखता है — उस transcript का नाम बताने वाला सारांश जिससे वह निकला, या जिस फ़ाइल का वर्णन है उसका नाम बताने वाला doc — ताकि विवरण पर्याप्त न हो तो पाठक नुकसान पर निर्भर रहने के बजाय pointer का अनुसरण कर सके।

उपयोग:

“Handoff doc कहता है auth पूरा है, लेकिन नया session token refresh में बार-बार खराबी पा रहा है।”

“Doc एक secondary source है — पिछले session ने वही लिखा जो उसे सही लगा, न कि जो सच है। नए session से auth tests चलवाएँ और primary source पर भरोसा करें।”

handoff को आगे ले जाने के लिए इस्तेमाल किया जाने वाला दस्तावेज़ — एक session इसे environment में लिखता है ताकि दूसरा इसे पढ़ सके। Specs, tickets और plan docs सभी handoff artifacts हैं।

इसे लिखने की वजह यह है: model stateless है, इसलिए clearing करने पर session की कोई बात बचती नहीं। निर्णय, सीमाएँ, अधूरी योजनाएँ — वे सब उस context के साथ चली जाती हैं जिसने उन्हें रखा था। Environment बना रहता है। महत्वपूर्ण स्थिति को फ़ाइल में लिखने से वह ऐसी जगह पहुँचती है जहाँ अगला session उसे वापस पढ़ सकता है।

Artifact एक secondary source है — session के काम का विवरण, काम स्वयं नहीं। इसी वजह से यह नए session को जानकारी देने लायक छोटा रहता है, और इसीलिए उसे गुमराह भी कर सकता है: इसमें वही दर्ज होता है जिसे लिखने वाले session ने सच माना; जो कुछ छूट गया या गलत हुआ, वह पाठक से छिपा रहता है। जहाँ कोई दावा महत्वपूर्ण हो, अगला session उसे विरासत में लेने के बजाय primary source — कोड और tests — के सामने जाँचे।

अच्छा artifact ऐसे session के लिए लिखा जाता है जिसके पास कोई संदर्भ नहीं है। “जिस फ़ाइल की हमने चर्चा की” की जगह ठोस फ़ाइल पथ। क्या और क्यों तय हुआ, ताकि अगला session फिर से बहस शुरू न करे। क्या पूरा हुआ और क्या बाकी है। लिखने वाले session को यह बताना मददगार होता है कि artifact किसके लिए है: “ऐसे नए session के लिए handoff doc लिखें जिसे इस काम के बारे में कुछ पता नहीं।”

आगे जानकारी ले जाने का दूसरा तरीका compaction है, जो मेमोरी में सारांश बनाता है। Artifact के दो फ़ायदे हैं: यह डिस्क पर रहता है, जहाँ किसी चीज़ के उस पर निर्भर होने से पहले आप इसे पढ़ और सुधार सकते हैं; और इसे फिर से इस्तेमाल किया जा सकता है — वही spec पाँच समानांतर sessions को जानकारी दे सकता है।

उपयोग:

“योजना बनाने वाले agent और लागू करने वाले agent के बीच इसे कैसे बाँटूँ?”

“योजनाकार से handoff artifact लिखवाएँ — फ़ाइल पथ, निर्णय और सीमाएँ। लागू करने वाले session की शुरुआत artifact के pointer से हो और वह उसी को brief माने।”

कई-session वाले काम का वर्णन करने वाला handoff artifact — क्या बनाया जा रहा है, यह बताता है; यह नहीं कि हर session अपना हिस्सा कैसे करता है। काम बढ़ने के साथ इसमें बदलाव आता है। यह tickets से बना होता है।

यह स्पेक इसलिए है क्योंकि session अस्थायी होते हैं और बड़ा काम नहीं। जिस काम में एक context window से अधिक मेहनत लगे, उसे context से बाहर घर चाहिए — एजेंट के environment में ऐसी जगह जो clearing के बाद भी बचे, चाहे वह रिपॉज़िटरी की फ़ाइल हो, GitHub issue हो या कोई ऐसा issue tracker जहाँ एजेंट पहुँच सके। स्पेक वही घर है: लक्ष्य, सीमाएँ, अब तक लिए गए निर्णय और स्थिति सहित टिकटों की सूची। कोई भी नया session इसे पढ़कर समझ सकता है कि काम कहाँ तक पहुँचा है, बिना पिछले session के जमा हुए शोर को विरासत में पाए।

स्पेक कई पहचाने जा सकने वाले रूपों में आते हैं, जो अधिकतर टीमों के पहले से लिखने के तरीकों से लिए गए हैं। product requirements document (PRD) उपयोगकर्ता के नज़रिये से क्या और क्यों पर केंद्रित रहता है — सुविधाएँ, व्यवहार और स्वीकृति मानदंड। design doc या RFC तकनीकी पक्ष पर केंद्रित रहता है — चुना गया तरीका, अस्वीकार किए गए विकल्प और समझौते। छोटे स्तर पर, टिकटों की चेकलिस्ट वाली साधारण `plan.md` फ़ाइल भी कई-session वाली सुविधा के लिए वही काम करती है। शैली से अधिक भूमिका मायने रखती है: agent के लिए ये सभी एक ही चीज़ हैं — इरादे का स्थायी विवरण जिसे वह हर session की शुरुआत में पढ़ता है।

उपयोग:

“क्या यह सब एक ही session में होना चाहिए?”

“नहीं, इसे spec के रूप में लिखें — टिकटों में बाँटें और हर टिकट को उसके अपने session में चलाएँ। पूरा काम एक ही context में करने की कोशिश आधा पूरा होने से पहले dumb zone में पहुँचा देगी।”

काम के एक session की सीमा तय करने वाला handoff artifact। यह अकेले खड़ा हो सकता है या spec के बच्चों में से एक के रूप में उससे जुड़ सकता है। टिकट अपने सहोदर टिकटों को रोक सकते हैं या उनसे रुक सकते हैं, इसलिए काम का क्रम किसी सीधी योजना के बजाय उनकी निर्भरता-ग्राफ़ से निकलता है।

परिभाषित करने वाली सीमा इसका आकार है: एक session। टिकट तब तक पूरा हो जाना चाहिए, जब तक session smart zone से बाहर न भटक जाए — और इस सीमा को परखा जा सकता है। यदि काम पूरा होने से पहले आपके टिकटों के session नियमित रूप से बिगड़ जाते हैं, तो टिकट बहुत बड़े हैं; उन्हें बाँट दें। यदि हर session पाँच मिनट काम करने से पहले अपना अधिकतर context तैयारी में खर्च करता है, तो वे बहुत छोटे हैं; उन्हें जोड़ दें।

अच्छा टिकट ऐसे पाठक के लिए लिखा जाता है जिसके पास कोई दूसरा संदर्भ नहीं है। लक्ष्य, स्वीकृति मानदंड और संबंधित फ़ाइलों व निर्णयों की ओर संकेत करने वाले context pointers — इतना कि session पिछली जानकारी फिर से निकाले बिना काम शुरू कर सके।

निर्भरता-ग्राफ़ ही समानांतर काम को संभव बनाता है। स्वतंत्र टिकट — ग्राफ़ की पत्तियाँ — एक ही समय पर अपने-अपने session में चल सकते हैं। एक साथ कई agent चलाने का यह प्रभावी तरीका है। software factory में किसी टिकट को तैयार चिह्नित करना ही उसका session शुरू करने का ट्रिगर होता है।

उपयोग:

“माइग्रेशन spec पर कहाँ से शुरू करूँ?”

“टिकटों का ग्राफ़ देखें — स्कीमा में बदलाव बैकफ़िल को रोकता है और बैकफ़िल API स्विच को। कोई पत्ती चुनें और उस पर session चलाएँ।”

मेमोरी में किया गया handoff: पिछले session का इतिहास संक्षेपित किया जाता है और वह सारांश एक नया session शुरू करता है। यह जानबूझकर कुछ जानकारी खोता है: ट्रांसक्रिप्ट primary source है, सारांश secondary source — अधिक क्षमता पाने के लिए कुछ विवरण छोड़ दिए जाते हैं। इसे उपयोगकर्ता हाथ से शुरू कर सकता है या यह autocompact के ज़रिये अपने-आप हो सकता है।

तंत्र यह है: context window की क्षमता सीमित है, और लंबा session इसे भर देता है — हर tool result, हर पढ़ी हुई फ़ाइल और हर गलत मोड़ इतिहास में बना रहता है। जब यह भारी हो जाता है, harness model से session का सारांश माँगता है, मूल इतिहास हटा देता है और उस सारांश से नया session शुरू करता है। जो भी बात सारांश में नहीं आई, वह context से चली जाती है। कुछ harness पुराना ट्रांसक्रिप्ट डिस्क पर रखकर और सारांश में उसका context pointer छोड़कर इस नुकसान को कम करते हैं — secondary source अपने primary source से जुड़ा रहता है, इसलिए सारांश से छूटा विवरण मूल को फिर से पढ़कर वापस पाया जा सकता है।

सारांश model लिखता है, इसलिए उसे निर्देश दिए जा सकते हैं। “स्कीमा के निर्णय सुरक्षित रखें” कहने से बना artifact अधिक सोच-समझकर तैयार होता है। समय भी मायने रखता है — काम के बीच में नहीं, बल्कि किसी चरण की सीमा पर और योजना तय हो जाने के बाद compact करें।

इसकी तुलना clearing से करें, जो सब कुछ छोड़कर शुरुआत से काम शुरू करता है: compaction ज़रूरी बातें आगे ले जाने की कोशिश करता है; clearing मानता है कि वे पहले से कहीं बेहतर जगह लिखी हुई हैं।

उपयोग:

“Context भारी हो रहा है और मुझे अभी test pass भी करना है।”

“शुरू करने से पहले compact करें — सारांश के प्रॉम्प्ट में वह लिखें जो बचना चाहिए, ताकि नया session स्कीमा के निर्णय रखे और खोजबीन छोड़ दे।”

जब context window लगभग भरने वाली होती है, तब harness अपने आप Compaction शुरू कर देता है।

Harness यह देखता रहता है कि context window कितनी भरी है। जब वह एक सीमा पार करती है — अक्सर लगभग 80% — तो वह रुकता है, model से अब तक के session का सारांश बनवाता है और उस सारांश के साथ नया session शुरू करता है। फिर काम ऐसे जारी रहता है मानो कुछ हुआ ही न हो।

लेकिन कुछ तो हुआ था। Compaction में जानकारी खोती है, और autocompact ऐसा समय चुनकर जानकारी खोता है जिसे आपने नहीं चुना। Manual compact काम के चरणों के बीच होता है, जब आप मॉडल को बता सकते हैं कि क्या सुरक्षित रखना है। Autocompact काम के बीच, जब भी सीमा पहुँचती है, सक्रिय हो जाता है — संभव है refactor के बीच में, जहाँ सारांश खुद तय करता है कि आपके किन निर्णयों को रखना चाहिए। इसका आम लक्षण: agent आत्मविश्वास से काम जारी रखता है, लेकिन एक घंटे पहले तय की गई शर्त चुपचाप भूल चुका होता है; आपको इसका पता तभी चलता है जब उसका काम उससे टकराने लगता है।

बचाव का तरीका है इसे सक्रिय ही न होने देना। Context indicator पर नज़र रखें और स्वाभाविक पड़ाव पर खुद compact करें, या निर्णयों को disk पर किसी plan doc या handoff artifact में लिखें, जहाँ कोई सारांश उन्हें खो नहीं सकता। ज़्यादातर harness आपको buffer को अनुकूलित करने भी देते हैं — सीमा को पहले या बाद में लाना या autocompact को पूरी तरह बंद करना — ताकि आप तय कर सकें कि सक्रिय होने से पहले कितनी खाली जगह रखनी है।

Usage

"इसे schema के बारे में पहले तय की हुई बात याद नहीं लगती।"

"turns के बीच autocompact सक्रिय हुआ — शुरुआती फैसलों का सारांश बना और शायद कुछ खो गया। Plan doc फिर लोड करें या अगली बार खुद compact करें ताकि तय कर सकें कि क्या बचाकर रखना है।"

ऐसा system जो agent को कई sessions में stateful बनाने की कोशिश करता है। यह session के दौरान जानकारी environment में सहेजता है और भविष्य के sessions की शुरुआत में उसे context window में फिर लोड करता है, ताकि उपयोगकर्ता द्वारा session clearing करने के बाद भी agent निरंतरता बनाए रखे।

Memory system के दो हिस्से हैं। Write path: session के दौरान agent अपनी सीखी बात दर्ज करता है — आपकी बताई पसंद या project से जुड़ा तथ्य — environment की फ़ाइलों में। Read path: session शुरू होते समय harness वे फ़ाइलें, या उनकी index, वापस context window में लोड करता है। कई harness अपने memory system के साथ आते हैं — Claude Code का `/memory` ऐसा ही एक है — लेकिन आप इसे स्वयं भी बना सकते हैं: notes की एक directory और AGENTS.md में उसे देखने का निर्देश।

हमेशा लोड होने वाली सामग्री के वही समझौते यहाँ भी लागू होते हैं। Memories जमा होती हैं, इसलिए अधिकतर systems एक पंक्ति की index लोड करते हैं और पूरा पाठ सीधे डालने के बजाय उसे context pointers के पीछे रखते हैं। Memories secondary sources भी हैं, इसलिए वे पुरानी पड़ती हैं: मार्च में दर्ज तथ्य जून में भी उतने ही विश्वास से लोड होता है, जबकि project तब तक आगे बढ़ चुका होता है। Memory system को भी छँटाई चाहिए, ठीक AGENTS.md की तरह।

उपयोग:

“मुझे बार-बार बताना पड़ता है कि मैं MySQL नहीं, Postgres इस्तेमाल कर रहा हूँ।”

“Memory system जोड़ें — पहली turn में वह जो सीखता है उसे filesystem में लिखें और session शुरू होने पर फिर लोड करें। model स्वयं stateless है; memory layer निरंतरता का आभास कराती है।”

एक environment की फ़ाइल जिसे harness, session शुरू होते समय context window में लोड करता है — agent के लिए परियोजना का स्थायी brief। यह विभिन्न harness में प्रचलित परंपरा है; कुछ harness का अपना रूप भी होता है (Claude Code का रूप CLAUDE.md है)।

क्योंकि यह अपने-आप लोड होता है, इसलिए यह sessions में एक ही बात बार-बार बताने से बचने का तरीका है। model stateless है — एक session में दिया गया सुधार अगले में नहीं रहता, और हर नए session को बताना पड़ता है कि परियोजना pnpm इस्तेमाल करती है, tests किसी खास flag से चलते हैं, और कोई directory generated है इसलिए उसे नहीं छूना चाहिए। जब आप agent को एक ही बात दो बार सुधार चुके हों, तो वह सुधार AGENTS.md में एक पंक्ति बनाने का उम्मीदवार है।

उपयुक्त सामग्री वह है जिसे agent कोड से नहीं निकाल सकता: build और test commands, वे conventions जो codebase से स्पष्ट नहीं हैं, और सख्त सीमाएँ (“generated client को कभी संपादित न करें”)। संक्षिप्त और घोषणात्मक — यह brief है, documentation नहीं।

इसका समझौता यह है कि इसमें लिखी हर बात हमेशा लोड होती है। निर्देश जमा होते जाते हैं और उनमें से अधिकांश किसी दिए गए काम के लिए अप्रासंगिक होते हैं; लंबी AGENTS.md फ़ाइल tokens खर्च करती है और अपने निर्देशों को भी कम प्रभावी बनाती है — context में जितने अधिक निर्देश हों, model द्वारा किसी एक का पालन करने की संभावना उतनी कम होती है।

इससे बचें: ऐसी सामग्री के लिए AGENTS.md का उपयोग करना जिसे progressively disclosed किया जाना चाहिए — इसमें हर पंक्ति हर session के हर turn पर token लागत लेती है, चाहे session को उसकी ज़रूरत हो या नहीं। Style guide को skill या context pointer के पीछे रखा जा सकता है; AGENTS.md में केवल वे पंक्तियाँ रखें जो हर जगह लागू होती हैं।

उपयोग:

“हर session शुरू होते ही 4k tokens क्यों खर्च हो जाते हैं?”

“AGENTS.md देखें — किसी ने पूरी style guide को skill के पीछे रखने के बजाय वहीं चिपका दिया है।”

अभी agent को जितना context चाहिए उतना ही लोड करना और बाकी के लिए context pointers रखना। यह विचार UI design से लिया गया है, जहाँ उपयोगकर्ता को उसके मौजूदा काम के लिए ज़रूरी controls दिखाए जाते हैं और बाकी को click के पीछे रखा जाता है।

यह तकनीक इसलिए है क्योंकि context की लागत दो बार लगती है। पहले से लोड हर token पर हर turn में input tokens के रूप में बिल लगता है और agent को ज़रूरत हो या नहीं, हर token उसका attention budget खर्च करता है। पूरी style guide, deployment runbook और database conventions से भरी AGENTS.md agent को इन सभी में कमज़ोर बनाती है — मौजूदा काम के लिए ज़रूरी निर्देश उन निर्देशों से पतले पड़ जाते हैं जिनकी ज़रूरत नहीं। संकेत यह है कि agent उन नियमों को अनदेखा कर रहा है जिन्हें आप उसके context में होने के बारे में जानते हैं: वे वहाँ हैं, बस नीचे दबे हैं।

Progressive disclosure इसे उलटता है। हमेशा लोड होने वाली परत छोटी रखें — हर विषय पर एक वाक्य और जहाँ विवरण है वहाँ का pointer। Component लिखते समय agent style guide पढ़ता है, deploy करते समय deployment runbook और test ठीक करते समय दोनों में से कोई नहीं। Skills, harness में अंतर्निहित तरीका हैं: हर session में छोटा विवरण लोड होता है, पूरा निर्देश केवल trigger होने पर।

उपयोग:

“क्या पूरी style guide AGENTS.md में डाल दूँ?”

“नहीं — progressive disclosure अपनाएँ। Style guide का संदर्भ skill के रूप में दें जिसे agent component लिखने की ज़रूरत पड़ने पर लोड करे। AGENTS.md हर turn पर token की कीमत लेती है।”

किसी दस्तावेज़ में ऐसा उल्लेख जो दूसरे दस्तावेज़ की ओर संकेत करे, ताकि agent काम की ज़रूरत पड़ने पर ही उसे context window में ला सके। इसी से progressive disclosure की इकाइयाँ बनती हैं।

सामग्री को सीधे डालने के बजाय pointer इस्तेमाल करने का कारण लागत है। Context window में pointer एक पंक्ति लेता है। उसके पीछे के दस्तावेज़ में हज़ारों tokens हो सकते हैं, लेकिन जब तक agent pointer का अनुसरण न करे, उनकी कोई लागत नहीं। AGENTS.md में 2,000-token का runbook सीधे डालें तो हर session उसकी कीमत चुकाता है; उसे “deploy process: see `internal/deploy.md`” से बदल दें तो केवल deploy करने वाले sessions उसे लोड करते हैं। काम से मेल मिलने पर agent tool call से pointer का अनुसरण करता है।

Pointer के काम करने के लिए दो चीज़ें चाहिए: स्थिर पथ और इतना विवरण कि agent समझ सके कि उसका अनुसरण करना कब उपयोगी है। बिना विवरण का पथ ऐसा pointer है जिसके पीछे जाने का agent के पास कोई कारण नहीं; “see `internal/deploy.md`” के साथ भीतर क्या है इसका संकेत न हो तो ज़रूरतमंद session भी उसे छोड़ देगा। पंक्ति ऐसी लिखें जो काम के स्वरूप से मेल खाए: “release, deploy, or rollback — read `internal/deploy.md` first”।

ध्यान दें तो pointers हर जगह दिखते हैं: lines in AGENTS.md, skill descriptions (harness description लोड करता है; skill का मुख्य भाग उसके पीछे रहता है), directory listing के फ़ाइलनामों में और दस्तावेज़ों के बीच के links में।

Pointer secondary source को उस primary source से भी जोड़ सकता है जिससे वह बना था — उदाहरण के लिए, मूल transcript का नाम बताने वाला compaction summary या जिस source file का वर्णन है उसका नाम बताने वाला दस्तावेज़। इससे secondary source में खोई जानकारी वापस पाई जा सकती है: जब सारांश पर्याप्त न निकले, agent pointer का अनुसरण करके मूल पढ़ता है, सारांश में बची किसी भी बात पर निर्भर रहने के बजाय।

इससे बचें: “reference” — यह बहुत रूखा है और यह नहीं बताता कि उसका अनुसरण करने से और context आएगा। “Portal” — यह बहुत अलंकृत है।

उपयोग:

“AGENTS.md बहुत बड़ी होती जा रही है।”

“उसमें अधिकतर content नहीं, context pointers होना चाहिए। हमेशा लागू होने वाले नियम वहीं रखें; deploy runbook और style guide को skills में बदलें और पीछे context pointer छोड़ें।”

एक इकाई के रूप में बँधी ऐसी क्षमता जिसे सिखाया जा सकता है — किसी काम को अच्छी तरह करने के निर्देश और संसाधन, जो environment में तब तक रहते हैं जब तक context pointer उस काम के लिए उन्हें context window में न लाए। harness में progressive disclosure की इकाई।

Skills एक खुला मानक हैं, जिसे agentskills.io पर परिभाषित किया गया है — पहले Anthropic ने विकसित किया और बाद में अधिकतर बड़े harness ने अपनाया, इसलिए एक बार लिखी skill उन सभी में काम करती है। इसका format एक folder है जिसमें शामिल होते हैं:

• एक `SKILL.md` फ़ाइल — metadata (कम-से-कम नाम और विवरण) तथा स्वयं निर्देश
• वैकल्पिक रूप से, ऐसे scripts जिन्हें agent चला सके
• वैकल्पिक रूप से, templates और संदर्भ सामग्री जिनकी ओर निर्देश संकेत करते हैं

डिफ़ॉल्ट रूप से context में केवल नाम और विवरण होते हैं। Agent का काम मेल खाने पर वह बाकी सामग्री लोड करता है। तब तक skill लगभग कोई जगह नहीं लेती — उसके पूरे निर्देश चाहे कितने भी बड़े हों, बस tokens के एक-दो वाक्य।

इसी से skills, AGENTS.md से अलग होती हैं, जो काम कुछ भी हो हर session में लोड होती है। कोई विशेष प्रकार का काम आने पर skill पढ़ी जाती है — release, नई service का scaffolding, migration लिखना — और बाकी समय नज़रअंदाज़ रहती है।

इससे बचें: “tool” — tool वह है जिसे agent call करता है; skill वे निर्देश हैं जिन्हें वह पढ़ता है।

उपयोग:

“Deploy runbook कहाँ रखना चाहिए?”

“Skill के रूप में — agent उसे तभी लोड करेगा जब काम में deploy शामिल हो। AGENTS.md में रखने पर वह हर turn पर tokens खर्च करेगा, जबकि हम इसका उपयोग हर हफ़्ते करते हैं।”

एक agent जिसे दूसरा agent tool call के ज़रिए शुरू करता है। यह अपने session और context window में चलता है और एक tool result के रूप में जवाब देता है। यह handoff से अलग है — parent स्पष्ट रूप से परिणाम की अपेक्षा करता है; handoff में लौटने का रास्ता नहीं होता। यह आगे subagents शुरू नहीं कर सकता — tree केवल एक स्तर गहरा होता है। Subagents का उद्देश्य context को अलग रखना है, पदानुक्रम बनाना नहीं।

मकसद है शोर वाले काम को parent के context से बाहर रखना। Parent के भीतर व्यापक खोज या फ़ाइलें पढ़ने की लंबी मुहिम चलाएँ तो उसके ज़्यादातर tool results केवल उत्तर ढूँढ़ने तक मायने रखते हैं, लेकिन बाकी session के लिए parent के context में रह जाते हैं। Subagent के भीतर काम करें तो शोर एक अस्थायी window भरता है — parent के context में केवल अंतिम रिपोर्ट आती है। रिपोर्ट एक secondary source है: parent को subagent का विवरण मिलता है कि उसने क्या पाया, कच्चे परिणाम नहीं; इसलिए रिपोर्ट में छोड़ी गई बात parent को दिखाई नहीं देती।

Subagents साथ-साथ भी चलते हैं — parent स्वतंत्र हिस्सों पर कई agents को एक बार में भेज सकता है।

उपयोग:

“grep के नतीजे मेरा context भर रहे हैं।”

“खोज के लिए subagent शुरू करें — वह शोर पर अपना context window खर्च करेगा और केवल वे दो file paths बताएगा जिनकी आपको वास्तव में ज़रूरत है।”

काम करने का ऐसा तरीका जिसमें एक या अधिक लोग session के दौरान agent के साथ मिलकर काम करते हैं — वास्तविक समय में समीक्षा, दिशा बदलना या सहयोग करना। मनुष्य मौजूद और सक्रिय होता है, केवल अलग-अलग कार्रवाइयों की अनुमति देने वाला gate नहीं।

इसके विपरीत AFK काम में agent बिना निगरानी चलता है और आप बाद में नतीजे का मूल्यांकन करते हैं। Human-in-the-loop का अर्थ है समस्याएँ तब पकड़ना जब उन्हें ठीक करना अभी सस्ता हो: आप agent को गलत फ़ाइल चुनते, आवश्यकता गलत समझते या गलत रास्ते पर बढ़ते देखते हैं और एक वाक्य में उसे दिशा देते हैं — बजाय इसके कि बीस मिनट का आत्मविश्वास भरा काम उस गलती पर बन चुका हो और तब आपको पता चले। Agents को भरोसेमंद ढंग से यह नहीं पता चलता कि वे रास्ते से भटके हैं; अकेला छोड़ने पर वे रुककर पूछने के बजाय आगे बढ़ते रहते हैं।

कौन-सा तरीका सही है, यह काम पर निर्भर करता है। स्पष्ट रूप से निर्दिष्ट, कम जोखिम वाले और आसानी से जाँचे जा सकने वाले काम AFK के लिए ठीक हैं। अस्पष्ट या अपरिवर्तनीय काम, या ऐसा काम जिसका पूरा हुआ परिणाम जाँचना कठिन हो — जैसे schema migration, पेचीदा design निर्णय या production को छूने वाली कोई भी चीज़ — loop में बने रहने के लिए उपयुक्त है। मूल निर्णय यही है: गलत मोड़ कितना महँगा पड़ेगा और आपको उसका पता कितनी देर से चलेगा?

कुछ काम स्वभाव से loop में ही होते हैं, क्योंकि आपका प्रत्युत्तर ही उनका input है। Grilling तभी काम करता है जब आप सवालों के जवाब देने के लिए मौजूद हों; prototyping तभी काम करता है जब आप artifact पर प्रतिक्रिया देने के लिए मौजूद हों।

Loop में बने रहने से आपका ध्यान खर्च होता है, जो सीमित संसाधन है। Agents के साथ बेहतर होने का एक हिस्सा अधिक काम को सुरक्षित रूप से loop से बाहर करना है — योजनाओं, automated checks और अंत में human review के सहारे, पूरे समय निगरानी के बजाय। software factory sessions को triggers से शुरू करके इसे और आगे ले जाती है, ताकि काम शुरू करने के लिए भी आपको पहल न करनी पड़े।

उपयोग:

“इसे रात भर AFK चलाएँ?”

“नहीं, schema migration है — इसे human-in-the-loop रखें। मैं हर चरण देखना चाहता हूँ और यदि वह backfill का गलत column चुने तो दिशा बदलूँगा।”

कीबोर्ड से दूर। काम करने का ऐसा तरीका जिसमें उपयोगकर्ता session शुरू करता है और agent को बिना निगरानी काम करने देता है। AI coding की कार्यक्षमता बढ़ाने वाला गुणक — जब आप सोते, खाते या किसी दूसरे काम में लगे हों, तब कई AFK sessions एक साथ चल सकते हैं। सुरक्षित रूप से चलाने के लिए आमतौर पर ढीला permission mode और sandboxing दोनों चाहिए।

आपके मौजूद न होने पर agent अस्पष्टता को अलग तरह से संभालता है। जब आप देख रहे होते हैं, अस्पष्ट निर्णय सवाल बनकर सामने आता है और आप जवाब देते हैं; आपके चले जाने पर agent कोई default चुनकर आगे बढ़ता है और बाद के हर निर्णय की नींव उस अनुमान पर बनती है। आम विफलता यह है कि आप लौटें तो घंटों का आत्मविश्वास भरा, पूरा काम किसी गलत निर्णय पर बना हो जो पहले दस मिनट में लिया गया था। काम लापरवाही से नहीं हुआ — वह सुसंगत है, बस गलत बात के बारे में सुसंगत है।

Run के दौरान आप input नहीं दे सकते, इसलिए उससे पहले और बाद में दें। पहले: अस्पष्टता पहले ही सुलझा लें — grilling session या लिखित spec के ज़रिये — ताकि agent को अकेले भरने के लिए कम खाली जगहें रहें। दौरान: automated checks और automated review आपके न दिए ध्यान की जगह लेते हैं और यांत्रिक रूप से पकड़ी जा सकने वाली बातों पर जल्दी विफलता दिखाते हैं। बाद में: run की समाप्ति किसी review करने योग्य चीज़ में हो — PR में, पहले से merge किए गए बदलावों में नहीं। AFK human review को हटाता नहीं; उसे अंत तक टालता है, इसलिए अंत में आया परिणाम समीक्षा करने लायक होना चाहिए। इसी कारण AFK runs में AX सबसे अधिक मायने रखता है — कोई निगरानी न कर रहा हो तो environment ही agent का एकमात्र सहारा है।

इससे बचें: “background agent” — यह मशीन पर ज़ोर देता है (“background में चल रहा है”), मनुष्य की स्थिति पर नहीं (“उपयोगकर्ता वहाँ से चला गया है”)। AFK उस महत्वपूर्ण तथ्य का नाम है: उपयोगकर्ता निगरानी नहीं कर रहा।

उपयोग:

“मैं इसे AFK चला रहा हूँ — refactor पर तीन sandboxed agents; सुबह PR की समीक्षा करूँगा।”

“Bypass permissions?”

“हाँ, केवल पढ़ने वाला filesystem, कोई network नहीं।”

environment में चलने वाली नियतात्मक जाँच — tests, type checks, lints, build, pre-commit hooks। पास/फ़ेल, कोई निर्णय नहीं। ऐसा संकेत जिससे agent किसी और को शामिल किए बिना अपनी गलती सुधार सकता है। अस्थिर test टूटी हुई जाँच है, जाँच का अभाव नहीं; automated checks को डिज़ाइन से नियतात्मक होना चाहिए।

स्व-सुधार एक चक्र की तरह काम करता है। Agent बदलाव करता है, tool call के रूप में जाँच चलाता है, और विफलता का आउटपुट उसके context window में आता है — फ़ाइल और पंक्ति सहित type error, या अपेक्षित और वास्तविक मानों सहित असफल assertion। इससे agent समस्या ठीक करके जाँच फिर चला सकता है और पास होने तक यह प्रक्रिया दोहराता है, बिना किसी मनुष्य को loop में लाए। इसी से यह चक्र भरोसेमंद बनता है: वही कोड हमेशा वही निर्णय देता है, इसलिए पास होने का अर्थ है। अस्थिर जाँच इस भरोसे को बिगाड़ती है — agent सही कोड को “ठीक” कर सकता है या वास्तविक विफलता के बावजूद बार-बार प्रयास कर सकता है।

इसीलिए अच्छी जाँचें codebase के AX का बड़ा हिस्सा होती हैं। सख्त types, तेज test suite और linter वाले repo में agent अपनी अधिकांश गलतियाँ आपके देखने से पहले पकड़ लेता है; इनमें से कुछ भी न हो तो agent अपना बनाया सब कुछ भेज देता है। यह अंतर AFK runs में सबसे ज़्यादा मायने रखता है, जहाँ run के दौरान जाँचें ही सत्यापन का एकमात्र साधन हैं। फिर भी जाँच केवल वही पकड़ती है जिसका वह दावा करती है — green checks का अर्थ है कि जाँचे गए गुण सही हैं, यह नहीं कि कोड सही है। निर्णय की ज़रूरत वाले खाली स्थान automated review और human review के लिए हैं।

इससे बचें: “feedback loop” / “backpressure” — दोनों जाँच को review के साथ मिला देते हैं। इससे बचें: “test” — tests automated checks हैं, लेकिन हर automated check test नहीं होता।

उपयोग:

“Agent AFK runs में लगातार टूटा हुआ कोड भेजता है।”

“sandbox में कौन-सी automated checks जुड़ी हैं?”

“बस unit tests।”

“Typecheck और lint जोड़ें — PR आने से पहले वह उनसे मिली जानकारी के आधार पर खुद को सुधार लेगा।”

एक agent द्वारा दूसरे agent के काम की समीक्षा, अक्सर अलग model या system prompt के साथ। यह नियतात्मक नहीं है: reviewer निर्णय बनाता है। कहीं भी चल सकता है — PR पर merge से पहले, commit history के बाद, या subagent के रूप में session के बीच। CI में LLM-as-judge automated review है, automated check नहीं; श्रेणी इस बात से तय होती है कि assertion क्या करता है, इस बात से नहीं कि वह कहाँ चलता है।

काम कर रहे agent से अलग होना ही इसकी प्रभावशीलता का कारण है। जिस agent ने code लिखा है, उसी से अपने काम की समीक्षा करवाने पर बहुत कम लाभ मिलता है — जिस session ने bug बनाया उसमें उसे बनाने का तर्क भी मौजूद होता है, और agent अपने निष्कर्षों को पुष्टि की तरह वापस पढ़ता है। नए context window वाला reviewer उस लगाव से मुक्त होता है: वह diff को किसी अजनबी की तरह देखता है, और समीक्षा इसी पर निर्भर करती है। अलग model या review-विशिष्ट system prompt इसे और बेहतर करता है — अलग blind spots और एक अस्पष्ट “समस्याएँ ढूँढ़ो” के बजाय उन बातों पर केंद्रित prompt जिनकी आपको सचमुच परवाह है (security, API contracts, performance)।

यह अन्य समीक्षा-स्तरों के बीच बैठता है। Automated checks नियतात्मक होते हैं और यांत्रिक ढंग से साबित की जा सकने वाली बातें पकड़ते हैं; human review महँगी है और बड़े पैमाने पर सबसे कठिन होती है। Automated review बीच में आता है: यह निर्णय-आधारित समस्याएँ पकड़ता है — भ्रामक function name या छूटा हुआ edge case — मशीन की लागत पर। नियतात्मक न होने के कारण यह बातें छोड़ सकता है और गैर-मुद्दों को चिह्नित कर सकता है; इसे मनुष्य की समीक्षा का विकल्प बनाने वाले gate के बजाय, मनुष्य के देखने से पहले न्यूनतम गुणवत्ता बढ़ाने वाला filter समझें।

इससे बचें: “AI review” / “agent review” — काम कर रहे agent से अंतर बताने के लिए ये बहुत अस्पष्ट हैं।

उपयोग:

“AFK runs से बहुत सारे खराब PR आ रहे हैं।”

“Merge से पहले automated review चरण जोड़ें — अलग model, अलग system prompt, security और contract बदलावों पर केंद्रित।”

agent द्वारा तैयार किए गए code को उपयोगकर्ता का पढ़ना और उसके बारे में निर्णय लेना। Diff या बदली हुई फ़ाइलों को पढ़ना गिना जाता है; agent ने क्या किया, इसका विवरण पढ़ना नहीं — वर्णन artifact नहीं है। विवरण secondary source है, जिसे समीक्षा के अधीन पक्ष लिखता है; diff primary source है, और review का अर्थ उसे पढ़ना है।

Agents तैयार किए जाने वाले code की मात्रा बढ़ाते हैं, इसलिए review बाधा बन जाता है। एक उपयोगी विचार अलग-अलग review रणनीतियों को परतों में रखना है। Automated checks यांत्रिक विफलताएँ पकड़ते हैं, automated review वे विफलताएँ पकड़ता है जिन्हें बताया जा सकता है, और human review उन बातों के लिए बचा रहता है जिनका निर्णय केवल आप कर सकते हैं — क्या बदलाव सही बदलाव है, क्या तरीका codebase के अनुरूप है, क्या यह चीज़ होनी भी चाहिए।

Review पहले करने पर सस्ता भी पड़ता है। काम शुरू होने से पहले plan पढ़ना या काम के बीच छोटा diff देखना कुछ मिनट लेता है; AFK run के बाद पूरी हो चुकी branch की परतें खोलने में अधिक समय लगता है। Review का checkpoint कहाँ रखना है, यह human-in-the-loop का निर्णय है, बाद में याद आने वाली बात नहीं।

Avoidकेवल "code review" कहना — इससे human और automated review के बीच अस्पष्टता रहती है।

Usage

"मैंने AFK output का human review किया।"

"तुमने diff पढ़ा या सिर्फ़ summary?"

"Diff। Summary ने कहा था कि बेकार code हटाया — पता चला function एक generated file से call होता था।"

काम करने का ऐसा तरीका जिसमें उपयोगकर्ता agent का code बिना human review स्वीकार करता है। Diff को अपारदर्शी माना जाता है — यह मायने रखता है कि program कैसे व्यवहार करता है, भीतर क्या है यह नहीं। Automated review और automated checks फिर भी चल सकते हैं; vibe coding इनके बारे में कोई रुख नहीं तय करता।

यह शब्द Andrej Karpathy से आया है, जिन्होंने इसे coined it in early 2025: आप “पूरी तरह vibes के आगे समर्पण कर देते हैं” और “भूल जाते हैं कि code मौजूद भी है” — जो चाहिए वह बताते हैं, लौटे हुए परिणाम को स्वीकार करते हैं और उसे चलाकर परखते हैं।

Vibe coding निरीक्षण के बदले गति देता है। Agent-संचालित काम में diff पढ़ना आमतौर पर सबसे धीमा चरण है, इसलिए इसे छोड़ने से मुख्य अड़चन हट जाती है। ऐसे code के लिए जिसकी विफलता सस्ती हो — prototypes, एक बार चलने वाले scripts और आंतरिक tools — यह उचित समझौता है। जोखिम code की आयु और उसके दाँव के साथ बढ़ता है।

लागत बाद में सामने आती है। Vibe-coded बदलाव ऐसे codebase में जमा होते जाते हैं जिसे किसी ने पढ़ा नहीं, और केवल व्यवहार की जाँच हुई होती है — इसलिए व्यवहार से न दिखने वाली बातें, जैसे logs में लिखा secret, छूटा हुआ edge case या चुपचाप गलत data handling, बिना देखे ही जारी हो जाती हैं। कोई व्यक्ति पहली बार system debug करे, वही पहली बार होता है जब कोई code पढ़ता है। Human review हट जाने पर जो भी automated verification बची हो — tests, types, automated review — वही एकमात्र gate है जिससे code गुज़रता है। इसी रुख को पूरे codebase या उसके किसी हिस्से पर लागू करना, जहाँ बदलाव software factory से आते हैं, dark factory कहलाता है।

इससे बचें: “vibe coding” को “घटिया AI coding” का समानार्थी कहना — यह शब्द समीक्षा के रुख का नाम है, बने हुए code की गुणवत्ता का नहीं।

उपयोग:

“क्या आपने देखा कि इसने auth flow में क्या बदला?”

“Vibe coded किया — login अब भी काम करता है, बस उतना ही जाँचा।”

“Push करने से पहले diff पढ़ो; auth में vibes पर चलना ही secrets को logs में पहुँचाता है।”

क्या बनाया जा रहा है, इसकी वह साझा समझ जो उपयोगकर्ता और agent के बीच समान रूप से मौजूद है, लेकिन किसी भी asset से अलग है। Brooks का शब्द (The Design of Design): बातचीत, handoff artifacts और code सभी ऐसे assets हैं जो design concept को पकड़ने या उस तक पहुँचने की कोशिश करते हैं, लेकिन इनमें से कोई भी स्वयं वह concept नहीं है। Design concept की गुणवत्ता उस बातचीत की गुणवत्ता में महसूस होती है जिसने उसे बनाया।

यह शब्द उस अंतर को नाम देता है जो एक परिचित निराशा के पीछे है: agent ठीक वही लिखता है जो आपने माँगा था, फिर भी वह गलत है। आम कारण यह है कि आपने खुद अभी पूरी तरह तय नहीं किया था कि आप क्या चाहते हैं। Design concept आपके मन में पूरा नहीं हुआ था — आपके prompt ने वे हिस्से पकड़ लिए जिन पर आपने विचार कर लिया था और उन हिस्सों पर कुछ नहीं कहा जिन पर आपने अभी विचार नहीं किया था। Agent ने उन ख़ामोश जगहों को अपनी धारणाओं से भर दिया, क्योंकि उनके साथ मिलाने के लिए कुछ था ही नहीं। कुछ भी खराब नहीं हुआ। साझा design concept था ही नहीं, क्योंकि साझा करने लायक कोई पूर्ण concept अभी बना ही नहीं था।

आप समझ सकते हैं कि design concept साझा है, ठीक वैसे ही जैसे किसी सहकर्मी के साथ समझते हैं: दूसरा पक्ष ऐसे सवालों के जवाब देना शुरू कर देता है जिन्हें आपने अभी पूछा भी नहीं, और जवाब वैसे होते हैं जैसे आप देते। तब तक काम बातचीत है — grilling उसका जान-बूझकर किया गया रूप है — और बहुत जल्दी spec लिखना बस असहमति को अधिक टिकाऊ asset में दर्ज करना है। सीखने के साथ design concept भी बदलता है; assets पीछे रह जाते हैं, इसलिए पिछले सप्ताह की समझ के प्रति ईमानदार spec भी इस सप्ताह के session को गुमराह कर सकता है।

Usage

"यह ठीक वही लिख रहा है जो मैंने माँगा था, फिर भी गलत है।"

"आप दोनों का design concept अभी साझा नहीं है — यह खाली जगहों में धारणाएँ भर रहा है। इसे spec लिखने देने से पहले बात जारी रखें, जब तक रद्दीकरण, धनवापसी और आंशिक पूर्ति — सब पर आप दोनों की समझ मेल न खाने लगे।"

agent के साथ design concept विकसित करने की एक तकनीक: agent उपयोगकर्ता से Socratic शैली में, एक बार में एक निर्णय पर सवाल करता है और हर निर्णय के लिए सुझाया गया उत्तर देता है। तैयार योजना तक जल्दबाज़ी को धीमा करती है — concept स्थिर होने तक कोई handoff artifact नहीं लिखा जाता।

यह तकनीक इसलिए है क्योंकि agents चुपचाप खाली जगहें भर देते हैं। दो-पंक्ति के prompt से spec लिखने को कहें तो agent उन निर्णयों पर नहीं रुकता जो आपने नहीं लिए — वह default चुनकर लिख देता है। नतीजा पूरा दिखता है और अंदाज़ों तथा आपके चुनावों में फ़र्क़ नहीं दिखता, इसलिए आपको देर से पता चलता है: review के समय या जब बनी सुविधा किसी edge case को ऐसे संभालती है जैसा आपने कभी चुना ही नहीं। Grilling इसे उलट देती है — अंदाज़ा लगाने के बजाय agent को पूछना पड़ता है।

यह human-in-the-loop तकनीक है: input आपके जवाब हैं। जब किसी सवाल का जवाब बातचीत में नहीं दिया जा सकता — क्योंकि आपको चीज़ देखनी होगी — तब prototyping पर जाएँ।

उपयोग:

“यह सीधे spec लिखने लगा और cancellation logic गलत समझा।”

“पहले उससे विस्तार से पूछें — doc में कुछ तय करने से पहले partial cancels, refunds और timing के बारे में पूछने दें। Code के बजाय बातचीत में बात सुलझाना सस्ता है।”

Agent से किसी चीज़ का जल्दी तैयार, मोटा-मोटा संस्करण बनवाना, जब बातचीत में पर्याप्त बारीकी न हो और चर्चा के लिए वास्तविक artifact चाहिए।

Grilling बातचीत में design निर्णय हल करता है। बातचीत सस्ती है, लेकिन उसमें बारीकी कम होती है: कुछ सवालों के जवाब शब्दों में नहीं दिए जा सकते — interaction कैसा लगता है, असली calling code में API का आकार सहज है या नहीं, या वास्तविक data के आकार पर layout काम करता है या नहीं। बातचीत में सवाल आता है और आपका सच्चा जवाब होता है “पता नहीं, देखना पड़ेगा।” इसके बाद चर्चा गोल-गोल घूमती है। उसकी जगह agent से चीज़ बनवाएँ, उसे देखें और जवाब लेकर बातचीत पर लौटें।

Agents निर्माण की लागत घटाते हैं, इसी से यह व्यावहारिक बनता है। जिस मोटे संस्करण का mockup कभी पूरा दिन लेता था, वह अब कुछ मिनट लेता है, इसलिए ऐसा नियमित रूप से करना लाभदायक है। यह human-in-the-loop तकनीक है: prototype आपकी प्रतिक्रिया के लिए मौजूद होता है।

आमतौर पर एक बार देखकर नहीं रुकते। Prototype के साथ दोहराएँ — प्रतिक्रिया दें, बदलाव माँगें, फिर प्रतिक्रिया दें — ताकि हर दौर वास्तविक artifact के आधार पर एक और निर्णय सुलझाए, बातचीत से संभव स्तर से अधिक बारीकी पर।

Prototype को पूरी तरह खुरदुरा रखना ज़रूरी नहीं। जिन हिस्सों का आप मूल्यांकन कर रहे हैं उन्हें production गुणवत्ता तक बना सकते हैं, ताकि निर्णय होने पर जिस component या API पर आपने प्रतिक्रिया दी वह वास्तविक codebase में ले जाई जा सके। इसलिए spec के लिए prototyping आवश्यक सामग्री है।

उपयोग:

“हम आधा घंटा इस बात पर बहस कर चुके हैं कि wizard एक page हो या तीन steps।”

“बातों से तय नहीं होगा — agent से दोनों का prototype बनवाएँ। पाँच मिनट में दोनों पर क्लिक करके पता चल जाएगा।”

Developer experience — मनुष्यों के लिए किसी codebase और उसके toolchain में अच्छा काम करना कितना आसान है। अच्छा DX तेज़ feedback, स्पष्ट error messages, आपके वास्तविक सवाल का उत्तर देने वाले documentation और पहली कोशिश में काम करने वाली setup है। यह शब्द AI coding से बहुत पहले का है; इस डिक्शनरी में मुख्यतः AX के साथ तुलना के लिए है।

DX मनुष्य और codebase के बीच की बातचीत है — इससे अधिक कुछ नहीं। दोनों पाठकों के बीच मुख्य अंतर यह है कि मनुष्य stateful हैं और agents stateless। मनुष्य codebase को एक बार सीखता है और वह ज्ञान हर अगले दिन साथ रखता है, इसलिए खराब DX के बावजूद काम चल सकता है: धीमे CI के बदले pushes एक साथ करता है, docs न हों तो Slack पर एक बार पूछता है, उलझी संरचना में चीज़ों की जगह याद रखता है। ऐसे उपाय जमा होते जाते हैं और अंततः टीम ऐसे codebase में भी उत्पादक हो जाती है जो हर कदम पर अड़चन डालता है।

Agents उसी codebase को इन जमा हुए उपायों के बिना देखते हैं। Sessions के पार stateless होने के कारण agent हर बार codebase को शुरू से सीखता है — तेज़ test suite और स्पष्ट error messages से उसे फ़ायदा होता है, लेकिन कल समझी हर बात चली जाती है, जब तक वह environment में न लिखी गई हो; agent उसे केवल tool results के ज़रिए देखता है। AX इसी अंतर को नाम देता है: DX के वे हिस्से जो developer के agent होने पर भी काम आते हैं, और वे चिंताएँ जो मनुष्यों को नहीं होतीं, जैसे context window को खाली रखना।

दोनों में समानता के कारण DX पर निवेश अक्सर बिना अतिरिक्त प्रयास के AX भी बेहतर करता है — सख्त types, तेज़ tests और अनुमानित संरचना दोनों की मदद करते हैं। अंतर का अर्थ है कि ऐसा हमेशा नहीं होता: सुंदर onboarding doc एक सप्ताह तक मनुष्य की मदद करता है, agent की नहीं, जब तक उस तक AGENTS.md से पहुँचा न जा सके।

उपयोग:

“हमारा DX ठीक है — नए कर्मचारी एक सप्ताह में उत्पादक हो जाते हैं।”

“क्योंकि कोई पूरे सप्ताह उनके साथ बैठता है। Agent को वह सप्ताह नहीं मिलता; AX अलग से जाँचें।”

एजेंट अनुभव — codebase में किसी agent के अच्छा काम करने के लिए environment कितनी अच्छी तरह तैयार है। यह DX का agent-केंद्रित समकक्ष है। जब वही agent एक repo में अच्छा और दूसरे में खराब काम करे — वही model, वही harness — तो आमतौर पर अंतर AX का होता है। सहज प्रतिक्रिया model को दोष देने या prompt फिर से लिखने की होती है; समाधान अधिकतर repo में होता है।

अच्छे AX के तीन मुख्य आयाम हैं:

AX और DX एक-दूसरे से मिलते हैं — अच्छी जाँचें और साफ़ architecture दोनों तरह के उपयोगकर्ताओं की मदद करते हैं — लेकिन दोनों अलग भी होते हैं। मनुष्य टीम का मौखिक ज्ञान, धीमा CI और “billing module के बारे में Sarah से पूछें” स्वीकार कर लेते हैं; agents ऐसा नहीं कर सकते। Agents को IDE tooltips या सुंदर dashboards से लाभ नहीं होता; उन्हें विफलताओं का पाठ tool result में चाहिए। किसी codebase का DX अच्छा और AX खराब हो सकता है।

इससे बचें: AX को DX का समानार्थी समझना — दोनों प्रकार के उपयोगकर्ताओं को अलग निवेश चाहिए।

उपयोग:

“API repo में agent शानदार code लिखता है और frontend में घटिया।”

“API repo में सख्त types और तेज़ test suite हैं; frontend में दोनों नहीं और चालीस skills हमेशा लोड रहती हैं। यह AX का अंतर है, model की समस्या नहीं।”

ऐसी कामकाजी व्यवस्था जिसमें agent sessions किसी व्यक्ति के बजाय triggers से शुरू होते हैं — issue बनना, समय-सारणी, CI विफलता या दूसरा session पूरा होना — ताकि अधिक काम AFK चले और मानव का ध्यान बचे हुए human-in-the-loop निर्णयों पर लगे।

Factory के बिना हर session इसलिए शुरू होता है क्योंकि किसी ने उसे शुरू किया। पूरी तरह AFK काम भी किसी व्यक्ति के session खोलने, उसे ticket दिखाने और चालू करने की प्रतीक्षा करता है। टीमें इससे अधिक काम भेजना चाहती हैं। Factory sessions शुरू करने की प्रक्रिया से मनुष्य को हटाती है, ज़रूरी नहीं कि बाकी हर काम से भी।

आम triggers और उनसे शुरू होने वाले sessions:

Factory को पूरी software प्रक्रिया का काम संभालना ज़रूरी नहीं। एक cron job जो एक प्रकार का session चलाती है और review करने योग्य एक PR खोलती है, वह भी factory है। छोटी शुरुआत उपयोगी है: संकीर्ण चक्र छोटे, एक जैसे PR बनाता है; उनकी समीक्षा से पता चलता है कि उसे बड़ा करने से पहले उस चक्र पर कितना भरोसा किया जा सकता है।

Factory में मनुष्य कहीं भी हो सकते हैं — sessions शुरू करने वाले issues लिखना और label करना, implementation शुरू होने से पहले योजना स्वीकृत करना, merge से पहले human review करना। कौन-से निर्णय मनुष्य के पास रहें, यह तय करना मुख्य design प्रश्न है। ऐसा codebase, या उसका हिस्सा, जिसके factory के output की कोई मनुष्य समीक्षा न करे, dark factory है।

उपयोग:

“सभी `no-floating-promises` उल्लंघन किसने ठीक किए?”

“Factory ने। Cron job हर रात एक lint rule चुनकर PR खोलती है। मैं बस सुबह उसकी समीक्षा करता हूँ।”

ऐसा codebase, या उसका हिस्सा, जहाँ software factory कोड लिखती है और कोई मनुष्य उसे पढ़ता नहीं। कोई human review नहीं होता। लोग अब भी काम शुरू करने वाले issues लिख सकते हैं, लेकिन निकले हुए कोड को कोई नहीं पढ़ता। नाम उन “lights-out” कारखानों से आया है जहाँ फ़र्श पर कोई व्यक्ति न हो तब भी चीज़ें बनती हैं।

Dark factory किसी एक बदलाव के लिए नहीं, बल्कि कोड के एक पूरे क्षेत्र के लिए vibe coding है। Vibe coding करते समय आप अपने माँगे हुए बदलाव को पढ़ने का निर्णय नहीं लेते, लेकिन जानते हैं कि बदलाव मौजूद है। Dark factory में टीम यह निर्णय पूरे क्षेत्र के लिए एक बार लेती है। उसके बाद कोई व्यक्ति हर बदलाव की माँग नहीं करता या उसे देखता नहीं। नए काम के triggers शुरू होते ही बदलाव आते रहते हैं।

जब कुछ टूटता है, तब समस्या दिखाई देती है। आपको नहीं पता कि क्या बदला, क्योंकि किसी ने बदलाव पढ़े नहीं। आपको ऐसा कोड debug करना पड़ता है जिसे टीम में किसी ने पढ़ा नहीं। कारण कई बदलावों में से किसी में हो सकता है, और हर बदलाव जाँचों से पास हुआ है।

Automated checks और automated review ही एकमात्र द्वार हैं। यदि उन्हें समस्या नहीं मिलती, तो समस्या कोड में चली जाती है।

इससे बचें: किसी codebase को सिर्फ़ इसलिए “dark” कहना कि उसकी factory बिना निगरानी चलती है। यदि agent sessions AFK चलती हैं और कोई व्यक्ति उनके PR की समीक्षा करता है, तो वह software factory है, dark factory नहीं।

उपयोग:

“Billing service में retry logic किसने बदला? टीम में किसी को याद नहीं।”

“Billing service एक dark factory है। Agents CI पास करने वाले सभी बदलाव merge कर देते हैं। उस बदलाव को किसी ने पढ़ा नहीं।”