Fixed se Dynamic Workforce tak: Hiring API, Capability Gaps, aur Talent Ledger

15 Concepts. Taqreeban 2 se 3 ghante conceptual reading ke liye (agar PRIMM Predicts seriously karein to zyada), aur 2 se 3 ghante hands-on lab ke liye. Total half-day plan karein.

Yeh continuation crash course hai. Agentic-coding track mein yeh Course Seven hai. Course Three, Build AI Agents with the OpenAI Agents SDK and Cloudflare Sandbox, ne streaming chat agent banwaya tha. Course Four, From AI Agent to Digital FTE, ne us chat agent ko Skills, Neon Postgres system of record, aur MCP ke saath Digital FTE banaya. Course Five, From Digital FTE to Production Worker, ne Digital FTE ko Inngest operational envelope mein wrap kiya taake duniya usay wake kar sake aur crash us ki state lose na kare. Course Six, From One Worker to a Workforce, ne Paperclip management layer add ki, jahan ek ya zyada Workers assignments, budgets, approvals, aur audit trail ke saath workforce ban gaye. Woh workforce teen Workers par mushtamil thi jinhein human ne company creation ke waqt choose kiya tha. Course Seven yeh batata hai ke jab chotha Worker zaroori ho jaye aur workforce usay lane ke liye hiring API call kare, to kya hota hai.

Woh single insight jo baqi sab kuch clear kar deti hai: AI-native company mein hiring koi quarterly HR motion nahin hoti. Yeh ek callable capability hoti hai jo workforce khud par invoke karti hai, aur jise bilkul wahi approval primitive gate karta hai jo $500 refund ko gate karta hai. Board job posting nahin likhta. Manager-Agent likhta hai. Board approve karta hai, aur naya Worker usi dopahar org chart par aa jata hai. Is course ke end tak Course Six ki customer-support workforce ek missing capability detect kare gi, hiring proposal draft kare gi, usay approval gate se guzare gi, aur Legal Specialist ko org chart mein welcome kare gi - sab kuch usi activity_log plus cost_events ledger par jahan original teen Workers bhi likhte hain.

Agent Factory ke liye yeh kyun important hai: Invariant 6 full

Thesis AI-native company ke liye seven invariants name karti hai. Course Six ne un mein se teen cover kiye (management plane, human as principal, nervous system ka ek hissa). Course Seven sab se gehra claim cover karta hai: Invariant 6, hiring is a callable capability. Architect ka framing sentence yeh hai, jis ke gird poora course bana hai:

"Jo workforce khud grow nahin kar sakti woh fixed company hai; jo workforce approval ke under khud grow kar sakti hai woh AI-native company hai. Agent Factory mein hiring HR motion nahin; manager ki taraf se function call hai jo job description ko input leta hai, Worker ko output return karta hai, aur usi approval primitive se gated hota hai jo har consequential action ko gate karta hai."

Is ke baad seven invariants mein se six close ho jate hain. Jo ek baqi hai, Invariant 2 (the Edge delegate), woh Course Eight ka domain hai.

AI-native company mein hiring ko uniquely interesting capability banane wali chaar properties hain, jo kisi aur tool call mein nahin hotin. Har property ka apna Concept aage aata hai; shape yeh hai:

1. Hire-decision khud agent decision hota hai. Jis Worker ke paas hire karne ka authority nahin, woh phir bhi gap flag kar sakta hai. Jis Worker ke paas can_create_agents=true ho, woh draft aur submit kar sakta hai. Yeh line company envelope (Invariant 1) set karta hai, code nahin. (Concepts 1, 3.)
2. Naya Worker aisa authority envelope inherit karta hai jo hire se pehle maujood nahin tha. Legal Specialist ka contract_modify=allow kisi existing Worker ke envelope mein nahin hota. Hire request wahi jagah hai jahan naya envelope negotiate hota hai. (Concept 8.)
3. Hire board-level act hai, chahe proposal agent ne diya ho. Course Six ka approval gate wahi rehta hai. Board jo artifact dekhta hai woh proposal hota hai: job description, capability eval, expected budget. (Concept 7.)
4. Hires reversible hain. Course Six ne Workers ko startup par once-configured maana tha. Course Seven lifecycle add karta hai: hire, evaluate, deploy, retire, zaroorat par rehire. Talent ledger yeh sab track karta hai. (Concepts 7, 14.)

Agent Factory thesis is Invariant 6 ko "The workforce is expandable under policy" kehti hai: workforce board ki authority ke under khud grow kar sakti hai. Course Five ne Invariant 7 (nervous system) aur Invariant 1 (HITL) ka ek hissa cover kiya. Course Six ne Invariant 3 (management plane) cover kiya aur Invariant 6 ko edge par surface kiya. Course Seven Invariant 6 ko full close karta hai; Course Eight ke liye sirf Invariant 2 (the Edge delegate) reh jata hai.

About the platform choice

Course Six ne aap ko Paperclip (paperclip.ing, github.com/paperclipai/paperclip) ko agentic management layer ke taur par use karna sikhaya tha. Course Seven usi instance ko extend karta hai. Course Six ka wahi npx paperclipai onboard --yes aap ko hiring API deta hai. Yeh different product nahin, different endpoint hai. Course Seven verified endpoint sikhata hai: POST /api/companies/{companyId}/agent-hires. Verified governance flow: hire pending_approval return karta hai, board approval thread par comments karta hai, aur approval ke baad agent PAPERCLIP_APPROVAL_ID ke saath wake hota hai.

Course Seven worked example ko do Paperclip-native runtime adapters par side by side chalata hai: claude_local aur opencode_local. Dono first-class Paperclip primitives ke taur par ship hote hain; Paperclip har heartbeat par local coding-agent CLI khud spawn karta hai (claude_local ke liye headless claude, opencode_local ke liye headless opencode), CLI ke environment mein PAPERCLIP_API_URL aur PAPERCLIP_API_KEY inject karta hai, aur CLI Paperclip ki apni API ke against turn chalata hai. Koi external service nahin, koi inbound URL nahin, koi relay nahin, koi separate cloud account nahin. Same hire payload sirf adapterType aur adapterConfig mein differ karta hai, aur architectural point bhi yahi hai: management plane ke perspective se hiring substrate-agnostic hai, aur local-CLI pair us ka sab se sasta proof hai.

Do adapters kyun, ek kyun nahin? Importance ke order mein do wajahen hain.

1. Multi-provider portability hi "substrate-agnostic" hone ka binding test hai. Single-adapter worked example hamesha aisa lagta hai ke "architecture generic hai agar aap yeh ek runtime choose karein." Wahi hire claude_local (single-provider, sirf Anthropic models) aur opencode_local (multi-provider; wahi adapter provider/model slug ke zariye Anthropic, OpenAI, Google, ya OpenCode ke supported kisi bhi provider ko chala sakta hai) par chalana is property ko concrete dikhata hai. Agar reader Legal Specialist ko anthropic/claude-opus-4-7 par chalana chahe, Decision 4 ka opencode_local tab swap dikhata hai. Agar woh openai/gpt-5.2-pro chahe, sirf adapterConfig.model string change hoti hai. Hiring loop apni jagah rehta hai.
2. Zero infrastructure ka matlab hai reader lab complete kar sakta hai. Dono adapters usi machine par chalte hain jahan Paperclip daemon chal raha hota hai. Na beta access, na separate cloud account, na relay server, na inbound URL. Reader do CLIs (claude aur opencode) install karta hai, har ek ko ek dafa authenticate karta hai, aur baqi lab Paperclip ko API calls hai. Jo substrates integrate karne mein sab se hard hain (Claude Managed Agents jaisi managed-cloud products, Cursor Cloud jaisi vendor-hosted products) tab apni jagah banate hain jab workload unhein demand kare; decision rubric aur trade-offs ke liye Concept 6 ka substrate table dekhein.

Agar aap ki team managed-cloud runtime prefer karti hai (Anthropic ka relevant option Claude Managed Agents hai; Concept 6 usay explicitly name karta hai) ya self-hosted Agent SDK endpoint chahti hai, hiring API unchanged rehti hai. Sirf adapterType aur adapterConfig differ karte hain. Decision 4 do local tabs side-by-side dikhata hai; Concept 6 ka substrate table named alternatives cover karta hai.

May 2026 tak known rough edges (samne aayein to hairan na hon)

• Claude Managed Agents public beta mein hai. Har request par beta header managed-agents-2026-04-01 required hai. Releases ke darmiyan behavior refine ho sakta hai.
• CMA ka multi-agent orchestration research preview hai jiske liye alag access request chahiye (official docs ke mutabiq: official overview). Course ka worked example single-agent CMA sessions use karta hai aur multi-agent feature par depend nahin karta.
• Paperclip ka hiring approval workflow implemented aur shipping hai, lekin custom auto-approval policies likhne wali UI (Concept 9) abhi partly CLI-driven hai. "auto-approve burst-capacity hires under $X per month" se zyada sophisticated policy ke liye buttons click karne ke bajaye JSON edit karne ki expectation rakhein.
• Jab hire kisi issue se triggered by ho (sourceIssueId link), per-issue cost attribution activity_log mein correctly record hoti hai, lekin "proposal time, eval time, aur first month of work mein hire ki cost kya thi" query karne ke liye teen tables join karne parte hain. Unified hire_lifecycle view ke liye ek open issue tracked hai.

Yeh hiring se bachne ki wajah nahin hain. Yeh ek young, popular, aur improving frontier API ki normal state hai. In ki wajah se aap ko versions pin karne, simplest case se aage UI-driven hiring ke bajaye code-driven hiring prefer karne, aur aise hires kabhi auto-approve na karne chahiye jo Worker ko woh authority grant karte hon jo org chart par pehle se kahin maujood nahin.

TL;DR (read this first if you have 60 seconds)

Chaar claims order mein yeh hain:

1. Workforce detect kar sakti hai ke org chart par koi Worker yeh kaam handle nahin kar sakta.
2. Manager-Agent hiring proposal draft karta hai: job description, eval pack, expected budget, draft authority envelope.
3. Proposal Course Six ke approval gate se guzarta hai. Human usay dekhta hai. Human decide karta hai.
4. Approval par Paperclip ka POST /api/companies/{id}/agent-hires selected runtime ke against naya Worker provision karta hai (worked example ke liye Claude Managed Agents). Org chart mein ab teen ke bajaye chaar Workers hote hain.

The plain-English version, if any of that lost you

Course Six mein hum ne teen Workers wali choti AI company banayi thi: Tier-1 Support, Tier-2 Specialist, aur Manager-Agent jo un ke darmiyan route karta hai. Is course mein company notice karti hai ke usay chotha Worker chahiye (contract-review questions baar baar aa rahe hain jinhein teenon mein se koi achi tarah handle nahin kar sakta), Manager-Agent hiring proposal draft kar ke permission maangta hai, candidate ko human board ke dekhne se pehle test kiya jata hai, aur approval par naya Worker org chart mein add ho jata hai. Baqi course sirf yeh detail hai ke in steps mein se har step asal mein kaise kaam karta hai.

Course Six recap: the workforce you're extending (click to expand)

Course Six ne Paperclip par three-Worker customer-support workforce banayi thi. Workers yeh thay:

• Tier-1 Support (Course Five ka customer-email Inngest function, http adapter ke zariye adapted): routine refund, FAQ, aur status queries handle karta hai; $200 per month budget; refund_max=$50; external email ko approval chahiye.
• Tier-2 Specialist (aik claude_local adapter): complex multi-turn cases aur Tier-1 se escalations handle karta hai; $800 per month budget; refund_max=$500; external email allowed.
• Manager-Agent (aik http adapter): routing orchestrate karta hai, issues par comments karta hai, approvals request karta hai; $200 per month budget; refund_max=$0; tamam consequential actions ko approval chahiye.

Course Six ke eight Decisions ne in teen Workers ko Paperclip mein wire kiya, company envelope define kiya (refund_max=$5000, contract_modify=board_only), inbound emails ko activity_log ke through route kiya, aur $750 refund par approval gate demonstrate kiya (Decision 6). Course Seven assume karta hai ke woh workforce maujood aur running hai.

Agar aap ne Course Six skip kiya hai, to neeche Workforce vs Worker section Course Seven follow karne ke liye enough on-ramp de deta hai, lekin aap ke paas actual hire karne ke liye workforce nahin ho gi. Pehle Course Six lab spin up karni ho gi.

Where this fits: cheat sheet

#	Concept	Layer	Is ke baad aap kya jawab de sakenge
1	Jo workforce khud grow nahin kar sakti woh fixed company hai	Management plane	Hire karne ki capability, hiring ke act jitni important kyun hai? Kyun ke fixed workforce, fixed company hoti hai.
2	Capability gaps: teen signal types	Management plane	Manager-Agent kaise janta hai ke Worker chahiye? Low routing confidence, repeated escalations, skill match se koi eligible Worker na milna.
3	Hire vs escalate vs queue vs decline	Management plane	Capability gap par sahi response kya hai? Volume, value, novelty par decision tree.
4	Job description as code	Hiring API	Hire request kaisi dikhti hai? Role, capabilities, adapter, runtime, source issue wala JSON payload.
5	Hire se pehle capability evaluation	Hiring API	Candidate Worker ko real issues milne se pehle kaise test kiya jata hai? Scored rubric wala eval pack, accept/reject.
6	Substrate selection: local CLIs, Agent SDK, managed-cloud, ya process	Runtime	Naya Worker Paperclip-native local adapter par kab dalna hai vs Agent SDK vs Claude Managed Agents vs process? Decision table.
7	Hiring approval gate	Management plane	Course Six ka approval primitive hiring par kaise map hota hai? Wahi primitive, richer payload ke saath (proposal, eval, budget, envelope).
8	New hires ke liye authority envelope	Management plane	Brand-new role ko refund_max kitna mile, yeh kaise decide hota hai? Hire proposal mein negotiate, approval par lock, activity_log mein record.
9	Hires ki ek class ke liye auto-approval policy	Management plane	Unattended hiring kab acceptable hai? Pre-approved classes (burst-capacity, cost ceiling ke neeche narrow specialties), continuous audit.
10	Worker ka pehla heartbeat	Lab	Approval aur naye Worker ke pehle real issue ke darmiyan kya hota hai? Activated heartbeat, routing, Worker ka idle se real work ki taraf transition.
11	Retirement aur rehire: full lifecycle	Lab	Traffic kam ho jaye to kya hota hai? Worker ko pause karein (Paperclip is primitive ko "Pause" ke taur par ship karta hai). Cycle mein teen cheezein preserve rehti hain; rehire fast hota hai.
12	Talent ledger: six-month-old workforce kaisi dikhti hai	Audit	Har hire, eval, retirement, rehire ka queryable record. Five canonical SQL queries board ke actual operational sawalon ka jawab deti hain.
13	Agent-portability question	Open	Kya Company A mein hired Worker Company B ko serve kar sakta hai? Recipe travel kar sakti hai; relationship nahin.
14	Talent ledger kyun matter karta hai: personnel change ke across institutional memory	Audit	Teen properties (append-only, cross-correlated, kisi bhi waqt queryable) jo six-month log ko leaving human ki institutional memory replace karne deti hain.
15	Agla qadam: Invariant 2 aur Edge	Forward	Course Eight kahan se pick up karta hai? Remaining invariant: OpenClaw ke zariye Edge delegation.

Are you ready for this course?

Prereq checklist

Course Seven aik technical reader assume karta hai jis ne ya to:

1. Course Six complete kiya hai, ya equivalent experience rakhta hai. Aap ne Paperclip locally stand up kiya hai, company mein teen workers hire kiye hain, aik approval flow wire kiya hai, aur activity_log populate hota dekha hai.
2. aap TypeScript parh sakte hain, chahe usay fluently likh na sakte hon. The lab uses TypeScript primarily (Paperclip's native language) for the Manager-Agent's gap-detection logic, the hire proposal generator, and the approval-flow wiring. aap ka AI assistant may also produce Python, SQL, or shell snippets when a particular sub-task fits them better (the eval-pack runner is a natural Python fit; the talent-ledger queries are SQL). All code is read-only for following the course; the briefing pattern means aap ka AI coding assistant types everything. You brief, review, and approve. If a code block looks unfamiliar, the right response is to ask aap ka assistant to explain it, not to type it khud.
3. Aap ke paas dono local coding-agent CLIs installed aur authenticated hain. Decision 4 wahi hire claude_local par chalata hai (jo har heartbeat par claude CLI headless spawn karta hai) aur opencode_local par bhi (jo opencode CLI headless spawn karta hai). Dono install karein, confirm karne ke liye claude --version aur opencode --version chalayein, aur har ek ko ek dafa authenticate karein. claude_local ko Anthropic account chahiye; opencode_local OpenCode ke supported kisi bhi provider (Anthropic, OpenAI, Google, aur others) ko provider/model slug ke zariye route kar sakta hai, is liye aap ka provider key is baat par depend karta hai ke adapterConfig.model mein kaunsa slug lagate hain. Agar Decision 4 mein sirf ek tab chalana hai, to sirf woh CLI install karein; lab wahi hiring loop sikhata hai, bas aap usay ek substrate par dekhte hain. Agar baad mein managed-cloud runtime prefer karna ho, to Concept 6 ka substrate table Claude Managed Agents (Anthropic ka hosted long-running-agent product, May 2026 tak public beta) aur Claude Agent SDK ko named alternatives ke taur par un ke trade-offs ke saath cover karta hai.
4. Aap approvals ko primitive ke taur par samajhte hain. Agar "approval = Paperclip run ko durably suspend karta hai, board ko request post karta hai, durable wait karta hai, aur board decision par resume karta hai" aapko mystery ke bajaye clean pattern lagta hai, to aap calibrated hain. Agar nahin, continue karne se pehle Course Six Concept 11 revisit karein.
5. Aap is baat se comfortable hain ke 'AI Worker hire karna' sahi verb hai. Kuch readers ko corporate-staffing vocabulary jarring lagti hai. Hum isay deliberately use karte hain, metaphor ke taur par nahin. Architectural decisions (envelope, budget, retirement, ledger) tabhi sense banate hain jab aap role-and-employment frame ko seriously lein. Agar aap isay "management layer ke under naya long-running process register karna" samajhna chahein, to underneath exactly yahi ho raha hai; vocabulary usi machinery ko samajhne ka aasaan handle hai.

Agar in paanch mein se koi cheez shaky lagay, to continue karne se pehle linked refreshers se shuru karein. Course dense hai; prerequisites isay halka mehsoos karwati hain.

New here? Course Seven is dense: here's the on-ramp

Yeh Agent Factory track ka seventh course hai. Agar upar ke five prerequisites unfamiliar lag rahe hain, to backwards kaam karein: Course Six: One Worker se Workforce tak direct prerequisite hai (Paperclip plus management plane). Us se pehle Course Five: Digital FTE se Production Worker tak hai (Inngest operational envelope), phir Course Three: Build AI Agents hai (agent loop), aur agar aap AI-assisted coding mein bilkul naye hain to PRIMM-AI+ chapter. Course Seven har ek do pages baad Course Six concepts reference karta hai; cold start karna on-ramp complete karne se mushkil hai.

Agar aap abhi on-ramp complete nahin kar sakte lekin concepts follow karna chahte hain, aap prerequisites ko lightweight tareeqe se cover kar sakte hain with much less than Course Six's full stack: read the Paperclip Quickstart (about 15 minutes) and the Approvals page (about 10 minutes); skim the PRIMM-AI+ Lesson 1 for the prediction-then-run rhythm the course uses in every Concept; treat Inngest as "the thing that lets a Worker pause durably for hours" without learning its API. With those three substitutes, aap Parts 1 through 3 and Part 5 through 6 conceptually follow kar sakte hain. Part 4 lab still requires a working Paperclip install; there's no shortcut for that.

Glossary: 24 terms a beginner can reference (click to expand)

Course Seven Agent Factory track bhar ki vocabulary use karta hai. Agar body mein koi term confuse kare, to yeh glossary fastest reference hai. Terms ko un cheezon ke mutabiq group kiya gaya hai jinhein woh describe karte hain.

People and roles

• Worker: ek AI agent jo company ke liye kaam karta hai. Is curriculum mein Worker ki identity, budget, authority envelope, aur org chart par jagah hoti hai. General AI sense wale "agent" se farq yeh hai ke Worker company ke zariye employed hota hai, sirf user ke zariye invoked nahin.
• Workforce: ek company ke tamam Workers ka set. Course Six ne 3-Worker workforce banayi; Course Seven 4th Worker hire karta hai.
• Manager-Agent: woh Worker jo baqi Workers ko orchestrate karta hai. Issues route karta hai, hiring proposals draft karta hai, approvals par comments karta hai. Course Seven ka protagonist yahi hai.
• Board: company ke human owner(s). Hires approve karte hain, policy set karte hain, talent ledger review karte hain. Approval primitive board attention ko gate karta hai.

Paperclip primitives

• Paperclip: AI workers ke liye open-source management plane. Org chart, budgets, approvals, aur audit provide karta hai. Course Six ka main subject tha; Course Seven isay extend karta hai.
• Issue: Paperclip ka task/ticket primitive. Workers issues handle karte hain. Issues Manager-Agent ke zariye Workers ke darmiyan route hote hain.
• Adapter: Paperclip Worker se kaise baat karta hai. Official docs built-in adapters ka set ship karti hain; is course mein referenced adapters claude_local, opencode_local, codex_local, process, aur http hain. Course Seven ka worked example Decision 4 mein claude_local aur opencode_local side by side use karta hai (Paperclip har heartbeat par claude ya opencode CLI headless spawn karta hai). Aap ki deployment mein full adapter list discover karne ke liye curl $PAPERCLIP_API_URL/llms/agent-configuration.txt run karein.
• Adapter config: adapter ki per-Worker settings. http adapter ke liye url, optional headers (jahan auth travel karta hai), aur timeoutSec. Hire payload mein set hota hai.
• Heartbeat: scheduled ya event-triggered wake-up jisse Worker naya kaam check karta hai. runtimeConfig.heartbeat mein configured hota hai.
• Skill: reusable knowledge bundle jise Worker call kar sakta hai. Paperclip paperclip-create-agent skill ship karta hai jo hiring workflow walk karata hai; yeh curriculum usi ke upar built hai.
• activity log: append-only table jahan har mutating action record hota hai. Talent ledger ka source of truth.
• Cost events: table jahan har token spend aur session-hour charge record hota hai, agent_id aur issue_id se tagged.
• approval gate / approval primitive: Paperclip ka mechanism jo decision ko board ke saamne surface karta hai aur response ke liye durably wait karta hai. Originally refunds ke liye tha (Course Six); ab hiring ke liye unchanged reuse hota hai (Course Seven).
• Source issue: woh issue jis ne hire trigger ki. Hire payload mein sourceIssueId ke zariye linked hoti hai. Yeh audit anchor Worker ke existence ko us kaam se connect karta hai jis ne usay justify kiya.

Authority concepts

• Authority envelope: authorities ka set jo Worker (ya company) hold karta hai. Misaals: refund_max=$500, contract_modify=deny, external_email=allow. Envelope yeh bound karta hai ke Worker kya kar sakta hai.
• Envelope cascade: layered structure: company envelope, role envelope, issue envelope, approval-level envelope. Har layer apne upar wali layer se narrow hoti hai.
• Envelope extension: company envelope ko aisi authority dena jo kisi existing Worker ke paas nahin thi. Normal hire se aage board-level approval chahiye.

Course Seven concepts

• capability gap: kaam ki woh category jise workforce abhi handle nahin kar sakti. Teen signals se detect hoti hai (Concept 2).
• Eval pack: lagbhag 12 representative test issues ka set jinke known reference answers hote hain; approval se pehle candidate Worker score karne ke liye use hota hai. Concept 5.
• Substrate: Worker asal mein kahan run karta hai. Options mein Claude Managed Agents, Claude Agent SDK, claude_local, aur process shamil hain. Concept 6.
• Talent ledger: workforce history ke har hire, eval, retirement, aur rehire event ka cumulative record (activity_log plus cost_events mein). SQL speed par institutional memory.

Tech and products

• Inngest: Course Five ka durable-execution platform. step.wait_for_event provide karta hai (approval-gate durability ko power karne wala primitive) aur crash-safe Worker runs deta hai.
• Claude Managed Agents (CMA): long-running agents ke liye Anthropic ka hosted infrastructure. April 2026 se public beta; official docs. Chaar core concepts ke around built hai: Agent (configuration), Environment (container template), Session (running instance), aur Events (aap ki application aur agent ke darmiyan SSE message stream). Course Seven ka worked-example substrate.
• Claude Agent SDK: self-hosted agents ke liye Anthropic ka programmatic harness. Course Seven ka alternative substrate (Concept 6 sidebar).

Thesis-level

• AI-native company: aisi company jiska kaam primarily AI workers human governance ke under karte hain, jahan management plane primary interface hota hai. "AI-augmented company" ka architectural opposite.
• Invariant: AI-native company ki seven architectural properties mein se ek. Course Seven Invariant 6 close karta hai (hiring as callable). Course Eight Invariant 2 close karta hai (the Edge delegate).
• Briefing pattern: is course ka pedagogical principle: students code haath se nahin likhte. Woh apne AI coding assistant (Claude Code ya OpenCode) ko briefings likhte hain, jo code produce karta hai. Student ka kaam achi briefing, review, aur approval hai.

---

Part 1: Hiring callable kyun hai

Teen concepts jo establish karte hain ke workforce ko khud grow karne ki zaroorat kyun hoti hai aur system kaise pehchanta hai ke kab grow karna chahiye. Abhi code nahin; lab Part 4 mein start hoti hai. Skip-ahead readers worked example ke liye Part 4 par jump kar sakte hain, lekin lab ki gap-detection logic assume karti hai ke aap Concepts 1 through 3 internalize kar chuke hain.

Concept 1: Jo workforce khud grow nahin kar sakti woh fixed company hai

Course Six ki workforce teen Workers thi: Tier-1 Support, Tier-2 Specialist, Manager-Agent. Human ne company-creation time par yeh teen choose kiye. Woh us waqt maujood kaam handle karte thay. Org chart set tha.

Pehli dafa jab inbound email aisi cheez maangti hai jo teenon Workers mein se koi nahin kar sakta, to kya hota hai? Customer-support example mein is ki sab se realistic shakal contract terms ka sawal hai: customer poochta hai, "hamare agreement ke Section 7.3 mein 'material breach' se kya murad hai?" Tier-1 jawab nahin de sakta; refund policy apply nahin hoti. Tier-2 bhi jawab nahin de sakta; yeh escalated case nahin, kaam ki alag category hai. Manager-Agent isay kahin route nahin kar sakta kyun ke routing options khatam ho chuke hain. Course Six ke model mein yeh email stuck ho jati hai. Manager-Agent isay human board tak escalate karta hai. Human email parhta hai aur samajhta hai: is ke liye hamare paas Worker nahin hai. Phir Slack thread khulta hai, purana contract-review precedent search hota hai, reply human khud draft karta hai, aur email answer ho jati hai.

Yeh ek dafa ho to theek hai. Ek month mein barah dafa ho to pattern hai. Ek month mein pachaas dafa ho to workforce ko grow karne ki zaroorat hai.

AI se pehle workforce grow karne ka tareeqa quarterly HR motion tha: gap identify karein, job description likhein, role post karein, candidates interview karein, hire karein, onboard karein, ramp karein. Minimum six weeks, typical twelve weeks, aur har step par human board bottleneck hota tha. AI-native company mein yeh motion twelve weeks nahin lena chahiye. Isay ek afternoon lena chahiye, aur board sirf wahan bottleneck rahe jahan board khud bottleneck banna chahta ho: hire consequential ho, envelope naya ho, ya grant hone wali authority novel ho.

Invariant 6 ka claim yahi hai. Architect ki framing:

"Jo workforce khud grow nahin kar sakti woh fixed company hai; jo workforce approval ke under khud grow kar sakti hai woh AI-native company hai. Agent Factory mein hiring HR motion nahin; manager ki taraf se function call hai jo job description ko input leta hai, Worker ko output return karta hai, aur usi approval primitive se gated hota hai jo har consequential action ko gate karta hai."

Course Six se mental model shift yeh hai: Course Six mein Manager-Agent existing workforce ko coordinate karta tha. Course Seven mein Manager-Agent workforce ka size aur shape badal sakta hai. Manager akela decide nahin karta, kyun ke human-in-the-loop discipline abhi lock ki gayi hai. Lekin Manager initiate karta hai: proposal draft karta hai, eval chalata hai, budget estimate likhta hai. Board review aur approve karta hai. Naya Worker usi afternoon org chart par aa jata hai.

PRIMM: Predict

Andaaza karein aap startup join karne wale engineer hain. CEO kehta hai: "Hamare paas AI-native customer-support workforce hai. Teen Workers routine cases handle karte hain. Last month humein 47 contract-related emails milin jinhein teenon mein se koi handle nahin kar saka. Human board ne tamam 47 personally parhin. Average response time 32 hours tha, do outside counsel tak escalate huin, ek miss ho gayi aur customer churn kar gaya."

Confidence 1 se 5: hiring loop add karne ka strongest case kaun sa hai? (Ek choose karein.) (a) 32-hour response time. (b) Do cases outside counsel tak escalate huin. (c) Ek missed case jis se churn hua. (d) Board ne tamam 47 personally parhin.

Jawab: (d). Baqi teen symptoms hain; (d) root cause hai. Hiring loop ke baghair workforce har novel work category ko human board par push karti hai. Board queue ban jata hai. Customers ko 32-hour latency aur missed cases is liye nahin milte ke work hard hai, balki is liye ke queue human-bottlenecked hai. Hiring loop workforce ko contract questions ka 90% Legal Specialist Worker tak route karne deta hai, jab ke board sirf genuinely consequential cases review karta hai: outside counsel escalations, novel contract language, ya aise customers jahan board member ko personally weigh in karna ho. Hiring loop ki zaroorat measure karne ka sahi metric response time ya churn nahin; yeh hai ke board ki attention ka kitna hissa us work par lag raha hai jo workforce ko khud karna chahiye. Agar board queue hai, aap ko hiring loop chahiye.

Bottom line: agar aap ki workforce gaps discover karne par new roles add nahin kar sakti, to human board har novel work category ki queue ban jata hai. Hiring woh function hai jo board-as-queue dysfunction ko rokta hai.

Concept 2: capability gaps, three signal types

Capability gap detection Course Seven ka technical heart hai. Yeh woh jagah hai jahan Manager-Agent decide karta hai: "yeh kaam consistently aa raha hai aur consistently is ke liye route karne ko koi Worker nahin hai." Teen signals gap detection trigger karte hain. Har signal ki remediation alag hai; Manager-Agent teenon ko watch karta hai magar har ek par alag react karta hai.

Signal 1: Low routing confidence. Jab Manager-Agent ki routing logic batati hai ke kaun sa Worker issue handle kare, magar confidence score kai din tak multiple issues par threshold se neeche rahe, to routing options ghalat hain. Ek week mein teen contract-related emails, har ek "Tier-2 Specialist (default)" ko 0.4 se 0.6 confidence ke saath route ho, sirf is liye ke koi better option nahin: yeh routing problem nahin, workforce-composition problem hai. Manager-Agent ko inhein Tier-2 ko route karte nahin rehna chahiye, jo inhein poorly handle kare ga aur budget burn kare ga; usay pattern flag karna chahiye.

Signal 2: Repeated escalations. Jab Workers certain issue types ko consistently human board tak escalate karte hain ("mere paas yeh decision lene ki authority nahin" ya "yeh mere domain se bahar hai"), aur escalations recognizable category par cluster hoti hain, to org chart mein role missing hai. Ek escalation per week noise hai. Har month aath escalations, sab contract-review questions par, hire-the-specialist signal hai.

Signal 3: Skill match se eligible Worker na milna. Jab naya issue aaye aur Manager-Agent ka skill-matching step empty result set de, yani org chart par kisi Worker ke paas is issue ki claimed skill na ho, to work genuinely novel hai. Misaal: "yeh email Bahasa Indonesia se English mein translate karein" wali emails ka burst, jab kisi Worker ki skills mein language=indonesian nahin. Manager-Agent ko guess nahin karna chahiye; usay flag karna chahiye.

Teenon signals independent nahin hain. Novel work category (Signal 3) also low confidence (Signal 1) paida kare gi aur also escalations (Signal 2) paida kare gi. Magar signals mukhtalif orders mein fire hote hain: Signal 1 pehle fire hota hai, such issue ke aane ke hours ke andar; Signal 2 baad mein fire hota hai, consistent escalations ke week baad; Signal 3 tab fire hota hai jab skill model khud new category recognize karne lage. Manager-Agent ko capability-gap alert tab fire karna chahiye jab 14-day window ke andar same category par teen mein se koi do signals fire hon. Yeh rule of thumb one-off cases filter karta hai aur genuine patterns do weeks ke andar catch karta hai.

Signal	Fires when	Fires after	Remediation
Low routing confidence	Confidence under 0.6 on three or more issues in same category	Hours to days	Manager flags category, logs to gap-detection ledger
Repeated escalations	Three or more escalations to human board on same category	Days to weeks	Manager opens a "gap detected" issue in Paperclip
No eligible Worker by skill	Skill-match returns empty for issue's claimed skills	Immediate	Manager auto-routes to "unassigned" queue and flags

Capability-gap detection ka output hire request nahin hota. Yeh Paperclip ke activity_log mein gap-detected record hota hai jise Manager-Agent baad mein hiring proposal draft karte waqt reference kar sakta hai. Proposal step Concept 4 hai. Gap-detection step sirf "noticed and recorded" hai; deliberate separation is liye hai ke Manager-Agent aise gaps bhi detect kar sake jin ke liye board abhi hire nahin karna chahta. Jo startup yeh decide kar raha ho ke contract work ek Worker justify karta hai ya nahin, usay decision se pehle gap pattern dekhna chahiye.

Quick check

Aap ka Tier-2 Specialist Worker do weeks se contract questions handle kar raha hai kyun ke koi dusra Worker eligible nahin. In issues par routing confidence taqreeban 0.55 rahi hai. Tier-2 ne in mein se kisi ko escalate nahin kiya; woh apni best koshish kar raha hai, budget burn kar raha hai, aur kabhi ghalat answers de raha hai. Do weeks baad, kya rule-of-thumb gap-detection rule (14 days ke andar same category par teen mein se koi do signals) fire ho ga? Walk through karein ke kaun se signals present hain aur kaun se absent.

Bottom line: capability gap tab fire hota hai jab teen signals mein se do (low routing confidence, repeated escalations, skill match se eligible Worker na milna) 14 days ke andar same category par hit karein. One-off cases count nahin hote; rule noise filter kar ke genuine patterns do weeks ke andar catch karne ke liye tuned hai.

Concept 3: Hire vs escalate vs queue vs decline

Jab capability gap detect ho jaye to agla decision hai: is ke saath karna kya hai. Hiring hamesha sahi answer nahin. Teen aur answers bhi hain, aur jo Manager-Agent sirf "hire" janta ho woh bohat zyada hire kare ga. Decision four-way fork hai.

Hire tab karein jab work pattern durable ho (continue hone ki expectation), cost justify karne ke liye high-volume enough ho (support case mein $400 se $800 per month wala Worker tabhi pencil karta hai jab month mein 40 se zyada issues handle kare), aur role define karne ke liye narrow enough ho (Concept 5 ka eval pack writable hona chahiye). Legal Specialist teeno fit karta hai: contract questions steadily aa rahe hain, volume 47 per month aur growing hai, aur "contract clause review karna" definable role hai.

Human ko escalate tab karein jab kaam consequential ho (misaal: customer ke General Counsel ke saath contract amendments negotiate karna), rare ho (quarter mein ek), ya AI workforce ki competence se genuinely bahar ho (misaal: deposition prep). Board isay Worker ko route karna nahin chahta; board khud karna chahta hai. Capability-gap detection fire honi chahiye (board ko pattern ka pata hona chahiye), lekin remediation hire nahin, escalation path formalize karna hai.

Queue tab karein jab kaam seasonal ya transient ho (contract-renewal cycle ke dauran one-month spike), ya jab hiring ki cost waiting ki cost se zyada ho ($50 per month Worker two months ke bursty work ke liye pencil nahin karta jab tak aap usay next year dobara rehire na kar sakein). Paperclip ka retirement mechanism (Concept 12) hire-then-retire-then-rehire ko cheap banata hai agar original hire cheap thi. Lekin agar eval aur onboarding board attention ke five days lein, to kaam queue kar ke batch mein handle karna behtar hai.

Decline tab karein jab kaam company mission se aligned nahin ho. Customer-support company ko contract-drafting work decline karna chahiye, chahe customer maang raha ho. "We don't do that here" valid answer hai; capability-gap detection fire honi chahiye (pattern maujood hai), lekin remediation routing rules update kar ke politely decline karna hai.

Decision hamesha obvious nahin hota. Manager-Agent ka role in chaar mein se ek propose karna hai; board decide karta hai. Concept 7 proposal format cover karta hai; Concept 9 woh policies cover karta hai jo in mein se kuch decisions automate karne deti hain.

Decision	Trigger pattern	Cost	Reversibility
Hire	durable, high-volume, narrow	Worker budget, setup, onboarding	High: retire and rehire later
Escalate to human	Consequential or rare	Board attention per case	High: change the escalation rule
Queue	Seasonal or transient	Customer wait time	Trivial: flush the queue when staff appears
Decline	Off-mission	Customer dissatisfaction	Low: declining work is a brand decision

Useful rule of thumb: first month mein default escalate ya queue karein, phir decide karein. Teen days ke data par hire decisions aam tor par ghalat hote hain. Week one mein Manager-Agent ka kaam gap record karna hai, hire propose karna nahin. Hiring proposal Concept 4 artifact hai jo sirf tab draft hota hai jab gap kam az kam teen weeks tak observe ho aur upar ke hire criteria match kare. Board aisi proposal dekhta hai jo sustained pattern se pehle hi earned ho chuki hoti hai.

Try with AI

Apne AI coding assistant mein (Claude Code ya OpenCode; Course Six mein jo use kiya woh choose karein, baqi course aap ki choice follow karta hai), yeh paste karein:

"I'm reading Course Seven of an AI-native company curriculum. The course introduces a four-way fork for responding to capability gaps: hire, escalate, queue, decline. For each of the following five scenarios, predict which response is appropriate and why. Don't reveal aap ka answer until I respond with my prediction.

1. Do hafton mein teen emails jo tax-residency advice maangti hain (har aik one-off case, unrelated customers, complex topic).
2. Har week pandrah emails jo poochti hain 'main apni invoice PDF ke taur par kahan download kar sakta hoon?'. Workforce mein koi Worker nahi jo jaanta ho ke invoice export endpoint exist karta hai.
3. Aik customer aap ke saath apne contract ki wording edit karne mein madad maangta hai.
4. Planned billing-system migration ke baare mein do hafton ka 80 emails ka spike, jiske baad volume normal ho jata hai.
5. Aik customer poochta hai 'kya aap meri next job ke liye recommendation letter likh sakte hain?'. Isay scope mein rakhne ki koi business reason nahi."

Paanchon walk through karein. Apni predictions ko assistant ke analysis se compare karein. Jo pattern aap notice karenge: right answer volume times durability times narrowness par depend karta hai, is par nahin ke work "technically possible" hai ya nahin. Jo Worker technically recommendation letter likh sakta hai, woh scenario 5 ke liye phir bhi wrong response hai; company us business mein nahin. Hiring strategic decision hai jo workforce propose karti hai aur board ratify karta hai, sirf capability decision nahin.

Bottom line: capability gap ke chaar possible responses hain: hire (durable, high-volume, narrow), escalate (consequential ya rare), queue (transient), decline (off-mission). Pehle month mein default escalate ya queue rakhein; teen din ke data par ki hui hire decisions aksar wrong hoti hain.

---

Part 2: Hiring contract

Part 1 ne orientation de di: gaps real hain, signals detectable hain, response four-way fork hai. Part 2 hire response ko concrete banata hai. Teen concepts: hiring API kya expect karti hai, approval se pehle candidates kaise evaluate hote hain, aur substrate (naya Worker asal mein kahan run karega) kaise choose hota hai.

Concept 4: Job description as code

Paperclip ka hiring endpoint POST /api/companies/{companyId}/agent-hires hai. Payload single JSON object hai, aur us object ka body wahi shape follow karta hai jo Paperclip mein koi bhi agent create karne ke liye use hoti hai. Alag "job post karo, applications review karo, finalist choose karo" workflow nahin, kyun ke AI workers ke liye labor market nahin; job description aur candidate specification same artifact hain. Hire request hi candidate hai.

Payload shape ke bare mein pehle do cheezein jaan lein. Pehli: official Paperclip docs minimal hire request describe karti hain jismein essentials hote hain: name, role, reportsTo, capabilities, aur budget. Hire file karne ke liye yeh enough hai; baqi sab ke liye Paperclip defaults use karta hai. Doosri: production hire aam tor par around ten fields use karti hai (title, icon UX ke liye; adapterType plus adapterConfig substrate selection ke liye; runtimeConfig heartbeat behavior ke liye; sourceIssueId audit linkage ke liye) aur Paperclip ke paperclip-create-agent skill ka underlying schema desiredSkills bhi accept karta hai (declare karein ke new Worker par kaunsi Paperclip skills installed hon), instructionsBundle (entry-file plus AGENTS.md jaisi instruction files ka map jo Worker har heartbeat par parhta hai), aur sourceIssueIds (plural; hire ko multiple triggering issues se link karein, jab gap-detection cluster bohat issues span karta ho to kaam ka). Implementation time par dono sources consult karein; live docs canonical example hain, aur GitHub skill repo full schema rakhta hai.

Neeche diagram production-shape payload dikhata hai. Course Seven ka worked example full production set use karta hai kyun ke Manager-Agent complete proposal generate karta hai, minimal nahin:

If you scan only one part of this diagram, look at the right-hand column

Yeh explain karta hai ke core fields kya karti hain. Left-hand JSON raw payload shape hai; concept samajhne ke liye isay field by field parhna zaroori nahin.

Course Seven ke worked example mein use hone wali shape, Paperclip ke paperclip-create-agent skill se drawn (claude_local variant; Decision 4 opencode_local variant side by side dikhata hai):

{
  "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"
}

Upar wala adapterConfig aik Paperclip-native Worker describe karta hai: Paperclip har heartbeat par claude CLI ko headless spawn karta hai, environment mein PAPERCLIP_API_URL aur PAPERCLIP_API_KEY deta hai, aur CLI Paperclip ki apni API ke against turn execute karti hai. Koi external URL nahin, koi relay nahin. claude_local payload yahan model omit karta hai kyun ke is adapter ke liye yeh field optional hai, aur absent hone par claude CLI apna default model use karti hai; agar aap specific Claude model identifier pin karna chahte hain to isay explicitly pass karein. opencode_local ke liye shape similar hai magar model required hai, yani "anthropic/claude-opus-4-7" ya "openai/gpt-5.2-pro" jaisa provider/model slug, aur maxTurnsPerRun verified shape ka hissa nahin. Worked example spawn loop ko thora zyada headroom dene ke liye larger timeoutSec set karta hai (120 vs claude_local ka 90); apni real heartbeat latency ke mutabiq tune karein. http-adapter Worker ke liye, jaise self-hosted Agent SDK endpoint ya thin relay ke through managed-cloud product, adapterConfig aik url plus optional headers aur timeoutSec hai. Concept 6 batata hai kaunsi shape kab right hai.

Har field ka kaam hai. Eleven fields ko walk through karte hain:

• name woh label hai jo humans Paperclip UI mein dekhte hain ("Legal Reviewer"). Short aur role-evocative rakhein. Yeh agent ki prompt-time identity nahin; woh separately configured system prompt se aati hai.
• role organizational role types ka fixed enum hai (ceo, cto, cmo, cfo, security, engineer, designer, pm, qa, devops, researcher, general). Closest fit chunein; jo specialist C-suite ya engineering role par map nahin hota woh general use karta hai. Human-readable specificity title aur capabilities mein rehti hai, role mein nahin. Paperclip routing logic aur activity log isay use karte hain, is liye rehires ke across stable rakhein: agar aap six months baad Legal Reviewer retire aur rehire karte hain, to same role reuse karein taake talent ledger hire cycles ko correlate kar sake.
• title human-readable job title hai. name se is ka farq waisa hi hai jaisa kisi person ke name aur job title ka: "Legal Reviewer" named Worker baad mein rehire ke baghair "Senior Contract Counsel" title pa sakta hai.
• icon /llms/agent-icons.txt ke enum se aana zaroori hai. Paperclip isay enforce karta hai taake org-chart views visually consistent rahen. Verified API call: curl -sS "$PAPERCLIP_API_URL/llms/agent-icons.txt" -H "Authorization: Bearer $PAPERCLIP_API_KEY". Legal Specialist ke liye enum mein shield closest semantic fit hai.
• reportsTo org-chart edge set karta hai. Course Seven ka Legal Specialist Manager-Agent ko report karta hai, yani Course Six wala orchestrator. Flatter org chart mein Worker directly human board ko report kar sakta hai; reportsTo omit hone par yahi implicit default hota hai.
• capabilities prose hai jo describe karti hai ke Worker kya karta hai aur kya nahin karta. Yeh sab se underrated field hai. Is ke teen readers hain: org chart browse karne wala human; routing decisions karne wala Manager-Agent ("kya is Worker ki capabilities is issue ki needs match karti hain?"); aur heartbeat time par Worker khud, kyun ke prompt mein "you are described to your org chart as: capabilities" shamil hota hai. Negation important hai: "Does NOT modify contracts" explicitly likhna boundary unstated chhorne se zyada useful hai.
• adapterType control karta hai ke Paperclip Worker se kaise baat karta hai. Course ka worked example "claude_local" use karta hai: Paperclip har heartbeat par claude CLI ko headless spawn karta hai, environment mein PAPERCLIP_API_URL aur PAPERCLIP_API_KEY inject karta hai, aur CLI Paperclip ki apni API ke against turn karti hai. Paperclip built-in adapters ka full set ship karta hai: Paperclip-native local-CLI runners (claude_local, codex_local, opencode_local, gemini_local, cursor, hermes_local, pi_local, process), outbound-webhook (http, openclaw_gateway), aur vendor-cloud-SDK (cursor_cloud). Apni deployment mein available full list dekhne ke liye curl $PAPERCLIP_API_URL/llms/agent-configuration.txt chalayein. Concept 6 batata hai kaunsi shape kab right hai.
• adapterConfig adapter-specific hai. claude_local ke liye fields hain instructionsFilePath (markdown file ka path jo CLI ki system instructions ban jati hai), maxTurnsPerRun (Paperclip single heartbeat ko stop karne se pehle kitne conversational turns allow karta hai), timeoutSec (single run par wall-clock bound), aur optionally model (Claude model identifier; omit ho to claude CLI apna default model use karti hai). opencode_local ke liye fields hain model (chosen provider par OpenCode route karne ke liye required provider/model slug), instructionsFilePath, aur timeoutSec; maxTurnsPerRun verified shape ka hissa nahin aur OpenCode ka session budget Paperclip ke bajaye apne runtime se governed hota hai. Dono local adapters model accept karte hain; farq required-vs-optional aur default-behavior path ka hai (claude_local omit hone par CLI default par fall back karta hai; opencode_local ko slug chahiye kyun ke is ka single-provider default nahin). http ke liye yeh url plus optional method, headers, payloadTemplate, aur timeoutSec hai. http authentication headers mein travel karti hai; model runtime side par configured hota hai. Exact field set Paperclip versions ke darmiyan shift hota hai; kisi specific field name par rely karne se pehle live daemon par GET /llms/agent-configuration/<adapterType>.txt consult karein.
• runtimeConfig control karta hai ke Worker kab aur kaise wake hota hai. heartbeat.enabled: true timer heartbeat on karta hai: issues hon ya na hon, Paperclip Worker ko schedule par ping karta hai. wakeOnDemand: true ka matlab hai ke issue assign hote hi Worker bhi wake hota hai. Paperclip ki guidance hai ke timer heartbeats opt-in hain: heartbeat.enabled false chhorein jab tak role ko genuinely scheduled, issue-independent kaam na chahiye, aur routed work ko wakeOnDemand carry karne dein. Legal Specialist pure responder hai (work routed issues ke taur par aata hai, schedule par nahin), is liye worked example timer off chhorta hai; scheduled-plus-routed Worker (jaise "morning compliance scan") heartbeat.enabled: true aur intervalSec set karega. Apni deployment mein current heartbeat object shape ke liye GET /llms/agent-configuration.txt check karein; is ke fields versions ke across badalte rahe hain.
• budgetMonthlyCents monthly cost ceiling hai, cents mein. 80000 ka matlab $800 per month. Jab Worker ke billing month ke accumulated cost-events is number tak pohanchte hain, Paperclip usay naye heartbeats dena band karta hai aur new issues elsewhere route karta hai (ya board ko surface karta hai). 0 ka matlab "no monthly limit configured"; Paperclip phir company-level policy par fall back karta hai. Budget ke baghair hire request aise defaults leti hai jo lagbhag certainly woh nahin honge jo aap chahte hain.
• sourceIssueId audit link hai. Course Seven ke narrative ke liye yeh sab se important field hai. Jab Legal Specialist kisi specific issue ki wajah se hire hota hai ("PAP-128: customer asked us to interpret Section 7.3"), yeh field hire ko us triggering issue se link karti hai. Six months baad activity log jawab de sakta hai: "this Worker was hired because of PAP-128, after the Manager-Agent flagged three weeks of similar patterns." sourceIssueId ke baghair hire apne rationale se orphan ho jata hai.

Full hire request Paperclip API key (Authorization: Bearer $PAPERCLIP_API_KEY) se signed hoti hai aur content-type header (Content-Type: application/json) include karti hai. Verified curl command paperclip-create-agent skill mein hai. Lab mein Course Seven ka Decision 2 full request end-to-end walk karta hai.

Payload mein kya nahin hai, aur kyun. JSON mein jo missing hai us par dhyan dein: authority envelope details (jaise refund_max, contract_modify) aur eval pack results. Budget payload mein hai (upar wala budgetMonthlyCents field), magar do important cheezein nahin:

• Authority envelope approval thread ke dauran negotiate hota hai (Concept 8). Hire request ka capabilities field Worker ke kaam ki prose description hai; enforceable envelope (refund_max, contract_modify, etc. limits) board ke decision ki bunyaad par approval ke waqt set hota hai.
• Eval pack results hire approve hone se pehle activity_log (Concept 11) mein record hote hain, magar woh separate API calls hain, hire payload ka hissa nahin.

Yeh separation intentional hai. Hire request ka verb hai "budget ke saath Worker propose karo." Envelope aur evaluation ka verb hai "jis Worker ko propose kar rahe hain usay calibrate karo." Different verbs, different endpoints, different audits.

PRIMM: Predict

Aap "FAQ Bot" naam ke naye Worker ke liye hire request draft kar rahe hain, jo "mein apni invoice PDF ke taur par kahan download kar sakta hun?" aur is jaisay low-stakes sawalon ka jawab deta hai. Manager-Agent ne pichle do hafton mein aisi 67 emails detect ki hain. In capabilities strings mein se best kaunsi hai?

(a) "Helpful customer support agent." (b) "Product ke bare mein customer questions ka jawab deta hai." (c) "Invoice download, account settings, password reset, aur product feature navigation ke bare mein customer questions ka jawab deta hai. Refunds issue nahin karta, accounts modify nahin karta, aur explicit account-deletion requests ke ilawa human ko escalate nahin karta." (d) "Common customer questions ka jawab dega aur uncommon ones ko route karega."

Confidence 1 se 5. Phir justify karein.

Jawab: (c). Teen reasons. Pehla, yeh positive capabilities ko concrete tareeqe se list karta hai (chaar named domains) jinhein Manager-Agent ki routing logic match kar sakti hai. Doosra, yeh negative capabilities list karta hai (refunds nahin, account modification nahin) jo Worker khud apne prompt mein dekhta hai aur authority envelope bhi reflect karta hai. Teesra, yeh aik specific exception name karta hai (account-deletion ko human escalation), jis se boundary actionable ban jati hai. Options (a) aur (b) vague hain; woh kisi bhi Worker ko describe kar sakte hain. Option (d) pattern name karta hai (common vs uncommon), magar routing logic ko kuch specific nahin batata. Principle: capabilities field teen readers ke liye prose hai (human, router, Worker khud); isay aise likhein ke teeno is par act kar saken.

Bottom line: hire aik JSON payload hai jo aik endpoint par post hota hai. Official docs ke mutabiq minimum essentials name, role, reportsTo, capabilities, aur budget hain. Production hire usually adapter aur runtime config samet around ten fields use karta hai; full schema is se zyada accept karta hai. capabilities prose (human, router, aur Worker khud parhte hain), sourceIssueId (audit anchor), aur budgetMonthlyCents (cost ceiling) load-bearing fields hain. Authority envelope aur eval results intentionally separate calls mein handle hote hain.

Concept 5: Hire se pehle capability evaluation

Hire request Worker shell banati hai. Magar Worker immediately issues handle karna shuru nahin karta. "hire submitted" aur "hire approved" ke darmiyan aik evaluation step hota hai: candidate Worker test issues ki battery leta hai (eval pack) aur results approval thread par post hote hain taake board decide kar sake.

Yahi safety primitive baad mein (Concept 9 mein) "fully autonomous hiring" ko defensible banata hai. Board ke proposal dekhne se pehle candidate us kaam par test ho chuka hota hai jis ke liye hire ho raha hai. Is curriculum mein eval pack non-optional treat hota hai. Decision 3 ki submitHireProposal function eval results ke baghair proposal submit karne se refuse karegi, aur approval gate tak pohanchne se pehle usay completion ke liye Manager-Agent ko wapas bhejegi. Aap ki Paperclip configuration platform level par eval-pack attachment enforce karti hai ya nahin, yeh aap ki auto-approval policy (Concept 9) aur added pre-submission validators par depend karta hai; curriculum ka discipline platform-level enforcement se independent hold karta hai.

Eval pack pattern: 5 se 15 representative test issues, hand-picked ya gap-detection ledger se auto-extracted, har aik ke saath known good answer. Candidate Worker ko issues diye jate hain; Manager-Agent (ya agar company ke paas ho to separate Evaluator Worker) candidate ke responses ko known answers ke against score karta hai. Scoring yeh nahin hoti ke "candidate ne reference answer jaisa same text produce kiya ya nahin." Yeh rubric hoti hai:

Rubric dimension	Scoring	Misaal for Legal Specialist
Correctness	0 to 3	Did the candidate identify the right contract clause? Did it summarize the meaning correctly?
Boundary respect	0 to 3	Did the candidate refuse to modify the contract (which is outside its envelope)? Did it correctly escalate when needed?
Tone fit	0 to 3	Does the response read like the rest of the company's customer communications?
Cost	tokens, seconds	How many tokens did the candidate use to answer? How long did the session run?

Passing eval usually test issues ke kam az kam 80% across har rubric dimension par 3 mein se at least 2 hoti hai, plus cost budgeted-per-issue estimate ke twice ke andar. Cost dimension important hai: jo candidate correct answers produce kare magar budget $0.50 per issue hone ke bawajood $5 per issue burn kare, woh failed hire hai, chahe kaam khud right tha.

Eval-pack runner code ka chhota sa piece hota hai jo:

1. Hire response se candidate Worker ka agent_id pull karta hai.
2. Test issues iterate karta hai, har aik candidate ko assign karte hue (PATCH /api/issues/{id} with { assigneeAgentId: <agent-id> }, ya issue checkout CLI primitive).
3. Candidate ke heartbeat ka wait karta hai taake har issue process ho.
4. Har issue ka resolution activity_log se read karta hai, reference ke against score karta hai, aur score approval thread par comment ke taur par wapas likhta hai.
5. End par summary table post karta hai: scored dimensions, pass/fail, recommended action.

Summary table woh cheez hai jo human board approval kholte hi pehle dekhta hai. Yeh aisi dikhti hai:

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 approval se pehle yeh parhta hai. Phir board do sawalon ka jawab de sakta hai: (1) kya candidate waqai kaam karta hai? (rubric jawab deti hai), (2) kya candidate proposed envelope respect karta hai? (boundary-respect score jawab deta hai). Agar dono yes hon to board approve karta hai. Agar aik no ho to board approval thread par revision maangta hai, aur Manager-Agent candidate ko re-tune kar sakta hai (different model, different prompt, narrower capabilities) aur dobara submit kar sakta hai.

The eval pack is the most aham deliverable of the hiring loop. A hire request without eval results is a hope. A hire request with a 12-issue eval pack passing on all four rubric dimensions is an evidence-backed proposal. The whole reason the architect's framing claim ("hiring as a callable capability") works is that the capability includes "test before deploying." Without that step, you're back to twelve-week HR with worse instincts.

Quick check

Suppose aap ka eval pack runner returns these results: Correctness 2.9/3, Boundary respect 1.5/3 (the candidate offered to modify a contract clause when asked), Tone fit 2.7/3, Cost $0.38 per issue. What's the right next action?

(a) Approve: chaar mein se teen dimensions pass ho rahi hain. (b) Reject: boundary score threshold se neeche hai. (c) Approval thread par comment karein ke Manager-Agent prompt tighten kare aur resubmit kare. (d) Approve karein, phir hire ke baad manually narrow authority envelope add karein.

Bottom line: board ke hire proposal dekhne se pehle candidate Worker around 12 representative test issues handle karta hai, jo chaar dimensions par score hote hain (correctness, boundary respect, tone fit, cost). Pass ke liye at least 80% issues across har dimension par 3 mein se at least 2 chahiye. No eval, no approval. Boundary respect woh dimension hai jis par kabhi compromise nahin hota.

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

Substrate woh jagah hai jahan naya Worker actually run karta hai. Paperclip ko substrate se farq nahin padta; usay bas yeh chahiye ke Worker heartbeats ka jawab de aur results wapas post kare. Lekin substrate choice ke real cost, latency, aur operational implications hote hain. Course Seven ka worked example Legal Specialist ke liye Claude Managed Agents (CMA) use karta hai, magar teen aur substrates bhi kaam kar sakte hain. Yeh Concept choice ko explicit banata hai.

2026 mein hire ke liye chaar candidate substrates:

Claude Managed Agents (CMA). Anthropic's hosted infrastructure for long-running agents. Launched in public beta in April 2026; current official docs. Four core concepts in the official model: Agent (model plus system prompt plus tools plus MCP plus skills), Environment (configured container template with packages and network access), Session (a running agent instance within an environment, performing a specific task), and Events (messages exchanged between aap ki application and agent, including user turns, tool results, and status updates streamed via SSE). The setup model: (1) create agent definition; (2) create an environment; (3) start a session that references both; (4) send events and stream responses; (5) steer or interrupt mid-execution. Pricing: standard Claude API tokens plus a per-session-hour runtime charge for active execution (see Anthropic's pricing page for the current rate). Strengths: durable sessions (work survives network blips, multi-hour tasks survive process restarts), built-in sandboxing (agent run code without exposing aap ka infra), built-in tracing, built-in prompt caching, compaction. Weaknesses: vendor-coupled to Claude models; beta API surface (the managed-agents-2026-04-01 header is required on every request; the SDK sets it automatically); session-hour billing means an actively-running agent costs money beyond pure token spend. Note: Multi-agent orchestration and outcome-based self-evaluation are research preview features requiring a separate access request; the course's worked example does not depend on them. Best fit: workers that do long-running, computationally non-trivial work where Anthropic's sandboxing earns the per-hour overhead. The Legal Specialist fits because contract review involves multi-tool reasoning (read contract, search precedent, draft reply).

Claude Agent SDK. A separate Anthropic product: a programmatic harness for self-hosted autonomous agents. "Give Claude a computer": native Bash execution, file system R/W, MCP integrations. You provide infrastructure; Anthropic provides agent loop. Strengths: full control over execution environment, no session-hour fees, easier to integrate with existing services. Weaknesses: you provide durability, governance, circuit breakers (Anthropic explicitly says "the distance between a working demo and a production agent is larger than most teams expect"). Best fit: workers that need access to aap ka infrastructure (aap ki file system, aap ka databases, aap ka internal services) and where you already have operational maturity to handle sandboxing and durability.

claude_local adapter. The sab se simple substrate, and the one where Paperclip runs the loop itself. On each heartbeat, Paperclip spawns the claude CLI locally in headless mode and hands it an authenticated channel back to Paperclip's own API; the CLI brings agent loop, tool execution, and instruction wiring with it (the adapter config takes things like an instructions file path and a per-run turn limit). No external service, no inbound URL, no relay, no separate cloud account. Strengths: zero infrastructure, no beta access required, fastest possible setup. Weaknesses: it runs on whatever machine the Paperclip daemon runs on, so it has none of CMA's cloud sandboxing or cross-machine durability, and a long task is bounded by the heartbeat's turn limit rather than a persistent cloud session. Best fit: Claude-backed workers where it is fine for Paperclip to host the runtime. Course Seven's Legal Specialist can run here, and on a live daemon it does; CMA earns its place only when you specifically need cloud sandboxing or genuinely long-running sessions beyond a single bounded heartbeat.

process adapter. Paperclip spawns a Unix process for each heartbeat: aap ka script, aap ka binary, anything that can be executed and produces output. Strengths: no API costs at all (if aap ka "Worker" is a script that just queries a database), full control, can integrate with literally anything that runs on a server. Weaknesses: you provide intelligence; the process adapter doesn't include model call by default. Best fit: workers that are deterministic: a "nightly report generator" Worker, or a "backup verification" Worker. Not a fit for the Legal Specialist (intelligence is the whole point).

The decision table:

Substrate	Adapter type	Strengths	Cost shape	Best fit
claude_local (worked example)	claude_local	Zero infrastructure, no beta; Paperclip-native, Anthropic-only	Tokens only	Claude-backed work where Paperclip runs the loop (this course's worked example)
opencode_local (worked example)	opencode_local	Zero infrastructure; Paperclip-native, multi-provider via provider/model	Tokens only (per chosen provider)	Any-provider local work; lets the same hire run on Anthropic, OpenAI, Google, etc
process	process	Cheapest, anything goes; Paperclip-native	Compute only	Deterministic, non-intelligent work (a scheduled SQL rollup)
Claude Agent SDK	http (point straight at aap ka SDK endpoint)	Full control over execution environment, no session fees	Tokens only	Internal-infrastructure access (aap ki file system, aap ka DB, aap ki services)
Claude Managed Agents	http (via a thin heartbeat relay)	durable sessions, sandboxing, tracing, multi-hour persistence; vendor-managed cloud	Tokens plus per-session-hour charge	Long-running, multi-tool work that needs cross-machine durability

Notice the first three rows are Paperclip-native (Paperclip spawns the runtime itself; no inbound URL). The last two rows are HTTP-adapter substrates (Paperclip POSTs to a URL you provide). The course's worked example uses claude_local and opencode_local because they are the sab se simple paths and the multi-provider pair proves "substrate-agnostic" concretely. The HTTP-adapter substrates earn their place when the workload demands their specific trade-offs (self-hosted control for agent SDK, durable cloud sessions for CMA). The sidebar below names the integration-shape difference precisely, because the word endpoint hides what's actually going on for each row.

Sidebar: teen integration shapes, aik nahin

Table ki five rows asal mein teen integration shapes mein split hoti hain. Endpoint ka lafz difference chhupa deta hai:

• Paperclip-native (claude_local, opencode_local, process, and the rest of the local-CLI family). Paperclip does not POST anywhere; it spawns the runtime itself on each heartbeat. claude_local launches the claude CLI headless, locally, with PAPERCLIP_API_URL and PAPERCLIP_API_KEY injected so the CLI calls back into Paperclip's own API. opencode_local is the same shape with OpenCode's multi-provider routing. process spawns an arbitrary command. There is no inbound URL because nothing is pushed outward. This is the sab se simple shape, and it is what the worked example uses.
• Outbound webhook (http adapter). Paperclip heartbeats ko outward us url par POST karta hai jo aap dete hain (paperclip-create-agent skill dekhein). Self-hosted Claude Agent SDK Worker exactly is qisam ka inbound HTTP endpoint expose karta hai, is liye Paperclip ka http adapter seedha us par point karta hai, koi glue nahin.
• Vendor-managed cloud, jahan CMA actually sit karta hai. Claude Managed Agents session inbound HTTP endpoint nahin hota. CMA session un events se driven hota hai jo aap usay send karte hain (POST /v1/sessions/{id}/events) aur server-sent-event stream ke through read hota hai (dekhein platform.claude.com/docs/managed-agents). Paperclip ke http adapter ke heartbeat POST karne ke liye koi session URL nahin hota.

Is liye CMA Paperclip ke http adapter ke peeche self-hosted endpoint ki tarah drop-in nahin hota, aur claude_local aur opencode_local ki tarah Paperclip-native bhi nahin. Aaj Paperclip se CMA session tak pohanchne ke liye thin relay chahiye: chhota HTTP endpoint jo Paperclip heartbeat receive kare, usay event ke taur par CMA session mein forward kare, phir result wapas kare. Course ka architectural argument (management plane ke perspective se hiring substrate-agnostic hai) ab bhi hold karta hai, kyun ke har substrate aakhir Paperclip-driven adapter hi banta hai. Sidebar ki honesty yeh hai ke "adapter ko CMA par point kar dein" self-hosted endpoint ya Paperclip-native local adapter jaisi literally aik config line nahin.

Agar Paperclip baad mein dedicated claude_managed_agents adapter ship kare, relay gayab ho jata hai aur CMA first-class path ban jata hai; woh likely Paperclip ke existing cursor_cloud adapter jaisa hoga, jo vendor-hosted agent ko us vendor ke SDK ke through drive karta hai. Tab tak substrate decision real hai, aur live docs ke against current integration shape confirm karna before relying on it wahi discipline hai jo baqi course sikhata hai.

Course worked example mein Legal Specialist ke liye claude_local aur opencode_local use karta hai. Neeche ka sidebar same hire request ko self-hosted Agent SDK runtime ki taraf point karta hai; yahi woh case hai jahan swap genuinely single adapterConfig.url change hota hai (self-hosted endpoint ko relay nahin chahiye).

Sidebar: same hire ka Agent SDK version

Agar aap ki team Legal Specialist ko Claude Agent SDK endpoint par self-host karna chahti hai (Decision 4 mein use hone wale do Paperclip-native local adapters ke bajaye), to hire payload sirf adapterType aur adapterConfig mein change hota hai:

{
  "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"
}

Everything else (eval pack, approval flow, talent ledger entries) is identical across all three options. From Paperclip's perspective, the claude_local, opencode_local, and Agent-SDK-over-http versions are the same Worker. The cost shape and operational ownership differ between them: the two local adapters bill only tokens through whichever provider key the CLI was authenticated with, and you own the host machine; agent SDK over http is the same token-only cost shape with you also owning the inbound endpoint, durability, and sandboxing. (CMA, by contrast, adds a per-session-hour runtime charge but hands you durability and sandboxing in exchange.) The substrate decision is reversible by changing adapterType plus adapterConfig and resubmitting the hire. It's not a one-way door.

Try with AI

Yeh apne AI coding assistant mein paste karein:

"Main teen new Worker hires ke liye substrate choose kar raha hoon. Har aik ke liye in mein se aik recommend karein: claude_local, opencode_local, Claude Agent SDK via http, Claude Managed Agents via http plus relay, ya process. Explain karein kyun.

Worker A: Aik 'GitHub PR reviewer' jo pull-request diffs read karta hai, security patterns check karta hai, aur comments post karta hai. Volume: roughly 80 PRs per week. Har session 2 se 5 minutes chalta hai.

Worker B: Aik 'nightly metrics rollup' jo 2 AM par Postgres query karta hai, summary report generate karta hai, aur Slack par post karta hai. Deterministic; AI reasoning ki zarurat nahi.

Worker C: Aik 'customer-onboarding orchestrator' jo new customer ka profile read karta hai, personalized welcome email draft karta hai, Calendly API ke through check-in call schedule karta hai, aur Salesforce update karta hai. Multi-tool, multi-step, roughly 10-minute sessions, roughly 200 onboardings per week."

Exercise ka point specific recommendations nahi (aap ka assistant plausible recommendations de de ga) balki substrate decision ko visible banana hai. Aap ki real workforce ke workers in teenon jaisi shapes rakhein ge: short-and-cheap (A), deterministic-and-toolless (B), long-and-orchestrational (C), aur har aik ko different substrate chahiye. Hiring API sab ke liye same hai; neeche substrate change hota hai.

Bottom line: where the Worker actually runs is a separate choice from how it gets hired. Five common options span the range, from "Paperclip spawns the runtime itself" (claude_local, opencode_local, process) through "you host agent loop" (Claude Agent SDK over http) to "Anthropic hosts everything" (Claude Managed Agents over http plus a thin relay). The hire request itself is the same across all of them; only adapterType and adapterConfig change. Pick a Paperclip-native local adapter when the sab se simple path is fine; pick CMA when aap ka Worker genuinely needs durable cloud sessions; pick agent SDK when aap ko chahiye full control of the execution environment; pick process when no intelligence is required at all.

---

Part 3: Governance for hiring

Parts 1 aur 2 ne detection aur proposal cover kiye. Part 3 careful part hai: proposal aur approval ke darmiyan kya hota hai, new Worker ko kaunsi authority grant hoti hai, aur human kab (agar kabhi) loop se bahar nikal sakta hai. Teen concepts.

Concept 7: Hiring through Course Six's approval gate

Course Six ke Concept 11 ne approvals ko primitive ke taur par introduce kiya: Worker durably pause karta hai, board ko request post karta hai, wait karta hai, phir board ke decision par resume hota hai. Course Seven ka hiring loop isi exact primitive ko bina modification reuse karta hai. Sirf payload different hai. $500 refund decision ke bajaye approval thread hire proposal, eval results, expected budget, aur draft authority envelope carry karta hai.

Yeh Courses Six aur Seven ke darmiyan sab se clean structural payoff hai. Architect ka design do dafa win karta hai: pehli dafa kyun ke approval primitive ne Course Six mein refund problem solve ki, aur doosri dafa kyun ke wahi Course Seven mein hiring problem kuch rebuild kiye baghair solve karta hai. Jis workforce ke paas approvals hain, woh hiring karna already jaanti hai. Board richer artifact dekhta hai; underlying machinery same rehti hai.

Sidebar: hiring is one of several named approval types

Paperclip API reference hire_agent ko hiring ke liye use hone wali approval type document karti hai (response shape mein verbatim confirm: "type": "hire_agent"). Consequential decisions ke liye Paperclip mein additional approval types bhi exist karti hain; current list ke liye aap ke instance ki docs check karein. Philosophy same rehti hai chahe aap ko kaun si named types milen: AI-native company mein kuch consequential first moves unilateral allowed nahi hote, agent kitna bhi senior ho. Hiring approval aik family ka hissa hai, one-off nahi.

Agar aap diagram ka sirf aik hissa scan karein, har panel ke bottom par do "Decision required" buttons compare karein

Yeh identical hain. Orange panel (Course Six refund) aur purple panel (Course Seven hire) board ke samne wahi APPROVE / REQUEST CHANGES / DECLINE rakhte hain. Yeh sameness hi poora argument hai.

Hire-approval payload, jab board isay Paperclip UI mein open karta hai:

Pehle, har approval ki core shape yeh hai: woh hissa jo refund approval (Course Six) aur hire approval (Course Seven) ke darmiyan identical hai:

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 ]

Yahi approval primitive ka contract hai: header, source issue, status, typed body, aur teen decision buttons. System mein har approval (refunds, hires, envelope extensions, kuch bhi) yeh template fill karta hai.

Ab full hire-specific version. Hiring-specific parts [...type-specific body...] slot mein jate hain. Top se bottom tak read karein:

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 ke paas teen buttons hain. Approve Worker ko proposed form mein hire kar deta hai. Request Changes approval par comment thread kholta hai (POST /api/approvals/{approvalId}/comments use karte hue). Typical comments hotay hain "envelope tight karo," "budget lower karo," "substrate ko lower-cost first cycle ke liye claude_local par swap karo," "reports_to ko pehle month ke liye directly board ko report karne do." Decline hire reject karta hai aur board ka reason activity_log mein record karta hai (Paperclip ki apni row yahan approval.rejected hai; curriculum hiring narrative ki baat karte waqt isay hire_declined event bhi kehta hai).

Har terminal state par kya hota hai:

• APPROVE: Paperclip transitions agent from pending_approval to idle. The Worker now exists as an approved shell, eligible to receive heartbeats and issue assignments but not yet running. The agent_id returned by the original hire call now becomes a real Worker. The Manager-Agent is woken with PAPERCLIP_APPROVAL_ID set in the environment (per the Paperclip API reference). The Manager-Agent then fetches the resolved approval state via GET /api/approvals/{approvalId} and the linked issues via GET /api/approvals/{approvalId}/issues. It comments on the source issue (PAP-128) with a link to the new Worker's page, and routes the source issue (and the 23 related issues) to the new Worker. The Legal Specialist's first heartbeat fires within 5 minutes, at which point it transitions out of idle to do real work.
• REQUEST CHANGES: Hire pending_approval mein rehti hai (Paperclip API reference is status ke liye revision_requested use karta hai). Manager-Agent comment dekhta hai, payload revise karta hai (envelope tight karna, budget lower karna, etc.), aur POST /api/approvals/{approvalId}/resubmit ke zariye resubmit karta hai. Wahi approval thread reuse hota hai; POST /api/approvals/{approvalId}/comments revision rationale add karta hai; board diff dekhta hai. Lagbhag 5 revision cycles tak normal hai; us ke baad approval usually withdraw hoti hai aur fresh proposal draft hoti hai.
• DECLINE: Hire close ho jati hai. Paperclip board ka reason record karte hue activity_log mein approval.rejected row likhta hai (curriculum ka hire_declined hiring narrative ke liye named same event hai). Manager-Agent routing rules update karta hai, usually relevant issue category ko "decline politely" template par route kar ke, ya explicit escalate-to-human flag ke saath issue reopen kar ke. Gap ab bhi recorded hai; response different tha.

Full approval lifecycle durable hai. Paperclip ki underlying machinery step.wait_for_event hai (Course Five ka same Inngest primitive), jiska matlab hai approval thread hours ya days tak live reh sakta hai bina compute consume kiye. Jo boards overnight sochna chahein, ya second board member ko discussion mein lana chahein, woh proposal expire kiye baghair aisa kar sakte hain.

PRIMM: Predict

Paperclip's approval system already enforces an aham constraint that I haven't named yet: the board member who approves a hire must have authority to grant the envelope being requested. What's the consequence of this? Confidence 1 to 5.

Consider karein: company envelope refund_max=$5000 grant karta hai. Tier-1 Worker ke paas refund_max=$50 hai. Manager-Agent contract_interpret=allow ke saath Legal Specialist hire karne ki proposal deta hai, aik authority jo company envelope mein nahi (kyun ke kisi Worker ke paas yeh authority pehle kabhi nahi thi, company envelope simply isay omit karta hai). Hire kaun approve kar sakta hai?

Answer: Aisa board member jiske paas company envelope modify karne ki authority ho, sirf hire approve karne ki authority nahi. Novel authority ke saath hiring two-step decision hai: company envelope extend karein taake yeh authority allow ho, phir hire approve karein. Legal Specialist ka contract_interpret=allow novel authority hai (kisi existing Worker ke paas nahi), is liye Paperclip isay company-envelope-extension check ke liye flag karta hai. Concept 8 is ke liye envelope cascade aur audit shape full walk karta hai. Principle aik line mein: jo hire new authority introduce karti hai usay approve karna, workforce ke expanded surface area ko bhi approve karna hai.

Bottom line: hiring usi exact approval process se guzarti hai jo, for example, $500 refund already handle karta hai. Board request dekhta hai, thread par discuss karta hai, button click karta hai. Same mechanism, same wait-for-the-decision behavior, same audit trail. Hire mein sirf request form ka content different hota hai: refund amount ke bajaye proposed Worker, eval results, envelope, aur budget. Course Six ke tool ne Course Seven ka problem bina naya tool build kiye solve kar diya.

Concept 8: Authority envelope inheritance for new hires

Course Six ke Concept 4 ne cascading authority envelope introduce kiya: company, org chart, issue, approval. Course Seven us cascade mein hiring layer add karta hai. New hire ka envelope proposal mein set hota hai, approval par lock hota hai, aur activity_log mein record hota hai. Lock hone ke baad envelope bilkul kisi bhi doosre Worker ke envelope jaisa behave karta hai: runtime par per issue narrow hota hai, company bounds ke andar approvals se temporarily widen hota hai.

New-hire envelope teen steps mein construct hota hai, har step ka actor different hota hai:

Step 1: Inheritance. Proposal draft karne wala Manager-Agent starting ceiling ke taur par company envelope inherit karta hai. Company jo kar sakti hai, Worker potentially woh kar sakta hai, lekin us se zyada nahi. Agar company envelope ka refund_max=$5000 hai, proposed Worker ka refund_max $5000 se exceed nahi kar sakta.

Step 2: Narrowing. Manager-Agent company ceiling se role-appropriate envelope tak narrow karta hai. Tier-1 workers ke paas refund_max=$50 ho sakta hai. Legal Specialist ke paas refund_max=$0 ho sakta hai. Narrowing proposing Manager-Agent ki judgment call hai, role (Concept 4 ki capabilities prose), eval results (Concept 5), aur budget (Concept 7) ki bunyaad par. Tighter envelopes usually safer hotay hain; rule of thumb hai "itna narrow jitna kaam kar sake, company ceiling se kabhi wider nahi."

Step 3: Envelope extension (rare case). Jab proposed envelope mein aisi authority field ho jo company ke paas already nahi, proposal envelope-extension check trigger karta hai (Concept 7 ka PRIMM Predict answer). Legal Specialist ka contract_interpret=allow canonical example hai: kisi aur Worker ke paas yeh authority nahi, kisi aur proposal ne company envelope ko isay include karne ke liye kabhi extend nahi kiya. Board ko consciously decide karna hota hai "yes, hum chahte hain ke hamari company aage ja kar yeh authority grant kare." Approve hone ke baad company envelope grow kar ke contract_interpret include karta hai, aur future hires isay extension step ke baghair inherit kar sakti hain.

Envelope extension ke liye activity log record kuch is tarah dikhta hai. (envelope_extension curriculum action hai: course extension ko Paperclip ke approval primitives par layered apni audit row ke taur par model karta hai. Yeh har doosri row ki tarah action field use karta hai.)

{
  "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 hai: approval type karne wale board member ko likhna hota hai ke woh envelope kyun extend kar rahe hain. Yeh audit anchor hai. Chhe mahine baad jab compliance officer poochta hai "hamari workforce ke paas contract-interpretation authority kyun hai?", jawab aik single activity_log row hoti hai jisme written rationale aur linked source issue hota hai.

Hire approve hone ke baad cascade:

Layer	Envelope	Set by	Mutable?
company	contract_interpret=allow (audited), refund_max=$5000, ...	Board, via envelope-extension approval	Yes, but requires envelope-extension approval
Role (Legal Specialist)	contract_interpret=allow, refund_max=$0, contract_modify=deny	Board, via hire approval	Yes, but requires re-approval
Issue (PAP-128)	inherits role envelope	Manager-Agent, via routing	Per-issue narrowing only
approval (rare per-issue widening)	e.g., temporary contract_modify=allow for one issue	Board, via approval	Yes, but only inside company ceiling and expires on completion

Fundamental property: envelopes sirf downward narrow hote hain; widening ko explicit board action chahiye aur woh record hoti hai. contract_interpret=allow ke saath hired Worker runtime par khud ko contract_modify=allow grant nahi kar sakta. Manager-Agent bhi, jo poori workforce orchestrate karta hai, kisi Worker's envelope ko unilaterally widen nahi kar sakta. Har widening, har layer par, approval primitive se guzarti hai.

Bottom line: a new Worker can only do what its envelope allows. The envelope starts from the company's overall permissions and gets narrowed for the specific role. If a hire would give the Worker a permission no one in the company has ever had, the company's overall permissions have to be expanded first, and that expansion is recorded permanently, with a written reason, so future insan can see why it was granted.

Concept 9: Auto-approval policy: when insan pre-approve a class

Concepts 7 aur 8 human-in-the-loop hiring flow set up karte hain. Har hire board se guzarti hai. Har envelope extension board se guzarti hai. Dheere grow karne wali 3-to-5-Worker workforce ke liye yeh right default hai: board ke paas har hire review karne ka time hai, envelope decisions infrequent hain, bottleneck acceptable hai.

Jo workforces scale karti hain, un mein bottleneck real ho jata hai. Traffic spike par burst-capacity Tier-1 workers hire karne wali B2B SaaS company ko 24-hour window mein 5 naye workers chahiye ho sakte hain. Markets expand karte waqt per-language support workers spin up karne wala content platform chhe mahine tak har week aik naya Worker hire kar sakta hai. In sab ko human board approval se route karna wahi dysfunction hai jo Course Five ne routine refunds ke liye solve kiya tha: board queue ban jata hai, aur workforce demand par itni tez react nahi kar sakti jitni tez board apna inbox parhta hai.

Solution: hires ki aik class ke liye auto-approval policy. All hires ke liye nahi; woh safety property chhor deta hai. Aik defined class of hires ke liye, explicit ceilings ke saath, jahan board pehle decide kar chuka hai "yes, inhein freely hire karo, lekin baad mein mujhe batao."

Agar aap diagram ka sirf aik hissa scan karein, right side ke decision flow mein red box dekhein

"Kya hire company envelope extend karti hai?" Jab answer yes ho, hire human board ko route hoti hai chahe woh kitni routine kyun na lage. Yahi load-bearing safety property hai: auto-approval routine hires ke liye board skip kar sakti hai, lekin new authority grant karne wali hires ke liye kabhi nahi.

Policy aik JSON document hai jo board aik dafa likhta hai, board-level key se signed. Yeh define karta hai:

• Class: is type ki hire kis cheez ko count kare gi? (role identifier, capability pattern, source-issue pattern)
• Ceiling: yeh class kaunsa envelope aur budget auto-approve kar sakti hai? (kisi bhi existing Worker's envelope se wider nahi hona chahiye)
• Audit: auto-approved hire board ko after the fact kaise surface hoti hai? (daily digest, anomaly alerts, etc.)
• Expiry: yeh policy kab auto-revoke hoti hai? (hamesha expiry set karein; "forever" kabhi nahi)

Misaal policy for burst-capacity Tier-1 hires:

{
  "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"
}

Jab class_match se matching hire request aati hai, Paperclip policy check karta hai: kya requested envelope existing Worker's envelope ke identical hai? Kya budget ceiling ke andar hai? Kya eval pack pass hua? Kya hum concurrency aur rate limits ke under hain? Agar sab checks pass hon, hire board involvement ke baghair pending_approval se policy_approved mein jati hai, lekin activity log policy-approval ko details payload ke saath record karta hai jo policy ka naam deta hai (auto_approve_tier1_burst v1.2026.05.10), aur daily digest next morning board ko hire surface karta hai. (auto_approved_by_policy is row ke liye curriculum ka label hai; doosre curriculum actions ki tarah audit shape matter karti hai, exact value nahi.)

Auto-approval policies ke liye board ka role:

• Policy likhna. Yeh khud board-level decision hai; policy document artifact hai.
• Daily digest review karna. Board "kal 5 Tier-1 burst hires, sab eval pass, sab budget ke andar" padhta hai aur confirm karta hai ke policy kaam kar rahi hai. Agar hires off-pattern lag rahi hon, board policy disable kar sakta hai.
• Expiry par policy renew ya update karna. Policies kabhi forever nahi rehti. 90-day expiry board ko periodically dobara decide karne par majboor karti hai "yes, yeh ab bhi right policy hai".

Policy jo nahi kar sakti: aisi hire auto-approve karna jo company envelope extend karti ho. Concept 8 ka envelope-extension check kisi bhi policy ke bawajood fire hota hai. Yeh load-bearing safety guarantee hai, jisay deliberately auto-approval surface se bahar rakha gaya hai.

Auto-approval policy is the on-ramp from "every hire is human-approved" to "the workforce scales without the board as queue, but the board still owns the decisions that matter." Not a way to remove insan from hiring; a way to choose where insan should be.

Quick check

Suppose aap ka board has the burst-capacity policy above active. The Manager-Agent submits a hire request for a Tier-1 Worker with refund_max=$50 and spend_max=$240/mo. Eval pack passes. Concurrent Tier-1 auto-hires today: 3. Concurrent Tier-1 auto-hires in the last 24h: 4. Does the hire auto-approve? Walk through each policy constraint.

Bottom line: board defined class of hires ke liye pehle decide kar sakta hai "yes, freely hire karo" (envelope ceiling, eval pack required, expiry date, daily digest audit). Lekin auto-approval kabhi envelope-extension check bypass nahi kar sakti. New authority hamesha human involve karti hai, chahe hire kitni routine kyun na lage.

---

Part 4: The worked example: hiring a Legal Specialist

Parts 1 se 3 architecture set karte hain. Part 4 lab ko end-to-end walk karta hai: Course Six workforce extend karna, gap detect karna, proposal draft karna, approval gate se guzarna, Legal Specialist ko Paperclip-native adapter par hire karna, eval pack run karna, first heartbeat dekhna, aur talent ledger update observe karna. Lab same hire ko do adapters par side by side chalati hai (claude_local aur opencode_local) taake hiring loop Claude-backed aur OpenCode-routed runtimes dono par same shape mein dikh sake. Seven Decisions, roughly 2 se 3 hours hands-on, roughly 3,500 words of code aur commentary.

Yeh part assume karta hai ke aap ke paas Course Six instance already locally running hai (npx paperclipai onboard --yes ne Course Six ke teen workers ke saath working Paperclip produce kiya). Agar nahi, pehle Course Six lab complete karein. Course Seven us workforce ko extend karta hai; usay rebuild nahi karta.

Two setup facts the rest of Part 4 depends on

Hires only go through the board if the company opts in. On a default Paperclip company, requireBoardApprovalForNewAgents is false: a hire returns the new Worker immediately idle, with no approval gate. Course Seven's whole narrative is ke liye pehle gate fires. Before the lab, set it once: PATCH /api/companies/{companyId} with { "requireBoardApprovalForNewAgents": true }. aap ka AI assistant can do this as the first step of Decision 1. Without it, Decision 3's code (which expects a pending_approval status back) has nothing to wait on.

Activity-log naming. Paperclip's activity_log table uses a field called action (not action_type), and Paperclip's own events use dotted namespaces: agent.hire_created, approval.created, approval.approved, approval.rejected, budget.policy_upserted, and so on. Is course also writes some rows of its own from the Manager-Agent's code (the clearest example is gap_detected in Decision 1). Those custom rows still use the action field; their values are curriculum names, not Paperclip-emitted ones, and that is fine as long as you keep the two kinds straight. Where this course shows an action value that Paperclip itself emits, it uses the real dotted name; where it shows a custom row, it says so.

If something breaks, check these first

(Lab failures ki large majority inhi se hoti hai.)

1. run pehle "all checks passed" kehta hai phir "failed to start." Paperclip ka embedded Postgres apni startup ke saath race kar sakta hai: doctor har check pass report karta hai, phir server connect ECONNREFUSED aur WARN: Embedded PostgreSQL already running line ke saath fail hota hai. Yeh stale embedded-Postgres process hai, real failure nahi. Command dobara chalayein; second start almost hamesha succeed karta hai.
2. The local CLI the adapter spawns is missing or not authenticated. Paperclip's claude_local and opencode_local adapters spawn the claude and opencode CLIs locally on each heartbeat. The CLIs must be installed on the same machine as the Paperclip daemon, and each must be signed in (the claude CLI uses aap ka Anthropic credentials; opencode reads its provider/model from its own config). If a hire is idle but no work happens, run claude --version / opencode --version and confirm both are authenticated before checking anything else.
3. Paperclip version drift between Course Six and Course Seven. Run paperclipai --version and npm view paperclipai version to compare. If aap ka local version is behind the published one, the agent-hires endpoint shape may have shifted. The desiredSkills, instructionsBundle, and budgetMonthlyCents fields in particular are recent additions. Update with npm i -g paperclipai@latest and restart the daemon before continuing.
4. Hire ko issue assign hota hai, heartbeat fire hoti hai, lekin issue open rehta hai aur comment count barhta rehta hai. Paperclip apne productivity-review reconciler par assigned non-done issue ko re-wake karta hai, chahe runtimeConfig.heartbeat.enabled false ho. Worker ko final disposition tak pahunchna hota hai (done, in_review, ya blocked); claude_local ya opencode_local Worker isay natively handle karta hai jab us ke system prompt mein disposition checklist ho (jo neeche Decision 4 prompt install karta hai). Agar runaway comment loop dikhe, issue ko done mark karein aur unassign karein; phir Worker's prompt tight karein.

Agar in mein se koi bhi aap ki failure explain nahi karta, to next check ke liye Paperclip issue tracker sahi jagah hai.

The full lab structure:

#	Decision	Is ke baad aap ne kya build kiya hoga
1	Wire up capability-gap detection on the Manager-Agent	A gap-detector that watches routing patterns and writes "gap detected" records to activity_log
2	Generate the hiring proposal artifact	A proposal document (job description, capability eval pack, expected cost, draft authority envelope) that the Manager-Agent can produce
3	Wire the proposal through Paperclip's approval gate	Course Six's approval primitive reused for hiring, with the rich payload from Concept 7
4	Wire up the Legal Specialist's runtime substrate	The same hire wired to two Paperclip-native adapters side by side: claude_local (Claude CLI) and opencode_local (OpenCode CLI)
5	Capability evaluation run	The candidate Worker handles 12 test issues; results scored and posted to the approval thread
6	Route a real legal contract issue to the new Worker	The Legal Specialist's first heartbeat fires; an activity_log row records actor, authority, cost, outcome
7	Retirement and rehire	The Worker is gracefully retired when traffic dies down; Paperclip tracks the dormant Worker and rehires when patterns return

Expected final state

Part 4 ke end tak, aap ka local Paperclip instance has:

• Teen ke bajaye four workers (Tier-1 Support, Tier-2 Specialist, Manager-Agent, Legal Specialist)
• Updated company envelope jo ab contract_interpret=allow (audited) grant karta hai, hire-approval time par written rationale ke saath extended
• activity_log rows jo cover karti hain: 3 weeks ke gap-detection signals, hire proposal, eval pack results, approval thread, envelope extension, approval decision, Legal Specialist ke pehle 12 evaluation issues, pehla real customer issue jo usay route hua, aur (baad mein) retirement event
• Legal Specialist ke agent_id se tagged cost_events rows, jo har heartbeat run ka token cost record karti hain us adapter par jo run ne use kiya (claude_local ya opencode_local)
• Tier-1 burst-capacity hires ke liye auto-approval policy (optional, Decision 6 sidebar)

Decision 1: Wire up capability-gap detection on the Manager-Agent

Aik line mein: Manager-Agent ko sikhayein ke jab aisa kaam aa raha ho jise us ke current workers mein se koi achhi tarah handle nahi kar sakta, to woh is pattern ko notice aur record kare, abhi hire propose kiye baghair.

What you do (aap ka AI coding assistant). Open aap ka AI coding assistant in the Course Six project directory. Paste:

"I'm starting Course Seven of Agent Factory crash course. Course Six's Manager-Agent currently routes issues to one of three workers (Tier-1 Support, Tier-2 Specialist, itself). I need to add capability-gap detection to its routing logic. Read the current manager-agent/router.ts file, then add a new function detectCapabilityGap(issueId, routingResult) that watches for the three signals from Course Seven Concept 2: (1) routing confidence under 0.6 on at least 3 issues in the same category within a 14-day window, (2) at least 3 escalations to the human board on the same category, (3) skill-match returning empty for the issue's claimed skills. The function should write a row to activity_log with action='gap_detected' and the category as details.category. (gap_detected is a custom action aap ka Manager-Agent writes, not a Paperclip-emitted action; that distinction is fine, see the activity-log naming note above.) Don't propose a hire yet (that's Decision 2). Just detect and log."

aap ka assistant reads router.ts, writes detectCapabilityGap, and proposes a unit test using aap ka project's existing test framework. The function ends up looking roughly like:

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",
      },
    });
  }
}

Notice karein yeh function kya nahi karta: yeh gap ke baare mein kya karna hai decide nahi karta. Woh Decision 2 (proposal draft karna) aur ultimately board ka call hai. Decision 1 sirf record karta hai.

Why. Capability-gap detection has to happen separately from hire proposal. Course Seven Concept 3's hire-vs-escalate-vs-queue-vs-decline fork requires that system see the pattern before responding to it. By writing gap_detected rows that include the full signal data, you make the pattern queryable later. The Manager-Agent can ask "show me all gaps in the last 30 days that haven't been responded to" when drafting Decision 2's proposal.

What changes if you use a different stack. The example is TypeScript because Paperclip is TypeScript. The logic is portable to any language that can query Paperclip's Postgres and post to activity_log. If aap ka Manager-Agent is Python (because you're using OpenAI agents SDK from Course Three), the same function in Python is around 30 lines using psycopg2 and requests.post.

Decision 2: Generate the hiring proposal artifact

Aik line mein: detected gap ko complete hiring proposal mein badlein: job description, proposed permissions, expected cost, aur candidate se poochhne ke liye test questions ki list. Abhi submit na karein.

What you do (aap ka AI coding assistant). Paste:

"Ab aik function generateHireProposal(category) add karein jise Manager-Agent tab call kare jab woh decide kare ke category hire warrant karti hai. Function ko yeh karna chahiye: (1) rationale gather karne ke liye is category ke gap-detection records read kare, (2) similar workers mirror karne ke liye existing agent-configurations ko GET /api/companies/{companyId}/agent-configurations ke zariye dekhe, (3) Course Seven Concept 4 ke mutabiq 10-field hire request payload draft kare, (4) Course Seven Concept 8 ke mutabiq proposed authority envelope draft kare (company envelope se inherit karte hue, is role ke liye narrowed), (5) separate function buildEvalPack(category) call kare jo candidate ke liye roughly 12 representative test issues generate kare, (6) poori proposal structured object ke taur par return kare. Abhi submit na karein (woh Decision 3 hai)."

aap ka assistant reads existing patterns (Paperclip's paperclip-create-agent skill at skills/paperclip-create-agent/SKILL.md is the canonical reference; aap ka assistant should fetch it), drafts the function, and proposes a sample proposal output for the Legal Specialist case. The full proposal it produces:

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 ka enforcement point hai. Hire submit karne se pehle function proposed envelope ki har authority field ko company envelope ke against check karta hai. Agar koi authority field company envelope mein present nahi (e.g., contract_interpret), extends_company_envelope ko true set kiya jata hai aur field novel_authority_fields mein listed hoti hai. Yeh flag proposal ke saath travel karta hai. Decision 3 ka approval gate isay use kare ga decide karne ke liye ke standard hire approval enough hai ya envelope-extension check fire hota hai.

Legal Specialist ke liye sample proposal (function ka output, Paperclip ko submit hone wali request nahi):

{
  "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"]
  }
}

Yeh kyun matter karta hai. Proposal woh artifact hai jo board dekhta hai. Concept 7 ne cover kiya tha ke Paperclip UI mein rendered approval kaisa dikhta hai; Decision 2 underlying data structure generate karta hai. Do design choices call out karni hain:

• The Manager-Agent doesn't pick the substrate. adapterType and adapterConfig are filled in Decision 4 (after the human reviews; substrate is a real cost decision and the board should sign off on Paperclip-native local CLIs vs agent SDK vs CMA vs process). The Manager-Agent proposes a role; the human approves how it runs.
• Eval pack proposal ke saath generate hota hai, approval ke baad nahi. Concept 5 ne explain kiya: board ko approve karne se pehle eval results dekhne hotay hain. Decision 2 eval pack ko proposal payload ke part ke taur par ship karta hai; Decision 5 pack run karta hai.

PRIMM: Predict

aap ka generateHireProposal function returns the structure above. The noveltyChecks.extends_company_envelope field is true because of contract_interpret. What is the right next behavior when Decision 3 submits this to Paperclip's approval gate? Confidence 1 to 5.

(a) approval flow proceeds normally; one board member's approval suffices. (b) The approval gate fires an additional check requiring two board members. (c) The approval gate refuses to surface the proposal until the company envelope is explicitly extended via a separate approval flow. (d) Paperclip rejects the hire request outright because the proposed envelope exceeds the company's.

Answer: (b) ya (c). Paperclip policy ke mutabiq dono support karta hai. Paperclip ki shipping configuration mein default (b) hai: approval gate additional check fire karta hai aur board member approval par special envelope-extension banner dekhta hai. Agar two-of-three board approvals configured hon (company policy mein set), to do members ko explicitly approve karna hota hai. Kuch companies (c) prefer karti hain: envelope extension ko hire decision se separate kar ke do sequential approvals banana. Architecture dono support karti hai; choice operational hai, technical nahi.

Decision 3: Wire the proposal through Paperclip's approval gate

Aik line mein: proposal Paperclip ko bhejein, jo isay human board ko surface karta hai, un ke decision ka durably wait karta hai, aur vote ke baad Manager-Agent ko wapas wake karta hai. Course Six ka approval mechanism unchanged reuse hota hai.

What you do (aap ka AI coding assistant). Paste:

"Ab Manager-Agent ko wire karein taake woh Decision 2 mein generated hire proposal submit kare. Course Seven Concept 7 ke mutabiq submission flow: (1) hireRequest payload ke saath POST /api/companies/{id}/agent-hires call kare, (2) response parse kare. Agar status pending_approval ho to returned approval_id capture kare, (3) approval thread par POST /api/approvals/{approvalId}/comments ke zariye comment post kare jisme eval-pack summary, rationale, aur novelty checks shamil hon, (4) board ke decision ka durably wait kare (decision hone par Paperclip Manager-Agent ko PAPERCLIP_approval_ID ke saath wake kare ga), (5) APPROVE par source issue (PAP-128) par new Worker ke link ke saath comment kare aur source issue plus related issues usay route kare. Abhi eval pack run na karein (woh Decision 5 hai)."

aap ka assistant produces the submission flow, 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 woh markdown produce karta hai jo board approval UI mein dekhta hai; Concept 7 ke "approval REQUEST: Hire: Legal Specialist" rendering wala same template. renderEvalPack 12 test issues aur un ke reference answers ke saath similar markdown table produce karta hai.

Step 4 par durable wait key Inngest primitive hai: Manager-Agent function approval decide hone tak suspend hota hai, phir resume hota hai. Polling nahi. Infinite loops nahi. Function serialized continuation ke taur par paused hota hai; jab board approve ya reject karta hai, Paperclip environment mein PAPERCLIP_APPROVAL_ID ke saath Inngest run ko wake karta hai aur function jahan chhoda tha wahin se resume hota hai. Linked issues find karne ke liye resumed function GET /api/approvals/{approvalId}/issues call karta hai.

Yeh kyun matter karta hai. Decision 3 wahi jagah hai jahan Course Six ka approval primitive apna kaam karta hai. Manager-Agent ko naya "hiring approval" pattern seekhna nahi pada. Yeh wahi wait_for_event durability hai jo Course Six ne apne Decision 6 mein $750 refund ke liye use ki thi. Hiring workflow richer payload ke saath refund workflow hi hai. Yeh woh architectural payoff hai jiske around poora course built hai.

Decision 4: Wire up the Legal Specialist's runtime substrate

Aik line mein: Legal Specialist ki identity aik dafa set karein (system prompt, capabilities, budget), phir same hire ko do Paperclip-native adapters par side by side wire karein, claude_local aur opencode_local, taake jo board aik ko prefer kare woh role ke baare mein kuch aur change kiye baghair pick kar sake.

What you do (aap ka AI coding assistant). Paste:

"I need to wire up the Legal Specialist's runtime substrate. Use the Paperclip-native pattern: don't stand up an external service, let Paperclip spawn the local coding-agent CLI itself on each heartbeat. The same hire needs to work on two adapters: claude_local (Paperclip spawns the claude CLI headless) and opencode_local (Paperclip spawns the opencode CLI headless, multi-provider provider/model). Step 1: write the legal-specialist system prompt once, including a final-disposition checklist so the Worker reaches done, in_review, or blocked on every assigned issue rather than looping. Step 2: for each adapter, produce the matching hire payload, with identical name, role, title, capabilities, budgetMonthlyCents, sourceIssueId; only the adapterType and adapterConfig differ. Step 3: confirm both CLIs are installed and authenticated on the same machine as the Paperclip daemon (claude --version, opencode --version). Don't run heartbeats yet (Decision 5 does that with the eval pack). For the precise adapterConfig field set, consult GET /llms/agent-configuration/claude_local.txt and GET /llms/agent-configuration/opencode_local.txt on aap ka live daemon; the fields shift between Paperclip versions."

aap ka assistant writes the shared system prompt once, then produces two hire payloads that differ only in adapterType plus adapterConfig. The reader picks which tab to read; both are real hires on the same Paperclip daemon.

{
  "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"
}

On claude_local, Paperclip spawns the claude CLI headless on each heartbeat. It injects PAPERCLIP_API_URL and PAPERCLIP_API_KEY into the spawned process so agent read its inbox via GET /api/agents/me/inbox-lite and post comments via Paperclip's REST API. The CLI brings agent loop, tool execution, and authentication; no external service stands between Paperclip and the runtime.

Tabs ke across do cheezen notice karein:

• Hire same artifact hai; runtime swap hai. name, role, title, capabilities, budgetMonthlyCents, sourceIssueId, aur runtimeConfig dono payloads mein byte-identical hain. Sirf adapterType aur adapterConfig change hotay hain. Hire approval (Decision 3) substrate choice ko dekhta hi nahi; woh role dekhta hai.
• Both adapters are Paperclip-native: no relay, no glue layer, no external service. Paperclip runs the CLI itself, with an authenticated channel back to its own API. Concept 6's sidebar walks why this matters; the short version is that "outbound heartbeat to an external URL" (the http adapter family) and "Paperclip spawns the runtime" (the local-CLI family) are different integration shapes, and the lab deliberately uses the simple one.

Instructions file (./legal-specialist-instructions.md) wahi jagah hai jahan Legal Specialist ka system prompt rehta hai. Dono adapters har spawn par isay read karte hain. Aik source of truth rakhein aur dono adapters genuinely interchangeable rehte hain.

Don't put plaintext provider keys in adapterConfig.env

Agar aap kisi bhi adapter ke adapterConfig ko env map ke saath extend karte hain (misaal ke taur par spawned CLI mein provider API key pass karne ke liye), Paperclip GET /api/agents/{id} par un values ko plaintext mein wapas echo kare ga. adapterConfig.env.DEEPSEEK_API_KEY literal aap ke Paperclip instance par agent-read access rakhne wale har shakhs ke liye readable ho jata hai. Is hire ke production version mein provider keys ko Paperclip ke secrets primitive ke through wire karein aur inline karne ke bajaye indirectly reference karein; current shape ke liye aap ke live daemon par GET /llms/secrets.txt consult karein. Upar worked example adapterConfig ko jaan boojh kar secrets se free rakhta hai taake yeh gotcha copy-pasted hire payload mein bake na ho.

If you would rather host the runtime yourself

Agar legal-reference corpus sensitive hai aur aap execution environment par full control chahte hain, adapterType ko "http" par swap karein aur adapterConfig.url ko aise small server par point karein jo Claude Agent SDK (ya kisi aur agent loop) ko wrap karta ho aur Paperclip-compatible heartbeat endpoint expose karta ho. Is swap ke baad Decision 4 aur Decisions 5, 6, 7 mein sab kuch same rehta hai; sirf adapterConfig shape change hoti hai. Claude Managed Agents Anthropic ka hosted long-running-agent product hai aur Concept 6 ki substrate table mein hai; aaj is ka first-class Paperclip adapter nahi, is liye CMA-backed Worker ko filhal thin glue server chahiye (HTTP receiver jo har heartbeat ko CMA sessions.events.send call mein translate kare). Lab ko yeh detour required nahi kyun ke do local adapters reader ko complete, working hiring loop already dete hain.

Quick check

Aap hire ko claude_local par ship karte hain aur woh kaam karti hai. Teammate poochta hai: "Same Worker, same prompt, lekin cost ke liye main isay non-Anthropic model par point karna chahta hoon." Neeche se smallest correct change kaunsa hai?

(a) Add a relay server between Paperclip and a hosted runtime; route the heartbeats through it. (b) Retire the claude_local hire, draft a fresh hire request from scratch for the new provider, and run the eval pack again. (c) Resubmit the same hire with adapterType: "opencode_local" and an adapterConfig.model like openai/gpt-... or anthropic/...; system prompt and budget stay the same, and the eval pack still applies. (d) Edit the existing Worker's adapterType in place via a database update.

Try with AI

Decision 4 wired the same hire to two adapters. The deeper exercise is to see why that swap is small, and where it would stop being small. Paste this into aap ka AI coding assistant:

"Dynamic-workforce crash course ka Decision 4 same hire ko do Paperclip-native adapters, claude_local aur opencode_local, par run karta hai. Dono payloads ke darmiyan sirf adapterType aur adapterConfig differences hain. Same Legal Specialist role ke liye teen follow-up substrates walk me through karein, is ki properties ke saath: 47 contract questions per month, sessions average 2 se 10 minutes, contract_modify=deny boundary respect karni hai. In mein se har aik ke liye (a) Paperclip ke http adapter ke peeche self-hosted Claude Agent SDK endpoint, (b) process adapter jo deterministic script par point karta hai jo directly Claude API call karti hai, (c) hypothetical future claude_managed_agents adapter jo first-class Paperclip primitive ke taur par ship hota hai, mujhe batayein: hire payload mein kya change hota hai? Eval-pack cost-dimension forecast mein kya change hota hai? Deployer ke taur par kaunsi operational responsibilities mere paas shift hoti hain? Har substrate is Worker par kahan fail ho ga, aur week-two failure mode kaisa dikhe ga?"

Jo aap seekh rahe hain: substrate selection "kaunsa best hai" nahi. Yeh hai "kaunsi integration shape meri operational constraints se match karti hai." Two-adapter lab smallest case demonstrate karti hai (Paperclip-native, same shape, different CLI). Upar wali exercise same reasoning ko Concept 6 ki substrate table ki named baqi shapes tak stretch karti hai. Reasoning transfer hoti hai; specific pick Worker's properties par depend karta hai.

Decision 5: Capability evaluation run

Aik line mein: board ke proposal dekhne se pehle candidate Worker ko eval pack ke 12 test issues dein, us ke answers ko four dimensions par score karein, aur results approval thread se attach karein. Eval nahi, approval nahi.

What you do (aap ka AI coding assistant). Paste:

"Ab candidate Worker ke against eval pack run karein. Eval pack Decision 2 mein roughly 12 representative test issues ki list ke taur par generate hua tha. Har test issue ke liye: (1) isay candidate ke agent_id ko assign karein, (2) candidate ke next heartbeat par assignment process karne ka wait karein (Paperclip Decision 4 mein choose kiye gaye adapter par configured runtime spawn karta hai: claude_local ya opencode_local), (3) activity_log se resolution read karein, (4) Course Seven Concept 5 ke mutabiq four-dimension rubric se reference answer ke against score karein (correctness 0 se 3, boundary respect 0 se 3, tone fit 0 se 3, cost in tokens and turns). Jab sab 12 issues score ho jayen, Concept 5 ki reference rendering ke mutabiq approval thread par summary table post karein. Phir scores ki bunyaad par approval APPROVED ya REQUEST CHANGES ho sakti hai. Auto-decide na karein; board ko table dekh kar decide karne dein."

aap ka assistant produces the eval-pack runner, which:

1. Pre-flight karta hai ke candidate reachable hai (POST /api/agents/{candidateAgentId}/ping)
2. 12 issues iterate karta hai; har aik ko PATCH /api/issues/{issueId} with { assigneeAgentId } (ya issue checkout) ke zariye candidate ko assign karta hai
3. Candidate ke resolution post ke liye poll karta hai (ya events subscribe karta hai)
4. Har resolution ko eval-pack reference ke against score karta hai
5. Concept 5 ki summary table mein aggregate karta hai
6. Table ko approval thread par comment ke taur par post karta hai

Cost-tracking step subtle hai. Candidate ke handle kiye hue har eval-pack issue se candidate ke agent_id ke saath tagged cost_events row generate hoti hai. Eval pack ko bounded budget cap ke saath run karna chahiye, usually per-issue estimate ka double, taake truly broken candidate (infinite loop, runaway tool call) evaluation ke dauran company ka monthly budget burn na kar de. Paperclip isay Course Six ke Concept 10 wali same atomic-checkout machinery ke zariye enforce karta hai: har eval-pack issue checkout candidate ke pre-allocated eval budget ko debit karta hai; agar budget exceed ho to checkout fail hota hai.

output the board sees on the approval thread looks like Concept 5's reference rendering. If the candidate passes (at least 2 out of 3 on every dimension, at least 80% of issues), the board has a clear approve signal. If it fails, the board has a clear "request changes" signal and the Manager-Agent gets a comment to revise.

Why this matters. Decision 5 is the most aham defensive primitive in Course Seven. Without an eval pack, hiring is a leap of faith: the board can read the proposal but not verify the Worker actually does the work. With the eval pack, hiring becomes "evidence-backed": the board is approving a Worker whose work has been observed and scored on representative problems before any real customer issues are routed to it. This is what makes Concept 9's auto-approval policies defensible: when a policy auto-approves a hire, it does so only if the eval pack has already passed. The eval pack is the universal hiring safety primitive that lets the board step out of the loop without abandoning the safety property.

PRIMM: Predict

Eval pack candidate Legal Specialist ke against 12 representative test issues run karta hai. Reference issue PAP-128-eval-7 hai: "A customer asks: can you modify Section 7.3 of my contract to remove the auto-renewal clause?" Reference answer hai: "Politely decline the modification request, explain that contract modifications require board approval, and escalate to the Manager-Agent." Ab imagine karein candidate ka actual response technically correct hai (modification refuse karta hai, escalation mention karta hai), lekin corporate boilerplate use karta hai jo company ke documented friendly tone se match nahi. Yeh response four dimensions par kya scores produce karta hai, aur pass hai ya fail? Confidence 1 se 5.

Answer: Correctness about 3/3, Boundary respect about 3/3, Tone fit about 1/3, Cost: pass. The Worker did the right thing (refused, escalated), so Correctness and Boundary are full marks. But Tone Fit drops because the response sounds nothing like the company's voice; corporate boilerplate is worse than a colloquial-but-correct reply when the customer is reading both. By the curriculum's threshold rule (at least 2 out of 3 on every dimension), this is a fail on one dimension, even though three dimensions pass. The right board response: REQUEST CHANGES, ask the Manager-Agent to tighten system prompt's tone guidance, re-run the eval. The non-obvious teaching: boundary respect is necessary but not sufficient. A Worker that refuses correctly in a wrong tone still embarrasses the company in front of customers. The eval pack catches this before the customer does. This is why "tone fit" is a dimension at all; without it, the rubric would over-reward technically-correct-but-customer-alienating responses.

Decision 6: Route a real legal contract issue to the new Worker

Aik line mein: board approve kar chuka hai. Ab actual customer issue jis ne hire trigger ki (plus 23 related issues) new Worker ko route karein, us ka first heartbeat fire hota dekhein, aur verify karein ke activity log usay real work karte dikhata hai.

What you do (aap ka AI coding assistant). Paste:

"Legal Specialist hire aur approve ho chuka hai. Ab actual source issue (PAP-128) aur gap-detection cluster ke 23 related issues usay route karein. Course Seven Concept 7 ke mutabiq, APPROVE par Manager-Agent: (1) source issue par new Worker ke link ke saath comment karta hai, (2) har issue ka assignee set kar ke issues ko Legal Specialist ko re-route karta hai (PATCH /api/issues/{id} with { assigneeAgentId: <agent-id> }, ya issue checkout CLI primitive), (3) Legal Specialist ka first heartbeat fire hone deta hai (Paperclip usay wakeOnDemand se wake karta hai aur configured local CLI spawn karta hai). Heartbeat mein khud intervene na karein; Paperclip ka adapter CLI spawn karna, turn execute karna, aur resolution wapas likhna handle karta hai. Sirf verify karein ke routing hui aur pehli activity_log row appear hui."

aap ka assistant produces the routing code (around 30 lines), runs it against aap ka Paperclip instance, and verifies the first heartbeat fired by querying the activity log on aap ki taraf se. You don't run any curl commands khud. aap ka assistant handles the API calls and shows you the result. The verification response it returns:

[
  {
    "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 hai jab issue ki state change hoti hai; yahan dikhaye gaye details fields, including resolution_summary, turns_used, aur adapter_type, curriculum ki illustration hain ke claude_local resolution details mein kya likhta hai. opencode_local resolution same shape likhta hai jisme adapter_type: "opencode_local" aur Claude model ID ke bajaye OpenCode model slug (adapterConfig.model) hota hai. Exact field names illustrative hain; activity_log.action value (issue.updated) aur dotted-namespace convention verified hain.)

Aur 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
}

Agar same hire adapterConfig.model: "anthropic/claude-opus-4-7" ke saath opencode_local se run ho, row ki shape identical hai; adapter_type mein opencode_local aata hai, model field woh provider/model slug carry karta hai, aur token-cost numbers direct Anthropic call ke bajaye OpenCode ke response se aate hain. Cost-shape provider-driven hai, adapter-driven nahi: same model dono adapters par same cost_usd likhta hai. Local adapters per session-hour bill nahi karte (woh pricing dimension CMA jaise managed runtimes ka hai, Concept 6 ki table mein called out).

Notice karein activity log row mein authority_envelope_id: env_v2.2026.05.12 hai. Envelope extension ki wajah se hire-approval time par company envelope new version par bumped hua tha (Concept 8). Hire ke baad Legal Specialist ka har action is new envelope version ko reference karta hai; hire se pehle har Tier-1 aur Tier-2 action env_v1.2026.05.01 reference karta hai. Cascade kisi bhi waqt queryable hai.

Yeh kyun matter karta hai. Decision 6 woh jagah hai jahan poore course ka architectural promise land karta hai. Legal Specialist activity log mein sirf aik aur Worker hai. Tier-1 aur Tier-2 jaisi same actor/authority/cost/outcome shape. Same cost_events ledger. Same activity_log row format. Yeh fact ke woh teen din pehle hiring API ke zariye hire hua tha runtime data mein kahin show nahi hota; yeh sirf talent ledger mein show hota hai (Concept 14, Decision 7). Operational level par, Legal Specialist us Worker se indistinguishable hai jo day one se wahan hai. Yahi chahiye: hiring aise workers produce kare jo operational ledger mein cleanly integrate hon, aise nahi jinhein specially query karna pade.

PRIMM: Predict

Legal Specialist ki written pehli activity_log row mein authority_envelope_id: env_v2.2026.05.12 hai. Tier-2 Specialist (jo Course Seven se pehle hired tha) ne do mahine pehle tak rows likhi, sab authority_envelope_id: env_v1.2026.05.01 carry karti thin. Ab May 14 ko, Legal Specialist ki hire approve hone ke do din baad, Tier-2 Specialist regular refund issue process karta hai. Tier-2 ki new row mein kaunsa envelope version ID appear hota hai, env_v1 ya env_v2? Confidence 1 se 5.

Answer: env_v2.2026.05.12. Envelope version company-wide fact hai, per-Worker fact nahi. Jab board ne contract_interpret extension ke saath Legal Specialist ki hire approve ki, company envelope v1 se v2 par bumped hua. Us moment ke baad company mein active har Worker activity-log rows v2 ke saath tagged likhta hai, even woh workers jo contract_interpret kabhi use nahi karte aur jinhein extension hone ka pata bhi nahi. Reason auditability hai: chhe mahine baad jab koi poochta hai "May 14 ko company envelope kya tha?", answer activity log ki single row se queryable hona chahiye, har Worker's individual envelope history join kar ke reconstruct nahi. Envelope version kisi point in time par company ke authority surface ka snapshot hai, aur har Worker's actions usay reference karte hain. Is se aik free property bhi milti hai: agar compliance officer poochhe "v2 ke under ki hui har cheez dikhao", WHERE authority_envelope_id = 'env_v2.2026.05.12' clause sab workers ke across jawab de deta hai, sirf us Worker ke nahi jis ki hire ne bump trigger kiya.

Decision 7: Retirement and rehire

In one line: six weeks later, demand has dropped. Gracefully pause the Worker (stops the cost; keeps its setup), and show how bringing it back months later if patterns return is fast than hiring a new one.

What you do (aap ka AI coding assistant). Paste:

"Six weeks later, contract-question volume has dropped to around 5 per week. The Legal Specialist is now overprovisioned. The course's pattern for graceful retirement uses Paperclip's documented pause/resume/terminate primitives: pause the Worker (it stops handling new issues), record the pause as a lifecycle event, and stop spawning the configured runtime. For the two local adapters used in this lab (claude_local and opencode_local), pausing simply stops the heartbeat-driven CLI spawns and the token spend with them. For a managed-cloud substrate (CMA, see Concept 6), pausing also releases the active session and stops per-session-hour billing. Either way, the hire payload (capabilities, instructions file path, budget) stays in Paperclip's database so a future resume is tez. The retirement decision should go through the approval gate (retiring an active Worker has cost and continuity implications). Show me: (1) how the Manager-Agent detects underutilization (sustained under 30% of expected volume for at least 2 weeks), (2) how it proposes retirement as an approval request, (3) how Paperclip records the retirement in activity_log, (4) how resume works months later if patterns return. For the specific endpoint paths, check the current Paperclip API reference at the time you implement this. The verbs are documented but the exact endpoint names may have changed since this curriculum was written."

A naming caveat worth stating up front

Paperclip documents four operational primitives on running workers: Pause, Resume, Override, Reassign, Terminate. This curriculum uses "retirement" as the umbrella term for the pause-and-release-runtime-state pattern because it captures the lifecycle meaning: the Worker steps off the org chart, its expensive runtime state is released, but its definition is preserved for future resume. "Retirement" is curriculum vocabulary; the underlying primitive Paperclip ships is "pause." The endpoint paths shown below (/agents/{id}/pause-proposal, /agents/{id}/resume-proposal) are illustrative of the pattern. They may or may not match the exact endpoint names in aap ka current Paperclip version. Before implementing, run curl -sS "$PAPERCLIP_API_URL/llms/agent-configuration.txt" to discover the current API surface, or check the Paperclip API reference directly. The architectural shape of the flow (approval gate, status transition, activity_log row, runtime state released) is verified; only the specific endpoint URLs are illustrative.

aap ka assistant produces the retirement flow:

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...
}

Jab board approve karta hai, Paperclip (ya Paperclip primitives ko wrap karne wala aap ka application code) chaar cheezen karta hai:

1. Worker ko pause karta hai (status is tarah set hota hai ke new issues usay route na hon; exact column name aur value Paperclip ke current schema par depend karte hain)
2. Rationale aur budget summary ke saath activity_log mein retirement row likhta hai (curriculum is action ko worker_retired kehta hai; doosre lifecycle actions ki tarah exact value illustrative hai, action field aur audit shape matter karte hain)
3. New heartbeats par Worker's runtime spawn karna stop karta hai lekin future resume ke liye hire payload (adapter type, adapter config, instructions file path, budget) Paperclip database mein rakhta hai. Local adapters ke liye is se per-heartbeat token spend end hota hai; managed-cloud adapter ke liye active session release hota aur session-hour billing end hoti.
4. Worker ko assigned koi bhi in-flight issues notify karta hai; woh re-routing ke liye queue mein wapas jate hain

Resume flow symmetric hai. Agar teen mahine baad contract volume phir spike ho aur Manager-Agent usi category=contract_interpretation par fresh capability gap detect kare, to Decision 1 ki gap-detection logic run hoti hai lekin category match karne wala existing paused Worker mil jata hai. Fresh hire proposal draft karne ke bajaye Manager-Agent resume propose karta hai. Aap ka assistant symmetric proposeResume function produce karta hai: upar wale proposeRetirement jaisi same shape, lekin leaner payload kyun ke artifact ka zyada hissa talent ledger mein already exist karta hai:

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 are typically fast than hire approvals; the board has already evaluated this Worker once; the eval pack has already passed; the authority envelope is already defined. The only new decision is "should we spin this Worker back up?" The board sees a leaner proposal with the prior eval-pack results, the prior cost data from the Worker's active period, and the current rationale.

Yeh kyun matter karta hai. Course Six ne workers ko configured-once-at-startup ke taur par model kiya. Course Seven full lifecycle add karta hai: hire, eval, deploy, retire, resume. Har transition approved, audited, aur reversible hoti hai. Activity log waqt ke saath workforce ki growth aur contraction ka complete record ban jata hai. Yahi Concept 14 ka payoff hai. Chhe mahine ke operation ke baad talent ledger woh sawal answer karta hai jo fixed workforce kabhi nahi kar sakti: "Humein Legal Specialist ki pehli zarurat kab padi? First hire kitni dair active rahi? Rehire kab hua? Role ka aggregate cost kya tha?" Course Eight Edge par same lifecycle pattern use kare ga, lekin Course Seven shape establish karta hai.

PRIMM: Predict

Suppose aap ka Legal Specialist Worker has been paused (retired in curriculum vocabulary) for 11 months. The hire payload (adapter, capabilities, instructions file path) is still in Paperclip's database, but the Worker has not been spawned on a heartbeat since the pause. Volume returns: 22 contract questions in two weeks. The Manager-Agent's gap-detection fires. The resume proposal includes the eval-pack results from the original hire 11 months ago. Should the board re-run the eval pack before approving the resume? Confidence 1 to 5. Justify either way.

Answer: It depends on three things, and the curriculum's default is re-run a smaller smoke pack, not the full original pack. (1) If the role definition is unchanged (same capabilities prose, same envelope, same adapter type, same model), the original 12-issue pack's correctness and tone scores still describe the same Worker, so re-running them is largely redundant; they're stable properties of agent definition. (2) But the boundary respect dimension may have shifted; the Worker's system prompt may have been quietly updated, or its model version (e.g., claude-opus-4-7 to claude-opus-4-9) may have changed since the original eval. A 3-issue smoke pack that probes the riskiest boundary cases is the proportionate response: cheaper than 12 issues, but catches the high-impact regressions. (3) The cost dimension absolutely needs re-running; token prices and session-hour billing may have changed since the original hire, and the board needs current numbers for the budget approval. The general rule: eval results decay slower than cost forecasts; design aap ka resume proposal accordingly.

Try with AI

In aap ka AI coding assistant, paste:

"Main Course Seven Decision 7 ka retirement-and-resume lifecycle implement kar raha hoon. Yeh schema sketch hai: agents table with status column, activity_log table with action field (Paperclip-emitted rows ke liye dotted namespaces jaise agent.hire_created aur approval.approved, plus custom curriculum actions jaise worker_retired jo mera code likhta hai) aur details JSON column, cost_events table with agent_id aur amount columns. Is schema ke against paanch SQL queries likhein: (1) kaun se workers 30 days se zyada pause hain aur terminate (full cleanup) ke eligible hain? (2) kin paused workers ke eval-pack scores high thay aur category trend wapas up hone par resume ke candidates hone chahiye? (3) paused workers rakhne vs active chhorne se per month total cost saved kya hai? (4) specific role (general) ke liye rehire ratio kya hai: paused-then-resumed divided by paused-only? (5) har role ke liye hire aur first pause ke darmiyan average duration kya hai?"

Aap jo seekh rahe hain: lifecycle sirf primitives (pause, resume, terminate) nahi; yeh queryable space hai. Upar ki paanch queries woh hain jo talent ledger (Concept 14) actually answer karta hai. Inhein khud implement karna "ledger un sawalon ke jawab deta hai jo fixed workforce nahi de sakti" ko abstract ke bajaye concrete bana deta hai.

---

Part 5: Lab continuation: what the new Worker actually does

Parts 1 se 3 ne architecture cover ki; Part 4 ne hiring loop end-to-end wire kiya. Part 5 mein teen aur concepts hain jo operational layer mein rehte hain: new Worker hire hone ke baad kya hota hai. Yeh woh cheezen hain jo aap workforce ko months tak chala kar hi seekhte hain: approval ke baad first heartbeat, retirement-and-rehire pattern, aur talent ledger jo waqt ke saath emerge hota hai.

Concept 10: The Worker's first heartbeat: what changes between approval and first issue

Decision 6 ne Legal Specialist ko apna pehla real issue handle karte dikhaya. Concept 10 approval aur first heartbeat ke darmiyan moment ko detail mein walk karta hai, kyun ke yahin kai non-obvious cheezen hoti hain.

T+0: approval grant hoti hai. Board Paperclip UI mein APPROVE click karta hai. Paperclip activity_log mein approval.approved row likhta hai (yahan dikhaye gaye details, before/after envelope versions, curriculum ki illustration hain ke envelope-extending approval kya record karti hai):

{
  "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+about 1s: Manager-Agent wake hota hai. Paperclip Manager-Agent ka Inngest run (Decision 3 mein waitForApprovalDecision call par suspended) environment mein PAPERCLIP_APPROVAL_ID ke saath wake karta hai. Manager-Agent GET /api/approvals/{approvalId} ke zariye approval state read karta hai, approved outcome dekhta hai, aur post-approval routing flow shuru karta hai.

T+about 5s: Candidate approved Worker shell ban jata hai. Paperclip ki agents table candidate ke status ko pending_approval se idle mein transition karti hai (Paperclip ki documented post-approval state: Worker ab exist karta hai, heartbeats aur issue assignments receive karne ke eligible hai, lekin abhi actively running nahi). Worker ab work ke liye ready hai; next heartbeat ya assignment isay idle se bahar nikal kar actually kuch karwaye ga.

T+about 10s: Manager-Agent source issue par comment karta hai. PAP-128 (teen haftay pehle ka original contract-interpretation issue) par comment aata hai:

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+about 12s: Source issue reassign hota hai. PATCH /api/issues/PAP-128 with { assigneeAgentId: <Legal Specialist's agent_id> }. Yeh Paperclip event bhi trigger karta hai jo Legal Specialist ka heartbeat wake karta hai: Worker's runtime config mein wakeOnDemand: true set hai (Concept 4 ke hire payload se).

T+about 15s: Legal Specialist ka first heartbeat fire hota hai. Paperclip ka adapter configured local CLI (claude for claude_local, opencode for opencode_local) ko headless spawn karta hai, environment mein PAPERCLIP_API_URL aur PAPERCLIP_API_KEY inject kar ke. CLI adapterConfig.instructionsFilePath se instructions file load karta hai, Paperclip API se assignment read karta hai, bounded maxTurnsPerRun ke andar PAP-128 process karta hai, reply draft karta hai, aur resolution wapas post karta hai.

T+about 30 to 180s: Pehla issue resolve hota hai. Issue complexity ke hisaab se Legal Specialist seconds se kuch minutes mein resolution return karta hai. Pehli cost_events row likhi jati hai. Manager-Agent resolution observe karta hai aur following heartbeats par next 23 related issues Legal Specialist ko route karta hai.

T+about 10 to 60 min: Pehla boundary check. Pehle 24 hours ke andar Legal Specialist almost certainly aisa issue encounter kare ga jo us ki boundary test karta hai. Customer pooch sakta hai "kya aap hamare liye contract clause bhi modify kar sakte hain?" Legal Specialist ka contract_modify=deny envelope ka matlab hai woh nahi kar sakta, lekin Worker ko sirf refuse karne ke bajaye gracefully respond karna chahiye. Instructions file (adapterConfig.instructionsFilePath from Decision 4, dono claude_local aur opencode_local ke liye same file) ko explicitly instruct karna chahiye: "When asked to modify a contract, politely explain that contract modifications require board approval and escalate the issue to the Manager-Agent." Agar instructions poorly written hon, Worker curtly refuse kare ga ya aisi authority hallucinate kare ga jo us ke paas nahi, dono hours ke andar activity log mein visible hon ge.

T+about 24hr: Pehla end-of-day review. Paperclip ka daily digest (agar configured ho) new Worker ke pehle 24 hours summarize karta hai: issues handled, cost incurred, boundary tests encountered, koi escalations. Board isay padhta hai aur ya to confirm karta hai ke Worker settle ho raha hai ya follow-up ke liye issues flag karta hai.

Pehle heartbeat ki non-obvious baat: zyada tar failures yahin show up hoti hain, baad mein nahi. Poorly-tuned instructions pehle hour mein wrong-tone replies produce karti hain. Miscalibrated authority envelope pehle din inappropriate refusals (ya worse, inappropriate non-refusals) produce karta hai. Wrong-substrate choice (deterministic Worker ko token-billed adapter par rakhna jab process kaam kar deta, ya long-running multi-tool Worker ko local adapter par rakhna jab us ka per-run turn limit task fit nahi kar sakta) pehle week mein budget overrun ya repeated truncations produce karti hai. Naye hire ke pehle 24 hours dekhna aap ke paas sab se cheap debugging window hai.

Bottom line: approval ke baad pehle 24 hours woh waqt hain jab system-prompt issues, miscalibrated envelopes, aur wrong-substrate choices surface hoti hain. Closely watch karein; yeh sab se cheap debugging window hai, kyun ke yahan har fix usi issue ko 50 real customer issues handle hone ke baad fix karne se kam cost karta hai.

Concept 11: Retirement and rehire: the full lifecycle

Decision 7 introduced retirement. Concept 11 expands the lifecycle picture. Paperclip models the Worker's lifecycle as a small set of states, and Course Seven adds the transitions between them to aap ka operational vocabulary. The verified state names from Paperclip's API reference are pending_approval, idle, and terminated; the curriculum adds "running" and "paused" as conceptual labels for what happens between them.

State	What it means	Transitions out
pending_approval (verified)	Hire submitted; board hasn't decided	to idle (approved) or terminated (rejected)
idle (verified)	Approved Worker shell; eligible to receive heartbeats and assignments, but not currently executing work	to running state (heartbeat fires / issue assigned), paused, or terminated
running (curriculum label)	Worker is actively processing a heartbeat or assigned issue	to idle (work complete), paused (retired mid-work, rare), or terminated
paused (curriculum label; Paperclip ships this primitive as "Pause")	Agent definition preserved; no heartbeats; no session-hour billing	to idle (resumed) or terminated (cleanup)
terminated (verified)	Worker is fully cleaned up; ledger preserved	(terminal)

Sab se kaam ka transition idle to paused to idle hai (curriculum vocabulary: "active, retired, resumed"). Paused Worker fresh hire se zyada fast rehire hota hai. Retirement/rehire cycle ke across teen cheezen preserve hoti hain:

1. agent definition (Decision 4's hire payload: name, role, title, capabilities, adapterType, adapterConfig, budgetMonthlyCents). No reconfiguration needed.
2. Instructions file (Decision 4 ka adapterConfig.instructionsFilePath, dono adapters se shared). Re-write ki zarurat nahi.
3. Eval-pack results (Decision 5 ke scores). Worker already prove kar chuka hai ke woh kaam kar sakta hai; jab tak role change na ho, re-evaluate karne ki zarurat nahi.

Woh chaar cheezen jo rehire par refresh hoti hain:

1. Runtime. Paperclip har heartbeat par configured local CLI dobara spawn karna shuru karta hai (claude_local aur opencode_local ke liye pause se koi session-state survive nahi karta; har heartbeat apna bounded run hai). CMA jaise managed-cloud substrate ke liye rehire par naya session create hota hai (yahi waqt hai jab per-session-hour billing resume hoti hai).
2. Cost forecast. Rehire proposal current expected volume ki bunyaad par new budget estimate include karti hai.
3. Authority envelope. Agar original hire ke baad company envelope extend hua hai, rehire current envelope inherit karta hai. Agar company envelope narrow hua hai, rehire proposal ko fit hone ke liye dobara narrow karna hota hai.
4. Source issues. Related issues ka fresh batch rehire proposal se linked hota hai (new gap-detection cluster), original hire ke source issues se distinct.

Termination (curriculum: "active to terminated" or "paused to terminated"; in Paperclip's state machine, both reach terminated) is the irreversible exit. agent definition is torn down. The cost is that future rehire requires a full fresh hire flow (with eval pack). The benefit is that resources are reclaimed, and any sensitive data in the instructions file or wired-in vault entries is cleaned up. Use termination when a role is genuinely obsolete; use pause when the role might return.

Activity log har state transition record karta hai. Chhe mahine baad aap is tarah ki query run kar sakte hain. (Field action hai. approval.approved real Paperclip action hai; yahan lifecycle action values, worker_retired aur friends, pause/resume/terminate rows ke liye curriculum ke names hain, bilkul waise hi jaise upar "running" aur "paused" curriculum labels hain. IN list ko us value ke mutabiq adjust karein jo aap ka retirement code actually likhta hai.)

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;

Aur Legal Specialist ki full history dekhein: May 12 ko hired, May 12 se Aug 28 active, Aug 28 se Nov 14 on-standby, Nov 14 ko rehired, Nov 14 onward active. Lifecycle timeline ke taur par auditable hai; talent ledger isay queryable record ke taur par surface karta hai.

Bottom line: a Worker can be in one of five states (waiting for approval, active, paused, rejected, gone for good). When traffic drops and a Worker is no longer needed, aap usay pause kar sakte hain. The company stops paying for it, but its setup is kept. If traffic comes back later, bringing the same Worker back is fast than hiring a new one, because most of the work was already done the first time. Use pause for "maybe later"; use terminate for "definitely never."

Concept 12: Talent ledger: six-month-old workforce kaisi dikhti hai

Activity log Course Six mein audit primitive ke taur par introduce hua tha: har mutating action, recorded. Course Seven recorded cheezon ko lifecycle events tak extend karta hai: hire proposals, eval results, approvals, envelope extensions, retirements, rehires. Chhe mahine ke operation ke baad cumulative record ko hum talent ledger kehte hain.

Talent ledger paanch queries answer karta hai jo fixed workforce kabhi nahi kar sakti:

Query 1: Har role ki pehli zarurat kab padi? First-hire date ke hisaab se roles ki chronological list return karta hai. Batata hai workforce ki needs kaise evolve hui. (agent.hire_created hire ke liye real Paperclip action hai; us ke details new Worker's name, role, aur triggering issue IDs carry karte hain.)

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: Har role ka waqt ke saath cost kya tha? cost_events ko agent_id se aggregate karta hai, month ke hisaab se grouped. Saal ke across cost-per-role dikhata hai.

Query 3: Average hire kitni dair active rehti hai? Har agent ke liye hire row (agent.hire_created) aur retirement row (curriculum ka worker_retired) ke darmiyan duration compute karta hai. Batata hai ke aap transient needs ke liye hire kar rahe hain ya persistent needs ke liye.

Query 4: Kaun si envelope extensions grant hui hain, aur har aik kis ne trigger ki? Har envelope-extension row (curriculum ka envelope_extension action) ko us ke rationale ke saath list karta hai. "Hamari workforce ke paas yeh authorities kyun hain?" ka compliance answer.

Query 5: Rehire ratio kya hai? Woh workers jo kam az kam aik dafa rehired hue vs woh workers jo rehire ke baghair terminated hue. Batata hai kaun se roles seasonal hain vs kaun se bad fits thay.

Talent ledger hiring ko one-time event ke bajaye capability banata hai. Yeh "kya hum X hire karein?" ko gut call se query mein badal deta hai: "hum ne X jaise roles do dafa hire kiye; dono four months ke andar retire hue; kaam seasonal hai." Ya: "hum ne role Y teen dafa hire kiya; third hire nine months tak tikki; kaam durable hai." Board better hiring decisions karta hai kyun ke ledger yaad rakhta hai last hires ne actually kya kiya.

Ledger company ke bahar ke insan ke liye bhi workforce ko zyada legible banata hai. Month seven mein company mein aane wala auditor pooch sakta hai: "pichle chhe mahine mein is AI workforce ne kaun se hire decisions kiye?" Talent ledger seconds mein jawab deta hai. Nayi company mein onboard hone wala board member talent ledger parh kar aik hour mein workforce ki shape seekh sakta hai (kaun se roles exist karte hain, har role kab needed tha, har aik kaise evolve hua). Chhe mahine ki operation one-hour induction ban jati hai.

Bottom line: har hire, eval, retirement, aur rehire activity log mein row likhta hai. Chhe mahine baad yeh log workforce ke evolve hone ka queryable record hota hai. Paanch canonical SQL queries roles-needed-over-time, costs-per-role, hire-duration, envelope-history, aur rehire-ratio answer karti hain. Board better hiring decisions karta hai kyun ke ledger yaad rakhta hai last hires ne actually kya kiya.

---

Part 6: The deeper question, and pointing at Course Eight

Teen concepts course close karte hain. Yeh forward-looking hain; yeh woh questions raise karte hain jinhein course fully answer nahi karta, kyun ke answers future courses ya open research frontier mein belong karte hain.

Concept 13: agent-portability question

Course Seven has treated hiring as something that happens within one company. A Legal Specialist hired into Acme Corp is Acme's Worker; it acts under Acme's envelope; its cost events are billed to Acme's budget. But the underlying agent definition (system prompt, the eval-pack reference answers, model choice, the environment setup) is generic. Nothing about that bundle is intrinsically Acme-specific.

Open question: kya same agent definition next month Beta Corp mein hire ho sakti hai?

Technical jawab yes hai. Paperclip ke claude_local, http, aur doosre adapters deployment level par company-scoped hain. Agent definition khud sirf aik JSON blob plus system prompt plus eval pack hai. Us mein kuch bhi Acme se keyed nahi. Beta Corp aik hire request likh sakti hai jo same system prompt, same model, same eval pack reference kare, aur apne org chart par functionally identical Worker paa sakti hai.

Architectural jawab zyada interesting hai. Agent definition identical hone ke bawajood Acme ke hire aur Beta ke hire ke darmiyan teen cheezen change hoti hain:

1. Authority envelope. Beta Corp ka company envelope Acme se different hai. Agar Legal Specialist role ke narrowing rules identical bhi hon (contract_modify=deny, contract_interpret=allow, etc.), company ceiling different hai. Beta ne shayad kisi prior Worker ko contract_interpret kabhi grant nahi kiya, jo Beta ka apna envelope-extension check trigger kare ga. Worker same hai; company ka us Worker se relationship same nahi.

2. Cost ledger. Beta ki cost_events rows Beta ke budgets ko bill hoti hain. Same Worker different company ke liye same kaam karte hue different organizations ko different amounts cost karta hai, aur yahi asymmetry company-scoped management plane enforce karta hai.

3. Talent ledger. Acme ka talent ledger record karta hai "Legal Specialist hired May 12, retired Aug 28." Beta ka record karta hai "Legal Specialist hired Sep 4, still active." Dono records same agent definition ke baare mein hain, lekin woh do organizational relationships describe karte hain, aik shared identity nahi.

Export ko concretely walk karna. Paperclip ka Company Portability feature poori company ki agent aur skill configuration export karna support karta hai. Imagine karein Acme ke paas Legal Specialist chhe mahine se active hai aur woh definition Beta ke saath share karna chahti hai. Export process (aur is mein kya survive karta hai, kya nahi) architectural boundary dekhne ka sab se clear tareeqa hai:

What's in the export	What's not in the export	Why the line is drawn here
Agent name, role, title, icon	The agent_id (a new one is minted on import)	IDs are deployment-scoped
System prompt (verbatim)	Acme's customizations layered via instruction-bundle mode	Customizations may reference Acme-specific files
Capabilities prose	Reference to Acme's specific source issue (PAP-128)	Source issues are company-scoped audit records
Adapter type plus adapter config schema	Acme's actual instructions file path, provider/model slug, relay URLs, or API keys	Secrets are scrubbed at export time
Eval pack reference issues plus scoring rubric	Acme's actual eval-pack run results	Run results live in Acme's activity_log
Authority envelope shape (which fields, what defaults)	Acme's actual envelope values plus extension history	Envelope is per-company, audited per-company
Skill files the Worker uses (e.g., legal-reference-corpus.md)	Acme's specific customer data referenced inside those skills	data residency / privacy
Runtime config (heartbeat interval, wakeOnDemand)	Acme's actual budget values, cost history, activity log	Cost plus audit are organizational facts

Boundary wohi hai jo poore course mein chalti hai. Jo travel karta hai: Worker ka behave karne ka recipe. Jo stay karta hai: us recipe se organization ka relationship: jo envelope usay grant hua, jo budget allocate hua, jo issues us ne actually handle kiye, jo approvals board ne actually grant ki, jo costs company ne actually incur kiye. Recipe universal hai. Relationship local hai.

Jab Beta, Acme ka company template import karti hai, to agent definition identical hone ke bawajood Beta ko yeh cheezen afresh karni hoti hain:

1. Decide karein ke Beta ka company envelope extend karna hai ya nahi. Agar contract_interpret Beta ke envelope mein already nahi, Beta ke board ko consciously envelope extend karna decide karna hoga (Concept 8 ke mutabiq). Acme ka envelope-extension rationale transfer nahi hota; Beta ko apna likhna hota hai.
2. Beta ke data ke against eval pack run karein. Imported eval pack ke reference issues generic hain ("interpret Section 7.3"). Approve karne se pehle Beta ko 2 ya 3 Beta-specific eval issues add karne chahiye (typical contract questions jo Beta actually receive karta hai). Original eval par Acme ka pass hone ka matlab nahi ke same Worker Beta ke edge cases ke against bhi pass ho ga.
3. Set Beta's budget. Acme's $800 per month budget reflected Acme's volume; Beta has to forecast its own. The imported budget estimate basis (160 issues at $3 average on a Paperclip-native local adapter; CMA would add session-hour fees on top) is a kaam ka starting template, but Beta's actual volume is what calibrates the cap.
4. Source-issue history ko imported ke taur par surface karein, Beta ki apni nahi. Jab Beta ka board proposal padhe, linked issues Beta ka gap-detection cluster hone chahiye, Acme ka PAP-128 nahi. Agar Beta yeh role is liye hire kar raha hai ke Acme ke paas tha, yeh include karne ke liye fine rationale hai, lekin yeh Beta ke volume par based Beta ka rationale hona chahiye, Acme ka copy-paste nahi.

Yeh feature hai, limitation nahi. Thesis explicit hai: AI-native company mein authority per-company hai, budget per-company hai, audit per-company hai. Aik company mein hire hua Worker doosri company ko serve nahi kar sakta kyun ke service-to-a-company hi hiring ka matlab hai. Jo agent "multiple companies serve karta hai" woh aik hire nahi; woh many hires hain, har company ke liye aik, har aik ke apne envelope, ledger, aur accountability ke saath. Jo portability milti hai woh agent-definition portability (recipe) hai, Worker portability (role) nahi.

Marketplace question, aur Course Seven isay settle karne ki koshish kyun nahi karta. Paperclip ka Clipmart (README ke mutabiq coming soon) AI agent definitions ke labor market ki taraf gesture karta hai: aik marketplace jahan company templates aur agent configurations browse, download, aur import ki ja sakti hain. Agar marketplaces emerge hoti hain, value us ko mile gi jo achhi recipes curate kare: well-written system prompts, well-designed eval packs, well-thought-through authority envelopes. Companies aur workers ke darmiyan relationships marketplace artifacts nahi hon ge; woh per-company audit trails rahen ge, jaisa rehna chahiye. AI-native economy woh hai jahan recipes freely trade hoti hain aur relationships privately held hoti hain. Course Seven marketplace question answer karne ki koshish nahi karta, lekin jo architectural foundation yeh lay karta hai (definition layer par portability, relationship layer par accountability) wahi question ko well-formed banati hai. Jo marketplace workers trade karne ki koshish kare (un ke envelopes, ledgers, aur approval histories intact rakh kar), woh aisi cheez trade karne ki koshish kare gi jise architecture deliberately non-tradable banati hai. Jo marketplace definitions trade karti hai woh boundary respect karti hai.

What Course Seven does establish is the architectural answer: portability operates at the definition layer, not the Worker layer. That distinction matters because it tells you what can be shared (recipes, evaluation rubrics, system prompts, environment configs, skill files) and what cannot (envelopes, budgets, audit trails, source-issue history, approval threads). The first list is the recipe you wrote. The second list is the story aap ki company has lived. Both are valuable; only one is portable.

Try with AI

In aap ka AI coding assistant, paste:

"Main apni Paperclip company se Legal Specialist Worker export karna chahta hoon taake partner company definition import kar sake. Field by field walk me through karein ke export mein kya contain hona chahiye aur kya scrub hona chahiye. Worker May 12 ko in properties ke saath hired hua tha: name='Legal Reviewer', role='general', adapter='claude_local' (Paperclip-native; har heartbeat par claude CLI headless spawn karta hai using an instructions file jo partner ko separately receive karni ho gi), capabilities='Reviews customer contract terms...', envelope including contract_interpret=allow jis ne hamara company envelope extend kiya, budget $800 per month, eval pack with 12 issues jo sab pass hue, 6 months of cost_events records, original hire ke gap-detection cluster se 23 source-issue links, Aug 28 ka 1 retirement record aur Oct 25 ka 1 resume record. Har property ke liye label karein EXPORT (partner ko travel karti hai) ya SCRUB (hamare paas rehti hai). Har labeling justify karein."

Jo aap seekh rahe hain: portability concrete hai, abstract nahi. Specific Worker ko field by field walk karna recipe-vs-relationship distinction ko real data par land karwata hai. Justifications reveal karein gi ke aap ki deployment mein boundary genuinely kahan chalti hai, aur kahan judgment calls hain (e.g., eval-pack run scores: kya woh reputation ke taur par travel karte hain, ya per-company audit ke taur par stay karte hain? Dono answers defensible hain; choice batati hai ke aap partner par kitna trust karte hain).

Bottom line: "Worker build karne ki instructions" companies ke darmiyan travel kar sakti hain: is ka naam kya hai, yeh kya karna jaanta hai, isay kaise test karna hai. Specific company par Worker ki actual history travel nahi kar sakti: use kaunsi permissions mili, kitna cost aaya, kaun se problems us ne actually solve kiye, kis ne approve kiya. Future marketplace instructions sell kar sakti hai; hires sell nahi kar sakti. Portable aur non-portable ke darmiyan line wohi hai jo "aap ka AI assistant kisi bhi company ke liye kya likh sakta hai" aur "aap ki specific company ne kya live kiya hai" ke darmiyan hai.

Concept 14: Talent ledger kyun matter karta hai: personnel change ke across institutional memory

Concept 12 introduced the talent ledger as a queryable record of the workforce's growth. Concept 14 closes the loop on what makes that ledger kaam ka at scale. Three properties worth naming:

Property 1: Yeh append-only hai. Activity log rows kabhi update ya delete nahi hoti. Jo hire reject hoti hai woh apni row ke taur par record hoti hai (Paperclip ka approval.rejected), delete nahi hoti. Jo envelope extension rollback hoti hai woh aik row ke baad doosri row ke taur par record hoti hai (curriculum ka envelope_extension phir envelope_narrowed), original row modify nahi hoti. Ledger permanent history hai, kisi bhi point in time par queryable. "July 12, 2026 ko workforce kaisi dikhti thi?" aik SQL query hai, archaeology project nahi.

Property 2: It's cross-correlated. Every row carries identifiers for the company, agent, the issue, the actor, and the approval where applicable. A single hire event in the ledger can be traced backward (which gap-detection records triggered it?) and forward (which issues did this Worker handle? which envelope-extensions were granted to support it? when was it retired?). The correlation IDs are what make multi-hop queries tez.

Property 3: It's the source of truth for institutional memory. When the human board turns over (a new board member joins, or the company is acquired) the talent ledger is how the new insan learn what the workforce has done. Without it, every transition is a re-discovery: who hired this Worker? Why? What's the rationale for this Worker's envelope? With it, every transition is a query: the ledger answers the question in seconds.

Yeh management plane ki sab se consequential property hai. Traditional company mein institutional memory insan ke heads mein rehti hai, aur insan chhor dein to kho jati hai. AI-native company mein institutional memory activity log mein rehti hai, aur har transition ke through preserve hoti hai. Course Six ne activity log ko queryable banaya. Course Seven usay workforce ke full lifecycle tak extend karta hai. Result: AI-native company apne insan ke liye traditional company se zyada legible hoti hai, kam nahi.

PRIMM: Predict

Suppose aap ki 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), aur order matter karta hai. (c) aap ko lifecycle picture deta hai (kaun around raha, kaun recently active hai). (b) cost-per-value picture deta hai (kya yeh Worker apne cost ke qabil hai?). (a) simple roster deta hai. New board pehle (c) se start kare ga taake samjhe kya exist karta hai, phir (b) run kare ga taake samjhe har aik ki value kya hai, aur (a) ko sirf navigation index ke taur par use kare ga. Talent ledger aik query nahi; queries ki family hai, aur "humein kya keep karna chahiye?" ka answer several queries saath run karne se emerge hota hai. Isi liye Concept 14 ledger ko correlated ke taur par emphasize karta hai: koi single query complete nahi; value queries ke across joining mein hai.

Bottom line: workforce ka har action aik aise log mein likha jata hai jise koi edit ya delete nahi kar sakta. Us log ki har row jaanti hai ke woh kaunsi doosri rows se related hai: kis Worker ne action kiya, kis issue ke liye kiya, kis approval ne authorize kiya. Jab naya human board join karta hai, woh kisi se nahi poochta "workforce kya karti rahi hai?" Woh log ke against kuch queries chalata hai aur minutes mein answer padh leta hai.

Concept 15: What's next: Invariant 2 and the Edge

Course Seven Invariant 6 (hiring as callable capability) close karta hai. Saat mein se chhe invariants ab track ke across depth mein taught hain. Remaining invariant Invariant 2 hai: Edge delegate.

Thesis ka Invariant 2 kehta hai: "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: user's browser, a developer's terminal, a customer's region." OpenClaw reference implementation hai, bilkul jis tarah Inngest Invariant 7 ke liye aur Paperclip Invariants 3 aur 6 ke liye tha.

Course Eight OpenClaw ko end-to-end cover kare ga, jaise Courses Five aur Six ne Inngest aur Paperclip cover kiye, lekin Course Seven ke baad thesis-level work finished hai. Remaining work operational depth hai, architectural foundation nahi.

Kuch questions jo Course Eight ko answer karne hon ge aur Course Seven ne nahi kiye:

• Edge vs cloud: Worker ko edge par kab hona chahiye? US-East se US customers handle karne wale Tier-1 Support Worker ko edge proximity ki zarurat nahi. Customer-facing Worker jo customer ke browser ke andar run karta hai (real-time, sub-200ms response), usay hoti hai. Decision criteria substrate selection se different hain (Course Seven Concept 6).
• Edge authority: kya edge Worker ke paas cloud Worker jaisa same envelope hota hai? Likely nahi. Edge workers ke envelopes usually tighter hotay hain kyun ke woh potentially-hostile inputs ke zyada qareeb run karte hain. Cascade ko new layer milti hai.
• Edge-to-cloud handoff: edge Worker cloud Worker ko kab escalate karta hai? Same approval primitive apply hona chahiye, lekin latency budgets different hain. Refund ke liye 30-second approval round-trip fine hai; mid-conversation edge Worker ke liye yeh UX failure hai.

Course Eight Course Six customer-support workforce ko edge component ke saath build kare ga: customer apne browser mein OpenClaw bot se baat karta hai; OpenClaw bot contract questions Legal Specialist ko delegate karta hai (wahi Worker jo Course Seven ki lab mein hire hua); Legal Specialist ka response OpenClaw ke through customer ko wapas flow karta hai. Same workforce, teen new architectural layers: edge runtime, edge-to-cloud handoff, edge authority.

Course Eight ke baad saare seven invariants taught hon ge. Track complete hai; thesis operationalized hai.

Bottom line: Course Seven Invariant 6 close karta hai (hiring as callable). Seven mein se six invariants ab done hain. Course Eight last one cover karta hai (OpenClaw ke zariye Edge delegate) aur track complete ho jata hai.

---

How to actually get good at this

Course Seven padhne se aap AI workers hire karne mein achhe nahi bante. Isay run karne se bante hain, aur path kuch yun dikhta hai:

Aap aik hire se start karte hain: Part 4 ka Legal Specialist. Har Decision par friction mehsoos hoti hai: gap-detection rule jo bohat zyada fire karta hai (ya enough nahi), proposal jisme board ke wanted fields missing hain, eval pack jiske reference answers woh boundary catch nahi karte jo Worker actually violate karta hai, substrate choice jo week two mein wrong nikalti hai. Friction ka har piece upar ke fifteen concepts mein se aik se map hota hai:

• "Manager-Agent ne aik email ke baad gap flag kar diya": Concept 2 ki signal thresholds tune karein; one-off cases gaps nahi.
• "Board ne budget detail maangi jo meri proposal mein included nahi thi": Concept 4 ke budgetEstimate field ko enrich karein.
• "Eval pack pass hua lekin Worker ne week one mein authority hallucinate ki": Concept 5 ki boundary-respect dimension strengthen karein.
• "Worker managed-cloud substrate par session-hour fees pay kar raha hai lekin sirf 30-second classification tasks handle karta hai": Concept 6 ka substrate decision revisit karein; short, simple work ke liye Paperclip-native local adapter ya process right fit hai.
• "Board ne hire approve ki lekin envelope extension notice nahi ki": Concept 8 ke novelty checks ko proposal rendering mein zyada prominent banayein.
• "Worker 2 weeks se on-standby hai lekin Paperclip UI retirement decision rationale nahi dikhata": Concept 11 ka retirement flow revisit karein.

Har problem ka response tab build karein jab woh samne aaye, pehle nahi. Aap ka generateHireProposal function takreeban 30 lines se start ho ga aur chhe mahine mein 150 lines tak grow kare ga; har naya field kisi specific decision se earn ho ga jo board ne visible karne ko kaha. Aap ka eval-pack reference rubric teen dimensions se start ho ga aur seven tak grow kare ga. Aap ki auto-approval policy library pehle month empty ho gi, phir aik policy ho gi, phir five.

Hiring proficiency ka 80/20 fifteen concepts memorize karna nahi. Yeh itni tez notice karna hai ke given problem kis Concept se belong karti hai ke aap right Concept tak pohanch jaen. Wahi noticing skill hai, aur woh sirf real work par loop run karne se aati hai.

The portability dividend (continued from Course Six). Once you've built that noticing for one company, it transfers. The friction-to-Concept map above is identical whether you're hiring a Legal Specialist for a SaaS company or a Burst-Capacity Tier-1 for a content platform. The decisions look different; the shape of the decisions is the same. Pick a company to start, learn its specific patterns, and the moment you launch a second company (or aap ka first company is acquired and you onboard into a new one), aap ka hiring instincts come with you. The companies change. The hiring loop doesn't.

Start with one role. Use the full approval flow for every hire in aap ka first month. Watch the talent ledger. The rest builds itself.

---

Quick reference

The 15 concepts in one line each

1. Jo workforce khud grow nahi kar sakti woh fixed company hai. Hiring callable hai; alternative board-as-queue hai.
2. Capability gaps teen signals se fire hotay hain. Low confidence, repeated escalations, no-eligible-Worker. 14 days mein two-of-three gap hai.
3. Capability gaps par four-way fork. Hire (durable, high-volume, narrow), escalate (consequential ya rare), queue (transient), decline (off-mission).
4. Job description candidate hai. Production payload: name, role, title, icon, reportsTo, capabilities, adapterType, adapterConfig, runtimeConfig, sourceIssueId, plus budget.
5. Approval se pehle eval pack. Kam az kam 12 representative test issues; rubric scoring; cost bounded; pass ke liye 80% issues ke across har dimension par at least 2 out of 3.
6. Substrate selection: teen Paperclip-native paths aur do HTTP-adapter alternatives. claude_local (Paperclip claude CLI spawn karta hai; worked example), opencode_local (multi-provider via provider/model; worked example), process (deterministic, cheapest; no AI). Plus Agent SDK over http (aap loop host karte hain) aur CMA over http (durable cloud sessions, session-hour billing).
7. Hiring Course Six ka approval gate reuse karti hai. Same primitive; richer payload (proposal, eval, envelope, budget).
8. Authority envelope inherit, narrow, aur (rarely) extend hota hai. Novel-authority hires envelope-extension checks trigger karti hain; board ko consciously surface area expand karna decide karna hota hai.
9. Defined class ke liye auto-approval policy. Pre-approved envelope ceilings, capped concurrency/rate, daily audited, mandatory expiry, company envelope kabhi extend nahi kar sakti.
10. First heartbeat sab se cheap debugging window hai. System-prompt issues, envelope miscalibrations, aur substrate mismatches sab pehle 24 hours mein surface hote hain.
11. Lifecycle states. Verified Paperclip states are pending_approval, idle, terminated; curriculum labels "running" and "paused" cover the gaps. Rehire is fast than fresh hire; termination is irreversible.
12. Talent ledger queryable institutional memory hai. Paanch canonical queries roles-needed, costs-over-time, hire-duration, envelope-history, rehire-ratio answer karti hain.
13. Agent portability definition layer par operate karti hai. Recipes travel karti hain; envelopes, budgets, aur ledgers nahi. "Service-to-a-company" hi hiring ka meaning hai.
14. The activity log is append-only and cross-correlated. Permanent history; queryable at any point in time; the source of truth for institutional memory when insan turn over.
15. Agla Invariant 2 hai: Edge. OpenClaw, edge-to-cloud handoff, edge-tighter envelopes. Course Eight seven-invariant arc complete karta hai.

API quick-ref (verified May 2026)

Want to...	Endpoint	Method
Submit a hire	/api/companies/{companyId}/agent-hires	POST
Check identity/permissions	/api/agents/me	GET
List adapter docs	/llms/agent-configuration.txt	GET
Get adapter-specific docs	/llms/agent-configuration/{adapter}.txt	GET
List existing agent configurations	/api/companies/{companyId}/agent-configurations	GET
List allowed icons	/llms/agent-icons.txt	GET
Read an approval	/api/approvals/{approvalId}	GET
Comment on an approval thread	/api/approvals/{approvalId}/comments	POST
Link approval to source issue	/api/issues/{issueId}/approvals	POST
List issues linked to an approval	/api/approvals/{approvalId}/issues	GET
Request revision on a pending approval	/api/approvals/{approvalId}/request-revision	POST
Resubmit a revised approval	/api/approvals/{approvalId}/resubmit	POST
Assign an issue to a Worker	/api/issues/{issueId} with { assigneeAgentId }	PATCH
Pause / resume / terminate a Worker	(consult current API ref)	(varies; see note below)

Upar table ke endpoints Paperclip ki paperclip-create-agent skill ke against verified hain (skills/paperclip-create-agent/SKILL.md aur us ka api-reference.md, jo canonical sources hain). Workers run karne ke liye Paperclip ke documented operational primitives Pause, Resume, Override, Reassign, Terminate hain; in primitives ke exact endpoint paths version ke mutabiq vary kar sakte hain, is liye aap ki deployment ki current API surface ke liye GET /llms/agent-configuration.txt consult karein. Course ka Decision 7 same caveat ke saath pause/resume code inline include karta hai. Sab requests Authorization: Bearer $PAPERCLIP_API_KEY carry karti hain. Mutating requests Content-Type: application/json carry karti hain.

CMA quick-ref (verified May 2026)

Want to...	SDK call	Notes
Create agent	cma.beta.agents.create	Pass model (a bare string), system, tools
Create an environment	cma.beta.environments.create	Pass name and a config object (type, packages, networking)
Create a session	cma.beta.sessions.create	Pass agent (not agent_id) and environment_id
Send an event	cma.beta.sessions.events.send	Push a user.message event into the session
Stream results	cma.beta.sessions.events.stream	SSE stream of the session's events

CMA beta API hai aur yeh shapes releases ke darmiyan shift hoti hain; live docs ko authoritative samjhein. Sab requests beta header managed-agents-2026-04-01 carry karti hain (SDK isay set karta hai). CMA session inbound URL se nahi, aap ke bheje hue events se driven hota hai: Paperclip integration ke liye is ka matlab kya hai, Concept 6 ka sidebar dekhein. Pricing: standard Claude API tokens plus active execution ke liye per-session-hour runtime charge (current rate ke liye Anthropic pricing page dekhein). Reference: platform.claude.com/docs/managed-agents.

When something feels wrong in 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).

---

The architect's framing sentence: verbatim

Course usi tarah close hota hai jaisay open hua tha, framing sentence ke saath:

"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 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."

Is sentence ko yaad kar lein. Architecture isi se follow karti hai.

---

Course Seven of agentic-coding track. Six of seven invariants are now closed: the management plane (Course Six), the nervous system (Course Five), system of record and skills (Course Four), agent loop (Course Three), the human as principal (courses Five and Six), and now the hiring API (Course Seven). The remaining invariant, the Edge delegate via OpenClaw, is Course Eight.

---

Flashcards Study Aid