Laptop से आगे: runtime crash course

12 concepts · ढक्कन बंद होते ही रुकने वाले loop से अपने घर वाले worker तक

आपका system तैयार है, लेकिन फँसा हुआ है। आपने जो loop design किया था, वह हर सुबह 9 बजे run होता है। Harness खतरनाक actions को रोकता है। Eval suite reviewer को ऐसा number देती है जिसे आप defend कर सकते हैं। आपने सब कुछ सही किया, फिर भी laptop बंद करते, Wi-Fi खोते या flight में बैठते ही पूरा system रुक जाता है। आपने अब तक जो सबसे भरोसेमंद worker बनाया है, उसका एक single point of failure बचा है: आपकी मेज़ पर रखी machine।

यह course section के आख़िरी खुले सवाल का जवाब देता है: runtime decision। सवाल यह नहीं है कि agent क्या करता है; तीन courses इसे तय कर चुके हैं। सवाल है कि वह कहाँ रहता है और कौन उसे चालू रखता है: व्यवहार नहीं, जगह और देखभाल करने वाला। यह infrastructure detail जैसा लगता है, लेकिन है नहीं। यही तय करता है कि आप एक बहुत अच्छे tool वाले operator हैं या ऐसे worker के owner जो आपके न आने पर भी काम पर आता है। Company scale पर पहला Digital FTE बनाते समय आप यही सवाल फिर पूछेंगे। इसे अभी उस scale पर सीखें जहाँ सारे parts साफ़ दिखाई देते हैं।

शुरू करने से पहले एक वादा: यह course आपको DevOps engineer नहीं बनाएगा। हर move उन चीज़ों का उपयोग करता है जो आपके पास पहले से हैं: agentic coding course की config files, evals course के headless commands, loop course के schedules और वह suite जो साबित करती है कि move काम कर गया। सिर्फ़ एक चीज़ सच में नई है: ऐसा runtime जिसे कोई दूसरा आपके लिए operate करता है। उसे उसकी price और trade-offs के साथ साफ़-साफ़ पेश किया गया है।

पहले Checker पर भरोसा पूरा करें। उस course ने आपको eval suite दी, और यह course उस पर बहुत निर्भर है: नए runtime पर move ऐसा change है जिसके बाद भरोसा करने से पहले suite फिर run करनी होगी। यह पूरी Stage 3 trilogy मानकर चलता है: Loop Engineering (beats, spine, human gate), Harness Engineering (five verbs, ratchet) और evals course (golden set, baselines, drift)। अगर ये शब्द नए हैं, पहले वे courses पूरा करें। यह course उनकी बनाई machinery को move करता है।

यहाँ नए हैं? जो पहले से पता होना चाहिए उसका 2-minute recap

• Beat: scheduled loop का एक पूरा run। Morning-triage loop हर weekday एक beat चलाता है।
• Harness: वह layer जो तय करती है कि agent क्या कर सकता है, उसे क्या पता होना चाहिए, उसके काम का proof कैसे बने और गड़बड़ी पर क्या हो।
• Golden set: असली पकड़ी गई failures से बने eval cases का folder, जो हर change पर फिर run होता है।
• Baseline: दर्ज pass rate जिससे नए runs compare होते हैं। Baseline से गिरना alarm है।
• Drift: आपके change के बिना behavior बदलना, अक्सर नीचे का model update होने के कारण।
• Human gate: risky या failed work किसी व्यक्ति के पास जाता है। Unattended काम main तक नहीं पहुँचता।
• Headless mode: interactive session के बिना agent चलाना (Claude Code में claude -p, OpenCode में opencode run), ताकि script या schedule उसे drive कर सके।

अगर इनमें से कुछ नया है, पहले Stage 3 के तीन courses पढ़ें। यह course उसी machinery को दूसरी जगह रखता है जिसे वे courses बना और prove कर चुके हैं।

आसान भाषा में मुख्य शब्द

Term	आसान मतलब
Runtime	वह computer और उसके आसपास का software जो agent को सच में execute करता है: start करता है, input देता है, crash पर restart करता है।
Home	Runtime choice के लिए इस course का शब्द: आपका session, cloud schedule, managed runtime या अपना process।
Control plane	Runtime का वह आधा हिस्सा जो agent loop operate करता है: sessions, scheduling, event streams और restarts।
Execution plane	वह आधा हिस्सा जहाँ काम होता है: tools का sandbox और उनका छुआ data। दोनों planes के अलग owners हो सकते हैं।
Custody	Data किसके पास और control में है: वह किसकी machines पर रहता है और कौन उसे access कर सकता है।
Headless	बिना interactive session के command से agent चलाना। हर move इसी bridge से जाता है।
Schedule	आपकी जगह तय समय पर loop start करने वाली चीज़: Claude Code Routine, Cowork Scheduled Task या scheduled GitHub Actions job।
Managed runtime	ऐसा service जहाँ आप agent definition भेजते हैं और vendor control plane तथा default रूप से sandbox भी operate करता है।
Agent definition	Agent को run किए बिना उसका पूरा वर्णन: model, system prompt, tools, rules और guardrails।
Hosted session	Managed runtime के अंदर जारी रहने वाला एक काम, जिसका अपना saved state और event log हो।
Sandbox	अलग किया गया environment जहाँ agent के actions execute होते हैं। कुछ homes में model के पास, कुछ में उससे अलग।
Portability	दूसरे home में move करने पर system का कितना हिस्सा बिना rebuild हुए बचता है।
Lock-in	Home छोड़ने का cost, उन सभी चीज़ों से मापा जाता है जिन्हें rebuild करना होगा। कम portability यानी अधिक lock-in।
Blast radius	किसी home में खराब रात कहाँ तक असर कर सकती है। Harness course का budgeting सवाल, runtimes पर लागू।
Pager	रात में system टूटने पर engineer को जगाने वाला alarm। "Pager उठाना" उस system की ज़िम्मेदारी लेना है।
Re-baseline	नया home मौजूदा acceptance bars pass करे, फिर runtime-specific pass rate दर्ज करना और तुलना के लिए पुराना baseline बचाना।
Probation	Trial period: पूरी तरह भरोसा करने से पहले नए home पर नज़दीकी नज़र और पुराने home को उपलब्ध रखना।

यह idea कहाँ से आया

Industry के ज़्यादातर इतिहास में "deployment" developer का शब्द था: code लिखें, फिर servers पर ship करें। 2025 और 2026 में operators के पास अचानक deploy करने लायक चीज़ आ गई। Operators वे लोग हैं जिन्होंने agent लिखा नहीं, सिर्फ़ configure और prove किया। Measured track record वाला configured loop asset है, और laptop खुला रहने पर ही मौजूद asset खराब तरीके से रखा गया asset है। Vendors ने इसे पहचाना। Anthropic ने consumer tools के लिए cloud execution और फिर agent definitions के लिए hosted runtime launch किया। Open-source side ने कम-cost alternative के रूप में CI schedulers अपनाए। इसलिए runtime decision, जो पहले project के आख़िर में सिर्फ़ engineers पूछते थे, अब पहले आता है और उन लोगों तक पहुँचता है जो कभी server नहीं लिखेंगे। यह course उनके लिए है। (Sources आख़िर में हैं।)

एक picture में mindset shift

पूरी trilogy की तरह यह course दोनों tools साथ सिखाता है। Judgment एक जैसा है: कौन-सा home, move कब, और move को prove कैसे करें। Mechanics पहले के किसी course से अधिक अलग हैं, और कारण सीधा है: एक tool का vendor उसके लिए cloud operate करता है, दूसरे tool का "vendor" आप हैं। यह asymmetry footnote नहीं, runtime decision का हिस्सा है।

caution

यह mid-July 2026 तक सही है। इस course की mechanical layer में product names, endpoints, prices और flags इस section के बाकी courses से तेज़ बदलते हैं। Move से पहले claude update या opencode upgrade run करें और किसी name या number पर भरोसा करने से पहले live docs (code.claude.com/docs, docs.claude.com, opencode.ai/docs) check करें।

इस course में क्या है

Part	Topic	आप क्या सीखेंगे
1	आख़िरी dependency	Laptop पर proven loop खराब रखा asset क्यों है, और options sort करने वाला एक सवाल
2	Headless bridge है	हर home का shared invocation और पहला move: cloud schedule
3	Managed runtime	Agent definitions, environments और sessions: आप क्या देते हैं, क्या मिलता है, cost क्या है
4	असल move	क्या travel करता है, क्या rebuild होता है, और track record नए home में फिर क्यों कमाना पड़ता है
5	Home चुनना	चार सवाल, जानबूझकर homes mix करना और शुरू से अंत तक एक पूरा move
6	ईमानदार रहना	Lock-in, ownership drift, home की limits और Mode 2 का bridge
Live	Dogfooding	इस किताब के loops कहाँ रहते हैं और क्यों
Practice	Projects	आसान से मुश्किल 8 moves

करके सीखना चाहते हैं? पूरा move देखने के लिए पहले Part 5 पढ़ें। फिर बाकी parts पर लौटें।

इस course को पढ़ने के दो तरीके

पहली बार? Parts 1 से 5 क्रम में पढ़ें और "Going deeper" वाली हर note छोड़ दें। इसे पढ़ने में लगभग 90 मिनट लगेंगे। फिर Projects 1 से 3 करें; वे अधिक समय लेंगे। उनके बाद आपका loop ऐसे schedule पर चलेगा जिसे laptop की ज़रूरत नहीं, और आप number के साथ बता पाएँगे कि वह अभी भी काम करता है।

दूसरी बार (पहले महीने की unattended nights के बाद): Part 6, deeper notes और Projects 4 से 8। Lock-in तभी पूरी तरह समझ आता है जब आपके पास कुछ ऐसा हो जिसे rebuild करना आपको परेशान करे।

Hindi दूसरी language के रूप में पढ़ रहे हैं? Course के हर picture-word के पास plain version है। "आसान भाषा में" boxes और ऊपर का glossary वही meaning छोटी, सीधी sentences में देते हैं। अगर कोई sentence decorative लगे, पास का box वही बात सरल रूप में कहता है।

क्या याद रखें और क्या lookup करें

दो layers अलग speed से पुरानी होती हैं। पहली याद रखें, दूसरी lookup करें।

• Lasting layer। सवाल है कि loop कौन operate करता है और work कहाँ execute होता है; बाकी details हैं। Headless हर move का bridge है। Discipline travel करती है, mechanics rebuild होती हैं और trust फिर measure होता है। चार सवाल home चुनते हैं, blast radius तय करता है कि move कब हो, और हर home human gate रखता है।
• Mechanical layer। नीचे का हर product name, endpoint, price और flag। यह course लिखते समय managed-runtime APIs कुछ हफ्ते पुरानी हैं। हर detail को live docs का pointer मानें, याद करने वाला fact नहीं।

---

📚 Teaching Aid

पूरा slideshow खोलें

पूरी presentation देखें: Laptop से आगे: runtime crash course

---

Part 1: आख़िरी dependency

1. Laptop पर proven loop खराब रखा हुआ asset है

तीन courses में बनाई चीज़ें गिनें। सुबह बैठने से पहले queue triage करने वाला loop। Dangerous mistakes को impossible बनाने और हर पकड़ी failure को permanent rule में बदलने वाला harness। Center के reviewer को defend करने लायक number देने वाली eval suite। मोटे तौर पर: written job description, supervisor और performance record वाला junior colleague।

अब dependencies गिनें। Laptop खुला हो। Session login हो। Machine सुबह 9 बजे awake, power और network पर हो। इनमें से एक भी छूटा तो beat बिना आवाज़ run नहीं होगी। Loop course ने इसकी cost बताई थी: queue बढ़ती है, escalations जमा होती हैं, और शुक्रवार बंद किए ढक्कन की कीमत सोमवार वाला आप चुकाते हैं।

इसे और साफ़ कहें। Trilogy ने single points of failure एक-एक करके हटाए: maker–checker split ने single unreviewed opinion हटाया, harness ने single unguarded action हटाया और evals ने single unchecked checker हटाया। एक बचा है, और वह आप हैं। आपका judgment नहीं, जिसे human gate सही तौर पर रखता है, बल्कि आपका hardware। System उस machine से अधिक reliable है जिस पर वह चलता है। यही संकेत है कि वह अपने home से बड़ा हो गया है।

आसान भाषा में

आपने अच्छे worker को train किया, फिर शर्त रखी कि वह सिर्फ़ आपके living room में और आपके घर पर रहने पर काम करे। Worker ठीक है; arrangement problem है।

2. एक सवाल हर option sort करता है: loop कौन operate करता है और work कहाँ execute होता है?

नया home खोजते ही options बढ़ते और vocabulary noisy हो जाती है: cloud sessions, hosted agents, managed runtimes, SDKs, serverless और orchestration। एक सवाल से सारी noise काटें। इसके दो हिस्से हैं: agent loop कौन operate करता है, और उसका work कहाँ execute होता है?

इन हिस्सों के नाम अभी सीखना उपयोगी है, क्योंकि modern runtimes इन्हें अलग कर सकते हैं। Control plane खुद loop है: sessions start करना, model को input देना, events stream करना और 3am crash restart करना। Execution plane actions की जगह है: tools का sandbox और उनका data। Laptop पर दोनों planes एक machine हैं, इसलिए अलग करने की ज़रूरत नहीं थी। आगे के homes इन्हें अलग कर सकते हैं, और सबसे interesting home जानबूझकर ऐसा करता है।

हर option इन चार homes में से एक है, दोनों halves के अनुसार sorted:

• Home 1: आपका session। Config, runtime और uptime सब आपका। Trilogy यहाँ हुई और build व proof के लिए यह सही home है। Depend करने के लिए गलत home है।
• Home 2: cloud schedule। Rules file, skills और subagents वाली config अभी भी आपकी है, लेकिन clock किसी और के computer पर चला जाता है। Claude Code Routine Anthropic cloud पर loop चलाती है। Scheduled GitHub Actions job GitHub runners पर OpenCode loop चलाती है। यह सबसे छोटा move और सबसे बड़ा immediate payoff है।
• Home 3: managed runtime। आप agent definition (model, prompt, tools, guardrails) देते हैं और vendor control plane चलाता है: loop, sessions, crash recovery। Execution plane choice है: default में vendor cloud sandbox, custody की माँग पर आपकी infrastructure का sandbox। आप loop operate करना छोड़ते हैं, उसके आसपास business operate करते रहते हैं।
• Home 4: अपना process। Harness आपके लिखे software की library और आपके servers का हिस्सा बनता है। सब आपका, पूरी responsibility भी आपकी। यह Agent SDK और Mode 2 का territory है; course दरवाज़ा दिखाता है, पार नहीं करता।

दो planes को flat करके देखें। Home 3 सच में दो है, इसलिए पाँच rows हैं:

Home	Control plane	Execution plane	टूटने पर कौन जागता है
1 · आपका session	आप	आपका laptop	आप
2 · Cloud schedule	आप, scheduler के ज़रिए	Cloud runner	Shared
3 · Managed, cloud sandbox	Vendor	Vendor	Infrastructure उनकी, outcomes आपके
3 · Managed, self-hosted sandbox	Vendor	आप	Plane के अनुसार split
4 · अपना process	आप	आप	जानबूझकर आपकी

ध्यान दें कि सवाल असल में technical नहीं है। हर business हर function के लिए यही पूछता है: खुद करें या किसी और को pay करें? आप यह सोचना पहले से जानते हैं। बाकी course उसी सोच को agent के नीचे के computer पर लागू करता है।

आसान भाषा में

चुनने के लिए चार homes हैं, चढ़ने की ladder नहीं: laptop (सब own करें), schedule (config own करें), managed runtime (definition own करें और sandbox उनकी cloud या custody के अनुसार आपकी infrastructure पर हो), या अपने servers (product scale पर फिर सब own करें)। Rule है: सिर्फ़ वही own करें जो ज़रूरी है, जो मन करे वह नहीं। ज़्यादातर readers पहले तीन में रहते और अक्सर हर loop के लिए अलग home साथ चलाते हैं। चौथा home Mode 2 की शुरुआत है।

खुद जाँचें

Lahore की Ayesha freelance invoicing loop अपने laptop पर चलाती हैं। Load-shedding से हर शाम power कटती है, और नया client रोज़ local time 6pm पर invoice बिना fail हुए चाहता है। उन्हें पहले कौन-सा home चाहिए, और Home 3 आज उनकी ज़रूरत से अधिक क्यों है?

जवाब देखें

Home 2, cloud schedule। Problem सिर्फ़ clock है: loop proven, config काम करती है, लेकिन machine 6pm promise नहीं कर सकती। Schedule को cloud runner पर move करने से power cut critical path से हटता है। Client के "बिना fail" शब्द पर honesty note: CI समेत अधिकांश schedulers लगभग किसी समय का promise करते हैं, ठीक उसी समय का नहीं। Load पर delay और कभी-कभी scheduled run drop होती है। इसलिए "without fail" scheduler feature नहीं, Part 2 की minimum unattended kit है: missed-run detector, duplicate invoice न भेजने वाला retry, और 6:30 तक success दर्ज न होने पर alarm। Home 3 दूसरे users को serve करने, long jobs का session state रखने और scale operations जैसी problems solve करता है, जो आज नहीं हैं, और उनकी cost लेता है। Part 5 पूछेगा: user कौन है? आज user Ayesha हैं। Home 2 और kit काफ़ी हैं।

---

Part 2: Headless ही bridge है

3. हर home headless भाषा समझता है

इस course की हर move को संभव बनाने वाली शांत-सी बात यह है: evals course में आप यह जाने बिना ही bridge पार कर चुके हैं कि वह bridge था। Eval runner ने claude -p और opencode run के ज़रिए agent को बातचीत की तरह नहीं, एक command की तरह call किया था। कोई खुली window नहीं, संभालने के लिए कोई session नहीं: prompt अंदर जाता है, काम होता है, output बाहर आता है और process समाप्त हो जाती है।

यही headless mode है, और पूरा course इसी idea पर टिका है। जो भी command चला सकता है, वह अब आपका agent चला सकता है। Shell script, cron job, CI runner या cloud scheduler, कोई भी। Home 2 से आगे हर home भीतर से बस इस सवाल का अलग जवाब है: "headless command किसका computer, किसकी clock पर चलाता है?"

Evals course से सीखी mechanics बिना बदले साथ आती है: Claude Code में machine-readable output के लिए --output-format json, OpenCode में JSON event stream और reviewer का verdict file में लिखना ताकि किसी को prose parse न करनी पड़े। अब एक habit जोड़ें, क्योंकि कोई human देख नहीं रहा: headless run को failure पर साफ़ और ऊँची alarm देनी चाहिए। Session में error आपको दिखती है। Runner पर ऐसा exit code जिसे कोई check नहीं करता, एक ऐसी beat है जो चुपचाप हुई ही नहीं। यह वही failure है जिसकी Concept 1 ने warning दी थी, बस cloud में फिर से बन गई। इस course का हर headless wrapper exit code check करता है और failure पर loud होता है, यानी ऐसी साफ़ दिखाई देने वाली alarm उठाता है जिसे loop course ने पाँचवाँ verb कहा था। Silence का अर्थ success होना चाहिए। यह rule आपको लागू करना है; default में नहीं मिलता।

आसान भाषा में

Interactive mode में आप agent से बात करते हैं। Headless mode में कोई भी script, schedule या server agent को note देता है और result ले लेता है। Agent note ले सके, तो जहाँ note पहुँच सकता है वहाँ वह काम कर सकता है।

4. Home 2, cloud schedule: सबसे पहले clock बाहर जाती है

पहली move जानबूझकर सबसे छोटी है: आपने जो बनाया है वह सब रखें, सिर्फ़ clock को दूसरी जगह ले जाएँ। आपकी config, यानी rules file, skills, subagents और hooks, बिल्कुल वैसी ही रहती है। सिर्फ़ यह बदलता है कि beat शुरू कौन करता है।

Vendor वाला रास्ता वही schedule है जिसका loop course ने promise किया था, और नाम भी वही रहा: Routine। Claude Code में /schedule command (जिसका alias /routines है) बातचीत के ज़रिए Routine बनाती है। वह prompt, repositories, connectors और environment वाली configuration save करती है। आपका laptop खुला हो या नहीं, वह configuration Anthropic-managed cloud infrastructure पर चलती है। Repo से जुड़ा आपका loop, "हर weekday सुबह 9 बजे morning triage skill चलाएँ और medium risk से ऊपर की हर चीज़ escalate करें," ठीक इसी रूप में बदल जाता है।

Live docs से तीन honesty notes, और तीनों परिचित लगने चाहिए:

• Routines research preview में हैं। यह mechanical layers में सबसे mechanical है, इसलिए depend करने से पहले verify करें।
• Design के कारण scheduled run घंटे के कुछ मिनट बाद शुरू हो सकती है (docs इसे stagger कहती हैं)। असली promise "लगभग 9 बजे" है। हर scheduler के बारे में course का यही point vendor खुद यहाँ कह रहा है।
• Green run status का अर्थ सिर्फ़ यह है कि session infrastructure error के बिना exit हुआ। इसका अर्थ यह नहीं कि आपका task सफल हुआ। Concept 3 का loud-failure rule अब भी आपको prompt और उसके checks के भीतर लागू करना है।

एक trap का नाम दोस्ताना है। Desktop app में Local चुनने से Desktop scheduled task बनती है, जो आपकी machine पर चलती है। यह timer वाला home 1 है, move नहीं।

Claude Cowork में knowledge work के लिए यही idea Scheduled Task है। आप उसे एक बार describe करते हैं और वह connectors, skills और plugins के साथ अपने schedule पर remotely चलती है। जब आप देखें, results आपका इंतज़ार करते हैं। उन्हीं docs की एक caveat है: जिस task को local files या desktop applications चाहिए, वह locally चलती है और आपका laptop फिर चुपचाप ज़रूरी हो जाता है। Loop क्या छूता है, उसके अनुसार चुनें: repository work के लिए Claude Code Routine; connector और document work के लिए Cowork Scheduled Task। दोनों में laptop का बचा हुआ एकमात्र काम results पढ़ने की जगह होना है।

दो honesty notes और, दोनों mechanical layer के हैं। पहला, cloud runner आपकी machine नहीं है। वह किन repos, connectors और credentials तक पहुँच सकता है, यह configure होता है, inherit नहीं। इसलिए पहली Routine run कुछ हद तक यह पता लगाती है कि नया home क्या देख सकता है और क्या नहीं। दूसरा, harness configured रूप में travel करता है, लेकिन आपको verify करना होगा कि उसने सच में किया। जिन permission walls और hooks पर आप depend करते हैं वे files हैं, और files सिर्फ़ उन runs की रक्षा करती हैं जो उन्हें load करें। Routines आपकी config कैसे source करती हैं, इसके लिए live docs देखें और Concept 8 की probation period को non-negotiable मानें।

Repository से जुड़े loops के लिए home 2 का दूसरा, vendor-neutral version भी है, जिसे loop course पहले ही बना चुका है। यह schedule: trigger वाला GitHub Actions workflow है। Repo की config साथ checkout करके यह CI runner पर claude -p को headlessly चलाता है। Home वही, बस दूसरी company से किराये पर। GitHub खुद एक honesty note publish करता है: scheduled workflows best-effort हैं। Load में देर से शुरू हो सकते हैं, कभी-कभी drop हो जाते हैं और सिर्फ़ default branch से चलते हैं। Morning loop का असली contract "लगभग 9 बजे" है। Hard deadline वाली किसी भी चीज़ को नीचे दी minimum unattended kit और शायद अधिक मज़बूत scheduler चाहिए।

OpenCode का अपना first-party hosted control plane नहीं है, और course इसका ढोंग नहीं करता, क्योंकि ईमानदार version अधिक सिखाता है। OpenCode में home 2 वह scheduler है जिसे आप चुनते हैं। Repo से जुड़े loops के लिए loop course वाला GitHub Actions pattern इस्तेमाल करें: opencode run को schedule: trigger पर चलाएँ और अपनी .opencode/ config checkout करें। बाकी हर काम के लिए कोई भी machine इस्तेमाल करें जो cron चला सकती है: पाँच डॉलर का cloud server, घर का always-on computer या कोई scheduled runner।

आपको वही मिलता है जिसका tool ने शुरू से promise किया था: आपके और loop के बीच कोई vendor नहीं, model आपकी पसंद का और provider आपकी पसंद का। आप यह स्वीकार करते हैं कि अब vendor आप हैं: runner की uptime, credentials और updates आपको संभालनी हैं। Actions पर repo loop हो तो यह burden छोटा और अधिकतर GitHub का है। Desk के नीचे छोटा computer हो तो आपने ज़्यादा काम के साथ home 1 फिर बना लिया। इसीलिए इस तरफ course Actions version को default recommendation बनाता है।

दो tabs का अंतर lesson है, defect नहीं: open tool पूरा runtime decision आपके हाथ में देता है और कुछ नहीं छिपाता। यही trade आपको Personal Agent Harnesses section में फिर मिलेगा, जहाँ runtime own करना ही पूरा point है।

आप जो version चुनें, success की definition एक ही और measurable है: laptop बंद रहते कम-से-कम एक पूरा operating cycle और कम-से-कम दस successful beats, जहाँ silence का अर्थ baseline हो। "Cloud से एक बार चल गया" काफ़ी नहीं, क्योंकि evals course ने सिखाया कि एक green run की कीमत क्या है। यह long-term uptime का proof भी नहीं; इसे initial operational evidence कहें और riskier या कम बार चलने वाले loops के लिए period बड़ा रखें। Scheduled beats, हर beat baseline से checked और alarm को जानबूझकर एक बार test किया गया। यही home 2 में सच में move करना है।

Minimum unattended kit। Course ने promise किया था कि आपको DevOps engineer नहीं बनाएगा, और एक पूरी discipline की जगह एक table से promise निभाता है। जब कोई human run नहीं देखता तब ये छह controls optional नहीं हैं। हर control छोटा है और हर एक की अनुपस्थिति के पीछे मशहूर failure story है।

Control	Rule	वह failure जिसे रोकता है
Idempotency	Retried beat को दोहराना safe होना चाहिए	Invoice दो बार भेजना, ticket दो बार file करना
Missed-run detection	दूसरी system notice करे कि पहली शुरू ही नहीं हुई	जो process चली नहीं वह अपनी absence report नहीं कर सकती
Concurrency lock	एक समय में एक beat, ताकि 8am वाली जीवित हो तो 9am वाली wait करे	एक queue की files को दो agents साथ edit करें
Credential discipline	Scoped service credentials, least privilege, rotation, personal login कभी नहीं	Cloud runner के पास आपकी पूरी identity होना
Time semantics	Timezone लिखी हो; daylight-saving और catch-up behavior पहले तय हो	6pm invoice का साल में दो बार एक घंटा खिसकना
Cost and execution limits	हर beat की maximum duration, turns, retries और spend, साथ में termination behavior	भटकती run का रात भर में महीने का budget खर्च करना

यह kit home 2 की entrance fee है, यानी move करने से पहले चुकाई जाने वाली कीमत, और यह travel करती है। आगे हर home यही छह controls माँगता है, कभी आपकी scripts की जगह service settings के रूप में। Part 5 का चौथा सवाल जब speed limit तय करता है, तब "minimum safety gate" से यही table मतलब है।

आसान भाषा में

पहली move सबसे छोटी है। पूरा setup रखें और सिर्फ़ यह बदलें कि loop शुरू कौन करता है। आपके laptop खोलने की जगह cloud का schedule clock पर इसे शुरू करता है। अब कोई देख नहीं रहा, इसलिए छह छोटे safety rules, यानी kit, जोड़ें ताकि failure चुप न रह सके।

और गहराई में: schedule move हुआ, human gate नहीं

Move में एक subtle trap है। Laptop पर human gate की सुविधाजनक बात यह थी कि आप वहाँ मौजूद थे। Loop escalate करता और escalation उसी window में आती जिसे आप देख रहे थे। Home 2 में loop आपके screen के पास होने या न होने से स्वतंत्र चलता है। अब unseen escalations जमा हो सकती हैं, और unseen escalation delayed decision है, जो कभी-कभी default में लिया गया decision बन जाती है। इसलिए home 2 की move ऐसा upgrade मजबूर करती है जिसकी laptop ने माँग नहीं की थी: escalation channel को आपकी desk नहीं, आप तक पहुँचना चाहिए, जैसे message, mention या आपके नाम वाला issue। Loop course के "get loud" verb को ऐसी जगह point करें जहाँ आप सच में रहते हैं। Gate move नहीं हुआ; doorbell को होना पड़ा।

खुद जाँचें

आपकी पहली cloud-scheduled beat green चलती है। Teammate कहता है migration पूरी है। एक run के बारे में evals course की सीख और silence पर इस part की सीख से बताइए: "done" ईमानदार होने से पहले कौन-सी दो चीज़ें अब भी missing हैं?

जवाब देखें

पहला: एक green beat एक run का fact है, home का नहीं। Migration rate से prove होती है, इसलिए success bar पहली रात नहीं, baseline के विरुद्ध पूरा operating cycle और कम-से-कम दस beats है। दूसरा: loud failure test नहीं हुई। जब तक आप एक deliberate failure plant करके alarm को अपने तक पहुँचते नहीं देखते, silence ambiguous है: इसका अर्थ baseline हो सकता है, या runner शुरू ही न हुआ हो और complain करने के लिए कुछ बना ही न हो। Done का अर्थ है: एक week green, alarm tested और escalations ऐसी जगह आ रही हों जिसे आप सच में देखते हैं।

---

Part 3: Managed runtime

5. Home 3: आप definition भेजते हैं, service worker चलाती है

Home 2 ने clock move की। Home 3 control plane को move करता है और execution plane को भी, लेकिन सिर्फ़ तभी जब आप चुनें। Managed runtime एक simple लेकिन radical contract वाली service है: आप अपने agent को describe करते हैं, यानी model, system prompt, tools, connectors और guardrails; service उसे operate करती है। Loop, session state, retries और रात 3 बजे crash recovery: control plane vendor के computers पर उसके engineers चलाते हैं और default में sandbox भी वहीं चलता है। आप agent loop operate करना छोड़ देते हैं। उसके आसपास की हर चीज़ अब भी आपकी है: calling schedule, credentials, event consumption, escalations, spend limits और outcome गलत होने पर incident। Definition के author आप हैं और business system के owner भी।

यह course लिखे जाने के समय concrete example Claude Managed Agents है, जो अप्रैल 2026 में public beta में आया। Details बदलें तब भी इसका shape सीखने लायक है, क्योंकि shape ही idea है। आप तीन चीज़ें बनाते हैं:

• Agent: definition, यानी model, prompt, tools और guardrails। आपकी rules file और reviewer prompt उस form में बदलती हैं जिसे service hold कर सके।
• Environment: दीवारों वाली वह जगह जहाँ agent के actions execute होते हैं। Harness course की fences अब local config file की जगह service-side object बनती हैं। यही execution plane है और इसमें choice है: default में vendor infrastructure पर cloud sandbox, या ऐसे काम के लिए आपकी controlled infrastructure पर self-hosted sandbox जिसका data आपकी custody से बाहर नहीं जाना चाहिए। दोनों में fences आपको set करनी हैं। Vendor की अपनी production guidance least-privilege networking और explicit allowed-hosts list कहती है, जो harness course जैसी ही लगनी चाहिए।
• Session: काम का एक ongoing हिस्सा, जिसका अपना preserved state और append-only event log है। यह loop course की beat है, लेकिन laptop को खुला रहने की ज़रूरत न होने से pause, resume और कई दिन survive कर सकती है।

आपकी application, या इस course के scale पर script, API के ज़रिए इनसे बात करती है और events stream करके वापस लेती है। सबसे महत्वपूर्ण architectural detail यह है कि इस home में Concept 2 के दोनों planes दिखाई देते और अलग किए जा सकते हैं। सोचने वाला model और action लेने वाला sandbox अलग pieces हैं, जिन्हें service जोड़ती है। पहले हर course में आपने coupled version देखा था: agent और उसके tools एक machine की एक process में। Decoupled shape किसी और को acting part scale पर operate करने देता है, और production agent architectures इसी shape की ओर बढ़ रही हैं। यह idea याद रखें: Mode 2 में यही आपकी अपनी design choice बनकर लौटेगा।

दो boundary facts साफ़ कहें, क्योंकि vendors उन्हें धीरे कहते हैं। Managed control plane vendor-specific होता है: यह Claude चलाता है और Anthropic operate करता है। Sandbox आपकी infrastructure पर हो सकता है, लेकिन loop, sessions और model path नहीं। नीचे OpenCode tab open-source side पर इसका ईमानदार अर्थ बताता है। और managed runtime hosting जोड़ा हुआ SDK नहीं है: Agent SDK और Managed Agents अलग products हैं; एक के विरुद्ध लिखा code दूसरे पर deploy नहीं होता। Code साथ नहीं जाता। Part 4 बताएगा कि क्या जाता है।

आपके ownership से service के storage तक translation exercise यह है: loop की job description agent का prompt बनती है। Permission walls और deny rules environment की configuration बनते हैं। हर scheduled beat एक session बनती है जिसे आपकी script headlessly खोलती है, उसी schedule पर जिसे home 2 ने चलाना सिखाया। Endpoints, SDK call shapes और beta headers इस पूरी किताब की सबसे mechanical layer हैं। वे कुछ हफ़्तों पुराने होते हैं और हर महीने बदलते हैं। हर detail docs.claude.com की live docs से लें और एक season से पुराने हर tutorial, इस tutorial समेत, को shape मानें, reference नहीं।

इस तरफ first-party home 3 नहीं है और course नक़ली version नहीं बनाएगा। लेकिन ठीक समझें कि missing क्या है। OpenCode remote पर अच्छी तरह चलता है। opencode serve headless server process देता है। Clients remote instance से attach हो सकते हैं और पूरा setup किसी भी managed compute पर containerize हो सकता है। जो कोई offer नहीं करता वह first-party managed control plane है, यानी vendor का loop, sessions और recovery को service की तरह operate करना। Interchangeable models वाले open tool के पास इसे करने वाला एक vendor नहीं होता। इसलिए यहाँ honest equivalents हैं: hardened home 2, यानी scheduler + kit और vendor की भूमिका में आप; या आपकी लिखी और operate की server process। Serious use में वह server process home 4 का material और Mode 2 का काम है। बदले में यह side वह चीज़ देता है जिसे managed control plane बेच नहीं सकता: आपके और loop के बीच कुछ नहीं। सही trade tool का सवाल नहीं, Part 5 का सवाल है।

आसान भाषा में

Homes 1 और 2 में worker को employ भी आप करते हैं और उसका office भी maintain करते हैं। Home 3 में job description और office rules आप लिखते हैं, जबकि building-services company power, security, night shifts और repairs वाला office चलाती है। आप front door से नहीं, reports के ज़रिए visit करते हैं।

6. आपको क्या मिलता है, क्या छोड़ते हैं और cost क्या है

Managed contract को दोनों तरफ से ईमानदारी से तौलें।

आपको क्या मिलता है। वे operations जो आप कभी नहीं चाहते थे: harness बनाने वालों द्वारा maintained sandboxing; crashes और कई दिन के jobs survive करने वाला session state; और current model ship करने वाले vendor द्वारा tune किया context management और prompt caching। इससे model-runtime compatibility का वह manual work घटता है जिसे harness course ने कराया था। ठीक समझें कि यह क्या खरीदता है: behavioral drift solve नहीं होती। Coordinated model और harness updates regression को attribute करना अधिक कठिन बना सकती हैं, क्योंकि दो चीज़ें साथ बदलीं। Evals course की scheduled baseline run का पूरा काम बना रहता है। Infrastructure pager उनका है, यानी रात में responsible engineer को जगाने वाली alarm। Contract के अनुसार 3am restart आपकी problem नहीं। Business-outcome pager अब भी आपका है: काम गलत हो लेकिन समय पर उनकी machines पर हो, तो escalation आपकी responsibility है।

आप क्या छोड़ते हैं। हल्की से भारी तक तीन चीज़ें। Visibility: आप machine नहीं, service का event log पढ़ते हैं। Depth-3 trace grading, जहाँ answer के साथ agent के steps भी check होते हैं, अब log की contents पर depend करती है। Custody: आपके prompts, fixtures और work inputs ऐसी infrastructure पर execute होते हैं जिसे आप control नहीं करते। कुछ data, professions और regulators के लिए यही एक fact फैसला कर देता है; feature list इसे नहीं बदलती। Portability: definition इस vendor के shapes में लिखी है। जिस दिन निकलेंगे, definition move नहीं, rewrite होगी। Part 6 इसी पर है।

Cost क्या है। Bill का नया प्रकार, जो आज की numbers से अधिक महत्वपूर्ण है। Homes 1 और 2 में tokens और runner की cost आती है। Home 3 runtime itself का meter जोड़ता है, बिजली meter जैसा use counter। अभी active session work का लगभग आठ cents प्रति hour है, idle time free, साथ में tokens और web search जैसे metered extras। Shape से दो consequences निकलते हैं। जो session थोड़ी देर सोचता और लंबे समय सोता है उसे बनाए रखना लगभग free है, और इसी से long-lived sessions affordable बनती हैं। जो loop भटकता है, यानी evals course की depth-3 disease, वह अब time के साथ money भी खर्च करता है। इससे eval suite quality gate के साथ cost control बनती है। Numbers बदलेंगी; live pricing page check करें। Lesson shape है।

आसान भाषा में

Managed runtime एक trade है। Vendor crashes, restarts और sandbox health जैसे unwanted operations संभालता है। बदले में आप कुछ visibility, data custody और आसान portability छोड़ते हैं। Bill का नया प्रकार भी जुड़ता है: runtime के active work-hours का payment, जबकि idle time free है। इसलिए भटकता loop अब time के साथ money भी waste करता है।

और गहराई में: vendor updates एक साथ मदद और नुकसान करती हैं

Evals course में drift story का fixed shape था: unchanged harness के नीचे model बदला और baseline ने tilt पकड़ लिया। Home 3 drift हटाए बिना shape बदलता है। अब model और harness vendor के schedule पर साथ बदलते हैं, उसके engineers साथ tune करते हैं। आम तौर पर इससे hand-tuned config की छोटी problems कम होती हैं, लेकिन कभी जिस behavior पर आप depend करते थे वह आपकी किसी file के बदले बिना बदलता है। Defense बिल्कुल नहीं बदलती, और यही point है: scheduled full-set run, committed baseline और drop पर loud alert। Managed runtime operations burden हटाता है, measurement burden नहीं। इस किताब में कोई चीज़ वह burden नहीं हटाती।

खुद जाँचें

Colleague कहता है: "Managed runtime sessions hour के हिसाब से metered हैं, इसलिए अपने schedule पर loop चलाने से साफ़ तौर पर महँगी हैं।" बताइए यह कौन-सी दो बातें miss करता है: एक meter के बारे में और दूसरी उस चीज़ के बारे में जिसे meter ने replace किया।

जवाब देखें

Meter active runtime गिनता है और idle free है। जो session हर beat में कुछ मिनट काम करके बाकी समय सोता है, runtime line पर लगभग कुछ नहीं जोड़ता। इसलिए "per hour" का अर्थ "exist करने के हर hour" नहीं है। उसने क्या replace किया: home 2 की price कभी सिर्फ़ tokens नहीं थी। वह tokens + runner + आपके hours थी, जिनमें configure, update और failure पर जागना शामिल है। Honest comparison में operator समेत total cost आती है। Hobby loop में home 2 आसानी से जीतता है; team को serve करते दस loops में pager की भी price है। इसी कारण cost Part 5 के decision की चौथी input है, पहली नहीं।

---

Part 4: Move खुद

7. Suitcase test: discipline travel करती है, mechanics नहीं

Homes के बीच हर move को course एक packing question में बदलता है: suitcase में क्या जाता है और पहुँचने पर क्या दोबारा बनता है?

Trilogy ने जो सच में सिखाया, वह सब travel करता है। Spec: job क्या है और "done" का अर्थ क्या है। आपकी मेहनत के anchors वाली rubric। हर case की origin line और साथ में baselines वाला golden set। Ratchet log, यानी पकड़ी गई failures का चलता record जिसमें हर failure permanent test case बनती है। Maker-checker split, category bars, यानी हर तरह के case की minimum pass rate, और human gate। इस list में common बात देखें: इनमें कुछ भी software नहीं है। ये लिखे हुए decisions हैं। इसीलिए travel करते हैं; decision को परवाह नहीं कि कौन-सा computer उसे enforce करता है।

Vendor या machine का नाम लिए हर चीज़ travel नहीं करती। Flags और output formats। File paths। Session state। एक runtime की API के लिए लिखा code। Concept 5 की SDK-versus-managed boundary इस rule का सबसे साफ़ रूप है। Cost assumptions भी नहीं, क्योंकि Concept 6 ने दिखाया कि homes के बीच उनकी size ही नहीं, shape बदलती है।

Lock-in का असली जवाब भी यही है, इसलिए सीधे कहें: आपका portable asset discipline layer है, और उसकी portability आपको maintain करनी है; वह अपने-आप मौजूद property नहीं। Repo के बदले सिर्फ़ vendor-side setting में रहने वाला हर rule, service के भीतर ही मौजूद हर eval case और तय लेकिन कभी न लिखी गई हर bar, suitcase से बाहर जाता weight है। Movable रहने की habit एक sentence की है: truth repo में रहती है और हर home उसी से configure होता है।

आसान भाषा में

घर बदलते समय अपनी चीज़ें pack करते हैं और दीवारों से जुड़ी lights वहीं छोड़ते हैं। Spec, rubric, cases और bars आपकी हैं, इसलिए suitcase में जाती हैं। Flags, paths और API shapes पुराने घर से जुड़ी हैं, इसलिए पीछे रहती हैं। Movable लोग घर में रहते समय भी अपनी valuables suitcase में रखते हैं।

8. Trust transfer नहीं होता, फिर कमाना पड़ता है

Figure के right panel की आख़िरी item अपना concept deserve करती है, क्योंकि movers सबसे अधिक इसी को skip करना चाहते हैं। आपका 35/36 एक system का measurement था: यह config, harness, model, machine और reachable tools का set। Move ने इनमें कई चीज़ें साथ बदल दीं। New home में चलने वाला system measured system का करीबी relative है, लेकिन old number उस system पर measured था जो अब मौजूद नहीं। इसलिए उसे inherit नहीं किया जा सकता। वह comparison target रहता है: new home को जिस standard तक पहुँचना है, free में मिलने वाला label नहीं।

Arrival protocol evals course को जानबूझकर फिर चलाना है। Familiar लगना चाहिए, क्योंकि move आपकी regression discipline द्वारा gate किया सबसे बड़ा change है:

1. New home में सबसे पहले पूरा golden set चलाएँ। Smoke set नहीं, full set। Runner headless है और new home headless समझता है। यह हमेशा काम करने वाला था, इसीलिए Concept 3 ने इसे bridge कहा।
2. Misses को count से पहले category के अनुसार पढ़ें, ठीक जैसे evals course के Concept 10 ने सिखाया। Tone case down छोटी problem है। New reachable surfaces वाले home में injection case down, यानी input में छिपी malicious instruction resist करने की test fail, emergency है। किसी और चीज़ के move होने से पहले rubric या fence fix चाहिए।
3. Bars hold करें, फिर home label वाला नया baseline record करें। Old baseline delete नहीं होता; वही comparison target है और location बदलने से उसके release bars नहीं बदलते। New home को existing bars pass करनी हैं। Old rate से meaningful difference investigate होगा, accept नहीं। तभी runtime-specific baseline record करें: recorded date, model, rubric version और अब runtime। Gap हो तो explanation के साथ दोनों numbers history में रखें। Environment-specific baseline बदलता है; acceptance standard चुपचाप नहीं।
4. Dependence से पहले probation। Fixed period रखें: कम-से-कम एक पूरा operating cycle और कम-से-कम दस successful beats; riskier या rare loops के लिए अधिक। इस दौरान old home available रहे और new home की beats रोज़ नए baseline से check हों। Result को initial operational evidence कहें, uptime proof नहीं; पाँच quiet weekday runs बहुत कम साबित करती हैं। Move तब पूरी होती है जब new track record कहे, old reputation नहीं।

आसान भाषा में

Old score old setup पर measured था और move ने setup बदल दिया, इसलिए score साथ नहीं आता। New home में इसे फिर कमाएँ: पहले दिन full test set चलाएँ, failures और उनकी categories देखें, वही pass-bar रखें, new home के नाम वाला fresh score लिखें और trust करने से पहले trial period में देखें।

Harness course की bad night जैसी एक warning। New home की reach नई है: cloud runner laptop से अलग credentials देखता है। Managed environment local config से अलग tools expose करता है। Injection और blast-radius cases old reach के विरुद्ध लिखे गए थे। Probation समाप्त होने से पहले golden set के hard cases देखें और हर एक से पूछें: "जिस failure से यह case बचाता है, क्या वह यहाँ अलग दिखती है?" आम तौर पर नहीं। जब जवाब हाँ हो, यह सवाल future की हर move में जगह बना चुका है।

खुद जाँचें

Home 2 में move के बाद पहली full-set run old baseline 35/36 के विरुद्ध 33/36 देती है। एक clean-fix case flake हुआ और re-run में green है। बाकी दोनों misses एक ही case की हैं: fixture old laptop की absolute path से file पढ़ती है। इस concept और suitcase test से तीनों misses sort करें।

जवाब देखें

Flake noise है, evals course की re-run policy से handled: record होगी, gate नहीं करेगी। Repeated miss agent की regression नहीं। यह suitcase error है: absolute file path mechanics है और गलती से fixture में travel कर गई। Fix system नहीं, case को repair करना है, यानी fixture की path relative बनानी है। फिर evals course के rule के अनुसार उसी commit में re-baseline करें, क्योंकि set बदला है। Bars खुद नहीं बदलतीं और repair history में visible होनी चाहिए, ताकि genuine regression कभी "suite fix" में छिप न सके। Honest net reading: new home baseline पर है। Move ने suite की portability bug पकड़ी, और new home की first run इसी तरह की चीज़ पकड़ने के लिए है।

---

Part 5: Home चुनना

9. चार सवाल

Course ने जो बनाया है वह क्रम में पूछे गए चार सवालों में समा जाता है। पहले तीन home चुनते हैं। चौथा तय करता है कि move कब करनी है।

Q1: User कौन है? Honest answer आप हो तो जल्दी रुकें: home 2 लगभग हमेशा आपकी ज़रूरत की ceiling है। अधिकतर readers के लिए अधिकतर समय यही सही है और इसमें शर्म की बात नहीं। जवाब में दूसरे लोग आते ही, जैसे output पढ़ती team, client या customer, loop को आपकी absence, vacation और login के बिना survive करना होगा। तब सवाल Q2 बनता है।

Q2: क्या own करना ही है? जो own करना चाहते हैं वह नहीं; जो सच में करना ज़रूरी है। दो planes से तीन precise answers मिलते हैं। कुछ own करना ज़रूरी नहीं: fully managed runtime सही है। Vendor को infrastructure pager देना compromise नहीं, money का सही use है। सिर्फ़ execution और data plane, यानी work और वह जो छूता है, loop नहीं: self-hosted sandbox वाला home 3 ठीक यही देता है। Custody आपकी, operations किराये पर। Control plane भी: prompts, sessions, model path या agent की product surface own करनी हो तो requirement home 3 के पार owned runtime, SDK path और Mode 2 की ओर ले जाती है।

Q3: क्या कोई व्यक्ति answer का इंतज़ार करता है? Scheduled और background work, जैसे triage, reports और pipelines, schedules व managed sessions में सहज बैठता है। Screen पर wait करता human owner को अपने-आप नहीं, requirements को बदलता है। अब predictable startup, streaming, cancellation और concurrency वाला serving runtime चाहिए। Managed service यह self-operated service से बेहतर दे सकती है। Runtime own करने से यह अपने-आप नहीं मिलता, क्योंकि कोई runtime model का thinking time नहीं हटा सकता। Ownership अब भी Q2 तय करता है। Q3 बताता है कि serving अलग work shape है, और वह Mode 2 की है। अभी इसे पहचानना काफ़ी है।

Q4: Bad night की cost क्या है? Harness course का budgeting question आख़िरी बार। Low blast radius: minimum unattended kit pass करें, जल्दी move करें और probation में बाकी harden करें। High blast radius: एक भी unattended shift से पहले new home kit और full suite pass करे, injection categories में सारे cases pass हों। Q4 destination नहीं बदलता, speed limit तय करता है।

आसान भाषा में

चार सवाल क्रम में। इसे कौन use करता है: सिर्फ़ आप या दूसरे भी? क्या own करना ज़रूरी है: कुछ नहीं, सिर्फ़ work या पूरा loop? क्या कोई व्यक्ति screen पर answer का wait करता है? Bad night की cost क्या है? पहले तीन home चुनते हैं। आख़िरी सिर्फ़ move की speed तय करता है।

10. एक पूरी move, और homes जानबूझकर mix होते हैं

इस section के दूसरे course से चले आ रहे morning triage loop पर पूरा course एक बार चलता देखें।

सवाल। Q1: user आप हैं और पिछले महीने से triage report पढ़ते दो teammates भी। यही "और" trigger है। Loop को आपका login survive करना होगा। Q2: कोई must नहीं, क्योंकि repo पहले ही GitHub पर है और queue में custody-restricted कुछ नहीं। Q3: screen पर कोई wait नहीं करता; beat सबके बैठने से पहले चलती है। Verdict: home 2, GitHub Actions version, क्योंकि loop repo-attached है और evals course का eval gate उसी CI में रहता है। Q4: bad night गलत triage labels और एक गलत escalation file करती है; परेशान करने वाला लेकिन recoverable, low radius। Speed limit: kit passed, अभी move, probation दो weeks, क्योंकि loop weekdays पर चलता और दस beats floor है।

Move। Monday को workflow file: schedule: trigger, headless invocation, repo से checkout config, checked exit code और ऐसी channel में loud failure जिसे आप सच में पढ़ते हैं। साथ में kit के तीन सबसे cheap controls: concurrency lock, missed-run heartbeat और per-beat limits। Suitcase check में laptop path वाली एक fixture मिली, repair हुई और उसी commit में set re-baseline हुआ। New home की पहली full-set run: सारी categories bar पर। runtime: actions label वाला नया baseline committed। अगले दो weeks: lid बंद, schedule पर beats, silence का अर्थ baseline, बीच में एक planted failure, क्योंकि कभी न सुनी alarm सिर्फ़ अफ़वाह है। Beat ten pass, probation खत्म, laptop schedule delete। System के पास अब दो track records हैं और नया record मायने रखता है।

Mix। अब पूरी system देखें, क्योंकि यह जानबूझकर one-home नहीं है। Loop home 2 में है। Evals course के अनुसार eval gate उसी CI में। Heavy one-off jobs, जैसे quarterly cleanup और big refactor, अब भी home 1 में interactively चलते हैं, जहाँ आप देख सकते हैं। Teammates client बनें तो Q1 फिर fire होता है और सिर्फ़ serving path के लिए home 3 conversation में आता है। Home permanent loyalty नहीं। यह हर loop के लिए चार सवालों का answer है, और healthy system अक्सर दो या तीन homes में फैलती है। Concept 7 का एक sentence mix को mess बनने से रोकता है: truth repo में रहती है और हर home उसी से configure होता है।

आसान भाषा में

Home ऐसी जगह नहीं जहाँ हमेशा के लिए बसें। हर loop के लिए चार सवालों से choice है। ज़्यादातर real setups दो या तीन homes साथ use करती हैं: daily loop schedule पर, heavy one-off job laptop पर जहाँ उसे देख सकें। एक rule mix को mess नहीं बनने देता: truth repo में रहती है और हर home वहीं से setup होता है।

खुद जाँचें

इस book की दुनिया के दूसरे loop पर चार सवाल फिर चलाएँ: Ayesha का invoicing loop अब पाँच clients को directly invoices भेजता है। उनमें एक bank चाहता है कि client data उस infrastructure पर रहे जिसे Ayesha की firm control करती है। हर सवाल कहाँ पहुँचता है और uncomfortable honest conclusion क्या है?

जवाब देखें

Q1: users clients हैं, इसलिए home 1 के पार और dependence के लिए "runner जब चल जाए" से भी आगे। Q2 deciding question है और दो planes इसे precise बनाते हैं: bank की must execution और data के बारे में है, यानी work कहाँ चलता और क्या छूता है। Firm की infrastructure पर self-hosted sandbox वाला managed control plane यह ठीक पूरा कर सकता है: client data firm की custody में और loop vendor operate करे। यह bank तय करेगा, Ayesha नहीं। Must control plane तक भी जाए, यानी prompts, sessions और model path, तो सिर्फ़ owned runtime answer है। Q3: invoicing scheduled background work है, latency pressure नहीं। Q4: real clients को गलत invoice high radius है; unattended shift से पहले kit और full suite। Honest conclusion: कोई single home fit नहीं। Bank का path या owned execution plane वाला home 3 है, या requirement आगे जाए तो SDK path। दोनों में Ayesha उस edge पर पहुँच गई हैं जिसे operator अकेले configure नहीं कर सकता। इस book में उस edge का नाम Mode 2 है। ठीक इसी moment के लिए book का fork है।

---

Part 6: ईमानदार बने रहना

11. Lock-in एक rate है और ownership drift करती है

पहले home के बाद हर home के साथ दो slow failures आती हैं, और कोई अपना announcement नहीं करती।

Lock-in event नहीं, rate है। Day one पर कोई portability sign away नहीं करता। वह leak होती है: vendor-side setting में बदला rule जो repo में mirror नहीं हुआ; service console में जोड़ा eval case; dashboard में renegotiated bar जिसके पीछे commit नहीं। हर item चुपचाप suitcase से fixtures में जा रही है। किसी समय आपके lock-in का measure एक सीधा सवाल है: अगर यह home इस quarter गायब हो जाए, move की cost क्या होगी? Defense वही sentence है: truth repo में रहती है। इसे वैसे audit करें जैसे evals course का Part 6 Goodhart को audit करता है, यानी उस trap को जहाँ target बनते ही number उस चीज़ को measure करना छोड़ देता है जिसकी आपको परवाह थी। Schedule पर hold-out mindset रखें: ऐसे set से test जिसे अलग रखते और कभी उसके अनुसार tune नहीं करते। हर quarter "सिर्फ़ repo से fresh home configure करें" वाली practice portability का hold-out set है। Fresh home complete न हो तो leak उस समय मिल गई जब वह सिर्फ़ एक item चौड़ी थी।

कुछ leak न हो तब भी ownership drift करती है। Subtle failure files में नहीं, आप में है। महीनों quietly चलने वाला home आपके मन में छोटी promotion invite करता है: "यह system measured है" से "यह system ठीक है" तक। Evals course ने mechanical version बताया था: drifted model के नीचे judge का 95 meaning बदलना। Runtime version human है: baselines green, schedule silent, और धीरे-धीरे आप per-category report पढ़ना, calibration replay करना और vendor की नई capability environment में आने पर Concept 8 का new-reach सवाल पूछना छोड़ देते हैं। Discipline में "और फिर यह खुद को maintain करती है" नाम का कोई step नहीं। Scheduled run system को देखती है। उसे पढ़ने की calendar reminder आपको देखती है।

आसान भाषा में

दो slow problems चुपचाप बढ़ती हैं। पहला, हर छोटी setting के साथ home छोड़ना कठिन होता जाता है, जब तक सब कुछ repo में न रखें। दूसरा, महीनों quietly चलने वाला home आपको check करना छुड़ा देता है। दोनों का fix एक है: repo को single source of truth रखें और reports सच में पढ़ने की calendar reminder set करें।

12. कोई home क्या fix नहीं कर सकता, और आगे कहाँ जाना है

Section को वहीं समाप्त करें जहाँ इसका हर course हुआ: honest boundary पर। Better home बदलता है कि agent कब काम करता है, उसे alive कौन रखता है और 3am पर क्या होता है। यह agent कितनी अच्छी तरह काम करता है, उसमें एक चीज़ नहीं बदलता। Weak spec Anthropic cloud पर भी weak है। Uncalibrated judge आठ cents प्रति hour पर भी uncalibrated है। Missing eval case earth के हर runner पर missing है। Runtime decision इस section का आख़िरी course ठीक इसलिए है कि पहले course के रूप में बेकार होता: वह जिस चीज़ को relocate करता है, उसे relocation के लायक होना था। इस course की move आसान लगी हो तो कारण यही है। कठिन काम trilogy थी; move सिर्फ़ suitcase है।

आसान भाषा में

Better home बदलता है कि agent कब चले, उसे alive कौन रखे और 3am पर कौन fix करे। वह agent को smarter या अधिक correct नहीं बनाता। Weak plan cloud में भी weak है। अच्छा काम पहले बने spec, harness और tests से आता है। Home सिर्फ़ तय करता है कि उसे running कौन रखेगा।

अब section का arc पूरा है, इसलिए इसे एक बार पूरी लंबाई में पढ़ें। आपने general agent को drive करना, spec से direct करना, फिर loop delegate, harness harden और checker measure करना सीखा, और अब पूरी system को योग्य जगह house किया। आखिर में आपके पास वही है जिसे book पहले page से quietly assemble कर रही थी: specified, guarded, measured और housed unit of work। इस phrase को book की vocabulary से मिलाएँ तो अगला door खुद खुलता है: दूसरे लोगों के लिए बनी, owned runtime, product surface और price वाली उस unit का नाम Digital FTE है। आप operating scale पर शुरू से वही manufacture कर रहे थे।

इस section से तीन doors निकलते हैं और चार सवाल पहले ही बता चुके हैं कि आपका कौन-सा है। अगला Personal Agent Harnesses section उस reader के लिए है जिसका Q2 personal scale पर must own कहता है: worker आपका, infrastructure आपकी और पूरा runtime decision हाथ से। Mode 1: Problem-Solving अभी वाली system से real problems solve करने के लिए है, और अधिकतर readers का सही next step है। Mode 2: Manufacturing इस course के हर previewed promise को पूरा करता है: Agent SDK से home 4 खुलता है, decoupled architecture inherited चीज़ की जगह आपकी design choice बनकर लौटती है, और Eval-Driven Development course उस suite को scale करता है जिसने अभी आपकी move supervise की।

Section के लिए closing thought। Loop ने agent को time दिया। Harness ने limits। Evals ने track record। इस course ने worker की आख़िरी ज़रूरत दी: ऐसा address जो आपका नहीं। Rhetoric के नीचे एक literal sentence, ताकि finish line गलत न समझें: independent address इस section की अंतिम requirement है, production operations की नहीं। Served product को फिर भी owner, escalation path, retention policy, continuity और उसे बंद करने की authority वाला व्यक्ति चाहिए; Mode 2 यह सब सिखाता है। लेकिन पहुँचना, काम करना, काम prove करना और अपनी जगह पर रहना: यही हमेशा पूरी job description थी। Agents के लिए भी, सिर्फ़ agents के लिए नहीं।

खुद जाँचें

Reader course पूरा करके कहता है: "तो endgame home 3 है। अंत में सब managed में जाता है।" Q1 से Q4, Concept 10 का mix और ऊपर की boundary use करके दो-sentence correction लिखें।

जवाब देखें

कोई endgame home नहीं: चार सवाल हर loop के लिए पूछे जाते हैं और healthy system जानबूझकर homes में फैली होती है, home 1 में build, home 2 में schedule और must के अनुसार home 3 या owned runtime से serve। कोई home agent का upgrade नहीं: quality spec, harness और travel करने वाली suite में रहती है। Home सिर्फ़ तय करता है कि lights कौन on रखता है, यानी system चलती कौन रखता है।

---

इस book के अपने loops कहाँ रहते हैं (dogfooding)

इस course का decision course के बनने से पहले इस book पर चला था। Book का review loop, reviewer rubric, 95 bar और उससे नीचे no merge, Q1 का जवाब "team" देता है: authors और issues file करने वाले readers। इसलिए उसका designed home home 2 है, book repo की CI, ठीक वही GitHub Actions version जो course सिखाता है। Loop repo-attached है और eval gate को merge gate के पास रहना चाहिए। Heavy interactive work, जैसे नया course draft करना या figure pipeline चलाना, अब भी home 1 में होता है जहाँ person देखता है। इस writing के समय home 3 open question है और book इसे Part 5 के अनुसार treat करती है: serving path को कोई must own force नहीं करता, latency pressure नहीं, इसलिए managed option Q1 के answer के फिर बढ़ने तक wait करता है। Truth repo में रहती है। Homes details हैं। आप अभी इसी arrangement का output पढ़ रहे हैं।

---

🚀 Projects

आसान से कठिन तक आठ moves। हमेशा वाले दो rules: throwaway repo और failure खुद plant करें। Home सिर्फ़ उस bad night से prove होता है जिसे वह survive करे।

📁Project 130-45 minHeadless wrapperएक beat command से चलाएँ और उसकी failure को miss करना असंभव बनाएँ।

Difficulty: आसान · Uses: Concept 3.

Build। Loop की beat को script में wrap करें: headless invocation, checked exit code और ऐसी जगह loud failure जिसे आप सच में देखते हैं।

Done when network cable निकालकर run करने पर silence नहीं, alarm मिले। Course की कोई और चीज़ safe होने से पहले silence का अर्थ success होना चाहिए।

⏰Project 21-2 hrsपहली scheduled beatसिर्फ़ clock move करें और lid बंद रहते beat चलती देखें।

Difficulty: आसान से medium · Uses: Concept 4.

Build। Wrapper को home 2 में schedule पर रखें, Routine या Actions schedule: trigger के साथ, और config repo से source हो।

Done when laptop बंद रहते एक beat चल चुकी हो और आप दिखा सकें result कहाँ पहुँचा। Kit की पहली तीन rows किसी रूप में मौजूद हों, छोटी ही सही: idempotency, missed-run detection और concurrency lock।

🧳Project 345-60 minSuitcase auditDiscipline layer में छिपी mechanics खोजें।

Difficulty: medium · Uses: Concept 7.

Build। Two-panel figure खोलकर config, cases और fixtures देखें। Discipline layer में छिपी mechanics की हर item list करें: absolute paths, machine names, prose में baked flags।

Done when list committed हो और worst three fix हों। कम-से-कम एक मिलने की उम्मीद रखें; Part 4 की story बनाई हुई नहीं थी।

📏Project 41-2 hrsArrival protocolNew home में full set चलाएँ और ईमानदारी से re-baseline करें।

Difficulty: medium · Uses: Concept 8.

Build। New home में full golden set चलाएँ। Misses category से sort करें। Runtime label वाला new baseline record करें।

Done when baseline.json में runtime: field हो और हर miss का written verdict हो: noise, suite bug या real, और real misses का fix shipped हो।

🌙Project 51 hr, plus two weeks of nightsProbationदस beats, एक planted failure और old home आखिर delete।

Difficulty: medium · Uses: Concepts 4 और 8.

Build। New home में कम-से-कम एक full operating cycle और दस scheduled beats चलाएँ, रोज़ new baseline से check करें और old home available रखें। बीच में एक failure plant करें।

Done when दस beats green हों, planted alarm आप तक पहुँची हो और old schedule delete हो। Course में "moved in" का यही अर्थ है। Log के ऊपर "initial operational evidence" लिखें, क्योंकि दस beats सिर्फ़ इतना ही हैं।

🗺️Project 645-60 minचार सवाल, लिखकरअपने हर loop के लिए Q1 से Q4 answer करें और answers commit करें।

Difficulty: medium · Uses: Concepts 9 और 10.

Build। हर real loop के लिए एक committed Markdown file में Q1 से Q4 answer करें, और हर answer home व speed limit पर समाप्त हो।

Done when सिर्फ़ वह file पढ़कर कोई बता सके कि हर loop कहाँ और क्यों रहता है। कम-से-कम एक loop का answer इतना surprising हो कि आप उसे move करें।

🏢Project 72-3 hrsHome 3 में एक sessionएक managed session खोलें और देखें event log क्या बताएगा और क्या नहीं।

Difficulty: medium से कठिन · Uses: Concepts 5 और 6। (Claude Code track। OpenCode readers: इसके बदले Project 2 का runner harden करें: credentials rotated, updates scheduled, uptime checked।)

Build। Live docs से one managed agent, one environment और golden set का एक graded case चलाने वाला one session बनाएँ। Event log पूरा पढ़ें। पहले और बाद में active-runtime meter note करें।

Done when अपनी run से तीन बातें लिख सकें: log ने क्या दिखाया, क्या नहीं दिखा सका और session की cost क्या थी। Project 6 की file के पास तीन sentences commit करें।

🔥Project 82 hrs, then a quarter of patienceVanishing-home drillसिर्फ़ repo से home फिर बनाएँ और time करें: यही number आपका lock-in है।

Difficulty: capstone · Uses: Concept 11.

Build। सिर्फ़ repo से, vendor console या old machine के बिना, loop के home की fresh copy configure करके baseline तक लाएँ। Time करें और drill quarterly schedule करें।

Done when fresh home full suite pass करे और written time-cost आपका measured lock-in हो। Drill fail हो तो leak तब मिली जब वह सिर्फ़ एक item चौड़ी थी, और यही पूरा point है।

---

Sources और आगे पढ़ें

इस book के भीतर

• Loop Engineering: beats, schedule और "get loud" verb जिन्हें यह course relocate करता है।
• Harness Engineering: fences और blast-radius budgeting जिसे Q4 runtimes के बारे में फिर पूछता है।
• Trusting the Checker: golden set, baselines और drift discipline जो इस course की हर move को gate करती है।
• Personal Agent Harnesses: Q2 का personal-scale must own answer।
• Mode 2 में Eval-Driven Development और Deploy the Agent Harness: manufacturing size पर वही decisions, home 4 पूरी तरह open।

Runtimes (official docs)

• Claude Code headless mode: claude -p, output formats और scripting: https://code.claude.com/docs/en/headless
• Claude Agent SDK overview: library और साफ़ कही SDK-versus-managed boundary: https://code.claude.com/docs/en/agent-sdk/overview
• Claude Managed Agents quickstart: agents, environments और sessions: https://platform.claude.com/docs/en/managed-agents/quickstart (अप्रैल 2026 से public beta और book में referenced सबसे तेज़ बदलती docs)
• Managed Agents environments: cloud sandboxes, least-privilege networking और Concept 5 की execution-plane choice के पीछे self-hosted sandbox option: https://platform.claude.com/docs/en/managed-agents/environments
• Managed Agents pricing: active session-hour meter: https://platform.claude.com/docs/en/about-claude/pricing
• Claude Code Routines: /schedule, triggers, environments, stagger और green-status caveat: https://code.claude.com/docs/en/routines (research preview)
• Claude Cowork Scheduled Tasks: knowledge-work वाला home 2 और local-files caveat: https://support.claude.com/en/articles/13854387-schedule-recurring-tasks-in-claude-cowork
• OpenCode CLI और server modes: opencode run, opencode serve, remote attach: https://opencode.ai/docs/cli/
• GitHub Actions schedule: triggers और GitHub की delay-and-drop caveats: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule और https://docs.github.com/en/actions/how-tos/troubleshoot-workflows

सारे links mid-July 2026 तक current हैं। इस course की mechanical layer section में किसी भी दूसरी layer से तेज़ पुरानी होती है। Depend करने से पहले live docs में हर name, endpoint और price confirm करें।

---

एक-line summary

एक सवाल से शुरू करें: loop कौन operate करता है और work कहाँ execute होता है? Headless mode हर new home का bridge है। Discipline travel करती है, mechanics फिर बनती है और move के बाद trust फिर measure होता है। चार सवाल home चुनते हैं। Blast radius speed तय करता है। Homes हर loop के लिए जानबूझकर mix होते हैं और truth repo में रहती है ताकि आप हमेशा निकल सकें। Worker तब complete है जब उसका address आपका नहीं।

Flashcards Study Aid

---

अपनी समझ जाँचें

Checking access...