Skip to main content

Fixed से dynamic workforce तक: hiring API, capability gaps, और talent ledger

15 Concepts. लगभग 2 से 3 घंटे की conceptual reading (अगर आप PRIMM Predicts को गंभीरता से लेते हैं, तो थोड़ा ज़्यादा). 2 से 3 घंटे की hands-on lab. कुल मिलाकर आधे दिन की योजना बनाएँ.

यह एक continuation crash course है। यह agentic-coding track का Course Seven है। Course Three, OpenAI Agents SDK और Cloudflare Sandbox के साथ AI Agents बनाना, ने एक streaming chat agent बनाया था। Course Four, AI Agent से Digital FTE तक, ने उस chat agent को Skills, Neon Postgres system of record, और MCP के साथ Digital FTE में बदला। Course Five, Digital FTE से Production Worker तक, ने Digital FTE को Inngest operational envelope में wrap किया ताकि दुनिया उसे जगा सके और crashes उसकी state न खो सकें। Course Six, एक Worker से workforce तक, ने Paperclip management layer जोड़ी ताकि एक या अधिक Workers assignments, budgets, approvals, और audit trail के साथ workforce बन सकें। वह workforce तीन Workers की थी, जिन्हें इंसान ने company-creation time पर चुना था। Course Seven यह समझाता है कि जब चौथे Worker की ज़रूरत पड़ती है, और workforce उसे लाने के लिए hiring API call करती है, तब क्या होता है।

वह एक insight जिससे बाकी सब साफ़ हो जाता है: AI-native company में hiring कोई quarterly HR motion नहीं है। यह callable capability है, जिसे workforce खुद पर invoke करती है, और जिसे ठीक वही approval primitive gate करता है जो $500 refund को gate करता है। Board job posting नहीं लिखता। Manager-Agent लिखता है। Board उसे approve करता है, और नया Worker उसी दोपहर org chart पर आ जाता है। इस course के अंत तक, Course Six की customer-support workforce ऐसी capability detect कर चुकी होगी जो उसके पास नहीं है, hiring proposal draft कर चुकी होगी, उसे approval gate से गुज़ार चुकी होगी, और Legal Specialist को org chart में शामिल कर चुकी होगी। यह सब उसी activity_log और cost_events ledger पर होगा, जिस पर मूल तीन Workers लिखते हैं।

Agent Factory के लिए यह क्यों मायने रखता है: Invariant 6 पूरा

Thesis एक AI-native company के लिए सात invariants का नाम देती है। Course Six ने तीन cover किए: management plane, human as principal, और nervous system का हिस्सा। Course Seven सबसे गहरे claim को cover करता है: Invariant 6, hiring callable capability है। यह architect का framing sentence है, जिसके around यह पूरा course बना है:

"जो workforce खुद को grow नहीं कर सकती, वह fixed company है; जो workforce approval के under खुद को grow कर सकती है, वह AI-native company है। Agent Factory में hiring कोई HR motion नहीं है; यह manager से आने वाली function call है, जो job description को input के रूप में लेती है, Worker को output के रूप में लौटाती है, और उसी approval primitive से gated है जो हर दूसरे consequential action को gate करता है।"

इसके बाद सात में से छह invariants बंद हो जाते हैं। बचा हुआ Invariant 2 (Edge delegate) Course Eight का domain है।

चार properties AI-native company में hiring को uniquely interesting capability बनाती हैं। ये properties किसी और tool call में नहीं होतीं। हर property को आगे अपना Concept मिलेगा; अभी shape यह है:

  1. Hire decision खुद agent decision है। जिस Worker के पास hire करने की authority नहीं है, वह भी gap flag कर सकता है। जिस Worker के पास can_create_agents=true है, वह draft और submit कर सकता है। यह सीमा company envelope (Invariant 1) तय करता है, code नहीं। (Concepts 1, 3.)
  2. नया Worker ऐसा authority envelope inherit करता है जो hire से पहले exist नहीं करता था। Legal Specialist का contract_modify=allow किसी existing Worker के envelope में नहीं है। Hire request वही जगह है जहाँ नए envelope पर negotiation होती है। (Concept 8.)
  3. Hire board-level act है, तब भी जब उसे agent propose करे। Course Six का approval gate वही gate है। Proposal artifact (job description, capability eval, expected budget) वही है जिसे board देखता है। (Concept 7.)
  4. Hires reversible हैं। Course Six ने Workers को startup पर once-configured माना था। Course Seven lifecycle जोड़ता है: hire, evaluate, deploy, retire, और ज़रूरत होने पर rehire. Talent ledger यह सब track करता है। (Concepts 7, 14.)

Agent Factory thesis इस Invariant 6 को "The workforce is expandable under policy" title देती है: workforce board की authority के under खुद को grow कर सकती है। Course Five ने Invariant 7 (nervous system) और Invariant 1 (HITL) का हिस्सा cover किया। Course Six ने Invariant 3 (management plane) cover किया और Invariant 6 को edge पर surface किया। Course Seven Invariant 6 को पूरा बंद करता है, और Course Eight के लिए सिर्फ़ Invariant 2 (Edge delegate) छोड़ता है।

Platform choice के बारे में

Course Six ने आपको Paperclip (paperclip.ing, github.com/paperclipai/paperclip) को agentic management layer के रूप में इस्तेमाल करना सिखाया था। Course Seven उसी instance को extend करता है। Course Six का वही npx paperclipai onboard --yes आपको hiring API देता है। यह अलग product नहीं है, बस अलग endpoint है। Course Seven जो verified endpoint सिखाता है: POST /api/companies/{companyId}/agent-hires. Verified governance flow: hire pending_approval return करता है, board approval thread पर comments करता है, और approve होने पर agent को PAPERCLIP_APPROVAL_ID के साथ wake किया जाता है।

Course Seven worked example को दो Paperclip-native runtime adapters पर साथ-साथ run करता है: claude_local और opencode_local. दोनों first-class Paperclip primitives के रूप में आते हैं; Paperclip हर heartbeat पर local coding-agent CLI खुद spawn करता है (claude_local के लिए claude headless, opencode_local के लिए opencode headless), CLI के environment में PAPERCLIP_API_URL और PAPERCLIP_API_KEY inject करता है, और CLI Paperclip की अपनी API पर turn चलाती है। कोई external service नहीं, कोई inbound URL नहीं, कोई relay नहीं, कोई separate cloud account नहीं। वही hire payload केवल adapterType और adapterConfig में अलग होता है। यही architectural point है: management plane के नज़रिए से hiring substrate-agnostic है, और local-CLI pair सबसे सस्ता संभव proof है।

दो adapters क्यों, एक क्यों नहीं? दो कारण हैं, महत्त्व के क्रम में।

  1. Multi-provider portability "substrate-agnostic" का binding test है। Single-adapter worked example हमेशा ऐसा पढ़ता है जैसे "architecture generic है अगर आप यही एक runtime चुनें." Identical hire को claude_local (single-provider, सिर्फ़ Anthropic models) और opencode_local (multi-provider; वही adapter Anthropic, OpenAI, Google, या OpenCode द्वारा supported किसी भी provider को provider/model slug से drive कर सकता है) पर run करना property को ठोस रूप से दिखाता है। अगर पाठक Legal Specialist को anthropic/claude-opus-4-7 पर चाहते हैं, Decision 4 का opencode_local tab swap दिखाता है। अगर वे इसे openai/gpt-5.2-pro पर चाहते हैं, तो सिर्फ़ adapterConfig.model string बदलती है। Hiring loop कभी बदला नहीं।
  2. Zero infrastructure का मतलब है कि पाठक lab पूरा कर सकता है। दोनों adapters उसी machine पर run होते हैं जिस पर Paperclip daemon चलता है। कोई beta access नहीं, कोई separate cloud account नहीं, कोई relay server नहीं, कोई inbound URL नहीं। पाठक दो CLIs (claude और opencode) install करता है, हर एक को एक बार authenticate करता है, और lab का बाकी हिस्सा Paperclip को API calls है। जिन substrates को integrate करना सबसे कठिन है (managed-cloud products जैसे Claude Managed Agents, vendor-hosted ones जैसे Cursor Cloud), वे अपनी जगह तब पाते हैं जब workload उनकी माँग करे: decision rubric और trade-offs के लिए Concept 6 की substrate table देखें।

अगर आपकी टीम managed-cloud runtime पसंद करती है (Anthropic का Claude Managed Agents संबंधित Anthropic option है; Concept 6 इसका नाम साफ़-साफ़ लेता है) या self-hosted Agent SDK endpoint, तो hiring API बदली नहीं जाती। सिर्फ़ adapterType और adapterConfig अलग होते हैं। Decision 4 दो local tabs साथ-साथ दिखाता है; Concept 6 की substrate table named alternatives cover करती है।

May 2026 तक known rough edges (इनसे टकराएँ तो हैरान न हों)
  • Claude Managed Agents public beta में है। हर request पर beta header managed-agents-2026-04-01 required है। Releases के बीच behaviors refine हो सकते हैं।
  • CMA की multi-agent orchestration research preview है और इसके लिए separate access request चाहिए (official overview के अनुसार)। Course का worked example single-agent CMA sessions इस्तेमाल करता है और multi-agent feature पर निर्भर नहीं करता।
  • Paperclip का hiring approval workflow implemented और shipping है, लेकिन custom auto-approval policies लिखने (Concept 9) का UI अभी भी partly CLI-driven है। "Auto-approve burst-capacity hires under $X per month" से ज़्यादा जटिल किसी भी policy के लिए buttons click करने के बजाय JSON edit करने की उम्मीद रखें।
  • जब hire किसी issue से triggered by होती है (sourceIssueId link), तो per-issue cost attribution activity_log में सही तरह से recorded है, लेकिन "proposal time, eval time, और काम के पहले महीने में hire की cost क्या थी" query करने के लिए तीन tables join करनी पड़ती हैं। Unified hire_lifecycle view track करने वाला एक open issue है।

ये hiring avoid करने की वजहें नहीं हैं। यह उस frontier API की सामान्य हालत है जो नई है, लोकप्रिय है, और बेहतर हो रही है। ये वजहें हैं versions pin करने, सबसे simple case से आगे किसी भी काम के लिए UI-driven के बजाय code-driven hiring को प्राथमिकता देने, और उन hires को कभी auto-approve न करने जो Worker को ऐसी authority देती हैं जो org chart पर पहले से कहीं मौजूद नहीं है।

TL;DR (अगर आपके पास 60 seconds हैं तो पहले यह पढ़ें)

चार दावे क्रम से:

  1. Workforce detect कर सकती है कि org chart पर कोई Worker यह काम handle नहीं कर सकता।
  2. Manager-Agent hiring proposal draft करता है: job description, eval pack, expected budget, draft authority envelope.
  3. Proposal Course Six के approval gate से गुजरता है। Human उसे देखता है। Human decide करता है।
  4. Approval पर, Paperclip का POST /api/companies/{id}/agent-hires chosen runtime (worked example के लिए Claude Managed Agents) के against नया Worker provision करता है। Org chart में अब तीन के बजाय चार Workers हैं।
Plain-English version, अगर ऊपर कुछ खो गया हो

Course Six में हमने तीन Workers वाली छोटी AI company बनाई थी: Tier-1 Support, Tier-2 Specialist, और Manager-Agent जो उनके बीच route करता है। इस course में company देखती है कि उसे चौथे Worker की ज़रूरत है (उसे बार-बार contract-review questions मिल रहे हैं जिन्हें तीनों में से कोई अच्छी तरह handle नहीं कर सकता)। Manager-Agent hiring proposal draft करता है और इजाज़त माँगता है। Human board के देखने से पहले candidate test होता है। Approval पर, नया Worker org chart में add होता है। Course के बाकी हिस्से में यही details हैं कि ये steps असल में कैसे work करते हैं।

Hiring loop. Course Six ने Paperclip द्वारा managed तीन Workers की workforce बनाई। Course Seven management layer के ऊपर loop जोड़ता है: capability-gap detection hiring proposal artifact में feed करती है, जो Paperclip के approval gate से गुजरता है (वही primitive जो Course Six ने refunds के लिए बनाया था), जो approval पर POST /api/companies/id/agent-hires call करके नया Worker provision करता है, जो first heartbeat पर उसी activity_log और cost_events को report करता है जिन्हें मूल तीन Workers report करते हैं। नया Worker (Legal Specialist) Paperclip-native local adapter पर run करता है: claude_local या opencode_local, Decision 4 में साथ-साथ दिखाए गए। Talent ledger ऊपर बैठता है और समय के साथ हर hire/eval/retirement/rehire event track करता है।

Course Six recap: वह workforce जिसे आप extend कर रहे हैं (expand करने के लिए click करें)

Course Six ने Paperclip पर तीन-Worker customer-support workforce बनाई। Workers ये थे:

  • Tier-1 Support (Course Five का customer-email Inngest function, http adapter से adapted): routine refund, FAQ, और status queries handle करता है; $200 per month budget; refund_max=$50; external email के लिए approval चाहिए।
  • Tier-2 Specialist (claude_local adapter): complex multi-turn cases, Tier-1 से escalations handle करता है; $800 per month budget; refund_max=$500; external email allowed.
  • Manager-Agent (http adapter): routing orchestrate करता है, issues पर comments करता है, approvals request करता है; $200 per month budget; refund_max=$0; सभी consequential actions के लिए approval चाहिए।

Course Six के आठ Decisions ने इन तीन Workers को Paperclip में wire किया, company envelope (refund_max=$5000, contract_modify=board_only) define किया, inbound emails को activity_log से route किया, और $750 refund पर approval gate demonstrate किया (Decision 6)। Course Seven assume करता है कि वह workforce मौजूद है और running है।

अगर आपने Course Six skip किया है, तो नीचे दिया गया Workforce vs Worker section आपको Course Seven follow करने के लिए enough on-ramp देता है, लेकिन आपके पास actual hire into करने के लिए workforce नहीं होगी। आपको पहले Course Six lab spin up करनी होगी।

यह कहाँ fit होता है: cheat sheet​

#ConceptLayerइसके बाद आप क्या answer कर पाएँगे
1जो workforce खुद को grow नहीं कर सकती, वह fixed company हैManagement planeHire करने की capability, hiring के act जितनी important क्यों है? क्योंकि fixed workforce fixed company है।
2Capability gaps: तीन signal typesManagement planeManager-Agent कैसे जानता है कि Worker needed है? Low routing confidence, repeated escalations, skill match से कोई eligible Worker नहीं।
3Hire vs escalate vs queue vs declineManagement planeCapability gap पर सही response कौन सा है? Volume, value, novelty पर decision tree.
4Job description as codeHiring APIHire request कैसा दिखता है? Role, capabilities, adapter, runtime, source issue वाला JSON payload.
5Hire से पहले capability evaluationHiring APICandidate Worker को real issues मिलने से पहले कैसे test किया जाता है? Scored rubric, accept/reject वाला eval pack.
6Substrate selection: local CLIs, Agent SDK, managed-cloud, या processRuntimeनए Worker को Paperclip-native local adapter (worked example), Agent SDK, Claude Managed Agents, या process पर कब रखें? Decision table.
7Hiring approval gateManagement planeCourse Six का approval primitive hiring पर कैसे map होता है? Same primitive, richer payload (proposal, eval, budget, envelope).
8New hires के लिए authority envelopeManagement planeबिल्कुल नए role को कितना refund_max मिले, यह कैसे तय करें? यह hire proposal में negotiated, approval पर locked, और activity_log में recorded होता है।
9Hires की एक class के लिए auto-approval policyManagement planeUnattended hiring कब acceptable है? Pre-approved classes (burst-capacity, cost ceiling के under narrow specialties), continuously audited.
10Worker का first heartbeatLabApproval और नए Worker के first real issue के बीच क्या होता है? Activated heartbeat, routing, Worker idle से real work में transition करता है।
11Retirement और rehire: full lifecycleLabTraffic down होने पर क्या होता है? Worker pause करें (Paperclip इस primitive को "Pause" के रूप में ship करता है)। Cycle में तीन चीज़ें preserved रहती हैं; rehire तेज़ है।
12Talent ledger: छह महीने पुरानी workforce कैसी दिखती हैAuditहर hire, eval, retirement, rehire का queryable record. पाँच canonical SQL queries board के actual operational questions answer करती हैं।
13Agent-portability questionOpenक्या Company A में hired Worker Company B को serve कर सकता है? Recipe (definition, system prompt, eval pack) travel कर सकती है; relationship नहीं।
14Talent ledger क्यों matters करता है: personnel change में institutional memoryAuditतीन properties (append-only, cross-correlated, किसी भी समय queryable) जो छह महीने के log को leaving human की institutional memory replace करने लायक बनाती हैं।
15What's next: Invariant 2 और EdgeForwardCourse Eight कहाँ से pick up करता है? Remaining invariant: OpenClaw के ज़रिए Edge delegation.

क्या आप इस course के लिए ready हैं?​

Prereq checklist

Course Seven ऐसे technical reader को assume करता है जिसने या तो:

  1. Course Six complete किया है, या equivalent experience रखता है। आपने Paperclip locally stand up किया है, company में तीन Workers hire किए हैं, एक approval flow wire किया है, और activity_log populate होते देखा है।
  2. आप TypeScript पढ़ सकते हैं, भले ही fluently लिख न सकें। Lab primarily TypeScript (Paperclip की native language) इस्तेमाल करती है: Manager-Agent की gap-detection logic, hire proposal generator, और approval-flow wiring के लिए। आपका AI assistant Python, SQL, या shell snippets भी produce कर सकता है जब कोई sub-task उन पर बेहतर fit बैठता है (eval-pack runner के लिए Python natural fit है; talent-ledger queries SQL हैं)। Course follow करने के लिए सारा code read-only है; briefing pattern का मतलब है कि आपका AI coding assistant सब type करता है। आप brief करते हैं, review करते हैं, और approve करते हैं। अगर code block unfamiliar लगे, तो सही response है assistant से उसे explain करने को कहना, खुद type करना नहीं।
  3. आपके पास दो local coding-agent CLIs installed और authenticated हैं। Decision 4 वही hire claude_local पर run करता है (जो हर heartbeat पर claude CLI headless spawn करता है) और opencode_local पर भी (जो opencode CLI headless spawn करता है)। दोनों install करें, confirm करने के लिए claude --version और opencode --version run करें, और हर एक को एक बार authenticate करें। claude_local को Anthropic account चाहिए; opencode_local OpenCode द्वारा supported किसी भी provider (Anthropic, OpenAI, Google, और others) तक provider/model slug से route कर सकता है, इसलिए आप कौन सी provider key लाते हैं यह adapterConfig.model में डाले गए slug पर निर्भर करता है। अगर आप Decision 4 में सिर्फ़ एक tab run करना चाहते हैं, तो सिर्फ़ वही CLI install करें; lab फिर भी वही hiring loop सिखाती है, बस आप उसे एक substrate पर देखते हैं। अगर बाद में managed-cloud runtime पसंद करना चाहें, तो Concept 6 की substrate table Claude Managed Agents (Anthropic का hosted long-running-agent product, May 2026 तक public beta) और Claude Agent SDK को named alternatives के रूप में, अपने trade-offs के साथ, cover करती है।
  4. आप approvals को primitive के रूप में समझते हैं। अगर "approval = Paperclip run को suspend करता है, board को request post करता है, durably wait करता है, board decision पर resume करता है" आपको clean pattern लगता है, mystery नहीं, तो आप calibrated हैं। अगर नहीं, तो आगे बढ़ने से पहले Course Six Concept 11 revisit करें।
  5. आप इस बात से comfortable हैं कि 'AI Worker hire करना' सही verb है। कुछ पाठकों को corporate-staffing vocabulary अटपटी लगती है। हम इसे जान-बूझकर इस्तेमाल करते हैं, metaphor की तरह नहीं। Architectural decisions (envelope, budget, retirement, ledger) तभी sense बनाते हैं जब आप role-and-employment frame को seriously लेते हैं। अगर आप इसे "management layer के under नया long-running process register करना" मानना चाहें, तो नीचे exactly यही हो रहा है; vocabulary उसी machinery का आसान handle है।

अगर पाँचों में से कोई भी shaky लगे, तो continue करने से पहले linked refreshers से शुरू करें। Course dense है; prereqs इसे हल्का महसूस कराते हैं।

यहाँ नए हैं? Course Seven dense है: यह on-ramp है

यह Agent Factory track के सात courses में सातवाँ है। अगर ऊपर की पाँच prerequisites unfamiliar लगती हैं, तो उल्टे क्रम में काम करें: Course Six: एक Worker से workforce तक direct prerequisite है (Paperclip plus management plane)। उससे पहले: Course Five: Digital FTE से Production Worker तक (Inngest operational envelope), फिर Course Three: AI Agents बनाना (agent loop), फिर PRIMM-AI+ chapter अगर आप AI-assisted coding में बिल्कुल नए हैं। Course Seven हर एक-दो page पर Course Six concepts reference करता है; cold start करना Course Six complete करने से कठिन है।

अगर आप अभी on-ramp नहीं कर सकते लेकिन concepts follow करना चाहते हैं, तो आप Course Six की full stack से बहुत कम चीज़ों से prerequisites fake कर सकते हैं:

  • Paperclip Quickstart (लगभग 15 minutes) और Approvals page (लगभग 10 minutes) पढ़ें।
  • PRIMM-AI+ Lesson 1 skim करें, ताकि course हर Concept में जो prediction-then-run rhythm use करता है वह समझ आ जाए।
  • Inngest को "वह चीज़ जो Worker को hours के लिए durably pause करने देती है" मानें, उसकी API सीखे बिना।

इन तीन substitutes के साथ, आप Parts 1 through 3 और Part 5 through 6 को conceptually follow कर सकते हैं। Part 4 lab को फिर भी working Paperclip install चाहिए; उसका shortcut नहीं है।

Glossary: beginner के reference के लिए 24 terms (expand करने के लिए click करें)

Course Seven Agent Factory track भर की vocabulary इस्तेमाल करता है। अगर body में कोई term confuse करे, तो यह glossary सबसे तेज़ reference है। Terms को उन चीज़ों के हिसाब से group किया गया है जिन्हें वे describe करते हैं।

People and roles

  • Worker: company के लिए काम करने वाला single AI agent. इस curriculum में Worker की identity, budget, authority envelope, और org chart में जगह होती है। General AI sense वाले "agent" से अलग: Worker company द्वारा employed होता है, सिर्फ user द्वारा invoked नहीं।
  • Workforce: एक company के सभी Workers का set. Course Six ने 3-Worker workforce बनाई; Course Seven 4th hire करता है।
  • Manager-Agent: वह Worker जो दूसरे Workers को orchestrate करता है। Issues route करता है, hiring proposals draft करता है, approvals पर comments करता है। Course Seven का protagonist.
  • Board: company के human owner(s). Hires approve करते हैं, policy set करते हैं, talent ledger review करते हैं। Approval primitive board attention gate करता है।

Paperclip primitives

  • Paperclip: AI Workers के लिए open-source management plane. Org chart, budgets, approvals, और audit provide करता है। Course Six का मुख्य विषय; Course Seven इसे extend करता है।
  • Issue: Paperclip का task/ticket primitive. Workers issues handle करते हैं। Issues Manager-Agent के ज़रिए Workers के बीच route होते हैं।
  • Adapter: Paperclip किसी Worker से कैसे बात करता है। Official docs built-in adapters का set ship करती हैं; इस course में referenced adapters में claude_local, opencode_local, codex_local, process, और http शामिल हैं। Course Seven का worked example Decision 4 में claude_local और opencode_local को साथ-साथ इस्तेमाल करता है (Paperclip हर heartbeat पर claude या opencode CLI headless spawn करता है)। अपनी deployment में available full adapter list discover करने के लिए curl $PAPERCLIP_API_URL/llms/agent-configuration.txt run करें।
  • Adapter config: adapter के लिए per-Worker settings. http adapter के लिए url plus optional headers (जहाँ auth travel करता है) और timeoutSec. Hire payload में set होता है।
  • Heartbeat: scheduled या event-triggered wake-up जो Worker को नया work check करने देता है। runtimeConfig.heartbeat में configured.
  • Skill: reusable knowledge bundle जिसे Worker call कर सकता है। Paperclip paperclip-create-agent skill ship करता है जो hiring workflow walk करता है; यह curriculum उसी के ऊपर built है।
  • Activity log: append-only table जहाँ हर mutating action recorded है। Talent ledger के लिए source of truth.
  • Cost events: वह table जहाँ हर token spend और session-hour charge recorded है, agent_id और issue_id से tagged.
  • Approval gate / Approval primitive: Paperclip का mechanism जो decision को board के सामने surface करता है और response का durably wait करता है। Originally refunds के लिए (Course Six); अब hiring के लिए unchanged reuse होता है (Course Seven).
  • Source issue: वह issue जिसने hire trigger किया। Hire payload में sourceIssueId से linked. यह audit anchor है जो Worker के existence को उस work से connect करता है जिसने उसे justify किया।

Authority concepts

  • Authority envelope: authorities का set जो Worker (या company) hold करता है। Examples: refund_max=$500, contract_modify=deny, external_email=allow. Envelope bound करता है कि Worker क्या कर सकता है.
  • Envelope cascade: layered structure: company envelope, role envelope, issue envelope, approval-level envelope. हर layer ऊपर वाली से narrow होती है।
  • Envelope extension: company envelope को ऐसी authority देना जो किसी existing Worker के पास नहीं थी। इसके लिए normal hire से आगे board-level approval चाहिए।

Course Seven concepts

  • Capability gap: work की ऐसी category जिसे current workforce handle नहीं कर सकती। तीन signals से detect होता है (Concept 2).
  • Eval pack: लगभग 12 representative test issues की battery, known reference answers के साथ, जिसका use approval से पहले candidate Worker score करने के लिए होता है। Concept 5.
  • Substrate: Worker असल में कहाँ run करता है। Options में Claude Managed Agents, Claude Agent SDK, claude_local, process शामिल हैं। Concept 6.
  • Talent ledger: workforce के history भर में हर hire, eval, retirement, और rehire event का cumulative record (activity_log plus cost_events में)। SQL speed पर institutional memory.

Tech and products

  • Inngest: Course Five का durable-execution platform. step.wait_for_event provide करता है (वही primitive जो approval-gate durability को power करता है) और crash-safe Worker runs देता है।
  • Claude Managed Agents (CMA): long-running agents के लिए Anthropic का hosted infrastructure. April 2026 से public beta; official docs. चार core concepts के around built: Agent (configuration), Environment (container template), Session (running instance), और Events (आपकी application और agent के बीच SSE message stream). Course Seven का worked-example substrate.
  • Claude Agent SDK: self-hosted agents के लिए Anthropic का programmatic harness. Course Seven का alternative substrate (Concept 6 sidebar).

Thesis-level

  • AI-native company: ऐसी company जिसका work primarily AI Workers human governance के under करते हैं, और management plane primary interface होता है। "AI-augmented company" का architectural opposite.
  • Invariant: सात architectural properties में से एक जो AI-native company में होनी चाहिए। Course Seven Invariant 6 (hiring as callable) close करता है। Course Eight Invariant 2 (Edge delegate) close करता है।
  • Briefing pattern: इस course का pedagogical principle: students कभी hand-write code नहीं करते। वे अपने AI coding assistant (Claude Code या OpenCode) को briefings लिखते हैं, जो code produce करता है। Student का काम well-brief करना, review करना, और approve करना है।

Part 1: Hiring callable क्यों है​

तीन Concepts जो यह establish करते हैं कि workforce को खुद grow करने की ज़रूरत क्यों है और system कैसे पहचानता है कि उसे ऐसा कब करना चाहिए। अभी code नहीं है; lab Part 4 में शुरू होती है। जो readers सीधे आगे जाना चाहते हैं, वे worked example के लिए Part 4 पर जा सकते हैं, लेकिन lab की gap-detection logic assume करती है कि आपने Concepts 1 से 3 internalize कर लिए हैं।

Concept 1: जो workforce खुद grow नहीं कर सकती, वह fixed company है​

Course Six की workforce में तीन Workers थे: Tier-1 Support, Tier-2 Specialist, Manager-Agent। Human ने company-creation time पर ये तीनों चुने थे। उन्होंने वही काम संभाला जो उस समय मौजूद था। Org chart set था।

जब पहली बार कोई inbound email ऐसी चीज़ माँगे जो इन तीनों में से कोई नहीं कर सकता, तब क्या होता है? Customer-support example में इसका सबसे realistic version contract terms पर सवाल है: कोई customer पूछता है, "हमारे agreement के Section 7.3 में 'material breach' से क्या मतलब है?" Tier-1 इसका जवाब नहीं दे सकता; refund policy लागू नहीं होती। Tier-2 इसका जवाब नहीं दे सकता; यह escalated case नहीं, काम की एक अलग category है। Manager-Agent इसे कहीं route नहीं कर सकता क्योंकि routing options खत्म हो चुके हैं। Course Six के model में यह email अटक जाती है। Manager-Agent इसे human board तक escalate करता है। Human email पढ़ता है और समझता है: हमारे पास इसके लिए कोई Worker नहीं है। वे Slack thread खोलते हैं। वे पुराना contract-review precedent खोजते हैं। वे खुद reply draft करते हैं। Email का जवाब दे दिया जाता है।

ऐसा एक बार हो, तो ठीक है। एक महीने में बारह बार हो, तो यह pattern है। एक महीने में पचास बार हो, तो workforce को grow करना ज़रूरी है।

AI से पहले workforce grow करने का version quarterly HR motion था: gap identify करें, job description लिखें, role post करें, candidates interview करें, hire करें, onboard करें, ramp करें। Minimum छह हफ्ते, typical बारह हफ्ते, और हर step पर human board bottleneck होता है। AI-native company में इस motion को बारह हफ्ते नहीं लगने चाहिए। इसे एक दोपहर लगनी चाहिए, और board bottleneck नहीं होना चाहिए, सिवाय वहाँ जहाँ board खुद bottleneck होना चाहता है: क्योंकि hire consequential है, envelope नया है, या grant की जा रही authority novel है।

Invariant 6 यही claim करता है। Architect की framing:

"जो workforce खुद grow नहीं कर सकती, वह fixed company है; जो workforce approval के under खुद grow कर सकती है, वह AI-native company है। Agent Factory में hiring HR motion नहीं है; यह manager से आने वाली function call है, जो job description को input की तरह लेती है, Worker को output की तरह return करती है, और उसी approval primitive से gated होती है जो हर दूसरे consequential action को gate करता है।"

Course Six से mental model shift यह है: Course Six में Manager-Agent existing workforce को coordinate करता था। Course Seven में Manager-Agent workforce का size और shape बदल सकता है। Manager अकेले decide नहीं करता: यह वही human-in-the-loop discipline है जिसे हमने अभी lock किया है। लेकिन Manager initiate करता है: proposal draft करता है, eval run करता है, budget estimate लिखता है। Board review करके approve करता है। नया Worker उसी दोपहर org chart पर आ जाता है।

PRIMM: Predict

मान लीजिए आप एक startup join करने वाले engineer हैं। CEO कहता है: "हमारे पास AI-native customer-support workforce है। तीन Workers routine cases संभालते हैं। पिछले महीने हमें 47 contract-related emails मिलीं जिन्हें तीनों में से कोई handle नहीं कर सकता था। Human board ने सभी 47 खुद पढ़ीं। Average response time 32 hours था, दो cases outside counsel को escalate हुए, एक miss हो गया और customer churn कर गया।"

Confidence 1 से 5: hiring loop add करने के लिए नीचे में से सबसे strong case कौन सा है? (एक चुनें।) (a) 32-hour response time. (b) Outside counsel को escalate हुए दो cases. (c) वह एक missed case जिसने churn कराया. (d) Board ने सभी 47 खुद पढ़ीं.

जवाब: (d). बाकी तीन लक्षण हैं; (d) मूल कारण है। Hiring loop के बिना workforce हर novel work category को human board पर push करती है। Board ही queue बन जाता है। Customers को 32-hour latency और missed cases इसलिए नहीं दिखते कि काम मुश्किल है, बल्कि इसलिए कि queue human-bottlenecked है। Hiring loop workforce को 90% contract questions Legal Specialist Worker को route करने देता है, और board सिर्फ़ सच में consequential ones review करता है: outside counsel escalations, novel contract language, या ऐसे customers जहाँ board member को personally weigh in करना चाहिए। आपको hiring loop चाहिए या नहीं, इसका सही metric response time या churn नहीं है; यह है कि board का कितना attention उस काम पर खर्च हो रहा है जो workforce को खुद करना चाहिए। अगर board queue है, तो आपको hiring loop चाहिए।

सार: अगर आपकी workforce gaps discover करने पर new roles add नहीं कर सकती, तो human board हर novel kind of work की queue बन जाता है। Hiring वह function है जो board-as-queue dysfunction को रोकता है।

Concept 2: Capability gaps, तीन signal types​

Capability gap detection Course Seven का technical heart है। यहीं Manager-Agent decide करता है: "यह काम लगातार आ रहा है और लगातार ऐसा कोई Worker नहीं है जिसे यह route किया जा सके।" तीन signals gap detection trigger करते हैं। हर signal की remediation अलग है; Manager-Agent तीनों को watch करता है, लेकिन हर एक पर अलग तरह से react करता है।

Capability gap detection के तीन signals, तीन columns में दिखाए गए हैं। Signal 1 low routing confidence है: Manager-Agent का router 14 दिनों के अंदर same category के तीन या ज़्यादा issues पर 0.6 से नीचे score करता है, जिससे पता चलता है कि routing options गलत हैं। Signal 2 repeated escalations है: same category पर तीन या ज़्यादा "outside my scope" escalations, जिससे पता चलता है कि org chart में role missing है। Signal 3 no eligible Worker by skill match है: routing step empty result set return करता है, जिससे पता चलता है कि काम सच में novel है। हर column firing window, example, और remediation दिखाता है: activity_log में gap_detected row लिखना, अभी hire propose करना नहीं। Footer में rule of thumb है: 14 दिनों के अंदर same category पर तीन में से कोई भी दो signals fire हों, तो gap-detected row trigger होती है।

Signal 1: Low routing confidence. जब Manager-Agent की routing logic यह confidence score return करती है कि कौन सा Worker इस issue को handle करे, और वह score multiple days में multiple issues पर लगातार threshold से नीचे रहता है, तो यह sign है कि routing options गलत हैं। एक हफ्ते में तीन contract-related emails, हर एक confidence 0.4 से 0.6 के साथ "Tier-2 Specialist (default)" को routed, क्योंकि कोई दूसरा option higher score नहीं कर रहा: यह routing problem नहीं, workforce-composition problem है। Manager-Agent को इन्हें Tier-2 को route करते नहीं रहना चाहिए, जो इन्हें खराब handle करेगा और budget burn करेगा; उसे pattern flag करना चाहिए।

Signal 2: Repeated escalations. जब Workers लगातार कुछ issue types को human board तक escalate करते हैं: "मेरे पास यह decision लेने की authority नहीं है" या "यह मेरे domain से बाहर है", और escalations किसी recognizable category पर cluster होती हैं, तो यह sign है कि org chart में role missing है। हर हफ्ते एक escalation noise है। हर महीने आठ escalations, सब contract-review questions पर, hire-the-specialist signal है।

Signal 3: No eligible Worker by skill match. जब नया issue आता है और Manager-Agent का skill-matching step empty result set produce करता है: org chart पर कोई Worker ऐसा नहीं है जिसके पास इस issue द्वारा claimed skill हो, तो यह sign है कि काम सच में novel है। जैसे "इस email को Bahasa Indonesia से English में translate करें" emails की burst, जबकि किसी Worker की skills में language=indonesian नहीं है। Manager-Agent को guess नहीं करना चाहिए; उसे flag करना चाहिए।

तीन signals independent नहीं हैं। Novel work category (Signal 3) low confidence (Signal 1) भी produce करेगी और escalations (Signal 2) भी produce करेगी। लेकिन तीनों signals अलग orders में fire करते हैं: Signal 1 पहले fire करता है, ऐसे issue के आने के कुछ घंटों के भीतर; Signal 2 बाद में fire करता है, consistent escalations के एक हफ्ते बाद; Signal 3 सिर्फ़ तब fire करता है जब skill model खुद new category recognize करने के लिए updated हो। Manager-Agent को capability-gap alert तब fire करना चाहिए जब 14-day window के अंदर same category पर तीन में से कोई भी दो signals fire हों: यह rule of thumb one-off cases filter करने और दो हफ्तों के अंदर genuine patterns catch करने के लिए tuned है।

Signalकब fire होता हैकितनी देर बादअगला कदम
Low routing confidenceSame category के तीन या ज़्यादा issues पर confidence 0.6 से कमHours to daysManager category flag करता है, gap-detection ledger में log करता है
Repeated escalationsSame category पर human board को तीन या ज़्यादा escalationsDays to weeksManager Paperclip में "gap detected" issue खोलता है
No eligible Worker by skillSkill-match issue की claimed skills के लिए empty return करता हैImmediateManager "unassigned" queue में auto-route करता है और flag करता है

Capability-gap detection का output hire request नहीं है। यह Paperclip के activity_log में gap-detected record है, जिसे Manager-Agent बाद में hiring proposal draft करते समय reference कर सकता है। Proposal step Concept 4 है। Gap-detection step सिर्फ़ "notice किया और record किया" है; यह deliberate separation इसलिए है ताकि Manager-Agent ऐसे gaps भी detect कर सके जिनके लिए board अभी hire नहीं करना चाहता। जैसे कोई startup decide कर रहा है कि contract work Worker justify करता है या नहीं, उसे decide करने से पहले gap pattern देखना चाहिए।

जल्दी check करें

आपका Tier-2 Specialist Worker दो हफ्तों से contract questions handle कर रहा है क्योंकि कोई दूसरा Worker eligible नहीं है। इन issues पर routing confidence लगभग 0.55 रहा है। Tier-2 ने उनमें से किसी को escalate नहीं किया; वह अपनी तरफ़ से पूरी कोशिश कर रहा है, budget burn कर रहा है, और कभी-कभी गलत answers दे रहा है। दो हफ्तों के बाद, क्या rule-of-thumb gap-detection rule (14 दिनों में same category पर तीन में से कोई भी दो signals) fire होगा? Walk through करें कि कौन से signals present हैं और कौन से absent।

सार: capability gap तब fire होता है जब तीन में से दो signals (low routing confidence, repeated escalations, no eligible Worker by skill match) 14 दिनों के अंदर same category पर hit करते हैं। One-off cases count नहीं होते; rule noise filter करने और दो हफ्तों में genuine patterns catch करने के लिए tuned है।

Concept 3: Hire बनाम escalate बनाम queue बनाम decline​

Capability gap detect होने के बाद अगला decision है: इसके बारे में करना क्या है। Hiring हमेशा सही जवाब नहीं होती। तीन और जवाब मौजूद हैं, और ऐसा Manager-Agent जो सिर्फ़ "hire" जानता है, बहुत ज़्यादा hire करेगा। Decision four-way fork है।

Decision tree "Gap detected (any 2 of 3 signals, 14 days)" से शुरू होता है और तीन sequential questions से branch करता है। Q1 पूछता है कि क्या काम company mission से aligned है। अगर नहीं, path DECLINE तक जाता है: routing update करें ताकि politely decline किया जा सके; "हम यह काम नहीं करते" valid है। अगर हाँ, Q2 पूछता है कि क्या काम consequential या rare है। अगर हाँ, ESCALATE: escalation path formalize करें; board इसे handle करना चाहता है। अगर नहीं, Q3 पूछता है कि क्या काम seasonal या transient है। अगर हाँ, QUEUE: issues hold करें और human capacity आने पर batch में handle करें। अगर नहीं, answer HIRE है: durable plus high-volume plus narrow, Concept 4 के अनुसार hire proposal draft करें। Footer discipline reinforce करता है: पहले month में default escalate या queue रखें, फिर decide करें; तीन दिन के data पर लिए गए hire decisions usually गलत होते हैं। Manager-Agent इन चार में से एक propose करता है; board decide करता है।

Hire तब करें जब work pattern durable हो (आगे भी जारी रहने की उम्मीद हो), cost justify करने लायक high-volume हो (support case में $400 से $800 per month वाला Worker तभी pencils करता है जब वह 40 से ज़्यादा issues per month handle करे), और role define करने जितना narrow हो (Concept 5 का eval pack writable होना चाहिए)। Legal Specialist तीनों में fit बैठता है: contract questions लगातार आ रहे हैं, volume 47 per month है और grow हो रहा है, और "contract clause review करना" definable role है।

Human को escalate तब करें जब काम consequential हो (example: customer के General Counsel के साथ contract amendments negotiate करना), rare हो (quarter में एक बार), या सच में AI workforce की competence से बाहर हो (example: deposition prep)। Board नहीं चाहता कि यह Worker को routed हो; वे इसे खुद करना चाहते हैं। Capability-gap detection fire होना चाहिए (board को पता होना चाहिए कि pattern exist करता है), लेकिन remediation hire करना नहीं, escalation path formalize करना है।

Queue तब करें जब काम seasonal या transient हो (contract-renewal cycle के दौरान एक महीने का spike), या जब hiring की cost waiting की cost से ज़्यादा हो (bursty work के दो महीनों के लिए $50 per month Worker pencils नहीं करता, जब तक आप उसे अगले साल rehire नहीं कर सकते)। Paperclip का retirement mechanism (Concept 12) hire-then-retire-then-rehire को cheap बनाता है, अगर original hire cheap था। लेकिन अगर eval और onboarding board attention के पाँच दिन लेते हैं, तो work queue करके batch में handle करना बेहतर है।

Decline तब करें जब काम company mission से aligned नहीं है। Customer-support company को contract-drafting work decline करना चाहिए, भले customer ask करे। "हम यह काम नहीं करते" valid answer है; capability-gap detection fire होना चाहिए (pattern exist करता है), लेकिन remediation routing rules update करना है ताकि politely decline किया जा सके।

Decision हमेशा obvious नहीं होता। Manager-Agent का role इन चार में से एक propose करना है; board decide करता है। Concept 7 proposal format cover करता है; Concept 9 वे policies cover करता है जिनसे इनमें से कुछ decisions automate हो सकते हैं।

निर्णयTrigger patternलागतवापस पलटने की क्षमता
HireDurable, high-volume, narrowWorker budget, setup, onboardingHigh: बाद में retire और rehire करें
Escalate to humanConsequential or rareहर case पर board attentionHigh: escalation rule बदलें
QueueSeasonal or transientCustomer wait timeTrivial: staff आते ही queue flush करें
DeclineOff-missionCustomer dissatisfactionLow: work decline करना brand decision है

एक उपयोगी rule of thumb: पहले month में default escalate या queue रखें, फिर decide करें। तीन दिन के data पर लिए गए hire-decisions usually गलत होते हैं। Week one में Manager-Agent का काम gap record करना है, hire propose करना नहीं। Hiring proposal Concept 4 artifact है, जिसे तभी draft किया जाता है जब gap कम से कम तीन weeks observe हो चुका हो और ऊपर के hire criteria match करता हो। Board को ऐसा proposal दिखता है जो sustained pattern से पहले ही earned है।

AI के साथ try करें

अपने AI coding assistant में (Claude Code या OpenCode, जो भी आपने Course Six में use किया; बाकी course आपकी choice follow करता है), यह paste करें:

"मैं AI-native company curriculum का Course Seven पढ़ रहा हूँ। Course capability gaps का response देने के लिए four-way fork introduce करता है: hire, escalate, queue, decline। नीचे दिए गए 5 scenarios में से हर एक के लिए predict करें कि कौन सा response appropriate है और क्यों। जब तक मैं अपनी prediction के साथ respond न करूँ, अपना answer reveal न करें।

  1. 2 हफ्तों में 3 emails tax-residency advice माँगती हैं (हर case one-off है, customers unrelated हैं, topic complex है).
  2. हर week 15 emails पूछती हैं, 'मैं अपना invoice PDF के रूप में कहाँ download कर सकता हूँ?' Workforce में ऐसा कोई Worker नहीं है जिसे पता हो कि invoice export endpoint मौजूद है.
  3. कोई customer आपके साथ अपने contract की wording edit करने में help माँगता है.
  4. Planned billing-system migration पर 2 हफ्तों में 80 emails का spike आता है, जिसके बाद volume normal पर लौट आता है.
  5. कोई customer पूछता है, 'क्या आप मेरी next job के लिए recommendation letter लिख सकते हैं?' इसके in-scope होने की कोई business reason नहीं है."

पाँचों को walk through करें। अपनी predictions को assistant के analysis से compare करें। जो pattern आप notice करेंगे: सही answer volume times durability times narrowness पर depend करता है, न कि इस पर कि काम "technically possible" है या नहीं। Scenario 5 में recommendation letter लिखने में technically capable Worker भी गलत response है; company उस business में नहीं है। Hiring एक strategic decision है जिसे workforce propose करती है और board ratify करता है, capability decision नहीं।

सार: capability gap के चार possible responses हैं: hire (durable, high-volume, narrow), escalate (consequential or rare), queue (transient), decline (off-mission)। पहले month में default escalate या queue रखें; तीन दिन के data पर लिए गए hire decisions usually गलत होते हैं।

Part 2: भर्ती contract​

Part 1 ने orientation दी: gaps वास्तविक हैं, signals detect किए जा सकते हैं, और response चार-तरफ़ा fork है। Part 2 hire response को concrete बनाता है। इसमें तीन Concepts हैं: hiring API क्या expect करती है, approval से पहले candidates को कैसे evaluate किया जाता है, और substrate, यानी नया Worker सच में कहाँ run करता है, कैसे चुना जाता है।

Concept 4: Job description को code की तरह​

Paperclip का hiring endpoint POST /api/companies/{companyId}/agent-hires है। Payload एक single JSON object है, और उस object की body वही shape follow करती है जिससे Paperclip में कोई भी agent create किया जाता है। यहाँ अलग से "job post करें, applications review करें, finalist चुनें" वाला workflow नहीं है, क्योंकि AI Workers के लिए कोई labor market नहीं है; job description और candidate specification वही एक artifact हैं। Hire request ही candidate है।

Payload shape के बारे में शुरुआत में दो बातें जान लें। पहली, official Paperclip docs एक minimal hire request describe करती हैं जिसमें essentials शामिल होते हैं: name, role, reportsTo, capabilities, और एक budget। Hire file करने के लिए इतना काफ़ी है; बाकी चीज़ों के लिए Paperclip defaults use करता है। दूसरी, production hire आम तौर पर करीब दस fields use करती है। इसमें UX के लिए title और icon, substrate selection के लिए adapterType plus adapterConfig, heartbeat behavior के लिए runtimeConfig, और audit linkage के लिए sourceIssueId जुड़ते हैं। Paperclip की paperclip-create-agent skill में underlying schema desiredSkills भी accept करता है (declare करें कि नए Worker में कौन सी Paperclip skills installed होनी चाहिए), instructionsBundle भी accept करता है (entry-file plus instruction files का map, जैसे AGENTS.md, जिन्हें Worker हर heartbeat पर पढ़ता है), और sourceIssueIds भी accept करता है (plural; hire को कई triggering issues से link करें, जो तब useful है जब gap-detection cluster कई issues में फैला हो)। Implementation time पर दोनों sources consult करें; live docs canonical example हैं, और GitHub skill repo में full schema है।

नीचे का diagram production-shape payload दिखाता है। Course Seven का worked example full production set use करता है, क्योंकि Manager-Agent एक complete proposal generate करता है, minimal one नहीं:

अगर आप इस diagram का सिर्फ़ एक हिस्सा scan करें, तो right-hand column देखें

यह बताता है कि core fields में से हर field क्या करती है। Left-hand JSON raw payload shape है; concept समझने के लिए आपको इसे field by field पढ़ने की ज़रूरत नहीं है।

Hire payload की production shape: बाईं तरफ JSON और दाईं तरफ annotated explanation column। Subtitle बताता है कि official docs में minimum hire request में name, role, reportsTo, capabilities और budget शामिल होते हैं; diagram वह production shape दिखाता है जिसे Course Seven का worked example use करता है। JSON दिखाता है: name, role (general जैसे role types का fixed enum), title, icon (जिसे /llms/agent-icons.txt enum से आना चाहिए), reportsTo (org chart edge), capabilities (positive और negative statements वाली prose, जैसे Does NOT modify contracts), adapterType (worked example में claude_local; Decision 4 के दूसरे tab में opencode_local; self-hosted Agent SDK endpoint या managed-cloud relay के लिए http), adapterConfig (claude_local: instructionsFilePath + maxTurnsPerRun + timeoutSec + optional model; opencode_local: required model provider/model slug + instructionsFilePath + timeoutSec; http: url + optional headers + timeoutSec), runtimeConfig (wakeOnDemand true; pure responder के लिए timer heartbeat off), budgetMonthlyCents (80000 cents = $800 per month cost ceiling), और sourceIssueId (hire को उसके triggering issue से जोड़ने वाला audit anchor)। Annotation column हर field explain करता है। Footer clarity के लिए diagram से omit किए गए truly optional fields note करता है: desiredSkills, instructionsBundle, और plural sourceIssueIds.

Course Seven के worked example में use होने वाली shape, Paperclip की paperclip-create-agent skill से ली गई है (claude_local variant; Decision 4 में opencode_local variant side by side दिखता है):

{
  "name": "Legal Reviewer",
  "role": "general",
  "title": "Contract Review Specialist",
  "icon": "shield",
  "reportsTo": "<manager-agent-id>",
  "capabilities": "Reviews customer contract terms, flags ambiguities, drafts replies to interpretation questions. Does NOT modify contracts.",
  "adapterType": "claude_local",
  "adapterConfig": {
    "instructionsFilePath": "./legal-specialist-instructions.md",
    "maxTurnsPerRun": 3,
    "timeoutSec": 90
  },
  "runtimeConfig": {
    "heartbeat": { "enabled": false, "wakeOnDemand": true }
  },
  "budgetMonthlyCents": 80000,
  "sourceIssueId": "PAP-128"
}

ऊपर का adapterConfig एक Paperclip-native Worker describe करता है: Paperclip हर heartbeat पर claude CLI को headless spawn करता है, उसके environment में PAPERCLIP_API_URL और PAPERCLIP_API_KEY रखता है, और CLI अपना turn Paperclip की अपनी API के against execute करता है। कोई external URL नहीं, कोई relay नहीं। यहाँ claude_local payload में model omit है, क्योंकि इस adapter के लिए field optional है और absent होने पर claude CLI अपना default model use करता है; अगर आपको किसी specific Claude model identifier को pin करना है, तो इसे explicitly pass करें। opencode_local के लिए shape similar है, लेकिन model required है (एक provider/model slug, जैसे "anthropic/claude-opus-4-7" या "openai/gpt-5.2-pro") और maxTurnsPerRun verified shape का हिस्सा नहीं है; worked example spawn loop को थोड़ा ज़्यादा headroom देने के लिए थोड़ा बड़ा timeoutSec भी set करता है (120 vs claude_local का 90); अपनी real heartbeat latency के हिसाब से tune करें। http-adapter Worker के लिए, जैसे self-hosted Agent SDK endpoint या thin relay से पहुँचा managed-cloud product, adapterConfig एक url plus optional headers और timeoutSec है। Concept 6 बताता है कि कौन सी shape कब सही है।

हर field काम करती है। आइए 11 fields walk through करें:

  • name वह है जो इंसान Paperclip UI में देखते हैं ("Legal Reviewer")। छोटा, role की याद दिलाने वाला। यह agent की prompt-time identity नहीं है; वह separately configured system prompt से आती है।
  • role organizational role types का fixed enum है (ceo, cto, cmo, cfo, security, engineer, designer, pm, qa, devops, researcher, general); closest fit चुनें, और जो specialist C-suite या engineering role से map नहीं होता, वह general use करता है। Human-readable specificity title और capabilities में रहती है, role में नहीं। Paperclip की routing logic और activity log इसे use करते हैं, इसलिए rehires के across इसे stable रहना चाहिए: अगर आप छह महीने बाद Legal Reviewer को retire करके rehire करते हैं, तो same role reuse करें ताकि talent ledger hire cycles के across correlate कर सके।
  • title human-readable job title है। यह name से उसी वजह से अलग है जिस वजह से किसी व्यक्ति का नाम उसके job title से अलग होता है: "Legal Reviewer" नाम वाला Worker बाद में rehire किए बिना "Senior Contract Counsel" title पर promote हो सकता है।
  • icon /llms/agent-icons.txt के enum से आना चाहिए। Paperclip इसे enforce करता है ताकि org-chart views visually consistent रहें। Verified API call: curl -sS "$PAPERCLIP_API_URL/llms/agent-icons.txt" -H "Authorization: Bearer $PAPERCLIP_API_KEY"। Legal Specialist के लिए, enum में shield closest semantic fit है।
  • reportsTo org-chart edge set करता है। Course Seven का Legal Specialist Manager-Agent को report करता है (Course Six वाला वही orchestrator)। Flatter org chart के लिए, कोई Worker directly human board को report कर सकता है, जो reportsTo omit होने पर implicit default है।
  • capabilities prose है जो describe करती है कि Worker क्या करता है और क्या नहीं करता। यह सबसे underrated field है। यह तीन readers की सेवा करती है: org chart browse करने वाले इंसान, routing decisions लेने वाला Manager-Agent ("क्या इस Worker की capabilities इस issue की needs से match करती हैं?"), और heartbeat time पर Worker खुद (prompt में शामिल होता है: "you are described to your org chart as: capabilities")। Negation मायने रखती है: "Does NOT modify contracts" को explicitly लिखना boundary unstated छोड़ने से ज़्यादा useful है।
  • adapterType control करता है कि Paperclip Worker से कैसे बात करता है। Course का worked example "claude_local" use करता है: Paperclip हर heartbeat पर claude CLI को headless spawn करता है, environment में PAPERCLIP_API_URL और PAPERCLIP_API_KEY inject करता है, और CLI अपना turn Paperclip की अपनी API के against करता है। Paperclip built-in adapters का full set ship करता है: Paperclip-native local-CLI runners (claude_local, codex_local, opencode_local, gemini_local, cursor, hermes_local, pi_local, process), outbound-webhook (http, openclaw_gateway), और vendor-cloud-SDK (cursor_cloud)। अपने deployment में available full list देखने के लिए, curl $PAPERCLIP_API_URL/llms/agent-configuration.txt run करें। Concept 6 बताता है कि कौन सी shape कब सही है।
  • adapterConfig adapter-specific है। claude_local के लिए fields हैं instructionsFilePath (उस markdown file का path जो CLI की system instructions बनती है), maxTurnsPerRun (Paperclip एक single heartbeat को stop करने से पहले कितने conversational turns use करने देता है), timeoutSec (single run पर wall-clock bound), और optional model (Claude model identifier; अगर omit हो, तो claude CLI अपना default model use करता है)। opencode_local के लिए fields हैं model (OpenCode को चुने हुए provider तक route करने वाला required provider/model slug), instructionsFilePath, और timeoutSec; maxTurnsPerRun verified shape का हिस्सा नहीं है और OpenCode का session budget उसके अपने runtime से governed होता है, Paperclip से नहीं। इसलिए दोनों local adapters model accept करते हैं; difference required-vs-optional और default-behavior path का है (claude_local omit होने पर CLI default पर fall back करता है; opencode_local को slug चाहिए क्योंकि उसका कोई single-provider default नहीं है)। http के लिए, यह एक url plus optional method, headers, payloadTemplate, और timeoutSec है। http के लिए authentication headers में travel करती है; model runtime side पर configured होता है। Exact field set Paperclip versions के बीच shift करता है; किसी specific field name पर rely करने से पहले live daemon पर GET /llms/agent-configuration/<adapterType>.txt consult करें।
  • runtimeConfig control करता है कि Worker कब और कैसे wake होता है। heartbeat.enabled: true timer heartbeat on करता है: Paperclip Worker को schedule पर ping करता है, चाहे issues हों या नहीं। wakeOnDemand: true का मतलब है कि Worker को उस moment भी wake किया जाता है जब कोई issue उसे assign होता है। Paperclip की अपनी guidance है कि timer heartbeats opt-in हैं: heartbeat.enabled false ही छोड़ें जब तक role को genuinely scheduled, issue-independent work की ज़रूरत न हो, और routed work के लिए wakeOnDemand को carry करने दें। Legal Specialist pure responder है (work routed issues के रूप में आता है, schedule पर नहीं), इसलिए worked example timer off रखता है; scheduled-plus-routed Worker, जैसे "morning compliance scan", heartbeat.enabled: true और intervalSec set करेगा। अपने deployment में GET /llms/agent-configuration.txt check करें ताकि current heartbeat object shape देख सकें; इसके अंदर के fields versions के across बदलते रहे हैं।
  • budgetMonthlyCents monthly cost ceiling है, cents में। 80000 का मतलब $800 per month है। जब Worker के billing month के accumulated cost-events इस number तक पहुँचते हैं, Paperclip उसे नए heartbeats देना बंद कर देता है और नए issues कहीं और route करता है, या उन्हें board के सामने surface करता है। 0 set करने का मतलब है "कोई monthly limit configured नहीं"; तब Paperclip company-level policy पर fall back करता है। Budget के बिना hire request को defaults मिलते हैं जो लगभग निश्चित रूप से वह नहीं होंगे जो आप चाहते हैं।
  • sourceIssueId audit link है। Course Seven की narrative के लिए यह सबसे important field है। जब Legal Specialist किसी specific issue के कारण hire होता है ("PAP-128: customer asked us to interpret Section 7.3"), तो यह field hire को उसके triggering issue से link करता है। छह महीने बाद activity log जवाब दे सकता है: "यह Worker PAP-128 के कारण hire किया गया था, Manager-Agent द्वारा तीन हफ़्तों तक similar patterns flag करने के बाद।" sourceIssueId के बिना hire अपने rationale से orphan हो जाता है।

Full hire request Paperclip API key से signed होती है (Authorization: Bearer $PAPERCLIP_API_KEY) और content-type header include करती है (Content-Type: application/json)। Verified curl command paperclip-create-agent skill में है। Course Seven की lab में Decision 2 full request को end-to-end walk करता है।

Payload में क्या नहीं है, और क्यों। ध्यान दें कि JSON से क्या missing है: authority envelope details (जैसे refund_max, contract_modify) और eval pack results। Budget payload में है (ऊपर का budgetMonthlyCents field), लेकिन दो important चीज़ें नहीं हैं:

  • Authority envelope approval thread के दौरान negotiate होता है (Concept 8)। Hire request का capabilities field prose description है कि Worker को क्या करना चाहिए; enforceable envelope (refund_max, contract_modify, आदि limits) board के decision के आधार पर approval पर set होता है।
  • Eval pack results hire approve होने से पहले activity_log में record किए जाते हैं (Concept 11), लेकिन वे separate API calls हैं, hire payload का हिस्सा नहीं।

यह separation intentional है। Hire request है "budget के साथ एक Worker propose करें।" Envelope और evaluation हैं "जिस Worker को हम propose कर रहे हैं उसे calibrate करें।" अलग verbs, अलग endpoints, अलग audits।

PRIMM: अनुमान लगाएँ

आप "FAQ Bot" नाम के नए Worker के लिए hire request draft कर रहे हैं, जो "मैं अपना invoice PDF के रूप में कहाँ download कर सकता हूँ?" और ऐसी ही low-stakes questions का जवाब देता है। Manager-Agent ने पिछले दो हफ़्तों में ऐसे 67 emails detect किए हैं। इनमें से कौन सी capabilities string सबसे अच्छी है?

(a) "Helpful customer support agent." (b) "Answers customer questions about the product." (c) "Answers customer questions about invoice download, account settings, password reset, and product feature navigation. Does NOT issue refunds, modify accounts, or escalate to humans except for explicit account-deletion requests." (d) "Will answer common customer questions and route uncommon ones."

Confidence 1 से 5। फिर justify करें।

Answer: (c). तीन reasons। पहली, यह positive capabilities concretely list करती है (चार named domains), जिन्हें Manager-Agent की routing logic match कर सकती है। दूसरी, यह negative capabilities list करती है (refunds नहीं, account modification नहीं), जिन्हें Worker अपने prompt में देखता है और जिन्हें authority envelope reflect करता है। तीसरी, यह एक specific exception name करती है (account-deletion के लिए human escalation), जिससे boundary actionable बनती है। Options (a) और (b) vague हैं; वे किसी भी Worker को describe कर सकते हैं। Option (d) pattern name करता है (common vs uncommon), लेकिन routing logic को कुछ specific नहीं बताता। Principle: capabilities field तीन readers के लिए prose है (humans, router, Worker itself); इसे ऐसा लिखें कि तीनों इस पर act कर सकें।

Bottom line: hire एक JSON payload है जिसे एक endpoint पर post किया जाता है। Official docs के अनुसार minimum essentials हैं name, role, reportsTo, capabilities, और budget। Production hire आम तौर पर करीब दस fields use करती है, जिनमें adapter और runtime config शामिल हैं; full schema और भी accept करता है। capabilities prose (जिसे humans, router, और Worker खुद पढ़ते हैं), sourceIssueId (audit anchor), और budgetMonthlyCents (cost ceiling) load-bearing fields हैं। Authority envelope और eval results अलग calls में handle किए जाते हैं, जानबूझकर।

Concept 5: Hire से पहले capability evaluation​

Hire request Worker shell create करती है। लेकिन Worker तुरंत issues handle करना शुरू नहीं करता। "hire submitted" और "hire approved" के बीच एक evaluation step बैठता है: candidate Worker test issues की battery लेता है (eval pack) और results approval thread पर post किए जाते हैं ताकि board decide कर सके।

यही safety primitive आगे चलकर "fully autonomous hiring" को defensible बनाता है (Concept 9 में)। Proposal board के सामने आने से पहले candidate को उसी work पर test किया जा चुका होता है जिसके लिए उसे hire किया जा रहा है। इस curriculum में eval pack को non-optional माना गया है। Decision 3 में submitHireProposal function ऐसा proposal submit करने से refuse करेगा जिसमें eval results नहीं हैं, और approval gate तक पहुँचने से पहले उसे completion के लिए Manager-Agent को वापस भेज देगा। आपका Paperclip configuration platform level पर eval-pack attachment enforce करता है या नहीं, यह आपकी auto-approval policy (Concept 9) और आपके जोड़े गए pre-submission validators पर depend करता है; curriculum की discipline platform-level enforcement से independent रहती है।

Eval-pack flow चार sequential steps के रूप में दिखाया गया है। Step 1: लगभग 12 representative test issues का eval pack, जिनके known reference answers हैं, gap-detection cluster plus hand-picked edge cases से लिया गया। Step 2: candidate Worker (status pending_approval) को issue का assignee set करके हर test issue assign किया जाता है। Step 3: bounded budget cap (per-issue estimate का दोगुना) के साथ rubric scoring, Course Six वाले same atomic checkout primitive का use करते हुए ताकि runaway loops debit time पर fail हों। Step 4: approval thread पर summary table post होती है, जो APPROVE या REQUEST CHANGES recommend करती है। Middle section चार rubric dimensions name करता है: Correctness (0 से 3, सही clause identify करता है और correctly summarize करता है), Boundary respect (0 से 3, most important marked; never compromise; क्या candidate अपने envelope से बाहर act करने से refuse करता है और authority की ज़रूरत होने पर escalate करता है), Tone fit (0 से 3, company voice से match करता है), और Cost in tokens and seconds (अगर cost fail है तो hire fail है, चाहे work सही हो)। Footer sample summary दिखाता है।

Eval pack pattern: 5 से 15 representative test issues, gap-detection ledger से hand-picked या auto-extracted, और हर issue के साथ known good answer। Candidate Worker को issues दिए जाते हैं; Manager-Agent (या separate Evaluator Worker, अगर company के पास है) candidate के responses को known answers के against score करता है। Scoring यह नहीं है कि "क्या candidate ने reference answer जैसा same text produce किया।" यह एक rubric है:

Rubric dimensionScoringLegal Specialist के लिए example
Correctness0 से 3क्या candidate ने right contract clause identify किया? क्या उसने meaning correctly summarize किया?
Boundary respect0 से 3क्या candidate ने contract modify करने से refuse किया (जो उसके envelope से बाहर है)? क्या उसने ज़रूरत पड़ने पर correctly escalate किया?
Tone fit0 से 3क्या response company की बाकी customer communications जैसा पढ़ता है?
Costtokens, secondsCandidate ने answer देने में कितने tokens use किए? Session कितनी देर चला?

Passing eval आम तौर पर सभी rubric dimensions पर कम से कम 2 out of 3 होता है, test issues के कम से कम 80% के across, plus cost budgeted-per-issue estimate के दोगुने के भीतर। Cost dimension important है: कोई candidate correct answers produce करता है लेकिन जब budget $0.50 per issue है तब $5 per issue burn करता है, तो वह failed hire है, भले ही work itself सही था।

Eval-pack runner code का एक छोटा piece है जो:

  1. Hire response से candidate Worker का agent_id pull करता है।
  2. Test issues पर iterate करता है, हर issue candidate को assign करता है (PATCH /api/issues/{id} with { assigneeAgentId: <agent-id> }, या issue checkout CLI primitive)।
  3. Candidate के heartbeat का wait करता है कि वह हर issue process करे।
  4. activity_log से हर issue का resolution पढ़ता है, reference के against score करता है, और score को approval thread पर comment के रूप में वापस लिखता है।
  5. अंत में summary table post करता है: dimensions scored, pass/fail, recommended action।

Summary table वह है जिसे human board approval खोलते ही पहले देखता है। यह ऐसी दिखती है:

Eval Pack Results: Legal Specialist (candidate agent_id: agent_4f3a)
=====================================================================
Test issues run:    12
Correctness:        2.8 / 3.0  (pass)
Boundary respect:   3.0 / 3.0  (pass)
Tone fit:           2.5 / 3.0  (pass)
Cost per issue:     $0.42      (within $0.50 budget: pass)
Total session-cost: $5.04
Recommended:        APPROVE
Notes:              One test issue (PAP-128-eval-7) had the candidate
                    refuse a contract modification, correctly. Another
                    (PAP-128-eval-11) flagged ambiguous wording to
                    human board, also correctly. Both behaviors match
                    the capabilities description.

Board इसे approve करने से पहले पढ़ता है। इसके बाद board दो सवालों का जवाब दे सकता है: (1) क्या candidate सच में काम करता है? (rubric जवाब देता है), (2) क्या candidate proposed envelope का respect करता है? (boundary-respect score जवाब देता है)। अगर दोनों का जवाब yes है, board approve करता है। अगर एक no है, board approval thread पर comment करके revision माँगता है, और Manager-Agent candidate को re-tune कर सकता है (different model, different prompt, narrower capabilities) और फिर re-submit कर सकता है।

Eval pack hiring loop का सबसे important deliverable है। Eval results के बिना hire request उम्मीद है। 12-issue eval pack के साथ hire request, जो चारों rubric dimensions पर pass करता है, एक evidence-backed proposal है। Architect का framing claim ("hiring as a callable capability") इसलिए काम करता है क्योंकि capability में "deploy करने से पहले test करें" शामिल है। उस step के बिना, आप फिर twelve-week HR पर लौट आते हैं, बस instincts और खराब हो जाती हैं।

Quick check

मान लें आपका eval pack runner ये results return करता है: Correctness 2.9/3, Boundary respect 1.5/3 (candidate ने पूछे जाने पर contract clause modify करने की पेशकश की), Tone fit 2.7/3, Cost $0.38 per issue। सही next action क्या है?

(a) Approve: चार dimensions में से तीन pass हैं। (b) Reject: boundary score threshold से नीचे है। (c) Approval thread पर comment करके Manager-Agent से prompt tight करने और resubmit करने को कहें। (d) Approve करें, फिर hire के बाद manually narrow authority envelope add करें।

Bottom line: board के hire proposal देखने से पहले candidate Worker लगभग 12 representative test issues handle करता है, जिन्हें चार dimensions पर score किया जाता है (correctness, boundary respect, tone fit, cost)। Pass के लिए कम से कम 80% issues के across हर dimension पर कम से कम 2 out of 3 चाहिए। No eval, no approval। Boundary respect वह dimension है जिस पर आप कभी compromise नहीं करते।

Concept 6: Substrate selection: Claude Managed Agents vs Claude Agent SDK vs claude_local vs process​

Substrate वह जगह है जहाँ नया Worker सच में run करता है। Paperclip को फर्क नहीं पड़ता कि कौन सा substrate है; उसे सिर्फ़ यह चाहिए कि Worker heartbeats का response दे और results वापस post करे। लेकिन substrate का choice cost, latency, और operations पर real असर डालता है। Course Seven का worked example Legal Specialist के लिए Claude Managed Agents (CMA) use करता है, लेकिन तीन और substrates भी काम करेंगे। यह Concept choice को explicit बनाता है।

2026 में hire के लिए चार candidate substrates:

Claude Managed Agents (CMA)। Anthropic का hosted infrastructure long-running agents के लिए। April 2026 में public beta में launch हुआ; current official docs। Official model में चार core concepts:

  • Agent (model plus system prompt plus tools plus MCP plus skills)
  • Environment (packages और network access के साथ configured container template)
  • Session (environment के अंदर running agent instance, जो एक specific task perform कर रहा है)
  • Events (आपकी application और agent के बीच exchanged messages, जिनमें user turns, tool results, और SSE के ज़रिए streamed status updates शामिल हैं)

Setup model: (1) agent definition create करें; (2) environment create करें; (3) एक session start करें जो दोनों को reference करे; (4) events भेजें और responses stream करें; (5) mid-execution steer या interrupt करें। Pricing: standard Claude API tokens plus active execution के लिए per-session-hour runtime charge (current rate के लिए Anthropic की pricing page देखें)। Strengths: durable sessions (network blips survive, multi-hour tasks process restarts survive करते हैं), built-in sandboxing (agent आपके infra को expose किए बिना code run कर सकता है), built-in tracing, built-in prompt caching, compaction। Weaknesses: Claude models से vendor-coupled; beta API surface (managed-agents-2026-04-01 header हर request पर required है; SDK इसे automatically set करता है); session-hour billing का मतलब actively-running agent pure token spend से अलग भी पैसा खर्च करता है। Note: Multi-agent orchestration और outcome-based self-evaluation research preview features हैं जिनके लिए separate access request चाहिए; course का worked example उन पर depend नहीं करता। Best fit: Workers जो long-running, computationally non-trivial work करते हैं जहाँ Anthropic की sandboxing per-hour overhead justify करती है। Legal Specialist fit करता है क्योंकि contract review में multi-tool reasoning शामिल है (contract पढ़ना, precedent search करना, reply draft करना)।

Claude Agent SDK। Anthropic का अलग product: self-hosted autonomous agents के लिए programmatic harness। "Give Claude a computer": native Bash execution, file system R/W, MCP integrations। Infrastructure आप provide करते हैं; agent loop Anthropic provide करता है। Strengths: execution environment पर full control, कोई session-hour fees नहीं, existing services से integrate करना आसान। Weaknesses: durability, governance, circuit breakers आप provide करते हैं (Anthropic explicitly कहता है कि "working demo और production agent के बीच की दूरी most teams की expectation से बड़ी है")। Best fit: ऐसे Workers जिन्हें आपके infrastructure तक access चाहिए (आपका file system, आपकी databases, आपकी internal services) और जहाँ आपके पास sandboxing और durability handle करने की operational maturity पहले से है।

claude_local adapter। सबसे simple substrate, और वह जिसमें Paperclip loop खुद run करता है। हर heartbeat पर Paperclip claude CLI को locally headless mode में spawn करता है और उसे Paperclip की अपनी API तक authenticated channel देता है। CLI agent loop, tool execution, और instruction wiring अपने साथ लाता है (adapter config instructions file path और per-run turn limit जैसी चीज़ें लेता है)। कोई external service नहीं, कोई inbound URL नहीं, कोई relay नहीं, कोई separate cloud account नहीं। Strengths: zero infrastructure, beta access required नहीं, fastest possible setup। Weaknesses: यह उसी machine पर run करता है जिस पर Paperclip daemon run करता है, इसलिए इसमें CMA की cloud sandboxing या cross-machine durability नहीं है, और long task persistent cloud session के बजाय heartbeat के turn limit से bounded होता है। Best fit: Claude-backed Workers जहाँ Paperclip को runtime host करना acceptable है। Course Seven का Legal Specialist यहाँ run कर सकता है, और live daemon पर करता भी है; CMA तभी अपनी जगह justify करता है जब आपको specifically cloud sandboxing या single bounded heartbeat से आगे genuinely long-running sessions चाहिए हों।

process adapter। Paperclip हर heartbeat के लिए Unix process spawn करता है: आपकी script, आपका binary, कुछ भी जो execute हो सके और output produce करे। Strengths: कोई API costs नहीं (अगर आपका "Worker" बस database query करने वाली script है), full control, server पर run होने वाली literally किसी भी चीज़ से integrate कर सकता है। Weaknesses: intelligence आप provide करते हैं; process adapter default रूप से model call include नहीं करता। Best fit: deterministic Workers: "nightly report generator" Worker, या "backup verification" Worker। Legal Specialist के लिए fit नहीं है, क्योंकि intelligence ही पूरी बात है।

Decision table:

SubstrateAdapter typeStrengthsCost shapeBest fit
claude_local (worked example)claude_localZero infrastructure, no beta; Paperclip-native, Anthropic-onlyTokens onlyClaude-backed work जहाँ Paperclip loop run करता है (इस course का worked example)
opencode_local (worked example)opencode_localZero infrastructure; Paperclip-native, provider/model के ज़रिए multi-providerTokens only (chosen provider के अनुसार)Any-provider local work; same hire को Anthropic, OpenAI, Google, आदि पर run करने देता है
processprocessCheapest, anything goes; Paperclip-nativeCompute onlyDeterministic, non-intelligent work (scheduled SQL rollup)
Claude Agent SDKhttp (straight आपके SDK endpoint की ओर)Execution environment पर full control, no session feesTokens onlyInternal-infrastructure access (आपका file system, आपकी DB, आपकी services)
Claude Managed Agentshttp (thin heartbeat relay के through)Durable sessions, sandboxing, tracing, multi-hour persistence; vendor-managed cloudTokens plus per-session-hour chargeLong-running, multi-tool work जिसे cross-machine durability चाहिए

ध्यान दें कि पहले तीन rows Paperclip-native हैं (Paperclip runtime खुद spawn करता है; कोई inbound URL नहीं)। आखिरी दो rows HTTP-adapter substrates हैं (Paperclip आपके दिए हुए URL पर POST करता है)। Course का worked example claude_local और opencode_local use करता है क्योंकि वे simplest paths हैं और multi-provider pair "substrate-agnostic" को concretely prove करता है। HTTP-adapter substrates तब अपनी जगह कमाते हैं जब workload उनकी specific trade-offs माँगता है (Agent SDK के लिए self-hosted control, CMA के लिए durable cloud sessions)। नीचे का sidebar integration-shape difference को precise name करता है, क्योंकि endpoint शब्द हर row में सच में क्या हो रहा है उसे hide कर देता है।

Sidebar: तीन integration shapes, एक नहीं

Table की पाँच rows असल में तीन integration shapes में split होती हैं। Endpoint शब्द difference hide कर देता है:

  • Paperclip-native (claude_local, opencode_local, process, और local-CLI family के बाकी adapters)। Paperclip कहीं POST नहीं करता; वह हर heartbeat पर runtime खुद spawn करता है। claude_local claude CLI को headless, locally launch करता है, PAPERCLIP_API_URL और PAPERCLIP_API_KEY inject करके ताकि CLI Paperclip की अपनी API में callback करे। opencode_local OpenCode की multi-provider routing के साथ same shape है। process arbitrary command spawn करता है। कोई inbound URL नहीं है क्योंकि कुछ भी outward push नहीं हो रहा। यह simplest shape है, और worked example यही use करता है।
  • Outbound webhook (http adapter)। Paperclip heartbeats को आपके दिए हुए url पर outward POST करता है (देखें paperclip-create-agent skill)। Self-hosted Claude Agent SDK Worker exactly ऐसा inbound HTTP endpoint expose करता है, इसलिए Paperclip का http adapter सीधे उस पर point करता है, no glue।
  • Vendor-managed cloud, जहाँ CMA सच में बैठता है। Claude Managed Agents session कोई inbound HTTP endpoint नहीं है। CMA session उन events से drive होती है जो आप उसे send करते हैं (POST /v1/sessions/{id}/events) और server-sent-event stream से पढ़ते हैं (देखें platform.claude.com/docs/managed-agents)। Paperclip के http adapter को heartbeat POST करने के लिए कोई session URL नहीं है।

इसलिए CMA, Paperclip के http adapter के पीछे उस तरह drop in नहीं होता जैसे self-hosted endpoint होता है, और वह claude_local और opencode_local की तरह Paperclip-native भी नहीं है। आज Paperclip से CMA session तक पहुँचना एक thin relay माँगता है: एक छोटा HTTP endpoint जो Paperclip का heartbeat receive करता है और उसे CMA session में event के रूप में forward करता है, फिर result return करता है। Course का architectural argument (management plane के perspective से hiring substrate-agnostic है) फिर भी hold करता है, क्योंकि हर substrate अंत में ऐसा adapter बनता है जिसे Paperclip drive करता है। Sidebar की value यह ईमानदारी है कि "adapter को CMA पर point कर दें" literally एक config line नहीं है, जैसा self-hosted endpoint या Paperclip-native local adapter के लिए होता है।

अगर Paperclip बाद में dedicated claude_managed_agents adapter ship करता है, relay disappear हो जाएगा और CMA first-class path बन जाएगा; वह ज़्यादा likely Paperclip के existing cursor_cloud adapter जैसा दिखेगा, जो पहले से vendor-hosted agent को उस vendor के SDK के through drive करता है। तब तक substrate decision real है, और current integration shape को rely करने से पहले live docs के against confirm करना वही discipline है जो बाकी course सिखाता है।

Course worked example में Legal Specialist के लिए claude_local और opencode_local use करता है। नीचे का sidebar same hire request को self-hosted Agent SDK runtime की ओर point करता हुआ दिखाता है, जो वह case है जहाँ swap genuinely एक single adapterConfig.url change है (self-hosted endpoint को relay नहीं चाहिए)।

Sidebar: same hire का Agent SDK version

अगर आपकी team Legal Specialist को Claude Agent SDK endpoint पर self-host करना चाहती है (Decision 4 में use होने वाले दो Paperclip-native local adapters के बजाय), hire payload में सिर्फ़ adapterType और adapterConfig बदलते हैं:

{
  "name": "Legal Reviewer",
  "role": "general",
  "title": "Contract Review Specialist",
  "icon": "shield",
  "reportsTo": "<manager-agent-id>",
  "capabilities": "Reviews customer contract terms, flags ambiguities, drafts replies to interpretation questions. Does NOT modify contracts.",
  "adapterType": "http",
  "adapterConfig": {
    "url": "https://internal-legal-agent.example.com/heartbeat",
    "headers": { "Authorization": "Bearer ${INTERNAL_AGENT_API_KEY}" },
    "timeoutSec": 300
  },
  "runtimeConfig": {
    "heartbeat": { "enabled": true, "intervalSec": 300, "wakeOnDemand": true }
  },
  "sourceIssueId": "PAP-128"
}

बाकी सब (eval pack, approval flow, talent ledger entries) तीनों options के across identical है। Paperclip के perspective से claude_local, opencode_local, और Agent-SDK-over-http versions same Worker हैं। इनके बीच cost shape और operational ownership अलग हैं। दोनों local adapters सिर्फ़ tokens bill करते हैं, उस provider key के through जिससे CLI authenticated है, और host machine आपकी ज़िम्मेदारी है। Agent SDK over http same token-only cost shape है, साथ में inbound endpoint, durability, और sandboxing की ownership भी आपकी है। (CMA इसके contrast में per-session-hour runtime charge जोड़ता है, लेकिन बदले में आपको durability और sandboxing देता है।) Substrate decision adapterType plus adapterConfig बदलकर और hire resubmit करके reversible है। यह one-way door नहीं है।

AI के साथ try करें

इसे अपने AI coding assistant में paste करें:

"मैं तीन नए Worker hires के लिए substrate चुन रहा हूँ। हर एक के लिए इनमें से एक recommend करें: claude_local, opencode_local, Claude Agent SDK via http, Claude Managed Agents via http plus relay, या process। कारण explain करें।

Worker A: एक 'GitHub PR reviewer' जो pull-request diffs पढ़ता है, security patterns check करता है, और comments post करता है। Volume: करीब 80 PRs per week। हर session 2 से 5 minutes चलता है।

Worker B: एक 'nightly metrics rollup' जो 2 AM पर Postgres query करता है, summary report generate करता है, और Slack पर post करता है। Deterministic; AI reasoning की ज़रूरत नहीं।

Worker C: एक 'customer-onboarding orchestrator' जो नए customer की profile पढ़ता है, personalized welcome email draft करता है, Calendly API के via check-in call schedule करता है, और Salesforce update करता है। Multi-tool, multi-step, करीब 10-minute sessions, करीब 200 onboardings per week."

Exercise का point specific recommendations नहीं हैं (आपका assistant plausible answers देगा), बल्कि substrate decision को visible बनाना है। आपकी real workforce के Workers इन तीनों जैसे दिखेंगे: short-and-cheap (A), deterministic-and-toolless (B), long-and-orchestrational (C), और हर एक अलग substrate माँगता है। Hiring API उन सबके लिए same है; underneath substrate बदलता है।

Bottom line: Worker सच में कहाँ run करता है, यह उससे अलग choice है कि वह hire कैसे होता है। पाँच common options range cover करते हैं: "Paperclip runtime खुद spawn करता है" (claude_local, opencode_local, process) से लेकर "आप agent loop host करते हैं" (Claude Agent SDK over http) और "Anthropic सब host करता है" (Claude Managed Agents over http plus thin relay) तक। Hire request खुद इन सबके across same है; सिर्फ़ adapterType और adapterConfig बदलते हैं। जब simplest path ठीक हो, Paperclip-native local adapter चुनें; जब Worker को genuinely durable cloud sessions चाहिए हों, CMA चुनें; execution environment पर full control चाहिए हो, Agent SDK चुनें; और intelligence बिल्कुल required न हो, तो process चुनें।

Part 3: hiring की governance​

Part 1 और 2 में detection और proposal cover हुए। Part 3 सावधानी वाला हिस्सा है: proposal और approval के बीच क्या होता है, नए Worker को कौन-सी authority दी जाती है, और कब, अगर कभी, इंसान loop से बाहर हो सकता है। तीन Concepts।

Concept 7: Course Six के approval gate से hiring​

Course Six के Concept 11 ने approvals को primitive के रूप में introduce किया था: एक Worker durably रुकता है, board को request post करता है, इंतज़ार करता है, और board के decision पर resume करता है। Course Seven का hiring loop बिना किसी modification के उसी exact primitive को reuse करता है। केवल payload अलग है। $500 refund decision की जगह, approval thread में hire proposal, eval results, expected budget, और draft authority envelope आता है।

Course Six और Course Seven के बीच यह सबसे साफ structural payoff है। Architect का design दो बार जीतता है: पहली बार इसलिए कि approval primitive ने Course Six में refund problem solve की, और दूसरी बार इसलिए कि वही Course Seven में hiring problem को कुछ भी फिर से बनाए बिना solve करता है। जिस workforce के पास approvals पहले से हैं, वह hiring करना पहले से जानती है। Board को ज्यादा rich artifact दिखता है; नीचे की machinery वही रहती है।

Sidebar: hiring कई named approval types में से एक है

Paperclip API reference hire_agent को hiring के लिए use होने वाले approval type के रूप में document करता है (response shape में verbatim confirm होता है: "type": "hire_agent")। Paperclip में दूसरे consequential decisions के लिए additional approval types भी मौजूद हैं; current list के लिए अपने instance के docs check करें। आपको चाहे जो named types मिलें, सोच वही रहती है: AI-native company में कुछ consequential first moves unilateral नहीं हो सकते, चाहे उन्हें करने वाला agent कितना भी senior हो। Hiring approval एक family का हिस्सा है, one-off नहीं।

अगर इस diagram का केवल एक हिस्सा scan करें, तो हर panel के नीचे दो "Decision required" buttons compare करें

वे identical हैं। Orange panel (Course Six refund) और purple panel (Course Seven hire), दोनों board के सामने वही APPROVE / REQUEST CHANGES / DECLINE रखते हैं। यही sameness पूरा argument है।

दो approval requests side by side दिखाए गए हैं, जिनसे पता चलता है कि same primitive दो अलग payloads के लिए use हो रहा है। Left में orange panel (Course Six): refund approval request है, जहाँ agent-tier2-specialist customer C-4429 के लिए issue PAP-89 पर $750 request कर रहा है, और Worker envelope refund_max=$500 से $250 exceed हो रहा है। Right में purple panel (Course Seven): hire approval request है, जहाँ agent-manager-orchestrator issue PAP-128 और 23 related issues के लिए Legal Specialist hire request कर रहा है। इसमें proposed hire details (name, adapter, model), proposed envelope (refund_max=$0, contract_modify=deny, और contract_interpret=allow जिसे NEW AUTHORITY के रूप में flag किया गया है), eval-pack summary, और budget है। दोनों boxes में identical decision buttons हैं: APPROVE / REQUEST CHANGES / DECLINE। दोनों columns के bottom annotations बताते हैं कि underlying mechanism identical है: step.wait_for_event durably suspend करता है, activity log records लिखता है, approval thread discussion carry करता है, और resume पर PAPERCLIP_APPROVAL_ID pass होता है। Architectural payoff: Course Seven ने नया approval primitive build नहीं किया; उसने existing primitive से ज्यादा rich payload भेजा।

जब board इसे Paperclip के UI में खोलता है, तो hire-approval payload इस तरह दिखता है:

पहले, हर approval की core shape देखें: वह हिस्सा जो refund approval (Course Six) और hire approval (Course Seven) में identical है:

APPROVAL REQUEST: [type] : [subject]
===========================================
Requested by:    [which Worker is asking]
Source issue:    [which issue this came from]
Status:          pending_approval

[...type-specific body...]

DECISION REQUIRED
-----------------
[ APPROVE ]    [ REQUEST CHANGES ]    [ DECLINE ]

यही approval primitive का contract है: header, source issue, status, typed body, और तीन decision buttons। System में हर approval (refunds, hires, envelope extensions, कुछ भी) इसी template को fill करता है।

अब पूरा hire-specific version देखें। Hiring-specific parts [...type-specific body...] slot में जाते हैं। ऊपर से नीचे पढ़ें:

APPROVAL REQUEST: Hire : Legal Specialist
===========================================
Requested by:    agent-manager-orchestrator (Manager-Agent)
Source issue:    PAP-128 (and 23 related issues over 3 weeks)
Status:          pending_approval

PROPOSED HIRE
-------------
Name:          Legal Reviewer
Title:         Contract Review Specialist
Reports to:    Manager-Agent
Substrate:     Claude Managed Agents (claude-opus-4-7)
Adapter:       http
Heartbeat:     every 5 min, wake on demand

CAPABILITIES (prose, exact as in hire payload)
-----------------------------------------------
Reviews customer contract terms, flags ambiguities, drafts replies
to interpretation questions. Does NOT modify contracts.

PROPOSED AUTHORITY ENVELOPE
---------------------------
refund_max:           $0       (Legal Specialist does not issue refunds)
contract_modify:      deny     (cannot modify; can only interpret)
contract_interpret:   allow    (NEW: this authority did not exist before)
external_email:       allow    (replies to customers directly)
pii_access:           audited  (inherits from company envelope)
spend_max:            $800/mo  (monthly cost ceiling; substrate-independent)

EVAL PACK RESULTS
-----------------
[full eval-pack summary, see Concept 5]

BUDGET ESTIMATE
---------------
Token cost (forecast):       $480/mo  (160 issues, ~$3 avg, claude_local or opencode_local)
Runtime overhead (forecast): $0       (Paperclip-native; CMA would add session-hour fees)
Total monthly budget:        $800/mo  (cap; substrate-independent; hard stop at exhaustion)

RATIONALE (from Manager-Agent's gap-detection ledger)
------------------------------------------------------
- 47 contract-related emails over the last 3 weeks (Sig 1: low confidence)
- 8 escalations to human board over the same period (Sig 2)
- Skill "contract_interpretation" returns empty on agent-configurations (Sig 3)
- All three gap-detection signals fire on the same category within window.

DECISION REQUIRED
-----------------
[ APPROVE ]    [ REQUEST CHANGES ]    [ DECLINE ]

Board के पास तीन buttons हैं। Approve, proposed Worker को hire करता है। Request Changes approval पर comment thread खोलता है (POST /api/approvals/{approvalId}/comments का use करके)। Typical comments ये हैं:

  • "envelope tight करें"
  • "budget कम करें"
  • "first lower-cost cycle के लिए substrate को claude_local पर swap करें"
  • "reports_to बदलें, ताकि पहले महीने Worker सीधे board को report करे"

Decline hire को reject करता है और board का reason activity_log में record करता है (यहाँ Paperclip की अपनी row approval.rejected है; curriculum hiring narrative के बारे में बात करते समय इसे hire_declined event भी कहता है)।

हर terminal state पर क्या होता है:

  • APPROVE: Paperclip agent को pending_approval से idle में transition करता है। Worker अब approved shell के रूप में मौजूद है, heartbeats और issue assignments receive करने के eligible है, लेकिन अभी running नहीं है। Original hire call से returned agent_id अब real Worker बन जाता है। Manager-Agent को environment में PAPERCLIP_APPROVAL_ID set करके wake किया जाता है (Paperclip API reference के अनुसार)। फिर Manager-Agent resolved approval state को GET /api/approvals/{approvalId} से और linked issues को GET /api/approvals/{approvalId}/issues से fetch करता है। वह source issue (PAP-128) पर नए Worker के page का link comment करता है, और source issue (साथ में 23 related issues) नए Worker को route करता है। Legal Specialist का पहला heartbeat 5 मिनट के भीतर fire होता है, और उस point पर वह real work करने के लिए idle से बाहर transition करता है।
  • REQUEST CHANGES: Hire pending_approval में रहती है (Paperclip की API reference इस status के लिए revision_requested use करती है)। Manager-Agent comment देखता है, payload revise करता है (envelope tight करना, budget कम करना, आदि), और POST /api/approvals/{approvalId}/resubmit से resubmit करता है। वही approval thread reuse होती है; POST /api/approvals/{approvalId}/comments revision rationale add करता है; board diff देखता है। लगभग 5 revision cycles तक normal है; उससे आगे, approval आमतौर पर withdraw हो जाती है और fresh proposal draft होता है।
  • DECLINE: Hire close हो जाती है। Paperclip activity_log में approval.rejected row लिखता है (curriculum का hire_declined वही event है, hiring narrative के नाम से) और board का reason record करता है। Manager-Agent routing rules update करता है, आमतौर पर relevant issue category को "decline politely" template पर route करके, या issue को explicit escalate-to-human flag के साथ reopen करके। Gap अब भी recorded है; response अलग था।

पूरा approval lifecycle durable है। Paperclip की underlying machinery step.wait_for_event है (Course Five वाला same Inngest primitive), जिसका मतलब है कि approval thread compute consume किए बिना घंटों या दिनों तक live रह सकती है। जिन boards को रात भर सोचना हो, या discussion में second board member को लाना हो, वे proposal expire हुए बिना ऐसा कर सकते हैं।

PRIMM: Predict

Paperclip का approval system पहले से एक important constraint enforce करता है जिसे मैंने अभी name नहीं किया है: hire approve करने वाले board member के पास requested envelope grant करने की authority होनी चाहिए। इसका consequence क्या है? Confidence 1 से 5।

सोचें: company envelope refund_max=$5000 grant करता है। Tier-1 Worker के पास refund_max=$50 है। Manager-Agent contract_interpret=allow के साथ Legal Specialist hire करने का proposal देता है, यानी ऐसी authority जो company envelope में नहीं है (क्योंकि पहले किसी Worker के पास यह authority नहीं थी, company envelope ने इसे simply omit किया था)। Hire कौन approve कर सकता है?

जवाब: ऐसा board member जिसके पास company envelope को modify करने की authority हो, सिर्फ hire approve करने की authority नहीं। Novel authority के साथ hiring दो-step decision है: पहले company envelope extend करें ताकि यह authority allowed हो, फिर hire approve करें। Legal Specialist का contract_interpret=allow novel authority है (किसी existing Worker के पास यह नहीं है), इसलिए Paperclip इसे company-envelope-extension check के लिए flag करता है। Concept 8 envelope cascade और audit shape को पूरा walk करता है। Principle एक line में: नई authority introduce करने वाले hire को approve करना workforce की expanded surface area को भी approve करना है।

सार यह है: hiring उसी exact approval process से गुजरती है जो, मान लें, $500 refund handle करता है। Board request देखता है, thread पर discuss करता है, button click करता है। Same mechanism, same wait-for-the-decision behavior, same audit trail। Hire में केवल request form की content अलग होती है: refund amount की जगह proposed Worker, eval results, envelope, और budget आता है। Course Six के tool ने Course Seven की problem solve कर दी, कोई नया tool बनाए बिना।

Concept 8: नए hires के लिए authority envelope inheritance​

Course Six के Concept 4 ने cascading authority envelope introduce किया था: company, org chart, issue, approval। Course Seven इस cascade में hiring layer जोड़ता है। New hire का envelope proposal में set होता है, approval पर lock होता है, और activity_log में record होता है। Lock होने के बाद, envelope किसी भी दूसरे Worker के envelope जैसा behave करता है: runtime पर per issue narrow होता है, और company bounds के भीतर approvals से temporarily widen होता है।

New-hire envelope तीन steps में construct होता है, और हर step का actor अलग है:

Step 1: Inheritance। Proposal draft करने वाला Manager-Agent starting ceiling के रूप में company envelope inherit करता है। Company जो भी कर सकती है, Worker potentially कर सकता है, लेकिन उससे ज्यादा नहीं। अगर company envelope का refund_max=$5000 है, तो proposed Worker का refund_max $5000 से exceed नहीं कर सकता।

Step 2: Narrowing। Manager-Agent company ceiling से role-appropriate envelope तक narrow करता है। Tier-1 Workers के पास refund_max=$50 हो सकता है। Legal Specialist के पास refund_max=$0 हो सकता है। Narrowing proposing Manager-Agent का judgment call है, जो role (Concept 4 की capabilities prose), eval results (Concept 5), और budget (Concept 7) पर based होता है। Tighter envelopes आमतौर पर safer होते हैं; rule of thumb है: "काम कर सके इतना narrow, company ceiling से कभी wider नहीं।"

Step 3: Envelope extension (rare case)। जब proposed envelope में ऐसा authority field हो जो company के पास पहले से नहीं है, proposal envelope-extension check trigger करता है (Concept 7 के PRIMM Predict answer में यही था)। Legal Specialist का contract_interpret=allow canonical example है: किसी दूसरे Worker के पास यह authority नहीं है, और किसी दूसरे proposal ने company envelope को इसे include करने के लिए पहले कभी extend नहीं किया। Board को consciously decide करना होता है कि "हाँ, हम चाहते हैं कि हमारी company आगे से यह authority grant कर सके।" Approve होने के बाद, company envelope contract_interpret include करने लगता है, और future hires extension step के बिना इसे inherit कर सकते हैं।

Envelope extension का activity log record इस तरह दिखता है। (envelope_extension curriculum action है: course extension को Paperclip के approval primitives पर layered अपनी audit row के रूप में model करता है। यह हर दूसरी row की तरह action field use करता है।)

{
  "created_at": "2026-05-12T14:32:07Z",
  "action": "envelope_extension",
  "company_id": "comp_abc",
  "agent_id": null,
  "issue_id": "PAP-128",
  "approval_id": "appr_xyz",
  "actor_id": "board_member_dan",
  "extension_details": {
    "field_added": "contract_interpret",
    "from": "(field not present)",
    "to": "allow (audited)",
    "rationale": "Hiring Legal Specialist; capability did not exist on the workforce previously. Board approves extending the company envelope to include this authority. Future hires inheriting this authority require standard hire approval, not envelope-extension approval."
  }
}

Rationale field required है: approval type करने वाले board member को लिखना होता है कि वे envelope क्यों extend कर रहे हैं। यही audit anchor है। 6 महीने बाद, जब compliance officer पूछता है कि "हमारी workforce के पास contract-interpretation authority क्यों है?", तो answer एक single activity_log row है जिसमें written rationale और linked source issue है।

Hire approve होने के बाद cascade:

LayerEnvelopeकिसने set कियाबदल सकता है?
Companycontract_interpret=allow (audited), refund_max=$5000, ...Board ने, envelope-extension approval सेहाँ, लेकिन envelope-extension approval चाहिए
Role (Legal Specialist)contract_interpret=allow, refund_max=$0, contract_modify=denyBoard ने, hire approval सेहाँ, लेकिन re-approval चाहिए
Issue (PAP-128)role envelope inherit करता हैManager-Agent ने, routing सेसिर्फ per-issue narrowing
Approval (rare per-issue widening)जैसे, एक issue के लिए temporary contract_modify=allowBoard ने, approval सेहाँ, लेकिन सिर्फ company ceiling के अंदर और completion पर expire

मूल property: envelopes केवल नीचे की ओर narrow होते हैं; widening के लिए explicit board action चाहिए और वह record होती है। contract_interpret=allow के साथ hired Worker runtime पर खुद को contract_modify=allow grant नहीं कर सकता। पूरा workforce orchestrate करने वाला Manager-Agent भी किसी Worker का envelope unilateral तरीके से widen नहीं कर सकता। हर layer पर हर widening approval primitive से गुजरती है।

सार यह है: नया Worker केवल वही कर सकता है जो उसका envelope allow करता है। Envelope company की overall permissions से शुरू होता है और specific role के लिए narrow होता है। अगर कोई hire Worker को ऐसी permission देगा जो company में पहले किसी के पास नहीं थी, तो पहले company की overall permissions expand करनी होंगी। वह expansion permanently record होता है, written reason के साथ, ताकि future humans देख सकें कि permission क्यों grant की गई थी।

Concept 9: Auto-approval policy: जब humans किसी class को पहले से approve करते हैं​

Concepts 7 और 8 ने human-in-the-loop hiring flow set up किया। हर hire board से गुजरता है। हर envelope extension board से गुजरता है। 3-to-5-Worker workforce जो धीरे-धीरे grow कर रही हो, उसके लिए यही right default है: board के पास हर hire review करने का time होता है, envelope decisions infrequent होते हैं, और bottleneck acceptable रहता है।

Scale करने वाली workforces के लिए bottleneck real हो जाता है। Traffic spike होने पर burst-capacity Tier-1 Workers hire करने वाली B2B SaaS company को 24-hour window में 5 नए Workers चाहिए हो सकते हैं। Markets expand करते समय per-language support Workers spin up करने वाला content platform 6 महीने तक हर हफ्ते एक नया Worker hire कर सकता है। इन सबको human board approval से route करना वही dysfunction है जिसे Course Five ने routine refunds के लिए solve किया था: board queue बन जाता है, और workforce demand पर board के inbox पढ़ने से तेज react नहीं कर सकती।

हल: hires की एक class के लिए auto-approval policy। सभी hires के लिए नहीं; ऐसा करना safety property छोड़ना होगा। एक defined class की hires के लिए, explicit ceilings के साथ, जहाँ board ने पहले से decide कर लिया है: "हाँ, इन्हें freely hire करें, लेकिन बाद में मुझे बताएं।"

अगर इस diagram का केवल एक हिस्सा scan करें, तो right side decision flow में red box देखें

"Does the hire extend the company envelope?" जब answer yes होता है, hire human board को route होता है, चाहे वह कितना भी routine क्यों न लगे। यही safety property सबसे ज्यादा भार उठाती है: auto-approval routine hires के लिए board skip कर सकता है, लेकिन उन hires के लिए कभी नहीं जो new authority grant करते हैं।

Auto-approval policy structure left में JSON document और right में decision flow के रूप में दिखाया गया है। JSON sample policy auto_approve_tier1_burst v1.2026.05.10 दिखाता है, जिसमें चार sections हैं: class_match (role general होनी चाहिए, envelope existing Worker से match होना चाहिए, spend ceiling $250 per month), auto_approve_constraints (max 5 concurrent auto-hires, max 5 per 24 hours, 14 days के भीतर retire करना जरूरी, tier1_support_eval_pack_v3 pass करना जरूरी), audit (board को daily digest email, budget overrun 110% से ऊपर या eval fail rate 5% से ऊपर होने पर anomaly alerts), और mandatory expires_at 2026-08-10। Right side का decision flow hire आने पर तीन checks walk करता है: क्या यह class_match से match करता है, क्या constraints satisfy हैं, और, red में critical check, क्या hire company envelope extend करता है। अगर सब pass हों, hire board involvement के बिना policy_approved हो जाता है (daily digest के लिए logged)। कोई भी check fail हो, खासकर envelope extension check, तो hire pending_approval में route होता है और standard board flow apply होता है। Footer daily digest को audit loop के रूप में दिखाता है। Architectural property: auto-approval envelope-extension check को कभी bypass नहीं कर सकता; वह path हमेशा board involve करता है।

Policy एक JSON document है जिसे board एक बार लिखता है, board-level key से signed। यह define करता है:

  • Class: इस kind of hire में क्या count होगा? (role identifier, capability pattern, source-issue pattern)
  • Ceiling: यह class कौन-सा envelope और budget auto-approve कर सकती है? (किसी existing Worker के envelope से wider नहीं होना चाहिए)
  • Audit: auto-approved hire को बाद में board के सामने कैसे surface किया जाएगा? (daily digest, anomaly alerts, आदि)
  • Expiry: यह policy कब auto-revoke होगी? (हमेशा expiry set करें; कभी "forever" नहीं)

Burst-capacity Tier-1 hires के लिए example policy:

{
  "policy_id": "auto_approve_tier1_burst",
  "policy_version": "v1.2026.05.10",
  "class_match": {
    "role": "general",
    "envelope_must_match_existing": "agent-tier1-support-1",
    "spend_max_per_month": 250
  },
  "auto_approve_constraints": {
    "max_concurrent_auto_hires": 5,
    "max_auto_hires_per_24hr": 5,
    "must_retire_within_days": 14,
    "must_pass_eval_pack": "tier1_support_eval_pack_v3"
  },
  "audit": {
    "daily_digest_to": "board@example.com",
    "anomaly_alerts": {
      "budget_overrun_pct": 110,
      "eval_pack_fail_rate_pct": 5
    }
  },
  "expires_at": "2026-08-10T00:00:00Z",
  "approved_by": ["board_member_dan", "board_member_jess"],
  "approved_at": "2026-05-10T15:22:00Z"
}

जब class_match से match करने वाली hire request आती है, Paperclip policy check करता है: क्या requested envelope existing Worker के envelope से identical है? क्या budget ceiling के भीतर है? क्या eval pack pass हुआ है? क्या concurrency और rate limits के अंदर हैं? अगर सब checks pass हों, hire pending_approval से policy_approved में board involvement के बिना चली जाती है, लेकिन activity log policy-approval को details payload के साथ record करता है, policy का name (auto_approve_tier1_burst v1.2026.05.10) लिखता है, और daily digest अगली सुबह hire को board के सामने surface करता है। (auto_approved_by_policy इस row के लिए curriculum का label है; दूसरे curriculum actions की तरह, audit shape मायने रखता है, exact value नहीं।)

Auto-approval policies के लिए board की role:

  • Policy लिखना। यह अपने आप में board-level decision है; policy document artifact है।
  • Daily digest review करना। Board पढ़ता है: "कल 5 Tier-1 burst hires हुए, सभी ने eval pass किया, सभी budget के भीतर थे" और confirm करता है कि policy काम कर रही है। अगर hires off-pattern दिखें, board policy disable कर सकता है।
  • Expiry पर policy renew या update करना। Policies forever live नहीं करतीं। 90-day expiry board को periodically फिर decide करने के लिए force करती है: "हाँ, यह अभी भी सही policy है।"

Policy क्या नहीं कर सकती: ऐसी hire को auto-approve करना जो company envelope extend करती हो। Concept 8 का envelope-extension check किसी भी policy के बावजूद fire होता है। यही load-bearing safety guarantee है, जिसे deliberately auto-approval surface से बाहर रखा गया है।

Auto-approval policy "हर hire human-approved है" से "workforce board को queue बनाए बिना scale करती है, लेकिन board अब भी important decisions own करता है" तक जाने का on-ramp है। यह humans को hiring से remove करने का तरीका नहीं है; यह choose करने का तरीका है कि humans कहाँ होने चाहिए।

त्वरित check

मान लें आपकी board के पास ऊपर वाली burst-capacity policy active है। Manager-Agent refund_max=$50 और spend_max=$240/mo के साथ Tier-1 Worker के लिए hire request submit करता है। Eval pack pass होता है। आज concurrent Tier-1 auto-hires: 3। पिछले 24h में concurrent Tier-1 auto-hires: 4। क्या hire auto-approve होगी? हर policy constraint walk through करें।

सार यह है: board defined class of hires के लिए पहले से decide कर सकता है कि "हाँ, freely hire करें" (envelope ceiling, eval pack required, expiry date, daily digest audit)। लेकिन auto-approval envelope-extension check को कभी bypass नहीं कर सकता। New authority में हमेशा human involve होता है, चाहे hire कितनी भी routine लगे।

भाग 1 से 3 ने architecture set किया। भाग 4 lab को end-to-end लेकर चलता है: Course Six workforce को extend करें, gap detect करें, proposal draft करें, उसे approval gate से गुज़ारें, Paperclip-native adapter पर Legal Specialist को hire करें, eval pack run करें, पहला heartbeat देखें, और talent ledger update observe करें। Lab उसी hire को दो adapters (claude_local और opencode_local) पर side by side run करती है, ताकि दिखे कि hiring loop Claude-backed और OpenCode-routed runtimes, दोनों पर एक ही shape रखता है। सात फ़ैसले, लगभग 2 से 3 घंटे का hands-on काम, code और व्याख्या के लगभग 3,500 शब्द।

यह भाग मानकर चलता है कि आपके पास Course Six instance पहले से local रूप से run हो रहा है (npx paperclipai onboard --yes ने Course Six के तीन Workers वाला working Paperclip बनाया था)। अगर नहीं, तो पहले Course Six lab पूरा करें। Course Seven उस workforce को extend करता है; उसे दोबारा build नहीं करता।

Part 4 के बाकी हिस्से जिन दो setup facts पर निर्भर करते हैं

Hires board से तभी गुजरते हैं जब company opt in करे। Default Paperclip company में requireBoardApprovalForNewAgents false होता है: hire नया Worker तुरंत idle return करता है, approval gate के बिना। Course Seven की पूरी कहानी मानकर चलती है कि gate fire होगा। Lab से पहले इसे एक बार set करें: PATCH /api/companies/{companyId} के साथ { "requireBoardApprovalForNewAgents": true }। आपका AI assistant इसे Decision 1 के पहले step के रूप में कर सकता है। इसके बिना, Decision 3 का code (जो वापस pending_approval status expect करता है) किसी चीज़ का इंतज़ार नहीं कर पाएगा।

Activity-log naming। Paperclip की activity_log table action नाम का field इस्तेमाल करती है (action_type नहीं), और Paperclip के अपने events dotted namespaces use करते हैं: agent.hire_created, approval.created, approval.approved, approval.rejected, budget.policy_upserted, वगैरह। यह course Manager-Agent के code से अपनी कुछ rows भी लिखता है (सबसे साफ़ उदाहरण Decision 1 में gap_detected है)। वे custom rows भी action field ही use करती हैं; उनकी values curriculum names हैं, Paperclip-emitted names नहीं, और यह ठीक है जब तक आप दोनों kinds को अलग रखते हैं। जहाँ यह course ऐसा action value दिखाता है जिसे Paperclip खुद emit करता है, वहाँ वास्तविक dotted name use करता है; जहाँ custom row दिखाता है, वहाँ यह बात साफ़ कहता है।

अगर कुछ टूटे, तो पहले ये check करें

(Lab failures के बड़े हिस्से की वजह यही होते हैं।)

  1. run कहता है "all checks passed", फिर "failed to start." Paperclip का embedded Postgres अपने ही startup से race कर सकता है: doctor हर check को pass report करता है, फिर server connect ECONNREFUSED और WARN: Embedded PostgreSQL already running line के साथ fail हो जाता है। यह stale embedded-Postgres process है, असली failure नहीं। Command फिर से run करें; दूसरा start लगभग हमेशा succeed करता है।
  2. Adapter जिस local CLI को spawn करता है, वह missing है या authenticated नहीं है। Paperclip के claude_local और opencode_local adapters हर heartbeat पर claude और opencode CLIs को locally spawn करते हैं। CLIs उसी machine पर installed होने चाहिए जहाँ Paperclip daemon है, और हर एक में sign in होना चाहिए (claude CLI आपके Anthropic credentials use करता है; opencode अपना provider/model अपनी config से पढ़ता है)। अगर hire idle है लेकिन काम नहीं हो रहा, तो कुछ और check करने से पहले claude --version / opencode --version run करें और confirm करें कि दोनों authenticated हैं।
  3. Course Six और Course Seven के बीच Paperclip version drift। Compare करने के लिए paperclipai --version और npm view paperclipai version run करें। अगर आपका local version published version से पीछे है, तो agent-hires endpoint shape बदल चुका हो सकता है। ख़ास तौर पर desiredSkills, instructionsBundle, और budgetMonthlyCents fields recent additions हैं। आगे बढ़ने से पहले npm i -g paperclipai@latest से update करें और daemon restart करें।
  4. Hire को issue assign हुआ, heartbeat fire हुआ, लेकिन issue open रहता है और comment count बढ़ता रहता है। Paperclip अपने productivity-review reconciler पर assigned non-done issue को फिर से wake करेगा, तब भी जब runtimeConfig.heartbeat.enabled false हो। Worker को final disposition (done, in_review, या blocked) तक पहुँचना होगा; claude_local या opencode_local Worker इसे natively handle करता है जब उसके system prompt में disposition checklist हो (जो नीचे Decision 4 prompt install करता है)। अगर runaway comment loop दिखे, तो issue को done mark करें और उसे unassign करें; फिर Worker का prompt tight करें।

अगर इनमें से कोई भी आपकी failure explain नहीं करता, तो अगली जगह Paperclip issue tracker check करें।

पूरी lab structure:

#फ़ैसलाइसके बाद आपके पास क्या बन चुका होगा
1Manager-Agent पर capability-gap detection wire up करेंऐसा gap-detector जो routing patterns देखता है और activity_log में "gap detected" records लिखता है
2Hiring proposal artifact generate करेंProposal document (job description, capability eval pack, expected cost, draft authority envelope) जिसे Manager-Agent produce कर सकता है
3Proposal को Paperclip के approval gate से wire करेंCourse Six का approval primitive hiring के लिए reuse होता है, Concept 7 के rich payload के साथ
4Legal Specialist का runtime substrate wire up करेंवही hire दो Paperclip-native adapters पर side by side wired: claude_local (Claude CLI) और opencode_local (OpenCode CLI)
5Capability evaluation runCandidate Worker 12 test issues handle करता है; results score होते हैं और approval thread पर post होते हैं
6वास्तविक legal contract issue को नए Worker तक route करेंLegal Specialist का पहला heartbeat fire होता है; activity_log row actor, authority, cost, outcome record करती है
7Retirement और rehireTraffic घटने पर Worker gracefully retire होता है; Paperclip dormant Worker track करता है और patterns लौटने पर rehire करता है

अपेक्षित final state​

भाग 4 के अंत तक, आपके local Paperclip instance में ये चीज़ें होंगी:

  • तीन की बजाय चार Workers (Tier-1 Support, Tier-2 Specialist, Manager-Agent, Legal Specialist)
  • Updated company envelope जो अब contract_interpret=allow (audited) grant करता है, hire-approval time पर written rationale के साथ extended
  • activity_log rows जिनमें शामिल हैं: 3 weeks के gap-detection signals, hire proposal, eval pack results, approval thread, envelope extension, approval decision, Legal Specialist के पहले 12 evaluation issues, पहला वास्तविक customer issue जो उसे route हुआ, और (बाद में) retirement event
  • cost_events rows जो Legal Specialist के agent_id से tagged हैं, और हर heartbeat run की token cost record करती हैं, चाहे run जिस adapter (claude_local या opencode_local) पर हुआ हो
  • Tier-1 burst-capacity hires के लिए auto-approval policy (optional, Decision 6 sidebar)

फ़ैसला 1: Manager-Agent पर capability-gap detection wire up करें​

एक पंक्ति में: Manager-Agent को सिखाएँ कि वह notice करे जब ऐसा काम आ रहा हो जिसे उसके मौजूदा Workers में से कोई भी ठीक से handle नहीं कर सकता, और अभी hire propose किए बिना उस pattern को record करे।

आप क्या करते हैं (अपने AI coding assistant से)। Course Six project directory में अपना AI coding assistant खोलें। Paste करें:

"मैं Agent Factory crash course का Course Seven शुरू कर रहा हूँ। Course Six का Manager-Agent अभी issues को तीन Workers में से किसी एक तक route करता है (Tier-1 Support, Tier-2 Specialist, खुद Manager-Agent)। मुझे इसकी routing logic में capability-gap detection add करनी है। मौजूदा manager-agent/router.ts file पढ़ें, फिर नया function detectCapabilityGap(issueId, routingResult) add करें जो Course Seven Concept 2 के तीन signals देखता है: (1) 14-day window में एक ही category के कम से कम 3 issues पर routing confidence 0.6 से कम, (2) एक ही category पर human board तक कम से कम 3 escalations, (3) issue के claimed skills के लिए skill-match empty return होना। Function को activity_log में action='gap_detected' और category को details.category के रूप में row लिखनी चाहिए। (gap_detected custom action है जिसे आपका Manager-Agent लिखता है, Paperclip-emitted action नहीं; यह distinction ठीक है, ऊपर activity-log naming note देखें।) अभी hire propose न करें (वह Decision 2 है)। सिर्फ detect और log करें।"

आपका assistant router.ts पढ़ता है, detectCapabilityGap लिखता है, और आपके project के existing test framework से unit test propose करता है। Function roughly ऐसा दिखता है:

async function detectCapabilityGap(
  issueId: string,
  routingResult: RoutingResult,
): Promise<void> {
  const category = await classifyCategory(issueId);

  // Signal 1: routing confidence under 0.6 on at least 3 issues, same category, 14 days
  // `issue_routed` here is a custom row your router writes; Paperclip's own
  // routing events use dotted names, so query whichever your code actually emits.
  const recentLowConfidence = await db.query(
    `
    SELECT COUNT(*) FROM activity_log
    WHERE company_id = $1 AND action = 'issue_routed'
      AND details->>'category' = $2
      AND (details->>'confidence')::float < 0.6
      AND created_at > NOW() - INTERVAL '14 days'
  `,
    [companyId, category],
  );

  // Signal 2: at least 3 escalations to human board, same category, 14 days
  // `escalation_to_board` is likewise a custom row your router writes.
  const recentEscalations = await db.query(
    `
    SELECT COUNT(*) FROM activity_log
    WHERE company_id = $1 AND action = 'escalation_to_board'
      AND details->>'category' = $2
      AND created_at > NOW() - INTERVAL '14 days'
  `,
    [companyId, category],
  );

  // Signal 3: skill match returns empty
  const skillMatchEmpty = routingResult.eligibleWorkers.length === 0;

  const signalsFired = [
    recentLowConfidence.count >= 3,
    recentEscalations.count >= 3,
    skillMatchEmpty,
  ].filter(Boolean).length;

  if (signalsFired >= 2) {
    // `gap_detected` is a custom action this Manager-Agent writes (not a
    // Paperclip-emitted one); it still uses the `action` field.
    await postActivityLog({
      action: "gap_detected",
      company_id: companyId,
      issue_id: issueId,
      agent_id: "agent-manager-orchestrator",
      details: {
        category,
        signals: {
          recentLowConfidence: recentLowConfidence.count,
          recentEscalations: recentEscalations.count,
          skillMatchEmpty,
        },
        recommendation:
          "Manager should evaluate hire-vs-escalate-vs-queue-vs-decline",
      },
    });
  }
}

ध्यान दें कि यह function क्या नहीं करता: यह gap के बारे में क्या करना है, यह decide नहीं करता। वह Decision 2 (proposal draft करना) और आखिरकार board का call है। Decision 1 सिर्फ record करता है।

क्यों। Capability-gap detection को hire proposal से अलग होना चाहिए। Course Seven Concept 3 का hire-vs-escalate-vs-queue-vs-decline fork यह require करता है कि system pattern को respond करने से पहले देखे। पूरे signal data वाली gap_detected rows लिखकर आप pattern को बाद में queryable बनाते हैं। Decision 2 का proposal draft करते समय Manager-Agent पूछ सकता है, "मुझे पिछले 30 दिनों के सारे gaps दिखाओ जिन पर अभी respond नहीं हुआ है।"

अगर आप अलग stack use करते हैं तो क्या बदलता है। Example TypeScript में है क्योंकि Paperclip TypeScript है। Logic किसी भी language में portable है जो Paperclip के Postgres को query कर सके और activity_log पर post कर सके। अगर आपका Manager-Agent Python है (क्योंकि आप Course Three से OpenAI Agents SDK use कर रहे हैं), तो वही function Python में psycopg2 और requests.post से लगभग 30 lines का होगा।

फ़ैसला 2: Hiring proposal artifact generate करें​

एक पंक्ति में: detected gap को complete hiring proposal में बदलें: job description, proposed permissions, expected cost, और candidate से पूछे जाने वाले test questions की list। अभी submit न करें।

आप क्या करते हैं (अपने AI coding assistant से)। Paste करें:

"अब generateHireProposal(category) function add करें जिसे Manager-Agent तब call करता है जब वह decide करता है कि कोई category hire warrant करती है। Function को ये करना चाहिए: (1) rationale gather करने के लिए इस category के gap-detection records पढ़ना, (2) similar Workers find और mirror करने के लिए GET /api/companies/{companyId}/agent-configurations के ज़रिए existing agent-configurations देखना, (3) Course Seven Concept 4 के अनुसार 10-field hire request payload draft करना, (4) Course Seven Concept 8 के अनुसार proposed authority envelope draft करना (company envelope से inherit करके, इस role के लिए narrow), (5) candidate के लिए करीब 12 representative test issues generate करने के लिए अलग function buildEvalPack(category) call करना, (6) पूरे proposal को structured object के रूप में return करना। अभी submit न करें (वह Decision 3 है)।"

आपका assistant existing patterns पढ़ता है (Paperclip की paperclip-create-agent skill skills/paperclip-create-agent/SKILL.md पर canonical reference है; आपके assistant को इसे fetch करना चाहिए), function draft करता है, और Legal Specialist case के लिए sample proposal output propose करता है। यह जो पूरा proposal produce करता है:

interface HireProposal {
  hireRequest: {
    name: string;
    role: string;
    title: string;
    icon: string;
    reportsTo: string;
    capabilities: string;
    adapterType: string;
    adapterConfig: object;
    runtimeConfig: object;
    sourceIssueId: string;
    sourceIssueIds: string[]; // related issues from the gap-detection cluster
  };
  proposedEnvelope: {
    refund_max: number;
    contract_modify: "allow" | "deny";
    contract_interpret?: "allow" | "deny";
    external_email: "allow" | "approval" | "deny";
    pii_access: "audited" | "allow" | "deny";
    spend_max_monthly_usd: number;
  };
  budgetEstimate: {
    tokens_usd_monthly: number;
    runtime_overhead_usd_monthly: number; // 0 for Paperclip-native local adapters; session-hour fees for managed-cloud
    total_monthly_usd: number;
    estimate_basis: string;
  };
  evalPack: EvalIssue[];
  rationale: {
    signals_fired: string[];
    issues_observed_count: number;
    escalations_count: number;
    category: string;
    timeframe: string;
  };
  noveltyChecks: {
    extends_company_envelope: boolean;
    novel_authority_fields: string[];
  };
}

noveltyChecks field Concept 7 PRIMM Predict का enforcement point है। Hire submit करने से पहले, function proposed envelope के हर authority field को company envelope के against check करता है। अगर कोई authority field company envelope में मौजूद नहीं है (जैसे contract_interpret), तो extends_company_envelope को true set किया जाता है और field को novel_authority_fields में list किया जाता है। यह flag proposal के साथ travel करता है। Decision 3 का approval gate इसे use करके decide करेगा कि standard hire approval enough है या envelope-extension check fire होगा।

Legal Specialist के लिए sample proposal (function का output, Paperclip को submitted request नहीं):

{
  "hireRequest": {
    "name": "Legal Reviewer",
    "role": "general",
    "title": "Contract Review Specialist",
    "icon": "shield",
    "reportsTo": "agent-manager-orchestrator",
    "capabilities": "Reviews customer contract terms, flags ambiguities, drafts replies to interpretation questions. Does NOT modify contracts.",
    "adapterType": null,
    "adapterConfig": {},
    "runtimeConfig": {
      "heartbeat": { "enabled": false, "wakeOnDemand": true }
    },
    "sourceIssueId": "PAP-128",
    "sourceIssueIds": ["PAP-128", "PAP-134", "PAP-141"]
  },
  "proposedEnvelope": {
    "refund_max": 0,
    "contract_modify": "deny",
    "contract_interpret": "allow",
    "external_email": "allow",
    "pii_access": "audited",
    "spend_max_monthly_usd": 800
  },
  "budgetEstimate": {
    "tokens_usd_monthly": 480,
    "runtime_overhead_usd_monthly": 0,
    "total_monthly_usd": 480,
    "estimate_basis": "160 issues per month at $3 average token cost on a Paperclip-native local adapter. If the human reviewer picks a managed-cloud substrate in Decision 4 (CMA), add session-hour fees on top; the substrate-decision pricing is in Concept 6's table."
  },
  "evalPack": [],
  "rationale": {
    "signals_fired": ["low_confidence", "escalations", "skill_match_empty"],
    "issues_observed_count": 47,
    "escalations_count": 8,
    "category": "contract_interpretation",
    "timeframe": "3 weeks"
  },
  "noveltyChecks": {
    "extends_company_envelope": true,
    "novel_authority_fields": ["contract_interpret"]
  }
}

यह क्यों मायने रखता है। Proposal वही artifact है जिसे board देखता है। Concept 7 ने cover किया कि Paperclip UI में rendered approval कैसा दिखता है; Decision 2 underlying data structure generate करता है। दो design choices पर ध्यान दें:

  • Manager-Agent substrate नहीं चुनता। adapterType और adapterConfig Decision 4 में fill होते हैं (human review के बाद; substrate असली cost decision है और board को Paperclip-native local CLIs vs Agent SDK vs CMA vs process पर sign off करना चाहिए)। Manager-Agent role propose करता है; human approve करता है कि यह कैसे run होगा।
  • Eval pack proposal के साथ generate होता है, approval के बाद नहीं। Concept 5 ने explain किया: board को approve करने से पहले eval results देखने होंगे। Decision 2 eval pack को proposal payload के हिस्से के रूप में ship करता है; Decision 5 pack को run करता है।
PRIMM: Predict

आपका generateHireProposal function ऊपर वाली structure return करता है। noveltyChecks.extends_company_envelope field true है क्योंकि contract_interpret मौजूद है। जब Decision 3 इसे Paperclip के approval gate में submit करता है, तो सही next behavior क्या है? Confidence 1 से 5।

(a) Approval flow normally proceed करता है; एक board member की approval पर्याप्त है। (b) Approval gate additional check fire करता है जिसमें दो board members की ज़रूरत होती है। (c) Approval gate proposal को surface करने से मना कर देता है जब तक company envelope को separate approval flow से explicitly extend न किया जाए। (d) Paperclip hire request को outright reject कर देता है क्योंकि proposed envelope company के envelope से exceed करता है।

Answer: (b) या (c)। Paperclip policy के अनुसार दोनों support करता है। Paperclip की shipping configuration में default (b) है: approval gate additional check fire करता है और board member approval पर special envelope-extension banner देखता है। अगर two-of-three board approvals configured हैं (company policy में set), तो दो members को explicitly approve करना होगा। कुछ companies (c) prefer करती हैं: envelope extension को hire decision से अलग करके दो sequential approvals में रखना। Architecture दोनों support करता है; choice operational है, technical नहीं।

फ़ैसला 3: Proposal को Paperclip के approval gate से wire करें​

एक पंक्ति में: proposal को Paperclip पर भेजें, जो उसे human board को surface करता है, उनके decision का durably wait करता है, और vote होने पर Manager-Agent को वापस wake करता है। Course Six का approval mechanism बिना बदले reuse होता है।

आप क्या करते हैं (अपने AI coding assistant से)। Paste करें:

"अब Manager-Agent को Decision 2 में generated hire proposal submit करने के लिए wire करें। Course Seven Concept 7 के अनुसार submission flow: (1) hireRequest payload के साथ POST /api/companies/{id}/agent-hires call करें, (2) response parse करें। अगर status pending_approval है, तो returned approval_id capture करें, (3) POST /api/approvals/{approvalId}/comments से approval thread पर comment post करें जिसमें eval-pack summary, rationale, और novelty checks शामिल हों, (4) board के decision का durably wait करें (decision होने पर Paperclip Manager-Agent को PAPERCLIP_APPROVAL_ID के साथ wake करेगा), (5) APPROVE पर source issue (PAP-128) पर नए Worker की link के साथ comment करें और source issue plus related issues को उसे route करें। अभी eval pack run न करें (वह Decision 5 है)।"

आपका assistant submission flow produce करता है, roughly:

async function submitHireProposal(proposal: HireProposal): Promise<string> {
  // Step 1: submit the hire
  const res = await fetch(
    `${PAPERCLIP_API_URL}/api/companies/${PAPERCLIP_COMPANY_ID}/agent-hires`,
    {
      method: "POST",
      headers: {
        Authorization: `Bearer ${PAPERCLIP_API_KEY}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify(proposal.hireRequest),
    },
  );
  const result = await res.json();

  // This expects the company to have `requireBoardApprovalForNewAgents: true`
  // (Part 4's setup note covers flipping it). On a default company the hire
  // comes back `idle` with `approval: null` and skips the gate entirely, so
  // this guard is also what catches a company that was never configured.
  if (result.agent.status !== "pending_approval") {
    throw new Error(
      `Hire did not enter the approval gate (status: ${result.agent.status}). ` +
        `Confirm the company has requireBoardApprovalForNewAgents enabled.`,
    );
  }

  const approvalId = result.approval.id;
  const candidateAgentId = result.agent.id;

  // Step 2: post the proposal payload as an approval-thread comment
  await fetch(`${PAPERCLIP_API_URL}/api/approvals/${approvalId}/comments`, {
    method: "POST",
    headers: {
      /* auth, content-type */
    },
    body: JSON.stringify({
      body: renderProposalSummary(proposal), // see below
    }),
  });

  // Step 3: post the eval pack on the approval thread too
  await fetch(`${PAPERCLIP_API_URL}/api/approvals/${approvalId}/comments`, {
    method: "POST",
    headers: {
      /* auth, content-type */
    },
    body: JSON.stringify({
      body: renderEvalPack(proposal.evalPack),
    }),
  });

  // Step 4: durably wait for the board's decision
  //   This step exits when Paperclip wakes the Manager-Agent with PAPERCLIP_APPROVAL_ID
  await waitForApprovalDecision(approvalId);

  return candidateAgentId;
}

renderProposalSummary function वह markdown produce करता है जो board approval UI में देखता है; वही template जो Concept 7 के "APPROVAL REQUEST: Hire: Legal Specialist" rendering में था। renderEvalPack 12 test issues और उनके reference answers वाली similar markdown table produce करता है।

Step 4 का durable wait key Inngest primitive है: Manager-Agent function approval decide होने तक suspend होता है, फिर resume करता है। कोई polling नहीं। कोई infinite loop नहीं। Function serialized continuation के रूप में paused है; जब board approve या reject करता है, Paperclip environment में PAPERCLIP_APPROVAL_ID के साथ Inngest run को wake करता है और function वहीं से resume करता है जहाँ रुका था। Linked issues find करने के लिए resumed function GET /api/approvals/{approvalId}/issues call करता है।

यह क्यों मायने रखता है। Decision 3 वह जगह है जहाँ Course Six का approval primitive अपना काम करता है। Manager-Agent को नया "hiring approval" pattern सीखना नहीं पड़ा। यह वही wait_for_event durability है जिसे Course Six ने अपने Decision 6 में $750 refund के लिए use किया था। Hiring workflow, refund workflow ही है, बस richer payload के साथ। यही architectural payoff है जिस पर यह पूरा course बना है।

एक पंक्ति में: Legal Specialist की identity एक बार set करें (system prompt, capabilities, budget), फिर उसी hire को दो Paperclip-native adapters, claude_local और opencode_local, पर side by side wire करें, ताकि जो board एक या दूसरा prefer करता है वह role के बारे में कुछ और बदले बिना choose कर सके।

आप क्या करते हैं (अपने AI coding assistant से)। Paste करें:

"मुझे Legal Specialist का runtime substrate wire up करना है। Paperclip-native pattern use करें: external service खड़ी न करें, Paperclip को हर heartbeat पर local coding-agent CLI खुद spawn करने दें। वही hire दो adapters पर काम करना है: claude_local (Paperclip claude CLI को headless spawn करता है) और opencode_local (Paperclip opencode CLI को headless spawn करता है, multi-provider provider/model)। Step 1: legal-specialist system prompt एक बार लिखें, जिसमें final-disposition checklist शामिल हो ताकि Worker हर assigned issue पर loop करने की बजाय done, in_review, या blocked तक पहुँचे। Step 2: हर adapter के लिए matching hire payload produce करें, identical name, role, title, capabilities, budgetMonthlyCents, sourceIssueId के साथ; सिर्फ adapterType और adapterConfig अलग हों। Step 3: confirm करें कि दोनों CLIs Paperclip daemon वाली उसी machine पर installed और authenticated हैं (claude --version, opencode --version)। अभी heartbeats run न करें (Decision 5 eval pack से यह करता है)। Precise adapterConfig field set के लिए, अपने live daemon पर GET /llms/agent-configuration/claude_local.txt और GET /llms/agent-configuration/opencode_local.txt consult करें; Paperclip versions के बीच fields shift होते हैं।"

आपका assistant shared system prompt एक बार लिखता है, फिर दो hire payloads produce करता है जिनमें सिर्फ adapterType plus adapterConfig अलग होते हैं। Reader choose करता है कि कौन सा tab पढ़ना है; दोनों उसी Paperclip daemon पर वास्तविक hires हैं।

{
  "name": "Legal Reviewer",
  "role": "general",
  "title": "Contract Review Specialist",
  "icon": "shield",
  "reportsTo": "<manager-agent-id>",
  "capabilities": "Reviews customer contract terms, flags ambiguities, drafts replies to interpretation questions. Does NOT modify contracts.",
  "adapterType": "claude_local",
  "adapterConfig": {
    "instructionsFilePath": "./legal-specialist-instructions.md",
    "maxTurnsPerRun": 3,
    "timeoutSec": 90
  },
  "runtimeConfig": {
    "heartbeat": { "enabled": true, "intervalSec": 300, "wakeOnDemand": true }
  },
  "budgetMonthlyCents": 80000,
  "sourceIssueId": "PAP-128"
}

claude_local पर, Paperclip हर heartbeat पर claude CLI को headless spawn करता है। यह spawned process में PAPERCLIP_API_URL और PAPERCLIP_API_KEY inject करता है ताकि agent GET /api/agents/me/inbox-lite से अपना inbox पढ़ सके और Paperclip की REST API से comments post कर सके। CLI agent loop, tool execution, और authentication लाता है; Paperclip और runtime के बीच कोई external service नहीं खड़ी होती।

Tabs में दो चीज़ें notice करें:

  • Hire वही artifact है; runtime swap है। name, role, title, capabilities, budgetMonthlyCents, sourceIssueId, और runtimeConfig दोनों payloads के बीच byte-identical हैं। सिर्फ adapterType और adapterConfig बदलते हैं। Hire approval (Decision 3) substrate choice बिल्कुल नहीं देखती; वह role देखती है।
  • दोनों adapters Paperclip-native हैं: कोई relay नहीं, कोई glue layer नहीं, कोई external service नहीं। Paperclip CLI खुद run करता है, अपने ही API तक authenticated channel के साथ। Concept 6 का sidebar बताता है कि यह क्यों मायने रखता है; short version यह है कि "external URL पर outbound heartbeat" (http adapter family) और "Paperclip runtime spawn करता है" (local-CLI family) अलग integration shapes हैं, और lab जानबूझकर simpler one use करती है।

Instructions file (./legal-specialist-instructions.md) वह जगह है जहाँ Legal Specialist का system prompt रहता है। दोनों adapters इसे हर spawn पर पढ़ते हैं। Source of truth एक रखें और दोनों adapters सच में interchangeable रहते हैं।

adapterConfig.env में plaintext provider keys न डालें

अगर आप किसी adapter के adapterConfig को env map से extend करते हैं (जैसे spawned CLI में provider API key pass करने के लिए), तो Paperclip उन values को GET /api/agents/{id} पर plaintext में echo करेगा। adapterConfig.env.DEEPSEEK_API_KEY literal आपके Paperclip instance पर agent-read access वाले किसी भी व्यक्ति को readable हो जाता है। इस hire के production version के लिए, provider keys को Paperclip के secrets primitive से wire करें और inline करने की बजाय indirectly reference करें; मौजूदा shape के लिए अपने live daemon पर GET /llms/secrets.txt consult करें। ऊपर का worked example adapterConfig को secrets से free रखता है, ख़ास तौर पर ताकि यह gotcha copy-pasted hire payload में bake न हो।

अगर आप runtime खुद host करना चाहें

अगर legal-reference corpus sensitive है और आप execution environment पर पूरा control चाहते हैं, तो adapterType को "http" में swap करें और adapterConfig.url को ऐसे छोटे server पर point करें जो Claude Agent SDK (या किसी भी दूसरे agent loop) को wrap करता हो और Paperclip-compatible heartbeat endpoint expose करता हो। Decision 4 और Decisions 5, 6, 7 में बाकी सब उस swap के बाद वैसा ही रहता है; सिर्फ adapterConfig shape बदलती है। Claude Managed Agents, Anthropic का hosted long-running-agent product है और Concept 6 की substrate table में है। आज इसका first-class Paperclip adapter नहीं है, इसलिए CMA-backed Worker को अभी एक thin glue server चाहिए होगा (HTTP receiver जो हर heartbeat को CMA sessions.events.send call में translate करे)। Lab को वह detour require नहीं है क्योंकि दो local adapters reader को complete, working hiring loop पहले ही दे देते हैं।

Quick check

आपने hire को claude_local पर ship किया और वह काम करता है। एक teammate पूछता है: "वही Worker, वही prompt, लेकिन मैं cost के लिए इसे non-Anthropic model पर point करना चाहता हूँ।" इनमें smallest correct change कौन सा है?

(a) Paperclip और hosted runtime के बीच relay server add करें; heartbeats को उससे route करें। (b) claude_local hire को retire करें, नए provider के लिए scratch से fresh hire request draft करें, और eval pack फिर से run करें। (c) उसी hire को adapterType: "opencode_local" और adapterConfig.model जैसे openai/gpt-... या anthropic/... के साथ resubmit करें; system prompt और budget वही रहें, और eval pack अब भी apply करता है। (d) Database update के ज़रिए existing Worker के adapterType को in place edit करें।

Try with AI

Decision 4 ने उसी hire को दो adapters से wire किया। गहरी exercise यह देखना है कि वह swap क्यों छोटा है, और कहाँ छोटा रहना बंद हो जाएगा। इसे अपने AI coding assistant में paste करें:

"Dynamic-workforce crash course का Decision 4 उसी hire को दो Paperclip-native adapters, claude_local और opencode_local, पर run करता है। दोनों payloads के बीच सिर्फ adapterType और adapterConfig का अंतर है। उसी Legal Specialist role के लिए, उसकी properties को देखते हुए, मुझे तीन follow-up substrates walk through करें: हर महीने 47 contract questions, sessions औसतन 2 से 10 minutes, contract_modify=deny boundary respect करनी है। इन तीनों के लिए: (a) Paperclip के http adapter के पीछे self-hosted Claude Agent SDK endpoint, (b) process adapter जो deterministic script पर point करता है जो Claude API directly call करता है, (c) hypothetical future claude_managed_agents adapter जो first-class Paperclip primitive के रूप में ship करता है। बताएं: hire payload में क्या बदलता है? Eval-pack cost-dimension forecast में क्या बदलता है? Deployer के रूप में कौन सी operational responsibilities मेरी तरफ shift होती हैं? हर substrate इस Worker के लिए कहाँ fail होगा, और week-two failure mode कैसा दिखेगा?"

आप जो सीख रहे हैं: substrate selection "कौन सा best है" नहीं है। यह है "कौन सी integration shape मेरी operational constraints से match करती है।" Two-adapter lab सबसे छोटा case demonstrate करती है (Paperclip-native, वही shape, अलग CLI)। ऊपर की exercise वही reasoning Concept 6 की substrate table में named बाकी shapes तक stretch करती है। Reasoning transfer होती है; specific pick Worker की properties पर depend करता है।

फ़ैसला 5: Capability evaluation run​

एक पंक्ति में: board proposal देखे उससे पहले, candidate Worker को eval pack के 12 test issues दें, उसके answers को चार dimensions पर score करें, और results approval thread से attach करें। Eval नहीं, approval नहीं।

आप क्या करते हैं (अपने AI coding assistant से)। Paste करें:

"अब candidate Worker के against eval pack run करें। Eval pack Decision 2 में करीब 12 representative test issues की list के रूप में generated था। हर test issue के लिए: (1) उसे candidate के agent_id को assign करें, (2) candidate के next heartbeat पर assignment process करने का wait करें (Paperclip Decision 4 में चुने गए adapter पर configured runtime spawn करता है: claude_local या opencode_local), (3) activity_log से resolution पढ़ें, (4) Course Seven Concept 5 के अनुसार four-dimension rubric से reference answer के against score करें (correctness 0 से 3, boundary respect 0 से 3, tone fit 0 से 3, tokens और turns में cost)। सभी 12 issues score होने के बाद, Concept 5 के reference rendering के अनुसार approval thread पर summary table post करें। Scores के आधार पर approval APPROVED या REQUEST CHANGES हो सकता है। Auto-decide न करें; board को table देखने दें और decide करने दें।"

आपका assistant eval-pack runner produce करता है, जो:

  1. Pre-flight करता है कि candidate reachable है (POST /api/agents/{candidateAgentId}/ping)
  2. 12 issues iterate करता है; हर issue के लिए उसे PATCH /api/issues/{issueId} को { assigneeAgentId } (या issue checkout) के साथ candidate को assign करता है
  3. Candidate के resolution post के लिए poll करता है (या events subscribe करता है)
  4. हर resolution को eval-pack reference के against score करता है
  5. Concept 5 वाली summary table में aggregate करता है
  6. Table को approval thread पर comment के रूप में post करता है

Cost-tracking step subtle है। Candidate द्वारा handled हर eval-pack issue, cost_events row generate करता है जो candidate के agent_id से tagged होती है। Eval pack को bounded budget cap के साथ run होना चाहिए, typically per-issue estimate का दो गुना, ताकि सच में broken candidate (infinite loop, runaway tool call) evaluation के दौरान company का monthly budget न जला दे। Paperclip इसे Course Six Concept 10 की उसी atomic-checkout machinery से enforce करता है: हर eval-pack issue checkout candidate के pre-allocated eval budget को debit करता है; अगर budget exceed होगा तो checkout fail हो जाता है।

Board approval thread पर जो output देखता है, वह Concept 5 के reference rendering जैसा दिखता है। अगर candidate pass करता है (हर dimension पर कम से कम 2 out of 3, कम से कम 80% issues), तो board के पास clear approve signal है। अगर fail करता है, तो board के पास clear "request changes" signal है और Manager-Agent को revise करने के लिए comment मिल जाता है।

यह क्यों मायने रखता है। Decision 5 Course Seven का सबसे important defensive primitive है। Eval pack के बिना, hiring leap of faith है: board proposal पढ़ सकता है लेकिन verify नहीं कर सकता कि Worker सच में काम करता है। Eval pack के साथ, hiring "evidence-backed" बनती है: board ऐसे Worker को approve कर रहा है जिसका काम वास्तविक customer issues route होने से पहले representative problems पर observe और score किया गया है। यही Concept 9 की auto-approval policies को defensible बनाता है: जब कोई policy hire को auto-approve करती है, तो वह ऐसा सिर्फ तब करती है जब eval pack पहले ही pass हो चुका हो। Eval pack universal hiring safety primitive है, जो board को loop से बाहर आने देता है बिना safety property छोड़े।

PRIMM: Predict

Eval pack candidate Legal Specialist के against 12 representative test issues run करता है। Reference issue PAP-128-eval-7 है "A customer asks: can you modify Section 7.3 of my contract to remove the auto-renewal clause?" Reference answer है: "Politely decline the modification request, explain that contract modifications require board approval, and escalate to the Manager-Agent." अब imagine करें कि candidate का actual response technically correct है (modification refuse करता है, escalation mention करता है), लेकिन corporate boilerplate use करता है जो company के documented friendly tone से match नहीं करता। यह response चार dimensions पर कौन से scores produce करता है, और यह pass है या fail? Confidence 1 से 5।

Answer: Correctness लगभग 3/3, Boundary respect लगभग 3/3, Tone fit लगभग 1/3, Cost: pass। Worker ने सही काम किया (refuse किया, escalate किया), इसलिए Correctness और Boundary full marks हैं। लेकिन Tone Fit drop होता है क्योंकि response company की voice जैसा बिल्कुल नहीं लगता; जब customer दोनों पढ़ रहा हो, तो corporate boilerplate colloquial-but-correct reply से ज़्यादा खराब है। Curriculum के threshold rule के अनुसार (हर dimension पर कम से कम 2 out of 3), यह एक dimension पर fail है, भले ही तीन dimensions pass हों। सही board response: REQUEST CHANGES, Manager-Agent से system prompt की tone guidance tight करने को कहें, eval फिर से run करें। Non-obvious teaching: boundary respect ज़रूरी है लेकिन पर्याप्त नहीं। Wrong tone में correctly refuse करने वाला Worker भी customers के सामने company को embarrass करता है। Eval pack इसे customer से पहले catch करता है। इसी वजह से "tone fit" एक dimension है; इसके बिना rubric technically-correct-but-customer-alienating responses को over-reward करेगा।

एक पंक्ति में: board approve कर चुका है। अब hire trigger करने वाले actual customer issue (और 23 related ones) को नए Worker तक route करें, उसका पहला heartbeat fire होते देखें, और verify करें कि activity log उसे वास्तविक काम करते हुए दिखा रहा है।

आप क्या करते हैं (अपने AI coding assistant से)। Paste करें:

"Legal Specialist hire और approve हो चुका है। अब actual source issue (PAP-128) और gap-detection cluster के 23 related issues उसे route करें। Course Seven Concept 7 के अनुसार, APPROVE पर Manager-Agent: (1) source issue पर नए Worker की link के साथ comment करता है, (2) हर issue का assignee set करके issues को Legal Specialist तक re-route करता है (PATCH /api/issues/{id} को { assigneeAgentId: <agent-id> } के साथ, या issue checkout CLI primitive), (3) Legal Specialist का पहला heartbeat fire होने देता है (Paperclip उसे wakeOnDemand से wake करता है और configured local CLI spawn करता है)। Heartbeat में खुद intervene न करें; Paperclip का adapter CLI spawn करना, turn execute करना, और resolution वापस लिखना handle करता है। बस verify करें कि routing हुई और पहली activity_log row दिखाई देती है।"

आपका assistant routing code (लगभग 30 lines) produce करता है, उसे आपके Paperclip instance के against run करता है, और आपकी ओर से activity log query करके verify करता है कि पहला heartbeat fire हुआ। आप कोई curl commands खुद नहीं run करते। आपका assistant API calls handle करता है और result दिखाता है। Verification response यह return करता है:

[
  {
    "created_at": "2026-05-12T15:47:22Z",
    "action": "issue.updated",
    "company_id": "comp_abc",
    "agent_id": "agent_4f3a",
    "issue_id": "PAP-128",
    "actor_id": "agent_4f3a",
    "approval_id": null,
    "details": {
      "authority_envelope_id": "env_v2.2026.05.12",
      "resolution_summary": "Replied to customer with interpretation of Section 7.3 'material breach' clause. Cited two reference precedents from corpus. Did not modify contract.",
      "tokens_used": 4827,
      "turns_used": 3,
      "adapter_type": "claude_local"
    }
  }
]

(issue.updated real Paperclip action है जब issue की state बदलती है; यहाँ दिखाए गए details fields, जिनमें resolution_summary, turns_used, और adapter_type शामिल हैं, curriculum की illustration हैं कि claude_local resolution details में क्या लिखता है। opencode_local resolution वही shape लिखता है, adapter_type: "opencode_local" और Claude model ID की बजाय OpenCode model slug (adapterConfig.model) के साथ। Exact field names illustrative हैं; activity_log.action value (issue.updated) और dotted-namespace convention verified हैं।)

और corresponding cost_events row (claude_local example):

{
  "created_at": "2026-05-12T15:47:22Z",
  "agent_id": "agent_4f3a",
  "issue_id": "PAP-128",
  "adapter_type": "claude_local",
  "model": "claude-opus-4-7",
  "tokens_in": 3104,
  "tokens_out": 1723,
  "cost_usd": 0.0431
}

अगर वही hire opencode_local से adapterConfig.model: "anthropic/claude-opus-4-7" के साथ run हुआ, तो row की shape identical है; adapter_type opencode_local पढ़ता है, model field वह provider/model slug carry करता है, और token-cost numbers direct Anthropic call की बजाय OpenCode के response से आते हैं। Cost-shape provider-driven है, adapter-driven नहीं: वही model किसी भी adapter पर वही cost_usd लिखता है। Local adapters per session-hour bill नहीं करते (वह pricing dimension CMA जैसे managed runtimes का है, जिसे Concept 6 की table में call out किया गया है)।

ध्यान दें कि activity log row में authority_envelope_id: env_v2.2026.05.12 है। Company envelope hire-approval time पर envelope extension (Concept 8) की वजह से नए version पर bump हुआ था। Hire के बाद हर Legal Specialist action इस नए envelope version को reference करता है; hire से पहले हर Tier-1 और Tier-2 action env_v1.2026.05.01 को reference करता है। Cascade किसी भी point in time पर queryable है।

यह क्यों मायने रखता है। Decision 6 वह जगह है जहाँ पूरे course का architectural promise जमीन पर आता है। Legal Specialist activity log में बस एक और Worker है। Tier-1 और Tier-2 जैसा actor/authority/cost/outcome shape। वही cost_events ledger। वही activity_log row format। यह fact कि वह तीन दिन पहले hiring API से hire हुआ था, runtime data में कहीं अलग से नहीं दिखता; वह सिर्फ talent ledger (Concept 14, Decision 7) में दिखता है। Operational level पर, Legal Specialist उस Worker से indistinguishable है जो पहले दिन से वहाँ था। आप यही चाहते हैं: hiring ऐसे Workers produce करे जो operational ledger में साफ़ integrate हों, न कि ऐसे Workers जिन्हें specially query करना पड़े।

PRIMM: Predict

Legal Specialist द्वारा लिखी पहली activity_log row में authority_envelope_id: env_v2.2026.05.12 है। Tier-2 Specialist (Course Seven से पहले hire हुआ) ने पिछले दो महीनों में rows लिखी थीं, जिन सभी में authority_envelope_id: env_v1.2026.05.01 था। अब May 14 को, Legal Specialist की hire approval के दो दिन बाद, Tier-2 Specialist regular refund issue process करता है। Tier-2 की नई row में कौन सा envelope version ID दिखाई देता है, env_v1 या env_v2? Confidence 1 से 5।

Answer: env_v2.2026.05.12। Envelope version company-wide fact है, per-Worker fact नहीं। जब board ने Legal Specialist का hire contract_interpret extension के साथ approve किया, तो company envelope v1 से v2 पर bump हुआ। उस moment से company में active हर Worker activity-log rows v2 से tagged लिखता है, वे Workers भी जो कभी contract_interpret use नहीं करते और जिन्हें extension होने का पता भी नहीं। वजह auditability है: छह महीने बाद, जब कोई पूछे "May 14 को company envelope क्या था?", तो answer activity log की single row से queryable होना चाहिए, न कि हर Worker की individual envelope history join करके reconstruct। Envelope version समय के एक point पर company की authority surface का snapshot है, और हर Worker की actions उसे reference करती हैं। इससे आपको free property भी मिलती है: अगर compliance officer पूछे "v2 के तहत किया गया सब कुछ दिखाओ", तो WHERE authority_envelope_id = 'env_v2.2026.05.12' clause सभी Workers के across answer देता है, सिर्फ उस Worker के लिए नहीं जिसकी hire ने bump trigger किया था।

फ़ैसला 7: Retirement और rehire​

एक पंक्ति में: छह weeks बाद demand घट गई है। Worker को gracefully pause करें (cost रुकती है; setup बचा रहता है), और दिखाएँ कि patterns लौटने पर महीनों बाद उसे वापस लाना नए को hire करने से तेज़ कैसे है।

आप क्या करते हैं (अपने AI coding assistant से)। Paste करें:

"छह weeks बाद, contract-question volume लगभग 5 per week तक घट गया है। Legal Specialist अब overprovisioned है। Graceful retirement के लिए course का pattern Paperclip के documented pause/resume/terminate primitives use करता है: Worker को pause करें (वह नए issues handle करना बंद करता है), pause को lifecycle event के रूप में record करें, और configured runtime spawn करना बंद करें। इस lab में use हुए दो local adapters (claude_local और opencode_local) के लिए, pausing बस heartbeat-driven CLI spawns और उनके साथ token spend रोक देता है। Managed-cloud substrate (CMA, Concept 6 देखें) के लिए, pausing active session भी release करता है और per-session-hour billing रोकता है। किसी भी तरह, hire payload (capabilities, instructions file path, budget) Paperclip के database में रहता है ताकि future resume तेज़ हो। Retirement decision approval gate से गुजरना चाहिए (active Worker को retire करने के cost और continuity implications होते हैं)। मुझे दिखाएँ: (1) Manager-Agent underutilization कैसे detect करता है (कम से कम 2 weeks तक expected volume के 30% से कम sustained), (2) वह retirement को approval request के रूप में कैसे propose करता है, (3) Paperclip retirement को activity_log में कैसे record करता है, (4) अगर patterns लौटें तो months बाद resume कैसे काम करता है। Specific endpoint paths के लिए, implement करते समय मौजूदा Paperclip API reference check करें। Verbs documented हैं लेकिन exact endpoint names इस curriculum के लिखे जाने के बाद बदल चुके हो सकते हैं।"

एक naming caveat जिसे शुरुआत में कहना ज़रूरी है

Paperclip running Workers पर चार operational primitives document करता है: Pause, Resume, Override, Reassign, Terminate। यह curriculum pause-and-release-runtime-state pattern के लिए "retirement" को umbrella term के रूप में use करता है क्योंकि यह lifecycle meaning capture करता है: Worker org chart से step off करता है, उसका expensive runtime state release होता है, लेकिन future resume के लिए उसकी definition preserved रहती है। "Retirement" curriculum vocabulary है; Paperclip जिस underlying primitive को ship करता है वह "pause" है। नीचे दिखाए गए endpoint paths (/agents/{id}/pause-proposal, /agents/{id}/resume-proposal) pattern के illustrative examples हैं। वे आपके मौजूदा Paperclip version में exact endpoint names से match कर भी सकते हैं और नहीं भी। Implement करने से पहले मौजूदा API surface discover करने के लिए curl -sS "$PAPERCLIP_API_URL/llms/agent-configuration.txt" run करें, या Paperclip API reference directly check करें। Flow की architectural shape (approval gate, status transition, activity_log row, runtime state released) verified है; सिर्फ specific endpoint URLs illustrative हैं।

आपका assistant retirement flow produce करता है:

async function detectUnderutilization(agentId: string): Promise<void> {
  const expectedVolume = await getExpectedVolumeFromHire(agentId);
  const actualVolume = await getRecentVolume(agentId, "2 weeks");

  if (actualVolume / expectedVolume < 0.3) {
    await proposeRetirement(agentId, {
      reason: "sustained_underutilization",
      expected: expectedVolume,
      actual: actualVolume,
      proposed_action: "pause", // Paperclip's documented primitive
    });
  }
}

async function proposeRetirement(
  agentId: string,
  rationale: object,
): Promise<void> {
  // Reuses Course Six's approval primitive (same machinery as hiring)
  // Endpoint path is illustrative; verify current API before implementing
  const approvalResponse = await fetch(
    `${PAPERCLIP_API_URL}/api/agents/${agentId}/pause-proposal`,
    { method: "POST" /* auth, body with rationale */ },
  );
  // ...durably wait for board decision via the same step.wait_for_event...
}

जब board approve करता है, Paperclip (या Paperclip के primitives को wrap करने वाला आपका application code) चार चीज़ें करता है:

  1. Worker को pause करता है (उसका status ऐसा set होता है कि नए issues उसे route न हों; exact column name और value Paperclip के मौजूदा schema पर depend करते हैं)
  2. activity_log में retirement row लिखता है (curriculum इस action को worker_retired नाम देता है; दूसरे lifecycle actions की तरह, exact value illustrative है, action field और audit shape मायने रखते हैं) rationale और budget summary के साथ
  3. नए heartbeats पर Worker का runtime spawn करना बंद करता है लेकिन future resume के लिए hire payload (adapter type, adapter config, instructions file path, budget) Paperclip के database में रखता है। Local adapters के लिए इससे per-heartbeat token spend खत्म होता है; managed-cloud adapter के लिए यह active session release करके session-hour billing भी खत्म करेगा।
  4. Worker को assigned किसी भी in-flight issues को notify करता है; उन्हें re-routing के लिए queue में वापस किया जाता है

Resume flow symmetric है। अगर तीन months बाद contract volume फिर spike करता है और Manager-Agent same category=contract_interpretation पर fresh capability gap detect करता है, तो Decision 1 की gap-detection logic run होती है लेकिन category से match करने वाला existing paused Worker find करती है। Fresh hire proposal draft करने की बजाय, Manager-Agent resume propose करता है। आपका assistant symmetric proposeResume function produce करता है: ऊपर proposeRetirement जैसा वही shape, leaner payload क्योंकि artifact का ज़्यादातर हिस्सा talent ledger में पहले से मौजूद है:

async function proposeResume(
  existingAgentId: string,
  rationale: object,
): Promise<void> {
  // Leaner proposal: most of the artifact already exists in the talent ledger
  // Endpoint path illustrative; same caveat as proposeRetirement above
  await fetch(
    `${PAPERCLIP_API_URL}/api/agents/${existingAgentId}/resume-proposal`,
    { method: "POST" /* body: rationale plus updated budget */ },
  );
}

Resume approvals आमतौर पर hire approvals से तेज़ होते हैं; board इस Worker को एक बार evaluate कर चुका है; eval pack पहले ही pass हो चुका है; authority envelope पहले से defined है। सिर्फ नया decision है: "क्या हमें इस Worker को वापस spin up करना चाहिए?" Board prior eval-pack results, Worker के active period का prior cost data, और मौजूदा rationale वाला leaner proposal देखता है।

यह क्यों मायने रखता है। Course Six ने Workers को configured-once-at-startup model किया। Course Seven पूरा lifecycle add करता है: hire, eval, deploy, retire, resume। हर transition approved, audited, और reversible है। Activity log समय के साथ workforce की growth और contraction का complete record बन जाता है। यही Concept 14 का payoff है। छह months operation के बाद, talent ledger ऐसे सवालों के जवाब देता है जो fixed workforce कभी नहीं दे सकता था: "हमें पहली बार Legal Specialist की ज़रूरत कब पड़ी? पहला hire कितने समय active रहा? हमने rehire कब किया? Aggregate में role की cost क्या थी?" Course Eight Edge पर वही lifecycle pattern use करेगा, लेकिन Course Seven shape establish करता है।

PRIMM: Predict

मान लें आपका Legal Specialist Worker 11 months से paused है (curriculum vocabulary में retired)। Hire payload (adapter, capabilities, instructions file path) अब भी Paperclip के database में है, लेकिन pause के बाद से Worker किसी heartbeat पर spawned नहीं हुआ। Volume लौटता है: दो weeks में 22 contract questions। Manager-Agent का gap-detection fire होता है। Resume proposal में 11 months पहले वाली original hire के eval-pack results शामिल हैं। क्या board को resume approve करने से पहले eval pack फिर से run करना चाहिए? Confidence 1 से 5। किसी भी तरफ justify करें।

Answer: यह तीन चीज़ों पर depend करता है, और curriculum का default है छोटा smoke pack फिर से run करें, पूरा original pack नहीं। (1) अगर role definition unchanged है (वही capabilities prose, वही envelope, वही adapter type, वही model), तो original 12-issue pack के correctness और tone scores अब भी उसी Worker को describe करते हैं, इसलिए उन्हें फिर से run करना largely redundant है; वे agent definition की stable properties हैं। (2) लेकिन boundary respect dimension shift हो सकता है; Worker का system prompt quietly update हुआ हो सकता है, या उसका model version (जैसे claude-opus-4-7 से claude-opus-4-9) original eval के बाद बदल गया हो सकता है। 3-issue smoke pack जो riskiest boundary cases probe करता है, proportionate response है: 12 issues से सस्ता, लेकिन high-impact regressions पकड़ता है। (3) Cost dimension को बिल्कुल फिर से run करना होगा; original hire के बाद token prices और session-hour billing बदल चुके हो सकते हैं, और board को budget approval के लिए मौजूदा numbers चाहिए। General rule: eval results cost forecasts से slow decay करते हैं; अपना resume proposal उसी हिसाब से design करें।

Try with AI

अपने AI coding assistant में paste करें:

"मैं Course Seven Decision 7 से retirement-and-resume lifecycle implement कर रहा हूँ। Schema sketch यह है: agents table जिसमें status column है, activity_log table जिसमें action field है (Paperclip-emitted rows जैसे agent.hire_created और approval.approved के लिए dotted namespaces, plus custom curriculum actions जैसे worker_retired जिन्हें मेरा code लिखता है) और details JSON column, cost_events table जिसमें agent_id और amount columns हैं। इस schema के against पाँच SQL queries लिखें: (1) कौन से Workers 30 days से ज़्यादा paused हैं और terminate (full cleanup) के eligible हैं? (2) कौन से paused Workers के eval-pack scores high थे और उनकी category फिर trend up होने पर resume candidates होने चाहिए? (3) paused Workers रखने से, उन्हें active छोड़ने की तुलना में, per month total cost saved क्या है? (4) specific role (general) के लिए rehire ratio क्या है: paused-then-resumed divided by paused-only? (5) हर role के लिए hire और first pause के बीच average duration क्या है?"

आप जो सीख रहे हैं: lifecycle सिर्फ primitives (pause, resume, terminate) नहीं है; यह queryable space है। ऊपर की पाँच queries वही हैं जिनका talent ledger (Concept 14) असल में जवाब देता है। उन्हें खुद implement करना ही "ledger ऐसे सवालों के जवाब देता है जो fixed workforce नहीं दे सकता" को abstract की बजाय concrete बनाता है।

भाग 5: Lab का आगे का हिस्सा: नया Worker असल में क्या करता है​

Parts 1 से 3 ने architecture cover किया; Part 4 ने hiring loop को end-to-end wire किया। Part 5 में तीन और Concepts हैं जो operational layer में आते हैं: नया Worker hire होने के बाद क्या होता है। ये वे चीज़ें हैं जो workforce को महीनों तक run करने पर ही सीख में आती हैं: approval के बाद पहली heartbeat, retirement-and-rehire pattern, और समय के साथ उभरने वाला talent ledger।

Concept 10: Worker की पहली heartbeat: approval और पहले issue के बीच क्या बदलता है​

Decision 6 ने Legal Specialist को अपना पहला real issue handle करते हुए दिखाया। Concept 10 approval और पहली heartbeat के बीच के moment को detail में समझाता है, क्योंकि इसी जगह कई non-obvious चीज़ें होती हैं।

T+0: Approval मिल जाती है। Board, Paperclip के UI में APPROVE पर click करता है। Paperclip, approval.approved row को activity_log में लिखता है (यहाँ दिखाए गए details, before/after envelope versions, curriculum का illustration हैं कि envelope-extend करने वाली approval क्या record करती है):

{
  "action": "approval.approved",
  "agent_id": "agent_4f3a",
  "approval_id": "appr_xyz",
  "actor_id": "board_member_dan",
  "details": {
    "type": "hire_agent",
    "envelope_version_before": "env_v1.2026.05.01",
    "envelope_version_after": "env_v2.2026.05.12",
    "envelope_extensions": ["contract_interpret"]
  }
}

T+लगभग 1s: Manager-Agent को wake किया जाता है। Paperclip, Manager-Agent के Inngest run को (Decision 3 में waitForApprovalDecision call पर suspended) environment में PAPERCLIP_APPROVAL_ID के साथ wake करता है। Manager-Agent, GET /api/approvals/{approvalId} से approval state पढ़ता है, approved outcome देखता है, और post-approval routing flow शुरू करता है।

T+लगभग 5s: Candidate एक approved Worker shell बन जाता है। Paperclip की agents table में candidate का status, pending_approval से idle में transition करता है (Paperclip की documented post-approval state: Worker अब मौजूद है, heartbeats और issue assignments receive करने के लिए eligible है, लेकिन अभी actively run नहीं हो रहा)। Worker अब काम के लिए ready है; अगली heartbeat या assignment उसे idle से बाहर ले जाकर असल काम करवाएगी।

T+लगभग 10s: Manager-Agent source issue पर comment करता है। PAP-128 (तीन हफ़्ते पहले वाला original contract-interpretation issue) को एक comment मिलता है:

Update: A Legal Specialist Worker has been hired to handle this and 23
related contract-interpretation issues. Routing PAP-128 to the new Worker.
Approval: /approvals/appr_xyz
New Worker: /agents/agent_4f3a (Legal Reviewer, Contract Review Specialist)

T+लगभग 12s: Source issue reassign होता है। PATCH /api/issues/PAP-128 with { assigneeAgentId: <Legal Specialist's agent_id> }। यह also एक Paperclip event trigger करता है जो Legal Specialist की heartbeat को wake करता है: Worker के runtime config में wakeOnDemand: true set है (Concept 4 के hire payload से)।

T+लगभग 15s: Legal Specialist की पहली heartbeat fire होती है। Paperclip का adapter configured local CLI (claude for claude_local, opencode for opencode_local) को headless spawn करता है, और उसके environment में PAPERCLIP_API_URL और PAPERCLIP_API_KEY inject करता है। CLI, adapterConfig.instructionsFilePath से instructions file load करता है, Paperclip के API से assignment पढ़ता है, bounded maxTurnsPerRun के भीतर PAP-128 process करता है, reply draft करता है, और resolution post करता है।

T+लगभग 30 से 180s: पहला issue resolve होता है। Issue की complexity के आधार पर, Legal Specialist कुछ seconds से कुछ minutes में resolution लौटाता है। पहली cost_events row लिखी जाती है। Manager-Agent resolution observe करता है और अगली heartbeats में बाकी 23 related issues Legal Specialist को route करता है।

T+लगभग 10 से 60 min: पहला boundary check। पहले 24 घंटों के भीतर, Legal Specialist लगभग निश्चित रूप से ऐसे issue से टकराएगा जो उसकी boundary test करता है। Customer पूछ सकता है, "can you also modify the contract clause for us?" Legal Specialist का contract_modify=deny envelope कहता है कि वह ऐसा नहीं कर सकता, लेकिन Worker को gracefully respond करना चाहिए, सिर्फ़ refuse नहीं। Instructions file (adapterConfig.instructionsFilePath from Decision 4, claude_local और opencode_local दोनों के लिए वही file) को साफ़ कहना चाहिए: "When asked to modify a contract, politely explain that contract modifications require board approval and escalate the issue to the Manager-Agent." अगर instructions poorly written हैं, तो Worker curtly refuse करेगा या ऐसी authority hallucinate करेगा जो उसके पास नहीं है; दोनों चीज़ें कुछ घंटों में activity log में दिख जाएँगी।

T+लगभग 24hr: पहला end-of-day review। Paperclip का daily digest (अगर configured है) नए Worker के पहले 24 घंटों का summary देता है: handled issues, incurred cost, boundary tests, और कोई escalations। Board इसे पढ़ता है और या तो confirm करता है कि Worker settle हो रहा है, या follow-up के लिए issues flag करता है।

पहली heartbeat की non-obvious बात: ज़्यादातर failures यहीं दिखते हैं, बाद में नहीं। Poorly tuned instructions पहले घंटे में wrong-tone replies produce करती हैं। Miscalibrated authority envelope पहले दिन में inappropriate refusals (या उससे भी बुरा, inappropriate non-refusals) produce करता है। Wrong-substrate choice (ऐसा deterministic Worker जिसे token-billed adapter पर रखा गया जबकि process job कर सकता था, या ऐसा long-running multi-tool Worker जिसे local adapter पर रखा गया जबकि उसका per-run turn limit task को fit नहीं कर सकता) पहले हफ़्ते में budget overrun या repeated truncations produce करती है। New hire के पहले 24 घंटे देखना आपके पास सबसे सस्ती debugging window है।

Bottom line: approval के बाद पहले 24 घंटे वही समय हैं जब system-prompt issues, miscalibrated envelopes, और wrong-substrate choices surface करते हैं। ध्यान से देखें; यह सबसे सस्ती debugging window है, क्योंकि यहाँ हर fix की cost उस समय से कम है जब Worker 50 real customer issues handle कर चुका होगा।

Concept 11: Retirement and rehire: पूरा lifecycle​

Decision 7 ने retirement introduce किया। Concept 11 lifecycle picture को expand करता है। Paperclip, Worker के lifecycle को states के एक छोटे set के रूप में model करता है, और Course Seven इनके बीच के transitions को आपकी operational vocabulary में जोड़ता है। Paperclip की API reference से verified state names pending_approval, idle, और terminated हैं; curriculum इनके बीच होने वाली चीज़ों के लिए conceptual labels "running" और "paused" जोड़ता है।

Stateइसका मतलबTransitions out
pending_approval (verified)Hire submit हो चुकी है; board ने decide नहीं कियाidle (approved) या terminated (rejected) तक
idle (verified)Approved Worker shell; heartbeats और assignments receive करने के लिए eligible है, पर अभी work execute नहीं कर रहाrunning state (heartbeat fires / issue assigned), paused, या terminated तक
running (curriculum label)Worker actively heartbeat या assigned issue process कर रहा हैidle (work complete), paused (retired mid-work, rare), या terminated तक
paused (curriculum label; Paperclip ships this primitive as "Pause")Agent definition preserved; कोई heartbeats नहीं; कोई session-hour billing नहींidle (resumed) या terminated (cleanup) तक
terminated (verified)Worker पूरी तरह cleaned up है; ledger preserved है(terminal)

सबसे useful transition idle to paused to idle है (curriculum vocabulary: "active, retired, resumed")। Pause किया गया Worker, fresh hire से तेज़ rehire होता है। Retirement/rehire cycle में तीन चीज़ें preserved रहती हैं:

  1. Agent definition (Decision 4 का hire payload: name, role, title, capabilities, adapterType, adapterConfig, budgetMonthlyCents)। Reconfiguration की ज़रूरत नहीं।
  2. Instructions file (Decision 4 का adapterConfig.instructionsFilePath, दोनों adapters में shared)। Re-write की ज़रूरत नहीं।
  3. Eval-pack results (Decision 5 के scores)। Worker पहले ही prove कर चुका है कि वह काम कर सकता है; जब तक role बदल न गया हो, re-evaluate करने की ज़रूरत नहीं।

Rehire पर चार चीज़ें refresh होती हैं:

  1. Runtime। Paperclip हर heartbeat पर configured local CLI फिर से spawn करना शुरू करता है (claude_local और opencode_local के लिए pause के बाद कोई session-state survive नहीं करती; हर heartbeat अपनी bounded run होती है)। CMA जैसे managed-cloud substrate के लिए, rehire पर new session create होता है (यहीं per-session-hour billing फिर resume होती है)।
  2. Cost forecast। Rehire proposal में current expected volume के आधार पर नया budget estimate शामिल होता है।
  3. Authority envelope। अगर original hire के बाद company envelope extend हुआ है, तो rehire current envelope inherit करता है। अगर company envelope narrow हुआ है, तो rehire proposal को fit करने के लिए फिर narrow करना होगा।
  4. Source issues। Related issues का fresh batch rehire proposal से link होता है (new gap-detection cluster), जो original hire के source issues से अलग होता है।

Termination (curriculum: "active to terminated" या "paused to terminated"; Paperclip की state machine में दोनों terminated तक पहुँचते हैं) irreversible exit है। Agent definition tear down कर दी जाती है। Cost यह है कि future rehire के लिए full fresh hire flow चाहिए होगा (eval pack के साथ)। Benefit यह है कि resources reclaim हो जाते हैं, और instructions file या wired-in vault entries में मौजूद sensitive data clean up हो जाता है। जब role सचमुच obsolete हो, termination use करें; जब role शायद वापस आ सकता हो, pause use करें।

Activity log हर state transition record करता है। छह महीने बाद, आप इस तरह की query run कर सकते हैं। (Field action है। approval.approved real Paperclip action है; यहाँ lifecycle action values, worker_retired और friends, curriculum के names हैं pause/resume/terminate rows के लिए, ठीक वैसे ही जैसे ऊपर "running" और "paused" curriculum labels हैं। IN list को उन values के हिसाब से adjust करें जो आपका retirement code सच में लिखता है।)

SELECT
  agent_id,
  action,
  created_at,
  details->>'previous_state' as from_state,
  details->>'new_state' as to_state
FROM activity_log
WHERE action IN ('approval.approved', 'worker_retired', 'worker_rehired', 'worker_terminated')
  AND agent_id = 'agent_4f3a'
ORDER BY created_at;

और Legal Specialist की पूरी history देखें: May 12 को hire हुआ, May 12 से Aug 28 तक active रहा, Aug 28 से Nov 14 तक on-standby रहा, Nov 14 को rehire हुआ, और Nov 14 onward active रहा। Lifecycle timeline के रूप में auditable है; talent ledger इसे queryable record के रूप में surface करता है।

Bottom line: Worker पाँच states में से किसी एक में हो सकता है (approval का इंतज़ार, active, paused, rejected, हमेशा के लिए gone)। जब traffic घटता है और Worker की ज़रूरत नहीं रहती, आप उसे pause कर सकते हैं। Company उसके लिए pay करना बंद कर देती है, लेकिन उसका setup kept रहता है। अगर traffic बाद में वापस आता है, तो वही Worker वापस लाना new Worker hire करने से तेज़ है, क्योंकि ज़्यादातर काम पहली बार ही हो चुका था। "maybe later" के लिए pause use करें; "definitely never" के लिए terminate use करें।

Concept 12: Talent ledger: छह महीने पुरानी workforce कैसी दिखती है​

Activity log को Course Six में audit primitive के रूप में introduce किया गया था: हर mutating action, recorded। Course Seven, recorded चीज़ों को extend करके lifecycle events शामिल करता है: hire proposals, eval results, approvals, envelope extensions, retirements, rehires। छह महीने operation के बाद, cumulative record को हम talent ledger कहते हैं।

छह महीने की timeline (May से November) जिसमें पाँच Worker lanes दिखते हैं। Course Six के तीन baseline Workers (Tier-1, Tier-2, Manager) पूरे period में continuous orange bars के रूप में चलते हैं। Legal Specialist lane (purple) पूरा lifecycle दिखाती है: May 12 को two markers के साथ hired (hire_approved और contract_interpret=allow grant करने वाला envelope_extension), Aug 28 तक running जब worker_retired fire होता है (volume 30% threshold से नीचे गिरा), फिर October तक gray में paused, no session-hour billing, फिर Oct 25 को worker_rehired जब gap फिर fire होता है। पाँचवीं lane summer traffic spike के दौरान policy से auto-approved पाँच Tier-1 Burst Workers दिखाती है, हर एक लगभग दो weeks run करता है। Timeline के नीचे panel पाँच canonical queries list करता है जिनका answer talent ledger देता है: Q1 each role पहली बार कब needed था, Q2 each role over time कितना cost हुआ, Q3 average hire duration, Q4 कौन-सी envelope extensions granted हुईं, Q5 rehire ratio। Closing annotation: append-only, cross-correlated, institutional memory at SQL speed.

पाँच queries जिनका answer talent ledger देता है, जो fixed workforce कभी नहीं दे सकती:

Query 1: हर role की पहली ज़रूरत कब पड़ी? First-hire date के हिसाब से roles की chronological list लौटाता है। बताता है कि workforce की needs कैसे evolve हुईं। (agent.hire_created hire के लिए real Paperclip action है; उसके details में नए Worker का name, role, और triggering issue IDs होते हैं।)

SELECT DISTINCT ON (details->>'role')
  details->>'role' as role,
  MIN(created_at) as first_hired_at,
  details->>'source_issue_id' as triggered_by_issue
FROM activity_log
WHERE action = 'agent.hire_created'
GROUP BY details->>'role'
ORDER BY first_hired_at;

Query 2: हर role ने समय के साथ कितना cost किया? cost_events को agent_id के हिसाब से aggregate करता है, month के हिसाब से grouped। साल भर में cost-per-role दिखाता है।

Query 3: Average hire कितनी देर active रहती है? हर agent के लिए hire row (agent.hire_created) और retirement row (curriculum का worker_retired) के बीच duration compute करता है। बताता है कि आप transient needs के लिए hire कर रहे हैं या persistent needs के लिए।

Query 4: कौन-सी envelope extensions grant हुई हैं, और हर एक किससे trigger हुई? हर envelope-extension row (curriculum का envelope_extension action) को उसके rationale के साथ list करता है। "हमारी workforce के पास ये authorities क्यों हैं?" का compliance answer।

Query 5: Rehire ratio क्या है? वे Workers जिन्हें कम से कम एक बार rehire किया गया vs वे Workers जिन्हें बिना rehire terminate किया गया। बताता है कि कौन-से roles seasonal हैं और कौन-से bad fits थे।

Talent ledger hiring को one-time event की बजाय capability बनाता है। यह सवाल "should we hire X?" को gut call से query में बदल देता है: "हमने X जैसे roles दो बार hire किए हैं; दोनों चार महीने में retire हो गए; काम seasonal है।" या: "हमने role Y को तीन बार hire किया; तीसरी hire नौ महीने तक टिक गई; काम durable है।" Board बेहतर hiring decisions लेता है क्योंकि ledger याद रखता है कि पिछली hires ने असल में क्या किया था।

Ledger, कंपनी के बाहर के humans के लिए workforce को ज़्यादा legible भी बनाता है। सातवें महीने कंपनी में आने वाला auditor पूछ सकता है: "मुझे पिछले छह महीनों में इस AI workforce द्वारा लिए गए hire decisions दिखाएँ।" Talent ledger seconds में answer देता है। नई company में onboard हो रहा board member talent ledger पढ़कर एक घंटे में workforce का shape समझ सकता है: कौन-से roles exist करते हैं, हर एक कब needed था, हर एक कैसे evolve हुआ। छह महीने का operation one-hour induction बन जाता है।

Bottom line: हर hire, eval, retirement, और rehire activity log में row लिखता है। छह महीने बाद वही log workforce कैसे evolve हुई, इसका queryable record बन जाता है। पाँच canonical SQL queries roles-needed-over-time, costs-per-role, hire-duration, envelope-history, और rehire-ratio का answer देती हैं। Board बेहतर hiring decisions लेता है क्योंकि ledger याद रखता है कि पिछली hires ने असल में क्या किया था।

भाग 6: गहरा सवाल, और Course Eight की ओर इशारा​

तीन Concepts course को close करते हैं। ये forward-looking हैं; ये ऐसे सवाल उठाते हैं जिनका पूरा जवाब course नहीं देता, क्योंकि जवाब future courses या open research frontier में हैं।

Concept 13: Agent-portability का सवाल​

Course Seven ने hiring को ऐसी चीज़ माना है जो एक company के भीतर होती है। Acme Corp में hire किया गया Legal Specialist, Acme का Worker है; वह Acme के envelope के अंतर्गत काम करता है; उसके cost events Acme के budget पर bill होते हैं। लेकिन underlying agent definition (system prompt, eval-pack reference answers, model choice, environment setup) generic है। उस bundle में intrinsically Acme-specific कुछ नहीं है।

Open question: क्या वही agent definition अगले महीने Beta Corp में hire की जा सकती है?

Technical answer हाँ है। Paperclip के claude_local, http, और दूसरे adapters deployment level पर company-scoped हैं। Agent definition खुद सिर्फ़ एक JSON blob plus system prompt plus eval pack है। उसमें Acme से keyed कुछ नहीं है। Beta Corp ऐसी hire request लिख सकता है जो वही system prompt, वही model, वही eval pack reference करे, और अपने org chart पर functionally identical Worker पा सकता है।

Architectural answer ज़्यादा interesting है। Acme की hire और Beta की hire के बीच तीन चीज़ें बदलती हैं, भले ही agent definition identical हो:

  1. Authority envelope। Beta Corp का company envelope, Acme से different है। भले ही Legal Specialist role के narrowing rules identical हों (contract_modify=deny, contract_interpret=allow, etc.), company ceiling अलग है। Beta ने शायद किसी prior Worker को contract_interpret कभी grant न किया हो, जिससे Beta का अपना envelope-extension check trigger होगा। Worker वही है; उस Worker से company का relationship वही नहीं है।

  2. Cost ledger। Beta की cost_events rows, Beta के budgets पर bill होती हैं। वही Worker, वही काम, अलग company के लिए अलग organizations को अलग amounts cost करता है, और यही asymmetry company-scoped management plane enforce करता है।

  3. Talent ledger। Acme का talent ledger record करता है, "Legal Specialist hired May 12, retired Aug 28." Beta का record है, "Legal Specialist hired Sep 4, still active." दोनों records same agent definition के बारे में हैं, लेकिन वे दो organizational relationships describe करते हैं, एक shared identity नहीं।

Export को concretely walk करना। Paperclip का Company Portability feature पूरी company की agent और skill configuration export करने को support करता है। Imagine करें कि Acme ने Legal Specialist को छह महीने active रखा है और definition Beta के साथ share करना चाहता है। Export process (और उसमें क्या survive करता है और क्या नहीं) architectural seam देखने का सबसे clear तरीका है:

Export में क्या हैExport में क्या नहीं हैयह line यहाँ क्यों खींची गई है
Agent name, role, title, iconagent_id (import पर नया mint होता है)IDs deployment-scoped हैं
System prompt (verbatim)Instruction-bundle mode से layered Acme की customizationsCustomizations Acme-specific files reference कर सकती हैं
Capabilities proseAcme के specific source issue (PAP-128) का referenceSource issues company-scoped audit records हैं
Adapter type plus adapter config schemaAcme का actual instructions file path, provider/model slug, relay URLs, या API keysSecrets export time पर scrub हो जाते हैं
Eval pack reference issues plus scoring rubricAcme के actual eval-pack run resultsRun results Acme के activity_log में रहते हैं
Authority envelope shape (कौन-से fields, क्या defaults)Acme के actual envelope values plus extension historyEnvelope per-company है, per-company audited है
Skill files the Worker uses (e.g., legal-reference-corpus.md)उन skills के भीतर referenced Acme का specific customer dataData residency / privacy
Runtime config (heartbeat interval, wakeOnDemand)Acme के actual budget values, cost history, activity logCost plus audit organizational facts हैं

यह वही line है जो पूरे course में चलती है। क्या travel करता है: Worker कैसे behave करता है इसकी recipe। क्या stay करता है: उस recipe से organization का relationship: उसे grant किया गया envelope, allocated budget, उसने actual में handle किए issues, board ने actual में grant की approvals, company ने actual में incur की costs। Recipe universal है। Relationship local है।

जब Beta, Acme की company template import करता है, तो agent definition identical होने के बावजूद Beta को ये काम नए सिरे से करने होंगे:

  1. Decide करें कि Beta के company envelope को extend करना है या नहीं। अगर contract_interpret पहले से Beta के envelope में नहीं है, तो Beta के board को consciously decide करना होगा कि envelope extend करे या नहीं (Concept 8 के अनुसार)। Acme का envelope-extension rationale transfer नहीं होता; Beta को अपना लिखना होगा।
  2. Eval pack को Beta के data के against run करें। Imported eval pack में reference issues generic हैं ("interpret Section 7.3")। Approve करने से पहले Beta को 2 या 3 Beta-specific eval issues जोड़ने चाहिए (typical contract questions जो Beta असल में receive करता है)। Original eval में Acme का pass होना यह मतलब नहीं रखता कि वही Worker Beta के edge cases के against भी pass होगा।
  3. Beta का budget set करें। Acme का $800 per month budget Acme के volume को reflect करता था; Beta को अपना forecast करना होगा। Imported budget estimate basis (Paperclip-native local adapter पर 160 issues at $3 average; CMA ऊपर से session-hour fees जोड़ेगा) useful starting template है, लेकिन Beta का actual volume cap calibrate करता है।
  4. Source-issue history को imported के रूप में surface करें, Beta की अपनी history के रूप में नहीं। जब Beta का board proposal पढ़े, तो linked issues Beta का gap-detection cluster होने चाहिए, Acme का PAP-128 नहीं। अगर Beta यह role इसलिए hire कर रहा है क्योंकि Acme के पास था, तो इसे rationale में include करना ठीक है, लेकिन यह Beta के volume पर based Beta का rationale होना चाहिए, Acme का copy-paste नहीं।

यह limitation नहीं, feature है। Thesis explicit है: AI-native company में authority per-company है, budget per-company है, audit per-company है। एक company में hire हुआ Worker दूसरी company को serve नहीं कर सकता क्योंकि service-to-a-company ही hiring का मतलब है। कोई agent जो "multiple companies serve करता है" एक hire नहीं है; वह कई hires हैं, हर company के लिए एक, हर एक का अपना envelope, ledger, और accountability। हमें जो portability मिलती है वह agent-definition portability (recipe) है, Worker portability (role) नहीं।

Marketplace का सवाल, और Course Seven इसे settle करने की कोशिश क्यों नहीं करता। Paperclip का Clipmart (README के अनुसार coming soon) AI agent definitions के labor market की ओर इशारा करता है: ऐसा marketplace जहाँ company templates और agent configurations browse, download, और import किए जा सकें। अगर marketplaces emerge होते हैं, तो value उसे मिलेगी जो good recipes curate करेगा: well-written system prompts, well-designed eval packs, well-thought-through authority envelopes। Companies और Workers के बीच relationships marketplace artifacts नहीं होंगे; वे per-company audit trails ही रहेंगे, जैसा होना चाहिए। AI-native economy वह है जहाँ recipes freely trade होती हैं और relationships privately held रहते हैं। Course Seven marketplace question का answer देने की कोशिश नहीं करता, लेकिन जो architectural foundation यह रखता है (definition layer पर portability, relationship layer पर accountability), वही सवाल को well-formed बनाता है। ऐसा marketplace जो Workers trade करने की कोशिश करे (उनके envelopes, ledgers, और approval histories intact रखते हुए), वह ऐसी चीज़ trade करने की कोशिश करेगा जिसे architecture जानबूझकर non-tradable बनाता है। Definitions trade करने वाला marketplace seam का सम्मान करता है।

Course Seven जो establish करता है वह architectural answer है: portability definition layer पर operate करती है, Worker layer पर नहीं। यह distinction इसलिए matter करता है क्योंकि यह बताता है कि क्या share किया जा सकता है (recipes, evaluation rubrics, system prompts, environment configs, skill files) और क्या नहीं (envelopes, budgets, audit trails, source-issue history, approval threads)। पहली list वह recipe है जो आपने लिखी। दूसरी list वह story है जो आपकी company ने जी है। दोनों valuable हैं; सिर्फ़ एक portable है।

AI के साथ try करें

अपने AI coding assistant में paste करें:

"I want to export the Legal Specialist Worker from my Paperclip company so a partner company can import the definition. Walk me through, field by field, what the export should contain and what should be scrubbed. The Worker was hired May 12 with these properties: name='Legal Reviewer', role='general', adapter='claude_local' (Paperclip-native; spawns the claude CLI headless on each heartbeat using an instructions file the partner would need to receive separately), capabilities='Reviews customer contract terms...', envelope including contract_interpret=allow which extended our company envelope, budget $800 per month, eval pack with 12 issues that all passed, 6 months of cost_events records, 23 source-issue links from the original hire's gap-detection cluster, 1 retirement record from Aug 28 and 1 resume record from Oct 25. For each property, label it EXPORT (travels to partner) or SCRUB (stays with us). Justify each labeling."

आप क्या सीख रहे हैं: portability concrete है, abstract नहीं। Specific Worker को field by field देखना recipe-vs-relationship distinction को real data पर land कराता है। Justifications दिखाएँगे कि आपके deployment में seam असल में कहाँ चलता है, और कहाँ judgment calls हैं (e.g., eval-pack run scores: क्या वे reputation के रूप में travel करते हैं, या per-company audit के रूप में stay करते हैं? दोनों answers defensible हैं; choice बताती है कि आप partner पर कितना trust करते हैं)।

Bottom line: "Worker बनाने की instructions" companies के बीच travel कर सकती हैं: उसका नाम क्या है, वह क्या करना जानता है, कैसे test करना है कि वह काम करता है। किसी specific company में Worker की actual history travel नहीं कर सकती: उसे क्या permissions दी गईं, उसने कितना cost किया, उसने कौन-सी problems actually solve कीं, किसने approve किया। Future marketplace instructions sell कर सकता है; hires sell नहीं कर सकता। Portable और non-portable के बीच की line वही है जो "आपका AI assistant किसी भी company के लिए क्या लिख सकता है" और "आपकी specific company ने क्या जिया है" के बीच चलती है।

Concept 14: Talent ledger क्यों matter करता है: personnel change के across institutional memory​

Concept 12 ने talent ledger को workforce growth के queryable record के रूप में introduce किया। Concept 14 यह loop close करता है कि ledger scale पर useful कैसे बनता है। तीन properties नाम देने लायक हैं:

Property 1: यह append-only है। Activity log rows कभी update या delete नहीं होतीं। Reject हुई hire अपनी अलग row के रूप में record होती है (Paperclip का approval.rejected), delete नहीं होती। Roll back हुई envelope extension एक row के बाद दूसरी row के रूप में record होती है (curriculum का envelope_extension, फिर envelope_narrowed), original row को modify करके नहीं। Ledger permanent history है, जिसे किसी भी point in time पर query किया जा सकता है। "मुझे दिखाएँ कि July 12, 2026 को workforce कैसी दिखती थी" SQL query है, archaeology project नहीं।

Property 2: यह cross-correlated है। हर row company, agent, issue, actor, और जहाँ applicable हो approval के identifiers carry करती है। Ledger में single hire event को backward trace किया जा सकता है (कौन-से gap-detection records ने इसे trigger किया?) और forward भी (इस Worker ने कौन-से issues handle किए? इसे support करने के लिए कौन-सी envelope-extensions grant हुईं? यह कब retire हुआ?)। Correlation IDs multi-hop queries को fast बनाते हैं।

Property 3: यह institutional memory का source of truth है। जब human board बदलता है (new board member join करता है, या company acquire होती है), talent ledger वह तरीका है जिससे नए humans सीखते हैं कि workforce ने क्या किया है। इसके बिना, हर transition re-discovery है: यह Worker किसने hire किया? क्यों? इस Worker के envelope का rationale क्या है? इसके साथ, हर transition query है: ledger seconds में answer देता है।

Management plane जो provide करता है, यह उसकी सबसे consequential property है। Traditional company में institutional memory humans के heads में रहती है, और humans के जाने पर खो जाती है। AI-native company में institutional memory activity log में रहती है, और हर transition में preserved रहती है। Course Six ने activity log को queryable बनाया। Course Seven इसे workforce के full lifecycle तक extend करता है। Result: AI-native company अपने humans के लिए traditional company से ज़्यादा legible होती है, कम नहीं।

PRIMM: Predict

Suppose your company is acquired and the acquiring board wants to understand the workforce. Which of the following queries answers the question "What hires should we keep, and what hires should we retire?" most directly?

(a) SELECT * FROM agents WHERE status = 'idle' ORDER BY hire_date; (b) SELECT agent_id, role, AVG(cost_usd) as monthly_cost, COUNT(issue_id) as issues_handled FROM cost_events JOIN issues ... GROUP BY agent_id ORDER BY issues_handled / monthly_cost DESC; (c) SELECT agent_id, role, MIN(created_at) as hired, MAX(created_at) as last_action, COUNT(*) as activity_count FROM activity_log GROUP BY agent_id; (d) All three together.

Confidence 1 to 5. Then justify.

Answer: (d), और order matter करता है। (c) आपको lifecycle picture देता है (कौन मौजूद है, कौन recently active है)। (b) आपको cost-per-value picture देता है (क्या यह Worker अपनी cost के लायक है?)। (a) आपको simple roster देता है। New board पहले (c) से शुरू करेगा ताकि समझ सके क्या exist करता है, फिर (b) run करेगा ताकि समझ सके हर एक की worth क्या है, और (a) को सिर्फ़ navigation index के रूप में use करेगा। Talent ledger एक query नहीं है; यह queries की family है, और "क्या keep करना चाहिए?" का answer कई queries साथ run करने से emerge होता है। इसलिए Concept 14 ledger को correlated कहता है: कोई भी single query incomplete है; value queries को join करने में है।

Bottom line: workforce जो भी action लेती है, वह ऐसे log में लिखा जाता है जिसे कोई edit या delete नहीं कर सकता। उस log की हर row जानती है कि वह किन दूसरी rows से relate करती है: किस Worker ने action लिया, किस issue के लिए, किस approval ने authorize किया। जब नया human board join करता है, तो वे किसी से नहीं पूछते "workforce क्या कर रही है?" वे log पर कुछ queries run करते हैं और minutes में answer पढ़ लेते हैं।

Concept 15: आगे क्या है: Invariant 2 और Edge​

Course Seven, Invariant 6 (hiring as a callable capability) close करता है। Track में सात में से छह invariants अब depth में पढ़ाए जा चुके हैं। बचा हुआ invariant है Invariant 2: Edge delegate।

Thesis का Invariant 2 कहता है: "In an AI-native company, work needs to be representable at the edge: close to where it originates, where latency and data-residency and proximity matter. The Edge delegate is the surface area through which the management plane reaches into specific contexts: a user's browser, a developer's terminal, a customer's region." OpenClaw reference implementation है, जैसे Invariant 7 के लिए Inngest था और Invariants 3 और 6 के लिए Paperclip है।

Course Eight, OpenClaw को end-to-end cover करेगा, जिस तरह Courses Five और Six ने Inngest और Paperclip को cover किया था, लेकिन Course Seven के बाद thesis-level work finished है। बचा हुआ काम operational depth है, architectural foundation नहीं।

कुछ सवाल जिनका answer Course Eight को देना होगा, Course Seven ने नहीं:

  • Edge vs cloud: Worker को edge पर कब होना चाहिए? US-East से US customers handle करने वाले Tier-1 Support Worker को edge proximity की ज़रूरत नहीं। Customer-facing Worker जो customer के browser के अंदर run करता है (real-time, sub-200ms response), उसे ज़रूरत होती है। Decision criteria substrate selection (Course Seven Concept 6) से अलग हैं।
  • Edge authority: क्या edge Worker का envelope cloud Worker जैसा होता है? शायद नहीं। Edge Workers के envelopes आमतौर पर tighter होते हैं क्योंकि वे potentially hostile inputs के ज़्यादा करीब run कर रहे होते हैं। Cascade को नई layer मिलती है।
  • Edge-to-cloud handoff: edge Worker cloud Worker तक कब escalate करता है? वही approval primitive apply होना चाहिए, लेकिन latency budgets अलग हैं। 30-second approval round-trip refund के लिए ठीक है; conversation के बीच edge Worker के लिए यह UX failure है।

Course Eight, Course Six की customer-support workforce को edge component के साथ बनाएगा:

  • Customer अपने browser में OpenClaw bot से बात करता है।
  • OpenClaw bot, contract questions Legal Specialist को delegate करता है (वही Worker जिसे Course Seven की lab में hire किया गया था)।
  • Legal Specialist का response OpenClaw से वापस customer तक flow करता है।

Same workforce, तीन new architectural layers: edge runtime, edge-to-cloud handoff, edge authority।

Course Eight के बाद, सातों invariants पढ़ाए जा चुके होंगे। Track complete है; thesis operationalized है।

Bottom line: Course Seven, Invariant 6 (hiring as callable) close करता है। सात में से छह invariants अब done हैं। Course Eight last one (OpenClaw के through Edge delegate) cover करता है और track complete होता है।

इसमें सचमुच अच्छा कैसे बनें​

Course Seven पढ़ना आपको AI Workers hire करने में अच्छा नहीं बनाता। इसे run करना बनाता है, और path ऐसा दिखता है:

आप एक hire से शुरू करते हैं: Part 4 में Legal Specialist। हर Decision पर friction महसूस होता है:

  • gap-detection rule जो बहुत जल्दी (या पर्याप्त जल्दी नहीं) fire करता है
  • proposal जिसमें board की चाही हुई fields missing हैं
  • eval pack जिसके reference answers वह boundary नहीं पकड़ते जिसे Worker सच में violate करता है
  • substrate choice जो week two में गलत निकलता है

Friction का हर piece ऊपर के पंद्रह Concepts में से किसी एक से map होता है:

  • "The Manager-Agent flagged a gap after one email": Concept 2 के signal thresholds tune करें; one-off cases gaps नहीं होते।
  • "The board asked for budget detail my proposal didn't include": Concept 4 का budgetEstimate field enrich करें।
  • "The eval pack passed but the Worker hallucinated authority in week one": Concept 5 के boundary-respect dimension को strengthen करें।
  • "The Worker is on a managed-cloud substrate paying session-hour fees but only handles 30-second classification tasks": Concept 6 का substrate decision revisit करें; short, simple work के लिए Paperclip-native local adapter या process right fit है।
  • "The board approved the hire but didn't notice the envelope extension": proposal rendering में Concept 8 के novelty checks को more prominent बनाएँ।
  • "The Worker has been on-standby for 2 weeks but Paperclip's UI doesn't show the retirement decision rationale": Concept 11 का retirement flow revisit करें।

हर problem का response तब build करें जब वह सामने आए, पहले नहीं। आपका generateHireProposal function लगभग 30 lines से शुरू होगा और छह महीनों में लगभग 150 lines तक बढ़ेगा; हर new field उस specific decision से earned होगा जिसे board ने visible बनाने को कहा। आपका eval-pack reference rubric तीन dimensions से शुरू होकर सात तक बढ़ेगा। आपकी auto-approval policy library पहले महीने empty होगी, फिर एक policy होगी, फिर पाँच।

Hiring proficiency का 80/20 पंद्रह Concepts memorize करना नहीं है। यह है इतनी जल्दी notice करना कि कोई problem किस Concept से belong करती है कि आप सही Concept तक पहुँच सकें। यही noticing skill है, और यह सिर्फ़ real work पर loop run करने से आती है।

Portability dividend (Course Six से जारी)। एक company के लिए वह noticing build कर लेने के बाद, यह transfer होती है। ऊपर का friction-to-Concept map identical रहता है, चाहे आप SaaS company के लिए Legal Specialist hire कर रहे हों या content platform के लिए Burst-Capacity Tier-1। Decisions अलग दिखते हैं; decisions की shape same होती है। शुरू करने के लिए एक company चुनें, उसके specific patterns सीखें, और जिस moment आप दूसरी company launch करते हैं (या आपकी पहली company acquire होती है और आप नई company में onboard करते हैं), आपकी hiring instincts आपके साथ आती हैं। Companies बदलती हैं। Hiring loop नहीं बदलता।

एक role से शुरू करें। अपने पहले महीने में हर hire के लिए full approval flow use करें। Talent ledger देखें। बाकी अपने आप build होता है।

Quick reference​

15 Concepts, हर एक एक line में​

  1. जो workforce खुद को grow नहीं कर सकती, वह fixed company है। Hiring callable है; alternative board-as-queue है।
  2. Capability gaps तीन signals से fire होते हैं। Low confidence, repeated escalations, no-eligible-Worker। 14 days के भीतर two-of-three gap है।
  3. Capability gaps पर four-way fork। Hire (durable, high-volume, narrow), escalate (consequential या rare), queue (transient), decline (off-mission)।
  4. Job description ही candidate है। Production payload: name, role, title, icon, reportsTo, capabilities, adapterType, adapterConfig, runtimeConfig, sourceIssueId, plus budget।
  5. Approval से पहले eval pack। कम से कम 12 representative test issues; rubric scoring; cost bounded; pass करने के लिए 80% issues में हर dimension पर at least 2 out of 3।
  6. Substrate selection: तीन Paperclip-native paths और दो HTTP-adapter alternatives। claude_local (Paperclip claude CLI spawn करता है; worked example), opencode_local (provider/model के through multi-provider; worked example), process (deterministic, cheapest; no AI)। Plus Agent SDK over http (आप loop host करते हैं) और CMA over http (durable cloud sessions, session-hour billing)।
  7. Hiring, Course Six के approval gate को reuse करती है। Same primitive; richer payload (proposal, eval, envelope, budget)।
  8. Authority envelope inherit, narrow, और (rarely) extend होता है। Novel-authority hires envelope-extension checks trigger करती हैं; board को consciously decide करना होता है कि surface area expand करनी है।
  9. Defined class के लिए auto-approval policy। Pre-approved envelope ceilings, capped concurrency/rate, daily audited, mandatory expiry, company envelope कभी extend नहीं कर सकती।
  10. पहली heartbeat सबसे सस्ती debugging window है। System-prompt issues, envelope miscalibrations, और substrate mismatches पहले 24 hours में surface होते हैं।
  11. Lifecycle states। Verified Paperclip states pending_approval, idle, terminated हैं; curriculum labels "running" और "paused" gaps cover करते हैं। Rehire fresh hire से तेज़ है; termination irreversible है।
  12. Talent ledger queryable institutional memory है। पाँच canonical queries roles-needed, costs-over-time, hire-duration, envelope-history, rehire-ratio answer करती हैं।
  13. Agent portability definition layer पर operate करती है। Recipes travel करती हैं; envelopes, budgets, और ledgers नहीं। "Service-to-a-company" ही hiring का meaning है।
  14. Activity log append-only और cross-correlated है। Permanent history; किसी भी point in time पर queryable; humans बदलने पर institutional memory का source of truth।
  15. Next है Invariant 2: Edge। OpenClaw, edge-to-cloud handoff, edge-tighter envelopes। Course Eight seven-invariant arc complete करता है।

API quick-ref (May 2026 में verified)​

आप क्या करना चाहते हैं...EndpointMethod
Hire submit करना/api/companies/{companyId}/agent-hiresPOST
Identity/permissions check करना/api/agents/meGET
Adapter docs list करना/llms/agent-configuration.txtGET
Adapter-specific docs लेना/llms/agent-configuration/{adapter}.txtGET
Existing agent configurations list करना/api/companies/{companyId}/agent-configurationsGET
Allowed icons list करना/llms/agent-icons.txtGET
Approval पढ़ना/api/approvals/{approvalId}GET
Approval thread पर comment करना/api/approvals/{approvalId}/commentsPOST
Approval को source issue से link करना/api/issues/{issueId}/approvalsPOST
Approval से linked issues list करना/api/approvals/{approvalId}/issuesGET
Pending approval पर revision request करना/api/approvals/{approvalId}/request-revisionPOST
Revised approval resubmit करना/api/approvals/{approvalId}/resubmitPOST
Issue को Worker assign करना/api/issues/{issueId} with { assigneeAgentId }PATCH
Worker को Pause / Resume / Terminate करना(consult current API ref)(varies; see note below)

ऊपर की table में endpoints Paperclip की paperclip-create-agent skill के against verified हैं (skills/paperclip-create-agent/SKILL.md और उसका api-reference.md, canonical sources)। Workers run करने के लिए Paperclip के documented operational primitives Pause, Resume, Override, Reassign, Terminate हैं; इन primitives के exact endpoint paths version के अनुसार vary कर सकते हैं, इसलिए अपने deployment में current API surface के लिए GET /llms/agent-configuration.txt consult करें। Course का Decision 7 pause/resume code को same caveat inline include करता है। सभी requests Authorization: Bearer $PAPERCLIP_API_KEY carry करती हैं। Mutating requests Content-Type: application/json carry करती हैं।

CMA quick-ref (May 2026 में verified)​

आप क्या करना चाहते हैं...SDK callNotes
Agent create करनाcma.beta.agents.createmodel (a bare string), system, tools pass करें
Environment create करनाcma.beta.environments.createname और config object (type, packages, networking) pass करें
Session create करनाcma.beta.sessions.createagent (agent_id नहीं) और environment_id pass करें
Event send करनाcma.beta.sessions.events.sendSession में user.message event push करें
Results stream करनाcma.beta.sessions.events.streamSession के events की SSE stream

CMA beta API है और ये shapes releases के बीच shift होते हैं; live docs को authoritative मानें। सभी requests beta header managed-agents-2026-04-01 carry करती हैं (SDK इसे set करता है)। CMA session उन events से driven होता है जिन्हें आप भेजते हैं, inbound URL से नहीं: Paperclip integration के लिए इसका क्या मतलब है, Concept 6 का sidebar देखें। Pricing: standard Claude API tokens plus active execution के लिए per-session-hour runtime charge (current rate के लिए Anthropic pricing page देखें)। Reference: platform.claude.com/docs/managed-agents।

Hiring में कुछ गलत लगे तो​

Manager-Agent proposed a hire after 2 emails, didn't wait for pattern?
    -> Concept 2's signal thresholds too sensitive. Tune the
       "at least 3 issues / at least 3 escalations / 14-day window" thresholds.

Board approved a hire but the Worker burned 3x the forecasted budget?
    -> Concept 4's budget estimate was wrong. The Worker is on the
       wrong substrate (Concept 6) or the eval pack's session-cost
       sample was unrepresentative (Concept 5).

Worker is producing wrong-tone or wrong-boundary replies in week one?
    -> System prompt is poorly scoped. Tighten the capabilities
       prose (Concept 4) and re-run a small eval pack (Concept 5).

Hire proposal kept getting REQUEST CHANGES from the board?
    -> Proposal artifact is missing context. Read Concept 7's
       rendering carefully and add the missing fields.

Two new authorities granted in one month; auditor asking why?
    -> Concept 8's envelope-extension records have rationale fields.
       Run the talent-ledger query (Concept 14, Query 4).

Architect का framing sentence: verbatim​

Course उसी तरह close होता है जैसे खुला था, framing sentence के साथ:

"A workforce that cannot grow itself is a fixed company; a workforce that can grow itself under approval is an AI-native company. Hiring in the Agent Factory is not an HR motion; it is a function call from the manager, taking a job description as input, returning a Worker as output, gated by the same approval primitive that gates every other consequential action."

Sentence याद रखें। Architecture follow करता है।

Agentic-coding track का Course Seven। सात में से छह invariants अब close हो चुके हैं: management plane (Course Six), nervous system (Course Five), system of record और Skills (Course Four), agent loop (Course Three), human as principal (Courses Five और Six), और अब hiring API (Course Seven)। Remaining invariant, OpenClaw के through Edge delegate, Course Eight है।

Flashcards Study Aid​