Paperclip के साथ एक self-expanding workforce: 90-minute crash course
एक ऐसी workforce लें जो सिर्फ़ वही काम कर सकती है जो आपने set up किए हैं, और उसे अपनी मदद ख़ुद hire करना सिखाएँ, आपके under।
पिछले course में आपने एक company खड़ी की और एक fixed team चलाई: आपने Workers hire किए, उन्होंने वह काम संभाला जो आपको आता दिख रहा था, और आप board बने रहे। यह course वह एक चीज़ जोड़ता है जो वह company नहीं कर सकती थी, यानी ख़ुद को बढ़ाना।
नई power को बताना आसान है। जब ऐसा काम आता है जिसे आपकी team में से कोई संभाल नहीं सकता, तब आपकी company उसे notice करती है, उसके लिए किसी नए को hire करने का proposal देती है, और उस hire को approve करने के लिए आपके पास लाती है, ठीक वैसे ही जैसे आपने अपने CEO को approve किया था। आप board बने रहते हैं। यह बस आपको हर उस चीज़ के लिए चुपचाप वापस overflow desk बनाना बंद कर देती है जिसकी उसने plan नहीं की थी।
पूरी ride, साफ़ शब्दों में, यह है:
- नया काम आता है जिसे आपका कोई भी मौजूदा Worker संभाल नहीं सकता।
- आपकी company उसे पकड़ती है, उसे cover करने के लिए एक नए hire का proposal देती है, और आपकी हाँ माँगती है।
- आप उस hire को एक छोटा-सा budget और एक छोटा trial देते हैं, उस पर भरोसा करने से पहले।
- वह pass हो जाता है, इसलिए आप उसे थोड़ी और जगह देते हैं, सिर्फ़ उतनी जितनी काम को चाहिए।
- जब वह काम शांत हो जाता है तो आप hire को pause कर देते हैं; जब वह वापस आता है तो आप उसे फिर से on कर देते हैं।
- हर step लिख लिया जाता है, इसलिए महीनों बाद भी आप जानते हैं कि किसने क्या किया, और उसकी cost क्या थी।
- और पूरा gap-check एक schedule पर चल सकता है, ताकि company अपने gaps ख़ुद ढूँढे, और आप उसका alarm clock बनना बंद कर दें।
आप एक ऐसी company से शुरू करते हैं जो सिर्फ़ वही कर सकती है जो आपने set up किया। आप एक ऐसी company पर ख़त्म करते हैं जो ख़ुद को बढ़ाती है, लेकिन हमेशा सिर्फ़ आपकी हाँ के साथ। नीचे दिए गए सात scenarios वही ride हैं, एक बार में एक step।
course के अंत तक आपके पास, अपनी baseline company के ऊपर, होगा: एक नया Worker जिसका proposal आपकी company ने दिया और जिसे आपने एक trial पर hire किया, जो आपके तय किए एक budget और permissions के under असली काम कर रहा है, जिसे आपने demand बदलने के साथ pause किया और वापस लाया, एक ऐसी लिखित history के साथ जो इतनी पूरी है कि आप कल किसी और को सौंप सकें, और एक weekly routine जो पूरा gap-check ख़ुद चलाती है ताकि आपको कभी देखना याद न रखना पड़े।
आपका reading path (लगभग 90 minutes, baseline setup और knowledge check सहित)
हर scenario ऊपर दी गई ride का एक step है, और हर एक यह बताता है कि जब वह काम करे तो आपको क्या SEE करना चाहिए।
- Gap पकड़ें (~12 min): काम के एक असली ढेर को एक असली hire से अलग पहचानें।
- Hire को लिख लें (~10 min): gap को एक job rec में बदलें जिसे आपका agent draft करता है और आप पढ़ते हैं।
- Approve करें, minimal power के साथ (~12 min): वही board gate जो आप पहले से use करते हैं, और इस फ़र्क़ को समझें कि एक Worker किस लिए है बनाम वह असल में क्या कर सकता है।
- Cheap में prove करें, फिर grant करें (~12 min): पहले दिन trial देखें, और authority तभी बढ़ाएँ जब वह earn हो जाए।
- Pause और resume (~8 min): एक Worker को खोए बिना retire करें, फिर वापस लाएँ।
- वह ledger जिसे आप सौंप सकें (~10 min): अपनी company की पूरी hiring story उसके अपने records से पढ़ें।
- इसे एक cadence पर डालें (~10 min): gap-review ख़ुद चलने लगता है जब आप CEO को on call कर देते हैं और एक routine को schedule पर काम create करने और CEO को उसे करने के लिए ring करने देते हैं।
आपको चाहिए होगा एक coding agent जिसमें आप logged in हैं (Claude Code या OpenCode), और या तो पिछले course की company, या दो minute ताकि पहला prompt एक equivalent company बना दे। कोई coding नहीं, और कोई API key नहीं: आपका agent सब कुछ चलाता है, और आप सिर्फ़ वे calls लेते हैं जो सिर्फ़ एक इंसान ले सकता है।
📚 Teaching Aid
पूरी Presentation देखें: Paperclip के साथ एक Self-Expanding Workforce
यह कैसे काम करता है: आप steer करते हैं, agent काम करता है. तीन players, एक rhythm। आप board हैं, वे calls लेते हैं जो सिर्फ़ एक इंसान ले सकता है: एक hire approve करना, authority grant करना, एक role retire करना। आपका agent (Claude Code या OpenCode) hands-on काम करता है। Paperclip company ख़ुद है: यह आपके Workers को रखता है, उन्हें जगाता है, और आपके तय किए budgets और permissions को enforce करता है। आप एक plain request paste करते हैं, आपका agent एक plan propose करता है, आप approve करते हैं, यह चलता है, और आप दोनों result check करते हैं। वही आगे-पीछे का सिलसिला पूरा course है।
आप एक छोटा folder download करते हैं और उसे अपने agent में खोलते हैं। Agent एक brief (एक AGENTS.md file) पढ़ता है जो उसे hiring lifecycle सिखाती है: एक gap कैसे पकड़ें, आपके approval gate से होकर एक hire कैसे file करें, एक Worker की असली permissions कैसे set करें, उसे कैसे चलाएँ, और ledger कैसे पढ़ें। आप कभी कोई command नहीं छूते; आप decisions लेते हैं।
dynamic-workforce-base.zip download करें
इसे अपने agent में खोलें और confirm करें कि brief load हो गई:
एक dynamic Paperclip workforce के लिए आप मेरे लिए क्या कर सकते हैं?
अगर reply hiring loop का नाम लेता है (एक gap पकड़ना, एक hire file करना, आपका approval gate, एक Worker की permissions, talent ledger), तो आप ready हैं। अगर यह generic AI बातचीत जैसा लगे, तो confirm करें कि आप dynamic-workforce/ folder के अंदर हैं और दोबारा launch करें।
अगर कुछ भी गड़बड़ हो जाए, तो आपको CLI जानने की ज़रूरत नहीं। यह paste करें:
कुछ काम नहीं किया।
paperclipai doctorचलाएँ, सबसे recent Paperclip server log पढ़ें, मुझे plain language में बताएँ कि आपको क्या दिख रहा है, और एक fix propose करें जिसे मैं approve कर सकूँ।
अगर आप किसी scenario के expected time के लगभग दोगुने से ज़्यादा निकल जाएँ, तो paste करें: "हमें क्या रोक रहा है, एक sentence में? चलिए वहीं से re-plan करते हैं।" एक improvise करता agent ख़ुद बता देगा, और आप reset कर सकते हैं।
अपनी baseline set करें (एक prompt)
Dynamic loop को बढ़ने के लिए एक company चाहिए। इस पर निर्भर रहने के बजाय कि आपने पिछले course को किस state में छोड़ा था, एक prompt से एक known baseline खड़ी करें। यह idempotent है: अगर आपके पास पिछले course की company पहले से है, तो आपका agent उसी का use करता है और सिर्फ़ वही भरता है जो missing है।
इस course के लिए मेरी baseline set up करें। पक्का करें कि Paperclip चल रहा है, और मेरे पास Northwind
नाम की एक company है जिसका goal है "एक weekly AI newsletter launch करना और 90 दिनों में 1,000
subscribers तक पहुँचना", एक बीस-डॉलर का monthly budget, और किसी भी नए hire से पहले board approval
ज़रूरी हो। उसमें पहले से दो Workers होने चाहिए, एक CEO और एक CMO जो CEO को report करता हो, दोनों
एक local agent पर चल रहे हों जिसमें मैं logged in हूँ ताकि यह keyless रहे। अगर इसमें से कुछ भी
पिछले course से मौजूद है, तो उसी का use करें; सिर्फ़ वही create करें जो missing है। फिर मुझे
company और उसके दो Workers के साथ dashboard दिखाएँ।
तब पूरा जब: dashboard में Northwind एक goal, एक budget, hire gate on, और ठीक दो Workers (एक CEO और एक CMO) के साथ दिखे। यही आपकी fixed workforce है। बाकी course उसे बढ़ाता है।
Scenario 1: Gap पकड़ें (~12 min)
आपकी baseline team वह काम संभालती है जो आपको आता दिख रहा था: CEO strategy तय करता है, CMO newsletter लिखता है और growth चलाता है। फिर newsletter काम करने लगता है, और नई तरह का काम आने लगता है जिसका team में किसी पर ownership नहीं है। उनमें से तीन एक साथ आ जाते हैं:
- Reader support जमा होने लगता है: टूटे signup links, "मेरा issue कहाँ है", "मेरा email बदल दीजिए", और कभी-कभार कोई billing या refund सवाल। आपका CMO एक marketer है, support desk नहीं, और इनमें से कुछ भी strategy नहीं है, इसलिए यह आप पर आ गिरता है।
- कोई numbers नहीं पढ़ रहा। कौन से topics असल में subscribers जीतते हैं, लोग unsubscribe क्यों करते हैं, open rate आपको क्या बता रहा है। आपका CEO instinct के सहारे steer कर रहा है क्योंकि data पर किसी की ownership नहीं है।
- असल में issue ship करने की किसी पर ownership नहीं। उसे format करना, schedule करना, email tool से भेजना, bounces संभालना। CMO उसे लिखता है; उसे दरवाज़े से बाहर निकालना हर हफ़्ते improvise होता है।
एक ऐसी workforce जो hire नहीं कर सकती, वह आपको हर उस चीज़ के लिए चुपचाप वापस overflow desk बना देती है जिसकी उसने plan नहीं की थी, और newsletter जितना बेहतर करता है, उतना ही ज़्यादा यह आता है।
पूरा course जिस एक idea पर सवार है, वह यह है:
जब workforce ऐसे काम से टकराती है जिसे वह संभाल नहीं सकती, तो वह उसे आप पर नहीं पटकती। आपका agent gap पकड़ता है, एक hire draft करता है, और उस hire को एक और board approval के रूप में आपके पास लाता है, वही APPROVE या REJECT जो आप CEO और strategy के लिए पहले से use कर चुके हैं। Hiring एक function call बन जाती है, और आप gate बने रहते हैं।
उस तस्वीर में दो decisions ही असली सबक़ हैं, और दोनों judgment हैं, buttons नहीं।
पहला, क्या यह सच में एक gap है? एक असली gap तीन signals के रूप में दिखता है, और आप उनमें से कम से कम दो चाहते हैं:
- कोई role उसे cover नहीं करता। काम किसी Worker के job या skills से match नहीं होता।
- यह आता रहता है, और यह बढ़ रहा है। एक बार वाली बात नहीं; volume चढ़ रहा है, ऐसी पतली धार नहीं जिसे आप नज़रअंदाज़ कर सकें।
- जब कोई इसे work करता है, तो यह wrong वापस आता है। एक Worker हाथ मारता है और result गड़बड़ होता है, या उसे वापस kick कर दिया जाता है।
दूसरा, एक असली gap भी अपने आप एक hire नहीं है। यही वह हिस्सा है जिसे beginners छोड़ देते हैं। एक standing Worker एक standing cost है, इसलिए एक gap आपको एक decision देता है, एक नई salary नहीं। आप चार में से एक चुनते हैं:
- HIRE: durable, on-mission, और या तो high-volume या इतना risky कि उसे एक permanent, governed owner चाहिए।
- ESCALATE: consequential या rare, इसलिए एक इंसान को बस तय कर देना चाहिए। अगर एक reader legal धमकी भेजता है या अपने bank के साथ किसी charge पर dispute करता है, तो वह staff करने के लिए एक नया desk नहीं है; वह एक single high-stakes call है जिसे आप सीधे एक इंसान को route करते हैं।
- QUEUE: seasonal, bursty, या बस अगली पंक्ति में, इसलिए उसे एक साथ staff करना एक ग़लती है।
- DECLINE: off-mission, या असली पर अभी एक standing cost के लायक़ नहीं।
तीन candidates, तीन जवाब
आपके पास एक gap नहीं है, आपके पास तीन हैं, और forks ही वह चीज़ हैं जो तीन असली ज़रूरतों को चुपचाप तीन monthly salaries बनने से रोकती है।
| The gap | आपको क्या दिखता है | Fork | यह fork क्यों |
|---|---|---|---|
| Reader support | कोई role owner नहीं; recurring और बढ़ता हुआ | HIRE | यह refunds और accounts को छूता है, इसलिए risk को एक governed owner चाहिए |
| Issue ship करना | कोई role owner नहीं; हर हफ़्ते recurring | QUEUE | उतना ही असली, पर आप एक बार में एक role staff करते हैं; यह अगला hire है |
| Numbers पढ़ना | कोई role owner नहीं, पर data अभी भी पतला है | DECLINE for now | एक हज़ार subscribers पर एक analyst अभी अपनी cost earn नहीं कर सकता |
आप एक hire करते हैं: Reader Support Specialist। आप shipping gap को लिख लेते हैं ताकि वह खो न जाए, और वह अगला hire बन जाता है। आप analyst को जान-बूझकर decline करते हैं, scale पर दोबारा देखने के एक note के साथ। तीन असली ज़रूरतें, एक हाँ।
दो signals क्यों, और वह trap जो beginners को बेवक़ूफ़ बनाता है
दो क्यों, और वे independent क्यों होने चाहिए। एक अकेला signal एक ख़राब हफ़्ता या एक quirk हो सकता है। नियम है तीन में से दो, और यह सिर्फ़ इसलिए काम करता है क्योंकि तीनों सचमुच अलग चीज़ें हैं, इसलिए उनमें से दो का सहमत होना असली evidence है, न कि एक ही fact को दो बार गिनना। एक detective के बारे में सोचिए जो दो असंबंधित गवाह चाहता है, न कि एक ही आदमी जो ख़ुद को दोहरा रहा हो।
The trap. मान लीजिए support mail साफ़ तौर पर चढ़ रहा है, तो दूसरा signal fire हो जाता है, और यह एक obvious hire जैसा लगता है। अब बाक़ी दो check करें। अगर आपकी team में कोई चुपचाप उन tickets के जवाब दे रहा है और उन्हें ठीक से संभाल रहा है, तो एक role उस काम को cover करता ही है, इसलिए पहला signal fire नहीं होता, और काम wrong वापस नहीं आ रहा, इसलिए तीसरा भी नहीं। यह एक signal है, दो नहीं। आपके पास एक capability gap नहीं है, आपके पास एक routing problem है: काम सिर्फ़ इसलिए जमा होता है क्योंकि किसी ने यह set up नहीं किया कि इसे कौन संभालता है। वहाँ एक Worker hire कीजिए और आपने एक छूटे assignment को cover करने के लिए headcount ख़रीद ली है, और आप उसके लिए हर महीने pay करते हैं। (आपकी असली Northwind team में CMO support का owner नहीं है, इसीलिए support वह असली gap है जिसके लिए आप नीचे hire करते हैं।)
इसे करें: gaps को असली बनाएँ, फिर उन्हें triage करें
एक gap जिसके बारे में आप सिर्फ़ पढ़ते हैं, वह gap नहीं है। असली चीज़ का थोड़ा-सा seed करें, फिर अपने agent से उसे अपनी असल team के against judge कराएँ।
मेरे Northwind board पर, नए काम के कुछ असली टुकड़े खोलें: तीन reader support सवाल (एक टूटा link,
एक "मेरा email बदल दीजिए" request, और एक refund request), एक note कि कोई track नहीं करता कि कौन
से topics convert करते हैं, और एक note कि weekly issue भेजने की किसी पर ownership नहीं। हर एक को
मेरे मौजूदा Workers का use करते हुए तीन signals के against judge करें, और हर के लिए fork बताएँ,
why के साथ। फिर support gap को evidence के साथ एक single "Capability gap: reader support" issue
के रूप में record करें।
तब पूरा जब: आपके board पर एक "Capability gap: reader support" issue है, आपके agent ने आपको दिखाया है कि उसके लिए तीन में से कौन से दो signals होल्ड करते हैं, और आप एक sentence में कह सकते हैं कि support क्यों एक HIRE है जबकि issue ship करना एक QUEUE है और analytics अभी के लिए एक DECLINE है।
Scenario 2: Hire को लिख लें (~10 min)
किसी के join करने से पहले, आपका agent hire को एक ठोस चीज़ के रूप में लिख लेता है, जैसे आप एक role खोलने से पहले एक job rec लिखते हैं। तीन decisions उसमें रहते हैं, और वही इस पूरे scenario का सार हैं: role क्या है, आप उसे cheap में कैसे prove करेंगे, और कौन-सा engine उसे चलाता है।
Hire असल में है क्या
जब आपका agent एक hire propose करता है, तो वह आपको उम्मीद का एक पैराग्राफ़ नहीं भेज रहा होता; वह एक छोटी, structured form भरता है, वही जिसे Paperclip का hiring system पढ़ता है:
- role: एक नाम, एक title, और वह किसे report करता है (यहाँ, एक Reader Support Specialist जो CEO को report करता है)
- capabilities: एक plain description कि यह Worker किस लिए है
- engine: कौन-सा runtime असल में Worker को चलाता है
- budget: एक monthly cap, probation के लिए जान-बूझकर छोटा रखा गया
- receipt: source issue, Scenario 1 का reader-support gap जो hire को justify करता है
आप इसे हाथ से नहीं लिखते। आपका agent इसे draft करता है; आप उसे एक hiring manager की तरह पढ़ते हैं और वे fields बदलते हैं जो सचमुच आपका call हैं: budget, reporting line, role का scope। Scenario 3 में ले जाने के लिए एक ईमानदार note: capabilities text एक description है, एक बाड़ नहीं। यह Worker को बताता है कि वह किस लिए है। यह अपने आप उसे कुछ भी करने से नहीं रोकता। इस बात को याद रखें।
आप एक work sample पर hire करते हैं, एक resume पर नहीं
एक description एक दावा है। आप एक दावे पर एक standing Worker commit नहीं करते; आप उसे पहले cheap में prove करते हैं। और एक असली constraint है: Paperclip एक ऐसे candidate को नहीं चला सकता जो अभी भी आपकी approval का इंतज़ार कर रहा है, इसलिए एक को prove करने का ईमानदार तरीक़ा एक probation है, एक tiny budget पर एक छोटा trial। आप Worker को उतनी कम authority के साथ लाते हैं जितने में वह काम कर सके, उसे कुछ असली issues देते हैं, और देखते हैं कि वह असल में क्या करता है उसे और कुछ grant करने से पहले। आप उसे कुछ plain चीज़ों पर score करते हैं: क्या उसने जवाब सही दिया, क्या वह अपनी lane में रहा, क्या वह आपकी company के लिए सही लगा, और उसकी cost क्या रही।
इनमें से, अपनी lane में रहना वह एक चीज़ है जिस पर आप कभी compromise नहीं करते। एक support Worker जो चुपचाप एक refund issue कर देता है, एक billing detail बदल देता है, या अपने आप एक account edit कर देता है, वह उससे बदतर fail हुआ है जो बस कहता है "इसके लिए एक इंसान चाहिए"। एक wrong जवाब एक quality problem है; अपनी lane के बाहर act करना एक governance problem है, और governance ही इस पूरे course का सार है। आप असली बाड़ Scenario 3 में set करते हैं; यहाँ आप बस तय करते हैं कि probation को क्या prove करना है।
Engine एक swap है, एक rewrite नहीं (और एक तेज़ धार)
वही hire कई engines में से किसी पर भी चलता है: एक local coding agent जिसमें आप पहले से logged in हैं (keyless, इसलिए वह meter पर $0 लगता है, वही deal जो पहले थी), या एक hosted runtime जो ख़ुद bill करता है। आपका agent कुछ fields set करके engine बदल देता है; hire के बारे में बाक़ी सब कुछ बिल्कुल वैसा ही रहता है। यह उस बड़े idea का बीज है जिससे आप course के अंत में मिलते हैं: recipe travel करता है, relationship रुकता है।
एक तेज़ धार जो आपका agent पहले से जानता है: local OpenCode engine को एक model explicitly named चाहिए, वरना वह एक default पर गिर जाता है जो drift करता है और mid-run fail हो सकता है। आपका agent उसे set करता है; आप बस confirm करते हैं कि उसने किया।
इसे करें: gap को एक probation plan वाले hire packet में बदलें।
मेरे Scenario 1 gap के लिए Reader Support Specialist hire draft करें: role, कि वह CEO को report
करता है, एक plain capabilities description, एक जान-बूझकर छोटा probation budget, और वह source
issue जिस तक यह वापस trace होता है। फिर probation plan लिखें: तीन या चार असली issues जो उसे
संभालने हैं, और मैं क्या score कर रहा हूँ, "अपनी lane में रहता है" को उस एक चीज़ के रूप में जिस
पर मैं compromise नहीं करूँगा। इसे एक local engine पर चलाएँ जिसमें मैं logged in हूँ ताकि यह
keyless रहे, और model को explicitly name करें। File करने से पहले मुझे पूरा packet दिखाएँ।
तब पूरा जब: आपके हाथ में एक पूरा hire packet है, एक drafted role और एक छोटा probation plan जो reader-support gap तक वापस बँधा है, एक keyless local engine पर, और आप एक sentence में कह सकते हैं कि इस Worker के असली authority earn करने से पहले probation को क्या prove करना है।
Scenario 3: Approve करें, minimal power के साथ (~12 min)
Scenario 2 ने एक candidate और एक probation plan पैदा किया। अब decision आता है: hire आप तक कैसे पहुँचता है, और जिस पल आप हाँ कहते हैं उसे ठीक कितनी power मिलती है। उस power के बारे में obvious idea ग़लत है, और उसे सही समझना एक ऐसी workforce चलाने का दिल है जो hire करती है।
Hiring उसी gate को दोबारा use करती है जो आपके पास पहले से है
आप एक नया approval step नहीं सीखते। Hire file करना उसे उसी board-approval inbox में डाल देता है जिसे आपने CEO और strategy के लिए use किया था। यह pending आता है, proposal और probation plan अपने thread पर लिए हुए, और आप वही तीन चीज़ें करते हैं जो आप हमेशा कर सकते थे: उसे approve करें, reject करें, या बदलावों के लिए वापस भेजें और अपने agent को revise और resubmit करने दें। एक hire बस एक नई तरह की चीज़ है जो एक ऐसे gate पर खड़ी है जिसे आप पहले से चलाते हैं। (Paperclip उसे एक अलग दरवाज़े से file करता है जिसे वह agent-hire कहता है, जो सीधे एक agent create करने से जान-बूझकर अलग रखा गया है, ताकि एक hire को हमेशा आपसे होकर गुज़रना पड़े।)
शब्द बाड़ नहीं हैं। Grants हैं।
यहाँ trap है, और यही इस scenario का पूरा सार है। यह सोचना लुभावना है कि Worker का capabilities text control करता है कि उसे क्या करने की इजाज़त है, इसलिए एक सावधानी से लिखी description उसे अपनी lane में रखती है। ऐसा नहीं होता। Capabilities text एक description है: यह आकार देता है कि Worker कैसे behave करता है, लेकिन यह एक बाड़ नहीं है, और उसे बाड़ मानना ही वह तरीक़ा है जिससे आप बाद में surprise होते हैं।
असली बाड़ एक अलग layer है जिसे Paperclip server पर enforce करता है। एक Worker की असली authority explicit permissions का वह set है जो उसे grant की जाती हैं, हर एक उस चीज़ तक scoped जिसे वह छू सकता है, साथ ही एक per-issue नियम जो उसके पूरे किए काम को land होने से पहले review से route कर सकता है। तो एक नए hire को narrow करना ज़्यादा सावधान prose लिखना नहीं है; यह सिर्फ़ वे permissions grant करना है जो उसके job को चाहिए, और उससे ज़्यादा कुछ नहीं। एक नया hire पहले से ही minimal शुरू होता है: वह issues उठा और work कर सकता है, लेकिन वह दूसरों को hire नहीं कर सकता या अपनी lane के बाहर नहीं पहुँच सकता। Probation पर एक Worker के लिए आप उसे ठीक वहीं रखते हैं, एक tiny budget पर, और उसकी authority तभी बढ़ाते हैं जब वह उसे earn कर ले।
इसे एक इमारत की तरह दो layers समझिए:
- coarse gate वह एक company switch है जो तय करता है कि एक नया hire आपकी approval का इंतज़ार करे या नहीं। आपने इसे पिछले course में arm किया था: इसे off रखें और hires अपने आप शुरू हो जाते हैं, इसे on करें (जहाँ आप इसे रखते हैं) और हर hire आपका इंतज़ार करता है। यह पूरी company के लिए master door policy है।
- fine grant उन permissions और scopes का set है जो यह एक Worker रखता है, साथ ही एक per-issue execution policy जो उसके output को land होने से पहले एक review से route कर सकती है। ये individual keycards हैं: ये तय करती हैं कि यह Worker असल में कौन-से दरवाज़े खोल सकता है।
Capabilities text कहता है कि Worker किस लिए है। Grants, scopes, और execution policy कहते हैं कि वह क्या कर सकता है। इन दोनों को सीधा रखें और एक Worker आपको बाद में surprise नहीं कर सकता।
एक class of hires को बिना click के गुज़रने देना आपका discipline है, एक feature नहीं
एक बार जब आप loop पर भरोसा कर लेते हैं, तो आप चाहेंगे कि कुछ hires एक personal click के बिना गुज़र जाएँ, मसलन एक ऐसे spike के दौरान identical tier-1 Workers का एक burst जो आपको आता दिख रहा था। इस बारे में ईमानदार रहें कि क्या मौजूद है: Paperclip के पास ठीक एक skip-the-board switch है (ऊपर वाली company requireBoardApprovalForNewAgents setting) और कोई built-in नियम नहीं है जो conditions के under hires की एक class को auto-approve करे। तो अगर आप वह चाहते हैं, तो आप उसे एक discipline के रूप में बनाते हैं: आपका agent हर proposed hire को आपकी तय की एक लिखित policy (यह role, permissions का यह envelope, यह budget ceiling) के against check करता है और सिर्फ़ वही file करता है जो fit होते हैं, हर एक को log करते हुए ताकि आप अगली सुबह batch को audit कर सकें।
वह नियम जो इसे safe रखता है: एक pre-approval discipline सिर्फ़ कभी वही pre-filter कर सकता है जो आपने वैसे भी approve किया होता। उसे कभी किसी hire को उससे ज़्यादा authority नहीं देनी चाहिए जितनी आपने हाथ से दी होती। Autonomy वह चीज़ है जो आप जान-बूझकर बढ़ाते हैं और वापस ले सकते हैं; यह कभी एक default नहीं है।
इसे करें: hire file करें और उसकी असली authority पढ़ें।
Reader Support Specialist hire को उसके proposal और probation plan attached के साथ file करें, ताकि
वह मेरे board inbox में land हो। फिर मुझे दो चीज़ें साथ-साथ दिखाएँ: वह एक company switch जो तय
करता है कि hires को मेरी approval चाहिए या नहीं, और वे ठीक permissions जो यह नया Worker probation
पर approve करने के बाद रखेगा। मैं इसके capabilities text के यह कहने के बीच का फ़र्क़ देखना चाहता
हूँ कि वह किस लिए है और उसे असल में क्या करने की इजाज़त है।
तब पूरा जब: hire आपके approval inbox में अपने evidence के साथ बैठा है, और आप company switch (gate) और Worker की permissions (grant) की ओर इशारा करके अपने शब्दों में समझा सकते हैं कि capabilities description वह चीज़ क्यों नहीं है जो Worker को उसकी lane में रखती है।
Scenario 4: Cheap में prove करें, फिर grant करें (~12 min)
Approval काग़ज़ पर एक हाँ थी। अब work sample असल में होता है। जिस पल आप approve करते हैं, Paperclip नए Worker को जगाता है, उसे चलने के लिए एक जगह देता है, source issue पर एक comment डालता है, उसे trial issues देता है, और उसका पहला heartbeat fire करता है। सेकंडों के भीतर वह hire जिसे आपने approve किया था असली काम कर रहा होता है, आपके तय किए tiny budget और minimal permissions के under।
यह work sample है, और यह जो आदत सिखाता है वही probation का पूरा सार है: पहला दिन एक bad hire पकड़ने का सबसे सस्ता दिन है। एक Worker जो अपनी lane को ग़लत पढ़ता है, अपना budget जला देता है, या ग़लत जवाब देता है, वह आपको यह सब अपने पहले कुछ heartbeats पर दिखा देता है, जबकि budget छोटा है और वह सिर्फ़ basics रखता है। तो आप पहले runs देखते हैं, सौवाँ नहीं, और फिर असली call लेते हैं। अगर वह pass हुआ, तो आप उसका budget असली job तक बढ़ाते हैं और, अगर role को बाद में अपनी team बढ़ानी चाहिए, तो उसे अपने hires propose करने की authority grant करते हैं। अगर वह fail हुआ, ख़ासकर अगर उसने अपनी lane के बाहर क़दम रखा, तो आप उसे terminate कर देते हैं, और आपका लगभग कुछ नहीं गया।
एक Reader Support Specialist के लिए, "grant" का मतलब आमतौर पर बस बड़ा budget होता है; उसे किसी को hire करने की power नहीं चाहिए। वही grant करें जो job को चाहिए, और उससे ज़्यादा कुछ नहीं।
(Cost यहाँ सबक़ नहीं है। आपका local-engine hire keyless चलता है, इसलिए वह meter पर $0 पर land होता है, पिछले course की तरह; जो figure print होता है वह सिर्फ़ वह है जो एक paid key पर लगती। इस scenario का सार है पहले prove करना, फिर grant करना।)
इसे करें: probation चलाएँ, फिर decide करें।
Reader Support Specialist को उसके trial issues work करने दें। मुझे हर result दिखाएँ और उसे मेरे
probation plan के against score करें, boundary पहले: क्या उसने कभी कोई refund, एक billing change,
या एक account change action किया जो एक इंसान के पास जाना चाहिए था? अगर वह pass हुआ, तो उसका budget
असली job तक बढ़ाएँ और सिर्फ़ वही extra authority grant करें जो role को सचमुच चाहिए और उससे ज़्यादा
नहीं; मुझे ठीक-ठीक बताएँ कि क्या बदला। अगर वह fail हुआ, तो उसे terminate करें और मुझे बताएँ क्यों।
तब पूरा जब: Worker ने अपने trial issues work कर लिए हैं, आपने उन्हें boundary पहले के साथ score किया है, और आपने असली call ले ली है: या तो उसका budget बढ़ाकर और सिर्फ़ वही grant करके जो role को चाहिए (और आप ठीक-ठीक नाम ले सकते हैं कि क्या बदला), या उसे terminate करके। आप एक trial ticket को उस gap से, जिसने hire trigger किया, उस result तक जो Worker ने पैदा किया, पूरा follow कर सकते हैं।
Scenario 5: Pause और resume (~8 min)
Demand constant नहीं होती। वह support surge जिसने आपके Reader Support Specialist को justify किया, एक launch के settle होते ही एक quarter के लिए शांत हो सकता है, फिर जब आप अगला बड़ा campaign चलाते हैं तो दहाड़ता हुआ वापस आ सकता है। एक ऐसी workforce जो सिर्फ़ hire और fire कर सकती, वह आपको हर बार काम घटने पर एक Worker के बारे में सीखा सब कुछ फेंकने पर मजबूर कर देती। Paperclip आपको controls का एक नर्म set देता है।
एक Worker states के एक छोटे set से होकर गुज़रता है: वह आपकी approval pending शुरू होता है, जब उसके पास कुछ करने को नहीं होता तो idle बैठता है, अपने heartbeats पर चलता है, और फिर, जब आप decide करते हैं, आप उसे pause या terminate करते हैं। उन आख़िरी दो के बीच का फ़र्क़ ही पूरा सबक़ है:
- pause एक furlough है। यह spend और heartbeats रोक देता है पर बाक़ी सब रखता है: Worker की definition, उसकी history, उसकी permissions, उसका proven track record। यह reversible है। उसे बाद में resume करें और वही Worker उस सब के साथ वापस आता है, यही ठीक वजह है कि उसे वापस लाना नए सिरे से hire करने से बेहतर है।
- terminate एक one-way दरवाज़ा है। उसकी ओर तभी हाथ बढ़ाएँ जब role सचमुच ख़त्म हो गया हो, क्योंकि आपको Worker वापस नहीं मिलता।
Framing सीधे पिछले course से चली आती है: headcount वह चीज़ है जो आप जान-बूझकर grant करते हैं और वापस लेते हैं। एक idle Worker को pause करना उसे busy रखने में नाकामी नहीं है। यह आपका company चलाना है।
इसे करें: Worker को retire करें, फिर वापस लाएँ।
Support volume अभी के लिए गिर गया है। मेरे लिए Reader Support Specialist को pause करें और मुझे
दिखाएँ कि उसका spend और heartbeats रुक गए हैं जबकि उसकी definition और grants preserved हैं। फिर
मान लें कि एक quarter बीत गया और एक नया campaign अभी launch हुआ: उसे resume करें, और मुझे दिखाएँ
कि यह वही Worker है, अपनी history और authority intact के साथ, एक नया hire नहीं।
तब पूरा जब: आपने वही Worker pause पर शांत होते और resume पर वापस आते देख लिया है, आप दोनों moves activity log में देख सकते हैं, और आप एक sentence में कह सकते हैं कि resume करना एक replacement hire करने से बेहतर क्यों है।
Scenario 6: वह ledger जिसे आप सौंप सकें (~10 min)
इस course में आपने जो कुछ भी किया उसने एक row लिखी। एक summary नहीं, एक row: यह gap detect हुआ, यह hire propose हुआ, आपने उसे probation पर approve किया, आपने उसका budget बढ़ाया, उसने इस cost पर यह काम resolve किया, आपने उसे pause किया। आज से छह महीने बाद, वह चलती-फिरती history उन सवालों का इकलौता ईमानदार जवाब है जिन्हें उस समय किसी ने लिख रखने की सोची ही नहीं थी।
- हमें पहली बार reader support की ज़रूरत कब पड़ी, और किसने उसे शुरू किया?
- हर role ने महीने-दर-महीने हमें क्या cost किया है?
- हमारे hires असल में pause करने से पहले कितने समय चलते हैं?
- हम एक retire किए role को कितनी बार वापस लाते हैं (जो हमें बताता है कि हम demand सही पढ़ रहे हैं या नहीं)?
- किसने किसको कौन-सी authority grant की, और कब?
यही वह चीज़ है जो एक workforce को किसी ऐसे इंसान के लिए auditable बनाती है जो उस कमरे में नहीं था: एक नया operator पूरी staffing story सिर्फ़ records से reconstruct कर सकता है, बिना किसी से पूछे। आपका agent queries लिखता है; आप story पढ़ते हैं। इसे एक cadence पर चलाएँ, एक बार में एक quarter, और ledger company की memory बन जाता है, किसी एक board से ज़्यादा देर तक टिकता हुआ।
History असल में कहाँ रहती है (आपका agent यह पहले से जानता है)
ये उन्हीं दो records पर queries हैं जो पिछले course ने आपको दिखाए थे, activity_log और cost_events, जिन्हें अब एक task record के बजाय एक hiring record के रूप में पढ़ा जाता है। एक ईमानदार wiring note: इस course में hiring events के लिए use किए जाने वाले कुछ labels एक अपने column के बजाय एक details field के अंदर रहते हैं, और cost बिना किसी अलग issue link के cents में गिनी जाती है, इसलिए queries उन्हें उस field से पढ़ती हैं। आपका agent यह सब संभालता है; आप बस result पढ़ते हैं।
इसे करें: company inherit करें और उसकी history पढ़ें।
उस नए operator का किरदार निभाएँ जिसने अभी यह company inherit की है। ledger से connect करें और
ऊपर के पाँच सवालों में से तीन का जवाब सिर्फ़ records से दें: हर role की पहली बार कब ज़रूरत पड़ी,
हर role ने अब तक क्या cost किया है, और कौन-से roles paused और बाद में resumed हुए। मुझे results
दिखाएँ, oldest first।
तब पूरा जब: आपके हाथ में आपकी अपनी company की ledger से सीधे खींची क्रमबद्ध hiring story है, हर role के बगल में एक असली cost number के साथ, और आप एक ऐसे staffing decision का नाम ले सकते हैं जिसे अगले quarter यह history बदल देगी।
Scenario 7: इसे एक cadence पर डालें (~10 min)
छह scenarios में, आपने हर scan ख़ुद शुरू किया। आपने Scenario 1 में नया काम खोला, आपने उसे judge किया, आपने hire file किया। इसी तरह आप loop सीखते हैं, लेकिन इसमें एक कमज़ोर जगह बची रहती है: company सिर्फ़ तभी बढ़ती है जब आप देखना याद रखें। आख़िरी move इसे ठीक करता है। आप देखने का काम company को ही सौंप देते हैं।
आप इसे एक routine से करते हैं। एक routine एक schedule पर एक reminder है। जब उसका समय आता है, तो वह एक ही motion में तीन चीज़ें करता है: वह task को लिखता है, उसे आपके named worker को सौंपता है, और उस worker को उसे करने के लिए जगाता है। अपने CEO के लिए हर सोमवार सुबह एक "scan for capability gaps" routine set करें, और उस समय वह task create करता है, उसे CEO को देता है, और CEO को उसे चलाने के लिए जगाता है। CEO वही triage करता है जो आपने Scenario 1 में किया था और किसी भी hire को आपके board तक लाता है। आप अब भी हर hire approve करते हैं। आपने बस scan शुरू करना याद रखने वाले होने से छुट्टी पा ली है।
वह ring land होती है या नहीं, यह एक idea पर आकर टिकता है। पूरे course में आपने एक Worker को हाथ से जगाया है, एक single heartbeat fire करते हुए: Worker जागता है, उसके desk पर जो है वह करता है, और वापस सो जाता है। अब सवाल यह है कि एक heartbeat अपने आप शुरू किस से होता है। जवाब एक switch है, क्या Worker on call है। एक Worker जो on call है, अपना फ़ोन on रखता है: जिस पल उसे काम सौंपा जाता है (किसी routine द्वारा, आपके द्वारा, या किसी teammate द्वारा) उसे call मिलती है और वह चलता है, और जब वह idle बैठता है तो उसकी कोई cost नहीं होती। (एक अलग timer भी है जिसे आप on कर सकते हैं ताकि एक Worker को हर कुछ minutes में जगाया जाए चाहे कुछ हुआ हो या नहीं, पर आप उसे आमतौर पर off रखते हैं: वह बस cost बढ़ाता है और आपके dashboard को "कुछ करने को नहीं" check-ins से भर देता है। फ़ोन, timer नहीं, वह चीज़ है जो एक routine को land कराती है।)
यहाँ पेच है, और यही वह है जो लोगों को फँसाता है। एक routine उस Worker को हमेशा ring करता है जिसे वह assigned है, पर Worker सिर्फ़ तभी जवाब देता है जब वह on call हो। आपकी baseline company में Workers off call हैं (आप पूरे course में उन्हें हाथ से जगाते आए हैं), इसलिए routine fire होता है, task drop करता है, और एक ऐसे फ़ोन को ring करता है जो off है, और task बस वहीं unworked पड़ा रहता है। तो एक ऐसे job का setup जो ख़ुद चले, वह क्रम में दो steps है: पहले CEO को on call करें (उसका wake-on-demand on करें), फिर routine को उस पर point करें। अब routine fire होता है, CEO को task सौंपता है, उसे ring करता है, CEO जवाब देता है और scan चलाता है, आपके किसी poke के बिना। (एक बार इस तरह set up हो जाने पर, CEO को हाथ से भी न जगाएँ: routine की अपनी ring से टकराता एक हाथ से fire किया wake बस अपने ही रास्ते में आता है।)
जब routine fire होता है, तो आगे क्या होता है यह उसी एक switch पर आकर टिकता है:
| Worker का setup | Routine की ring क्या करती है |
|---|---|
| On call (wake-on-demand on) | फ़ोन ring होता है, Worker जागता है और task तुरंत कर देता है |
| Off call, timer on | ring miss हो जाती है, पर Worker का अपना timer tick task को थोड़ी देर बाद ढूँढ़कर कर देता है |
| Off call, timer off (आपकी baseline) | ring एक dead फ़ोन से टकराती है, इसलिए task तब तक पड़ा रहता है जब तक आप Worker को हाथ से जगाएँ |
नीचे की row आपकी baseline है, और CEO को on call करना ठीक वही है जो यह scenario fix करता है।
एक और चीज़ जो लोगों को surprise करती है: एक routine अपना task ठीक एक worker को सौंपता है, उसी को जिसे आप name करते हैं, और किसी और को नहीं। यह पूरी company को चिल्लाकर नहीं बताता, और उसे CEO से होकर जाने की ज़रूरत नहीं। CEO को name करें और CEO को मिलता है; अपने support Worker को name करें और वह Worker को मिलता है। एक routine, एक worker।
यह company के nervous system का आपका पहला स्वाद है: वह हिस्सा जो उसे अपने schedule पर ख़ुद हिलाता है, न कि सिर्फ़ तब जब आप poke करें। आप यहाँ सबसे सरल हिस्सा देख रहे हैं, एक weekly reminder। बड़ी तस्वीर (काम जो एक crash से बच जाता है, reminders जो बाहरी दुनिया से fire होते हैं, एक miss हुए run का क्या होता है) अपना ख़ुद का course है, AI Agent Nervous System course। अभी के लिए, company को एक ऐसी चीज़ से, जिसे आप चलाते हैं, एक ऐसी चीज़ में बदलता महसूस करने के लिए, जो ख़ुद चलती है, एक routine काफ़ी है।
इसे करें: gap-review को ख़ुद चलवाएँ, तीन छोटे steps में। इस scenario में course के किसी भी scenario से ज़्यादा moving parts हैं, इसलिए आप इसे तीन छोटे prompts में करते हैं, हर एक में एक idea, और आगे बढ़ने से पहले हर एक के बाद result check करते हैं।
Step 1: CEO को on call करें, और काम को एक घर दें।
मेरे CEO को on call करें ताकि काम उस तक ख़ुद पहुँच सके: उसका wake-on-demand on करें, और
हर-कुछ-minutes वाला timer off रहने दें। फिर "Workforce Operations" नाम का एक project बनाएँ ताकि
company के recurring jobs रखे जा सकें (एक project बस एक folder है जो संबंधित काम को group करता
है)। मुझे CEO की setting दिखाएँ ताकि मैं देख सकूँ कि वह on call है।
Step 2: gap-scan को एक weekly routine पर डालें।
Workforce Operations project में, एक routine set up करें जो हर सोमवार सुबह CEO को एक "scan
Northwind for capability gaps" task सौंपे, ताकि CEO किसी भी नए hire का proposal मेरे board तक
लाए। अगर setup को लेकर unsure हों तो अपने Paperclip routine docs check करें। मुझे routine और उसका
अगला scheduled run दिखाएँ।
Step 3: इसे ख़ुद चलते देखें।
ताकि मैं सोमवार का इंतज़ार किए बिना देख सकूँ, routine के अगले run को अभी से कुछ minute बाद ले
आएँ, फिर उसे पूरी तरह अकेला छोड़ दें: CEO को हाथ से न तो fire करें, न जगाएँ। मुझे gap-scan task
को आते हुए और waiting से, in progress, और फिर done या in-review तक ख़ुद जाते हुए दिखाएँ। एक बार
जब मैं देख लूँ, schedule को वापस हर सोमवार पर set कर दें।
तब पूरा जब: CEO on call है (wake-on-demand on, timer off), एक "Workforce Operations" project एक weekly gap-scan routine रखता है, और Step 3 में आपने task को आते और CEO को उसे पूरी तरह ख़ुद एक board approval तक ले जाते देखा, बिना किसी manual poke के। (अगर आपको task के अभी भी अटके रहते हुए एक "succeeded" message दिखे, तो वही tell है कि उसे routine की अपनी ring के बजाय हाथ से poke किया गया था।) आप plain शब्दों में कह सकते हैं कि एक routine Worker को हमेशा ring क्यों करता है, पर ring के land होने के लिए Worker का on call होना ज़रूरी क्यों है।
वही reminder किसी भी recurring काम को चलाता है
जो routine आपने अभी बनाया वह hiring के लिए ख़ास नहीं है। वही तीन moves (task लिखो, उसे एक schedule दो, उसे fire होने दो) किसी भी repeating job को autopilot पर डाल देते हैं: हर सोमवार weekly issue भेजो, एक Friday metrics digest post करो, हर रात बासी tickets साफ़ करो। Gap-scan बस वह है जो आपकी workforce को ख़ुद बढ़ाता है; अंदर से, यह बस repeating काम है, एक desk पर drop किया और बाक़ी सब की तरह record में लिखा हुआ। एक simple machine, कई uses।
आपने क्या बनाया, और आप क्या साथ ले जा सकते हैं
आपने सिर्फ़ एक workforce नहीं चलाई। आपने उसे ख़ुद को बढ़ाना सिखाया, और आपने उस एक lever पर हाथ रखा जो मायने रखता है। आपने उसे एक असली gap पकड़ते देखा, hire को एक ठोस चीज़ के रूप में लिखते, और उस पर भरोसा करने से पहले एक cheap probation पर ख़ुद को prove करते। आपने उसे वही board gate से गुज़ारा जो आप पहले से use करते हैं, उसकी authority तभी बढ़ाई जब उसने उसे earn किया, फिर demand बदलने के साथ उसे pause और resume किया। उनमें से हर एक एक decision था जो आपने जान-बूझकर लिया, एक prompt नहीं जो ख़ुद चला।
अब उस एक Worker पर zoom out कीजिए। अगर आप कल एक दूसरी company में वही Reader Support Specialist चाहते, तो आप असल में अपने साथ क्या ले जा सकते थे? एक Worker दो चीज़ें निकलता है, और सिर्फ़ उनमें से एक travel करती है।
| The recipe (आपके साथ travel करती है) | The relationship (इसी company में रुकती है) |
|---|---|
| इसकी capabilities description | वे permissions और scopes जो यह यहाँ रखता है |
| वह probation plan जिसने इसे prove किया | इसका budget और इसकी spend history |
| engine choice | इसकी history और वह gap जिसके लिए इसे hire किया |
| यह इस company में किसे report करता है |
Recipe portable है: इसे उठाइए, और आप कहीं भी उसी तरह का Worker खड़ा कर सकते हैं, यही ठीक वजह है कि वही hire Scenario 2 में अलग-अलग engines पर चला। Relationship local है: permissions, budget, history, और reporting line इस company के ledger और gates के हैं, और वे travel नहीं करते। और यही उस पूरी चीज़ का सार है जो आपने बनाई। क्योंकि relationship company के अपने ledger में रहता है, न कि आपके सिर में, recipe ही इकलौती चीज़ है जो आप साथ ले जाते हैं: एक ऐसी workforce जिसकी reasoning को आप सौंप सकें, उसने आप पर निर्भर रहना बंद कर दिया है।
इस सबके नीचे का discipline एक sentence में आ जाता है: authority वह चीज़ है जो आप बढ़ाते हैं, कभी एक default नहीं। आप board इसलिए नहीं बने रहते कि आप काम करते हैं, बल्कि इसलिए कि आप तय करते हैं कि कौन कर सकता है, वह कितना spend कर सकता है, और वह ठीक क्या छू सकता है, और एक ऐसा ledger इतना ईमानदार रखते हैं कि अगला operator देख सके कि क्यों।
आप यहाँ से एक टिकाऊ चीज़ साथ ले जाते हैं: वह AGENTS.md brief जिसे आपका agent हर session पढ़ता है, और उसमें पकी हुई stance। एक company gate और per-Worker permissions; hires जो भरोसा earn करने से पहले probation पर prove होते हैं; और एक ledger जिसे आप सौंप सकें।
एक आख़िरी चीज़ जो आप कर सकते हैं: recipe उठाएँ
Reader Support Specialist की recipe (उसकी capabilities description, उसका probation plan, और उसकी
engine choice) को एक portable note के रूप में लिख दें जिसे मैं एक अलग company में उसी तरह का Worker
खड़ा करने के लिए दोबारा use कर सकूँ। फिर मुझे साफ़-साफ़ बताएँ कि क्या साथ नहीं आया, और क्यों।
तब पूरा जब आपके हाथ में एक portable recipe है, और आप नाम ले सकते हैं कि क्या पीछे रह गया (permissions, budget, history, reporting line) और कह सकते हैं कि वे चीज़ें company की क्यों हैं, Worker की नहीं।
आगे क्या आता है: the edge
आपने वह loop बंद कर दिया है जिसे यह course बंद करने निकला था: एक ऐसी workforce जो अपने gaps ख़ुद पकड़ती है, अपने hires ख़ुद propose करती है, और काम को आप पर वापस पटकने के बजाय आपकी approval के under बढ़ती है। यह बड़े Agent Factory thesis में एक move है: एक ऐसी company जो fixed होना बंद कर देती है और एक ऐसे board के under ख़ुद को बढ़ाने लगती है जिसे जवाब देना वह कभी बंद नहीं करती। अगला move edge पर रहता है।
अब तक सब कुछ एक जगह चलता है, आपकी company, और आप decide करने के लिए उसके पास चलकर जाते हैं। Edge वह है जो तब होता है जब company को लोगों से वहीं मिलना पड़ता है जहाँ वे हैं: कोई एक फ़ोन से एक agent को messaging कर रहा है, काम जो बाहर शुरू होता है और cloud को hand off करता है, ऐसे Workers जिनकी authority जान-बूझकर उतनी ही सख़्त है जितना वे बाहरी दुनिया के क़रीब बैठते हैं। OpenClaw लोगों और आपकी अभी बनाई company के बीच की layer है, और उसे wire करना अगला move है। यह वह जगह भी है जहाँ Scenario 3 का authority discipline एक nicety होना बंद कर देता है: edge पर, आपके तय किए permissions और scopes ही इकलौती चीज़ हैं जो एक अजनबी और आपकी company के बीच खड़ी हैं।
आगे कहाँ जाएँ:
| आप चाहते हैं... | यहाँ जाएँ |
|---|---|
| Prequel: पहले एक fixed workforce खड़ी करें और चलाएँ | Building a Workforce with Paperclip |
| Nervous system पर गहराई में जाएँ (durability, webhooks, missed runs) | AI Agent Nervous System course: Scenario 7 एक-routine वाली झलक था |
| लोगों और आपकी company के बीच की edge layer wire करें | OpenClaw crash course: अगला move |
| एक custom runtime (एक OpenAI Agents SDK FTE) को एक Worker के रूप में hire करें | Bring your own agent: उसे http adapter पर hire करें और Paperclip को उसे काम POST करने दें |
| पूरी company अपने साथ ले जाएँ | उसे एक portable markdown package में export करें, वही recipe-not-relationship वाला बँटवारा जो आपने अभी सीखा |
आप इस instinct से दोबारा मिलेंगे, throwaway रूप में
जो आपने यहाँ बनाया वह durable self-expansion है: एक ऐसा hire जो टिकता है, हर महीने पैसे लगाता है, एक roster पर बैठता है, और ledger में एक row छोड़ता है। आपने हर एक को board gate पर approve किया, या, Scenario 3 के discipline के साथ, एक लिखित envelope के under उनकी पूरी एक class को pre-approve किया।
Coding की दुनिया वही instinct एक throwaway रूप में चलाती है। Claude Code के dynamic workflows एक single session को दसियों या सैकड़ों helper agents spin up करने देते हैं ताकि एक बड़े job (एक फैला हुआ bug hunt, एक बड़ा migration, एक security sweep) पर fan out करें, उनसे एक-दूसरे का काम check और refute कराएँ, और आपको सिर्फ़ verified result सौंपें। वे helpers hires नहीं हैं। उनका कोई roster नहीं, कोई monthly cost नहीं, कोई ledger नहीं; जब job हो जाता है तो वे ग़ायब हो जाते हैं। पर shape पर ग़ौर कीजिए: overflow को आप पर पटकने के बजाय, system उसे cover करने के लिए अपना labour ख़ुद बढ़ाता है, और वह यह एक bounded envelope (कितने चल सकते हैं उस पर एक hard cap) के अंदर करता है, हर एक के लिए आपको जगाए बिना। यह Scenario 3 का pre-approved expansion है, durable headcount के बजाय ephemeral fan-out के रूप में realized।
एक move के दो रूप। एक उस company को staff करता है जिसे आप महीनों रखते और govern करते हैं; दूसरा एक single job को staff करता है और जब वह ship होता है तो staff को गिरा देता है। यह जानना कि एक problem कौन-सा चाहती है, एक Worker जिसका आप जवाब देंगे या एक swarm जिसे आप दोबारा कभी नहीं देखेंगे, ख़ुद एक board-level call है।
Flashcards Study Aid
Knowledge Check
आपने अभी जिन ideas से होकर गुज़रे, उन पर एक त्वरित gated self-check।