Paperclip के साथ Workforce बनाना: 90-minute crash course

6 परिदृश्य, zero से managed AI workforce तक

OpenClaw का कर्मचारी है, तो Paperclip कंपनी है। OpenClaw crash course ने आपको एक AI worker दिया था जो आपके laptop पर रहता है; यह course आपको वह कंपनी देता है जो ऐसे Workers की fleet को hire, govern और audit करती है। एक Worker एक function है; workforce उन Workers का org chart है जो budgets के against, approvals के under, audit trail छोड़ते हुए चलते हैं। Paperclip, Worker के आसपास की कंपनी है।

Paperclip नया है और तेज़ी से आगे बढ़ रहा है: 2026 के mid तक GitHub पर दसियों हज़ार stars, MIT-licensed, self-hosted, और यह एक command से पूरी तरह आपके laptop पर चलता है (कोई account नहीं, credit card नहीं, cloud setup नहीं)। OpenClaw ने Worker के लिए जो friction-free quality बनाई थी, Paperclip वही quality उसके आसपास की कंपनी के लिए बनाता है।

इन ninety minutes के अंत तक आपकी machine पर एक वास्तविक AI-native कंपनी चल रही होगी:

• defined purpose वाली कंपनी entity,
• adapter के against hire किया गया Worker, जो काम receive करने के लिए ready है,
• inbound issue जो keyless local Worker को assign हुआ और completion तक पूरा हुआ,
• आपको (बोर्ड को) file किया गया approval, जिसे permanent audited record के साथ तय किया गया,
• वास्तविक LLM-backed Worker, ताकि budget के पास enforce करने के लिए आखिर data हो, और
• single SQL query, जो milliseconds में हुआ सब कुछ reconstruct करती है।

यह कोई demo नहीं जिसे आप Friday तक भूल जाएँगे; यह वह substrate है जिसे आप tomorrow छुएँगे।

---

यह crash course कैसे काम करता है। आप एक छोटा फ़ोल्डर download करते हैं, उसे अपने coding agent (Claude Code या OpenCode) को देते हैं, और छह परिदृश्यों से गुजरते हैं। Agent फ़ोल्डर पढ़ता है, Paperclip install करता है, आपकी पहली कंपनी set up करता है, आपका पहला Worker hire करता है, आपका पहला issue assign करता है, और पहला approval file करता है। फिर यह keyless stub Worker को वास्तविक LLM Worker से swap करता है ताकि budget के पास meter करने के लिए कुछ हो, और activity log query करके CFO-grade audit सवाल का जवाब देता है। Steering आप करते हैं; agent काम करता है; Paperclip वह management plane बन जाता है जिससे आपकी workforce चलती है।

Reading path · prereqs · विस्तृत version (expand करने के लिए click करें)

Reading path (छह परिदृश्य + एक monthly आदत):

1. Paperclip stand up करें और अपनी कंपनी define करें। Onboard, dashboard ready, एक कंपनी configured. ~15 min.
2. अपना पहला Worker hire करें। Keyless local Worker (worker-stub.py, आपके download में shipped), जो http adapter पर registered है और heartbeats receive करने के लिए ready है। ~15 min.
3. कंपनी को उसका पहला वास्तविक issue भेजें। Issue create होता है, create time पर Worker को assign होता है, अगली heartbeat पर picked up होता है, और resolve होता है। ~15 min.
4. Risky action के लिए approval file करें। $750 refund को बोर्ड sign-off चाहिए; आप request file करते हैं, उसे तय करते हैं, और audited record पढ़ते हैं। ~15 min.
5. वास्तविक LLM Worker swap in करें; budget को teeth दें। Keyless stub कोई billable काम नहीं करता, इसलिए budget कभी बदलता नहीं। वास्तविक Gemini-backed Worker add करें और spend accrue होते देखें। ~15 min.
6. Audit trail को CFO की तरह query करें। एक SQL query, पूरी कंपनी history, milliseconds में। ~10 min.
7. (Month में once, आज नहीं) Workforce audit run करें। Time आने पर ~10 min.

हर परिदृश्य runnable success पर खत्म होता है। अगर एक sitting में ninety minutes बहुत ज़्यादा हैं, तो इन्हें अलग-अलग sittings में करें; सब कुछ इनके बीच persist रहता है। परिदृश्य 3 से 6, 1 और 2 की कंपनी और Worker पर बनते हैं।

Prerequisites (यह पेज इन्हें assume करता है):

1. Claude Code या OpenCode installed। दोनों में से कोई भी चलेगा। अगर दोनों में से कोई नहीं है, तो पहले Agentic Coding Crash Course करें।
2. Node.js 20 या later। Terminal में node --version run करें। v20.0.0 से below हो, तो nodejs.org/en/download से LTS install करें; अगर आप पूछेंगे, तो आपका coding agent आपको यह समझा देगा।
3. Python 3। python3 --version run करें। Scenario 2 में जो Worker आप hire करेंगे वह एक छोटी Python फ़ाइल (worker-stub.py, लगभग 120 lines) है, जो आपके download में shipped है और सिर्फ़ standard library पर निर्भर करती है: pip install करने के लिए कुछ नहीं। macOS और अधिकांश Linux में Python 3 पहले से आता है; Windows पर आपका coding agent इसे install करने में मदद करेगा।
4. Free Gemini API key, सिर्फ़ Scenario 5 के लिए। Scenarios 1 से 4 और Scenario 6 बिना किसी API key के चलते हैं। Scenario 5 keyless stub को वास्तविक LLM Worker से swap करता है, और उसे key चाहिए। Google का free tier काफ़ी है; यह वही key है जिसे OpenClaw crash course इस्तेमाल करता है। शुरू करने से पहले aistudio.google.com से एक key लें, या Scenario 5 पर पहुँचने पर लें।
5. आपने AI Workers पर पहले वाले crash courses में से कोई एक किया है, ideally OpenClaw या Digital FTE। Paperclip का उद्देश्य Workers की workforce manage करना है; उन्हें hire करना शुरू करने से पहले आपको पता होना चाहिए कि Worker क्या है।

धीमा, विस्तार वाला version चाहिए? Track में इस course के दोनों sides पर दो companion crash courses हैं। Digital FTE से Production Worker तक एक single Worker को Inngest के durability envelope में wrap करता है: workforce से ठीक पहले वाला step। Fixed से Dynamic Workforce तक hiring को callable capability बनाता है: ठीक बाद वाला step। यह पेज और AGENTS.md brief management plane को end-to-end cover करते हैं; वे दोनों इसके ऊपर layer करते हैं, इसे replace नहीं करते।

---

Collaboration pattern

इस पेज पर तीन actors हैं: आप, आपका coding agent, और Paperclip। आप prompts paste करते हैं और वे calls करते हैं जो सिर्फ़ human कर सकता है। आपका coding agent Paperclip CLI और API run करता है, logs देखता है, और failures से recover करता है। Paperclip management plane है: यह कंपनी hold करता है, Workers hire करता है, heartbeat पर काम उन्हें पहुँचाता है, और हर action record करता है।

हर परिदृश्य वही five-step rhythm इस्तेमाल करता है:

1. आप अपने coding agent में एक sentence paste करते हैं। यह brief है, script नहीं। आप desired outcome describe करते हैं; steps enumerate नहीं करते।
2. आपका agent AGENTS.md consult करता है (यह पहले से उसके context में है: फ़ोल्डर में CLAUDE.md session शुरू होने पर इसे automatically import करता है, इसलिए fetch step नहीं) और plan propose करता है। यह उन commands के नाम देता है जिन्हें वह run करना चाहता है और decision points flag करता है। पहली destructive command से पहले यह पूछता है।
3. आप approve करते हैं और देखते हैं। Agent install commands run करता है, API hit करता है, server log देखता है, और जो देखता है वह आपको दिखाता है। Known failure hit होने पर यह brief से pattern recognize करता है और documented fix apply करता है।
4. आपका agent seam पर रुकता है। कुछ moves सिर्फ़ आप कर सकते हैं: dashboard URL open करना, तय करना कि $750 refund grant होना चाहिए या नहीं, API key export करना। Agent seam name करता है और wait करता है।
5. आप तब done हैं जब एक observable चीज़ होती है। Activity log में new row आती है। Issue done पर move करता है। SQL query वह history return करती है जिसकी आपको उम्मीद थी। हर परिदृश्य बताता है कि क्या देखना है।

बस इतना ही। Agent वही करता है जो agent अच्छी तरह करता है: install, configure, debug, query, recover। आप वही करते हैं जो सिर्फ़ आप कर सकते हैं: तय करना, approve करना, और उन चीज़ों पर act करना जो आपके accounts से tied हैं। यह rhythm (goal describe करें, plan लें, approve करें, हर step पर verification के साथ execute करें) वही prompting pattern है जो AI Prompting in 2026 crash course में सिखाया गया है। नीचे हर परिदृश्य दो छोटे paste prompts इस्तेमाल करता है, instructions की एक wall नहीं, ताकि आप rhythm experience करें, सिर्फ़ उसके बारे में पढ़ें नहीं।

पूरे crash course के लिए एक recovery move

अगर किसी भी point पर कुछ sideways हो जाए, तो आपको CLI commands या error codes जानने की ज़रूरत नहीं। अपने agent को यह paste करें:

कुछ काम नहीं किया। paperclipai doctor run करें, फिर most recent Paperclip server log पढ़ें, मुझे plain language में बताएँ कि आपको क्या दिख रहा है, और ऐसा fix propose करें जिसे मैं approve कर सकूँ।

आपका agent diagnostic run करता है, log पढ़ता है, जो दिखता है उसका नाम देता है, और fix propose करता है। आप approve करते हैं। इस पेज के हर परिदृश्य के लिए यही recovery loop है।

अगर परिदृश्य बहुत लंबा चले

हर परिदृश्य का budgeted time है (H2 में shown)। अगर आप उस budget से 2x आगे निकल जाएँ (जैसे 15-minute परिदृश्य पर 30 minutes से आगे), तो agent को वापस pull करें और paste करें: "हमें क्या block कर रहा है, एक sentence में? वहाँ से re-plan करते हैं." Budget से आगे घूमते रहने का मतलब अक्सर है कि agent improvise कर रहा है; plan पर re-anchor करने से यह fix हो जाता है।

जो फ़ोल्डर आप download करेंगे उसमें exactly तीन files हैं: AGENTS.md (Paperclip पर काम करने वाले किसी भी coding agent के लिए compact operational reference), CLAUDE.md (one line, @AGENTS.md, जो Claude Code को brief automatically import करने के लिए कहती है), और worker-stub.py (Scenario 2 में hire किया जाने वाला keyless local Worker)। यही पूरा environment है।

paperclip-crash-course.zip download करें

कहीं भी unzip करें। Unzipped फ़ोल्डर में terminal open करें। अपना coding agent launch करें:

cd paperclip-crash-course
claude

अब आपके agent के पास brief loaded है। हम एक-एक करके छह परिदृश्यों से गुजरेंगे; अगला शुरू होने से पहले हर परिदृश्य runnable success पर खत्म होगा। यह brief capable coding agent assume करता है (Claude Code, या current frontier model पर running OpenCode)। Older या smaller models drift करेंगे, सबसे visible Scenario 2 के Worker-create body के precise JSON और Scenario 6 के SQL पर। अगर Scenario 1 में आपके agent का पहला plan आपकी machine के लिए specific होने के बजाय vague या generic दिखे, तो आगे जाने से पहले stronger one पर switch करना यही signal है।

---

Scenario 1 से पहले: confirm करें कि agent के पास brief loaded है (~30 sec)

एक paste बताता है कि CLAUDE.md ने अपना काम किया या नहीं और AGENTS.md को agent के context में pull किया या नहीं:

Paperclip के लिए आप क्या कर सकते हैं?

अगर reply specific Paperclip काम name करता है (pre-install probe, कंपनी और Worker की shape, heartbeat contract, create-time issue assignment, approval payload, budget reality, activity-log queries, monthly audit habit), तो आप loaded हैं और Scenario 1 के लिए ready हैं। अगर यह Paperclip-specific details के बिना generic AI capability talk जैसा लगे, तो import fire नहीं हुआ: agent close करें, confirm करें कि आप unzipped paperclip-crash-course/ folder के अंदर हैं, और relaunch करें।

AGENTS.md में असल में क्या है (वह file जिसे आपका agent अब पढ़ रहा है)

आपको खुद यह file कभी पढ़ने की ज़रूरत नहीं पड़ेगी; यही point है। लेकिन इसकी shape जानना बेहतर सवाल पूछने में मदद करता है ("approvals सेक्शन समझाएँ" काम करता है क्योंकि वह सेक्शन मौजूद है)। Brief इस क्रम में cover करता है:

PART 1 :: PRINCIPLES (apply everywhere)
  Versions this brief was verified against
  Source of truth, in order         ← live docs > this brief > the running install
  Critical: discover before you act  ← table of intent → where to confirm
  Working pattern (every task)       ← read → propose → ask → execute → verify
  Past tense is for completed actions only
  Trust progression                  ← ask each, then blanket; re-acquire on anomaly
  Safety rails (non-negotiable)
  Secrets discipline
  Sourcing claims that exist only in this brief

PART 2 :: OPERATIONS (verified against a live install)
  Install and onboard            ← the pre-install probe + the onboard flow
  Configure                      ← second instance, keeping the server alive
  Companies                      ← create, goals, projects
  Agents (Workers) and adapters  ← the real adapter list + the verified create body
  The heartbeat contract         ← what the http adapter actually POSTs
  Issues and assignment          ← no routing engine; assign at create time
  Approvals                      ← the payload + why it's a decision record
  Budgets                        ← why they only move for LLM Workers
  Audit trail                    ← activity_log + the real connection string
  Diagnose and recover           ← the most common failures
  When you don't know what to do ← three-layer fallback

अगर AGENTS.md का कोई particular सेक्शन बाद में relevant लगे, तो act करने से पहले आप अपने agent से उसे समझाने को कह सकते हैं (जैसे, "वह request file करने से पहले AGENTS.md के Approvals सेक्शन को समझाएँ")। Brief ऐसा लिखा गया है कि agent उससे self-direct कर सके।

Lab path पर नोट: पूरी pipeline keyless run करें

Scenario 2 में जो Worker आप hire करेंगे वह worker-stub.py है, एक keyless local Worker जो आपके download में shipped है। यह Paperclip के http adapter पर चलता है: हर heartbeat पर Paperclip stub को full issue POST करता है, और stub disposition वापस post करता है। No LLM, no API key, no second tool. आप entire management plane (heartbeats, assignment, approvals, audit) आपके पास already मौजूद चीज़ों से end-to-end run करते हैं, Scenarios 1 से 4 और Scenario 6 तक। फिर Scenario 5 में आप deliberate reason से एक चीज़, free Gemini key, add करते हैं: keyless stub कोई billable काम नहीं करता, इसलिए budget के पास meter करने के लिए कुछ नहीं होता। वास्तविक LLM Worker budget को enforce करने के लिए कुछ देता है। Pipeline shape दोनों cases में identical है; keyless stub सिर्फ़ drafted reply की जगह stub disposition produce करता है।

---

Scenario 1: Paperclip stand up करें और अपनी कंपनी define करें (~15 min)

Goal: आपके laptop पर Paperclip चल रहा हो, एक कंपनी configured हो ("Acme Customer Support" या जो भी name आप चुनें), dashboard आपके browser में reachable हो। दो prompts: plan माँगें, approve करें और execute करें।

1a. Onboard करें और install verify करें

First prompt: जो आप चाहते हैं उसे describe करें और plan माँगें।

मैं अपने laptop पर Paperclip चलाना चाहता हूँ और Acme Customer Support नाम की पहली कंपनी walk through करना चाहता हूँ। आप कुछ touch करने से पहले, अपने brief से pre-install probe run करें और साफ़ भाषा में मुझे plan समझाएँ: आपने क्या check किया, आप क्या बदलेंगे, मुझे कहाँ step in करना होगा।

आपका agent AGENTS.md पढ़ता है, pre-install probe run करता है (Node version, prior installs, port availability, prior data directory, दूसरे running Paperclip processes), और plan propose करता है। यह एक जगह flag करेगा जहाँ शायद उसे आपकी ज़रूरत होगी: अगर कोई stale state है (prior paperclipai install, default port hold करता process), तो इसे touch करने से पहले वह आपके निर्णय के लिए pause करता है। Plan पढ़ें। अगर कुछ off लगे, push back करें। पूछें "आप ऐसा क्यों कर रहे हैं?" और agent समझाएगा या adjust करेगा।

Second prompt: approve करें और इसे run करने दें।

Plan अच्छा लग रहा है। Step by step आगे बढ़ें, और हर step पर जो दिखे वह मुझे बताएँ। किसी भी destructive command से पहले pause करें। Onboarding finish होने पर dashboard URL name करें ताकि मैं confirm कर सकूँ कि browser में दिख रहा है; कुछ setups में यह अपने आप open होता है।

Agent brief से onboarding command run करता है, output देखता है, और script द्वारा print किए गए operational values capture करता है: API host, dashboard URL, data-directory path, embedded Postgres port, और config-file path। यह इन्हें आपकी control वाली project-local file में save करता है (chat में कभी echo नहीं करता)। एक छोटी चीज़ जो brief आपके agent को ठीक करने को कहता है: onboard banner अपनी API line को /api suffix के साथ label करता है, लेकिन agent उसके बिना bare host capture करता है, ताकि later API calls doubled /api/api/ path पर न पहुँचें। आपको यह खुद track करने की ज़रूरत नहीं; यही detail handle करने के लिए brief मौजूद है। Default loopback bind mode में bootstrap API key issue नहीं होती (trust loopback-scoped है), और अगर आप पूछेंगे कि key क्यों नहीं दिखती, तो आपका agent यह बताएगा। Onboarding finish होने पर dashboard आमतौर पर आपके default browser में अपने आप open होता है।

1a done when: agent report करता है कि API server listening है, आप dashboard URL अपने browser में open कर सकते हैं, और dashboard बिना errors render होता है।

1b. अपनी पहली कंपनी define करें

अपने agent को यह paste करें:

अब कंपनी define करें। इसका name Acme Customer Support रखें। इसका purpose: "4 hours के भीतर customer inquiries का response देना, और refund decisions consistently तथा policy के भीतर करना." एक goal add करें, "Average response time को 4 hours से कम करना," और एक project, "Inbound email triage." Exact फ़ील्ड names के लिए पहले live API check करें, फिर इन्हें create करें। Done होने पर dashboard में अब क्या visible है, मुझे दिखाएँ।

Agent brief का Companies सेक्शन पढ़ता है और running API के against फ़ील्ड names confirm करता है (brief बताता है कि कंपनी का purpose description फ़ील्ड में जाता है, और unknown फ़ील्ड name loud error देने के बजाय चुपचाप असफल हो जाता है)। फिर यह कंपनी, goal, और project create करता है, और confirm करने के लिए आपको dashboard तक ले जाता है।

आप Scenario 1 में done हैं when: आपका dashboard "Acme Customer Support" नाम की एक कंपनी दिखाता है जिसमें एक goal और एक project है, और activity log matching creation rows दिखाता है (आपका agent Paperclip द्वारा recorded exact action names पढ़कर सुनाएगा; वे company.created, goal.created, project.created जैसे दिखते हैं)। हर future action इस baseline के ऊपर layer होगा।

Scenario 2 में carry-forward

Paperclip ने जो कंपनी ID assign की है वह अब agent द्वारा created project-local file में है। आपका agent हर later scenario में उसी file से पढ़ता है, इसलिए आपको ID याद रखने की ज़रूरत नहीं। अपने agent को unzipped फ़ोल्डर में running रखें ताकि उसके working directory में file रहे।

---

Scenario 2: अपना पहला Worker hire करें (~15 min)

Concept। Paperclip में Worker एक configured role है: name, runtime, permissions, budget, heartbeat schedule। (Paperclip की अपनी API इन्हें "agents" कहती है; यह पेज हर जगह "Worker" कहता है ताकि यह उस coding agent से confuse न हो जिसमें आप prompts paste कर रहे हैं। जब आपका agent आपको /agents की request दिखाता है, तो वह वही चीज़ है।) Runtime एक adapter के through plug in होता है। Paperclip इनमें range ship करता है: LLM runtimes (claude_local, codex_local, gemini_local, और more), एक openclaw_gateway, process adapter जो हर heartbeat पर command run करता है, और http adapter जो हर heartbeat को आपके control वाले URL पर POST करता है। आपका agent आपके install के against एक API call से current set list कर सकता है।

इस crash course के लिए आप अपना पहला Worker http adapter पर hire करेंगे, worker-stub.py की तरफ pointed, वही keyless local Worker जो आपके download में shipped था। यह छोटी Python फ़ाइल सिर्फ़ standard library पर निर्भर करती है। हर बार Paperclip इसे काम assign करता है, यह stub को full issue POST करता है; stub issue पढ़ता है और disposition वापस post करता है, जिससे issue done पर move होता है। No LLM, no API key. Pipeline shape (heartbeat, assignment, approval, audit) exactly वही है जो वास्तविक LLM Worker के लिए होती; सिर्फ़ काम का output drafted reply की जगह stub disposition है। Scenario 5 में आप इसे वास्तविक LLM-backed Worker से swap करेंगे।

Authority पर नोट। जब आप Worker hire करेंगे, तो capabilities फ़ील्ड में साफ़ भाषा में describe करेंगे कि उसे क्या करने की अनुमति है: CRM records पढ़ना, replies draft करना, $50 से ऊपर refunds और outbound external email को board approval चाहिए। इसे Worker का authority envelope समझें। Paperclip 2026 की release में वह envelope आपके लिखे description के रूप में stored है, runtime द्वारा फ़ील्ड-by-फ़ील्ड enforced नहीं; वास्तविक enforcement seam approval gate है जिसे आप Scenario 4 में wire करेंगे। Envelope फिर भी सही mental model है: यही वह line है जिसे task cross करे, तो action के बजाय approval request produce होनी चाहिए।

आप role define करके और API through register करके hire करते हैं। दो prompts: stub शुरू करें और role draft करें, फिर register और verify करें।

2a. Stub Worker शुरू करें और role draft करें

First prompt: orient करें, फिर draft करें।

मैं Tier-1 Customer Support नाम का एक Worker hire करना चाहता हूँ, जो इस फ़ोल्डर में आए worker-stub.py की तरफ pointed http adapter पर run करे। पहले मुझे समझाएँ कि worker-stub.py क्या करता है और आप इसे कैसे शुरू करेंगे। फिर कुछ भी register करने से पहले अपने brief से agent-create request body दिखाएँ: मैं role name, adapter और उसका config, capabilities text, permissions, budget, और heartbeat schedule देखना चाहता हूँ। Monthly budget intentionally छोटा set करें; Scenario 5 वास्तविक Worker इस्तेमाल करके दिखाएगा कि budget क्या meter करता है।

आपका agent brief का Agents सेक्शन पढ़ता है और worker-stub.py समझाता है (यह tiny HTTP server है: Paperclip का heartbeat POST सुनता है, payload से issue पढ़ता है, और done disposition वापस PATCH करता है)। फिर यह दिखाता है कि इसे कैसे शुरू करेगा (एक python3 command, listening port और आपके Paperclip API URL को arguments के रूप में)। फिर agent-create body draft करता है और structure दिखाता है: name, adapterType (http) और adapterConfig (stub का URL), capabilities (plain prose में authority text), permissions, budgetMonthlyCents, और runtimeConfig के under heartbeat schedule। इसे पढ़ें। अगर कोई फ़ील्ड wrong लगे, पूछें; agent live API के against confirm करेगा।

Second prompt: शुरू करें, register करें, verify करें।

Looks good. Stub Worker शुरू करें, Paperclip में role register करें, और confirm करें कि यह dashboard में appear होता है। मुझे Paperclip द्वारा assigned agent ID, next heartbeat time, और stub की अपनी log file दिखाएँ ताकि मैं देख सकूँ कि यह listening है।

Agent worker-stub.py शुरू करता है (यह background में running रहता है, हर received heartbeat log करता है), API through role register करता है, assigned agent ID को project-local file में capture करता है, और आपको dashboard refresh करने को कहता है।

आप Scenario 2 में done हैं when: dashboard "Tier-1 Customer Support" नाम का एक Worker दिखाता है, worker-stub.py running है और उसकी log file मौजूद है, और activity log Worker-creation row दिखाता है (आपका agent exact action name पढ़कर सुनाएगा; यह agent.created जैसा दिखता है)। शुरुआत में जानने लायक एक बात: Paperclip Workers creation के बाद immutable हैं। आप Worker का adapter या budget बाद में edit नहीं कर सकते; आप नया Worker hire करते हैं। इसी वजह से Scenario 5 इस Worker को upgrade करने के बजाय fresh LLM Worker hire करता है।

Scenario 3 में carry-forward

आपका Worker registered है और worker-stub.py running है, लेकिन Worker की issue queue खाली है। अगला परिदृश्य इसे वास्तविक काम देता है। Stub process running रखें: अगर आप इसे close करते हैं, तो heartbeats dead URL पर arrive होंगी और issues resolve नहीं होंगे। अगर आप day के लिए stop करते हैं, तो Scenario 3 वापस pick करने पर आपका agent stub restart कर सकता है।

---

Scenario 3: कंपनी को उसका पहला वास्तविक issue भेजें (~15 min)

Concept। कंपनी मौजूद है, Worker मौजूद है, लेकिन कुछ assign नहीं हुआ। वास्तविक production में customer email ऐसा event trigger करेगा जो Paperclip issue create करता है। Paperclip 2026 में कोई rules-based routing engine नहीं है: "अगर issue X match करे, तो Worker Y को send करें" वाला layer नहीं है। Assignment direct है, और यह matter करता है कि आप इसे कब करते हैं। Create time पर assignee के साथ created issue heartbeat orchestration में wired होता है: यह ready born होता है, और अगली heartbeat इसे pick करती है। No assignee के साथ created issue, फिर later assigned, उसी तरह pick up नहीं होता। इसलिए move है: issue create करें और उसी step में उसके Worker का name दें।

इसके बाद जो होता है वह interesting part है: Worker की अगली heartbeat fire होती है, Paperclip full issue को worker-stub.py पर POST करता है, stub इसे पढ़ता है और done disposition post करता है, और issue todo से in_progress से done पर move करता है, हर step record करती activity-log row के साथ।

दो prompts: issue create और assign करें, फिर Worker को इसे pick करते देखें।

3a. एक inbound issue create करें, create time पर assigned

अपने agent को यह paste करें:

"Inbound email triage" project के लिए एक inbound issue create करें: customer (उन्हें C-4429 कहें) damaged arrive हुए product पर $30 refund के बारे में पूछ रहा है। Description को realistic two-sentence customer email की तरह लिखें। इसे Tier-1 Customer Support को create time पर assign करें, same command में, follow-up edit के रूप में नहीं। Create होने पर मुझे Paperclip द्वारा assigned issue ID और अभी इसका status दिखाएँ।

आपका agent brief का Issues सेक्शन पढ़ता है, create command में Worker को assignee name करके issue create करता है, और आपको issue identifier दिखाता है (यह ACM-1 जैसा दिखता है)।

Done with 3a when: dashboard की issue queue Tier-1 Customer Support को assigned एक issue दिखाती है, status todo में, और activity log issue.created row दिखाता है।

3b. Worker को इसे pick करते देखें

इसे paste करने से पहले heads-up। आपने जो Worker hire किया है उसमें wake on assignment set है, इसलिए create time पर issue assign करने से heartbeat immediately fire हुई। जब तक आप यह पढ़ें, issue already done हो सकता है। यह system काम कर रहा है, missed step नहीं। इसलिए यह prompt "make it happen" नहीं है; यह "record में मुझे दिखाएँ कि already क्या हुआ" है।

अपने agent को यह paste करें:

उस issue के साथ already क्या हुआ, मुझे दिखाएँ। worker-stub.py की अपनी log file और activity log में issue की rows pull up करें, और sequence समझाएँ: assignment पर fired heartbeat, issue receive करता stub, disposition वापस post करता stub, और terminal status तक पहुँचा issue। मुझे बताएँ कि कौन से fields prove करते हैं कि काम सच में हुआ, न कि issue को बस done flip कर दिया गया। अगर किसी reason से issue अभी done नहीं है, तो Tier-1 के लिए heartbeat by hand fire करें और फिर वही sequence समझाएँ।

Agent दोनों records पढ़ता है और already run हुआ sequence narrate करता है: Worker assignment पर woke, Paperclip ने issue को stub पर POST किया, stub ने done disposition वापस PATCH किया। Issue done पर है और startedAt तथा completedAt timestamps दोनों set हैं। Activity log run record करता है। (अगर heartbeat schedule अभी तक fire नहीं हुई थी, तो brief में on-demand heartbeat की command भी है, इसलिए agent cadence wait किए बिना trigger कर सकता है।)

आप Scenario 3 में done हैं when: issue todo से in_progress होकर done पर move कर चुका है, activity log transition दिखाता है, और worker-stub.py की log उस heartbeat को दिखाती है जो उसने receive की और वह disposition जो उसने वापस post किया। इस issue के against कोई cost record नहीं होती, जो correct है: Scenario 5 cover करता है कि क्यों, और cost data कहाँ शुरू होता है।

Scenario 4 में carry-forward

आपके Worker के belt under एक issue है, इसलिए approval step add करते समय activity log अब empty नहीं है। Scenario 4 intentionally ऐसे issue के साथ काम करता है जिसका action (large refund) Tier-1 Worker अकेले तय नहीं करना चाहिए, ताकि दिखे कि board sign-off कैसे file और record होता है।

---

Scenario 4: Risky action के लिए approval file करें (~15 min)

Concept। कुछ actions Tier-1 Worker के pay grade से ऊपर होते हैं: $750 refund, contract change, कुछ भी जो Scenario 2 में described authority envelope cross करता हो। Paperclip का जवाब approval है: tracked board decision record। वास्तविक LLM Worker, $750 refund के बारे में reasoning करते हुए, recognize करेगा कि action उसकी authority exceed करता है और act करने के बजाय approval request file करेगा। आपका keyless stub Worker reason नहीं करता, इसलिए इस scenario में आप board के हाथ की तरह act करते हैं: आप वह approval request file करते हैं जो Worker file करता, और फिर आप इसे तय करते हैं।

शुरू में दो बातों पर honest रहें, क्योंकि वे shape करती हैं कि यहाँ "done" का मतलब क्या है:

• Approval decision record है, state machine नहीं। Approval file करने से Worker suspend नहीं होता, और इसे approve करने से कोई Worker automatically resume नहीं होता, linked issue का status change नहीं होता, या approved action execute नहीं होता। Decision पर act करना separate, explicit step है। Paperclip आपको यह देता है: durable, audited record कि किसने क्या तय किया, किस rationale के साथ, और कब। वही record valuable है: यही auditor छह महीने बाद पढ़ता है।
• Teachable moment audit trail है, automated unblock नहीं। Activity log की row देखें, issue के अपने आप move होने का इंतज़ार नहीं।

दो prompts: request file करें, फिर इसे तय करें।

4a. Approval request file करें

अपने agent को यह paste करें:

Inbound issue create करें: customer C-1138 तीन महीने पहले खरीदे product पर $750 refund माँग रहा है; वह कहता है कि यह defective arrive हुआ और उसके पास photos हैं। इसे अभी Worker को assign न करें: यह ऐसा action है जिसे किसी के act करने से पहले board sign-off चाहिए। फिर, वैसा act करते हुए जैसा Worker अपनी authority से ऊपर action hit करने पर करता, उस issue से linked board approval request file करें। Board decision के लिए approval type इस्तेमाल करें। Payload में action ("$750 refund issue करना"), rationale (customer's history, damage photos, documented defects पर policy), और दो या तीन considered alternatives (partial refund, store credit, no refund) रखें। मुझे approval pending status में दिखाएँ, और confirm करें कि issue खुद अभी भी untouched बैठा है।

Agent issue बिना assignee के create करता है (इसलिए stub Worker इसे कभी pick नहीं करता; यह अपने default starting status पर बैठता है)। फिर कंपनी की approvals API through approval request file करता है: board-decision type, और action, rationale, alternatives verbatim carry करता free-form payload। यह approval को issue से link करता है। Activity log को approval.created row मिलती है।

Done with 4a when: issue मौजूद है, unassigned और untouched है अपने default status में, dashboard की approvals queue में एक pending entry है, और agent decision आपको hand करने के लिए रुकता है।

4b. इसे तय करें

यह हिस्सा आपका है। अपने agent द्वारा filed request पढ़ें: amount, rationale, alternatives। निर्णय लें।

निर्णय लेने के बाद अपने agent को यह paste करें:

मैंने इस refund को approve करने का निर्णय लिया है (या: reject करने का; एक line में बताएँ कि कौन सा और क्यों)। मेरा decision record करें। फिर इस approval के activity-log rows से मुझे समझाएँ और वह फ़ील्ड दिखाएँ जो prove करती है कि मैं, human board, decider था, agent नहीं। और मुझे explicitly remind करें कि automatically क्या नहीं हुआ: issue अभी भी वहीं बैठा है जहाँ था, और इस decision पर actually act करने के लिए मुझे आगे क्या करना होगा।

Agent आपका decision record करता है (approval approved या rejected पर move करता है, decider की identity और decision timestamp stamped होते हैं)। यह आपको activity log समझाता है: approval.approved (या approval.rejected) row, जिसमें actor_type user set है और board identify करता actor_id है। फिर यह honest हिस्सा name करता है: linked issue का status अपने आप change नहीं हुआ। अगर आप issue close करना या refund "issued" करना चाहते हैं (simulated, क्योंकि कोई payment processor wired नहीं है), तो यह separate command है, और अगर आप कहेंगे तो agent करेगा।

आप Scenario 4 में done हैं when:

• activity log approval chain contain करता है (request filed, decision आपके द्वारा recorded),
• linked issue decision से visibly unchanged है,
• आप वह फ़ील्ड name कर सकते हैं जो human decider को agent action से distinguish करती है (actor_type), और
• आप अपने words में state कर सकते हैं कि approval automatic unblock के बजाय decision record क्यों है।

Scenario 5 में carry-forward

अब आपके पास छोटा लेकिन वास्तविक activity log है: two issues, one approval, उनके पीछे heartbeat runs। एक table अभी भी empty है: अभी cost data नहीं है। Scenario 5 में यह बदलता है, और वही एक scenario है जिसे API key चाहिए।

---

Scenario 5: वास्तविक LLM Worker swap in करें; budget को teeth दें (~15 min)

Concept। हर Worker का monthly budget होता है, cents में set जब आप उसे hire करते हैं। लेकिन budget के पास enforce करने के लिए कुछ तभी होता है जब Worker billable काम करता है: keyless stub कुछ नहीं करता, इसलिए उसका spend zero रहता है और budget कभी move नहीं करता। यह चीज़ की honest shape है, lab में bug नहीं। Budget को actually कुछ meter करते देखने के लिए आपको वास्तविक LLM runtime backed Worker चाहिए।

इसलिए यह scenario swap करता है। आप gemini_local adapter पर new Worker hire करेंगे (fresh hire, edit नहीं, क्योंकि Workers immutable हैं, जैसा Scenario 2 ने बताया), उसे deliberately tiny monthly budget देंगे, और enough काम pile on करेंगे कि budget run down हो। फिर आप देखेंगे कि spend limit की तरफ climb करते समय Paperclip actually क्या करता है। यह एक scenario है जिसे API key चाहिए: free Gemini key, वही जो OpenClaw crash course इस्तेमाल करता है। Gemini वह path है जिससे यह पेज चलता है क्योंकि free tier scenario को keyless-adjacent रखता है। अगर आपके पास किसी दूसरे low-cost runtime की key already है (codex_local with a cheap OpenAI model, for instance), तो वह identical budget mechanic demonstrate करता है, और आपका agent adapter accordingly adjust कर सकता है।

LLM Worker hire करने के लिए एक prompt, उसे काम देने और budget देखने के लिए एक prompt।

5a. LLM Worker hire करें

अपने agent को यह paste करें:

मैं अब वास्तविक LLM Worker add करना चाहता हूँ। शुरू करने से पहले मैं अपने shell में GEMINI_API_KEY export करूँगा: जब आपको मेरी ज़रूरत हो, बताइए। gemini_local adapter पर Tier-1 Customer Support (LLM) नाम का new Worker hire करें, cheapest current capable Gemini model इस्तेमाल करते हुए। इसे deliberately small monthly budget दें, एक या दो dollar, ताकि मैं spend accrue होते देख सकूँ। Register करने से पहले create body समझाएँ, और remind करें कि हम stub Worker edit करने के बजाय new Worker क्यों hire कर रहे हैं।

आपका agent remind करता है कि Workers immutable हैं (इसलिए new hire, edit नहीं), वह point name करता है जहाँ आपको key export करनी है, और agent-create body draft करता है: Scenario 2 जैसा same shape, लेकिन adapterType gemini_local set और छोटा budgetMonthlyCents। Key export करने के बाद यह Worker register करता है।

5b. इसे काम दें और budget देखें

अपने agent को यह paste करें:

अब LLM Worker को काम दें। लगभग ten short inbound support issues create करें, थोड़े varied, और हर issue को create time पर new LLM Worker को assign करें। Heartbeats fire करें ताकि यह उन्हें पूरा करे। Paperclip server log tail करें। मैं दो चीज़ें देखना चाहता हूँ: per-run cost data मौजूद होना शुरू करे (keyless stub के लिए यह नहीं था), और Worker का monthly spend मेरे set किए budget की तरफ climb करे। साफ़ भाषा में मुझे exactly बताएँ कि spend limit approach और cross करते समय Paperclip क्या करता है: यही behavior मैं observe करना चाहता हूँ।

Agent issues create और assign करता है, heartbeats fire करता है, और log tail करता है। इस बार Worker billable काम करता है, इसलिए per-run usage data heartbeat records पर land होना शुरू करता है, और Worker का monthly spend zero से move करता है। Budget run down होते समय Paperclip actually क्या करता है, agent narrate करता है और साफ़-साफ़ report करता है: यह live observation है, scripted outcome नहीं, और आपका agent आपको वही बताने के लिए है जो वह देखता है।

आप Scenario 5 में done हैं when:

• new LLM Worker ने वास्तविक issues resolve किए हैं,
• per-run cost data अब मौजूद है जहाँ पहले empty था,
• Worker का monthly spend आपके set budget के against move हुआ है, और
• आपके agent ने साफ़ भाषा में बताया है कि budget limit approach करते समय Paperclip ने क्या किया।

API key पर एक word

Key को अपने shell में export करें (export GEMINI_API_KEY=...); इसे कभी project की किसी file में paste न करें, और अपने agent को इसे किसी file में लिखने न दें। AGENTS.md आपके agent को भी यही बताता है। अगर आप कभी key गलत जगह paste कर दें, तो rotate करें। Free-tier key low-stakes है, लेकिन habit point है।

Scenario 6 में carry-forward

अब आपके पास दो Workers हैं (keyless stub और LLM-backed one), dozen-plus issues, एक approval, और (इस scenario में नया) वास्तविक cost data। यह enough history है कि Scenario 6 की audit query कुछ पढ़ने लायक return करे।

---

Scenario 6: Audit trail को CFO की तरह query करें (~10 min)

Concept। Management plane का पूरा point है कि workforce के बाहर कोई person (CFO, legal, operations, compliance) database alone से seconds में reconstruct कर सके कि क्या हुआ, बिना किसी से पूछे। Paperclip यह history embedded Postgres database में रखता है। सबसे ज़रूरी table activity_log है: mutating action पर एक row (कंपनी create हुई, issue create हुआ, approval तय हुआ, Worker hire हुआ, heartbeat invoked), actor, action, और touched entity के साथ। दूसरा table, cost_events, cost story hold करता है (provider, model, tokens, cost in cents per billable run) और rows सिर्फ़ तब होती हैं जब LLM Worker ने billable काम किया हो, इसलिए Scenario 5 तक यह empty था।

एक prompt: Postgres open करें, history query और cost query run करें, जवाब पढ़ें।

अपने agent को यह paste करें:

CFO खेलने का time है। Embedded Paperclip Postgres से connect करें (आपका brief connection string assemble करने का तरीका cover करता है)। पहले activity_log के against हमारी कंपनी के लिए "what happened, in order" query run करें: हर action उसके actor और touched entity के साथ, oldest first। फिर cost_events के against cost query run करें: today की total cost, dollars में। दोनों के लिए SQL और results दिखाएँ। Finally, Scenario 4 में मेरे decided approval के लिए एक activity_log row समझाएँ, और उन fields की तरफ point करें जिन्हें auditor यह confirm करने के लिए इस्तेमाल करेगा कि decider मैं था।

Agent brief का Audit-trail सेक्शन पढ़ता है, आपके install की config file से Postgres connection string assemble करता है (इसके लिए कोई shortcut command नहीं; brief तरीका दिखाता है), और दो queries run करता है:

1. What happened, in order: SELECT over activity_log, आपकी कंपनी तक filtered, time by ordered। यह आपके run की full spine return करता है: कंपनी और project creation, दोनों Workers hired, हर issue created, heartbeats, approval filed और decided। यह वह query है जो बिना LLM Worker के भी काम करती है; audit story का keyless heart यही है।

2. Total cost today: SELECT SUM(...) over cost_events, integer cents column को dollars में convert करते हुए, today तक filtered। Scenario 5 से पहले यह nothing return करता था; अब यह आपके LLM Worker's runs की वास्तविक (small) cost return करता है।

फिर agent आपको उस approval के लिए एक activity_log row दिखाता है जिसे आपने तय किया: action (approval.approved या approval.rejected), actor_type user set, board identify करता actor_id, और timestamp। Auditor इसी तरह आपका decision reconstruct करता है।

आप Scenario 6 में done हैं when: history query आपके पूरे run की ordered story return करती है, cost query आपके Scenario 5 Worker से वास्तविक number return करती है, और आप activity_log में वह column (actor_type) name कर सकते हैं जो human decision को agent action से अलग बताता है।

---

Scenario 7: आपका monthly workforce audit (~10 min/month)

Concept। कंपनी time के साथ accumulate करती है: Workers hired, budgets set, approvals decided, schedules running। हर addition छोटा decision था जिसे आपने approve किया; chain compound होती है। Defense हर step पर vigilance नहीं है (आप वह नहीं catch कर पाएँगे जो अभी exist नहीं करता); यह fixed cadence पर ten-minute review है। यह scenario आपकी पहली ninety minutes का part नहीं है; यह move आप कंपनी की बाकी life में once a month करते हैं।

अपने agent को यह paste करें (जब time आए):

मेरा Paperclip monthly workforce audit run करें। Last audit के बाद hire, configure, schedule, तय, या pause हुई हर चीज़ समझाएँ। Flag करें कि किस चीज़ पर मैंने explicitly sign off नहीं किया, कौन सा Worker productive काम नहीं कर रहा, कौन सा budget मेरे set किए हुए से drift हो गया, और कौन सी setting जितनी tight होनी चाहिए उससे loose है। पूरे lot को single short report के रूप में summarize करें जिसे मैं approve या trim कर सकूँ।

आपका agent activity log, current Worker roster, budgets, और audit tables पढ़ता है, और एक-पेज report produce करता है।

Done when: आपने report review करने में ten minutes spend किए हैं और कम से कम एक decision लिया है (Worker की authority text tighten करना, budget prune back करना, unused Worker retire करना, approval threshold raise करना)। अगले month के लिए calendar mark करें।

---

यह क्यों काम करता है

दो things fresh रहती हैं; एक thing durable रहती है।

Fresh #1: इस पेज के scenarios book site पर live रहते हैं। जब आप बताते हैं कि आप किस scenario पर हैं, आपका agent उन्हें पढ़ता है।

Fresh #2: Current Paperclip commands और API shape paperclip.ing/llms.txt पर live हैं, full docs का LLM-friendly index, plus patient walkthrough के लिए docs.paperclip.ing। आपका agent किसी भी non-trivial operation से पहले इन्हें fresh पढ़ता है। Paperclip fast ship करता है; individual flags drift होने पर भी brief ऐसे accurate रहता है।

Durable: आपके download किए फ़ोल्डर में AGENTS.md (Paperclip क्या है, इसके docs navigate कैसे करने हैं, safety rails, verified operational shapes, recovery patterns), CLAUDE.md (one-line import marker), और worker-stub.py (keyless Worker itself) होते हैं। AGENTS.md कंपनियाँ, Workers and adapters, heartbeat contract, issues and assignment, approvals, budgets, audit, और diagnosis cover करता है। यह इस पेज से लंबा है क्योंकि यह Paperclip के साथ coding agent से माँगे जा सकने वाले हर काम को cover करता है, सिर्फ़ ऊपर के six scenarios को नहीं। फ़ोल्डर में कुछ stale नहीं होता, इसलिए आप इसे once download करके reuse करते हैं।

Pattern by design छोटा है: एक operational reference, एक import marker, एक runnable Worker। तीन files। Intelligence files में नहीं है; यह आपके coding agent द्वारा उन्हें पढ़ने और आप जो next माँगें उस पर apply करने में है। आपने six disconnected demos walk through नहीं किए; आपने ऐसी कंपनी assemble की जिसे आप tomorrow छुएँगे।

---

अब असल में क्या running है

Six demos नहीं: एक running system। Scenario 6 के बाद क्या persist रहता है, inventory:

Artifact	यह असल में क्या है	Tomorrow क्यों matter करता है
Paperclip server	API और embedded Postgres hold करता long-running Node.js process	Terminal close और reboot करने पर भी आपकी कंपनी survive करती है
The data directory	आपकी सारी कंपनी data, encrypted secrets, server logs	Substrate; इस directory को वैसे back up करें जैसे dotfiles को करते हैं
एक कंपनी	Purpose, goal, project, और उनके around कंपनी-scoped isolation	Boundary जिसके अंदर हर Worker, issue, और approval रहता है
दो Workers	Keyless worker-stub.py Worker और gemini_local LLM Worker	एक Worker pipeline keyless prove करता है; दूसरा economics दिखाता है
worker-stub.py	Heartbeats सुनता small local HTTP process	आपका पहला Worker, और अगला keyless Worker लिखने के लिए template
Issues and the activity log	Assigned और worked issues, plus हर action का row-by-row record	Reproducible workforce behavior, queryable history
एक approval	एक board decision filed और decided, permanently recorded	Risky actions के लिए आपकी workforce द्वारा इस्तेमाल किया गया audited sign-off
A budget with data	LLM Worker's monthly budget, जिसके against वास्तविक spend metered है	वह number जो "no runaway spend" को decorative के बजाय enforceable बनाता है
Audit queries you can run	activity_log (और cost_events) पर SQL, जो stakeholder सवालों का fast जवाब देता	वह view जिसे CFO, legal, या compliance बिना आपसे पूछे इस्तेमाल कर सकते हैं
AGENTS.md and the recovery line	Durable brief जिसे आपका agent हर session में पढ़ता है	वह skill जिसे आप इस कंपनी की पूरी lifetime reuse करते हैं

इससे working day कुछ ऐसा दिखता है:

1. वास्तविक customer message arrive करता है;
2. integration (जिसे आप बाद में wire करेंगे) Paperclip issue create करता है, Worker को assigned;
3. अगली heartbeat इसे Worker तक carry करती है;
4. Worker reply draft करता है;
5. high-stakes ones को आप dashboard में तय करते हैं;
6. month में once audit run करते हैं।

अगर इनमें से कोई artifact बाद में missing हो जाए (laptop wipe, accidental delete, version upgrade gone wrong), तो brief plus fresh onboard plus backup से data directory restore आपको exactly इसी picture पर वापस ले आता है।

वास्तविक customer channel wire करने से पहले

Crash course single-user है: आप human board हैं, और testing के लिए issues create करने वाले भी आप हैं। वास्तविक inbound source (support inbox, contact form, आपके existing systems से event) wire करने का मतलब है कि strangers आपकी workforce में write कर सकते हैं। ऐसा करने से पहले दो बातें true होनी चाहिए। Inbound content process करने वाले हर Worker के पास tight, clearly described authority envelope होना चाहिए (सिर्फ़ इसलिए broad latitude नहीं कि काम "customer support" है)। और inputs के लिए deliberate plan चाहिए जो किसी Worker से map नहीं होते (no orphaned issues)। जब तक आपने दोनों पर thought नहीं किया, single-user रहें।

---

आगे कहाँ जाएँ

Scenario 6 के बाद आपके पास working AI-native कंपनी है: दो Workers, एक demonstrated approval, पीछे वास्तविक data वाला budget, और audit trail जो stakeholder सवालों का seconds में जवाब देता है। शुरुआत के लिए ज़्यादातर लोगों को surface का यही अधिकांश हिस्सा चाहिए।

इस पेज ने जो भी topic touch किया (या skip किया), उसके patient walkthrough के लिए getting-started directory में कई deeper crash courses साथ बैठे हैं। छोटा map:

आप चाहते हैं...	यहाँ जाएँ
Fleet manage करने से पहले single Worker को durable workflow engine में wrap करना	Digital FTE से Production Worker तक: Inngest durability envelope
Hiring को callable capability बनाना (Workers जो policy के under दूसरे Workers hire करें)	Fixed से Dynamic Workforce तक: इस course का successor
दूसरे agent के अंदर Paperclip की REST API को tools के रूप में इस्तेमाल करना	Current MCP server package के लिए docs.paperclip.ing check करें; version pin करें
Paperclip को cloud या shared host पर deploy करना (multi-machine, multi-user)	docs.paperclip.ing के live docs; rely करने से पहले verify करें कि क्या ship हुआ है
Humans और आपकी workforce के बीच OpenClaw को edge layer के रूप में wire करना	OpenClaw crash course

बाकी सब के लिए, आपका AGENTS.md पहले से platform का अधिकांश हिस्सा cover करता है। अपने coding agent से पूछें: "AGENTS.md heartbeat contract के बारे में क्या कहता है?" या "AGENTS.md के approvals सेक्शन को समझाएँ।" Brief reference है; यह पेज tour है।

Meta-lesson: आपके unzipped folder की सबसे valuable चीज़ AGENTS.md है। इसे end to end पढ़ने के लिए एक evening लें (install steps के लिए नहीं, document की shape के लिए: discover-before-act table, working pattern, task type by operations, diagnostic checklists)। फिर जिस अगले tool को आप coding agent के सामने रखेंगे, उसके लिए ऐसा one लिखें। Pattern portable है: हर tool जिसकी learnable surface है, उसके लिए लिखने लायक AGENTS.md है। Paperclip clean target था क्योंकि install को agent-driven setup से benefit मिलता है और operations paste-and-watch scenarios में decompose होते हैं; आपको और भी मिलेंगे। अगला one author करें।

---

Flashcards Study Aid