Skip to main content

Human-Agent Teams: आपकी Workforce का Operating Model

यह course AI workers की उस team का operating model है जो लोगों के साथ चलती है। इसकी basic unit एक भरोसेमंद worker है, यानी Digital FTE: वह loop run करता है, searchable memory से काम करता है, अपनी identity से sign in करता है, और edges पर escalate करता है। इस track में आप वह worker बनाते हैं; यह operating model पहले paper पर लिख सकते हैं, फिर जब live workers online आएँ तो इसे उनसे wire कर सकते हैं। एक भरोसेमंद worker unit है। ऐसे workers की team चलाना, एक worker बनाने से अलग skill है, और यह course वही है: एक को कई में बदलना।

कई workers की team, एक worker का बड़ा version नहीं होती। वह अलग चीज़ है, और उसे अलग skill चाहिए: worker बनाना नहीं, बल्कि उन workers की team को लोगों के साथ चलाना

यह course वही operating model है। इसके बाद के चार courses machinery हैं: board hire करने वाला lead agent (Workforce with Paperclip), खुद grow होने वाली workforce (Self-Expanding Workforce), delegated approval (Identic AI), और earn करने वाले workers (Payment-Enabled Agents)। यह machinery उस team पर काम नहीं करती जिसे चलाना आपने सीखा ही न हो। इसलिए workforce automate करने से पहले आप set करते हैं कि humans और workers एक roster, एक workspace, और एक goal कैसे share करेंगे

इस course के shift का diagram। Left side पर "single-player": एक human, एक chat window, एक task पर एक agent के साथ काम कर रहा है। Right side पर "multiplayer": कई humans और कई agents एक workspace, एक roster, और एक north-star goal share कर रहे हैं, हर member से shared goal की तरफ arrows हैं। Caption कहता है: unit एक worker था; team humans और Digital FTEs हैं जो साथ खींचते हैं।

यह किस तरह का course है, इस पर एक note। बाकी workforce courses build-along हैं। यह नहीं। यहाँ आप बहुत कम code लिखेंगे। आप operating documents लिखेंगे (roster, role cards, north star, verification rubric), वैसे जैसे manager लिखता है, बस आपका agent draft करेगा और decision आप लेंगे। Deliverables वे agreements हैं जिन पर team चलती है। ये code से कम glamorous हैं और ज़्यादा निर्णायक: ज़्यादातर human-agent teams technology पर नहीं, practices पर fail होती हैं।

यह section का सबसे accessible course भी है। Roles, goals, trust, और कौन-किस-चीज़-का-owner-है, ये वे बातें हैं जिन्हें आप लोगों के साथ काम करके पहले से समझते हैं। Agents इन fundamentals को नहीं बदलते। वे इन्हें सही करने की stakes बढ़ा देते हैं।

ये practices कहाँ से आती हैं

यहाँ के patterns Anthropic के अपने human-agent teams चलाने के account से लिए गए हैं, और इस book के पहले से बने frameworks पर map किए गए हैं (पूरे links अंत में Sources में हैं)। जहाँ Anthropic कोई specific result report करता है, वह उनका है और उनके नाम से दिया गया है। जिन features पर यह lean करता है (shared team tools में काम करने वाले agents, अपनी credentials और memory वाले agents), वही capabilities आप इस track में बनाते हैं।

📚 Teaching Aid

Open Full Slideshow

Full presentation देखें — Human-Agent Teams

आप क्या बनाएँगे (artifact set)

App नहीं: operating documents का set जिस पर आपकी team चलती है। Starter आपको हर document template के रूप में देता है; आप इन्हें अपने agent की मदद से fill करते हैं।

  • एक team roster: हर member, human और agent, role, owner, tools, और autonomy level के साथ।
  • हर agent के लिए एक role card: वह क्या owns करता है, क्या नहीं करता, उसकी tools, उसका work कैसे checked होता है, और वह कब escalate करता है।
  • एक working agreement: default public क्या है, कुछ security boundaries क्या हैं, क्या private रहता है।
  • एक north-star doc: team का एक ambitious goal, और कौन से agents बिना prompt के उस पर act कर सकते हैं।
  • एक verification rubric: work product कैसे grade होता है, ताकि human के हर line पढ़े बिना उस पर trust किया जा सके।
  • एक doer-verifier setup: दूसरा agent जिसका केवल एक काम है: पहले agent को check करना।
  • एक weekly report: "lessons and missteps" log जो team को improve करता है।
  • एक attention budget: आप क्या review करेंगे, क्या batched होगा, और आपके पास पहुँचने वाली चीज़ों की cap।

Setup

  1. Starter download करें (human-agent-teams-starter.zip) और unzip करें। यह templates का folder है, code नहीं। इन्हें किसी भी editor में खोलें।
  2. Ideally, एक Digital FTE (Building a Digital FTE) हो जिसके around आप real team run कर सकें। अभी worker नहीं? ठीक है: यह course planning mode में करें (नीचे note), फिर manual को live worker से wire करें जब वह exist करे।
  3. ऐसी जगह हो जहाँ work team को visible हो: shared channel, doc library, repository। Agents वही पढ़ते हैं जो वहाँ लिखा है।
  4. अपने agent को draft करने के लिए ready रखें (claude.ai, Cowork, या आपका worker)। Starter का हर artifact इसी rhythm से fill होता है: आप direct करते हैं, agent draft करता है, आप decide करते हैं।

यहाँ से हर Part एक practice सिखाता है, फिर आपसे वह document लिखवाता है जो practice को जगह देता है। आपको theory पर quiz नहीं देना; आप एक team का operating manual लेकर निकलेंगे।

Readiness check (Part 2 से पहले करें)

यह course assume करता है कि आपका worker पहले से आपकी team का written record पढ़ सकता है। अभी test करें: अपने agent से कहें कि पिछले week का कोई decision या document ढूँढे, ऐसे channel में जिसे वह own नहीं करता। अगर कर सकता है, आप ready हैं। अगर खाली लौटे, तो आपने AI Searchable Context वाला searchable system of record अभी पूरा नहीं किया। पहले वह करें। उसके बिना यहाँ की हर practice के पास पढ़ने के लिए कुछ नहीं।

अभी वहाँ तक नहीं पहुँचे? इसे planning mode में run करें

Technical stack से पहले भी आप यह पूरा course कर सकते हैं: claude.ai या Cowork को drafting agent बनाएं, सारे operating documents लिखें, और हर agent role को "active" की जगह "planned" mark करें। आप paper पर complete operating manual लेकर निकलेंगे। जब पहले workers बन जाएँ, वापस आकर planned roles को live roles से swap करें।


Part 1: एक worker से team तक

Concept 1: Single-player खत्म हो चुका है

AI के साथ काम पहले single-player था: एक person, एक chat window, एक task। Digital FTE इससे पहले ही ज़्यादा करता है। इस course का shift multiplayer है: कई लोग और कई agents एक workspace में, shared goals की तरफ खींचते हुए। Humans strategy set करते हैं; agents execute करते हैं।

Multiplayer agent वह है जो एक साथ कई humans के साथ काम करता है। Digital FTE की तरह उसकी अपनी memory और skills होती हैं। Chat window से अलग, उसके पास अपनी credentials होती हैं (किसी person से borrowed नहीं), और वह जहाँ work होता है वहीं रहता है: team के channels और docs में, private session में नहीं।

Unit Digital FTE है। Team humans और Digital FTEs का shared roster है। Team ही business है।

Concept 2: Worker को किन parts की ज़रूरत होती है

Team तब तक काम नहीं करती जब तक हर agent के पास तीन चीज़ें न हों, और यह track तीनों बनाता है:

  • Persistent memory: ताकि वह goal को कई दिनों तक hold करे, सिर्फ़ एक prompt तक नहीं (AI Searchable Context)।
  • अपनी identity: credentials जो human से tied न हों, ताकि वह किसी के logins borrow करने की जगह आप के set किए guardrails के अंदर act करे (AI Identity)।
  • Broad, searchable access: ताकि वह लिखी हुई चीज़ों से सीखे कि organisation कैसे काम करती है (आपका Postgres system of record और RAG: retrieval, वह searchable memory जो आपने उसे दी)।

इनके बिना, "team में agent add करना" का मतलब है कोई person अपना password एक script से share कर रहा है। इनके साथ, इसका मतलब है roster का हिस्सा बनने वाला worker। आप operating model अभी design कर सकते हैं और जैसे ही ये तीन parts live हों, इसे live workers से wire कर सकते हैं; human practices दोनों cases में ऊपर बैठती हैं।

Checkpoint: आप unit जानते हैं। Memory, identity, और access वाला worker ही वह चीज़ है जिससे team बनती है। अब आप ऐसे कई workers को लोगों के साथ काम करवाते हैं।

Concept 3: Scarce resource human judgment है

पूरा operating model एक चीज़ protect करता है: human attention और judgment। Agents तेज़ और बहुत हैं; लोग bottleneck और authority हैं। इस course की हर practice humans को वही decisions करवाने के लिए है जो सिर्फ़ humans को करने चाहिए, और बाकी सब से बाहर रखने के लिए।

Failure mode का नाम पहले रखें, क्योंकि यह common है। Operating model के बिना लोग side में personal AIs की fleets चलाते हैं। Work duplicate होता है। Team का context private windows में टूट जाता है जिन्हें कोई और, human या agent, नहीं देख सकता। जिस metric की सबको ज़रूरत है वह पाँच तरीकों से compute होती है। Fix ज़्यादा agents नहीं; fix है एक team को open में run करना

Course का बाकी हिस्सा चार practices है जो यही करती हैं।

Operating model को चार practices की तरह दिखाया गया है, चार cards में। Card 1, "Work in the open": context कुछ clear boundaries के अंदर हर teammate तक flow करता है। Card 2, "One roster, clear roles": हर member, human और agent, सही tools के साथ named job own करता है। Card 3, "A north star": एक ambitious goal जिसे humans set करते हैं, और जो agents को बताता है कौन सा work करने लायक है। Card 4, "Trust, earned": autonomy proven reliability के साथ बढ़ती है, और हर work checkable है। नीचे band कहता है: हर practice एक चीज़ protect करती है — human judgment।

Checkpoint: आप shape जानते हैं। चार practices, एक purpose। अब पहली practice।


Part 2: Open में काम करें

Concept 4: अगर लिखा नहीं, तो वह exist नहीं करता

Agent अपनी understanding पूरी तरह उन चीज़ों से बनाता है जिन्हें team searchable बनाती है: channels, code, docs, notes। Private messages, hallway conversations, और restricted files उस तक नहीं पहुँचते। Agent के लिए unwritten invisible है।

इसलिए पहली practice technical होने से पहले cultural है: public में काम करें। Decisions channels और docs में land करते हैं, direct messages और बिना notes वाली meetings में नहीं। Artifacts ऐसे लिखें कि agent उन्हें find कर सके: agent अब आपकी documentation का primary reader है, afterthought नहीं।

Payoff real है, और Anthropic इसे साफ़ report करता है। जो agent team के decisions पढ़ सकता है, वह वह work pitch नहीं करेगा जिसे आप पहले kill कर चुके हैं। जो दूसरी team के specs पढ़ सकता है, वह काम कर चुका pattern reuse करेगा। और क्योंकि agent किसी भी human से बहुत तेज़ पढ़ता है, वह अक्सर relevant work surface करता है जो लोग miss कर देते। Transparency virtue से leverage बन जाती है।

Concept 5: Boundaries workspace पर, document पर नहीं

Agent क्या देख सकता है, यह decide करने का गलत तरीका है: हर document और हर channel को अलग-अलग देखना। यह humans और agents दोनों के लिए decision fatigue है: क्या यह private हो? क्या मैं वह doc share कर सकता हूँ? क्या यह agent उस thread में allowed है? Soft, per-item lines थकाने वाली होती हैं और उन्हें गलत करना आसान है।

सही तरीका: कुछ clear security boundaries जो workspace level पर draw हों: security boundary बस information के set के चारों ओर wall है, और यह rule है कि अंदर कौन है। Boundary के अंदर context हर teammate, human या AI, तक flow करता है। Clear lines की छोटी संख्या soft lines की बड़ी संख्या से बेहतर है, और यह रोज़ का "क्या मैं यह share कर सकता हूँ?" tax हटाती है।

यहीं आपका system of record अपनी जगह कमाता है। Boundary wall है; AI Searchable Context का searchable store वह चीज़ है जो उसके अंदर freely flow करती है। Wall एक बार draw करें; retrieval को बाकी काम करने दें।

Exception साफ़ कहें, क्योंकि public-by-default का मतलब everything-is-public नहीं। कुछ work sensitive होता है और एक human और एक agent के बीच रहना चाहिए। वह agent को direct message है, या private apps (claude.ai, Cowork) आपके personal connectors पर, जहाँ conversation private रहती है। Default open रखें; जो सच में private रहना चाहिए उसके लिए clear, narrow lane रखें।

Draft it. 01-working-agreement.md खोलें और अपने agent में paste करें:

Draft a working agreement for my team. State what is public by default. List the few security boundaries we need (no more than a handful) and who is inside each. List what stays private (one human, one agent). For each boundary, write one sentence a new teammate could follow.

Check it. क्या आप हर boundary को एक single sentence में state कर सकते हैं? अगर नहीं, boundaries ज़्यादा हैं। Few and clear, वरना यह टिकेगा नहीं।

Checkpoint: context flow करता है। आपकी team वहाँ काम करती है जहाँ agents पढ़ सकते हैं, कुछ ऐसी walls के पीछे जिनका नाम कोई भी ले सकता है। अब work को names दें।


Part 3: एक roster, clear roles

Concept 6: Team का roster होता है

Human-agent team एक roster, एक artifact set, और एक working space share करती है। इसलिए roster लिखें: हर member, human और agent, और हर एक क्या own करता है।

Agents different roles रखते हैं। एक data analysis own करता है; एक design standard hold और enforce करता है; एक research synthesis चलाता है। जब project शुरू होता है, humans agents से बात करते हैं कि कौन से roles assign करने हैं और वे साथ कैसे काम करेंगे: roster उस conversation का output है, पहले से लगाया गया guess नहीं।

यह आपकी Roles Taxonomy और Digital FTE taxonomy है, एक team के लिए concrete बनी हुई। Catalog बताता है कि कौन से types के workers exist कर सकते हैं; roster बताता है कि इस team पर कौन हैं और कौन क्या own करता है।

Concept 7: Role एक card भी है, और skill file भी

हर agent को एक role card मिलती है: वह क्या owns करता है, क्या नहीं owns करता, उसे कौन से tools और access चाहिए, उसका work कैसे checked होता है, और वह कब human को escalate करता है। Scope "does not own" के बारे में उतना ही है जितना "owns" के बारे में: fuzzy edges वाला agent दूसरे लोगों के work में drift करता है।

Tools का नाम लिखें, क्योंकि उनके बिना role सिर्फ़ बिना हाथ वाला title है। Analyst को database चाहिए। QA agent को browser tool चाहिए। हर role के access list करें, और सिर्फ़ वही grant करें (least privilege वही rule है जो delegated approval में फिर मिलेगा)।

फिर role को skill file के रूप में लिखें। यही move book के frameworks को click करवाता है: agent का role skill में define करें, और role portable बन जाता है: org में कोई भी उससे same type का दूसरा agent stand up कर सकता है। Roles org chart के boxes रहना बंद कर देते हैं और copy की जा सकने वाली skills बन जाते हैं। (Skills इस पूरी book का portable lever हैं; role एक और चीज़ है जिसे skill carry कर सकती है।)

Human-only roles explicit रखें। Humans उन्हीं threads में काम करते हैं जहाँ agents करते हैं, लेकिन वे roles humans के पास रहते हैं जो सिर्फ़ humans रख सकते हैं: consequential calls, cost वाला judgment। Roster से आप human judgment को उन decisions पर रखते हैं जहाँ ज़रूरत है और उनसे हटाते हैं जहाँ ज़रूरत नहीं।

जब agent को दूसरे agent की ज़रूरत हो

कभी job एक worker के लिए बहुत बड़ी होती है, और lead agent sub-task के लिए सही context वाले teammates spawn करता है: यहाँ researcher, वहाँ reviewer। यह instinct सही है, और next course इसे automate करता है: Workforce with Paperclip "lead hires a board" को budgets और approvals के अंदर managed workforce बना देता है। आपका roster और role cards उसके inputs हैं। यहाँ आप roles हाथ से लिखते हैं ताकि समझ सकें कि Paperclip बाद में आपके लिए क्या करेगा।

Underlying feature पर mid-2026 तक दो honest notes: Claude Code agent teams experimental हैं और default से disabled हैं (आप setting से on करते हैं), और सिर्फ़ lead teammates spawn करता है; teammates अपने nested agents नहीं बना सकते। इसलिए "agents spinning up agents" असल में "lead flat team spawn करता है" है। इसे early मानें, और production में lean करने से पहले current docs पढ़ें।

Draft it. 02-roster.md और 03-role-cards/role-card.template.md की copy खोलें और paste करें:

Draft a team roster for [team]. List every member, human and agent. For each: role, who owns it, the tools and access it needs, and its autonomy level. Mark the roles only a human should hold. Then write a full role card for [my worker]: owns, does NOT own, tools/access, how its work is verified, and what triggers an escalation to a human.

Check it. हर member का owner और "does not own" है। हर agent के पास tools और एक clear escalation trigger है। अगर दो members same task claim कर सकते हैं, scopes अभी sharp नहीं हैं।

Checkpoint: हर किसी का lane है। Humans और agents एक roster पर, हर एक named job own करता है और उसके tools रखता है। अब team को direction दें।


Part 4: North star

Concept 8: ऐसा goal जो agent को proactive बनाता है

Context और roles agent से वह work करवाते हैं जो आप assign करते हैं। North star उससे सही work propose करवाती है। North star एक ambitious, wide-reaching goal है जो team को बताता है कि कौन से tasks और workstreams करने लायक हैं: वह एक sentence जिसके against बाकी सब measure होता है। Humans इसे हमेशा set करते हैं, business mission में grounded।

जब यह लिख दिया जाए, आप इसे team के agents के साथ share करते हैं। फिर (और यही part लोग skip करते हैं) आप नाम लेकर बताते हैं कि कौन से agents बिना prompt के इस पर act कर सकते हैं। हर agent को work propose नहीं करना चाहिए। सिर्फ़ वे agents जिनके पास skills और earned trust है।

Anthropic की example छोटी और exact है: एक team जिसकी north star थी "product onboarding को ज़्यादा helpful बनाना" उसके agent ने proactively onboarding error messages rewrite करने की recommendation दी: ऐसी changes जिनसे अगले week onboarding success measurably बढ़ी। Agent ने पूछे जाने का wait नहीं किया। North star ने उसे बताया कि rewrite on-mission है।

यह आपकी AI-Native Company mission है, एक team तक push down हुई। Company की mission है; team की north star है जो उसे serve करती है; agent का work है जो north star को serve करता है। Line goal से task तक सीधी चलती है।

Concept 9: Proactivity वह privilege है जो आप grant करते हैं

Proactive agent का risk यह है कि agent वह work propose करे जिसे उसे touch नहीं करना चाहिए। इसलिए proactivity named होती है, assumed नहीं। आप कहते हैं कौन से agents workstreams suggest कर सकते हैं, और north star वह test है जो हर proposal को pass करना होता है। जिस agent के पास यह grant नहीं, वह फिर भी अपना assigned job करता है: बस freelance नहीं करता।

Draft it. 04-north-star.md खोलें और paste करें:

Help me write a north star for [team]. It should be one ambitious goal, grounded in our mission. State why it matters. Name which agents on the roster may propose new work against it, and the guardrails on those proposals. Write it so an agent, given only this doc, could judge whether a new idea is on-mission.

Check it. इसे named agent की नज़र से पढ़ें। सिर्फ़ इस doc से क्या वह on-mission idea को off-mission idea से अलग कर सकता है? अगर नहीं, star steering के लिए बहुत vague है।

Checkpoint: team के पास direction है। एक goal, humans के set करने के लिए, और कुछ named agents जिन्हें इसे chase करने की अनुमति है। अब decide करें कि आप उन्हें कितना run करने देते हैं।


Part 5: Trust, earned

Concept 10: Autonomy reliability के साथ बढ़ती है

आप नए colleague को पहले दिन keys नहीं देते। आप agent को भी पहले दिन 500 bug fixes नहीं देते। Anthropic के engineers वहाँ तक पहुँचे (agents hundreds of fixes अपने आप handle करने लगे), लेकिन शुरुआत वहाँ से नहीं हुई। Autonomy demonstrated reliability के proportion में grant करें, फिर हर task type के लिए deliberately widen करें।

Task को अच्छी तरह करने का tacit knowledge externalise करने के लिए feedback cycles लगते हैं: नए human के लिए भी, agent के लिए भी। और models बदलें तो retest करें: weaker model को help करने वाली guardrail stronger model को shackle कर सकती है, और model improve होने पर prompt को reword करना पड़ सकता है। Trust एक बार set नहीं होता; tune होता है।

Trust ladder, चार ऊपर चढ़ते steps के साथ जिनके labels autonomy level हैं। L1 "Review everything": human agent के हर decision को check करता है। L2 "Verify the work": rubric या second agent output को human से पहले check करता है। L3 "Batch the escalations": agent सिर्फ़ consequential calls को grouped form में surface करता है। L4 "Earned autonomy": agent task type को अपने approved scope के अंदर खुद run करता है, repeated wins के बाद scope widen होता है। Steps के नीचे L0 का मतलब draft only है — human work करता है। Steps के ऊपर arrow का label "demonstrated reliability" है; side note कहता है "per task type widen करें, सब एक साथ नहीं।"

Ladder को operational बनाने के लिए fixed rungs दें। Roster में autonomy level हर agent per task type set करें, पूरे agent के लिए एक level नहीं:

LevelWhat the agent doesWhere the human is
L0Drafts only; the human does the workhuman does everything
L1Acts, but a human reviews every outputhuman reviews all
L2Acts; a verifier checks; human reviews only exceptionshuman reviews exceptions
L3Acts within limits; batches escalations to the humanhuman reviews batched escalations
L4Runs the task type on its own, within approved scopehuman reviews the weekly report

नया agent किसी task type पर L1 से शुरू करता है और repeated, verified wins के बाद ऊपर जाता है। वही agent एक task type पर L4 और दूसरे पर L1 हो सकता है: autonomy worker-on-a-job को grant होती है, worker को generally नहीं।

Concept 11: Work को checkable बनाएँ

जो चीज़ autonomy को safely grow करने देती है वह यह है: work human के देखने से पहले verify हो सकता है। Code के पास tests होते हैं, ज़ाहिर है। लेकिन ज़्यादातर दूसरा work भी grade हो सकता है: document rubric और style guide के against, report checklist के against। जब आप bar set करते हैं और हर assignment को vettable बनाते हैं, quality high रहती है और आपके intended direction से drift नहीं करती।

यह team level पर Eval-Driven Development है (Eval-Driven Development)। वहाँ eval worker को automatically grade करता है। यहाँ rubric वही eval है जो एक worker के output पर apply होता है: वही idea, checklist के रूप में जिसे teammate run कर सकता है।

फिर doer-verifier: एक agent task करता है, second agent का सिर्फ़ एक काम होता है उसे check करना। (Anthropic इसे doer-verifier harness कहता है।) यह cheap insurance है, और human time बचाने के लिए agent time spend करता है: verifier drift को आपकी scarce attention spend होने से पहले पकड़ लेता है।

Draft it. 05-verification-rubric.md और 06-doer-verifier.md खोलें और paste करें:

Write a verification rubric for [my worker]'s main output: the concrete checks that decide whether the work is good enough to ship, in plain pass/fail terms. Then describe a doer-verifier setup: a second agent whose only job is to grade the first's output against this rubric and return pass/fail with reasons.

Check it. क्या second agent सिर्फ़ इस rubric से first agent का work grade कर सकता है, और क्या आप उस pass पर trust करेंगे? अगर "pass" के बाद भी आप हर line पढ़ना चाहते हैं, rubric specific नहीं है।

Concept 12: Human attention को money की तरह spend करें

Agents independent होने के बाद नया failure mode आता है: humans output में डूब जाते हैं। इसलिए human attention को scarce resource मानें। Best teams अपने agents से questions batch करवाती हैं एक single pass में, key context repeat करवाती हैं ताकि human जल्दी up to speed हो, और items की संख्या limit करती हैं जो human एक बार में देखता है।

कुछ teams एक agent को सिर्फ़ यह काम देती हैं कि humans तक क्या elevate करना है। कुछ cap लगाती हैं कि agent हर दिन कितना work करे: उसे slow करने के लिए नहीं, बल्कि इसलिए कि humans अब भी work के साथ meaningfully engage कर सकें और उन skills को बनाए रखें जो उनके लिए important हैं।

Cycle में reflection build करें। Team से weekly "lessons and missteps" report माँगें, ताकि mistakes track हों और repeat होना बंद करें। Track करें कि हर agent ने किन task types पर autonomy earn की है, और scope सिर्फ़ repeated wins के बाद widen करें। Report से team luck की जगह purpose से better होती है।

Draft it. 07-weekly-report.md और 08-attention-budget.md खोलें और paste करें:

Draft a weekly team report template that captures, for each agent: what it shipped, its lessons and missteps this week, and which task types it has earned more autonomy on. Then propose an attention budget for me: what I will review, what gets batched, and the cap on how much reaches me at once.

Check it. Busy week में क्या यह human को important चीज़ों का decision करने देता है, और nothing else? अगर human को अब भी सब पढ़ना पड़ता है, budget scarce resource protect नहीं कर रहा।

Checkpoint: trust switch नहीं, dial है। Work checkable है, autonomy proof के साथ widen होती है, और human attention वहाँ spend होती है जहाँ वह count करती है। आपके पास पूरा operating model है।


Part 6: अपनी team खड़ी करें

आपने चार practices सीखी हैं और हर एक के लिए document draft किया है। अब इन्हें एक team के operating manual में assemble करें।

Operating manual: एक folder, आठ files

Manual एक folder है, उस order में numbered जिसमें आप इसे fill करते हैं। Starter exactly यह ship करता है:

human-agent-team/
01-working-agreement.md few clear boundaries · what's public · what's private
02-roster.md every member · owner · tools · autonomy level (L0–L4)
03-role-cards/ one card per agent (copy the template)
role-card.template.md
reconciler.md (filled example)
04-north-star.md the one goal · which agents may act on it unprompted
05-verification-rubric.md the pass/fail checks a verifier can apply
06-doer-verifier.md which agent checks which, and what happens on fail
07-weekly-report.md shipped · lessons & missteps · autonomy changes
08-attention-budget.md what you review · what's batched · the cap

हर file की छोटी required checklist होती है (template में भी, और हर Part के end पर "Check it" के रूप में repeat भी)। File तब तक done नहीं जब तक उसकी checklist all yes न हो। Manual तब तक done नहीं जब तक सभी आठ done न हों।

इसे order में fill करें

Order dependency order है। चार practices पाँच fill-steps में map होती हैं (trust practice verification और attention में split होती है), और ये आठ files बनाती हैं: एक manual तीन zoom levels पर।

  1. Working agreement: क्या public है, कुछ boundaries, क्या private रहता है। (Context पहले; इसके बिना कुछ और काम नहीं करता।)
  2. Roster + role cards: हर member, वह क्या own करता है, उसकी tools, उसके escalation triggers।
  3. North star: goal, और कौन बिना prompt के उसे chase कर सकता है।
  4. Verification rubric + doer-verifier: आपके देखने से पहले work कैसे checked होता है।
  5. Weekly report + attention budget: team कैसे improve करती है और आपका time कैसे protect करती है।

पाँच operating documents dependency order में, हर एक अगले को feed करता है: working agreement, फिर roster और role cards, फिर north star, फिर verification rubric और doer-verifier, फिर weekly report और attention budget। इनमें से दो Phase 3 के बाकी हिस्सों को hand off करते हैं: roster Workforce with Paperclip को feed करता है (जो इससे hire करता है), और attention budget Identic AI को feed करता है (जो इसे automate करता है)। Caption कहता है: हर एक अपने agent के साथ fill करें; हर एक का decision खुद लें; starter इन पाँच को templates के रूप में ship करता है।

हर एक को उसी rhythm से चलाएँ: Part का prompt paste करें, agent का draft पढ़ें, और decide करें: cut, sharpen, approve। Authority आप हैं; agent drafter है।

Anthropic के पाँच questions को done-test बनाएं। Team ready तब है जब हर answer yes हो:

  1. क्या agents और humans को चाहिए information और access दोनों public और broadly searchable हैं?
  2. क्या आप अपनी team का roster, humans और agents, लिख सकते हैं और कह सकते हैं हर member क्या own करता है?
  3. क्या हर human और agent के पास अपना job करने के लिए सही tools हैं?
  4. क्या key work products verify करने के लिए rubrics या tests हैं?
  5. क्या team के पास clear north star है जिसे सब reference कर सकते हैं?

Worked example: finance close team

Templates abstract रहती हैं जब तक आप filled example न देखें। यह छोटी finance team है जो monthly close run करती है (एक human controller और तीन agents), जहाँ important parts concrete हैं। (Starter इसे examples/finance-close-team.md के रूप में ship करता है।)

North star: building से बाहर जाने वाला हर number सही हो और अपने source तक traceable हो.

MemberHuman/AgentOwnsTools / accessAutonomy
ControllerHumanSign-off on anything that leaves the companynonehuman-only
PullerAgentPulling figures from the source systemsERP / GL read-onlyL2 (verified)
ReconcilerAgentMatching figures across sources, flagging variancesthe ledger, the system of recordL3 on routine ties; L1 on new accounts
CheckerAgentGrading the reconciliation against the rubricthe rubricdoer-verifier only

जो detail इसे safe बनाती है वह escalation trigger है, Reconciler की role card पर साफ़ लिखा हुआ।

Example: Reconciler का escalation trigger

Controller को escalate करें जब: कोई variance account balance के 1% या $10,000 से ज़्यादा हो, जो भी छोटा हो (deliberately conservative, ताकि छोटी accounts भी छोटी swings पर escalate हों), या कोई figure system of record में source के बिना हो। Otherwise, उसे tie करें और log करें।

और verification rubric जिसे Checker apply करता है। Reconciliation सिर्फ़ तब pass होती है जब:

Example: Checker की rubric
  1. every balance ties to its source within threshold; 2. every variance has a reason code; 3. every source document is linked in the system of record; 4. every exception is listed in the escalation queue.

वह escalation line miniature में पूरा operating model है। Reconciler routine ties अपने आप run करता है (L3), Checker किसी के देखने से पहले rubric के against verify करता है (doer-verifier), unsourced या material numbers रुककर human तक पहुँचते हैं (attention सिर्फ़ वहाँ spend होती है जहाँ count करती है), और Controller वह एक role hold करता है जो बाहर की दुनिया को number ship करता है। Note करें Reconciler routine ties पर L3 लेकिन new accounts पर L1 है: autonomy per task type, per agent नहीं। Thresholds और sources swap करें, और यही shape accounts payable, payroll, या board reporting run करता है।

Checkpoint: आप team run कर सकते हैं। Working agreement, clear roles वाला roster, north star, work verify करने का तरीका, और अपनी attention का budget। यह operating model है, और बाकी workforce courses इसी पर run करते हैं।


Part 7: Ceiling, जहाँ यह grow करता है

Operating model अकेले team को scale नहीं करता। यह rules set करता है; अगले चार courses वह machinery हैं जो इन पर run करती है, और हर एक आपके अभी लिखे artifact को input बनाता है:

  • Workforce with Paperclip roster automate करता है: lead agent budgets, approvals, और full audit trail के अंदर workers का board hire और run करता है। आपका roster और role cards वही हैं जिनसे वह hire करता है।
  • Self-Expanding Workforce work grow होने पर team grow करती है, बजाय इसके कि आप हर worker हाथ से add करें।
  • Identic AI आपका attention budget automated है: signed identity जो आपकी set की limits के अंदर routine approvals clear करती है और सिर्फ़ consequential ones surface करती है।
  • Payment-Enabled Agents worker को transact करने देता है: cost बचाने वाली team से earn करने वाली team तक का step।

पहले operating model बनाएं, और उस machinery के पास run करने के लिए sound चीज़ होगी। इसे skip करें, और आप ऐसी team automate कर रहे होंगे जो शुरू से coherent ही नहीं थी।

और practices का ceiling खुद: humans के लिए इसमें कुछ नया नहीं। Clear north star, defined roles, open में काम, quality के लिए shared bar, mistakes से सीखने की जगह: ये healthy team habits हैं जिन्हें हम decades से जानते हैं। Agents इन्हें introduce नहीं करते। वे इन्हें skip करना fatal बना देते हैं, क्योंकि agent बुरी practice को भी अच्छी practice जितनी तेज़ scale करेगा। जो teams agents से सबसे ज़्यादा पा रही हैं, वे fundamentals पर सबसे ज़्यादा disciplined हैं।

यही वह line है जहाँ तक book चलकर आ रही थी: Digital FTEs की workforce, इस operating model पर run होती हुई, एक AI-native company के अंदर। आप यहाँ एक worker के बारे में सोचकर आते हैं। आप यहाँ से निकलते हैं तो लोगों के साथ उनकी team run कर सकते हैं, और उस team के output को scale, govern, और sell कर सकते हैं।

वही manual, दूसरी teams

Artifact set एक shape है; team बदलती है, documents नहीं:

  • Research team: analyst, synthesiser, और fact-checker agents, "answer the question, with sources" north star के नीचे।
  • Delivery team: planner, doer, और doer-verifier, quality rubric के नीचे, ship decision human hold करता है।
  • Finance team: data-pull agent, reconciliation agent, और वह human जो building से बाहर जाने वाले हर number का owner है।

वही पाँच documents। अलग roster, अलग north star, अलग rubric।

Capstone: real team खड़ी करें

अपनी organisation का real goal चुनें और उसके लिए full artifact set produce करें: working agreement, roster, role cards, north star, verification rubric, doer-verifier, weekly report, attention budget।

1Your Work
2Get Your Score

Discuss with an AI. Question your scores.
Come back when you have your BEST evaluation.

Starter graded example (examples/finance-close-team-graded.md) ship करता है, एक complete finance manual जो इन आठ checks के against 15/16 score करता है, एक weak check named और fix shown के साथ। अपना manual grade करने से पहले इसे पढ़ें: यह दिखाता है कि rubric क्या पकड़ता है और strong manual कैसा दिखता है।

Sources

यह course Anthropic के human-agent teams चलाने के account से सिखाता है, और इस book के पहले से बने frameworks पर map करता है। Primary source और Anthropic material जिससे यह draw करता है:

Flashcards Study Aid


अपनी समझ test करें

Checking access...