चार Layers: Prompt, Context, Harness, Loop
12 concepts · लगभग 50 minutes · कुछ install नहीं करना · वह छोटा course जिस पर आप बार-बार लौटेंगे
एक agent चालीस minutes तक चलता है। वह पचास dollars खर्च करता है। ऐसा कुछ नहीं बनाता जिसे आप use कर सकें। बाद में log पढ़ने पर साफ़ दिखता है कि उसने वही तीन चीज़ें बार-बार आज़माईं, हर बार केवल कुछ शब्द बदले।
आप क्या बदलेंगे?
लगभग हर कोई prompt बदलता है। वही सबसे पहले दिखता है और दस seconds में edit हो सकता है। इसलिए लोग उसे फिर लिखते हैं, run दोबारा शुरू करते हैं और agent को अगले चालीस minutes वही काम करते देखते हैं।
Prompt ठीक था। उस system में ऐसा कुछ था ही नहीं जो पहचान सके कि run ने progress करना बंद कर दिया है, इसलिए किसी चीज़ ने उसे रोका नहीं। Fix लगभग ग्यारह शब्दों का था, दूसरी file में, ऐसी layer पर जिसका नाम ज़्यादातर लोग नहीं जानते।
यह course आपको वे नाम देता है। चार नाम हैं: prompt, context, harness, loop। ये चुनने वाली चार skills या चढ़ने वाले चार steps नहीं हैं। ये चार containers हैं, हर एक अगले के अंदर है और हर एक अलग काम का ज़िम्मेदार है। इन्हें देखना सीखने के बाद "मेरा agent टूट गया है" एक address वाले सवाल में बदल जाता है: कौन-सी layer टूटी?
यह जानबूझकर इस section का सबसे छोटा course है। यह map है, और जो map याद न रहे वह अपना काम नहीं कर रहा।
आपने कम-से-कम एक बार general agent चलाया होना चाहिए, किसी भी door से: code के साथ काम करते हैं तो Claude Code और OpenCode, नहीं तो Cowork और OpenWork। Spec-Driven Development मदद करता है, लेकिन ज़रूरी नहीं है। यहाँ repository, database या install की ज़रूरत नहीं है। एक chat tab और पहले इस्तेमाल किया हुआ एक agent ही पूरा setup है।
📚 Teaching Aid
पूरी Presentation देखें: चार Layers: Prompt, Context, Harness, Loop
ये शब्द अभी confusing क्यों लगते हैं
Online पढ़ते समय ये शब्द फिसलते हुए लगें, तो problem आप नहीं हैं। यह field नई है और इसे vocabulary ग़लत order में मिली।
कुछ समय पहले केवल एक layer थी जिसे कोई छू सकता था। आप message type करते थे और जवाब पढ़ते थे। "Prompt engineering" पूरी skill का नाम था, क्योंकि prompt ही पूरी surface थी।
फिर tools तेज़ी से बाहर की ओर बढ़े। Coding agent ने permissions file, rules file और hooks दिए। यह model के चारों ओर एक configurable layer है। फिर schedules और routines आए। यह पहली layer के चारों ओर दूसरी configurable layer है। कम समय में दो नई surfaces आ गईं।
Vocabulary साथ नहीं चल सकी। हर surface का नाम उस व्यक्ति ने रखा जिसने पहले उसके बारे में लिखा, और नाम आपस में टकरा गए। "Context engineering" कभी window है और कभी model run होने से पहले किया गया सब कुछ। "Graph" तीन अलग चीज़ों के लिए इस्तेमाल होता है, जिन्हें Concept 11 अलग करता है। सबसे ज़्यादा परेशानी harness देता है। Online writing में harness और loop को अक्सर एक ही layer मान लिया जाता है। कुछ writing इस शब्द को platform के लिए use करती है जो tools, credentials और security boundary देता है।
यह शब्दों पर harmless बहस होती, अगर एक बात न होती। Missing permission rule और missing schedule अलग bugs हैं। वे अलग surfaces पर रहते हैं और अलग लोग उन्हें fix करते हैं। दोनों के लिए एक शब्द आपको ग़लत जगह देखने भेजता है, जैसा opening story में हुआ।
इसलिए यह course दो काम करता है। यह चार layers को containers की तरह दिखाता है। और ऐसा test देता है जो शब्द दोबारा बदलने के बाद भी काम करेगा।
आसान भाषा में मुख्य शब्द
इसे अभी एक बार पढ़ें। कोई term धुँधला हो तो वापस आएँ। हर term बाद में विस्तार से समझाया गया है।
| Term | आसान अर्थ |
|---|---|
| Prompt | भेजा गया message: ask, examples, format और role। |
| Context window | एक response लिखते समय model जो कुछ देख सकता है। जो इसमें नहीं है, वह fact की तरह available नहीं है। |
| Curator | जो तय करता है कि window में क्या जाए, किस order में जाए और क्या बाहर रहे। |
| Beat | Agent का एक पूरा turn: आपकी instruction से लेकर उसके सारे tool calls और फिर उसके शांत होने तक। |
| Harness | Model के चारों ओर का code जो एक beat चलाता है। |
| Loop | Harness के चारों ओर का system जो beats शुरू करता, judge करता और उनके बीच याद रखता है। |
| Heartbeat | Beat शुरू करने वाली चीज़: schedule, event या condition। |
| Spine | Model के बाहर save state, ताकि अगला beat पिछले beat का काम जान सके। |
| Stopping condition | Test की जा सकने वाली rule जो बताती है कि काम पूरा है। इसे maker के अलावा कोई चुनता और enforce करता है। |
| Maker-checker | एक agent काम करता है। अलग agent या command उसे check करता है। |
| Human gate | वह point जहाँ run जारी होने से पहले इंसान फैसला करता है। |
| Sub-agent | अपनी window वाला helper जो एक job करता है और summary लौटाता है। |
| Graph | ऐसे कई stacks की topology: आगे क्या चले, हर edge पर कौन-सा state जाए और कौन किसे check करे। |
ये शब्द Loop Engineering और Harness Engineering में फिर मिलेंगे। यह जानबूझकर है। यह course map है। वे courses territory हैं: वे वह बनाते हैं जिसका यह केवल नाम देता है।
तस्वीर: चार containers, हर एक अगले के अंदर
Containers, steps नहीं। हर beat अब भी prompt बनाता है। Checker और human gate loop पर रहते हैं, beat के अंदर नहीं, क्योंकि काम बनाने वाली चीज़ यह तय नहीं कर सकती कि finished किसे मानना है।
तस्वीर असल में यह sentence कह रही है। Course खत्म होने से पहले यह तीन बार और आएगा:
Bad context के अंदर अच्छा prompt fail होता है। Bare harness के अंदर अच्छा context fail होता है। Loop के बिना अच्छा harness idle रहता है।
"हर एक अगले के अंदर" का practical मतलब यही है। Inner layer की कोई चीज़ missing outer layer से नहीं बचा सकती और outer layer टूटी inner layer को नहीं बचा सकती।
90 seconds में सबसे महत्वपूर्ण claim का proof
इस course की एक मुख्य बात को होते देखने के बाद मानना आसान है। अपना familiar agent खोलें। उसे कोई छोटा real task दें जिसका result check हो सकता हो: run होने वाली script, balance होने वाला spreadsheet total या खुलने वाला link।
काम माँगें, फिर जवाब पढ़ें।
इसे ठीक करें ताकि यह काम करे, फिर बताएं कि कब पूरा हुआ।
जवाब पर भरोसा करने से पहले चीज़ को खुद check करें। Script run करें। Column जोड़ें। Link खोलें।
Real work वाले tasks में अक्सर confident "done, सब ठीक" ऐसे काम के साथ मिलता है जिसे verify ही नहीं किया गया। ऐसा इसलिए नहीं कि model ने झूठ बोला या prompt कमज़ोर था। कारण यह है कि setup में check करना ज़रूरी नहीं था और model के अलावा किसी ने तय नहीं किया कि "done" का मतलब क्या है। उस feeling को याद रखें। Concept 6 इसे समझाता है और बाकी course इसी पर टिका है।
15 minutes: ऊपर की तस्वीर, Concept 2 (चार units of work), और Concept 9 की table। अपनी अगली ख़राब debugging session में वह table सामने रखें।
50 minutes: शुरू से अंत तक, दोनों छोटे observation exercises और अंत का diagnosis drill करते हुए।
बाद में: prose के लिए नहीं, drill के लिए लौटें। ये recipes याद करने के लिए नहीं, ज़रूरत पर देखने के लिए हैं। इस course में याद रखने लायक केवल एक sentence है और वह सबसे अंत में है।
Part 1: Shape
Concept 1: Containers, steps नहीं
इन चार words को अक्सर ladder की तरह दिखाया जाता है: beginners के लिए नीचे prompt, experts के लिए ऊपर loop। तस्वीर चुपचाप वादा करती है कि काफ़ी अच्छे होने पर आप lower steps पीछे छोड़ देंगे।
यह तस्वीर ग़लत है, और पैसे खर्च कराने वाले ढंग से ग़लत है।
हर beat अब भी prompt बनाता है। छह महीने से schedule और checker तथा spine के साथ बिना supervision चल रहा loop भी दिन में कई बार model को message भेजता है। Message vague हो तो loop vague काम को तेज़ी से, timer पर produce करता है। Inner layers पीछे नहीं छूटतीं। आप उन्हें wrap करते हैं।
इसलिए relationship containment है। Prompt window के अंदर है। Window एक beat के लिए बनती है। Beat को run शुरू करता, judge करता और याद रखता है।
इस picture से तीन ग़लत beliefs आसानी से आते हैं। इन्हें अभी हटाना ठीक है:
- Outer का मतलब later नहीं है। आप इन्हें order में build नहीं करते। अक्सर तीन rent करते और एक own करते हैं, जैसा Concept 10 बताता है।
- Outer का मतलब ज़्यादा important नहीं है। Carefully engineered loop के अंदर careless prompt schedule पर bad work और receipt बनाता है। Layers ranked नहीं, nested हैं।
- ये एक box के चार sizes नहीं हैं। Nesting picture एक object के चार versions सुझा सकती है। ये चार सच में अलग objects हैं और अगला concept उन्हें अलग पहचानता है।
Concept 2: Unit-of-work test
हर layer उस काम के piece से define होती है जिसके लिए वह responsible है। ये चार साफ़ हो जाएँ तो नाम कुछ भी हो, आप layer पहचान सकते हैं।
| Layer | Unit of work | आसान अर्थ |
|---|---|---|
| Prompt | One model call | जो type करके enter दबाया। Words बदलें तो prompt बदल गया। |
| Context | The window | उस एक answer के समय model जो कुछ देख सकता है: message, files, earlier turns, rules file और tool results। |
| Harness | One beat | Agent आम तौर पर एक जवाब पर नहीं रुकता। Tool call, result, फिर सोच, फिर call। आपकी instruction से उसके quiet होने तक सब एक beat है। Harness उसे चलाने वाला code है। |
| Loop | The whole run | जब कोई type नहीं कर रहा तब क्या होता है। कोई beat शुरू करता है, कोई work judge करता है और कोई beats के बीच याद रखता है। |
अब test। Vocabulary बदलने के बाद भी यही हिस्सा काम आएगा:
जब blog post, vendor या job description "harness", "context engineering" या "agent loop" कहे, शब्द पर बहस न करें। पूछें: वे किस unit of work की बात कर रहे हैं? One model call, window, one beat या पूरा run?
अगर उनके "harness" में schedule भी है, तो उन्होंने इस किताब की दो layers को एक बनाया है। अगर harness tools और credentials देने वाला platform है, तो उनका मतलब और wider है। कोई भी ग़लत नहीं है। वे अलग maps हैं। अब आप confuse होने के बजाय translate कर सकते हैं।
Part 2: चारों layers, एक-एक करके
Concept 3: Prompt, unit है one model call
Prompt वह message है जिसे आप बनाते हैं: model कौन हो, आपको क्या चाहिए, अच्छा काम कैसा है, उसके examples और answer किस shape में लौटे। यह एक input है और एक response बनाता है।
यह craft लोगों की सोच से narrow है। सबसे weak ingredient खोजें और केवल उसे fix करें। Output shape ग़लत है तो सही shape का example जोड़ें। Tone ग़लत है तो audience बताएं। पाँचों ingredients एक साथ rewrite करने पर पता नहीं चलेगा कि problem कौन थी। AI Prompting in 2026 इस layer को विस्तार से cover करता है।
लोग इस layer पर ज़्यादा invest करते हैं और उसके दो honest reasons हैं। यही एक layer है जिसकी practice बिना code के हो सकती है। और यही दस seconds में edit हो सकती है। ये दोनों अच्छी बातें हैं, लेकिन production में problem आते ही trap बनती हैं, क्योंकि pressure में लोग टूटी चीज़ के बजाय आसानी से बदलने वाली चीज़ पकड़ते हैं।
Prompt layer सच में टूटी हो तो कैसा दिखता है: model ने task समझा और लगभग सही काम किया, लेकिन answer ग़लत shape, length या voice में आया, या वह section missing है जिसे आपने obvious मान लिया था। Facts ग़लत नहीं हैं। बस output माँगे जैसा नहीं है, और अपने words दोबारा पढ़ने पर कारण दिखता है।
Concept 4: Context, unit है window
Window वह सब है जो model एक response लिखते समय देख सकता है। इसे एक direction में literally लें: जो file attach नहीं हुई वह fact की तरह available नहीं है। Yesterday की conversation available नहीं है, जब तक कोई उसे वापस न डाले।
दूसरी direction में literally न लें। Thin window होने पर model empty नहीं होता। Training में सीखी चीज़ें gap भरती हैं। इसी से concept के अंत वाला failure pattern आता है। Missing document पर model blank नहीं होता; वह पहले से ज्ञात सबसे likely बात उठाता और truth जितने confidence से कहता है।
यही layer की defining problem है। Material हमेशा fit होने से ज़्यादा है, इसलिए किसी को चुनना होगा कि क्या जाए और किस order में। वही curator है। आप उसे लिखें या नहीं, curator मौजूद है। Window उसके लिए तीन jobs तय करती है।
Order पहले। Position material की ताक़त बदलती है। एक प्रसिद्ध study में important passage input के शुरू या अंत में हो तो accuracy सबसे अधिक और बीच में हो तो कम थी। इसे "lost in the middle" कहते हैं।1 Study ने 2023 के models मापे थे, इसलिए आज effect कितना है उसे test करें, assume नहीं। Lesson नहीं बदला: attachment के paragraph nine में important constraint दबाना भी आपका decision है।
फिर compression, जो free नहीं है। चालीस pages को चार में summarize करके fit कराया जा सकता है, लेकिन summary ने exception drop कर दिया तो वह बाद में वापस नहीं आता। वह information run से जा चुका है। हर compression यह bet है कि क्या matter नहीं करेगा।
अंत में dropping, और वह policy है। Window भरने पर कुछ तो बाहर जाएगा। Policy आपने set नहीं की तो harness आपके लिए, सबसे ख़राब समय पर, ऐसी rule से करेगा जिसे आपने पढ़ा नहीं।
किसी setup पर यह one-minute test चलाएँ:
Window के किसी document पर इशारा करके बताएं कि किस rule ने उसे वहाँ रखा। Honest answer "retriever ने return किया" है तो आपके पास curator नहीं, search box है। कुछ jobs में यह ठीक और कुछ में dangerous है। Give Your AI Searchable Context retrieval को build करता है। Agentic Coding, Parts 2 से 4, window को हाथ से manage करना सिखाता है।
Context layer टूटी हो तो कैसा दिखता है: answer fluent, confident और factually wrong है। अक्सर वह किसी और चीज़ के बारे में सही होता है: file का old version, अलग customer, आपके case के बजाय documentation example। Confident, wrong और किसी true चीज़ के पास होना इस layer की पहचान जैसा है। अब जानते हैं कि "कुछ और" कहाँ से आया।
खुद देखें (2 minutes)। परिचित document पर एक question दो अलग fresh chats में पूछें। पहली में पूरा document paste करें। दूसरी में केवल पहला third paste करें और वही question पूछें।
यह document है। केवल मेरे दिए हुए text के आधार पर बताएं कि [last third वाली चीज़] के बारे में इसमें क्या लिखा है?
दूसरी chat आम तौर पर "पता नहीं" कहने के बजाय confident answer देगी। यह model का bad behavior नहीं है। Window के hole को training knowledge भर रही है। आपने prompt का एक word बदले बिना answer बदल दिया।
Concept 5: Harness, unit है one beat
आप एक instruction देते हैं। Agent तीन files पढ़ता है, command run करता है, error पढ़ता है, edit करता है, फिर command चलाकर quiet हो जाता है। आपने एक बार type किया। लगभग दर्जन भर चीज़ें हुईं। यह पूरा stretch one beat है और harness उसे चलाने वाला code है।
Job list छोटी और ordinary है। Context assemble करें। Model call करें। Model जिन tools को माँगे, उन्हें run करें। Results वापस feed करें। Errors handle करें। Beat खत्म होने से पहले जो proof ज़रूरी है उसे enforce करें। Model के रुकने तक फिर करें।
आप पहले से harness इस्तेमाल करते हैं। Claude Code, OpenCode और Cowork में harness है। Permission prompt, startup पर पढ़ी rules file और commit से पहले automatic check, ये सब harness हैं। Harness Engineering inherited default के बजाय इसे purpose से build करना सिखाता है।
एक बात लोगों को surprise करती है और बहुत matter करती है।
Sub-agents tools की तरह call होते हैं और बहुत बड़ी चीज़ की तरह behave करते हैं। ज़्यादातर systems में sub-agent tool call से शुरू होता है, इसलिए difference छूट जाता है। Tool call result लेकर लौटता है: file contents, API response या error। Sub-agent अपनी window खोलता है और अपना beat चलाता है। Tool-shaped opening से इस पूरे stack की nested copy का output लौटता है।
इसका real benefit है। Sub-agent चालीस documents पढ़ सकता है, वे आपकी window में नहीं आते और आपको तीन paragraphs मिलते हैं। Real cost भी है: वापस summary आती है, full confidence के साथ, उसमें वे हिस्से भी जिनमें sub-agent ग़लत था। आपने चालीस documents नहीं देखे। Downstream भी नहीं देखेगा। Summary का confidence उसकी reading quality नहीं बताता।
Concept 6: Harness को define करने वाली limit
यह course का turning point है। पहले description था, आगे consequence है।
Beat कई कारणों से end हो सकता है। Timeout, token ceiling, error, denied permission या model का "done"। इनमें से कोई work success prove नहीं करता। वे केवल बताते हैं कि beat ended।
अच्छा harness beat के अंदर real checks enforce कर सकता है। Edit के बाद test suite run करना, schema validate करना या output को known total से compare करना। Command success के बिना finish refuse कर सकता है। यह model की opinion नहीं, verification है और जहाँ हो सके build करना चाहिए।
लेकिन boundary important है:
Beat prove कर सकता है कि specific check pass हुआ। वह तय नहीं कर सकता कि वह check पर्याप्त था।
Passing test केवल test का pass होना prove करता है। यह नहीं कि test ने important case cover किया या chosen test ने पूरा task define किया। Run शुरू होने से पहले किसी को "finished" define करना होगा।
Bank-reconciliation agent सोचें। वह चालीस matches propose करके statement balanced बताता है, पर दोनों totals compare नहीं करता। Context ठीक था, tools चले और error नहीं आया। Internal signals healthy हैं। Claim फिर भी false है।
Beat का checker इसे तभी पकड़ता जब किसी ने पहले totals match होना required किया होता। वही requirement important है। Maker अपनी finish line बनाकर खुद certify नहीं कर सकता कि उसने उसे cross किया।
Prompt में "अपना काम verify करें" लिखना solve नहीं करता। Model "verified" उतनी आसानी से लिख सकता है जितनी "done"। Success की final definition judged work के बाहर से आनी चाहिए। इसलिए वह अगली outer layer में है।
Concept 7: Loop, unit है पूरा run
Loop वह देता है जो एक beat खुद को नहीं दे सकता।
Heartbeat हर beat शुरू करता है: schedule, event या condition जो किसी बात के true होने तक fire करता है। इसके बिना heartbeat आप हैं। Type करना बंद, work बंद।
Spine model के बाहर state रखता है, ताकि अगला beat पिछले का work जाने। यह हर beat के बाद rewrite होने वाली एक file जितना simple हो सकता है:
run: nightly reconciliation, 2026-03-14
done: pulled 412 payments and 388 open invoices
in progress: matching pass 3 of 5, 341 matched so far
needs a person: invoice 4471, two candidates both at 0.52
budget: 3 beats used of 12
File में clever कुछ नहीं, इसलिए यह काम करती है। अगला beat acting से पहले इसे पढ़ता है और फिर से शुरू होने के बजाय pass 3 से resume करता है। चौथी line वह decision रखती है जो agent नहीं कर सका। Concept 8 उसे human gate बनाता है।
Outside stops तय करते हैं कि पूरा run जारी रहे या नहीं:
- पहले चुनी और command से prove की गई success condition। Criterion maker के बाहर से आता है।
- Beats, spending और elapsed time की limits। Next attempt कितना promising है, ceiling को फ़र्क नहीं पड़ता।
- No-progress check। Meaningful change के बिना repeated attempts पहचानता है।
- अलग checker। Work judge करने वाले component ने work बनाया नहीं।
इनमें से कोई maker से नहीं पूछता कि वह finished है या नहीं। हर stop maker की judgment के बाहर established fact पर टिका है। यही maker-checker rule एक sentence में है।
Opening failure पर लौटें: चालीस minutes, पचास dollars और वही तीन attempts। Missing part no-progress check था, बेहतर prompt नहीं। Prompt rewrite हर attempt के words बदल सकता था, run को stuck होना नहीं सिखा सकता था।
Loop Engineering heartbeat, spine, stops, checker और gate बनाता है। Trusting the Checker पूछता है कि checker खुद trust के लायक है या नहीं।
Concept 8: Human gate exit है, stop नहीं
Run से निकलने का एक और रास्ता है, और वह ऊपर के चारों से अलग है।
Stops run को safely fail कराते हैं। Gate run को help के साथ succeed कराता है।
यह इसलिए matter करता है क्योंकि एक idea कहना आसान और पकड़े रखना कठिन है: ambiguity error नहीं है।
Genuinely two-sided decision मिलने पर agent malfunction नहीं हुआ। Invoice 4471 दो payments से match करता है और दोनों 0.52 हैं। यह matcher का bug नहीं, data है। Gate के बिना agent के दो bad options हैं: fail करके नौ passes का legitimate work फेंकना, या guess करना।
Guess dangerous है। Crash loud है। Guess silent है और correct answer जैसा ही दिखता है: same format, confidence और report position। Downstream कोई difference नहीं जानता। Failed run fix होता है। Guessed run spreadsheet में quietly wrong number बनता है।
Gate advance में लिखा जाता है, moment में decide नहीं। Triggers picture की बाईं तरफ हैं: set line से कम confidence, set limit से अधिक value, या undo में कठिन action। Gate fire होने पर case named person को जाता है। Accounts payable की Ayesha invoice 4471 और दोनों candidate payments देखकर बीस seconds में सही चुनती है, क्योंकि उसे March में customer का दो बार pay करना याद है।
उसका answer run खत्म नहीं करता। वह new evidence की तरह re-enter होता है और run pause वाली जगह से आगे चलता है।
Part 3: Map का use
Concept 9: कौन-सी layer टूटी?
Map का लाभ यह है कि हर layer recognizable ढंग से fail होती है, इसलिए symptom surface की ओर इशारा करता है।
| जो दिखता है | पहले कहाँ देखें | क्या बदलें |
|---|---|---|
| Output shape या tone ग़लत है, लेकिन task समझा गया | Prompt | सबसे weak ingredient: examples, instructions या output shape |
| Answer confident, fluent और factually wrong है | Context | Curator: क्या गया, किस order में गया, क्या drop हुआ |
| Success report हुआ लेकिन demonstrate नहीं हुआ, या failed tool call unnoticed रहा | Harness | Tools, error handling और beat को क्या prove करना है |
| Wrong answers बिना check के person या system तक गए | Loop | Checker, criteria किसने चुना और क्या उसने कभी कुछ fail किया |
| कभी stop नहीं, बहुत जल्दी stop, या पूछने के बजाय guess | Loop | Stops और gate |
इस table पर दो honest notes।
यह search order है, verdict नहीं। Failures boundaries cross करती हैं। हर row को "पहले यहाँ देखें" पढ़ें, "blame यहाँ है" नहीं। Genuinely unclear cases Concept 12 में हैं।
यह table जिस habit को तोड़ती है। Teams predictable कारण से ग़लत layer पर debug करती हैं। Agent पचास dollars दोहराने में खर्च करता है और response system prompt rewrite करना है। Prompt ठीक था; no-progress check नहीं था। लेकिन prompt दस seconds में edit होता है, इसलिए pressure में लोग broken layer के बजाय easy layer चुनते हैं। कुछ छूने से पहले layer का नाम loud बोलना पूरी discipline है। पाँच seconds लगते हैं और एक fix को छह fixes से अलग करते हैं।
Concept 10: आप किन layers को own करते हैं?
हर project में चारों build नहीं होते। अक्सर तीन rent किए होते हैं। कौन-सी कौन है, यह जानना तय करता है कि कौन-सी advice लागू भी होती है।
| Layer | Mode 1: general agent से problem solve करना | Mode 2: worker manufacture करना |
|---|---|---|
| Prompt | अधिकतर आपका। Platform अपने system instructions और tool descriptions own करता है। | आपका, एक बार लिखा और reused। |
| Context | Partly आपका: क्या attach करें, कब clear करें। Compaction और retrieval harness के हैं। | आपका। Curator आप लिखते हैं। |
| Harness | Rented, tools, skills, hooks और project instructions से कुछ configure हो सकता है। | आपका। |
| Loop | Mostly rented। Platform loop set करता है, caps और approvals expose कर सकता है। | आपका। हर stop आपने लिखा। |
Mode 1 में "no-progress check जोड़ें" actionable instruction नहीं है; उसके लिए file नहीं है। Outer layers पर job अलग है: rented behaviour जानें। Harness window कहाँ compact करता और क्या फेंकता है? क्या silently retry करता है? Task के बीच room खत्म हो तो क्या होता है? ये product के answerable questions हैं और answers आपके work को बदलते हैं।
Mode 2 में चारों आपके हैं और beats कोई और cap नहीं करेगा।
Mode 1 में यह page पढ़कर कहना, "मैं यह सब already करता हूँ क्योंकि मेरा tool यह सब करता है।"
Tool यह अपने work के लिए करता है। जो worker आप build करेंगे, उसके लिए कोई tool यह नहीं कर रहा। Claude Code अपने beats cap करता है, आपके लिखे loop को नहीं। इसी gap में demo production incident बनता है।
क्या rent किया, पता करें (4 minutes)। अपना सबसे-used agent चुनें। देखने से पहले इन सवालों के guesses लिखें। Guess और real answer की दूरी वही trust है जिसे आप जानते नहीं थे।
- Window भरने पर harness क्या हटाता है, और क्या बताता है?
- Tool call fail होने पर retry करता है? कितनी बार? क्या आपको दिखता है?
- Task के बीच run limit पर पहुँच जाए तो done work का क्या होता है?
अब answers खोजें। Documentation कुछ बताती है। पहला सवाल test भी कर सकते हैं। Long session चलाएँ, शुरू में तीन decisions agree करें, compaction तक काम करें, फिर agent से वे decisions restate कराएँ। जो restate न हो, harness ने उसे unnecessary माना।
Answers team-readable जगह लिखें। Mode 1 में वही छोटा document आपका context और loop work है। यह job का छोटा version नहीं, अलग job है।
Concept 11: Graphs कहाँ fit होते हैं
Graph engineering की बहुत चर्चा है, लेकिन graph fifth layer नहीं है।
चार layers एक execution path बताती हैं: एक message, एक window, एक beat, एक run। Graph topology बताता है: आगे क्या चले, हर edge पर क्या move हो और कौन किसे check करे।
चार layers बताती हैं कि एक node के अंदर क्या होता है। Graph बताता है कि nodes के बीच क्या होता है।
Node agent होना ज़रूरी नहीं। वह function, rule, tool call, human gate, measurement, one beat, whole loop या full agent हो सकता है। Multi-agent system graph का केवल एक type है।
यह किताब "graph" के तीन uses अलग करती है:
- Execution graph तय करता है कि आगे क्या चले और steps के बीच कौन-सा state जाए।
- Memory graph entities, findings और sources को later runs के लिए रखता है।
- Governance graph record करता है कि कौन-से components दूसरों को feed, check, approve और constrain करते हैं।
ये labels इस किताब का map हैं, standard industry vocabulary नहीं।
एक real graph, छह nodes, एक agent।
Concept 8 का nightly accounts-payable pipeline लें:
- Pull। Function payments और open invoices पढ़कर common format में डालता है। Model नहीं है।
- Route। Fixed rule पाँच लाख रुपये से अधिक invoices को confidence से अलग human approval में भेजती है।
- Match। Full agent चारों layers use करके matches और confidence scores propose करता है।
- Gate। Ayesha low-confidence या high-value cases decide करती है। Answer Match में new evidence की तरह लौटता है।
- Prove। Function matched total को statement total से compare करता है। Mismatch pipeline रोकता है।
- Post। Function accepted matches लिखता और unresolved cases review में भेजता है।
दो conditions work को Gate में भेजती हैं और उसका decision Match में लौटता है। हर edge अपने payload का नाम देता है।
केवल Match agent है। दूसरे nodes deterministic code, rule, person और measurement हैं। Graph अलग kinds को same pretend किए बिना coordinate करता है।
Match के अंदर course की पहली तस्वीर दिखती है: loop, harness, context, prompt। Concepts 1 से 8 का सब कुछ उस node में होता है। Graph का सवाल है कि उसके पहले और बाद क्या हो।
Prove node में Concept 6 का missing check है। वह Match के बाहर है, Match उसे skip नहीं कर सकता और उसे केवल needed values मिलती हैं। यही governance design है: matches बनाने वाला node judging measurement को overrule नहीं कर सकता।
Edges nodes जितने important हैं। Pull normalized records भेजता है। Match proposed matches और confidence scores लौटाता है। Gate एक human decision लौटाता है। Graph difficult हो तो unclear edge contracts अक्सर कारण हैं।
Token cost भी अधिकतर Match के अंदर है। बाकी पाँच nodes agent के मुकाबले लगभग free हैं। "हमने graph बनाया" cost के बारे में कम बताता है। Agentic nodes गिनें, frequency देखें और measure करें।
इसलिए केवल एक node model call करता हो तो six-node graph single agentic workflow से सस्ता हो सकता है। Boxes की संख्या cost model नहीं है; उनमें adaptive work है।
दो cautions। June 2025 में Anthropic ने single-agent research system के लिए chat से लगभग चार गुना और multi-agent system के लिए लगभग पंद्रह गुना tokens report किए।2 ये एक system के dated measurements हैं, constants नहीं। Agent-heavy graphs को cost earn करनी चाहिए।
Anthropic ने यह भी कहा कि workers को same context चाहिए या वे एक-दूसरे पर heavily depend हों तो multi-agent designs poor fit हैं।3 Coding tools बदल चुके हैं, underlying constraint नहीं। Shared context और intermediate results जितने tight, parallel agents उतना कम gain देते हैं।
Graph Engineering इसे build करता है और बताता है कि कब build नहीं करना।
Concept 12: जब framework आपसे लड़ता है
जिस map से कभी argue न करें, वह map नहीं ritual है। इसलिए uncomfortable cases देखें।
कुछ failures सच में two-layer हैं। Oldest turns silently drop करने वाली policy context decision है, पर trouble इसलिए भी हो सकती है कि loop run को window भरने जितना long होने देता है। कौन टूटा? दोनों। Cheaper fix किस पर है, यह आपके system पर निर्भर है।
कुछ diagnosis एक layer दिखाते हैं और fix दूसरी पर रखते हैं। Agent ने success report किया लेकिन demonstrate नहीं किया, diagnosis layer 3 है क्योंकि यह beat की self-knowledge की limit है। Fix अक्सर layer 4 है क्योंकि outside-chosen success criterion claim को trustworthy बनाता है। Framework ने अपना काम तब किया जब symptom वाली जगह से अलग fix दिखाया।
कुछ failures चारों में से कोई नहीं हैं। Model task को needed quality पर कर ही नहीं सकता और containers capability पैदा नहीं करते। Layers guessing रोकती हैं, weak model को strong नहीं बनातीं। चारों clear हों और work bad रहे तो बेहतर model, छोटा task या अलग approach चुनें। Trusting the Checker पता लगाने में मदद करता है।
हर project को चारों नहीं चाहिए। One-off task के लिए loop बनाना waste हो सकता है। Layers बताती हैं कि क्या exists करता है; हर layer build करना compulsory नहीं करतीं।
Part 4: Practice
Drill: layer का नाम लें
आठ failures हैं। हर एक के लिए वह layer लिखें जहाँ पहले देखेंगे और एक change लिखें। Key खोलने से पहले answer दें। Answer recognize करना, उसे produce करने से आसान है; skill केवल दूसरा है।
1. आपने five named columns वाली table में competitor summary माँगी। तीन excellent prose paragraphs आए। Content accurate है।
Answer
Prompt। Model ने task समझा और work किया; केवल shape ग़लत है। Fix desired table का example है, table क्यों चाहिए उसकी longer explanation नहीं। Signature है: right work, wrong container।
2. Agent confidently कहता है pricing tier 5,000 requests पर cap है। Pricing page 50,000 कहता है। Agent ने page पढ़ा।
Answer
Context। Window में supposedly मौजूद document के बारे में confident, fluent और wrong answer लगभग signature है। कुछ compress, truncate या old copy से replace हुआ। Curator test चलाएँ: page किस rule से window में आया और क्या पूरा आया?
3. Overnight run कहता है "all tests passing, changes committed." सुबह test suite कभी run नहीं हुई और build red है।
Answer
Diagnosis के लिए harness, fix के लिए loop। Harness में hook suite run करे और उसके बिना beat end न हो। लेकिन इससे केवल suite run होना prove है; run ने खुद suite को सही bar चुना। Trustworthy version outside stop है: advance में चुनी success condition, maker के अलावा किसी से enforced। Prompt में "tests हमेशा run करें" जोड़ना Concept 6 miss करता है।
4. Run एक afternoon में पूरा budget खर्च करता है। Log में वही तीन approaches थोड़े अलग words के साथ repeat हैं।
Answer
Loop। No-progress check और शायद spending limit missing है। यही opening story है। Prompt tempting जगह है और वह आपका afternoon भी waste करेगा।
5. Invoice agent ने रात में 300 invoices process करके 300 matched बताए। Sample में कुछ cases में दो payments equally plausible थे और उसने silently एक चुन लिया।
Answer
Loop, खासकर missing gate। कुछ malfunction नहीं हुआ। Genuinely ambiguous decision पर options guess या fail थे। Advance trigger लिखें और low-confidence/high-value cases person को route करें।
6. Sub-agent ने चालीस support tickets पढ़कर clean three-paragraph summary दी। दो claims wrong हैं।
Answer
Harness। Sub-agent tool call से आता है पर nested stack चलाता है, इसलिए summary full confidence से आती है। Check हो सकने वाले quotes, ticket IDs और receipts माँगें, ऐसी conclusions नहीं जिन पर blind trust हो।
7. Long session बीस turns तक ठीक चलता है। फिर agent early agreed decision से contradict करता है, जैसे वह हुआ ही नहीं।
Answer
Context। Window भरी और कुछ बाहर गया। Dropping policy harness ने set की और सबसे needed item drop हुआ। Decision को conversation के बाहर rules file, spec या फिर attach होने वाली note में durable बनाएँ।
8. Hard research task पर चारों layers clear हैं। Precise prompt, सही window, verified harness, proper stops और checks। Output फिर भी mediocre है।
Answer
इनमें से कोई नहीं। Layers break locations बताती हैं, capability नहीं बनातीं। Honest moves: stronger model, छोटा और sharper task, अलग approach या person की ज़रूरत accept करना। जो framework कभी wrong न हो वह help नहीं कर रहा।
अब अपने failure पर करें
ऊपर का drill calibration है। अब map को real failure पर transfer करें।
अपने पिछले wrong या expensive agent output को सोचें। Order में answer दें:
- कौन-सी unit of work ग़लत हुई? One model call, window, one beat या पूरा run?
- बाद में मैंने क्या बदला? क्या वही layer थी?
- क्या इसे पकड़ता? Mechanism, layer और criterion चुनने वाला व्यक्ति बताएं।
एक example:
Failure। Legal operations team agent से हर auto-renew supplier contract खोजने को कहती है। वह 40 reviewed और 3 renewals report करता है। दो months बाद 3 और contracts renew होते हैं क्योंकि उनमें "evergreen term" लिखा था।
1. कौन-सी unit fail हुई?
Report shape सही और 40 contracts available थे। Missing piece "reviewed" का meaning था। Run ने success को एक phrase पाने की तरह define कर खुद को judge किया। पूरा run fail हुआ।
2. Team ने क्या बदला?
Prompt में और phrases जोड़े: evergreen, rolling term, self-renewing। इससे known examples fix होते हैं, अगली unfamiliar wording नहीं। Failure layer 4 का था, change layer 1 पर।
3. क्या पकड़ता?
Run से पहले legal operations lead की chosen success condition:
- हर contract quoted renewal clause और page number लौटाए; या
- no renewal clause found लौटाकर person को जाए।
Command check कर सकती है कि 40 contracts से 40 complete results आए और blank कोई नहीं। Rule legal lead ने चुनी और agent उसे weak नहीं कर सकता।
Missing contracts silent success के बजाय visible questions होते। Prompt improve करना पड़ सकता था, लेकिन loop अगले unfamiliar phrase को complete certify करने के बजाय expose करता।
Useful skill तुरंत right layer बताना नहीं, tempting answer test करना और easiest layer पर रुकने से इंकार करना है।
यह prompt अपना case diagnose करने में मदद कर सकता है:
मेरा हाल का agent failure यह है: [क्या माँगा, क्या मिला और ग़लत होने का पता कैसे चला]। मैं चार layers में broken layer ढूँढ़ रहा हूँ: prompt (one model call), context window (model क्या देख सकता था), harness (one beat, tools चलाने और beat over तय करने वाला code), या loop (पूरा run: start, stop और check)। Narrow करने के लिए ज़रूरी सवाल पूछें, best guess और earlier catch करने वाला mechanism बताएं। अगर मैंने wrong layer चुनी है तो push back करें।
Drill cases की signatures clean थीं। Real failures नहीं होंगी। एक real case work करना आठ answers recognize करने से ज़्यादा सिखाता है।
यहाँ से क्या लेकर जाएँ
हर concept की एक line, फिर main sentence।
- Concept 1। चार nested containers, ladder के steps नहीं। हर beat अब भी prompt बनाता है।
- Concept 2। Unit of work layer define करती है: one model call, window, one beat, whole run। Vocabulary बदलने पर भी यही सवाल रहता है।
- Concept 3। Prompt one model call है। सबसे weak ingredient fix करें, पाँचों नहीं। Easy edit होने के कारण दूसरे bugs का blame इसे मिलता है।
- Concept 4। Window model के facts हैं और training knowledge holes भरती है। Curator हमेशा है: order, compress और drop करता है। हर document को रखने वाली rule बताएं।
- Concept 5। Beat एक instruction से agent के quiet होने तक सब है। Sub-agents tool call से आते, nested stack चलाते और unearned confidence लौटाते हैं।
- Concept 6। Beat specific check pass prove कर सकता है; यह नहीं कि वह enough था। Maker finished का criterion judge नहीं कर सकता।
- Concept 7। Loop heartbeat, spine और चार outside stops देता है; कोई maker को success define नहीं करने देता।
- Concept 8। Human gate exit है, stop नहीं। Ambiguity error नहीं; guess crash से dangerous है क्योंकि answer जैसा दिखता है।
- Concept 9। Layers recognizable ढंग से fail करती हैं। Fix से पहले layer का नाम लें।
- Concept 10। Mode 1 में आप तीन layers rent और एक configure करते हैं। Mode 2 में चारों आपकी हैं। "Tool यह करता है" आपके worker के बारे में नहीं है।
- Concept 11। Graph fifth layer नहीं। Layers node के अंदर और graph nodes के बीच की topology बताता है। Nodes सभी agents नहीं और token multipliers measure करने चाहिए।
- Concept 12। Map search order है, proof नहीं। Failures cross कर सकती हैं, model itself हो सकता है और हर project को चारों नहीं चाहिए।
और केवल यह sentence याद रखने लायक है:
Bad context के अंदर अच्छा prompt fail होता है। Bare harness के अंदर अच्छा context fail होता है। Loop के बिना अच्छा harness idle रहता है। इसलिए कुछ टूटे तो fix से पहले layer का नाम लें।
Demo में चलने वाला agent production में इसलिए fail होता है। Demo को inner layers चाहिए थीं; outer बनी ही नहीं थीं। Problem model नहीं, उसके चारों ओर की missing layers थीं।
आगे कहाँ जाएँ
Map मिल गया। Section का बाकी हिस्सा territory है और हर course एक layer own करता है:
- Harness Engineering layer 3 बनाता है, जहाँ request enforced rule बनती है।
- Loop Engineering layer 4 बनाता है: heartbeats, spine, maker-checker और human gate।
- Trusting the Checker layer 4 का अगला सवाल पूछता है: checker अच्छा है या नहीं।
- Graph Engineering one execution path के बाद की topology है और पिछले दोनों assume करता है।
- Leaving the Laptop section close करता है: trusted loop कहाँ live करे?
Layers 1 और 2 के पीछे homes हैं: prompt के लिए AI Prompting in 2026, और window के लिए Agentic Coding, Parts 2 से 4।
असल में काम करने वाले agents clever prompts लिखने वालों ने नहीं बनाए। वे उन लोगों ने बनाए जिनके loops जानते हैं कि कब stop और कब ask करना है।