Claude Platform & Solution Design

Screen 1: Claude के साथ समाधान डिजाइन करना सिर्फ एक मॉडल चुनने से परे है।

TEACHING 2 MIN · MODULE INTRODUCTION Claude के साथ समाधान डिजाइन करना सिर्फ एक मॉडल चुनने से परे है।

Claude के साथ समाधान डिजाइन करते समय, निर्माण शुरू करने से पहले चार मुख्य निर्णय लेने होते हैं।

01 काम का कौन सा हिस्सा Claude को देना चाहिए?

कुछ भी आकार देने से पहले, आपको यह तय करना चाहिए कि Claude को क्या सौंपना है, मौजूदा सिस्टम के साथ क्या रखना है, और एक मानव के साथ क्या रहता है।

02 काम का आकार क्या है?

क्या आप एक लाइव कॉल को बढ़ा रहे हैं, एक वर्कफ़्लो को स्वचालित कर रहे हैं, या एक एजेंट को तैनात कर रहे हैं जो अपने आप पर कार्य करता है?

03 क्या आप संदर्भ आर्किटेक्चर का नाम दे सकते हैं जिसके लिए आप प्रतिबद्ध हैं?

एक संदर्भ आर्किटेक्चर को अग्रिम रूप से चुनना आपको महंगे pivots से बचा सकता है।

04 आपका काम Claude के साथ कहाँ इंटरैक्ट करता है?

सही entry point, मॉडल, और context strategy चुनना आपके समाधान को काम करने और cost-conscious रखेगा।

इस मॉड्यूल में, आप सीखेंगे कि इन निर्णयों को कैसे लें ताकि एक अस्पष्ट व्यावसायिक समस्या को एक प्रस्तावित समाधान में अनुवाद किया जा सके और विश्वसनीय विकल्पों के विरुद्ध अपनी पसंद का बचाव किया जा सके।

इस मॉड्यूल के अंत तक, आप सक्षम होंगे: 1 एक partner के अनुरोध को उस चीज़ में तोड़ना जो Claude करता है, मौजूदा सिस्टम क्या करते हैं, और मनुष्य क्या करते हैं, generative AI के चार गुणों को अपने निर्णय lens के रूप में उपयोग करके। 2 एक augmented call, एक workflow, और एक agent के बीच चुनना करके नाम देना कि प्रत्येक विकल्प की कीमत क्या है। 3 समस्या के आकार के लिए एक reference architecture pattern चुनना और यह पहचानना कि retrieval किस काम को live-state को देना चाहिए। 4 defensible model, context-window, और context-strategy निर्णय लेना, और किसी भी model swap से पहले evaluations को gate के रूप में उपयोग करना। 5 जानना कि प्रत्येक platform entry point कहाँ फिट बैठता है (Claude. ai, API, SDK, Claude Code, या MCP server) और कौन सी customization प्रत्येक layer पर है। 6 Claude entry points के बीच अंतर करना जो एक user देखता है, build-time interfaces जो एक engineer code करता है, और delivery routes जो एक enterprise खरीदता है, साथ ही यह पहचानना कि कौन से governance या regulated-industry constraints से पहले किसी अन्य tradeoff से ruled out हैं। WHO THIS MODULE IS FOR

यह मॉड्यूल Architect के लिए है जो एक partner के अस्पष्ट अनुरोध को एक समाधान में बदलता है जिसे कोई बना सकता है, fund कर सकता है, और defend कर सकता है। आप तकनीकी, निर्णायक, और tradeoff-aware हैं। आप इस मॉड्यूल में production code नहीं लिख रहे हैं, और यह आपको सिखाता नहीं है। यह code के ऊपर के निर्णयों को सिखाता है: Claude को कौन सा काम देना चाहिए, वह काम किस आकार का है, कौन सा reference architecture फिट बैठता है, और कौन से model, context, और entry point विकल्प सिस्टम को सटीक और सस्ता रखते हैं जब यह real हो।

"The work" इस मॉड्यूल में

यहाँ सब कुछ एक sample engagement के चारों ओर बनाया गया है: एक partner से एक व्यावसायिक समस्या लेना और एक proposed architecture पर पहुँचना जिसके पीछे आप खड़े हो सकते हैं जब एक विश्वसनीय विकल्प टेबल पर हो। इस परिदृश्य में, partners high-stakes, अक्सर regulated, settings में enterprise buyers हैं जहाँ एक design choice जो एक demo में clean दिखता था एक audit में तीन महीने बाद एक misroute बन जाता है। यह परिदृश्य निर्णयों की एक श्रृंखला के रूप में प्रस्तुत किया जाता है, प्रत्येक निर्णय आपसे कुछ अलग माँगता है।

निर्णय निम्नलिखित sections में map करते हैं:

Decomposition वह जगह है जहाँ आप अनुरोध के प्रत्येक हिस्से को Claude, एक मौजूदा सिस्टम, या एक मानव को assign करते हैं, generative AI के चार गुणों को lens के रूप में उपयोग करके। इसे गलत तरीके से करना Claude को over-assign करके सबसे आम और सबसे महंगी early mistake है। Pattern selection वह जगह है जहाँ आप तय करते हैं कि काम एक augmented call, एक workflow, या एक agent है। प्रत्येक विकल्प आपको कुछ देता है और आपसे कुछ लेता है, costs को नाम देना objective है। Reference architectures वह जगह है जहाँ एक known, good blueprint या तो problem shape में फिट बैठता है या misapplied होता है। देखने के लिए failure यह है कि retrieval quietly एक काम कर रही है जो live transactional state को देना चाहिए। Model, context, और entry point वह जगह है जहाँ आप एक model tier, एक context strategy, और एक delivery route चुनते हैं, और जहाँ evaluations किसी भी model swap से पहले एक stage-gate बन जाते हैं। जांचें कि क्या governance और regulated-industry constraints किसी भी cost या latency tradeoffs पर विचार करने से पहले एक route को rule-out करते हैं।

इन stages को memorize करने के बजाय, इस मॉड्यूल में objective यह पहचानना है कि कौन सा निर्णय आपके सामने है, क्योंकि प्रत्येक एक अलग move को reward करता है: decomposition में आपकी सेवा करने वाला निर्णय एक entry point चुनते समय अलग होता है। इस मॉड्यूल के अंत में cumulative task में आप सब कुछ एक नए brief से full architecture को assemble करने के लिए एक साथ रखेंगे।

DISCLAIMER / NOTICE FOR EDUCATIONAL CONTENT

हमने यह Architect course Module 1: Claude Platform & Solution Design Claude के साथ real work करने में आपकी मदद करने के लिए बनाया है। इसे educational content के रूप में treat करें। यह legal, financial, या अन्य professional advice constitute नहीं करता है, इसलिए अपनी स्थिति के लिए जो सीखते हैं उसे adapt करें। हमारे products और services तेजी से evolve करते हैं, इसलिए कुछ content में errors हो सकते हैं या outdated हो सकते हैं; Anthropic की website या docs पर verify करना याद रखें। Examples और scenarios जो course में उपयोग किए जाते हैं वे illustrative हैं और अक्सर fictitious हैं। यदि course material एक company या product का mention करता है, तो इसका मतलब यह नहीं है कि Anthropic उन्हें endorse करता है, वे Anthropic को endorse करते हैं, या कि हम affiliated हैं। यह भी note करें कि आपका Anthropic products और services का उपयोग हमारे terms, policies और documentation द्वारा covered है; यदि इस course में कुछ उनके साथ conflict करता है, तो वे control करते हैं।

Screen 2: चार गुण जिनके चारों ओर architects डिजाइन करते हैं

Teaching 12 min · How Claude Behaves

चार गुण जिनके चारों ओर architects डिजाइन करते हैं इससे पहले कि आप तय करें कि Claude को एक समाधान में क्या करना चाहिए, आपको Claude कैसे behave करता है इसकी स्पष्ट समझ होनी चाहिए। मॉडल के चार गुण हर following design decision को shape करते हैं। ये गुण कोई flaw नहीं हैं जिन्हें fix किया जाए, प्रत्येक एक force है जिसके चारों ओर आप design करते हैं – जैसे एक structural engineer अपनी building materials के गुणों के चारों ओर design करता है।

इस screen को initial groundwork के रूप में consider करें, आपसे कोई design decisions लेने के लिए नहीं कहा जा रहा है। Goal यह है कि चार गुणों को नाम से पहचानें और प्रत्येक गुण के design consequences को समझें ताकि आप module में later judgment exercises में informed choices लेने के लिए तैयार हों।

चार गुण और उनके design consequences नीचे दी गई प्रत्येक row के लिए, वही characteristics जो Claude को एक situation में capable बनाती हैं वही हैं जो दूसरे में fail करती हैं। प्रत्येक row को एक capability के साथ paired के रूप में read करें इसके matching limitation के साथ, और mitigation जो एक architect के लिए पहुँचता है।

प्रत्येक गुण को देखने के लिए select करें इसके paired capability, limitation, और mitigation के साथ।

Next Token Prediction Knowledge Working Memory Steerability

Capability: Common patterns पर built tasks: summarizing, reformatting, और well-established concepts को explaining करना। Limitation: कुछ भी जिसके लिए specifics पर precision की जरूरत है। Claude text produce कर सकता है जो accurate दिखता है लेकिन नहीं है। यह risk names, dates, citations, और statistics के चारों ओर concentrate करता है। Mitigation: Citations, uncertainty signaling, और generator-verifier loops का उपयोग करें। Specific factual lookups को tool calls या authoritative sources के माध्यम से route करें बजाय model के output पर solely rely करने के।

Capability: Model के training data में topics जो common, recent, और consistently included हैं जहाँ model reliably answer कर सकता है जो यह learned है। Limitation: Topics जो rare, niche, contested, या frequently changing हैं। Model stale या incomplete information present कर सकता है established facts के लिए उपयोग करने वाले same confident tone के साथ। Mitigation: Web search, retrieval (RAG), tool use, या MCP servers का उपयोग करें ताकि एक external system model के बजाय truth का source बन जाए। Model के parametric knowledge को check करने के बजाय, authoritative answer retrieved source से आता है। जब freshness या authority matter करता है, तो data को अपने आप re-introduce करें बजाय model के training data में provided पर rely करने के।

Capability: कुछ भी जो active context window में fit करता है। Limitation: Context window एक hard edge है: एक बार content window के बाहर fall करता है, model के पास इसका कोई access नहीं है। Window के edge पर दो अलग errors होते हैं, लेकिन वे conflate करने में आसान हो सकते हैं। एक oversized request है, meaning एक prompt या conversation जो पहले से ही बहुत बड़ा है भेजने के लिए। जब एक oversized request भेजा जाता है तो यह generation से पहले rejected होता है। यदि request model के token limit को exceed करता है, तो API एक 400 invalid_request_error return करता है एक message के साथ indicating कि prompt बहुत लंबा है। यदि raw request body API के byte limit को exceed करता है, तो API एक 413 request_too_large error return करता है एक message के साथ indicating कि request maximum allowed number of bytes को exceed करता है। दूसरा error तब होता है जब एक prompt fit करता है, लेकिन इसका generation window ceiling में run करता है और early stop करता है; current models पर response एक model_context_window_exceeded stop reason के साथ आता है और truncated output। Limit को hit करने से बचने के लिए, आप हर response पर usage field को check कर सकते हैं और भेजने से पहले token-counting API को। Mitigation: Progressive context loading, chunking, और critical information के front-loading का उपयोग करें। Extended work के लिए, projects scope में क्या रहता है इसे manage करने में मदद कर सकते हैं। Context long हो रहा है जब turns के across summarize करने की practice में get करें।

Capability: Short, concrete, और verifiable instructions defined formats के साथ, explicit length limits, clear roles। Limitation: Abstract या ambiguous instructions, long reasoning chains, और tasks जिनके लिए precise numerical या logical computation की जरूरत है। High-stakes numerical accuracy के लिए, deterministic computation या tool execution को answer own करना चाहिए। Model instruction के letter को follow कर सकता है जबकि intent से drift करता है। Mitigation: System prompts, structured outputs, और code execution का उपयोग करें कुछ भी के लिए जिसके लिए logical precision की जरूरत है। जब intent और literal instruction diverge कर सकते हैं, तो goal को explicitly restate करें instruction के साथ।

Property से design consequence तक हम इस course के एक later part में इन गुणों में से प्रत्येक को revisit करेंगे। अभी प्रत्येक property को उनके design consequence में map करें ताकि connection उस जगह पर हो जहाँ आपको इसकी जरूरत है:

Non-determinism। Same input अलग-अलग runs में अलग outputs produce कर सकता है। यही कारण है कि evaluation frameworks exist करते हैं: आप behavior को certify नहीं कर सकते जिसे आपने केवल एक बार observe किया है। (Module 2 में evaluation work को feed करता है।) Context as a finite resource। Context window एक hard edge है एक fixed token budget के साथ। आप इसमें क्या put करते हैं, किस order में, और क्या छोड़ते हैं वे design decisions हैं जो दोनों को affect करते हैं कि model किसके साथ काम कर सकता है और इसे run करने में क्या cost होता है। (इस module में later model और context strategy को feed करता है।) Confidence is not validity। Claude एक wrong answer produce कर सकता है same fluent, assured tone में जो यह एक right के लिए उपयोग करता है। यही कारण है कि human-in-the-loop placement और verification architectural choices हैं, afterthoughts नहीं। (Module 3 में responsible-deployment work को feed करता है।) Knowledge और capability boundaries। Model reliable है topics के साथ जो common, recent, और consistent हैं इसके training data में, और unreliable है topics के साथ जो rare, private, या fast-changing हैं। Unreliable topics के लिए, web search, retrieval, tools, और MCP को एक external system को model के बजाय truth का source बनाने के लिए उपयोग किया जा सकता है। (इस module में later reference architectures और RAG को feed करता है।)

Scenario: एक failure जो एक misread property से शुरू हुई एक architect ने एक demo को cleanly पाँच बार run करते हुए देखा और निष्कर्ष निकाला कि behavior deterministic था। उस basis पर team ने एक financial reconciliation pipeline ship किया जो प्रत्येक model output को एक fixed, repeatable result के रूप में treat करता था और इसके चारों ओर कोई checks नहीं बनाया। Production के दूसरे week में outputs drift करने लगे: same statement, re-processed, एक अलग categorization produce किया। यह discrepancy केवल chance से discovered था जब एक analyst को एक batch को re-run करने का happen हुआ। Input में कुछ नहीं बदला था, लेकिन अलग outputs produce किए गए क्योंकि model एक non-deterministic system है और architecture को ऐसे build किया गया था जैसे यह deterministic था। Lesson यह नहीं है कि model unreliable है, यह है कि एक demo determinism का evidence नहीं है और कि चार गुण present हैं चाहे आपका architecture उन्हें acknowledge करे या नहीं।

Cost · Complexity · Risk Cost: इन गुणों पर विचार किए बिना designing सबसे महंगी mistake है जो एक architect कर सकता है, क्योंकि cost launch के बाद lands करता है, जब rework सबसे महंगा है और trust को rebuild करना सबसे कठिन है। Complexity: चार गुणों को upfront name करना later design conversations को precise रखता है। आप "यह एक knowledge-boundary problem है" acknowledge कर सकते हैं बजाय debate करने के कि model "अच्छा enough" है। Risk: गुण अपने आप को announce नहीं करते। एक system जो इन गुणों के चारों ओर design नहीं करता है एक error produce नहीं करेगा; यह quietly drifts करता है और gap variable outputs में results करता है जो एक audit में या एक angry user द्वारा found हो सकते हैं, system के द्वारा नहीं।

Screen 3: Entry points, build-time interfaces, delivery routes

Teaching 12 min · Platform Map & Primitives

Entry points, build-time interfaces, delivery routes इस course के दौरान आप चुनेंगे कि एक user Claude तक कैसे पहुँचता है, लेकिन उससे पहले, आपको consistent vocabulary की जरूरत है। तीन terms अक्सर interchangeably उपयोग किए जाते हैं, लेकिन वे architecture के अलग-अलग layers में sit करते हैं। यह screen इन terms में से प्रत्येक को सिखाता है। उनके बीच चुनना later आता है, एक बार rest of the design in place हो।

तीन layers, तीन distinct decisions ये तीन layers एक दूसरे के alternatives नहीं हैं। हर deployment सभी तीन को involve करता है और उन्हें confuse करना सबसे common source है muddled architecture conversations का।

Entry Points क्या एक person या system directly interact करता है। Entry Points वे wrappers हैं जो decide करते हैं कि कौन Claude से बात कर सकता है और कैसे। Examples: Claude. ai (web, mobile, desktop), Claude Code, API पर built एक custom application।

Build-time interfaces एक engineer कैसे Claude के विरुद्ध program करता है, वह layer जिसके लिए partner का code लिखा जाता है। Examples: Direct API, SDKs, MCP, Agent SDK।

Delivery routes जहाँ API traffic terminate होता है। Delivery routes determine करते हैं कि request किसके infrastructure पर run होता है। Examples: Anthropic directly, AWS Bedrock, GCP Vertex AI, Microsoft Foundry।

क्यों layers को distinct रखना matter करता है एक entry point user और work के लिए चुना जाता है। एक build-time interface engineering team और integration के लिए चुना जाता है। एक delivery route partner के cloud commitments और compliance posture के लिए चुना जाता है। ये तीन अलग conversations हैं तीन अलग stakeholders के साथ, और एक layer में एक decision rarely दूसरों को dictate करता है। अभी के लिए, उनके नाम और उनके distinction को सीखने पर focus करें। उनके बीच select करना real constraints के तहत later सिखाया जाएगा, एक बार आपके पास एक model, एक pattern, और एक architecture हो जो उन्हें fit करे।

एक failure जो layers को collapse करने से आई एक retail banking workflow solution के लिए एक proposal ने Claude Code, एक engineering entry point, को एक non-engineering audience के सामने रखा क्योंकि, author के शब्दों में, "यह सब Claude है।" यह सब Claude है, इस sense में कि same model हर entry point के नीचे sit करता है। लेकिन entry point wrapper है, और Claude Code developers के लिए built था एक terminal run करते हुए, bank branch staff के लिए नहीं एक workflow follow करते हुए। तीन layers को एक के रूप में treat करना उस distinction को erase कर देता है जो choice को immediately rule out करना चाहिए।

Cost · Complexity · Risk Cost: हर entry point अपनी non-trivial integration cost carry करता है। गलत layer pick करना क्योंकि vocabulary unclear था गलत solution के लिए pay कर सकता है, फिर इसे replace करने के लिए फिर से pay कर सकता है। Complexity: जब तीन layers को named और precisely discussed किया जाता है, एक design review exactly isolate कर सकता है कि कौन सा decision contested है। जब वे blurred होते हैं, review circles में argue करता है। Risk: एक entry point chosen before the user is named एक common और avoidable architecture error है जो अक्सर इन तीन distinct layers को एक concept में collapse करने के लिए traceable है।

Screen 4: प्रत्येक piece को अपने layer में रखें

Checkpoint 4 min · Platform Map & Primitives

प्रत्येक piece को अपने layer में रखें एक platform piece को select करने के लिए click करें, फिर इसे place करने के लिए right layer bucket को click करें। एक placed chip को pool में return करने के लिए click करें। सभी 8 items को submit करने से पहले place किया जाना चाहिए।

claude. ai Direct API Claude Desktop SDKs Bedrock / Vertex / Foundry Claude Code MCP Agent SDK

Entry Points

Build-time Interfaces

Delivery Routes

Submit Skip for now

Screen 5: एक architect समाधान assemble करता है उसके parts

Teaching 16 min · Platform Map & Primitives

एक architect समाधान assemble करता है उसके parts हर pattern और architecture इस course में एक small set of primitives का एक assembly है। उन्हें एक बार यहाँ name करें, ताकि later lessons आप पहले से recognize करते हैं उसके parts के combinations बन जाएँ। यह screen सात primitives को name करता है, उनका job, और एक one-line statement प्रत्येक को सिखाने के लिए कि प्रत्येक किसके लिए है। आप अभी उनके बीच choose नहीं कर रहे हैं; आप सीख रहे हैं कि प्रत्येक किसके लिए है।

सात primitives, सात jobs प्रत्येक primitive को एक single job के रूप में read करें। किसी भी एक primitive पर deep जाने के बजाय, सभी सात का एक wholistic view रखें। एक architect के रूप में एक key skill इन primitives को compose करके एक solution develop करना है।

प्रत्येक card को flip करने के लिए click करें: front primitive को name करता है और इसका one-word job, back one-line definition देता है।

ActToolsFlip ↻ क्या model को एक action लेने या आपके code से एक result fetch करने देता है, एक function जो model call कर सकता है।

ConnectMCPFlip ↻ एक protocol tools के एक set को expose करने के लिए ताकि multiple Claude clients same entry points तक पहुँच सकें।

Isolate / parallelizeSubagentsFlip ↻ एक scoped sub-task को एक separate context में hand करें ताकि work isolation में या parallel में run हो।

GuaranteeHooksFlip ↻ Deterministic code जो defined events पर fires करता है एक rule को enforce करने के लिए जो model skip नहीं कर सकता।

Package a procedureSkillsFlip ↻ एक versioned, reusable unit (instructions plus optional scripts) जो एक repeatable procedure को package करता है।

Coordinate peersAgent TeamsFlip ↻ Multiple agents working as coordinated peers, प्रत्येक एक larger goal का एक part own करता है।

Compose at runtimeDynamic WorkflowsFlip ↻ Workflow के steps को runtime पर assemble करें बजाय उन्हें advance में fix करने के।

Agent Teams (coordinated peer agents) और Dynamic Workflows (runtime composition) older vocabulary को extend करते हैं single agents और fixed workflows की। आप उन्हें current practitioner conversations में named देखेंगे भले ही कई existing systems उन्हें predate करते हैं।

क्यों उन्हें अभी inventory करें Later में सिखाए गए patterns, augmented call, workflow, agent, abstract categories नहीं हैं। प्रत्येक pattern सात primitives का एक particular assembly है। एक workflow steps है आपके code में wired, अक्सर tools का उपयोग करके। एक agent model को अपने tool calls का sequence choose करने देता है। एक multi-agent system एक orchestrator है subagents को delegate करता है। जब आप उन lessons तक पहुँचते हैं, आप primitives को compose कर रहे होते हैं जिन्हें आपने पहले से ही name किया है, उन्हें पहली बार meet नहीं कर रहे।

Scenario: एक failure जो shared vocabulary को miss करने से आई एक architecture review में, किसी ने कहा "हम एक agent का उपयोग करेंगे।" Room में पाँच लोगों ने पाँच अलग चीजें सुनीं: एक ने एक single tool-using model सुना, एक ने एक multi-step workflow सुना, एक ने एक team of subagents सुना, एक ने Claude Code सुना, और एक ने एक chatbot सुना। Design conversation बीस minutes के लिए stall हो गई इससे पहले कि किसी को realize हुआ कि वे अलग architectures describe कर रहे थे same word के साथ। एक common understanding establish करके primitive vocabulary की, team clarity और efficiency के साथ operate कर सकता है।

Cost · Complexity · Risk Cost: एक heavier primitive को reach करना जो job से ज्यादा है latency, tokens, और operational surface area में paid होता है, हर request। E. g. , एक team of agents का उपयोग करना जब एक single tool call काफी होता। Complexity: Design में प्रत्येक added primitive एक part है build, observe, और govern करने के लिए। Discipline यह है कि fewest primitives का उपयोग करें जो requirement को meet करें। Risk: Shared vocabulary के बिना, teams effectively communicate नहीं कर सकते क्योंकि वे agree नहीं करते कि parts क्या हैं।

Screen 6: Primitive को job से match करें

Checkpoint 4 min · Platform Map & Primitives

Primitive को job से match करें तीन sets के across बाईं ओर प्रत्येक item को दाईं ओर इसके match से match करें। यह design half से पहले readiness check है। सभी तीन sets का answer दें, फिर submit करें।

Set 1 of 3: Behavior properties को उनके design consequence से प्रत्येक property को design consequence से match करें जो यह create करता है। Non-determinismChoose... Why evaluation frameworks existWhy retrieval and tools existWhy context strategy is a design decisionWhy human-in-the-loop placement matters Knowledge boundaryChoose... Why evaluation frameworks existWhy retrieval and tools existWhy context strategy is a design decisionWhy human-in-the-loop placement matters Context as a finite resourceChoose... Why evaluation frameworks existWhy retrieval and tools existWhy context strategy is a design decisionWhy human-in-the-loop placement matters Confidence is not correctnessChoose... Why evaluation frameworks existWhy retrieval and tools existWhy context strategy is a design decisionWhy human-in-the-loop placement matters

Set 2 of 3: Platform pieces को उनके layer से प्रत्येक platform piece को layer से match करें जो यह sit करता है। Claude CodeChoose... Entry pointBuild-time interfaceDelivery route MCPChoose... Entry pointBuild-time interfaceDelivery route BedrockChoose... Entry pointBuild-time interfaceDelivery route

Set 3 of 3: Primitives को उनके job से प्रत्येक primitive को one-word job से match करें जो यह करता है। ToolsChoose... ActIsolate / parallelizeGuaranteePackage a procedure SubagentsChoose... ActIsolate / parallelizeGuaranteePackage a procedure HooksChoose... ActIsolate / parallelizeGuaranteePackage a procedure SkillsChoose... ActIsolate / parallelizeGuaranteePackage a procedure

Submit Skip for now

Screen 7: Claude कहाँ fit करता है (Claude / systems / humans)

Teaching 9 min · Decomposition

Claude कहाँ fit करता है (Claude / systems / humans) जब आप एक partner के लिए एक solution architect कर रहे हैं, आप पहले से ही तीन तरह के decisions बना रहे हैं: ask क्या है, कौन से systems आपके पास available हैं इसे address करने के लिए, और कहाँ human judgment को involve होना चाहिए। यह module एक चौथा decision add करता है: determine करना कि Claude कहाँ help कर सकता है। वह चौथा decision एक है जो architects गलत करते हैं क्योंकि उनके पास Claude के predictable strengths और failure modes की deep understanding नहीं है। इस module का goal आपको एक concrete decision framework देना है determine करने के लिए कि "Claude help कर सकता है" specificity के साथ।

कौन क्या करता है? हर solution के तीन owners हैं: उन्हें early assign करना आपको success के लिए set up करता है हर solution जो आप Claude के साथ architect करते हैं तीन buckets में से एक में lands करता है:

OwnerWhat belongs here

What Claude doesवह काम जो language understanding, summarization, planning, drafting, या tool-mediated action से benefit करता है। What existing systems doकुछ भी आपका partner पहले से ही reliable बनाने के लिए paid है: order-status service, policy engine, rules table, database of record। What humans doJudgment calls, exception paths, approvals, moments जहाँ right होना fast होने से ज्यादा matter करता है।

Architects कभी-कभी सभी तीन को "what Claude does" में collapse करते हैं, लेकिन over-assigning tasks को Claude almost always process को ज्यादा महंगा, slower, और harder बनाता है। Key यह है कि जानना कि Claude क्या best करता है और आपके solution में इसे क्या responsible होना चाहिए।

Delegation: decide करना कि Claude को क्या trust किया जाए Decomposition एक delegation map produce करता है। अनुरोध के प्रत्येक part के लिए आप decide करते हैं न केवल कि Claude यह कर सकता है, बल्कि कि Claude को इसे own करना चाहिए: AI-appropriate work, human-retained work, या collaborative work जहाँ Claude draft करता है और एक person decide करता है। प्रत्येक assignment को justify करें through:

Reversibility: क्या एक wrong call को undo किया जा सकता है? Stakes: एक wrong call की cost क्या है? Accountability: इसके लिए किसे answer देना चाहिए?

यह screen delegation की discipline को सिखाएगा, चार AI Fluency competencies में से पहला। चार behavior properties जो आपको बताते हैं कि Claude को क्या trust किया जा सकता है foundations section में सिखाए गए थे; यहाँ आप उन्हें apply करेंगे।

Scenario: एक partner request को decompose करना, प्रत्येक step को right owner को assign करना एक partner "एक claims triage assistant माँगता है जो एक claim को read करता है, priority decide करता है, policy coverage को look up करता है, और adjuster को email करता है।" एक architect की first instinct सभी चार steps को "What Claude does" bucket में put करना हो सकता है, लेकिन four-properties lens यह होने से रोकता है:

"Claim को read करें।" यह squarely Claude के capability zone में है। एक claim को read और interpret करना pattern-rich language work है, और यदि output schema constrained है, तो both next-token prediction और steerability आपके favor में काम कर रहे हैं। यह काम है जो Claude करता है। "Priority decide करें।" यह step एक language task की तरह दिख सकता है, लेकिन यह नहीं है। Priority एक deterministic rule है जो आपका partner पहले से ही define और maintain करता है। क्या priority count करता है partner के organization में एक rule engine में रहता है, Claude के training data में नहीं। इसे Claude को route करना एक unnecessary knowledge limitation introduce करता है। इसके बजाय, Claude rule engine को call करता है और existing system काम को decide करने के लिए करता है। "Policy coverage को look up करें।" यह same problem में run करता है priority के रूप में, लेकिन higher stakes के साथ। Policies change करते हैं और coverage tables update होते हैं, और model के पास कोई reliable way नहीं है जानने के लिए कि version जो यह training के दौरान learned current होना बंद कर दिया। Answer live coverage data को hold करने वाले system से आना चाहिए, tool use या एक MCP server के through retrieved। "Adjuster को email करें।" यह step को split up करने की जरूरत है। Message को draft करना language work है और Claude को करने के लिए कुछ है। Message को send करना email system को belong करता है। एक human को review और approve करना चाहिए कुछ भी एक value threshold से ऊपर, क्योंकि यदि Claude अपने आप decide करता है, तो दोनों इसके working-memory और steerability limitations दोनों risks बन जाते हैं।

Decomposition को driven होना चाहिए question को answer करके "where do the four properties argue for Claude over the system that already does this right? " बजाय "Where can Claude help? " इस framing में shift पर close attention दें, यह key concept है जो यह module build कर रहा है।

Cost · Complexity · Risk Cost: हर lookup जो एक simple deterministic system handle कर सकता था Claude को instead भेजा जाता है। आप model को काम के लिए pay करते हैं जो एक database query या एक rules table एक fraction of the cost के लिए कर सकता था, और thousands of requests के across यह add up कर सकता है fast। Complexity: जब आप logic को एक table-driven system से बाहर move करते हैं और model में, errors traceable होना बंद कर देते हैं। एक deterministic rule एक predictable, debuggable way में fail करता है। एक model same job को handle करता है variable outputs produce करता है जो observe और diagnose करना बहुत harder है। Risk: Model के पास कोई reliable way नहीं है जानने के लिए कि इसकी information कब out of date है, और यह gap को flag नहीं करेगा। जब model truth का source बन जाता है partner के actual system के बजाय, authoritative answers quietly drift कर सकते हैं, कोई error thrown नहीं और कोई warning raised नहीं।

Screen 8: जब deterministic check quietly drifted

Watch Out 4 min · Decomposition

जब deterministic check quietly drifted

Setup hook जब team Claude के बारे में excited है, एक deterministic check को model के अंदर put करना एक cleaner design provide करता है: एक component, fewer integrations, और easier to demo। यह type का move है एक senior Architect करता है जब एक team fast move कर रहा है और rule "easy enough" दिखता है model के लिए।

एक scoping call, transcribed नीचे दिया गया conversation एक real scoping exchange है। दो लोग एक reasonable call करते हैं एक design को simplify करने के लिए, और moment में यह एक clean win दिखता है। क्या उन्होंने actually किया है एक deterministic business rule को hand करना, एक जो हर बार right होना चाहिए, model को, एक probabilistic system, जो most of the time right है लेकिन not all of the time। वह gap development के दौरान surface नहीं हुआ, इसके बजाय यह तीन महीने बाद surface हुआ, एक audit में। यह section एक failure mode को explore करता है जहाँ goal यह दिखाना है कि क्या गलत हुआ ताकि आप pattern को early recognize कर सकें और एक अलग decision लें।

Partner: "हमारे पास एक rule है कि कोई भी claim £5,000 से ऊपर एक senior adjuster को जरूरत है। आज हम claims table के विरुद्ध एक SQL check कर रहे हैं। क्या Claude इसके बजाय handle कर सकता है? " Architect: "हम Claude को prompt कर सकते हैं amount को extract करने के लिए और accordingly route करने के लिए यदि यह 5K से ऊपर है। यह इसे एक step में रखता है बजाय एक separate system तक पहुँचने के, तो यह way simpler है।" Partner: "Perfect, यह मेरे लिए काम करता है।"

[तीन महीने बाद, production में]

14,000 claims में से, 41 incorrectly routed सभी 41 same problem share करते थे। Amount एक clean number के रूप में नहीं लिखा गया था। यह एक sentence के अंदर tucked था, जैसे 'damages estimated around five thousand pounds।' Model ने 'around five thousand' को एक loose estimate के रूप में treat किया बजाय एक figure के जो senior review को trigger करना चाहिए, तो वे claims standard handling को गए। Rule precise था। Information जो इसे work करनी थी precise नहीं था, और model rule के letter को follow किया बजाय इसके intent के।

क्या broke: एक deterministic rule एक probabilistic system को handed Threshold नहीं बदला, लेकिन क्या rule को enforce किया। एक deterministic rule जो हर बार correct होना चाहिए Claude को folded किया गया था, जो most of the time right है। Gap उनके बीच 41 misroutes में रहता था। Team ने कभी test cases का एक set नहीं बनाया routing को check करने के लिए, क्योंकि उन्होंने routing को कुछ के रूप में treat किया था model just handle करेगा बजाय एक rule के business count कर रहा था। वह difference crux है problem का। एक rule business count कर रहा है tested, watched, और owned होना चाहिए एक human द्वारा। कुछ आप assume करते हैं model handle करेगा left alone है जब तक यह break नहीं करता। Misroutes एक audit द्वारा caught थे, system के अपने monitoring द्वारा नहीं। Kind का logging जो एक broken SQL check को catch किया होता एक single request के अंदर model के choices को record नहीं करता, तो कुछ भी drift को flag नहीं किया। Failure invisible रहा जब तक किसी ने इसे look नहीं किया।

क्यों यह broke एक rule जो हर बार right होना चाहिए एक system को handed जो most of the time right है। वह tradeoff demo के दौरान miss करना आसान है क्योंकि model clean cases को correctly handle करता है, और clean cases वह हैं जो आप demos और early testing में देखते हैं। "Most of the time" की cost reveal नहीं करती जब तक आप audit नहीं करते और by then partner call कर रहा है।

Screen 9: Field-service capabilities को sort करें

Checkpoint 4 min · Decomposition

Field-service capabilities को sort करें एक field-service partner ने आपको एक request list दिया है एक knowledge assistant के लिए उनके engineers on-site use करेंगे। एक capability को select करने के लिए click करें, फिर इसे place करने के लिए right owner bucket को click करें। सभी 8 items को submitting से पहले place किया जाना चाहिए।

Engineer के case notes को एक one-page handover में summarize करें Return the current stock level of part SKU 78-A at the closest warehouse £2,000 से ऊपर एक refund को approve करें यदि engineer एक request करता है एक unit label की एक photo से part number को extract करें तीन job tickets के across total billable time को calculate करें Customer को delay को explain करते हुए एक follow-up email को draft करें Engineer को बताएँ कि क्या warranty इस serial number को apply करता है Decide करें कि क्या एक safety incident को field manager को escalate करना है

Claude

Existing Systems

Human

Submit Skip for now

Screen 10: Request को decompose करें

Checkpoint 4 min · Decomposition

Request को decompose करें एक partner brief नीचे है। प्रत्येक step के लिए, right owner को select करें: क्या Claude करता है, क्या existing systems करते हैं, या क्या humans करते हैं। Previous checkpoint tested किया कि क्या आप चार गुणों को recognize कर सकते हैं; यह एक split को decompose करने के लिए test करता है।

Brief एक regional logistics partner एक assistant चाहता है जो, प्रत्येक inbound shipping exception के लिए: carrier के free-text exception note को read करता है, decide करता है कि क्या shipment partner के published policy के तहत एक automatic refund के लिए qualify करता है, customer के contract tier को look up करता है, customer को एक notification को draft करता है, और refund को issue करता है।

Carrier के free-text exception note को read करें

Claude Existing System Human

Decide करें कि क्या shipment partner के published policy के तहत एक automatic refund के लिए qualify करता है

Claude Existing System Human

Customer के contract tier को look up करें

Claude Existing System Human

Customer notification को draft करें

Claude Existing System Human

Refund को issue करें

Claude Existing System Human

Submit Skip for now

Screen 11: Primitives को augmented call, workflow, agent में compose करना

Teaching 13 min · Pattern Selection

Primitives को augmented call, workflow, agent में compose करना एक बार जब आप establish कर लेते हैं कि task के कौन से parts Claude own करता है बनाम क्या आपके systems और people own करते हैं, next decision structural है: Claude की involvement किस shape को लेता है? Choose करने के लिए तीन patterns हैं: एक augmented LLM, एक workflow, और एक agent। प्रत्येक दो axes पर एक अलग position लेता है: predictability (काम के through path कितना predictable है) और model autonomy (आप model को कितना autonomy hand करने को willing हैं)।

Claude की involvement को structure करने के लिए तीन patterns

Augmented LLM Workflow Agent

एक single model invocation: आप request भेजते हैं, model task को complete करता है, और आपका code इसके चारों ओर wiring को handle करता है। आप tool use, retrieval, या extended thinking को उस call में add कर सकते हैं, लेकिन model अभी भी एक bounded job को एक pass में कर रहा है। Control flow कभी branch नहीं करता है जो model decide करता है पर आधार। इसे use करें जब task well-defined है, output कुछ है आप verify कर सकते हैं, और work को multiple steps के across split करने का कोई reason नहीं है। आप task को named steps में decompose करते हैं और उन्हें अपने code में orchestrate करते हैं। प्रत्येक step may या may not Claude को call कर सकता है। क्योंकि control flow आपके code में रहता है बजाय model के अंदर, आप इसे log कर सकते हैं, test कर सकते हैं, और इसके behavior को reason कर सकते हैं same way आप software के किसी अन्य piece को करते हैं। इसे use करें जब error cost real है, observability matters, और steps को advance में determine किया जा सकता है। आप Claude को एक goal और एक set of tools देते हैं और model अपने sequence of steps को determine करता है उस goal तक पहुँचने के लिए। Control flow model के अंदर रहता है, आपके code में नहीं। वह क्या है जो इसे एक agent बनाता है बजाय एक workflow के: काम के through path को advance में कहीं inspect नहीं किया जा सकता। इसे use करें केवल जब काम के through path को advance में enumerate नहीं किया जा सकता, और केवल जब एक unexpected या inconsistent output की cost acceptable और recoverable है। Production में, agents typically bounded हैं constrained tool entry points द्वारा, per-turn budgets, explicit permissions, और stopping criteria। ये constraints options नहीं हैं; वे एक agent को एक liability बनने से रखते हैं।

Use cases को predictability और autonomy द्वारा map करना किसी भी use case को दो axes पर plot करें: path कितना predictable है, और आप model को कितना autonomy grant करने को willing हैं।

HIGH LOW LOW PREDICTABILITY HIGH PREDICTABILITY MODEL AUTONOMY

AgentHigh autonomy, low predictability। Model trajectory को own करता है। WorkflowPredictable shape; bounded model judgment प्रत्येक step के अंदर। Augmented LLMHigh predictability, low autonomy। एक bounded model call।

Augmented LLMs high-predictability, low-autonomy quadrant में sit करते हैं। आप task को जानते हैं, आप जानते हैं क्या good दिखता है, और model इसे एक बार execute करता है। Workflows middle band को occupy करते हैं। Overall shape predictable है, लेकिन प्रत्येक step एक contained way में model judgment को involve कर सकता है। Agents high-autonomy, low-predictability corner में sit करते हैं। यह pattern को reach करने के लिए है जब steps को advance में enumerate करना और है expensive part problem का: open-ended investigation, long-horizon work, और tasks जहाँ next move depend करता है क्या last one turned up पर। Claude Code एक production-proven example है: यह एक unfamiliar codebase को explore करता है, decide करता है कि कौन सी files को read करना है जो यह पहले से ही found है पर आधार, और multi-step engineering work को run करता है जो कोई script ahead of time नहीं कर सकता। वह capability है जो agents unlock करते हैं, लेकिन associated cost बस as real है। यह जगह है जहाँ non-deterministic failures concentrate करते हैं production में, क्योंकि model का trajectory control flow है और कोई code boundary नहीं है जहाँ एक guard sit कर सकता है।

Workflows के अंदर sub-patterns एक workflow को choose करना design को fully specify नहीं करता। चार shapes हैं एक workflow ले सकता है, और प्रत्येक एक अलग assumption को reflect करता है कि कैसे steps एक दूसरे से relate करते हैं।

Sub-patternShapeWhen it earns its placeExamples

Chaining Step 2 step 1 के output को अपने input के रूप में लेता है, sequentially और linearly काम करता है। इसे use करें जब task naturally decompose करता है stages में clear handoffs के साथ, जैसे extract, फिर classify, फिर summarize। प्रत्येक stage एक defined output है next stage consume करता है। एक contract review pipeline: पहला call सभी obligations और deadlines को raw document से extract करता है, दूसरा प्रत्येक को risk level द्वारा classify करता है, और तीसरा lawyer के लिए एक summary memo को draft करता है। प्रत्येक stage एक clean output है next stage consume करता है।

Routing एक classifier, अक्सर Claude itself, decide करता है कि कौन सा downstream path लेना है। इसे use करें जब inputs kind में vary करते हैं और अलग kinds को अलग handling की जरूरत है। एक incoming support ticket arrives: एक classifier इसे read करता है और billing questions को एक retrieval index पर route करता है account data के ऊपर, technical issues को एक retrieval index पर product documentation के ऊपर, और escalations directly को एक human queue को। Same input entry point, तीन अलग handling paths।

Parallelization Multiple model calls concurrently run करते हैं; results को aggregate या vote किया जाता है। इसे use करें जब sub-tasks independent हैं और same time पर run कर सकते हैं। Multiple files को review करना या एक long document के distinct sections को review करना इस shape में fit करता है क्योंकि न तो sub-task दूसरे के output पर depend करता है। एक due diligence review twelve supplier contracts के across: प्रत्येक contract एक separate model call को simultaneously भेजा जाता है। सभी बारह results return होते हैं और एक single risk report में aggregate होते हैं। कोई call दूसरे के output पर depend नहीं करता, तो sequentially run करने का कोई reason नहीं है।

Evaluator-optimizer एक model call output का एक first attempt produce करता है। एक दूसरा call इसे evaluate करता है और revision को request करता है। Loop repeat होता है जब तक एक quality criterion को meet किया जाता है या एक retry limit को reach किया जाता है। इसे use करें जब quality verifiable है लेकिन एक single attempt reliable enough नहीं है। Code generation एक test suite के विरुद्ध run किया जाता है, या structured-output extraction एक strict schema के साथ, common applications हैं। एक model एक customer complaint को एक response को draft करता है। एक दूसरा model call इसे एक rubric के विरुद्ध grade करता है (क्या यह specific issue को name करता है, ownership लेता है, concrete next steps को offer करता है brand के tone में) और check करता है कि क्या output expected structure को match करता है। यदि यह नहीं करता है, evaluator specific feedback return करता है और generator rewrite करता है। Loop exit होता है जब हर rubric item pass होता है या एक retry limit को hit करता है।

ये चार patterns mutually exclusive नहीं हैं। अधिकांश production workflows एक से ज्यादा pattern को combine करते हैं, और right choice usually simplest है जो error tolerance और observability requirements को meet करता है task का, और revisit करता है वह choice एक बार आपके पास production data हो; escalate केवल जब measurement दिखाता है simpler pattern fall short हो रहा है।

Right pattern को choose करने के लिए एक framework: sequence में पाँच factors इन पाँच factors को sequence में walk करें। प्रत्येक के लिए, ask करें कि क्या factor किसी भी तीन patterns को rule out करता है – Augmented LLM, Workflows, Agent। पहला factor जो एक pattern को rule out करता है deciding है। नीचे दी गई table दिखाती है कि प्रत्येक pattern प्रत्येक factor पर आपसे क्या cost करता है, तो आप देख सकते हैं कि tradeoffs कहाँ land करते हैं।

FactorThe question to answerAugmented LLMWorkflowAgent

PredictabilityCan you enumerate the steps in advance? Low: single bounded task. Low: you wrote the path. High: trajectory is unpredictable by design. Error costWhat does a wrong answer cost: a retry, an audit, a lawsuit? Medium: exposes you to the model's output distribution without step-level guards. Low: deterministic guards sit between steps. High: exposes you to the full output distribution across multiple turns. ObservabilityCan your operations team see what happened and reconstruct why? Medium: a single call is easy to log but opaque inside. Low: steps log as code does, with standard tooling. High: the trajectory reads like a transcript; most current observability tooling isn't built to alert on this. Latency budgetWhat is the user-visible deadline? Low: fastest in standard configurations, though extended thinking or retrieval adds time. Medium: predictable but additive in duration. High: runtime is open-ended; budget for the worst case, not the median. CostWhat's the per-request token cost at your expected volume? Low: fewest tokens per request. Medium: scales with step count. High: iterative reasoning, multi-turn tool use, retries, and growing context can materially increase token usage and latency. Poorly bounded agents are often the most expensive pattern.

Prompting को try करें इससे पहले कि आप fine-tuning को consider करें यदि prompting unreliable दिखता है, तो बहुत सारे engineers के लिए instinct fine-tuning को reach करना है। Claude पर, वह usually wrong first move है। इस sequence को पहले work करें:

Prompt को optimize करें। अधिकांश reliability problems prompt problems हैं। Tool use या retrieval को add करें यदि prompt alone enough नहीं है। एक stronger pattern जैसे एक evaluator-optimizer को move करें यदि quality अभी भी जहाँ होना चाहिए वहाँ नहीं है। केवल तब fine-tuning को consider करें।

Fine-tuning की एक जगह है, लेकिन specific situations में:

Task बहुत high volume पर run करता है और inference cost real constraint है। Latency critical है और एक smaller specialized model एक prompted general को outperform करेगा। Output को एक consistent format को follow करना चाहिए और prompting इसे reliably solve नहीं किया है।

उन situations के बाहर, fine-tuning आपको एक fixed model version को lock करता है और बिना बहुत कुछ दिखाए बिना आपके options को narrow करता है। इसे last step के रूप में treat करें एक deliberate progression में, एक quick fix नहीं एक prompt के लिए जो अभी तक काम नहीं कर रहा है।

Availability पर note Fine-tuning Claude broadly available नहीं है। Access limited है, model और delivery route द्वारा vary करता है, और changes जैसे Anthropic program को expand करता है। Anthropic account team के साथ current options को confirm करें इससे पहले कि आप इस path को एक partner को recommend करें।

ये तीन patterns abstract categories नहीं हैं। प्रत्येक foundations section में आपने inventory किए primitives का एक assembly है: एक augmented call model plus tools है; एक workflow primitives को अपने code में wired है; एक agent model को अपने sequence of tool calls को choose करने देता है। एक pattern को choose करना उन parts को compose करने का तरीका choose करना है।

Skills-based architecture एक packaging option के रूप में एक pattern को choose करने के साथ, decide करें कि capability कैसे packaged है। तीन options एक spectrum पर sit करते हैं: एक prompt-only solution (instructions alone), direct tool use (model आपके code में functions को call करता है), और एक Skills-based architecture (एक versioned, reusable Skill जो procedure, इसके instructions, और कोई भी scripts को एक governed unit के रूप में package करता है)। एक Skill को reach करें जब same procedure repeatedly run करता है, teams या products के across distribute होना चाहिए, या versioned और governed होना चाहिए। Delegation lens को pattern itself पर apply करें: क्या यह pattern Claude को appropriate या excessive decision authority grant करता है risk profile के लिए जो आपके सामने है? एक agent जो autonomously act कर सकता है right choice है केवल जब stakes और reversibility इसके actions को autonomy justify करते हैं जो यह दिया जाता है।

Cost · Complexity · Risk Cost: Agents automatically workflows से ज्यादा cost नहीं करते। क्या drive करता है cost है कितना context conversation के across accumulate होता है और कितने model calls बनाए जाते हैं। एक poorly designed workflow एक well-designed agent से ज्यादा cost कर सकता है। Design pattern label से ज्यादा matter करता है। Complexity: Workflows और agents अलग तरीकों में fail करते हैं। एक workflow fail करता है जब आपके code में एक step fail करता है। एक agent fail करता है जब model एक bad decision कहीं एक sequence of turns में करता है। वह दूसरा type failure harder है spot करने के लिए और harder है diagnose करने के लिए, और आपके standard debugging tools इसे same way में catch नहीं करेंगे। Risk: एक agent की autonomy आपकी liability surface है। एक agent कुछ भी कर सकता है इसके tools allow करते हैं, combinations को including आपने test नहीं किया। Broader tool permissions, larger space है चीजों का जो गलत हो सकता है। Tool entry point को narrow रखें जितना task allow करता है।

Screen 12: जब team flexibility चाहता था और non-determinism मिला

Watch Out 4 min · Pattern Selection

जब team flexibility चाहता था और non-determinism मिला

Setup hook: जब teams agents को pick करते हैं और shouldn't यह एक common mistake है। Agents अक्सर choose किए जाते हैं क्योंकि एक task open-ended दिखता है, not क्योंकि task को एक की जरूरत है। लेकिन work को structure करने के बारे में uncertain होना अलग है एक task से जहाँ steps genuinely advance में determine नहीं किए जा सकते। यदि आप steps को code में लिख सकते थे, आप एक workflow के बजाय एक agent का उपयोग कर सकते थे और non-deterministic control flow की unnecessary complexity को avoid कर सकते थे।

तीन quotes नीचे एक single team के 90-day retrospective से हैं। प्रत्येक एक अलग layer को name करता है same underlying mistake का।

"हमने एक agent pick किया क्योंकि हम इसे बहुत जल्दी constrain नहीं करना चाहते थे। Month दो तक हमने इतने सारे guardrail tools add किए थे हमने basically workflow को agent loop के अंदर rewrite किया था, minus the logging।" "Compliance आया और पूछा कि कौन सा step disbursement को approve किया। हमने एक model turn पर point किया। उन्होंने पूछा कि कौन सा version model का। हमने trace check किया। Version दो weeks पहले roll forward हुआ था और किसी ने re-validate नहीं किया।" "Actual paths through the system, जब हमने traces को mine किया, केवल चार shapes में fall किए। चार। हम इसे एक router और चार chains के रूप में लिख सकते थे और अपने आप को छह महीने बचा सकते थे।"

क्या broke और क्यों प्रत्येक quote एक distinct failure को name करता है, और वे order में compound करते हैं। Team ने unknown future flexibility के लिए optimize किया बजाय known present shape के। जब team ने अपने traces को month तीन पर mine किया, actual paths through the system चार shapes में fall किए, सभी week एक से enumerable। Workflow जिसकी उन्हें जरूरत थी एक router था चार chains के साथ। उन्होंने एक agent build किया और छह महीने खर्च किए उस structure को agent loop के अंदर reconstruct करने में। Non-determinism एक compliance problem बन गई। जब एक auditor ने पूछा कि कौन सा step एक disbursement को approve किया, team केवल एक model turn पर point कर सकता था। क्या agent pattern specifically add किया वह एक discrete, auditable step नहीं होना है point करने के लिए। यह है कि कैसे agent autonomy एक compliance risk बन जाता है: normal operation में नहीं, लेकिन जब एक external party को एक deterministic answer की जरूरत है और system केवल एक trajectory produce कर सकता है। एक unpinned model version ने gap को compound किया। Auditor ने फिर पूछा कि कौन सा version model का run किया था। Trace दिखाया कि version दो weeks पहले roll forward हुआ था कोई re-validation checkpoint के साथ। वह roll-forward एक model-governance gap है और किसी भी pattern के तहत एक problem होता: एक unpinned version कोई re-validation gate या एक workflow के साथ जो same way ship किया गया था दोनों को same exposure inherit होता। केवल एक इन दोनों failures में agent pattern के बारे में है।

एक agent को choose करना जब आप sure नहीं हैं कि क्या यह right pattern है safe default नहीं है। एक agent right choice है केवल जब काम के through steps genuinely advance में determine नहीं किए जा सकते। यदि steps known हैं upfront, एक agent को choose करना एक workflow के ऊपर means आप flexibility के लिए pay कर रहे हैं आप use नहीं करेंगे: extra tokens, latency, और audit gaps जो surface करते हैं जब compliance कुछ पूछता है आपके traces answer नहीं कर सकते। Agents को avoid नहीं किया जाना चाहिए, लेकिन उन्हें fit for purpose होना चाहिए। यदि काम genuinely unpredictable होता, एक agent exactly उस reason के लिए right call होता। यह team की mistake उस जगह पर jump करना था एक agent जब चार paths through उनके system knowable थे start से। एक router और चार chains उन्हें एक clean, auditable structure दिया होता। इसके बजाय, उन्होंने छह महीने खर्च किए उस structure को hand से एक agent loop के अंदर rebuild करने में।

Screen 13: Multi-agent systems और orchestration

Teaching 9 min · Pattern Selection

Multi-agent systems और orchestration Pattern selection आपको बताता है कि कब एक agent को reach करना है। कुछ problems एक single agent के लिए बहुत बड़े या बहुत varied हैं एक context में hold करने के लिए। जब वह होता है, design multiple agents को काम करने के लिए move करता है together: एक orchestrator जो काम को decompose करता है और subagents जो प्रत्येक इसका एक part carry करते हैं। यह screen सिखाता है कि कैसे वे systems structured हैं, कैसे वे fail करते हैं, और कहाँ एक human loop में belong करता है।

Orchestrator और subagents: roles, delegation, synthesis एक multi-agent system दो roles रखता है।

Orchestrator Goal को own करता है: यह काम को decompose करता है, decide करता है कि क्या delegate करना है, और results को एक single answer में synthesize करता है। Orchestrator कभी sub-task work को itself नहीं करता; इसका job delegation और synthesis है।

Subagents Scoped sub-tasks को own करते हैं: प्रत्येक अपने context में run करता है, एक piece को करता है, और एक result return करता है।

तीन चीजें design की जानी चाहिए, assumed नहीं: कैसे काम को sub-tasks में decompose किया जाता है, कैसे प्रत्येक subagent का result structured है ताकि orchestrator इसे combine कर सके, और कैसे orchestrator conflicts या gaps को resolve करता है जब results back आते हैं।

Worked pattern: एक large work item के ऊपर fan-out सबसे common multi-agent shape एक fan-out है। उदाहरण के लिए: एक parent agent एक work item का सामना करता है एक context के लिए बहुत बड़ा: एक 400-file codebase को audit करना, एक 200-document corpus को summarize करना, और एक regulatory filing को check करना fifty rules के विरुद्ध। Orchestrator item को independent units में split करता है, एक subagent को प्रत्येक unit को dispatch करता है (parallel में जहाँ units एक दूसरे पर depend नहीं करते), और फिर returned results को एक single deliverable में synthesize करता है। यहाँ win twofold है: प्रत्येक subagent एक clean context में काम करता है अपने unit को sized, और independent units concurrently run करते हैं।

Error recovery: जहाँ एक failure को catch किया जा सकता है, और जहाँ नहीं एक multi-agent system में, architectural question को ask करना है 'Where is each failure mode recoverable? '।

एक subagent failure usually recoverable है: यदि एक unit fail करता है, orchestrator इसे retry कर सकता है, इसे elsewhere route कर सकता है, या इसे drop कर सकता है और gap को flag कर सकता है, जबकि rest of the work proceed करता है। एक orchestrator failure usually recoverable नहीं है: यदि agent जो goal को own करता है और synthesis को hold करता है अपने thread को lose करता है, पूरा run fail करता है, और partial subagent work stranded हो सकता है।

Design इस asymmetry के लिए, subagent work को idempotent और retryable बनाएँ, और orchestrator के state को protect करें।

FailureWhere it landsDesign response

एक subagent एक malformed या empty result return करताSubagent boundary (recoverable)प्रत्येक result को validate करें; failed unit को retry या re-route करें; gap को record करें बजाय run को fail करने के। दो subagents conflicting results return करते हैंSynthesis step (recoverable)Orchestrator को एक explicit conflict-resolution rule दें, या conflict को एक human को escalate करें। Orchestrator goal को lose करता है या इसके synthesis state को lose करताOrchestrator (often unrecoverable)Orchestrator state को protect करें; progress को checkpoint करें ताकि एक failed run resume कर सके बजाय restart के। Traces orchestrator और subagents के across fragmentFragmentObservability (cross-cutting)एक shared trace identifier को propagate करें ताकि एक single run end to end को reconstructable हो।

Agent workflows के लिए human-in-the-loop checkpoint patterns एक multi-agent system कई actions ले सकता है इससे पहले कि एक human कभी output को देखता है, जो checkpoint placement को एक deliberate design choice बनाता है। एक human-in-the-loop checkpoint एक gate है जो execution को pause करता है review के लिए, positioned by the risk और reversibility of the action about to be taken। एक gate को place करें किसी भी irreversible या high-stakes action से पहले एक subagent otherwise autonomously लेता; lower-stakes actions को sample करें बजाय प्रत्येक को gate करने के। Stakes द्वारा routing का full treatment एक later section में covered होगा, यहाँ point यह है कि gate orchestration design का एक part है, bolted on afterward नहीं।

Cost · Complexity · Risk Cost: Multi-agent systems token spend को multiply करते हैं, हर subagent का अपना context है, और orchestrator synthesize करने के लिए pay करता है। Pattern को reach करें जब काम genuinely एक context को exceed करता है, default के रूप में नहीं। Complexity: प्रत्येक added agent एक अलग failure boundary है observe और govern करने के लिए। Discipline fewest agents है जो requirement को meet करते हैं, clear goal ownership के साथ। Risk: Dangerous failure silent है: एक subagent एक unit को drop करता है और orchestrator एक confident, complete-looking answer को incomplete work के ऊपर synthesize करता है। Coverage को validate करें, assume न करें।

Screen 14: जब fan-out ने एक dropped unit को hide किया

Watch Out 4 min · Pattern Selection

जब fan-out ने एक dropped unit को hide किया

Trace एक compliance team ने एक multi-agent system build किया एक 50-section vendor contract को check करने के लिए एक internal policy checklist के विरुद्ध। Orchestrator काम को एक subagent को प्रत्येक section को fan out किया, प्रत्येक एक pass/flag verdict return करता है, और एक clean summary को synthesize किया: "48 sections reviewed, 3 flagged।" Summary complete दिखता था और legal lead को circulate किया गया। दो sections कभी review नहीं किए गए। एक subagent timeout हुआ था और कुछ नहीं return किया; दूसरा एक scanned page को parse करने में fail हुआ था और एक empty result return किया था। Orchestrator, coverage check दिए बिना, केवल results को count किया जो यह receive किया और report किया "48 reviewed", लेकिन 50 sections थे, और किसी ने synthesis step को नहीं बताया कि count को reconcile करना चाहिए।

क्या broke और क्यों

Synthesis पर कोई coverage check नहीं। Orchestrator results को synthesize किया जो यह happen को receive किया, कोई rule के साथ नहीं कि results की number dispatched units की number को equal होना चाहिए। एक recoverable failure कभी recover नहीं किया गया। एक timed-out subagent recoverable case है, लेकिन केवल यदि कुछ इसे retry करता है या gap को flag करता है। यहाँ failure silent था क्योंकि कुछ भी boundary को watch नहीं कर रहा था। Incomplete work के ऊपर confident synthesis। Output की fluency gap को mask किया। एक multi-agent system सबसे dangerously fail करता है जब summary complete दिखता है और नहीं है।

क्यों यह broke Completeness को assumed किया गया, verified नहीं। Orchestrator 50 units को dispatch किया और results को report किया जो यह receive किया। दो units कभी back नहीं आए, और design में कुछ भी difference को notice नहीं किया। तीन gaps line up करते हैं इसे through let करने के लिए।

Count को कभी reconcile नहीं किया गया। Synthesis step verdicts को add up किया जो यह receive किया और stop किया। कोई rule नहीं कहा कि results की number dispatched units की number को match करना चाहिए, तो 48 returned results "48 reviewed" बन गए बजाय "two are missing।" एक recoverable failure के पास कुछ नहीं था इसे watch करने के लिए। एक timed-out subagent और एक empty parse result दोनों recoverable case हैं, लेकिन केवल जब कुछ unit को retry करता है या gap को flag करता है। कोई component subagent boundary को own नहीं करता था, तो दोनों failures silently pass किए। Output complete दिखता था। Summary fluent था और well-formed, जो exactly है जो gap को invisible बनाता है। एक multi-agent system सबसे dangerously fail करता है जब एक confident summary built होता है काम के ऊपर जो कभी finish नहीं हुआ। Fix एक coverage check है synthesis पर: results returned को units dispatched को equal होना चाहिए, या run flag करता है difference को इससे पहले कि कोई summary को read करता है।

Screen 15: Orchestration design को critique करें

Checkpoint 5 min · Pattern Selection

Orchestration design को critique करें

Draft architecture submitted for review नीचे एक draft multi-agent architecture है submitted for review: एक orchestrator एक large document-classification job को subagents को fan करता है। छह components list किए गए हैं। तीन को select करें जो एक control या failure-boundary defect carry करते हैं।

Select exactly 3 components that carry a control or failure-boundary defect.

1Orchestrator decomposes the corpus into per-document units

↓

2Subagents run in parallel, each returns a verdict

↓

3Synthesis sums returned verdicts into a report

↓

4Irreversible action (auto-archive) taken with no human gate

5No retry or gap-flag on a failed subagent 6Shared trace ID propagated to every subagent

Submit Skip for now

Screen 16: Shapes जो industry पहले से ही pay करके learn किया है

Teaching 15 min · Reference Architectures

Shapes जो industry पहले से ही pay करके learn किया है एक pattern को choose करना right structure देता है। Patterns आपको shape देते हैं। Next question को ask करना है कि कैसे वह structure सब कुछ के साथ connect करता है। Reference architectures आपको wiring देंगे।

Reference architectures: क्या good दिखता है और जहाँ projects गलत जाते हैं Reference architectures references हैं, blueprints नहीं adhere करने के लिए। Goal matching नहीं है एक problem को एक fixed design के लिए और इसे drawn के रूप में implement करना। हर partner workload unique है, तो आपका goal यहाँ है इन common patterns को अच्छी तरह समझना ताकि आप उनसे generalize कर सकें। Ultimately, आप able होना चाहिए shape को लेने के लिए जो fit करता है, इसे workload में adapt करने के लिए आपके सामने, और recognize करने के लिए जब एक workload एक से ज्यादा pattern draw करता है एक बार। अधिकांश partner problems एक handful reference architectures को map करते हैं पहले से ही Claude ecosystem में proven: documented patterns कि कैसे एक LLM application को wire करना है एक recurring class of problem को solve करने के लिए। नीचे दी गई table common reference architectures को cover करता है, क्या वे दिखते हैं जब वे well-built हैं, और failure modes जो repeatedly show up करते हैं।

प्रत्येक pattern को expand करें देखने के लिए क्या good दिखता है और जहाँ projects गलत जाते हैं।

Agent (see S11)What good looks like: Model एक goal की ओर काम करता है deciding करके कि कौन से tools को call करना है और किस order में। Autonomy को check में रखा जाता है limiting करके कि tools क्या कर सकते हैं और setting करके एक budget कि कितने turns model को मिलते हैं। इसे use करें जब काम के through path को advance में नहीं लिखा जा सकता: एक codebase को investigate करना, multiple research sources से pull करना, या complex customer cases को triage करना।Where projects go wrong: Unbounded autonomy: Model को tools देना जो state को change करते हैं कोई human review के साथ, कोई turn limit, और कोई way नहीं measure करने के लिए कि क्या goal को meet किया गया। Retrieval-augmented generation (RAG) (see S11)What good looks like: एक stable knowledge corpus, जैसे product manuals, internal docs, या regulatory text, को chunk और index किया जाता है। जब एक question आता है, सबसे relevant chunks को retrieve किया जाता है और model को context के रूप में pass किया जाता है।Where projects go wrong: RAG को use करना live state के बारे में questions को answer करने के लिए: order status, inventory levels, ticket queues। Index एक snapshot है। यदि underlying data change हुआ है जब से last refresh, answer गलत होगा। Document processing pipeline → Evaluator-optimizer (see S11)What good looks like: Structured extraction semi-structured documents से जैसे claims, invoices, और contracts। Pipeline OCR को handle करता है, fields को एक schema के विरुद्ध extract करता है, output को validate करता है, और exceptions को route करता है। एक evaluator-optimizer common है यहाँ क्योंकि first-pass extraction edge cases पर reliable enough नहीं है trust करने के लिए बिना एक check के।Where projects go wrong: कोई exception path नहीं। Low-confidence extractions same pipeline के through जाते हैं clean documents के रूप में, कोई human gate के साथ नहीं catch करने के लिए ones model को गलत मिला। Customer-service / ticket triage → Routing (see S11)What good looks like: Intent को classify करें और user क्या पूछ रहा है, फिर right backend को route करें: एक knowledge retrieval layer documentation questions के लिए, एक transactional API live state queries के लिए जैसे order status या account changes, और एक human approval layer high-consequence actions के लिए।Where projects go wrong: Live order status के लिए retrieval को use करना बजाय API को directly call करने के। कोई escalation path नहीं एक human को। एक agent variant को deploy करना simpler routed workflow को properly measure किए बिना। Coding agent (agentic exploration with deterministic edit/test/review steps) (see S11)What good looks like: काम दो phases में split होता है। पहले, agent codebase को investigate करता है समझने के लिए क्या change होना चाहिए: यह part agentic है क्योंकि path एक unfamiliar codebase के through advance में नहीं लिखा जा सकता। दूसरा, actual edits deterministic steps को follow करते हैं: parse, plan, propose, test, review। Subagents isolated tasks को handle करते हैं enough context के साथ काम करने के लिए लेकिन इतना नहीं कि steps unmanageable बन जाएँ।Where projects go wrong: Agent को edit और commit करने देना बिना एक human review gate के। Regression rates को track नहीं करना एक eval set के विरुद्ध प्रत्येक language या framework के लिए codebase में। पूरी चीज़ को एक conversation के रूप में treat करना बजाय एक structured pipeline के defined handoffs के साथ।

Full RAG implementation depth, including chunking strategies, embedding approaches, hybrid lexical-plus-semantic retrieval, और reciprocal rank fusion, RAG pipeline design screen में covered है जो follows।

कैसे decide करें कि एक problem को एक या कई patterns की जरूरत है Real partner problems frequently sit करते हैं boundary पर दो architectures के बीच। एक routing workflow कुछ intents को एक agentic investigation loop को hand कर सकता है। एक document processing pipeline RAG को use कर सकता है policy text के ऊपर जब यह एक exception case को hit करता है। एक से ज्यादा pattern draw करना कभी-कभी right answer है। क्या matter करता है क्यों आप एक दूसरे pattern को reach कर रहे हैं। Patterns को pieces के रूप में think न करें आप snap together करते हैं। देखें कि क्यों प्रत्येक काम करता है और idea को अपनी problem में fit करने के लिए shape करें। एक दूसरे pattern को draw करें जब आपकी problem के दोनों parts अलग तरीकों में break करते हैं जो separately manage करने के लिए worth हैं। यदि आप एक दूसरे pattern को reach कर रहे हैं क्योंकि आपने decide नहीं किया कि आप क्या problem solve कर रहे हैं, एक single pattern को adapt करें। वह एक design decision है आप defer कर रहे हैं, एक pattern नहीं आप apply कर रहे हैं।

सबसे common mistake: retrieval applied to live state सबसे common reference architecture mistake retrieval को use करना है जहाँ एक tool call belong करता है। आप इसे recognize कर सकते हैं इन symptoms को देखकर: stale chunks, results जो हर index refresh के साथ shift करते हैं, answers जो contradict करते हैं क्या database में है। एक better embedding model या एक shorter refresh interval यह issue को fix नहीं करेगा। इसके बजाय, system को directly call करें जो live state को own करता है बजाय एक cached version को retrieve करने के।

Cost · Complexity · Risk Cost: दो reference architectures को compose करना roughly double करता है surface area आपको maintain करना चाहिए। जब doubt में हो, एक को pick करें। Complexity: प्रत्येक reference architecture अपनी eval contract carry करता है। आपको separate eval sets की जरूरत है प्रत्येक architecture के लिए, एक single eval set नहीं composed system के लिए। एक system जो top level पर healthy दिखता है एक को mask कर सकता है इसके components में failures। Risk: Retrieval को live state पर misapply करना stale लेकिन confident answers produce करता है। System healthy दिखता है outside से: normal latency, कोई errors नहीं। Detection cost high है क्योंकि कोई signal नहीं है कि कुछ गलत है जब तक एक user notice नहीं करता answer reality को match नहीं करता।

Screen 17: जब retrieval को tool call के बजाय reach किया गया

Watch Out 4 min · Reference Architectures

जब retrieval को tool call के बजाय reach किया गया

Setup hook: कैसे RAG fail करता है जब live state पर applied Broader underlying skill यहाँ context engineering है: decide करना कि कौन सी mechanism responsible है प्रत्येक kind के data को model के सामने लाने के लिए। Retrieval एक vector index के ऊपर एक example है, और यह trace दिखाता है क्या होता है जब इसे data को own करने के लिए ask किया जाता है यह नहीं कर सकता। यह अक्सर होता है जब एक team RAG को reach करता है क्योंकि यह एक previous use case पर काम किया, बिना stop किए ask करने के लिए कि क्या नया एक same properties share करता है। RAG well काम करता है जब answer एक body of reference material में रहता है जो index refreshes के बीच stable रहता है, e. g. , documentation, policy text, product manuals। यह live state के लिए break करता है क्योंकि retrieval आपके data को text snapshots के रूप में treat करता है, एक system के रूप में नहीं current values के साथ। जब वे snapshots disagree करते हैं, model most similar को pick करता है और confidently answer करता है। कोई way नहीं है जानने के लिए कि कौन सा snapshot current है। नीचे दिया गया trace exactly दिखाता है कि यह कैसे play out करता है।

Trace: electronics retailer customer service assistant User asks: "Where's my order? "

RETRIEVED CHUNK #1 (similarity 0. 78): "Order #88412 was placed on the 11th of June and shipped on the 12th via standard courier. Tracking number AB123…" RETRIEVED CHUNK #2 (similarity 0. 74): "Order #88412 is currently being processed. Expected dispatch within 24 hours. "

MODEL OUTPUT: "Your order shipped on the 12th of June via standard courier. Tracking: AB123…"

दोनों chunks real strings थे जो corpus में अलग-अलग points पर existed। Index ने उन्हें conflate किया। Order ship हुआ था, depot को return किया गया था एक damaged label के कारण, और re-dispatch के लिए awaiting था। Note करें कि यह current state न तो chunk में appear करता है: corpus दो stale snapshots hold करता था और कोई record नहीं जहाँ order था, क्योंकि एक index capture करता है क्या true था जब यह लिखा गया, not at the present। एक customer service tool live order status को fetch करने के लिए partner के API में existed। यह call नहीं किया गया।

क्या broke और क्यों Category error। Retrieval right mechanism है knowledge के लिए: FAQs, policies, manuals। यह wrong mechanism है transactional state के लिए। Order status नहीं fail कर रहा था क्योंकि retrieval broken है। यह fail कर रहा था क्योंकि current state को historical text snapshots के रूप में represent किया गया था पहली जगह में। एक data-architecture failure, retrieval failure नहीं। Live state को text के रूप में index किया गया था, तो system past snapshots के corpus को search किया बजाय system of record को query करने के। Similarity truth नहीं है। Embedding similarity confidently दो stale snapshots को एक answer में merge किया। एक higher similarity score का मतलब एक truer answer नहीं है; इसका मतलब है retrieved text semantically close था query के लिए, जो same thing नहीं है जब underlying state change हुआ है जब से text लिखा गया। Fix एक tool call है। Not एक better chunker, एक shorter refresh interval, या एक higher similarity threshold: एक tool call order-status service को। Knowledge base FAQ content को keep करता है। Transactional database orders को keep करता है। दो types data, दो access patterns, दो mechanisms।

Retrieval principle Retrieval stable knowledge के लिए है: चीजें जो कल true थीं और कल true होंगी। Tool use live state के लिए है: चीजें जिनका current value एक system द्वारा owned है और independently change करता है आपके index से। उन्हें conflate करना answers produce करता है जो fluent, confident, और गलत हैं तरीकों में जो hard हैं detect करने के लिए क्योंकि system कोई error signal नहीं दिखाता है। Model एक response return किया। Response correct दिखता था। Customer को false information मिली अपने order के बारे में।

Screen 18: Diagram को critique करें

Checkpoint 6 min · Reference Architectures

Diagram को critique करें Practice: एक partner के draft architecture को review करें नीचे एक customer-service assistant का एक reference-architecture sketch है। छह components list किए गए हैं। तीन को select करें जो इस routing design के लिए misapplied हैं। Select exactly 3 components that are misapplied.

1Intent classifier (Claude call)

↓↓

2Retrieval over "Order Status Index" 3Retrieval over "Product Manual Corpus"

↓↓

4Agent loop with tool entry point: refund, cancel, update-address 5(missing) Escalation path to human agent

↓↓

6Response composer (Claude call)

Submit Skip for now

Screen 19: Chunking और indexing

Teaching 10 min · RAG Pipeline Design

Chunking और indexing Previous screen पर reference-architectures ने RAG को एक known-good shape के रूप में name किया और दिखाया जहाँ यह misapplied है। यह screen एक level deeper जाता है, retrieval pipeline के design में: कैसे एक corpus को chunks में break किया जाता है, कैसे वे chunks indexed हैं, और कैसे retrieval strategy को query patterns से match किया जाता है system देखेगा।

Chunking: कैसे आप corpus को break करते हैं, किस से corpus है एक chunk unit है जो retrieve होता है। Chunking approach source material की structure द्वारा chosen है, एक default size द्वारा नहीं।

Chunking approachHow it worksWhen it earns its place

Fixed-sizeUniform spans में split करें (overlap के साथ) regardless of structure।Homogeneous, unstructured text जहाँ natural boundaries weak हैं; simplest to operate। SemanticMeaning boundaries पर split करें, topic shifts, sentence groups जो hang together।Prose जहाँ एक retrieved chunk self-contained होना चाहिए अच्छी तरह answer करने के लिए; reduces mid-idea cuts। HierarchicalDocument structure को preserve करें, sections, subsections, और retrieve करें level पर जो fit करता है।Structured documents (contracts, manuals, policies) जहाँ section context meaning carry करता है।

Indexing: कैसे आप chunks को findable बनाते हैं, कैसे queries phrase किए जाते हैं Indexing decide करता है कि "similar" क्या मतलब है जब एक query arrive करता है। Strategy query pattern द्वारा chosen है।

Indexing strategyWhat it matchesWhen it earns its place

Dense (embeddings)Semantic similarity, meaning, not words।Queries phrased differently from the source; paraphrase, intent, concept matching। Sparse (keyword, e. g. BM25)Exact terms, identifiers, codes, names।Queries जो hinge करते हैं specific tokens पर: part numbers, statute citations, error codes। HybridBoth, results combined के साथ।Mixed query patterns, common production case; recovers exact-match results dense retrieval misses।

जब एक hybrid index दो ranked lists return करता है, उन्हें एक में merge किया जाना चाहिए। Reciprocal rank fusion standard है, low-tuning way: प्रत्येक result को score किया जाता है इसके rank द्वारा प्रत्येक list में, और combined score items को favor करता है जो दोनों में well rank करते हैं। Architect के लिए point dense और sparse results को combine करना एक design decision है एक known, defensible default के साथ।

Tradeoff को articulate करना हर retrieval design तीन चीजों के बीच tradeoffs बनाता है:

Retrieval quality: क्या right chunk back आता है? Latency: Retrieval प्रत्येक request में कितना time add करता है? Maintenance: Pipeline को correct रखने में कितना cost होता है जैसे corpus grow और change करता है?

Smaller chunks और hybrid indexing quality और latency को together raise करते हैं; larger chunks और dense-only indexing latency और maintenance को lower करते हैं लेकिन exact-match queries को miss करते हैं। कोई universally right point नहीं है, केवल point जो इस corpus और इन queries को fit करता है, एक tradeoff के रूप में stated जो आप defend कर सकते हैं।

Cost · Complexity · Risk Cost: Hybrid indexing और smaller chunks दोनों retrieval compute को raise करते हैं और per-request latency को। Pipeline को size करें query patterns को आप actually have, most thorough को imaginable नहीं। Complexity: हर chunking और indexing choice कुछ है maintain करने के लिए जैसे corpus change करता है। एक pipeline जो launch पर correct था silently degrade कर सकता है जैसे documents add होते हैं। Risk: Failure mode एक confident answer है built wrong chunk पर। Retrieval quality output में visible नहीं है, इसे एक labeled set के विरुद्ध measure किया जाना चाहिए, जो यह काम को directly evaluation में tie करता है।

Screen 20: RAG pipeline को design करें

Exercise 8 min · RAG Pipeline Design

RAG pipeline को design करें Brief एक professional-services partner के पास roughly 4,000 documents का एक corpus है: client engagement contracts (highly structured, section-numbered), past project write-ups (long-form prose), और एक methodology handbook (structured, defined procedures के साथ)। उनकी team तीन kinds questions पूछती है: "methodology क्या कहता है X के बारे में? " (concept lookup), "Acme contract में termination clause को find करें" (exact-target lookup), और "summarize करें कि कैसे हमने engagements को handle किया है जैसे यह एक" (broad synthesis across write-ups)। अपने pipeline design को draft करें। तीन document types में से प्रत्येक के लिए, chunking approach को name करें जो आप use करेंगे और explain करें क्यों। फिर full corpus के लिए indexing strategy को name करें और state करें tradeoff आप बना रहे हैं। अपने answer को लिखें इससे पहले कि आप reveal करने के लिए click करें। Feel free को ask करें Claude अपने लिखे हुए को compare करने के लिए provided answer के साथ।

Your pipeline design

Reveal the model answer Skip for now

Contracts और methodology handbook: Hierarchical chunking जो section और subsection structure को preserve करता है। दोनों sources structured हैं और section-numbered, तो retrieving section level पर clause या procedure को intact रखता है और self-contained। Fixed-size chunking section boundaries के across cut करता है और structural context को lose करता है query depend करता है। Project write-ups: Semantic chunking meaning boundaries पर ताकि प्रत्येक retrieved chunk self-contained हो। Long-form prose के पास section numbers नहीं हैं hierarchical chunking को anchor करने के लिए, और fixed-size chunks mid-idea cut करते हैं। Semantic chunking प्रत्येक retrieved passage को coherent enough रखता है अपने आप पर question को answer करने के लिए। Indexing strategy: Hybrid dense-plus-sparse। Query set exact-clause lookups को mix करता है ("find the termination clause in the Acme contract") open-ended conceptual questions के साथ ("how did we approach X? ")। Sparse exact-target lookups को handle करता है जहाँ specific identifiers matter; dense concept-lookup और synthesis queries को handle करता है जहाँ meaning, not exact terms, match को drive करता है। न तो alone दोनों patterns को cover करता है। Dominant tradeoff: query variety load-bearing constraint है। Hybrid index retrieval compute को add करता है और एक rank-fusion step, लेकिन वे costs अपनी जगह earn करते हैं क्योंकि query set genuinely दोनों modes को need करता है।

आपका design कैसे compare किया?

Correct: मेरा design match किया Partial: close, लेकिन एक piece पर off Incorrect: मैंने structure को miss किया

Screen 21: Model, context window, और context strategy

Teaching 13 min · Model & Context Strategy

Model, context window, और context strategy इस point तक आपके पास एक pattern और एक reference architecture होना चाहिए, लेकिन एक shippable system नहीं। तीन decisions remain करते हैं, और प्रत्येक determine करता है कि same architecture production volume पर क्या cost करता है: 1. कौन सा model task को fit करता है, 2. Actually कितना context window को use करना है, और 3. क्या आपकी context strategy progressive या monolithic होनी चाहिए। ये decisions production volume पर हर request के across compound करते हैं।

Distinct terms जो conflate करना आसान है निम्नलिखित terms अक्सर practice में interchangeably use किए जाते हैं लेकिन उन्हें conflate करना reference architecture mistakes produce करता है। प्रत्येक term को carefully review करने के लिए समय लें detail में:

Context window। Model की active attention space। सब कुछ context window के अंदर reasoning के लिए available है और सब कुछ बाहर model के लिए exist नहीं करता। Context window calls के बीच reset होता है जब तक आपका application explicitly continuity को manage नहीं करता। Retrieval। Fetched external knowledge, pulled at query time एक corpus से model memory में hold नहीं करता। Retrieval context window को augment करता है; यह replace नहीं करता। Model केवल देखता है क्या retriever surface करता है। Persistent application state। Owned और managed आपके system द्वारा, model द्वारा नहीं। Order status, user records, account balances। Model के पास inherent access नहीं है और एक tool call को require करता है इसे get करने के लिए। Summaries और memory layers। Application-managed continuity turns या sessions के across। Model के पास calls के बीच native memory नहीं है, तो कुछ भी जो persist करता है ऐसा करता है क्योंकि आपका application इसे store किया और pass back किया। यह एक architectural choice है, model capability नहीं।

Model selection: Sonnet से start करें, deliberately move करें Claude model family currently Opus, Sonnet, और Haiku से consist करता है, प्रत्येक अलग cost, latency, और capability tradeoffs के लिए optimized। Opus Anthropic का सबसे capable model है available use के लिए, demanding reasoning, advanced coding, और research synthesis के लिए suited जहाँ Sonnet आपके quality bar को meet नहीं करता। Default starting point अभी भी Sonnet है। Opus को move करें केवल जब एक eval set आपको बताता है Sonnet आपके quality bar को meet नहीं कर रहा। Haiku को move करें केवल जब एक eval set confirm करता है quality tradeoff acceptable है आपके specific task के लिए। आपका decision models को move करने के लिए हमेशा measured होना चाहिए, reflexive नहीं।

Context-window sizing: working-memory cliff सब कुछ model attends करता है context window में रहता है। Window के अंदर, attention available है। बाहर, model के पास कोई access नहीं है। Working memory चार में property है hardest edge के साथ: चीजें काम करती हैं जब तक वे नहीं करतीं, और फिर transition abrupt है। Context window tokens में measured है। कितना text एक token cover करता है model generation, tokenizer, और language द्वारा vary करता है, तो किसी भी fixed characters-per-token ratio को एक rough illustration के रूप में treat करें बजाय एक rule के। Measure करें estimating के बजाय: हर API response actual token counts को इसके usage field में report करता है, और वे measured counts हैं context limit और billing apply करते हैं। सब कुछ context window में enter करता है, आपकी system prompt, conversation history, retrieved documents, tool outputs, और model के responses, tokens में counted है। यह दो reasons के लिए matter करता है: context window एक fixed token limit है, और आप हर API call पर per token के लिए billed होते हैं। दोनों constraints directly इस section में covered decisions में show up करते हैं। Practical implication direct है: full window को budget न करें। Budget largest realistic conversation के लिए, plus retrieved context, plus system prompt, plus working scratch, plus margin for growth। Context window एक ceiling है, target नहीं, तो designing towards ceiling का मतलब आप production में इसे hit करते हैं।

Context strategy: progressive और monolithic के बीच spectrum हर production workload एक choice बनाता है, implicitly या explicitly, कैसे context model तक reach करता है हर call पर। Choice एक spectrum पर sit करता है दो poles के बीच। एक end पर, एक monolithic context strategy सब कुछ को prompt में एक बार place करता है: full document, full conversation history, full retrieved corpus। यह bounded tasks के लिए काम करता है predictable input sizes के साथ। यह भी strategy है जो working-memory cliff को production में hit करता है, क्योंकि context accumulate करता है turns के across और window silently fill होता है इससे पहले कि किसी को notice हो कुछ truncated हुआ है। दूसरे end पर, एक progressive context strategy context को stage करता है: यह just-in-time retrieve करता है, turns के across summarize करता है, और केवल load करता है क्या next step को need है। अधिकांश production workloads यहाँ belong करते हैं। दो अन्य patterns poles के बीच sit करते हैं और अक्सर enough show up करते हैं उन्हें strategies के रूप में treat करने के लिए। नीचे दी गई table लays out करता है जहाँ प्रत्येक strategy अपनी जगह earn करता है और जहाँ वे break down करते हैं। प्रत्येक strategy को expand करें देखने के लिए जहाँ यह अपनी जगह earn करता है और जहाँ यह break down करता है।

Monolithic, full required context को एक single prompt में loadWhere it earns its place:Bounded tasks with predictable input size. Stable prefixes जो prompt caching से benefit करते हैं. Single-shot Q&A जहाँ retrieval latency pay करने के लिए worth नहीं है. Reasoning जो genuinely सभी material के simultaneous access को require करता है. Where it breaks down: Conversations या tool loops जहाँ context accumulate करता है turn over turn. Cost और latency linearly scale करते हैं input length के साथ. Attention quality बहुत long contexts पर degrade कर सकता है well before hard limit। Progressive, carry forward केवल क्या next step को needWhere it earns its place:Multi-turn dialogue और iterative refinement. Agent loops जहाँ प्रत्येक step mainly recent state पर depend करता है. Workflows जो stages में decompose करते हैं narrow, well-defined handoffs के साथ. Right default अधिकांश production workloads के लिए. Where it breaks down:Tasks requiring long-range coherence across full history. Decisions जो depend करते हैं detail dropped एक earlier turn में. Prompt caching harder है जब carried-forward context mutates हर turn. Exact input model ने देखा step N पर अब longer है reconstructable, जो debugging को complicate करता है. Retrieval (RAG), fetch relevant chunks एक external store से at query timeWhere it earns its place:Knowledge bases बहुत बड़े fit करने के लिए context में. Sources जो change करते हैं faster than prompt को redeploy किया जाता है. Domains जहाँ कोई भी single query केवल available material का एक small slice को need करता है. Cases जहाँ source citation एक requirement है. Where it breaks down:Queries requiring synthesis across many documents retriever independently scores. Chunking जो split करता है semantic units जैसे tables, code blocks, या multi-paragraph arguments. Recall failures जहाँ correct document कभी top-k में enter नहीं करता. Retrieval quality एक system बन जाता है आपको evaluate और maintain करना चाहिए. Compaction, periodically summarize या compress accumulated contextWhere it earns its place:Long-running agents और conversations जहाँ full transcript wasteful है लेकिन recent state matter करता है. Phase transitions multi-step workflows में जो एक clean summary को checkpoint कर सकते हैं. Sessions जो otherwise context limits को hit करेंगे mid-task. Where it breaks down:Summaries जो drop करते हैं load-bearing detail: exact identifiers, numeric values, prior decisions, edge cases mentioned once. Summarizer itself एक model call है latency, cost, और failure modes के साथ. Compaction largely one-way है. Measuring summary fidelity against original transcript एक unsolved evaluation problem है.

Practice में, strategies को combine किया जा सकता है चार strategies ऊपर separately presented हैं learning clarity के लिए, लेकिन production systems almost always उन्हें combine करते हैं। प्रत्येक context problem के एक अलग dimension को handle करता है, तो एक well-designed system deliberately उन्हें layer करता है बजाय एक को pick करने के। एक worked example, long-running coding agent:

PhaseWhat's happeningStrategy in play

Session startLoad task description और few files user explicitly referencesMonolithic prefix, एक small, stable context loaded once, ideal for prompt caching. Active workप्रत्येक tool call (read file, run tests, edit) working context को appendProgressive recent state, latest additions क्या next step को need है. DiscoveryAgent realize करता है इसे एक file की जरूरत है यह initially load नहीं किया; codebase को search करता है और matches को pullJust-in-time retrieval, corpus बहुत बड़ा है preload करने के लिए, और केवल relevant slice को fetch किया जाता है on demand. Context fillingBहुत सारे turns के बाद, early exploration space ले रहा है; conclusions matter करते हैं लेकिन verbatim tool outputs नहीं करते हैं. Compaction, summarizes "क्या हमने try किया और क्या हमने learned," preserving केवल insights और decisions जो काम को carry करते हैं forward.

Notice करें कि कोई भी single strategy इस workload को carry नहीं कर सकता। Monolithic alone context limit को hit करता है। Progressive alone के पास कोई way नहीं है code को surface करने के लिए agent initially load नहीं किया। Retrieval alone thread को lose करता है क्या try किया गया है। Compaction alone के पास कुछ नहीं है compact करने के लिए जब तक अन्य strategies trajectory को build नहीं किए हैं। Architectural takeaway: जब एक context system को design कर रहे हैं, अपने आप से ये separate questions को ask करें:

Model को start पर क्या चाहिए? → monolithic baseline को drive करता है इसे most recent steps से क्या चाहिए? → progressive window को drive करता है इसे on demand fetch करने की क्या जरूरत हो सकती है? → retrieval layer को drive करता है Earlier material को क्या compress किया जा सकता है decision-relevant detail को lose किए बिना? → compaction policy को drive करता है

Context strategy और context sizing separate decisions हैं जो interact करते हैं लेकिन एक दूसरे को determine नहीं करते। उन्हें एक के रूप में treat करना जहाँ अधिकांश context-management designs गलत जाते हैं।

Extended thinking क्या control करता है Extended thinking एक per-request capability है: model problem को एक separate block of thinking tokens में काम करता है इससे पहले कि यह final answer produce करता है। कैसे आप इसे control करते हैं model generations के across बदल गया है। Claude Opus 4. 6 और later, Claude Sonnet 4. 6 और later, और Claude Sonnet 5 पर, adaptive thinking effort parameter के साथ recommended control है: आप set करते हैं कितना reasoning effort apply करना है बजाय एक token budget को configure करने के। Adaptive thinking Claude Fable 5 पर only thinking mode है। Older manual thinking-token budget (budget_tokens) 4. 6 generation पर deprecated है और Claude Sonnet 5 पर removed है, जहाँ यह एक 400 error return करता है; verify करें current model support platform. claude. com के विरुद्ध publish time पर। Thinking tokens output tokens के रूप में billed होते हैं model के standard output rate पर और उन्हें generate करना call को latency add करता है। जब extended thinking engaged नहीं है, कोई भी वे tokens generate नहीं होते हैं और कोई भी billed नहीं होते हैं। Decision extended thinking को use करने के लिए anchor करता है कि क्या एक call को एक billed reasoning pass को add करना है। Model किसी भी तरीके से internally reason करता है। क्या आप choosing करते हैं कि क्या एक expanded pass के लिए tokens और latency को spend करना है। Models पर जो extended thinking को support करते हैं, API एक summarized representation को thinking process का return कर सकता है बजाय full reasoning output के। आप thinking tokens को actually consumed करने के लिए billed होते हैं reasoning के दौरान, visible summary की length नहीं। एक बार वह distinction clear है, decision rule straightforward है। Extended thinking एक cost और latency tradeoff है। अपने evals को बिना इसके run करें पहले: यदि accuracy अभी भी आपकी requirements को meet नहीं कर रहा है prompt पर काम करने के बाद, तब extended thinking को enable करने पर consider करें। Extended thinking engaged के साथ, आप thinking tokens के लिए pay करते हैं और additional latency हर call पर। Case को turn करने के लिए एक measured accuracy gap से आना चाहिए, assumption नहीं कि यह एक mode है जो "hurt नहीं कर सकता।" उस evidence के बिना, आप cost को pay कर रहे हैं कोई proof के साथ नहीं कि यह आपके accuracy metrics को move कर रहा है।

हर model change को एक eval के साथ gate करें इससे पहले कि आप इसे ship करें Model में कोई भी change system के behavior में एक change है। दो models के बीच एक swap एक code deployment है और ऐसे treat किया जाना चाहिए। Minimum पर आपको तीन चीजों की जरूरत है:

एक curated test set prompts का known-good outputs के साथ जो real distribution को cover करता है काम का system देखता है एक grading function (model-graded एक rubric के विरुद्ध, या programmatic जहाँ आप check को code में express कर सकते हैं) एक delta threshold set in advance जिसके नीचे आप ship नहीं करते। Threshold को set करें इससे पहले कि आप eval को run करें। यदि आप इसके बाद set करते हैं, आप standard set नहीं कर रहे हैं, आप acceptance criteria को build के बाद लिख रहे हैं।

Worked case: एक Sonnet to Haiku downgrade, well done नीचे दिया गया case एक real production constraint के विरुद्ध एक model downgrade run का full sequence दिखाता है। Pattern को carry करने के लिए अपने काम में rollback criterion है: advance में set, refused to negotiate जब data आया, और एक partial migration को motivate करने के लिए use किया बजाय एक full के। एक document-intelligence pipeline छह महीने के लिए Sonnet पर run हुआ है और अपना entire budget use किया है। अब team Haiku को move करना चाहता है।

Team एक eval set build करता है 250 representative documents का hand-validated extraction targets के साथ, stratified across document types जो production traffic में show up करते हैं। Sample को size किया जाता है ताकि per-document-type scores meaningful रहें, केवल overall average नहीं। Team दोनों models को same set के विरुद्ध run करता है और प्रत्येक extraction को same grading rubric के साथ score करता है। Regression signature back आता है as follows: Sonnet 0. 94 पर average score करता है, Haiku 0. 86 पर average score करता है, और variance दो document types में concentrated है जहाँ Haiku 0. 71 और 0. 74 पर score करता है respectively। Rest of the document types tolerance के अंदर आते हैं। Rollback criterion advance में set किया गया था: यदि कोई भी single document type 0. 85 के नीचे drop करता है, migration rejected है। दो document types वह line को cross किए, तो migration as proposed rejected है। Salvage move उन दो document types को Sonnet को route करना है existing classifier के through, और अन्य types को Haiku को route करना है। Cost materially drop करता है बिना difficult document types पर regression लिए।

Specific scores के बजाय, आपका takeaway इस case से focused होना चाहिए कैसे rollback criterion को decide किया गया था data आने से पहले। यह meant जब data आया, team को अपने आप के साथ negotiate नहीं करना पड़ा, और eval set एक partial-migration option को surface किया जो एक single overall score hide किया होता।

Forward pointer Model selection और context strategy prompting-area levers में दो हैं। आप दो अन्य prompting area levers के बारे में सीखेंगे (system-prompt design और prompt reuse) later इस module में।

Cost · Complexity · Risk Cost: Monolithic context silent budget killer है। एक document-heavy pipeline में, एक conversation जो एक 4,000-token prompt के साथ start होता है turn 30 तक 80,000 tokens carry कर सकता है। Per-call cost conversation के साथ grow करता है, और कोई visible signal नहीं है जब तक यह billing में show up नहीं करता। Complexity: एक model swap एक one-line configuration change दिखता है, लेकिन यह rewrite करता है कैसे पूरा product behave करता है। Model swaps को releases के रूप में treat करें। Risk: कोई eval set नहीं means कोई rollback signal नहीं। एक regression production में discovered एक regression है जो कभी detect नहीं किया गया, क्योंकि by the time आप देखते हैं, user पहले से ही है।

Screen 22: जब everywhere को Opus default करना एक 7× cost overrun produce किया

Watch Out 4 min · Model & Context Strategy

जब everywhere को Opus default करना एक 7× cost overrun produce किया

Setup hook जब demo को land करना है और partner room में है, smart-sounding answer है "best available model use करें।" वह answer भी path of least resistance है build के दौरान: कोई eval set required नहीं, कोई choice को defend नहीं करना। Bill later आता है, और by then system live रहा है long enough कि downgrading एक associated change-management cost carry करता है।

Launch के 90 दिन बाद Symptom। Monthly cost सात times original modeling figure पर run हो रहा है। User-facing path पर latency 2. 3 seconds median पर sitting है, जो 800-millisecond target से well above है partner launch पर agree किया। Customer-satisfaction scores pre-launch baseline के compared move नहीं किए। Cause। Stack में हर call Opus use कर रहा है। Architecture document में कोई per-step model selection नहीं है, क्योंकि कोई per-step eval नहीं था जो per-step selection को make करना होता। Team "best available model" को default किया build के दौरान और कभी revisit नहीं किया एक बार traffic live था। Contributing factors। तीन चीजें compound किए: Original architecture document model-tier decision को किसी भी step पर include नहीं किया, तो implicit default deployment तक carry किया। Cost को monthly review किया गया बजाय development के दौरान determined किए गए, तो gap projected और actual spend के बीच surface नहीं किया जब तक weeks बाद launch के। Extended thinking एक routing classifier पर enable किया गया था जिसे reasoning की जरूरत नहीं थी, और वह setting measurable latency और cost को हर request को add किया जो classifier के through pass किया। क्या team ने change किया। Team एक eval set retroactively build किया, covering काम प्रत्येक pipeline step actually कर रहा था। उन्होंने classifier step को Haiku को route किया और eval पर कोई regression confirm किया। उन्होंने mid-pipeline summarization को Sonnet को route किया और confirm किया कोई regression नहीं। उन्होंने Opus को final response-composition step पर keep किया, जो एक जगह था eval ने कहा higher tier अपनी जगह earn किया। Monthly cost 71% drop किया। Latency 940 milliseconds median को drop किया। Customer-satisfaction scores unchanged रहे।

कैसे एक model-tier decision एक budget conversation बन जाता है तीन failure mechanisms compound किए, और प्रत्येक एक advance में recognizable है।

पहला: "no model-tier decision" itself एक implicit decision था, और system most expensive option को default किया। Deliberate choice की absence neutral नहीं है। दूसरा: cost visibility build से weeks lag किया। Bill launch के बाद आया, partner पहले से ही live चला गया था। वह cost conversation को design से move किया change management में। तीसरा: eval set build के दौरान exist नहीं किया, तो जब "best model use करें" propose किया गया, team के पास कुछ नहीं था point करने के लिए जो एक अलग choice को ground किया होता। Eval set केवल release gate नहीं है, यह एक चीज़ है जो model decision को defensible बनाता है design conversation के दौरान।

क्यों यह break करता है? एक model को choose न करना most expensive को choose करने के बराबर है। एक eval set upfront extra work दिखता है लेकिन यह भी एक चीज़ है जो model decision को defensible बनाता है।

Screen 23: Cost & latency calculator

Checkpoint 9 min · Model & Context Strategy

Cost & latency calculator Configurations को explore करने के लिए calculator को use करें। Model tier (Opus / Sonnet / Haiku), context strategy (monolithic / progressive), calls per day, और extended thinking (on / off) को set करें। Readouts cost और latency को प्रत्येक setting के लिए दिखाते हैं। आपका goal: एक configuration को find करना जो दोनों cost ceiling और latency budget को same time पर meet करता है, दोनों को trade नहीं किया जा सकता। Calculator केवल values display करता है; यह आपकी exploration को score नहीं करता। एक से ज्यादा valid configuration exist करता है।

Model tier OpusSonnetHaiku

Context strategy MonolithicProgressive

Calls per day

Extended thinking OffOn

Estimated monthly cost, Median latency,

Illustrative figures based on published list pricing as of June 2026 (current per-million-token input/output pricing for Opus, Sonnet, और Haiku, available at docs. claude. com)। Verify करें current pricing और latency at docs. claude. com इससे पहले कि आप इन numbers पर एक partner के साथ rely करें।

Decision: load-bearing control को identify करें एक बार आपके पास एक configuration है जहाँ दोनों readouts budget के अंदर हैं, ask करें: कौन सी single setting, यदि relaxed, एक budget को breach करेगी पहले?

A. Call volume, क्योंकि यह एक input है आप change नहीं कर सकते। B. Dominant constraint का control, उदाहरण के लिए, यदि latency tight budget है, model tier या extended-thinking setting जो latency को drive करता है। C. None; कोई भी setting को freely change किया जा सकता है एक बार दोनों readouts green हैं।

Submit Skip for now

एक बार आपके पास एक passing configuration है और ऊपर correct answer को select किया है: 2–3 sentences में, dominant constraint को name करें आपके passing configuration में और identify करें single setting जो इसके लिए load-bearing है। अपना answer लिखें, फिर नीचे model answer को reveal करें।

Your rationale

Reveal the model answer Dominant constraint depend करता है कि कौन सा budget आपके configuration में tighter था। यदि latency binding constraint है, model tier और extended-thinking setting load-bearing हैं, वे controls हैं जो most directly latency को move करते हैं। यदि cost binding है, tier और context strategy load-bearing हैं। Load-bearing control वह है tied करता है whichever budget को least margin था। Naming इसे explicitly क्या configuration को defensible बनाता है बजाय lucky के।

Screen 24: System prompts, templates, और guardrails को design करना

Teaching 10 min · Prompting as Architecture

System prompts, templates, और guardrails को design करना Model और context screen model tier को choose करने और एक context strategy को cover किया। अन्य major lever उस decision area में prompt itself है। Enterprise scale पर prompt एक sentence नहीं है आप type करते हैं, लेकिन एक asset है आप design करते हैं: एक system prompt, एक reusable template, और guardrails जो दोनों को safe और consistent रखते हैं। यह prompting as an architectural discipline पर तीन screens में से पहला है।

Enterprise reuse के लिए system-prompt architecture एक system prompt एक one-off chat के लिए और एक system prompt जो hundreds of requests a day depend करते हैं अलग artifacts हैं। Enterprise version reuse के लिए designed है, जिसका मतलब है इसके पास structure है: role और scope का एक clear statement, constraints model को hold करना चाहिए (क्या यह नहीं करना चाहिए, क्या यह हमेशा करना चाहिए), और एक output contract जो shape name करता है response को लेना है। जब एक system prompt scale पर reuse किया जाता है, ambiguity एक defect है multiplied हर request के across।

Templates: consistency और safety, enforced एक template एक system prompt है parameterized slots के साथ (parts जो change करते हैं per request) और fixed scaffolding के साथ उनके चारों ओर। Design goal यह है कि fixed scaffolding consistency और safety guarantees को carry करता है, तो एक slot को fill करना accidentally एक constraint को remove नहीं कर सकता। एक well-designed template safe path को default path बनाता है: person using इसे variable content को supply करता है और guardrails को inherit करता है बिना उन्हें re-author किए।

Description: prompt design पर applied चार AI Fluency competencies में से एक Description चार AI Fluency competencies में से एक है, discipline precisely बताने का model को क्या आप चाहते हैं: task का scope, output का format, और constraints जो इसे bound करते हैं। Prompt design पर applied, Description वह है जो एक prompt को separate करता है जो एक demo में काम करता है एक से जो production में hold करता है। एक well-described prompt names:

Scope: क्या in और out of bounds है Format: Exact output contract Constraints: Rules जो कभी violated नहीं होने चाहिए

Underspecification एक gap है model fill करता है अपने assumption के साथ, differently हर बार, और key failure है watch करने के लिए।

Underspecification gaps को diagnose करना Architect की skill यहाँ एक prompt को read करना है क्या यह fail करने के लिए। जहाँ prompt silent है, model improvise करता है और improvisation exactly non-determinism है आप एक reused asset में नहीं चाहते। Gap को diagnose करना means asking, प्रत्येक requirement के लिए output को meet करना चाहिए, क्या prompt actually state करता है या merely hope करता है। Fix implicit को explicit बनाना है: goal को restate करें instruction के साथ, format को name करें, और constraints को bound करें।

Cost · Complexity · Risk Cost: एक vague system prompt हर request में paid होता है जिसे correction, retry, या human cleanup की जरूरत है। Prompt को well design करना एक बार far cheaper है than diagnosing drift thousands of calls के across। Complexity: Templates complexity को एक जगह में concentrate करते हैं जहाँ इसे reviewed और governed किया जा सकता है, बजाय ad-hoc prompts के across scattered करने के कोई own नहीं करता। Risk: एक underspecified guardrail एक missing से worse है, क्योंकि यह एक control की appearance create करता है substance के बिना। एक constraint model quietly route कर सकता है around एक constraint नहीं है।

Screen 25: Prompt engineering techniques across models

Teaching 7 min · Prompting as Architecture

Prompt engineering techniques across models एक बार एक prompt design किया जाता है reuse के लिए, next question कौन सी technique use करना है इसके अंदर। Technique task की complexity द्वारा chosen है, habit द्वारा नहीं। यह screen main techniques को cover करता है, कैसे choice models के across change करता है, और कैसे prompt में bias को build करने से avoid करना है।

Technique selection by task complexity

TechniqueWhat it isWhen it fits

Zero-shotInstruction only, कोई examples नहीं. Well-specified tasks model पहले से ही reliably handle करता है; default को try करने के लिए। Few-shotएक handful of input/output examples prompt में. Tasks जहाँ desired format या judgment show करना easier है describe करने से। Chain-of-thoughtPrompt model को reason करने के लिए step by step इससे पहले कि answer करें. Multi-step reasoning, arithmetic-like logic, या tasks जहाँ path answer को matter करता है।

Progression deliberate है: zero-shot से start करें, केवल examples add करें यदि task को उन्हें need है, और explicit reasoning को केवल add करें यदि task की structure इसे demand करता है। प्रत्येक step tokens और latency को add करता है, तो lightest technique को reach करें जो requirement को meet करता है।

Behavioral differences across models Same prompt identically behave नहीं करता models के across या generations। एक more capable model को कम scaffolding की जरूरत हो सकती है (fewer examples, कम explicit step-by-step instruction) same quality तक पहुँचने के लिए, जबकि एक less capable model को ज्यादा की जरूरत हो सकती है। एक prompt एक model के लिए tuned एक starting point है दूसरे के लिए, एक finished artifact नहीं। यही कारण है कि एक model swap एक release के रूप में treat किया जाता है और एक evaluation के साथ gated: prompt-model pairing वह है आप actually shipping कर रहे हैं।

Prompt construction में bias को avoid करना Prompt construction bias को introduce कर सकता है task कभी intended नहीं किया। Leading phrasing, unbalanced examples (few-shot sets जो केवल एक kind of case दिखाते हैं), और assumptions baked instruction में सभी output को steer करते हैं तरीकों में जो easy हो सकते हैं miss करने के लिए। Discipline neutrally phrase करना है, examples को balance करना cases के across system actually देखेगा, और check करना कि क्या prompt एक answer को presume करता है यह elicit करना चाहिए।

Checkpoint: technique-selection matrix नीचे दिए गए प्रत्येक task के लिए, technique (zero-shot / few-shot / chain-of-thought) को select करें और एक one-sentence reason को type करें। दोनों submit करने से पहले required हैं।

Task 1. एक customer support ticket को पाँच standard categories में से एक में classify करें: billing, technical, returns, account, या general. Choose... Zero-shotFew-shotChain-of-thoughtCorrect: Zero-shot। Task well-specified है, categories named हैं, और model classification को reliably handle करता है examples के बिना। Task 2. Structured fields, date, vendor, और amount, को extract करें expense receipts से जो layout और formatting में widely vary करते हैं. Choose... Zero-shotFew-shotChain-of-thoughtCorrect: Few-shot। Desired extraction format demonstrate करना easier है examples के साथ describe करने से, especially given layout variation। Task 3. Determine करें कि क्या एक multi-step contract clause एक liability create करता है तीन conditions के तहत जो एक दूसरे के साथ interact करते हैं. Choose... Zero-shotFew-shotChain-of-thoughtCorrect: Chain-of-thought। Answer एक sequence of conditional logic steps पर depend करता है; step-by-step reasoning के लिए prompting एक interaction को skip करने का chance reduce करता है। Task 4. एक 400-word product description को दो sentences में summarize करें. Choose... Zero-shotFew-shotChain-of-thoughtCorrect: Zero-shot। Standard summarization एक well-bounded input पर; examples या explicit reasoning steps को add करना tokens और latency को add करता है कोई quality gain के साथ नहीं।

Submit Skip for now

Cost · Complexity · Risk Cost: Heavier techniques tokens और latency को cost करते हैं हर call पर। Chain-of-thought एक task पर जिसे इसकी जरूरत नहीं है एक recurring tax है कोई gain के लिए। Complexity: Few-shot examples content हैं maintain करने के लिए: जैसे task evolve करता है, stale examples quietly model को steer करते हैं गलत। Risk: Prompt में introduced bias invisible है किसी भी single output में और केवल aggregate में show up करता है, जो यह neutral phrasing और balanced examples को एक design requirement बनाता है, एक polish step नहीं।

Screen 26: Caching mechanics, modular prompts, और Skills

Teaching 8 min · Prompting as Architecture

Caching mechanics, modular prompts, और Skills Reusable prompts एक question raise करते हैं one-off prompt कभी नहीं करता: कैसे आप उन्हें efficiently reuse करते हैं, और कैसे आप उन्हें package करते हैं ताकि एक team उन्हें share और govern कर सके? यह screen caching की mechanics को cover करता है, एक modular prompt library और एक Skill के बीच difference, और decision कि कौन सा use करना है।

एक cache जो कभी hit नहीं करता एक team अपने reusable analysis prompt को production में put किया और caching को supposed bring करने के लिए cost savings में से कोई नहीं देखा। Cause ordering था: उन्होंने per-request content (document being analyzed) को prompt के top पर place किया, large fixed instruction block से पहले। क्योंकि cache एक stable prefix पर match करता है, dynamic content को first put करना meant prefix हर request पर change किया और cache कभी hit नहीं किया। Fix reorder करना था fixed content के साथ first और dynamic content के साथ last।

Caching mechanics एक architect designs around Cache breakpoints। Caching एक stable prefix पर काम करता है। Mark करें boundary fixed part के बीच prompt (cacheable) और variable part (not), और fixed part को genuinely fixed रखें। Content ordering। Static before dynamic, always। Large, unchanging instruction block first जाता है; per-request content breakpoint के बाद जाता है। TTL selection। Match करें cache lifetime को कितनी बार fixed content actually change करता है और कितनी बार prompt को call किया जाता है। एक prompt constantly called को एक longer-lived cache से benefit करता है; एक rarely called को कभी amortize नहीं कर सकता write overhead। When the write overhead is not worth it। Cache को write करना अपनी cost है। यदि एक prompt infrequently called है या इसका fixed portion small है, caching cost कर सकता है ज्यादा than it saves। Caching एक design decision है, default नहीं everywhere को switch करने के लिए।

Modular prompt libraries vs Skills as versioned reusable units दो तरीके हैं एक prompt को reusable बनाने के लिए एक team के across। एक modular prompt library एक shared collection है prompt fragments और templates का engineers अपने code में assemble करते हैं। एक Skill एक more formal, versioned, self-contained unit है: एक SKILL. md जो instructions को package करता है, optional executable scripts, और version management, तो पूरी procedure एक governed artifact के रूप में travels। एक Skill reuse primitive है foundations screen में named (packaging एक repeatable procedure) prompting को applied।

Reuse decision: library या Skill

ConsiderationLean toward a prompt libraryLean toward a Skill

Repeatabilityएक assembled, often-tweaked prompt per use. एक stable procedure run same way हर बार। DistributionShared एक codebase या team के अंदर. Distributed teams या products के across जिन्हें same procedure की जरूरत है। GovernanceLightweight; engineers fragments को own करते हैं. Needs versioning, approval, और rollback, Skills carry करते हैं।

Cost · Complexity · Risk Cost: Caching substantially cost को cut कर सकता है जब यह hit करता है और cost को add करता है जब यह नहीं करता। Economics call frequency और prefix size पर depend करते हैं, तो उन्हें model करें committing से पहले। Complexity: एक Skill एक procedure को एक versioned unit में concentrate करता है जो reviewed और rolled back किया जा सकता है; copy-pasted prompts का एक sprawl नहीं कर सकता। Risk: एक ungoverned prompt जो teams के across copy किया जाता है slightly different versions में drift करता है, प्रत्येक अपने quietly different behavior के साथ। Versioned reuse control है।

Screen 27: Reusable prompt asset को author करें

Exercise 6 min · Prompting as Architecture

Reusable prompt asset को author करें Brief एक partner के support organization same operation को hundreds of times a day run करता है: एक customer के support ticket और product manual के relevant section को given, एक drafted reply produce करें जो partner के tone guidelines को follow करता है, manual section को cite करता है यह relied on, और कभी एक refund या एक timeline को promise नहीं करता partner ने approve नहीं किया। Reusable prompt asset को draft करें। तीन design decisions नीचे बनाएँ और प्रत्येक के लिए एक brief rationale लिखें:

Stable prefix कहाँ end होता है और per-request content कहाँ begin होता है? Breakpoint placement को name करें और explain करें क्यों। आप never-promise-a-refund guardrail को structurally कैसे enforce करते हैं, केवल एक stated instruction के रूप में नहीं? Output contract constraint को describe करें। क्या यह एक template या एक Skill के रूप में ship करना चाहिए? Packaging choice को name करें और reason को state करें।

अपना answer लिखें, फिर नीचे model answer को reveal करें। Feel free को ask करें Claude अपने लिखे हुए को compare करने के लिए provided answer के साथ।

Your prompt asset design

Reveal the model answer

Cache-breakpoint placement: Role, tone rules, output contract, और never-promise guardrail को first place करें stable prefix के रूप में, फिर ticket और manual section को only per-request content के रूप में। Dynamic content को breakpoint से पहले put करना meant prefix हर call पर change करता है और cache कभी hit नहीं करता। Hundreds of calls a day पर, stable prefix जहाँ cost savings रहते हैं। Enforcing the guardrail: इसे output contract में एक structural constraint के रूप में build करें format require करता है, role text में एक sentence के रूप में नहीं। एक rule role में stated को drift past किया जा सकता है। एक constraint output contract में built response format को shape करता है और quietly ignore नहीं किया जा सकता। Packaging: एक versioned Skill। Procedure stable है, run identically hundreds of times a day support org के across, और versioning और rollback की जरूरत है। एक pasted prompt template प्रत्येक agent locally keep करता है कोई central governance नहीं है, rolled back नहीं किया जा सकता, और slightly different versions में drift करता है over time।

Screen 28: Entry point, route, और governance selection

Teaching 11 min · Entry Points & Governance

Entry point, route, और governance selection आपने model को choose किया है और shape, और अब यह time है partner Claude को कैसे consume करता है choose करने के लिए। Partner को Claude consume करने के लिए choose करना तीन separate decisions को involve करता है, sequence में made। उन्हें right order में getting most common architecture mistakes को prevent करता है।

कौन सा entry point काम को fit करता है? कौन सा build-time interface team को suit करता है? कौन सा delivery route partner के cloud commitments को fit करता है?

तीन layers (entry points, build-time interfaces, और delivery routes) foundations section में vocabulary के रूप में सिखाए गए थे। यह screen selection work है: उन्हें real constraints के तहत choose करना।

Claude entry points: कैसे आप Claude के साथ interact करते हैं एक entry point wrapper है जो decide करता है कौन Claude से बात कर सकता है, Claude क्या touch कर सकता है, और कितना engineering partner को get करना चाहिए। Entry points को same intelligence के रूप में think करें अलग jobs के लिए packaged। गलत entry point को pick करना काम को break नहीं करता, लेकिन यह friction add करता है partner हर दिन feel करेगा। Claude. ai और Claude Code के परे, Anthropic तीन entry points ship करता है जो Claude को specific applications या environments में extend करते हैं। किसी भी partner workflows को build करने से पहले जो उनमें से किसी पर depend करते हैं, current capabilities, supported configurations, और availability को verify करें Anthropic के documentation के विरुद्ध। End-user entry points Entry pointDescriptionAudience and useCore tradeoff

Claude. ai (web, mobile, and desktop apps)End-user chat product Anthropic द्वारा hosted। एक signed-in user एक conversation को open करता है, files को attach करता है, Projects के through shared context को use करता है, और built-in connectors के through services को connect करता है जैसे Slack, Outlook, या Google Drive। यह consumer tiers (Free, Pro, Max) और Claude for Work में आता है। Claude for Work दो tiers है। Team tier admin controls, SSO और SAML, domain capture, और एक contractual commitment को add करता है customer content पर train न करने के लिए। Enterprise tier SCIM provisioning, configurable retention, audit logs, एक Compliance API, और एक HIPAA-ready option को add करता है एक signed BAA के साथ।Knowledge workers के लिए Claude को एक thinking partner के रूप में use करते हुए research, drafting, analysis, और review के लिए। कोई code नहीं लिखा जाता। Web app, mobile app, और Claude Desktop सभी same Claude. ai product तक reach करते हैं। यह end-user entry point है builders के लिए नहीं। Consumer tiers individuals और small teams को fit करते हैं और Claude for Work organizations को fit करता है जिन्हें governance और identity controls की जरूरत है same product पर।Zero build cost vs. zero integration entry point: आप product को get करते हैं Anthropic ships करता है और आप इसे embed नहीं कर सकते दूसरे product में या customize नहीं कर सकते क्या expose होता है। Right tier governance needs पर depend करता है: consumer tiers low-sensitivity work के लिए, Claude for Work जहाँ admin controls, SSO, और no-training commitments required हैं। Claude Code (terminal, IDE plugin, desktop, web)एक agentic coding tool जो files को read करता है, code को edit करता है, commands को run करता है, और multi-step engineering tasks को execute करता है configurable permission boundaries के तहत।Engineers के लिए real development work करते हुए: codebases को explore करना, files के across refactor करना, debugging, features को build करना। Product एक terminal में, IDE plugins में (VS Code, JetBrains, others), desktop पर, और web पर claude. ai/code पर run करता है। Same agent, wherever आप काम करते हैं।Purpose-built for engineering: Coding के लिए outstanding option लेकिन एक customer-service product या कोई non-engineering workflow के लिए wrong shape हो सकता है। Claude CoworkA desktop agent non-developers के लिए जो local files और applications के साथ काम करता है, user के machine पर file और task management को automate करता है configurable permissions के तहत।Operations, admin, और अन्य non-engineering roles के लिए जिन्हें Claude को actions लेने की जरूरत है उनके computer पर बजाय केवल एक chat window में text produce करने के। Claude Desktop app पर available सभी paid plans पर (Pro, Max, Team, Enterprise) macOS और Windows पर; Linux support beta में है।Real system actions vs. supervision overhead: Powerful file और task automation के लिए क्योंकि Cowork user के machine पर directly operate करता है, permission scoping और human review के साथ matter करते हैं ज्यादा than वे एक chat-only entry point में करते हैं। Claude in ChromeA browsing agent जो Chrome browser के अंदर operate करता है, pages को navigate करता है और user की ओर से actions लेता है।Knowledge workers जिनके tasks web applications में anchored हैं बजाय files या codebases में।N/A Claude for ExcelA spreadsheet agent जो Excel के अंदर operate करता है, directly cells, formulas, और structured data के साथ काम करता है।Analysts, finance teams, और कोई भी role जिसका primary working tool एक spreadsheet है।N/A

Build-time interfaces: कैसे आप Claude के विरुद्ध program करते हैं एक बार एक entry point pick किया जाता है, next decision कौन सी programmatic layer partner का code talk करता है। नीचे दी गई table चार build-time interfaces को describe करता है। API, SDKs, MCP, और Agent SDK हर case में एक दूसरे के alternatives नहीं हैं, वे एक दूसरे पर layer करते हैं। Build-time interfaces InterfaceDefinitionAudience and purposeTradeoff

Direct APIDirect HTTP interface Claude को। एक developer authenticate करता है, एक request भेजता है messages, एक model name, और parameters के साथ, और एक response back पाता है।Teams के लिए Claude को directly अपने product में build करते हुए। Partner का team सब कुछ own करता है: retries, streaming, tool use, observability, और UI। यह most foundational build-time interface है, और layer सब कुछ sits पर।Maximum control vs maximum responsibility: इसे use करें जब एक SDK एक feature को expose नहीं किया है आपको need है, या जब team raw HTTP को prefer करता है। SDKs (Python, TypeScript, Java, Go, Ruby, C#, PHP)SDKs same capability offer करते हैं API के रूप में, language-native types और helpers में wrapped जो boilerplate को cut down करते हैं। वे authentication, request formatting, retries, streaming, और tool-use plumbing को handle करते हैं idiomatic code में। Agent loop, यदि कोई है, अभी भी partner का code है।Teams के लिए same use case के रूप में direct API, लेकिन team language-native types, कम boilerplate, और built-in ergonomics को streaming और tool use के लिए चाहता है। Default choice embedding Claude के लिए एक product में।Ergonomics vs. control: SDK abstractions Anthropic के release cadence पर move करते हैं। यदि आपको एक raw API feature की जरूरत है SDK ने expose नहीं किया है, आप anyway HTTP को drop करेंगे। MCPएक open protocol tools, prompts, और resources को expose करने के लिए एक server से ताकि कोई भी MCP-aware client including Claude. ai, Claude Code, API, या एक third-party client उन्हें discover और use कर सके।एक single product में Claude के लिए calling convention नहीं, लेकिन एक sharing convention products के across। Teams के लिए जिन्हें same tools reachable होना चाहिए multiple Claude clients से। Same tool entry point दो या ज्यादा clients में needed है: Claude. ai, Claude Code, एक internal app, एक partner का product। Server को एक बार build करें, इसे everywhere connect करें।Reusability across clients vs. added architectural complexity: यदि केवल एक client कभी इसे use करेगा, MCP overhead add करता है बिना बहुत payback के। Agent SDK (@anthropic-ai/claude-agent-sdk)एक managed agent loop run करना, same loop जो Claude Code को power करता है, partner के अपने application code से। Package iteration, tool execution, और termination को handle करता है। Currently TypeScript (@anthropic-ai/claude-agent-sdk on npm) और Python (claude-agent-sdk on PyPI)।Teams के लिए जिन्हें Claude को multiple turns के over act करना चाहिए partner के अपने product के अंदर, partner के application के साथ surrounding workflow को control करते हुए, और Claude Code CLI wrong shape है। Common case: एक internal agent एक web app में embedded, एक terminal tool नहीं।Managed loop vs. custom orchestration: Agent SDK iteration और termination को handle करता है, लेकिन partner loop itself पर fine-grained control को give up करता है।

एक तरीका इन terms को separate रखने के लिए API और SDK: same entry point, अलग ergonomics। API और SDK same entry point हैं Claude के perspective से। SDK एक opinionated wrapper है API के ऊपर stacked। यह language-native types को add करता है, streaming और tool-use boilerplate को handle करता है, और partner के team को अपने preferred stack (Python, TypeScript, Java, Go, Ruby, C#, या PHP) में काम करने देता है बजाय raw HTTP के विरुद्ध। SDK default है अधिकांश teams के लिए। केवल reason raw HTTP को drop करने के लिए है जब एक freshly shipped API feature SDK में make नहीं किया है। MCP और API tool use: अलग layers, alternatives नहीं। MCP protocol है tools को share करने के लिए entry points के across, कैसे एक tool entry point को expose और discover किया जाता है multiple clients के across। API tool use है कैसे Claude एक tool को call करता है एक single request के अंदर। MCP और API tool use alternatives नहीं हैं। Under the hood, एक MCP server tools को expose करता है कि कोई भी MCP-aware client API tool use का उपयोग करके call कर सकता है। Choice down आता है कितनी बार आप feature को reuse करने जा रहे हैं: MCP को pick करें जब एक tool entry point multiple Claude clients से reachable होना चाहिए; raw API tool use को pick करें जब tools एक product के अंदर रहते हैं केवल। Claude Agent SDK: जब एक partner को एक agent loop की जरूरत है वे अपने product में embed कर सकते हैं। Partners और engineers अक्सर "SDK" को mean करने के लिए use करते हैं या तो Anthropic SDK या Agent SDK depending context पर। Anthropic SDK एक convenience wrapper है API के ऊपर। यह boilerplate को handle करता है लेकिन एक agent loop को run नहीं करता। Agent SDK managed runtime है जो loop को run करता है, same जो Claude Code को power करता है। Model एक tool को pick करता है, इसे run करता है, result को देखता है, और keep करता है जब तक task done नहीं है या एक stop condition fire नहीं करता। Partner इसे अपने application code से call करता है, और SDK rest को handle करता है। कौन सी layer को use करना है down आता है क्या Claude को करना चाहिए: एक request, एक response? API या SDK को use करें। Reusable tools multiple clients के across? MCP को use करें। Claude acting multiple turns के over partner के अपने product के अंदर? Agent SDK को use करें। तीन layers एक दूसरे के विरुद्ध काम करते हैं, एक दूसरे के विरुद्ध नहीं।

Claude Code: customization और governance layers Claude Code को choose करना एक दूसरे decision की start है: कौन सी customization किस layer पर belong करता है। एक layer, इस context में, एक discrete configuration entry point है जो एक aspect को control करता है कैसे agent thinks या acts: प्रत्येक एक independent है, composable, और एक अलग point पर applied agent के execution में। Layers दो groups में fall करते हैं: shape क्या agent knows और करता है (CLAUDE. md, skills, subagents, MCP), और govern क्या agent को touch करने की allow है (Hooks, permission boundaries, approval flows, sandboxing, और restricted execution)। Shaping layers और governing layers distinct हैं। यह split को right get करना क्या एक agent को दोनों useful और safe बनाता है production में run करने के लिए। Claude Code customization और governance layers LayerWhat it doesWhen it belongs here

SHAPING: क्या agent knows और करता है CLAUDE. mdएक markdown file loaded into context session start पर। Sets standing instructions, project conventions, और background knowledge agent को हमेशा होना चाहिए।Persistent context जो apply करता है हर task को project में (coding standards, repo layout, team conventions)। SkillsMarkdown-defined procedures Claude Code invoke कर सकता है on demand बजाय upfront loading के, keeping main context lean. Repeatable workflows team को spell out नहीं करना चाहिए हर बार। Typical examples एक commit-push-PR flow, एक release-notes generator, एक schema-migration procedure हैं। SubagentsAgent calling और creating additional agents को parse out करने के लिए sections एक task का या isolated context-window helpers के लिए bounded tasks जैसे code review या codebase exploration जो otherwise main thread को clutter करेंगे. काम जो run करना चाहिए read-only tools के साथ, एक restricted tool entry point, या एक अलग system prompt main session से। MCP serversExternal tools और data entry points को Claude Code से connect किए गए standardized protocol के ऊपर. जब same tool entry point को reusable होना चाहिए clients के across, उदाहरण के लिए जब team का Linear MCP server भी Claude. ai से काम करना चाहिए। GOVERNING: क्या agent को touch करने की allow है HooksScripts जो Claude code lifecycle events पर fire करते हैं (e. g. before/after एक tool run करता है, session start पर, stop पर), used as deterministic gates agent skip नहीं कर सकता. Deterministic gates agent को skip नहीं करना चाहिए, जहाँ guarantee code से आना चाहिए बजाय prompting से। Permission boundaries और approval flowsछह permission modes control करते हैं क्या Claude Code बिना prompting के कर सकता है। Default हर action से पहले ask करता है। acceptEdits file edits को approve करता है और common filesystem commands (mkdir, touch, rm, mv, cp, sed), though अन्य Bash commands अभी भी prompt करते हैं। Plan mode session को read-only lock करता है जब तक user एक plan को approve नहीं करता। Auto mode एक classifier को use करता है safe actions को approve करने के लिए और risky ones को block करने के लिए; यह एक research preview है जो सभी plans पर काम करता है (admin-enabled Team और Enterprise पर) और default करता है Anthropic API को provider के रूप में। एक environment variable CSP providers को enable करता है। dontAsk auto-deny करता है कुछ भी जो prompt करेगा और केवल run करता है क्या आपके allow rules cover करते हैं, जो इसे locked-down CI के लिए mode बनाता है। bypassPermissions सभी checks को skip करता है और containers या CI तक scoped है।कोई भी environment जहाँ एक unintended action की cost non-trivial है। Permissions govern करते हैं क्या agent को touch करने की allow है। Hooks govern करते हैं क्या एक action से पहले या बाद में happen करना चाहिए। Sandboxing और restricted executionContainment around workspace जिसमें Claude Code run करता है, including filesystem boundaries, network egress rules, और constrained command surfaces. कोई भी deployment जहाँ एक wrong action real consequences होंगे और जहाँ approval prompts alone एक sufficient backstop नहीं हैं। Environment itself को boundary को enforce करना चाहिए, केवल agent के judgment नहीं।

CSP delivery routes: जहाँ API traffic terminate होता है एक बार entry point और build-time interface pick किए जाते हैं, एक अधिक decision sits underneath: जहाँ API traffic terminate होता है? Same Claude model चार delivery routes के through available है। क्या differ करता है कौन सा cloud account spend land करता है, कौन सी identity system authentication को handle करता है, कौन सा region traffic terminate करता है, और कौन सी procurement contract partner पहले से ही sign किया है। Decision rule technical capability के बारे में नहीं है, model हर route पर same behave करता है। Rule क्या partner पहले से ही commit किया है के बारे में है। यदि partner पहले से ही एक long-term AWS contract है, Bedrock usually easiest path है, AI spend same agreement के तहत fall करता है जो उनके पास पहले से ही है, और identity system उनकी team use करता है (IAM) as-is काम करता है। Same logic apply करता है Vertex AI को GCP पर और Foundry को Azure पर: यदि partner उस cloud में रहता है, वह route use करें। Direct Anthropic API right call है जब partner के पास कोई strong cloud preference नहीं है, newest features को moment वे ship करते हैं चाहता है, या AI spend को Anthropic के साथ directly keep करना prefer करता है। एक tradeoff: CSP-mediated routes (Bedrock, Vertex, Foundry) tend करते हैं lag करने के लिए first-party API को weeks पर, कभी-कभी longer major capabilities के लिए। CSP delivery routes Delivery routeWhat it is और कैसे partner reaches itWhen to pick

Anthropic first-partyDirect Anthropic API at api. anthropic. com, billed by Anthropic, और authenticated एक Anthropic API key के साथ। SDKs Python, TypeScript, C#, Java, Go, PHP, और Ruby में इस entry point को wrap करते हैं।Partner के पास कोई binding cloud commitment नहीं है, newest features को day वे ship करते हैं चाहता है, या AI spend को consolidate करना prefer करता है directly Anthropic के साथ। Default choice जब कोई procurement constraint दूसरे तरीके को pull नहीं कर रहा है। AWS BedrockClaude served as एक managed model AWS पर। Called via Messages API at /anthropic/v1/messages AWS-managed infrastructure पर, billed partner के AWS account पर और authenticated through IAM। Previous Bedrock Runtime integration (InvokeModel/Converse via boto3 या AWS SDK) documented legacy path के रूप में remain करता है। Regional availability matter करता है और inference profiles cross-region routing problem को solve करते हैं।Partner के पास एक committed AWS enterprise agreement है, अपने stack का rest AWS पर run करता है, और AI spend को draw down करना चाहता है उस commitment के विरुद्ध। Identity, networking, और audit सभी existing AWS account से inherit करते हैं। GCP Vertex AIClaude served as एक managed model Google Cloud के Vertex AI Model Garden में। Called via Anthropic Vertex client या Google SDK, billed partner के GCP project पर, authenticated Google Cloud credentials के साथ। Models को per project में Model Garden console में enable किया जाता है।Partner GCP पर run करता है, उनके ML stack का rest Vertex AI में रहता है, और एक single billing और audit entry point को foundation models के across चाहता है। Microsoft Foundry (Azure)Claude served through Microsoft Foundry catalog Azure पर। Billed partner के Azure subscription पर, authenticated through Entra ID, deployed partner के Azure region में।Partner के पास एक Microsoft enterprise agreement है, identity को Entra ID के through run करता है, और उनके cloud footprint का rest Azure पर है। Foundry consolidate करता है AI procurement same paper पर। Note: Foundry Claude models को दो hosting forms में offer करता है: Hosted on Azure (generally available, inference partner के Azure environment में run करता है; as of this writing Opus 4. 8, Sonnet 5, और Haiku 4. 5, verify करें current list at publish time) और Hosted on Anthropic infrastructure (अन्य models, inference Anthropic-managed infrastructure को route करता है)। Partners strict data residency या GDPR requirements के साथ specific models के hosting form और compliance posture को verify करना चाहिए commit करने से पहले इस route को।

क्या routes के across change नहीं करता। Claude model itself same है regardless of route। Prompting, evaluation strategy, tool use, और context-window behavior सभी transfer करते हैं। क्या change करता है wrapper है: model identifiers और version strings routes के across differ करते हैं, regional availability differ करता है, और CSP-side features जो inference को wrap करते हैं (जैसे Bedrock पर inference profiles, Foundry में model deployments, और Vertex में Model Garden access controls) सभी concepts add करते हैं Architect को know करना चाहिए भले ही partner के engineering team implementation को own करता है।

Skills as एक integration mechanism Skills एक integration mechanism हैं, केवल एक packaging नहीं। एक Skill को एक request को container. skills parameter के through attach किया जा सकता है, published और versioned /v1/skills endpoint के through, और managed version control के तहत किसी भी अन्य deployed asset की तरह। Skills Code Execution Tool को require करते हैं run करने के लिए, जिसका मतलब है integration pattern एक sandboxed execution environment dependency को carry करता है। जब integration decision है कैसे एक reusable procedure Claude तक reach करता है entry points के across, एक versioned Skill एक mechanism है weigh करने के लिए MCP और direct tool use के साथ।

Cost · Complexity · Risk Cost: प्रत्येक entry point एक non-trivial integration cost carry करता है। एक से ज्यादा pick न करें जब तक partner का use case उन्हें span न करता हो। Complexity: दो most common mistakes reaching करना है Claude Code को non-engineering work पर और treating करना है MCP को default integration layer के रूप में regardless of कि क्या reusability जो justify करता है MCP actually needed है। Entry point को follow करना चाहिए काम, precede नहीं। Risk: Wrong entry point को outgrow करना expensive है, केवल code के कारण नहीं जिसे rewrite किया जाना चाहिए, लेकिन conventions और user habits के कारण जो इसके चारों ओर build हुए। एक better entry point पर starting over cheaper है और starting right one पर cheapest है।

Security, governance, और regulated-industry constraints कुछ entry point decisions आपके अपने discretion पर नहीं हैं। जब एक partner attorney-client privilege, HIPAA, GDPR, FedRAMP, या एक internal data-residency policy के subject है, वे constraints entry points को rule in या out करते हैं इससे पहले cost, ergonomics, या build effort conversation में enter करते हैं। Claude. ai यह entry point है जो most often hit होता है। Consumer-grade product को design नहीं किया गया था satisfy करने के लिए हर enterprise data-handling requirement out of the box। API और SDK, एक partner-approved gateway के through routed एक logging, retention, और identity controls के साथ partner के अपने infrastructure में, entry points हैं जो most regulated reviews को survive करते हैं। Governing constraint को name करें जब आप एक entry point recommend करते हैं और constraint को eliminate करने दें options को preferences से पहले। Regulated-industry constraints ConstraintWhat it tends to rule outWhat usually survives review

Attorney-client privilegeConsumer tiers Claude. ai का privileged document review के लिए, और कुछ भी जो privileged material को touch करता है एक surface के through जो firm audit नहीं कर सकता end to end। Claude for Work admin controls और audit logging को add करता है, लेकिन एक firm को अभी भी confirm करना चाहिए configuration अपने privilege-handling bar को meet करता है इससे पहले privileged material इसके through flow करता है।API या SDK firm के अपने application के पीछे, SSO के through authenticated, एक firm-approved LLM gateway के through routed जो हर request को log करता है। Firm audit trail को own करता है end to end, जो privilege review turn करता है। HIPAA (PHI handling)कोई भी entry point जहाँ एक Business Associate Agreement partner use कर रहा है specific configuration के लिए place में नहीं है। एक BAA जो एक configuration के लिए exist करता है दूसरे को extend नहीं करता, तो एक uncovered route ruled out है भले ही partner एक BAA को elsewhere hold करता है।API या SDK एक BAA-covered configuration पर delivery route के through partner पहले से ही use कर रहा है। BAA existence sufficient नहीं है क्योंकि feature eligibility matter करता है। Beta features generally excluded हैं BAA coverage से जब तक explicitly listed नहीं हैं eligible के रूप में। GDPR & data residencyDelivery routes जहाँ model execution का region pin नहीं किया जा सकता, और routes जहाँ data approved geographic boundary को leave करता है किसी भी step पर।एक CSP-mediated delivery route (Bedrock या Vertex) region को एक covered jurisdiction में pin किया गया और DPA terms inherited existing cloud contract से। Foundry यहाँ check करने के लिए route है, क्योंकि इसकी residency guarantees कुछ नहीं हैं यह course confirm कर सकता है। Foundry route के current documentation के साथ verify करें residency से पहले rely करने से पहले। FedRAMP / governmentकोई भी path जो एक authorized cloud environment पर नहीं है required impact level पर।Claude for Government (C4G) FedRAMP High civilian workloads के लिए। Bedrock GovCloud FedRAMP High और DoD IL4/5 के लिए। Vertex Assured Workloads FedRAMP High और IL2 के लिए। Note: authorized government environments एक model lag पर run करते हैं, तो newest Claude models GovCloud और Assured Workloads तक reach करते हैं commercial release के बाद। Confirm करें कौन सा model route offer करता है commit करने से पहले। Internal data-residency policyRoutes partner के approved cloud vendor list के बाहर, underlying technical capability के regardless।Delivery route partner के approved CSP पर। यह procurement है, engineering नहीं: right route कौन सा है उनके CIO पहले से ही clear किया है।

Note: हमेशा verify करें current authorization scope प्रत्येक constraints के लिए Anthropic के साथ committing से पहले।

Forward pointer Module 3 (Responsible AI, Safety and Risk for Architects) guardrail design, data handling, और full regulated-industry framework पर deep जाता है। इस section की role constraint को surface करना है design conversation के point पर जहाँ यह options को eliminate करता है, जो right यहाँ entry point और delivery-route decision पर है।

Screen 29: जब Claude Code को engineering के बाहर pick किया गया

Watch Out 4 min · Entry Points & Governance

जब Claude Code को engineering के बाहर pick किया गया

Setup hook Claude Code एक strong first impression बनाता है। यह complex, multi-step engineering tasks को execute कर सकता है एक fraction में time एक developer manually spend करेगा, और वह capability hard है unsee करने के लिए। Risk यह है कि यह teams को Claude Code को default से reach करने के लिए lead करता है, भले ही काम इसे require नहीं करता है और एक simpler integration या Claude alone sufficient होता। नीचे दिया गया diagram एक real handoff था एक partner से asking करते हुए हमें उनके design को validate करने के लिए। Proposed architecture: regional bank operations assistant एक regional bank चाहता था क्या उन्होंने एक "operations assistant" call किया उनके branch staff के लिए। काम required करता था customer balances को look up करना, appointments को schedule करना, और policy questions को answer करना। Proposed architecture तीन components था:

Claude Code branch laptops पर run करता है, एक CLAUDE. md file maintained per branch को local conventions को encode करने के लिए। MCP servers customer database, appointment system, और policy corpus के लिए, प्रत्येक standardized protocol के through exposed। Subagents compliance checks को run करते हैं हर interaction पर, अपने restricted tool entry point के साथ।

Diagram के across annotation

Claude Code on branch laptops (per-branch CLAUDE. md)

Engineering entry point for an operational workflow। Branch staff terminals को run नहीं करते; entry point user के साथ mismatched है। ↓

MCP servers: customer database, appointment system, policy corpus

MCP केवल earn करता है अपनी जगह जब reused clients के across। इस bank में कोई अन्य Claude clients exist नहीं किए। ↓

Subagents run compliance checks on every interaction

Compliance weakest deterministic guarantees को assign किया गया। High-consequence path को नहीं करना चाहिए subagents पर run करना, जो weaker deterministic guarantees provide करते हैं than server-side code।

Diagram के across red में annotation reads: यह एक engineering entry point है एक operational workflow के लिए। Branch staff terminals को run नहीं करते, तो entry point itself user के साथ mismatched है। Compliance एक high-consequence path है और server-side code में deterministic नहीं करना चाहिए run करना, जहाँ guarantees explicit हैं बजाय emergent के। Customer database को expose करने की जरूरत नहीं है MCP के ऊपर केवल क्योंकि MCP entry point के menu पर था; MCP अपनी जगह earn करता है जब same tool entry point clients के across reused है, और इस case में कोई अन्य clients नहीं थे bank में। Architecture जो काम को fit करता है एक custom web application है API को directly call करता है। Compliance deterministic server-side code में रहता है जहाँ guarantees explicit हैं बजाय emergent के। User interface bank के SSO के through authenticated है और एक banking workflow को fit करता है बजाय एक developer workflow के। Tool calls server boundary पर audited हैं। वह architecture right answer था screen एक से। तीन failure mechanisms, प्रत्येक original proposal में visible

पहला: entry point को choose किया गया था इससे पहले user को name किया गया। Branch staff को एक interface की जरूरत है जो एक banking workflow को fit करता है, एक developer tool नहीं। वह constraint को determine करना चाहिए entry point इससे पहले कोई अन्य decision किया गया। दूसरा: MCP को एक prior project से एक default integration layer के रूप में carry किया गया। Reusability argument जो MCP को justify करता है यहाँ apply नहीं किया। Bank में कोई अन्य Claude clients नहीं थे जो same tool entry point को consume करेंगे। Protocol layer integration cost को pay कर रहा था एक capability के लिए partner को need नहीं किया। तीसरा: compliance, highest-consequence path system में, को assign किया गया entry point को weakest deterministic guarantees के साथ। Pattern inverted था। काम जो सबसे code-level certainty को need किया वह entry point पर run कर रहा था furthest से। क्यों यह break करता है? Entry point choice को follow करना चाहिए user और काम। Claude Code या MCP को reach करना केवल क्योंकि last project उन्हें use किया capabilities के लिए pay कर रहा है partner को need नहीं किया।

Screen 30: Entry point को pick करें और deciding tradeoff को name करें

Checkpoint 7 min · Entry Points & Governance

Entry point को pick करें और deciding tradeoff को name करें प्रत्येक partner scenario के लिए, option को choose करें जो दोनों right entry point AND tradeoff को name करता है जो choice को drive करता है। एक right entry point paired wrong reason के साथ correct नहीं है, reasoning वह है being tested। एक worked example scenario 1 के लिए shown है; आप scenarios 2 through 6 को complete करते हैं।

Scenario 1, worked example एक non-engineering operations team को एक chat assistant की जरूरत है approved internal docs के ऊपर। Correct choice: claude. ai with a Project, क्योंकि deciding tradeoff audience है: एक non-technical team को एक ready-made entry point की जरूरत है, build-time interface नहीं।

Scenario 2. एक regional bank एक loan officer assistant को deploy करना चाहता है जो customer account data को एक core banking system से retrieve करता है और draft loan summaries को generate करता है। Bank AWS पर run करता है और एक existing enterprise agreement है।

A. AWS Bedrock, क्योंकि deciding tradeoff integration depth है: assistant को programmatic access की जरूरत है core banking data को और bank के existing AWS infrastructure में embed करना चाहिए। B. claude. ai Enterprise, क्योंकि deciding tradeoff integration depth है: bank को एक governed product को SSO और audit controls के साथ चाहिए। C. Direct API, क्योंकि deciding tradeoff integration depth है: direct API requests को build करने पर most control देता है।

Scenario 3. एक law firm Claude को use करना चाहता है attorneys को assist करने के लिए privileged documents को review करते हुए। Firm के general counsel ने determine किया है कि सभी AI tooling privileged material को touch करता है firm के अपने audit infrastructure के पीछे run करना चाहिए।

A. claude. ai Enterprise, क्योंकि deciding tradeoff governance/control है: Enterprise SSO, audit logging, और admin controls को add करता है। B. Direct API या SDK firm के अपने application के पीछे और gateway, क्योंकि deciding tradeoff governance/control है: firm को audit trail को own करना चाहिए end to end, जो infrastructure को require करता है firm control करता है। C. AWS Bedrock, क्योंकि deciding tradeoff regulatory residency है: Bedrock regional data handling provide करता है जो privilege requirements को satisfy करता है।

Scenario 4. एक global logistics company warehouse operations staff को एक Claude assistant देना चाहता है shift handoff notes के लिए और equipment checklist completion के लिए। Staff non-technical हैं और floor पर shared tablets से काम करते हैं।

A. Direct API with a custom-built interface, क्योंकि deciding tradeoff integration depth है: एक custom build experience पर full control देता है। B. claude. ai with a Project, क्योंकि deciding tradeoff audience है: non-technical staff को एक ready-made interface की जरूरत है वे बिना training के use कर सकते हैं, और Projects shared context provide करते हैं team को need है। C. Claude Code, क्योंकि deciding tradeoff audience है: Claude Code tablets पर run करता है और staff को Claude capabilities को direct access देता है।

Scenario 5. एक healthcare network एक clinical documentation assistant को deploy करना चाहता है जो patient records को process करता है। Network एक BAA को AWS के साथ hold करता है और confirm किया है Bedrock वह agreement के तहत covered है। एक competing proposal direct Anthropic API को use करना suggest करता है एक separately negotiated BAA के साथ।

A. AWS Bedrock, क्योंकि deciding tradeoff regulatory residency है: Bedrock data को एक US region में pin करता है जो HIPAA को satisfy करता है। B. Direct Anthropic API with a separately negotiated BAA, क्योंकि deciding tradeoff governance/control है: direct API system के through PHI को कैसे flow करता है पर more control देता है। C. AWS Bedrock, क्योंकि deciding tradeoff governance/control है: network का existing BAA इस configuration को cover करता है, जो compliance risk को eliminate करता है इससे पहले कोई अन्य tradeoff apply करता है। D. claude. ai Enterprise with a BAA, क्योंकि deciding tradeoff governance/control है: Enterprise HIPAA-ready configuration और audit controls को add करता है।

Scenario 6. एक financial services firm एक high-frequency trade commentary system को build कर रहा है। System को हर trade के 400 milliseconds के अंदर एक short natural-language summary को generate करना चाहिए execution के। Firm GCP पर run करता है।

A. Google Vertex AI, क्योंकि deciding tradeoff latency है: 400ms requirement lowest-latency path को demand करता है, और Vertex AI request path को firm के existing Google Cloud environment के अंदर रखता है, network round-trip को minimize करता है। B. Direct Anthropic API, क्योंकि deciding tradeoff latency है: direct API fastest feature releases को have करता है और lowest overhead। C. AWS Bedrock, क्योंकि deciding tradeoff latency है: Bedrock की managed infrastructure low-latency inference के लिए optimized है।

Submit Skip for now

Screen 31: एक mid-market law firm के लिए एक contract-review system

Checkpoint 7 min · Assembly & Recap

एक mid-market law firm के लिए एक contract-review system चार complete architectures नीचे described हैं। प्रत्येक सभी पाँच design decisions को commit करता है module covered: platform entry point, pattern, कैसे काम Claude, existing systems, और humans के across split है, model और context strategy, और human-in-the-loop posture। केवल एक brief के विरुद्ध hold up करता है। अन्य तीन प्रत्येक एक single decision पर fail करते हैं। एक को pick करें आप एक partner-side review committee के सामने रखेंगे।

Brief एक 180-lawyer mid-market law firm contract review को speed up करना चाहता है। Senior associates currently एक estimated 12 to 18 hours per week spend करते हैं vendor और partnership contracts को read करने के लिए clauses को flag करने के लिए जो firm के standard playbook के साथ conflict करते हैं। Average contract length 35 pages है। Current output एक redlined PDF है margin comments के साथ। Firm iManage को document storage के लिए use करता है, एक private LLM gateway को approved करता है उनके CIO द्वारा, और attorney-client privilege requirements द्वारा bound है जो consumer-grade tools को exclude करते हैं। Target 60% से associate time को cut करना है contract per जबकि senior associate को final reviewer के रूप में रखते हुए।

Step 1: अपने architecture को draft करें इससे पहले कि आप चार options को read करें, अपने architecture को draft करें law firm के लिए। एक paragraph में, सभी पाँच decisions को cover करें: platform entry point, pattern, कैसे काम Claude और existing systems के across split है, model और context strategy, और human-in-the-loop posture। Click-to-reveal एक answer compare करने के लिए आपके response के साथ; feel free को ask करें Claude अपने लिखे हुए को compare करने के लिए provided answer के साथ।

Your architecture

Reveal the model answer Direct API या SDK पर build करें, एक thin internal web app में embedded जो firm के SSO के through authenticate करता है और approved LLM gateway के through route करता है। एक parallelized workflow contract को section by section review करता है, एक evaluator pass के साथ flagged-clauses output पर एक strict schema को enforce करता है। Claude extraction, classification against playbook, और draft redlines को handle करता है। Playbook firm के systems में एक versioned source of truth के रूप में रहता है, per clause पर retrieve किया जाता है call time पर। iManage document fetch को handle करता है। Sonnet default है progressive context के साथ, extended thinking enabled per clause पर केवल जहाँ एक eval set justify करता है। Senior associate हर output पर sign off करता है, और low-confidence clauses को attention के लिए flag किया जाता है।

Step 2: चार options में से कौन सा आपके design को most closely match करता है?

Option A. Claude. ai पर build करें, प्रत्येक contract को एक Project में upload करते हुए जो playbook को reference files के रूप में hold करता है। एक parallelized workflow contract को section by section review करता है और flagged clauses को aggregate करता है। Sonnet default है progressive context के साथ। Senior associate हर output पर review करता है इससे पहले कुछ भी client को जाता है। Option B. Direct API या SDK पर build करें, एक thin internal web app में embedded जो firm के SSO के through authenticate करता है और approved LLM gateway के through route करता है। Playbook को full system prompt में load किया जाता है हर call पर ताकि model को हमेशा firm के standard हो context में। एक parallelized workflow contract को section by section review करता है और results को aggregate करता है। Sonnet default है। Senior associate हर output पर review करता है। Option C. Direct API या SDK पर build करें, एक thin internal web app के पीछे SSO और approved gateway के साथ। एक open-ended agent को contract और iManage tools को दिया जाता है और अपने आप को decide करने दिया जाता है कैसे document के through काम करना है। Playbook per clause पर retrieve किया जाता है call time पर। Opus हर call पर run करता है maximum accuracy के लिए। Senior associate हर output पर review करता है। Option D. Direct API या SDK पर build करें, एक thin internal web app में embedded जो firm के SSO के through authenticate करता है और approved LLM gateway के through route करता है। एक parallelized workflow contract को section by section review करता है, एक evaluator pass के साथ flagged-clauses output पर एक strict schema को enforce करता है। Claude extraction, classification against playbook, और draft redlines को handle करता है। Playbook firm के systems में एक versioned source of truth के रूप में रहता है, per clause पर retrieve किया जाता है call time पर। iManage document fetch को handle करता है। Sonnet default है progressive context के साथ, extended thinking enabled per clause पर केवल जहाँ एक eval set justify करता है। Senior associate हर output पर sign off करता है, और low-confidence clauses को attention के लिए flag किया जाता है।

Submit Skip for now

Screen 32: Glossary

Reference · Assembly & Recap

Glossary Key terms used इस module के across, alphabetical order में। एक term को expand करने के लिए click करें।

Adaptive thinkingExtended thinking जहाँ model itself, बजाय आप, decide करता है कि क्या think करना है और कितना, प्रत्येक request की complexity के आधार पर। यह एक hard problem पर length पर reason कर सकता है और एक trivial पर thinking को completely skip कर सकता है। आप इसे एक effort level के साथ steer करते हैं बजाय एक token budget को configure करने के। Current Claude models पर यह recommended control है, और newest models पर यह only एक है। APIApplication Programming Interface। Direct way Claude को अपने code से requests भेजने के लिए, prompt, model, parameters, और कैसे response को handle करना है पर full control के साथ। API को use करना means आप surrounding application को build कर रहे हैं: user interface, conversation history, error handling, logging। Tradeoff maximum flexibility है exchange में ownership के लिए infrastructure के चारों ओर। AuthoritativeAuthoritative means source आप agree किए हैं treat करने के लिए correct के रूप में: partner का system of record, live policy table, current price list। जब एक answer authoritative है, यह उस trusted source से आता है बजाय model के recollection से, तो आप इसके पीछे stand कर सकते हैं। Claude Agent SDKA managed agent runtime distributed @anthropic-ai/claude-agent-sdk package के रूप में TypeScript और Python के लिए। यह एक partner को programmatic access देता है same agent loop को जो Claude Code को power करता है: iteration, tool execution, observation, termination, तो partner एक agent को अपने product के अंदर embed कर सकता है बजाय Claude Code को एक terminal में run करने के। Anthropic SDK से distinct, जो एक thin convenience wrapper है API के ऊपर और एक agent loop को run नहीं करता। Claude Codeएक agentic coding tool जो files को read करता है, code को edit करता है, commands को run करता है, और multi-step engineering tasks को execute करता है configurable permission boundaries के तहत। Distributed एक CLI, IDE plugins (VS Code, JetBrains, और others), एक desktop application, और एक web product के रूप में claude. ai/code पर। Claude Code entry point है engineers use करते हैं real development work करने के लिए, और यह customizable है CLAUDE. md, skills, subagents, hooks, MCP servers, और permission settings के through। Claude. aiEnd-user chat product Anthropic द्वारा hosted। Reached web, mobile apps, और Claude Desktop के through। Users sign in, conversations को open करते हैं, files को upload करते हैं, Projects के through context को share करते हैं, और built-in connectors के through external services को connect करते हैं। कोई code नहीं लिखा जाता। Claude. ai entry point है users के लिए, builders के लिए नहीं, जो यही कारण है एक partner के engineering team usually Claude. ai को consume नहीं करता जब Claude को अपने product में embed करते हैं। CorpusDocuments का body एक retrieval system search करता है। एक corpus एक knowledge base, एक set of policy documents, एक product manual, या एक collection of past tickets हो सकता है। Corpus को load और index किया जाता है ahead of time, जो यही कारण है यह stable reference material के लिए काम करता है और live state के लिए नहीं। CSP delivery routeCloud Service Provider delivery route: Path जो API traffic Claude तक reach करने के लिए लेता है। Anthropic एक direct route offer करता है api. anthropic. com पर, और same Claude models भी AWS Bedrock, GCP Vertex AI, और Microsoft Foundry on Azure के through available हैं। Route आप choose करते हैं determine करता है जहाँ spend को bill किया जाता है, कैसे call को authenticate किया जाता है, कौन सा region traffic terminate करता है, और कौन सी contract इसे cover करता है। यह affect नहीं करता कैसे model behave करता है। Deterministic ruleएक deterministic rule एक rule है जो हमेशा same output produce करता है same input के लिए। Same in, same out, हर बार, कोई variation के साथ नहीं। EvalEval short है evaluations के लिए एक structured test set used measure करने के लिए कि क्या एक model एक defined task पर अच्छी तरह perform कर रहा है। एक eval inputs को pair करता है expected outputs या quality criteria के साथ, उन्हें model के विरुद्ध run करता है, और एक score produce करता है आप compare कर सकते हैं model versions, prompts, या configurations के across। Evals हैं कैसे teams decide करते हैं कि क्या एक change एक improvement है या एक regression इससे पहले यह production तक reach करता है। Extended thinkingCapability जहाँ model एक problem के through काम करता है एक separate block of thinking tokens में इससे पहले कि यह एक final answer को commit करता है, बजाय एक pass में responding के। यह help करता है tasks पर जहाँ एक one-shot answer steps को skip करेगा। Thinking tokens output tokens के रूप में billed होते हैं और latency को add करते हैं। कितना thinking होता है control mode पर depend करता है: एक thinking-token budget आप configure करते हैं older models पर, या adaptive thinking (see Adaptive thinking) current ones पर। IDEIntegrated Development Environment। एक software application जो एक code editor, debugger, और अन्य tools को एक जगह में bundle करता है code को write और run करने के लिए (e. g. , VS Code, PyCharm, Xcode)। Live stateData जो एक conversation या process के lifetime के दौरान change करता है: एक order status, एक inventory count, एक price, एक calendar slot, एक user का current session। Live state static reference material से distinct है क्योंकि correct answer 10:00 a. m. पर 10:05 तक गलत हो सकता है। Systems जिन्हें live state की जरूरत है एक direct lookup को require करते हैं source of truth के विरुद्ध, एक stored snapshot नहीं। MCPModel Context Protocol। एक open standard जो Claude को external tools और data sources को connect करने देता है एक dedicated server के through, बजाय आपको एक custom integration को write करने के लिए प्रत्येक के लिए। एक MCP server tools, prompts, और resources को expose करता है कि कोई भी MCP-compatible client use कर सकता है, जिसका मतलब है एक single integration written एक बार applications के across reused किया जा सकता है। MCP tool definitions को build और maintain करने का काम shift करता है आपके application code से और reusable servers में। MonolithicOpposite progressive का: सब कुछ model को need हो सकता है एक block में context में load किया जाता है upfront। Monolithic context simpler है set up करने के लिए और short, contained tasks के लिए fine है, लेकिन यह over time grow करता है, context window के विरुद्ध push करता है, और model को material को attend करने के लिए force करता है जो current step के लिए relevant नहीं हो सकता। Long-lived deployments built monolithically tend करते हैं degrade करने के लिए जैसे conversation accumulate करता है। ObservabilityAbility देखने के लिए आपका system क्या कर रहा है, reconstruct करने के लिए क्यों यह एक certain way behave किया, और detect करने के लिए जब कुछ गलत जाता है। Parametric knowledgeParametric knowledge means जो कुछ model training के दौरान learned और अपने weights (parameters) में carry करता है। यह model answering है memory से, कोई outside lookup के साथ नहीं। Opposite है knowledge model pull करता है moment के request पर, जैसे एक document आप hand करते हैं या एक web search result। ProgressiveApproach जहाँ context, instructions, या capabilities को stages में load किया जाता है जैसे काम require करता है, बजाय सभी एक बार start पर। Progressive context model को केवल क्या यह हर step पर need करता है देता है, जो working set को focused रखता है और हर call की cost को lower रखता है। Pattern show up करता है skills में जो reference files को on demand load करते हैं और agents में जो information को tool calls के through gather करते हैं बजाय सब कुछ initial prompt में receive करने के। Prompt cachingPrompt caching एक feature है जो आपको frequently used parts को एक prompt में store करने देता है, typically एक long system prompt या एक large document, तो model को उन्हें scratch से reprocess नहीं करना पड़ता हर request पर। Cached portion को एक बार compute किया जाता है और multiple calls के across reused किया जाता है। RetrievalFetching relevant information एक outside source से moment के request पर और इसे model को question के साथ hand करना। बजाय rely करने के क्या model training में learned, आप current document, record, या passage को pull करते हैं और इसे model के सामने रखते हैं ताकि answer उस source में grounded हो। SDKSoftware Development Kit। एक language-specific library (Python, TypeScript, और others) जो API को idiomatic code में wrap करता है उस language के लिए। SDK request formatting, authentication, retries, और response parsing को handle करता है तो आप few lines of code के साथ Claude को call कर सकते हैं बजाय HTTP requests को hand से construct करने के। SDK API के ऊपर built है, तो कुछ भी API कर सकता है, SDK कर सकता है, कम boilerplate के साथ। जब एक engineer "SDK" कहता है वे may mean करते हैं यह Anthropic SDK (एक wrapper API के ऊपर) या Claude Agent SDK (एक managed agent runtime); however, ये दो अलग चीजें हैं। ShippableProduction use के लिए ready, केवल एक working demo नहीं। Shippable output accuracy, latency, cost, और reliability के लिए bar को meet करता है deployment actually require करता है, और यह evals और review gates को pass किया है team use करता है changes को release करने के लिए। Distinction matter करता है क्योंकि एक prototype जो happy path को handle करता है same नहीं है एक system के रूप में जो real user inputs के long tail को handle करता है। TerminalA text-based interface आपके computer के operating system के साथ interact करने के लिए commands को type करके। Also called एक command line या shell (e. g. , Terminal on Mac, Command Prompt on Windows)। Tool useCapability जो Claude को external functions, APIs, या services को call करने देता है एक response के दौरान बजाय केवल text generate करने के। Model decide करता है कि कब एक tool को invoke करना है, कौन से arguments pass करने हैं, और result को अपने next step में कैसे use करना है। Tool use वह है जो Claude को एक text generator से एक system में turn करता है जो files को read कर सकता है, databases को query कर सकता है, web को search कर सकता है, या अन्य software में action ले सकता है। WrapperCode जो surrounds या encapsulates करता है दूसरे code, library, या API को इसे use करना easier बनाने के लिए, functionality को add करने के लिए, या interfaces के बीच translate करने के लिए। उदाहरण के लिए, एक Python wrapper एक C library के चारों ओर आपको C functions को call करने देता है जैसे वे native Python थे।

Screen 33: Key takeaways

Recap 3 min · Assembly & Recap

Key takeaways

01

Decomposition architecture से पहले आने वाला move है। इससे पहले कि आप एक pattern को choose कर सकें, आपको काम को तीन buckets में split करना चाहिए: Claude क्या handle करता है, आपके existing systems क्या handle करते हैं, और humans क्या handle करते हैं। Split driven है कि कैसे model behave करता है काम के प्रत्येक piece पर, जो आपको बताता है कि क्या एक task Claude के साथ belong करता है या कहीं और stack में। Designs जो यह step को skip करते हैं Claude को काम में force करते हैं जो दूसरा system lower cost पर करेगा या इसे operate करने के लिए context के बिना ask करते हैं एक human colleague को दिया होता।

02

एक pattern को choose करना कितना autonomy grant करना है choose करना है। Augmented LLM, workflow, और agent spectrum पर points हैं "Claude एक step को assist करता है" से "Claude पूरे sequence को plan करता है", चार workflow sub-patterns के साथ underneath। Decision पाँच factors पर depend करता है: predictability (task कितना predictable है), error cost (एक wrong answer कितना expensive है), observability (काम कितना visible है जबकि यह run करता है), latency (आप कितना wait कर सकते हैं), और cost (आप per run कितना spend कर सकते हैं)। जब error cost binding constraint है, error cost pattern को pick करता है। Tightest constraint वह factor है जो decide करता है।

03

Tested reference architectures को reach करें इससे पहले कि आप अपना खुद का invent करें। पाँच reference architectures: Agent, RAG, Document processing pipeline (Evaluator-optimizer), Routing, और Coding agent documented हैं क्योंकि अन्य teams पहले से ही learned हैं क्या breaks प्रत्येक में। उन्हें combine करें जब आपके system के अलग parts अलग तरीकों में break करते हैं और एक को pick करें जब आप अभी भी uncertain हैं क्या system को need होगा handle करने के लिए। Most common mistake retrieval को use करना है live state के लिए एक substitute के रूप में। Retrieval static documents के लिए built है और stale snapshots, तो उन्हें एक conversation के दौरान use न करें जिसे live data की जरूरत है।

04

एक model को choose करना: Sonnet से start करें और हर swap को एक release के रूप में treat करें। Sonnet default tier है क्योंकि यह intelligence, speed, और cost को balance करता है अधिकांश production workloads के लिए। Opus या Haiku को move करना एक deliberate decision है जिसे same gate की जरूरत है कोई अन्य release को get करता है: एक eval set जो define करता है क्या "better" means, और एक rollback criterion set advance में, बाद में नहीं। Same principle apply करता है context को। Progressive context, जहाँ model केवल क्या यह हर step पर need करता है receive करता है, एक long-lived deployment के ऊपर better hold करता है than monolithic context जो सब कुछ upfront load करता है और grow करता है जब तक यह break नहीं करता।

05

Entry point को pick करें काम द्वारा जो इसे करना है, shelf पर क्या पहले से ही है नहीं। Claude. ai, direct API, SDK, Claude Code, और MCP प्रत्येक एक अलग core tradeoff carry करते हैं: setup की speed versus control की depth, prebuilt UI versus custom integration, tools की breadth versus focus। Right recommendation वह है जहाँ आप tradeoff को out loud name कर सकते हैं time पर आप इसे make करते हैं। Tradeoff को out loud name करना जब आप entry point को recommend करते हैं वह है जो आपको बताता है, later, जब switch करना है।

Sources

Anthropic Skilljar, Claude 101: model family (Opus, Sonnet, Haiku), Claude. ai और API entry points। Anthropic Skilljar, Claude Code 101 In Action: Claude Code customization stack, CLAUDE. md, subagents, MCP, Skills। Anthropic Skilljar, AI Fluency Foundations: four-properties framework, next-token prediction, knowledge, working memory, steerability। Anthropic Skilljar, Building with the Claude API: RAG, chunking, hybrid retrieval, tool use, extended thinking, evaluation।

Screen 34: Congratulations! आपने successfully इस module को complete किया है।

Module Complete · Architect · 2 min Congratulations! आपने successfully इस module को complete किया है। Module 1 platform decisions को establish करता है जो हर downstream Architect choice पर depend करता है। आपने model selection, prompt architecture, tool design, और tradeoffs के through काम किया है जो प्रत्येक layer को connect करते हैं। Platform layer पर आप जो decisions लेते हैं वे ceiling को set करते हैं सब कुछ के लिए built above।

0 of 0 checkpoints passed

M1

Claude Platform & Solution Design Model selection, prompt architecture, tool design, और platform-layer tradeoffs।

You Are Here

M2

Enterprise Integration & Production Deployment patterns, integration architecture, और production reliability।

Up Next

M3

Responsible AI, Safety & Risk Safety frameworks, risk identification, और governance practices।

M4

Stakeholder Engagement, Lifecycle & Go-to-Market Stakeholder communication, lifecycle management, और go-to-market strategy।

M5

Team Enablement और Operational Productivity Team tooling configuration और operational support practices।

Review module Start over