Agentic Architectures चुनना: Decision-Driven Crash Course

pattern selection पर एक वैचारिक क्रैश कोर्स, कब sequential workflow, single agent + ReAct + tools, planning + ReAct execution, या multi-agent specialist system (चार मुख्य pattern) का उपयोग करना है, और उनमें से किसी के ऊपर reflection कब परत करना है, उन इंजीनियरों के लिए जिन्होंने agents भेजा है और उन्हें सैद्धांतिक तरीके से architectures चुनने की आवश्यकता है, नहीं जो प्रभावशाली दिखता है.

*22 अवधारणाएँ • 5 निर्णय • चार सीखने के ट्रैक। रीडर ट्रैक: 2-3 घंटे शुद्ध वैचारिक पढ़ना (decision tree, पांच pattern, failure signals, कोई सेटअप नहीं)। शुरुआती/मध्यवर्ती/उन्नत ट्रैक: ~1 दिन, 2-3 दिन, 4-5 प्रत्येक दिन (वैचारिक पढ़ना और वास्तविक कार्यों को वर्गीकृत करने पर गहराई बढ़ाना, deployment topologies स्केच करना, और प्रत्येक pattern के लिए विशिष्ट eval signals वायरिंग करना)। कुल ईमानदार अनुमान: रीडर ट्रैक के लिए 2-3 घंटे; एक टीम के लिए pattern selection को कार्य अनुशासन के रूप में आत्मसात करने के लिए 4-5 दिन। भाग 5 के decision lab से पहले अपना ट्रैक चुनें।*

एंकर लेख: Bala Priya C, "सही चुनना Agentic Design Pattern: एक निर्णय-वृक्ष दृष्टिकोण," Machine Learning Mastery, मई 15, 2026: machinelearningmastery.com/choosing-the-right-agentic-design-pattern-a-decision-tree-approach। इस पाठ्यक्रम की रीढ़ decision tree उसी की है। रचना परत, आपके deployment topology और आपके eval suite के लिए प्रत्येक pattern का क्या अर्थ है, यह पाठ्यक्रम शीर्ष पर जोड़ता है।

---

सादा-अंग्रेजी संस्करण (पहले इसे पढ़ें)

आपने agents बनाया है। हो सकता है कि customer-support Worker Maya को Digital FTE पाठ्यक्रम में बनाया गया हो, जो कि eval-driven course में एक मूल्यांकन agent हो, एक Tier-1 Support agent आपने cloud deployment पाठ्यक्रम में production तक का सफर तय किया हो। अब आप build एक कर सकते हैं। सैद्धांतिक रूप से, आप अभी तक यह तय नहीं कर सकते हैं कि अगली बार build को किस प्रकार का agent दिया जाए।

production AI में एक वास्तविक विफलता मोड: इंजीनियर उस pattern तक पहुंचते हैं जो प्रभावशाली दिखता है, आमतौर पर multi-agent, जब task एक sequential workflow की मांग करता है जिसके पांच चरणों में से तीन में LLM की भी आवश्यकता नहीं होगी। एक समस्या के लिए हफ्तों का ऑर्केस्ट्रेशन काम करता है जिसे दो tools के साथ एक अच्छी तरह से प्रेरित single agent एक दिन में संभाल सकता है। विपरीत विफलता मोड भी वास्तविक है: इंजीनियर एक लंबी प्रणाली prompt के साथ single agent के लिए पहुंचते हैं जब task को वास्तव में specialists में अपघटन की आवश्यकता होती है, और agent context के अंतर्गत ढह जाता है जो एक मानसिक model में फिट नहीं होता है।

Pattern selection वह डिज़ाइन कार्य है जो build से पहले आता है। यह प्रश्न है कि "इस agent system का वास्तव में क्या आकार होना चाहिए?" और एक सैद्धांतिक उत्तर है: अपने task के बारे में पांच प्रश्न पूछें, और पांच शुरुआती pattern में से एक के उत्तर map पूछें। यह पाठ्यक्रम पाँच प्रश्न, पाँच pattern, failure signals सिखाता है जो आपको बताता है कि pattern गलत था, और (वह हिस्सा जो वास्तव में shipping होने पर सबसे अधिक मायने रखता है) प्रत्येक pattern का आपके deployment topology और आपके eval suite के लिए क्या मतलब है।

**अनुशासन यह नहीं है कि "हमेशा सबसे सरल pattern चुनें।" multi-agent system सही उत्तर है जब विशेषज्ञता या पैमाना वास्तविक bottleneck बनाता है, न कि तब जब यह स्लाइड पर अधिक उन्नत दिखता है।

डिज़ाइन के अनुसार यह कोर्स eval-संचालित कोर्स और cloud deployment कोर्स से छोटा है। decision-logic framework तंग है; प्रत्येक pattern के इतिहास के बारे में सर्वेक्षण सामग्री के साथ इसे जोड़ने से अनुशासन कमजोर हो जाएगा। तंग framework एक सुविधा है, बग नहीं।

📖 यदि आपने Agent Factory ट्रैक में पहले के पाठ्यक्रम नहीं लिए हैं

यह पाठ्यक्रम operational envelope (Inngest), eval अनुशासन, और एक cloud deployment को क्रॉस-रेफरेंस करता है, और उन पाठ्यक्रमों से चल रहे उदाहरण के रूप में "Maya के Tier-1 Support agent" का उपयोग करता है। आप इन्हें पढ़े बिना इस पाठ्यक्रम का बिल्कुल उपयोग कर सकते हैं। पांच-प्रश्न decision tree, पांच pattern, और विफलता-संकेत अनुशासन एक हस्तांतरणीय framework के रूप में अपने आप में खड़े हैं।

पूर्व-पाठ्यक्रम context के बिना एक केंद्रित प्रथम पास के लिए, इस क्रम में पढ़ें:

• भाग 1 (pattern-चयन समस्या): अनुशासन स्थापित करता है
• भाग 2 (पांच-प्रश्न decision tree): वैचारिक रीढ़
• भाग 3 pattern, लेकिन पहले पास पर ऑपरेशनल-लिफाफा साइडबार को छोड़ दें
• भाग 4 (failure signals और संशोधन)
• भाग 5 (decision lab): पांच कार्यशील उदाहरण Maya context के बिना भी उतरते हैं
• भाग 7 समापन

पहली बार में पूर्वावलोकन या वैकल्पिक के रूप में क्या माना जाए:

• संकल्पना 8.5 (SDK primitives): यदि आप OpenAI Agents SDK का उपयोग कर रहे हैं तो उपयोगी; यदि आप किसी भिन्न framework का उपयोग कर रहे हैं, तो इसे हटा दें, क्योंकि अंतर्निहित pattern आकार स्थानांतरित हो जाता है
• संकल्पना 8.6 (operational envelope with Inngest): यदि आप shipping production agentic सिस्टम हैं तो उपयोगी; यदि आप केवल डिज़ाइन चरण में हैं तो इसे छोड़ दें। argument कि "अधिक विस्तृत pattern के लिए अधिक परिचालन मशीनरी की आवश्यकता होती है" Inngest से परे सामान्यीकृत है
• यदि आप उसी cloud stack पर हैं तो भाग 3: में deployment-संरचना साइडबार उपयोगी हैं; सामान्य सिद्धांत (किस pattern को sandbox की आवश्यकता है और किसे नहीं) किसी भी cloud सेटअप में स्थानांतरित होता है

क्रॉस-रेफरेंस को सामान्य सिद्धांतों के ठोस उदाहरण के रूप में मानें, न कि गेटकीपिंग पूर्वापेक्षाओं के रूप में। framework उनके बिना काम करता है।

प्लेटफ़ॉर्म अनुवाद तालिका, प्रत्येक Agent Factory विकल्प किस पर मैप करता है

यदि आप किसी भिन्न stack पर हैं, तो यह तालिका सामान्य विकल्पों के लिए प्रत्येक Agent Factory संदर्भ को मैप करती है। decision tree, पांच pattern, failure signals, और anti-pattern गैलरी सभी इन प्लेटफार्मों पर समान रूप से काम करते हैं; केवल primitive नाम बदलते हैं।

Agent Factory संदर्भ (stack का उपयोग यहां किया गया है)	2026 में सामान्य विकल्प	परत क्या करती है
Inngest (operational envelope)	Temporal, Restate, Dapr Workflows, AWS Step Functions, Azure Durable Functions, LangGraph (आंशिक; durable execution के माध्यम से checkpointers)	Triggers, durable execution, प्रवाह नियंत्रण, HITL gates
OpenAI Agents SDK (agent engine)	LangGraph, AutoGen, CrewAI, AWS Strands, Pydantic AI, LlamaIndex Workflows	Agent loop, tool routing, multi-agent रचना, structured output
Phoenix / Arize (trace observability)	Langfuse, Helicone, LangSmith, Logfire, Honeycomb, Datadog APM	Per-trace agent-behavior observability प्लस trace-to-eval pipeline
Azure Container Apps (harness runtime)	AWS Fargate, Google Cloud Run, Fly.io, Railway, Render, Kubernetes (कोई भी cloud)	लंबे समय से चल रहा HTTP सेवा होस्ट, ऑटोस्केल, रहस्य, प्रवेश
Neon Postgres (durable state)	Supabase, AWS RDS Postgres, PlanetScale, CockroachDB, Google Cloud SQL	Sessions, runs, traces, audit log: टिकाऊ agent अवस्था
Cloudflare R2 (file storage)	AWS S3, Google Cloud Storage, Azure Blob, Backblaze B2	इनपुट, आउटपुट, knowledge artifacts; sandbox के लिए निर्धारित-URL पहुंच
Cloudflare Sandbox (code execution)	E2B, Modal, Daytona, Vercel Sandbox, Fly.io Machines, Cloudflare Containers	agent-generated code के लिए पृथक कार्यक्षेत्र
@inngest_client.create_function (लिफाफा primitive)	@workflow.defn (Temporal), state machine definition (Step Functions), StateGraph(...) (LangGraph)	टिकाऊ function इकाई पंजीकृत करता है
ctx.step.run(name, fn) (लिफाफा primitive)	workflow.execute_activity() (Temporal), Task state (Step Functions), node StateGraph में (LangGraph)	Durable checkpoint जो retry पर याद रखता है
ctx.step.wait_for_event(...) (लिफाफा primitive)	workflow.wait_condition() (Temporal), waitForTaskToken (Step Functions), interrupt() (LangGraph)	event या टाइमआउट तक टिकाऊ निलंबन, HITL primitive
Fan-out trigger (लिफाफा primitive)	workflow.execute_child_workflow() parallel (Temporal), Map state (Step Functions), parallel edges (LangGraph)	एक coordinator → N specialist runs
Agent(...) + Runner.run() (SDK primitive)	Agent.execute() (LangGraph), Agent + initiate_chat() (AutoGen), Crew + kickoff() (CrewAI)	agent loop चलाएँ
@function_tool (SDK primitive)	@tool (LangGraph/LangChain), Tool(...) (AutoGen), Pydantic models CrewAI में	Python function को agent tool के रूप में उजागर करें
handoff(target_agent) (SDK primitive)	Command(goto=...) (LangGraph), nested chats (AutoGen), task प्रतिनिधिमंडल (CrewAI)	Specialist बातचीत का अधिग्रहण
Agent.as_tool() (SDK primitive)	Subgraph-as-node (LangGraph), nested agent calls (AutoGen), CrewAI में as_tool pattern	Coordinator-specialist-को-tool के रूप में उपयोग करता है
output_guardrail (SDK primitive)	कस्टम node + सशर्त edge (LangGraph), सत्यापनकर्ता pattern (Pydantic AI), AWS Strands रेलिंग	agent आउटपुट पर आलोचना/सत्यापन पास

इस तालिका का उपयोग कैसे करें। जब यह पाठ्यक्रम कहता है "Runner.run() को step.run में लपेटें," और आप Temporal प्लस LangGraph पर हैं, तो इसे "Agent.execute() को workflow.execute_activity() में लपेटें" के रूप में पढ़ें। architectural argument समान है; वाक्यविन्यास भिन्न है। एक anti-pattern से बचने के लिए: केवल इस पाठ्यक्रम को पढ़ने के लिए Agent Factory stack सीखने का प्रयास न करें। Map primitives, framework पढ़ें, इसे अपने stack पर लागू करें।

एक पंक्ति जो map को स्पष्ट रूप से नहीं दर्शाती है: Agent.as_tool() बनाम handoff()। OpenAI Agents SDK "coordinator प्रभारी रहता है" (as_tool) को "specialist कार्यभार संभालता है" (handoff) को प्रथम-class primitives के रूप में अलग करता है। अधिकांश अन्य ढाँचे या तो भेद को समाप्त कर देते हैं या केवल एक आधे को ही लागू करते हैं। अंतर ही वास्तुशिल्प की दृष्टि से महत्वपूर्ण चीज़ है; primitive नाम आकस्मिक है। जब आप अपने framework में as_tool-शैली और handoff-शैली संरचना के बीच चयन करते हैं, तो आप इस पाठ्यक्रम के नाम के लिए वही architectural विकल्प चुन रहे हैं; आपका framework इसे अलग तरह से प्रदर्शित कर सकता है।

---

शब्दावली (एक बार पढ़ें, आवश्यकतानुसार दोबारा देखें)

संपूर्ण शब्दावली का विस्तार करने के लिए क्लिक करें.

• Agentic design pattern. AI agent systems के लिए एक आवर्ती architectural आकार: sequential workflow, ReAct + tools, planning + निष्पादन, reflection, multi-agent specialist। प्रत्येक pattern task के बारे में विशिष्ट बातें मानता है; जब वे धारणाएँ कायम रहती हैं, तो pattern मूल्य जोड़ता है; जब वे ऐसा नहीं करते, तो यह overhead बन जाता है।
• Sequential workflow. चरणों का एक निश्चित pipeline जहां प्रत्येक चरण का आउटपुट अगले चरण को फीड करता है। solution path पहले से ज्ञात है; LLM कॉल व्याख्या या सृजन के लिए आरक्षित हैं, आगे क्या करना है यह तय करने के लिए नहीं। उदाहरण: invoice intake → निकालें → मान्य करें → स्टोर → सूचित करें।
• ReAct (कारण + अधिनियम)। एक agentic loop जिसमें agent अपनी वर्तमान स्थिति के बारे में तर्क करने और कोई कार्रवाई करने (आमतौर पर tool call) के बीच वैकल्पिक होता है, परिणाम देखता है, और दोहराता है। परिभाषित संपत्ति: अगली कार्रवाई runtime पर तय की जाती है, पहले से निर्दिष्ट नहीं।
• Planning agent. एक agent जो निष्पादन शुरू होने से पहले एक स्पष्ट योजना (निर्भरता के साथ चरणों का क्रम) तैयार करता है। योजना कार्य की संरचना करती है; व्यक्तिगत चरण अभी भी आंतरिक रूप से ReAct का उपयोग कर सकते हैं। उदाहरण: "एक बाज़ार पर शोध करें" → एक 5-चरण योजना बनाएं → प्रत्येक चरण को tools के साथ निष्पादित करें।
• Reflection (self-critique). एक pattern जहां agent एक आउटपुट उत्पन्न करता है, स्पष्ट criteria के विरुद्ध इसकी आलोचना करता है, और आलोचना के आधार पर इसे परिष्कृत करता है। latency और cost जोड़ता है; केवल तभी मूल्यवान है जब criteria जांच योग्य हो और त्रुटियां महंगी हों। उदाहरण: शुद्धता जांच के साथ SQL पीढ़ी।
• Multi-agent specialist system. एक प्रणाली जिसमें अलग-अलग भूमिकाओं (researcher, writer, reviewer) के साथ कई agents एक task पर सहयोग करते हैं, जो एक रूटिंग या supervisor agent द्वारा समन्वित होता है। विशेषज्ञता, context-overload, या समानांतर-निष्पादन आवश्यकताओं द्वारा उचित; सौंदर्यबोध से नहीं.
• Solution path. चरणों का क्रम जो task को हल करता है। ज्ञात पथ का अर्थ है कि चरणों को runtime से पहले निर्दिष्ट किया जा सकता है; अज्ञात पथ का अर्थ है agent की जांच से निकले चरण।
• Task structure. प्रमुख चरण और उनकी निर्भरताएँ। आर्टिकुलेबल संरचना का अर्थ है कि आप निष्पादन से पहले के चरणों का वर्णन कर सकते हैं; उभरती संरचना का अर्थ है कि चरण फीडबैक के माध्यम से स्वयं को प्रकट करते हैं।
• Architectural fit. एक pattern की मान्यताओं और task के वास्तविक गुणों के बीच मिलान। Pattern selection fit-matching है, न कि capability-matching: सबसे सक्षम pattern चुनना गलत अनुमान है।
• Coordination overhead. एकाधिक agents के बीच रूटिंग या उनके हैंडऑफ़ को समन्वयित करने का cost (tokens, latency, debugging जटिलता और विफलता मोड में)। मल्टी-agent systems इस cost का भुगतान करें; समन्वय जो खरीदता है उससे इसे उचित ठहराया जाना चाहिए।
• Failure signal. एक runtime लक्षण जो दर्शाता है कि चुना गया pattern task से मेल नहीं खाता है। उदाहरण: ReAct loops हल किए गए कार्य पर दोबारा गौर करना (संरचना का अभाव), planner योजनाओं के निष्पादन को (overstructured) से अलग कर देता है, reflection आउटपुट में सुधार नहीं करता है (अस्पष्ट criteria)।
• Pattern composition. एक बड़े सिस्टम की विभिन्न परतों पर विभिन्न pattern का उपयोग करना। उदाहरण: शीर्ष परत पर एक planning agent, प्रत्येक योजना चरण के अंदर ReAct + tools, अंतिम संश्लेषण पर reflection।
• Agent (OpenAI Agents SDK). कोर SDK class: instructions= द्वारा परिभाषित एक LLM-driven इकाई, वैकल्पिक tools=, structured output के लिए वैकल्पिक output_type=, और वैकल्पिक handoffs=। इस पाठ्यक्रम में प्रत्येक pattern की परमाणु इकाई।
• Runner.run(agent, input) (OpenAI Agents SDK). SDK उस runs को Agent कहता है जब तक कि वह अंतिम आउटपुट उत्पन्न न कर दे। आंतरिक रूप से SDK runs reason-act-observe loop: हाथ से रोल किए गए loop की आवश्यकता नहीं है। max_turns= parameter स्टेप बजट है।
• @function_tool (OpenAI Agents SDK). Decorator जो Python function को tool में बदल देता है जिसे agent कॉल कर सकता है। प्रकार के संकेत और डॉकस्ट्रिंग स्वचालित रूप से tool के JSON schema बन जाते हैं।
• handoff() (OpenAI Agents SDK). multi-agent संक्रमणों के लिए पहला-class SDK primitive: एक agent स्पष्ट रूप से बातचीत को दूसरे को सौंपता है, और SDK context को सुरक्षित रखता है। उस समय उपयोग करें जब specialist को user-facing इंटरैक्शन पर कब्ज़ा करने की आवश्यकता हो।
• Agent.as_tool() (OpenAI Agents SDK). SDK method जो एक Agent को कॉल करने योग्य tool के रूप में लपेटता है जिसे कोई अन्य Agent लागू कर सकता है। उस समय उपयोग करें जब coordinator को प्रभारी बने रहने और specialist आउटपुट लिखने की आवश्यकता हो।
• output_guardrail (OpenAI Agents SDK). SDK decorator जो एक सत्यापन/आलोचना agent को दूसरे agent के आउटपुट पथ में जोड़ता है। ब्लॉक-खराब-आउटपुट-शैली reflection के लिए SDK-मूल primitive; निकाल दिए जाने पर OutputGuardrailTripwireTriggered बढ़ जाता है।
• Operational envelope (Inngest). runtime परत जो agent function (triggers) को जगाती है, उड़ान के बीच में दुर्घटनाग्रस्त होने से बच जाती है (step.run के माध्यम से durable execution), load (concurrency, throttle, priority) को सीमित करती है, और HITL का समन्वय करती है (step.wait_for_event). आपके cloud deployment और SDK इंजन के साथ रचना करता है। ऑपरेशनल-लिफाफा पाठ्यक्रम में सिखाया जाता है।
• @inngest_client.create_function (Inngest). Decorator जो एक Python async function को Inngest के साथ एक टिकाऊ-निष्पादित इकाई के रूप में पंजीकृत करता है। trigger सतह और प्रवाह-नियंत्रण नीति की घोषणा करता है।
• ctx.step.run(name, fn, args) (Inngest). स्थायित्व checkpoint। पूर्ण चरण return memoized आउटपुट retry पर; घातीय बैकऑफ़ के साथ स्वतंत्र रूप से विफल चरण retry।
• ctx.step.wait_for_event(...) (Inngest). मिलान event आने या टाइमआउट सक्रिय होने तक टिकाऊ निलंबन। निलंबन के दौरान शून्य गणना खपत। HITL gates के पीछे runtime primitive।
• Fan-out trigger pattern (Inngest). एक coordinator function N events उत्सर्जित करता है; प्रत्येक event अपने स्वयं के ग्राहक function को जगाता है। runtime primitive मल्टी-agent systems में समानांतर specialist निष्पादन के पीछे।
• Replay (Inngest). विफल runs पूर्ण trace के साथ जारी रहता है। Ship एक समाधान, replay पर क्लिक करें; function नए कोड के साथ विफल चरण से फिर से शुरू होता है। सफल कदम बने रहें memoized.

---

क्या आप तैयार हैं? (आवश्यकताएँ)

1. आपने अपना पहला agent बना लिया है, या आपके पास समकक्ष अनुभव है। यह पाठ्यक्रम जो pattern सिखाता है, वह मानता है कि आप समझते हैं कि agent loop क्या है, tool call कैसा दिखता है, और model structured output कैसे लौटाता है। यदि आपने अभी तक agent नहीं बनाया है, तो पहले agent-बिल्डिंग कोर्स पर काम करें।
2. आपने कम से कम एक कार्यशील agent बनाया है। चाहे वह customer-support Worker Maya निर्मित हो, एक research agent, एक चैटबॉट, या एक coding agent हो, आपको एक architectural विकल्प चुनने का अनुभव चाहिए (भले ही आपको एहसास न हो कि आप एक बना रहे थे) और परिणामों के साथ जी रहे हैं।
3. आप छद्मकोड पढ़ सकते हैं। यह एक वैचारिक पाठ्यक्रम है, इसलिए इसमें बहुत कम निष्पादन योग्य कोड है। आप जो देखेंगे वह pattern दर्शाने के लिए छद्मकोड है; यदि आप Python या TypeScript पढ़ सकते हैं, तो आप इसे पढ़ सकते हैं।
4. (वैकल्पिक लेकिन दृढ़ता से अनुशंसित) आपने eval और cloud deployment पाठ्यक्रमों के माध्यम से काम किया है। इस पाठ्यक्रम का मुख्य योगदान आपके deployment topology और आपके eval suite के साथ pattern selection की रचना करना है। जिन पाठकों ने वे पाठ्यक्रम नहीं किए हैं, वे अभी भी framework से लाभ उठा सकते हैं, लेकिन वे एकीकरण arguments से चूक जाएंगे।

यदि आपके पास आइटम 4, नहीं है तो इस पाठ्यक्रम को पढ़ें और deployment-composition और eval-composition साइडबार को पूर्वावलोकन के रूप में देखें। framework उनके बिना उतरता है।

सामने के बारे में जानने के लिए खुरदुरे किनारे (ईमानदार दायरा)

• यह एक वैचारिक पाठ्यक्रम है, कोई कोड पाठ्यक्रम नहीं। यह आपको architecture चुनना सिखाता है, न कि इसे लागू करना। कार्यान्वयन अनुशासन पहले के Agent Factory पाठ्यक्रमों में रहता है। architectural तर्क के 30 पृष्ठों और छद्म कोड के कुल 5 पृष्ठों की अपेक्षा करें।
• पांच pattern संपूर्ण नहीं हैं। रियलिटी में graph-आधारित agent systems, वाद-विवाद pattern, ब्लैकबोर्ड pattern, पदानुक्रमित task नेटवर्क और अन्य शामिल नहीं हैं। यह पाठ्यक्रम उन पांच pattern को शामिल करता है जिन्हें लेख प्रमुख architectural शुरुआती बिंदुओं के रूप में पहचानता है; ये पांच production agent systems के मध्य-2026, के बड़े बहुमत को कवर करते हैं, हालांकि सभी को नहीं।
• decision tree एक प्रारंभिक बिंदु है, अंतिम उत्तर नहीं। वास्तविक agent architectures विकसित होता है। एक प्रणाली जो tools के साथ single agent के रूप में शुरू हुई थी, कार्यभार में विविधता आने पर वह multi-agent system में विकसित हो सकती है; जैसे-जैसे रास्ते स्पष्ट होते जाते हैं, planning-तब-निष्पादन प्रणाली sequential workflow में सरलीकृत हो सकती है। यह पाठ्यक्रम आरंभिक निर्णय सिखाता है, विकास नहीं।
• Cost और latency पसंद का हिस्सा हैं। Reflection latency जोड़ता है। Multi-agent tokens जोड़ता है। Planning एक अतिरिक्त LLM कॉल जोड़ता है। यह पाठ्यक्रम इन costs को वास्तविक बाधाओं के रूप में मानता है; अवधारणा 18 तब शामिल होती है जब प्रत्येक pattern का overhead उचित होता है।
• लेख रीढ़ है; रचना परत विस्तार है। Bala Priya C का decision tree इस पाठ्यक्रम की संरचनात्मक रीढ़ है। यह पाठ्यक्रम दो परतें जोड़ता है जो लेख में नहीं है: (ए) आपके deployment topology के लिए प्रत्येक pattern का क्या अर्थ है, और (बी) आपके eval suite के माध्यम से प्रत्येक pattern की विफलता मोड कैसा दिखता है। यदि आपने केवल लेख पढ़ा है, तो यह पाठ्यक्रम production-अनुशासन परत जोड़ता है।

---

चार सीखने के ट्रैक

ट्रैक	समय की प्रतिबद्धता	जो आप पूरा करते हैं	यह किसके लिए है
पाठक (शुद्ध वैचारिक)	~2-3 घंटे, कोई प्रयोगशाला नहीं	पूर्ण वैचारिक आर्क: भाग 1 (समस्या), भाग 2 (decision tree), भाग 3 (पांच pattern), भाग 4 (failure signals), और भाग 7. में समापन _ कोई वर्गीकरण अभ्यास नहीं, कोई decision lab नहीं।	इंजीनियरिंग लीडर, प्लेटफ़ॉर्म आर्किटेक्ट, या जिज्ञासु-लेकिन-गैर-इंजीनियर पाठक यह तय करते हैं कि टीम को व्यवस्थित pattern selection के लिए समय देना है या नहीं।
शुरुआती	~1 दिन	रीडर ट्रैक + निर्णय 1-2 decision lab में। decision tree का उपयोग करके दो कार्यों को वर्गीकृत करें (Maya का Tier-1 समर्थन और एक घटना-response agent); चुने गए pattern को उच्च स्तर पर स्केच करें।	agentic architecture में नए इंजीनियर जो निर्देशित pattern-चयन अभ्यास का एक दौर चाहते हैं।
मध्यवर्ती	~2-3 दिन	शुरुआती ट्रैक + निर्णय 3-4. एक research agent और एक enterprise onboarding agent जोड़ें; अपने cloud stack पर उनके deployment topologies को स्केच करें; eval signals की पहचान करें जो प्रत्येक pattern के विफलता मोड को पकड़ लेगा।	इंजीनियर shipping agentic सिस्टम जो deployment और मूल्यांकन के साथ pattern selection बनाना चाहते हैं।
उन्नत	~4-5 दिन	मध्यवर्ती ट्रैक + निर्णय 5 + भाग 6 और 7. एक coding agent जोड़ें (सबसे कठिन मामला); pattern composition का पता लगाएं (विभिन्न परतों पर कई pattern); वास्तुकार पूर्ण अनुशासन का उपयोग करते हुए एक काल्पनिक agent system शुरू से अंत तक।	वरिष्ठ इंजीनियर और तकनीकी नेतृत्वकर्ता जो pattern selection को एक टीम-व्यापी अनुशासन बनाना चाहते हैं।

ट्रैक-फोर्क मार्गदर्शन। इंजीनियरिंग लीडरों को रीडर ट्रैक से शुरुआत करनी चाहिए। इंजीनियरों को इंटरमीडिएट ट्रैक पर डिफ़ॉल्ट होना चाहिए, decision lab वह जगह है जहां framework वास्तव में आंतरिक होता है। भाग 5 को पूरी तरह से केवल इसलिए न छोड़ें क्योंकि आप भाग 2 को जल्दी से पढ़ सकते हैं। framework केवल तभी चिपकता है जब आपने इसे वास्तविक कार्यों पर लागू किया हो।

🚀 न्यूनतम व्यवहार्य पथ, pattern selection पर काम करने का सबसे छोटा मार्ग। भाग 1 (समस्या), भाग 2 (decision tree), और प्रयोगशाला से निर्णय 1 पढ़ें (Maya का Tier-1 समर्थन)। वह ~90 मिनट है; अंत में आप पाँच प्रश्नों का उपयोग करके एक नया task वर्गीकृत कर सकते हैं और एक प्रारंभिक pattern चुन सकते हैं। बाकी हर चीज़ अनुशासन को गहरा करती है; यह बीज है.

अंत में आपके पास क्या होगा (ठोस परिणाम)

रीडर ट्रैक समझ पैदा करता है, artifacts नहीं। आप यह बता सकते हैं कि कोड लिखे जाने से पहले pattern selection क्यों मायने रखता है; पाँच patternों में से प्रत्येक और उनकी विशिष्ट task धारणाओं का वर्णन कर सकेंगे; पाँच सामान्य failure signals को पहचानें जो pattern बेमेल का संकेत देते हैं।

शुरुआती/मध्यवर्ती/उन्नत ट्रैक एक कार्यशील वर्गीकरण अनुशासन तैयार करते हैं:

• एक नए task पर पांच-प्रश्न decision tree पर चलने और एक सैद्धांतिक शुरुआती pattern चुनने की क्षमता।
• आपके cloud stack पर प्रत्येक pattern के लिए deployment topology का एक स्केच (multi-agent या planning सिस्टम की तुलना में sequential workflow को किन घटकों की आवश्यकता होती है)।
• प्रत्येक pattern के संभावित विफलता मोड से विशिष्ट eval signals तक मैपिंग जो उन्हें पकड़ लेगी।
• एक टीम-साझा करने योग्य artifact: एक-पेज "वर्गीकृत-यह-task" टेम्पलेट जिसे आप डिज़ाइन समीक्षाओं में उपयोग कर सकते हैं।

---

टीएल;डीआर, यह पाठ्यक्रम जिन चार दावों का बचाव करता है

1. Pattern selection architectural fit है, क्षमता मिलान नहीं। प्रत्येक pattern task के बारे में कुछ न कुछ मानता है। सही pattern वह है जिसकी धारणाएँ task के वास्तविक गुणों से मेल खाती हैं, न कि सबसे अधिक क्षमता या सबसे प्रभावशाली संरचना वाला। _मल्टी-agent sequential workflow से "बेहतर" नहीं है; यह उस विशिष्ट मामले के लिए बेहतर है जहां विशेषज्ञता या पैमाना bottleneck बनाता है।

चार मुख्य pattern + एक योगात्मक परत। decision tree का Q1-Q3 एक कोर pattern चुनें: sequential workflow, single agent + ReAct + tools, planning + ReAct execution, या multi-agent specialist system। Q4 यह तय करता है कि चयनित कोर के शीर्ष पर एक योगात्मक परत के रूप में प्रतिबिंब जोड़ना है या नहीं। **Reflection पाँचवाँ सहकर्मी pattern नहीं है; यह एक गुणवत्ता-नियंत्रण परत है जो चार कोर में से किसी एक को लपेटती है। ** यह अंतर मायने रखता है: जो छात्र reflection को एक स्टैंडअलोन pattern के रूप में मानते हैं, वे architectural सच्चाई को याद करते हैं कि यह उनके द्वारा पहले से चुने गए किसी भी कोर pattern से बना है।

2. task के बारे में पांच प्रश्न architecture निर्धारित करते हैं। Q1-Q3 मुख्य pattern चुनें: क्या solution path ज्ञात है? क्या workflow ठीक हो गया है? क्या task structure व्यक्त करने योग्य है? Q4 तय करता है कि शीर्ष पर reflection परतें हैं या नहीं: क्या checkable criteria के साथ गुणवत्ता गति से अधिक मायने रखती है? Q5 तय करता है कि multi-agent में अपग्रेड करना है या नहीं: क्या कोई विशेषज्ञता है, context, या स्केल bottleneck? शुरुआती architecture के उत्तर map निश्चित रूप से देते हैं। लेख सही है कि decision logic, स्वयं pattern नहीं, वह है जो साहित्य से गायब है।
3. Pattern selection deployment topology और eval signals के साथ बनता है। प्रत्येक pattern cloud stack के एक अलग उपसमूह का उपयोग करता है: अनुक्रमिक workflows को sandbox निष्पादन की आवश्यकता नहीं होती है; मल्टी-agent systems को सावधानीपूर्वक ऑडिट लॉगिंग की आवश्यकता है क्योंकि समन्वय विफलताएं सबसे कठिन production बग हैं। प्रत्येक pattern में विशिष्ट विफलता मोड होते हैं जिन्हें आपका eval suite अलग ढंग से पकड़ता है। इस विषय पर कुछ पाठ्यक्रम इस संरचना को सिखाते हैं, क्योंकि इसे आधार के रूप में deployment और eval पाठ्यक्रमों की आवश्यकता होती है।
4. decision tree एक प्रारंभिक बिंदु देता है, अंतिम उत्तर नहीं। वास्तविक सिस्टम विकसित होते हैं। अनुशासन "हमेशा के लिए architecture में बंद" नहीं है, यह "प्रारंभिक निर्णय को सैद्धांतिक बनाएं, failure signals पर नज़र रखें, और runtime साक्ष्य को विकास का मार्गदर्शन करने दें।" pattern चयन पहला कदम है; pattern संशोधन जारी है।

आप जो सीख रहे हैं उसका आकार (एक आरेख, पूरे समय देखें)

यह पाठ्यक्रम 22 अवधारणाओं (19 मुख्य प्लस 3 ब्रिज अवधारणाओं पर 8.5, 8.6, और 16.5) का परिचय देता है और 5 निर्णयों के माध्यम से चलता है। इनमें से किसी से भी पहले, यहाँ decision tree है जो इसके चारों ओर रचित है।

*पेड़ का आकार: यह पूछकर शुरू करें कि क्या आपको LLM-driven agent (Q1-Q2) की भी आवश्यकता है; यदि हां, तो पूछें कि task कितना संरचित है (Q3); फिर गुणवत्ता (Q4) और पैमाने (Q5) पर केवल तभी परत चढ़ाएं जब वे वास्तविक मूल्य बनाते हैं। जब भी कोई अवधारणा या निर्णय अमूर्त लगे तो इस आरेख को वापस देखें।*

---

भाग 1: pattern-चयन समस्या

संकल्पना 1: Pattern selection वह डिज़ाइन कार्य है जो build से पहले आता है

agentic सिस्टम पर अधिकांश पाठ्यक्रम आपको प्रत्येक pattern का निर्माण करना सिखाते हैं। यह पाठ्यक्रम एक अलग प्रश्न के बारे में है: task दिया गया है, आपको कौन सा pattern build चाहिए? यह प्रश्न build से पहले आता है, और यह होना चाहिए, लेकिन एक अजीब कारण से इसे आमतौर पर नहीं पढ़ाया जाता है: ** प्रत्येक pattern का कार्यान्वयन अच्छी तरह से प्रलेखित है; उनके बीच चयन करने के लिए decision logic नहीं है।**

pattern कैटलॉग परिपक्व है. ReAct 2022 पेपर से आता है। Planning-तब-निष्पादन pattern trace शास्त्रीय AI में स्ट्रिप्स पर वापस आ गया और 2023. में LLMs के लिए फिर से खोजा गया Reflection को औपचारिक रूप दिया गया है क्योंकि 2023. Multi-agent architectures को हर प्रमुख framework द्वारा सिखाया जाता है। आप पांच मिनट से कम समय में किसी भी pattern के लिए एक ट्यूटोरियल पा सकते हैं। जो आप आसानी से नहीं पा सकते हैं वह है: इन विशिष्ट बाधाओं के साथ इस विशिष्ट task को देखते हुए, कौन सा pattern फिट बैठता है?

यह विफलता मोड बनाता है। इंजीनियर उस pattern को डिफ़ॉल्ट करते हैं जिसका उन्हें हाल ही में सामना करना पड़ा या जो बातचीत में सबसे प्रभावशाली दिखता है। agents डेमो विशेष रूप से आकर्षक हैं क्योंकि वे "वास्तविक AI" की तरह दिखते हैं: agents एक-दूसरे से बात कर रहे हैं, श्रम को विभाजित कर रहे हैं, समन्वय कर रहे हैं। टीमें दो अच्छी तरह से परिभाषित tools के साथ single agent समस्याओं के लिए ऑर्केस्ट्रेशन बनाने में कई सप्ताह बिताती हैं, जिन्हें एक दिन में हल किया जा सकता है। परिणाम: वे ship धीमे हैं, अधिक डीबग करते हैं, और tokens में आवश्यक task से अधिक भुगतान करते हैं।

विपरीत विफलता मोड भी वास्तविक है और कम चर्चा की जाती है। जब task को वास्तव में संरचनात्मक अपघटन की आवश्यकता होती है, तो इंजीनियर "वास्तव में लंबे सिस्टम prompt के साथ single agent का उपयोग करें" तक पहुंचते हैं। agent context के अंतर्गत ढह जाता है जो एक मानसिक model में फिट नहीं बैठता है। Tool-कॉलिंग त्रुटियां कैस्केड होती हैं। Reflection एकमात्र फिक्स बन जाता है जिसे टीम जानती है, इसलिए वे इसे हर जगह जोड़ते हैं, और अब प्रत्येक response को 30 सेकंड लगते हैं। वे ship कुछ भंगुर हैं जिसे architectural विकल्प द्वारा रोका जा सकता था।

यह पाठ्यक्रम जो अनुशासन सिखाता है: pattern चयन architectural fit-मिलान है, क्षमता मिलान नहीं। यह न पूछें कि "सबसे अच्छा pattern क्या है?" (वहाँ एक भी नहीं है). पूछें "इस task को वास्तव में क्या चाहिए, और सबसे छोटा pattern क्या है जो इसे प्रदान करता है?" भाग 2 में पाँच-प्रश्न decision tree यह है कि आप उसका व्यवस्थित रूप से उत्तर कैसे देते हैं।

यह पहले की तुलना में अधिक महत्वपूर्ण क्यों है। 2023, में agentic प्रणालियाँ प्रयोगात्मक थीं। गलत pattern चुनने से एक सप्ताहांत बर्बाद हो गया। 2026, में agentic सिस्टम production में वास्तविक उपयोगकर्ताओं को सेवा प्रदान कर रहे हैं; आपके द्वारा चुना गया pattern आपके deployment topology, आपके ईवल अनुशासन और पैमाने पर आपके परिचालन cost को निर्धारित करता है। एक गलत pattern का चुनाव अब कई मायनों में महंगा है: गलत धारणा के लिए बनाया गया बुनियादी ढांचा, गलत विफलता मोड के लिए लिखे गए मूल्यांकन, गलत घटनाओं पर प्रतिक्रिया देने वाली रनबुक। Pattern selection "वरीयता" से "उच्च-दांव डिजाइन निर्णय" में स्थानांतरित हो गया है।

मुख्य पंक्ति: pattern स्वयं अच्छी तरह से प्रलेखित हैं; उनके बीच चयन करने के लिए decision logic वह अंतर है जिसे यह पाठ्यक्रम भरता है। Pattern selection architectural fit-मिलान है, क्षमता मिलान नहीं। गलत pattern production में महंगा पड़ता है: गलत बुनियादी ढांचा, गलत मूल्यांकन, गलत रनबुक। यह पाठ्यक्रम पाँच-प्रश्नों वाला अनुशासन सिखाता है जो सबसे आम pattern-चयन विफलताओं को रोकता है।

अवधारणा 2: प्रत्येक pattern task के बारे में कुछ अलग मानता है

गहरा विचार जो pattern selection को सुव्यवस्थित बनाता है: प्रत्येक agentic pattern एक शर्त है कि task कैसा दिखता है। जब शर्त वास्तविकता से मेल खाती है, तो pattern मूल्य जोड़ता है। जब दांव गलत होता है, तो pattern overhead बन जाता है, कभी-कभी अदृश्य overhead जो सिर्फ costs tokens होता है, कभी-कभी विनाशकारी overhead होता है जो सिस्टम को पूरी तरह से तोड़ देता है।

यहां बताया गया है कि पांच pattern में से प्रत्येक पर क्या दांव लगाया जा रहा है:

Sequential workflow दांव: मुझे चरण पहले से पता हैं, और वे हर बार समान होते हैं। शर्त यह है कि runtime से पहले solution path निश्चित और स्पष्ट है। _यदि सत्य है, तो आगे क्या करना है यह तय करने के लिए आपको LLM की आवश्यकता नहीं है: workflow जानता है। आप LLM कॉल को केवल उन चरणों के लिए आरक्षित रखते हैं जिनकी वास्तव में व्याख्या की आवश्यकता है (इसे पाठ से निकालें, वह सारांश तैयार करें)। Cost पूर्वानुमानित है; latency परिबद्ध है; विफलता के तरीके स्पष्ट हैं. यदि गलत है: यदि चरण वास्तव में इनपुट में शामिल चीज़ों के आधार पर भिन्न होते हैं, तो workflow गलत पथ को बाध्य करता है या शोर से विफल हो जाता है।

Single agent + ReAct + tools दांव: मुझे पहले से रास्ता नहीं पता; agent इसका पता लगा लेगा। शर्त यह है कि task इतना खुला है कि अब तक जो देखा गया है उसके आधार पर अगला कदम तय किया जाना चाहिए। यदि सत्य है, ReAct का loop (कारण → कार्य → निरीक्षण → दोहराना) ही इसे संभालने का एकमात्र तरीका है, कोई भी पूर्वनिर्धारित योजना कदम से गलत होगी 3. यदि गलत: यदि पथ वास्तव में काफी स्थिर है और लिखा जा सकता है, तो ReAct latency, cost, और जोखिम जोड़ता है agent लूपिंग या हल किए गए काम पर दोबारा गौर करना, यह सब कुछ भी खरीदे बिना जो आप sequential workflow से प्राप्त नहीं कर सकते।

Planning + ReAct execution दांव: मैं प्रमुख चरणों और निर्भरताओं को पहले से स्पष्ट कर सकता हूं, लेकिन प्रत्येक चरण के लिए अभी भी अनुकूली तर्क की आवश्यकता होती है। शर्त यह है कि कार्य का आकार ज्ञात है (अनुसंधान → विश्लेषण → संश्लेषण → रिपोर्ट) लेकिन प्रत्येक चरण की सामग्री की जांच की आवश्यकता होती है। यदि सत्य है, योजना मचान प्रदान करती है और agent को भटकने से रोकती है, जबकि प्रत्येक चरण के अंदर ReAct अनिश्चितता को संभालती है। यदि गलत है: यदि योजना को वास्तव में स्पष्ट नहीं किया जा सकता है (शुद्ध ReAct का उपयोग करें) या प्रत्येक चरण को अनुकूली तर्क की आवश्यकता नहीं है (sequential workflow का उपयोग करें), तो योजना overhead बन जाती है जिसका निष्पादन किसी भी तरह से अलग हो जाता है।

Reflection दांव: आउटपुट गुणवत्ता गति से अधिक मायने रखती है, और गुणवत्ता जांच योग्य है। शर्त यह है कि एक समालोचना पास उन दोषों की पहचान कर सकता है जो generator चूक गए हैं, और यह कि "अच्छे आउटपुट" के लिए criteria पर्याप्त स्पष्ट हैं कि आलोचना सार्थक है। यदि सत्य है, reflection पहले पास में उत्पन्न त्रुटियों को पकड़कर विश्वसनीयता में सुधार करता है (गलत SQL, कमजोर कानूनी arguments, रिपोर्ट में तथ्यात्मक गलतियाँ)। यदि गलत है: यदि criteria अस्पष्ट हैं या यदि critic और generator समान ब्लाइंड स्पॉट साझा करते हैं, तो reflection आउटपुट में सुधार किए बिना latency और cost जोड़ता है। इससे भी बदतर: यह झूठा विश्वास पैदा कर सकता है कि आलोचना की "सत्यापित" गुणवत्ता वास्तव में सत्यापित नहीं है।

Multi-agent specialist system दांव: नहीं single agent के पास इसे अच्छी तरह से करने के लिए विशेषज्ञता, context या क्षमता नहीं है। शर्त यह है कि task वास्तव में specialist भूमिकाओं में विभाजित होता है (researcher + writer + reviewer; कोडर + सुरक्षा + डॉक्स), और specialists में समन्वय एक ओवरलोड से सस्ता है agent. यदि सत्य है, specialists अपने डोमेन में एक सामान्य विशेषज्ञ की तुलना में बेहतर आउटपुट उत्पन्न करता है, और parallel execution throughput में सुधार करता है। यदि गलत है: यदि "specialists" अधिकतर एक ही काम कर रहे हैं, या यदि coordination overhead काम पर हावी है, तो आपने जटिलता जोड़ दी है जिससे कुछ भी नहीं मिलता है और नए विफलता मोड (रूटिंग त्रुटियां, एकीकरण त्रुटियां, स्वामित्व अस्पष्टता) पेश किए जाते हैं।

pattern ही शर्त है; task के वास्तविक गुण यह निर्धारित करते हैं कि दांव सही है या नहीं। यही कारण है कि pattern selection fit-matching है। आप यह नहीं पूछ रहे हैं कि "कौन सा pattern सबसे शक्तिशाली है?" आप पूछ रहे हैं "किस pattern का दांव इस task के बारे में मुझे वास्तव में जो पता है उससे सबसे अच्छा मेल खाता है?"

निचली पंक्ति: प्रत्येक agentic pattern task के बारे में एक दांव है: sequential workflow ज्ञात निश्चित पथों पर दांव लगाता है, ReAct अज्ञात अनुकूली पथों पर दांव लगाता है, planning स्पष्ट संरचना पर दांव लगाता है, reflection जांच योग्य गुणवत्ता पर दांव लगाता है criteria, multi-agent वास्तविक विशेषज्ञता आवश्यकताओं पर दांव लगाता है। सही pattern वह है जिसका दांव वास्तविकता से मेल खाता हो; pattern selection fit-matching है, क्षमता मिलान नहीं।

संकल्पना 3: दो विफलता मोड, ओवरशूटिंग और अंडरशूटिंग

अवधारणा 2 ने कहा कि प्रत्येक pattern एक शर्त है। संकल्पना production उन दो तरीकों का नाम देती है जिनसे दांव गलत हो जाता है, और वे वास्तविक production सिस्टम में लगभग समान आवृत्ति के साथ होते हैं।

ओवरशूटिंग: task की आवश्यकता से अधिक विस्तृत pattern चुनना। यह अधिक प्रसिद्ध विफलता मोड है, जिसमें बातचीत और डेमो आसानी से शामिल हो जाते हैं। उदाहरण:

• एक task के लिए तीन-agent system (researcher, writer, reviewer) का निर्माण, जो एक एकल LinkedIn-पोस्ट पीढ़ी है। "researcher" agent का आउटपुट दो पैराग्राफ है, फिर "writer" को संक्षेप में प्रस्तुत करना होगा। reviewer उन मुद्दों के लिए आउटपुट के 5% को अस्वीकार कर देता है जिन्हें स्वयं-जांच prompt पकड़ लेता। तीन agents, cost से तीन गुना, कोई मापने योग्य गुणवत्ता सुधार नहीं।
• task में planning जोड़ना वास्तव में एक fixed workflow है। planner हर बार एक ही योजना तैयार करता है (क्योंकि task वही है)। प्रत्येक रन के लिए अतिरिक्त LLM कॉल का भुगतान करना पड़ता है। बदतर: जब इनपुट थोड़ा असामान्य होता है, तो planner थोड़ा अलग योजना तैयार करता है, और अब टीम को डीबग करना होगा "planner ने इस इनपुट पर एक अलग रास्ता क्यों अपनाया?"
• checkable criteria के बिना task में reflection जोड़ना। critic और generator समान model, समान प्रशिक्षण डेटा और (अक्सर) समान ब्लाइंड स्पॉट साझा करते हैं। reflection पास या तो आउटपुट पर रबर-स्टैम्प लगाता है या वर्बोज़-लेकिन-नॉन-एक्शनेबल आलोचना उत्पन्न करता है। विलंबता दोगुनी हो जाती है; गुणवत्ता स्थिर रहती है.

ओवरशूटिंग विफलता pattern: आपने उस क्षमता के लिए भुगतान किया है जिसकी task को आवश्यकता नहीं थी, और आप इसे आसानी से पूर्ववत नहीं कर सकते क्योंकि ऑर्केस्ट्रेशन अब load-असर है। छह महीने से production में मौजूद multi-agent system को हटाना कोई रिफैक्टर नहीं है; यह एक पुनर्लेखन है.

अंडरशूटिंग: वास्तव में task की आवश्यकता की तुलना में एक सरल pattern चुनना। यह विफलता मोड है जो बातचीत में शायद ही कभी दिखाई देता है क्योंकि यह नाटकीय रूप से कम प्रभावशाली है, लेकिन यह कम से कम सामान्य है। उदाहरण:

• billing, तकनीकी, account, और refund मुद्दों में customer support को संभालने के लिए 4,000-token सिस्टम prompt के साथ single agent का उपयोग करना। agent तकनीकी नियमों के साथ billing नियमों को भ्रमित करता है। Reflection मामूली मदद करता है लेकिन मूल कारण को ठीक नहीं करता है। task को वास्तव में specialist रूटिंग की आवश्यकता थी; एक agent context को पकड़ नहीं सका।
• workflow के लिए ReAct + tools का उपयोग करना जो एक निश्चित pipeline होना चाहिए। agent कभी-कभी चरणों को छोड़ देता है, कभी-कभी पूर्ण किए गए कार्य को दोबारा देखता है, कभी-कभी tool calls का आविष्कार करता है जो अस्तित्व में नहीं है। टीम prompt में "stop conditions" और "प्रगति criteria" जोड़ती है, जो अंतर्निहित बेमेल के बजाय लक्षणों का इलाज करती है। लागत भिन्नता एक रनबुक समस्या बन जाती है।
• उन आउटपुट पर reflection को छोड़ना जिन्हें वास्तव में सत्यापन की आवश्यकता है। SQL queries सूक्ष्म त्रुटियों के साथ ship से production। कानूनी ड्राफ्ट उद्धरण संबंधी गलतियों के साथ clients को भेजे जाते हैं। टीम तथ्य के बाद परीक्षण जोड़ती है, लेकिन इन त्रुटियों को पकड़ने का स्वाभाविक स्थान पीढ़ी के समय reflection पास था।

अंडरशूटिंग विफलता pattern: आपने कुछ भंगुर भेजा है जो मैन्युअल निरीक्षण या भाग्यशाली होने से बच जाता है। Production अंतराल का खुलासा करता है; remediation में या तो उस pattern को जोड़ना शामिल है जिसके साथ आपको शुरुआत करनी चाहिए थी या विफलता दर को व्यवसाय करने के cost के रूप में स्वीकार करना शामिल है।

दोनों विफलता मोड समान रूप से महत्वपूर्ण क्यों हैं। pattern selection की चर्चाएं ओवरशूटिंग पर ध्यान केंद्रित करती हैं (क्योंकि यह अधिक दिखाई देने वाली विफलता है, multi-agent system जिसे कोई भी डीबग नहीं कर सकता है)। लेकिन अंडरशूटिंग उतना ही सामान्य और यकीनन अधिक खतरनाक है: यह ऐसे सिस्टम तैयार करता है जो तब तक काम करते प्रतीत होते हैं जब तक वे काम नहीं करते, और विफलता के तरीके सूक्ष्म होते हैं। एक टीम जो ओवरशूटिंग से बचना सीखती है, लेकिन अंडरशूटिंग को कभी नहीं पहचानती, उसने केवल आधा अनुशासन ही सीखा है।

भाग 2 में decision tree को दोनों विफलता मोड को प्रदर्शित करने के लिए डिज़ाइन किया गया है। प्रत्येक प्रश्न एक कार्य गुण के बारे में पूछता है (क्या पथ ज्ञात है? क्या संरचना स्पष्ट है? क्या गुणवत्ता जांच योग्य है?); यदि उत्तर अधिक विस्तृत pattern को उचित नहीं ठहराता है, तो पेड़ एक सरल pattern की ओर ले जाता है (overshoot को रोकते हुए)। यदि उत्तर अधिक विस्तृत pattern को उचित ठहराता है, तो पेड़ वहां स्पष्ट रूप से रूट करता है (अपग्रेड को जागरूक बनाकर undershoot को रोकता है)।

निचली पंक्ति: pattern selection दो तरह से विफल रहता है: ओवरशूटिंग (task की आवश्यकता से अधिक विस्तृत pattern चुनना, उस क्षमता के लिए भुगतान करना जो मदद नहीं करती है) और अंडरशूटिंग (task की आवश्यकता से अधिक सरल pattern चुनना, shipping कुछ भंगुर होना)। दोनों विफलता मोड लगभग समान आवृत्ति के साथ होते हैं; बातचीत ओवरशूटिंग पर जोर देती है लेकिन अंडरशूटिंग कम से कम उतना ही खतरनाक है क्योंकि यह अधिक सूक्ष्म है। भाग 2 में decision tree pattern प्राथमिकताओं के बजाय task गुणों के बारे में पूछकर दोनों विफलताओं को सामने लाता है।

---

भाग 2: पाँच-प्रश्न decision tree

यह भाग प्रश्न दर प्रश्न decision tree पर चलता है। प्रत्येक संकल्पना में पांच प्रश्नों में से एक को शामिल किया गया है: यह क्या परीक्षण करता है, वास्तविक task के लिए इसका उत्तर कैसे देना है, और उत्तर को किस pattern पर ले जाना है। भाग 2, के अंत तक आप एक बार पूरे पेड़ पर चल चुके होंगे।

पेड़ की संरचना:

#	प्रश्न	यह क्या परीक्षण करता है	के लिए मार्ग
प्रश्न1	क्या solution path को पहले से परिभाषित किया जा सकता है?	क्या प्रक्रिया को runtime से पहले निर्दिष्ट किया जा सकता है	यदि हाँ → Q2 (fixed workflow जाँच); यदि नहीं → अनुकूली तर्क की आवश्यकता है, तो Q3 पर जाएँ
Q2	क्या workflow runs पर स्थिर और स्थिर है?	क्या हर बार वही चरण लागू होते हैं	यदि हाँ → Sequential Workflow; यदि नहीं → अनुकूली pattern पर दोबारा गौर करें
Q3	क्या task structure निष्पादन से पहले स्पष्ट किया जा सकता है?	क्या प्रमुख चरण और निर्भरताएँ स्पष्ट हैं	यदि हाँ → Planning + ReAct execution; यदि नहीं → Single agent + ReAct + tools
प्रश्न4	क्या checkable criteria के साथ गुणवत्ता गति से अधिक मायने रखती है?	क्या अतिरिक्त आलोचना/शोधन पास latency/cost के लायक हैं	यदि हां → चुने गए pattern के शीर्ष पर Reflection layer जोड़ें; यदि नहीं → छोड़ें reflection
Q5	क्या कोई विशेषज्ञता है, context, या स्केल bottleneck?	क्या किसी agent के पास विशेषज्ञता का अभाव है, context, या parallel capacity	यदि हाँ → Multi-Agent Specialist System; यदि नहीं → single agent रखें

प्रश्न 1-3 मूल pattern निर्धारित करते हैं। प्रश्न 4-5 योगात्मक परतें हैं; वे किसी भी मूल pattern के शीर्ष पर आवेदन कर सकते हैं, लेकिन केवल तभी जब उनकी धारणाएँ मान्य हों।

संकल्पना 4: Q1: क्या solution path को पहले से परिभाषित किया जा सकता है?

सबसे महत्वपूर्ण प्रश्न, क्योंकि यह निर्धारित करता है कि आपको agentic सिस्टम की आवश्यकता है या नहीं।

"solution path" का क्या अर्थ है। सीधे: यदि मैं आपको इनपुट बताता हूं, तो क्या आप मुझे आउटपुट उत्पन्न करने वाले चरणों का सटीक अनुक्रम बता सकते हैं? स्वयं उत्तर नहीं, केवल पथ। invoice intake के लिए: ईमेल प्राप्त करें → संरचित फ़ील्ड निकालें → database के विरुद्ध सत्यापन करें → स्टोर → अनुरोधकर्ता को सूचित करें। पांच कदम, हर बार वही पांच कदम। यह एक ज्ञात solution path है।

कंट्रास्ट: एक ग्राहक पूछता है "मुझसे नवंबर 12 पर दो बार शुल्क क्यों लिया गया?" रास्ता इस पर निर्भर करता है कि आप क्या पाते हैं। लेन-देन का इतिहास देखें. इसे ढूंढें। दोनों आरोप अलग-अलग व्यापारियों की ओर से हैं, "क्या यह धोखाधड़ी थी?" या वे अलग-अलग टाइमस्टैम्प वाले एक ही व्यापारी हैं, "क्या दूसरा retry था?" या ग्राहक के account के एकाधिक उपयोगकर्ता हैं, "क्या किसी और ने खरीदारी की?" प्रत्येक शाखा एक अलग अगले चरण की ओर ले जाती है। पथ को पहले से निर्दिष्ट नहीं किया जा सकता है; यह जांच से जो पता चलता है उससे सामने आता है। यह एक अज्ञात solution path है।

इसका ईमानदारी से परीक्षण कैसे करें। क्रम में तीन परीक्षण:

1. क्या आप इनपुट देखने से पहले चरणों का फ़्लोचार्ट लिख सकते हैं? यदि हाँ, तो पथ ज्ञात है। यदि आपके फ़्लोचार्ट को "अब agent तय करता है कि क्या करना है" बॉक्स की आवश्यकता है, तो पथ अज्ञात है।
2. क्या चरण कई runs में अपरिवर्तित दोहराए जाते हैं? Invoice intake दोहराए जाते हैं। Customer support जांच नहीं होती। एक शोध रिपोर्ट की रूपरेखा हर बार एक ही आकार की हो सकती है (परिचय, तीन खंड, निष्कर्ष) लेकिन सामग्री खोज एक चरण अनुक्रम नहीं है; यह अनुकूली खोज है.
3. जब इनपुट बदलता है, तो क्या चरण बदलते हैं? एक ज्ञात पथ विभिन्न इनपुट के लिए समान चरण अनुक्रम उत्पन्न करता है। एक अज्ञात पथ प्रत्येक चरण से जो पता चलता है उसके आधार पर अलग-अलग चरण अनुक्रम उत्पन्न करता है।

जहां टीमें यह गलत करती हैं। सबसे आम त्रुटि यह मानना है कि पथ ज्ञात है क्योंकि task विवरण संरचित लगता है। "प्रक्रिया refund requests" ज्ञात लगता है: request प्राप्त करें, ऑर्डर देखें, refund जारी करें, ग्राहक को सूचित करें। वास्तविक refund requests ऐसे नहीं हैं। कुछ को विवाद जांच की आवश्यकता होती है (क्या यह चार्जबैक था?), कुछ को पॉलिसी लुकअप की आवश्यकता होती है (क्या इस ग्राहक की योजना रिफंड की अनुमति देती है?), कुछ को वृद्धि की आवश्यकता होती है (राशि agent के अधिकार से अधिक है), कुछ में कई शुल्क शामिल होते हैं जिन्हें स्पष्ट करने की आवश्यकता होती है। चार-चरणीय फ़्लोचार्ट ग़लत है; वास्तविक पथ अनुकूली है.

दर्पण त्रुटि: विश्वास करना कि पथ अज्ञात है क्योंकि task विवरण खुला हुआ लगता है। "आज रात शहर में एक अच्छा रेस्तरां ढूंढने में मेरी मदद करें" _अनुकूली लगता है, लेकिन यदि वास्तविक कार्यान्वयन है: request → query रेस्तरां database को फ़िल्टर के साथ पार्स करें → return रेटिंग के आधार पर शीर्ष 5, पथ ज्ञात है और एक sequential workflow सही pattern है। "agentic" फ़्रेमिंग भ्रामक थी।

मार्ग। यदि पथ ज्ञात है (और स्थिर है, तो अगला Q2 देखें), आप sequential workflow की ओर जा रहे हैं। **आपको LLM-driven agent की आवश्यकता भी नहीं हो सकती; आपको व्याख्या या निर्माण के लिए विशिष्ट चरणों में एम्बेडेड LLM कॉल के साथ workflow की आवश्यकता हो सकती है। ** यदि पथ अज्ञात है, तो आपको agentic तर्क की आवश्यकता है, सवाल यह है कि क्या संरचना स्पष्ट है (Q3, planning) या नहीं (Q3, शुद्ध ReAct)।

एक उपयोगी अनुमान। अपने आप से पूछें: "अगर मुझे इसे Python function के रूप में बिना LLM कॉल के लिखना होता, तो क्या मुझे पता होता कि इसे कैसे संरचित किया जाए?" यदि हाँ, तो पथ संभवतः ज्ञात है; LLM केवल विशिष्ट तर्क या पीढ़ी के क्षणों के लिए आवश्यक है। यदि नहीं, तो संभवतः पथ अज्ञात है; LLM संरचनात्मक निर्णय ले रहा है, न कि केवल उत्पादक।

निचली पंक्ति: Q1 पूछता है कि क्या solution path को runtime से पहले निर्दिष्ट किया जा सकता है। अनुक्रमिक workflows (Q2) के लिए ज्ञात पथ मार्ग; अज्ञात पथ अनुकूली agentic तर्क (Q3) की ओर ले जाते हैं। सबसे आम त्रुटि यह मानना ​​है कि पथ ज्ञात है जब task विवरण संरचित लगता है लेकिन वास्तविक कार्यान्वयन अनुकूली है, refund प्रसंस्करण, customer support, debugging। विपरीत त्रुटि यह मानना ​​है कि पथ अज्ञात है जबकि यह वास्तव में LLM-सुगंधित इनपुट वाला workflow है। "Python function बिना LLM कॉल्स" अनुमान के साथ परीक्षण करें।

अवधारणा 5: Q2: क्या workflow runs में स्थिर और स्थिर है?

आपने Q1 का उत्तर "हां, रास्ता ज्ञात है" कहकर दिया है। Q2 दूसरी जांच है: क्या यह उन सभी इनपुटों पर स्थिर और स्थिर है जिनकी आप वास्तव में अपेक्षा करते हैं? क्योंकि "ज्ञात" और "स्थिर" एक ही चीज़ नहीं हैं।

अंतर। एक मार्ग को सिद्धांत रूप में जाना जा सकता है लेकिन व्यवहार में भिन्न होता है। एक "अनुसंधान सहायक" agent पर विचार करें जो उपयोगकर्ता queries को संभालता है। कभी-कभी उपयोगकर्ता त्वरित उत्तर चाहता है (एक तथ्य देखें, return इसे)। कभी-कभी वे बहु-स्रोत संश्लेषण (खोज, तुलना, सारांश) चाहते हैं। कभी-कभी वे अपने द्वारा अपलोड किए गए दस्तावेज़ का विश्लेषण चाहते हैं (इसे पढ़ें, दावे निकालें, मूल्यांकन करें)। आप प्रत्येक मामले के लिए पथ लिख सकते हैं, लेकिन पथ इनपुट प्रकार के साथ भिन्न होता है। यह ज्ञात-लेकिन-परिवर्तनीय है, ज्ञात-और-स्थिर नहीं है।

बनाम: invoice intake। प्रत्येक चालान समान पाँच चरणों से होकर गुजरता है। पथ स्थिर है। प्रत्येक चरण की सामग्री अलग-अलग होती है (अलग-अलग विक्रेता, अलग-अलग मात्रा), लेकिन चरण संरचना में नहीं।

यह क्यों मायने रखता है। एक sequential workflow स्थिरता मानता है। यदि आप एक निश्चित pipeline build करते हैं और पथ बदलता रहता है, तो pipeline कुछ इनपुट के लिए गलत पथ को बाध्य करता है, या तो उन चरणों को लागू करने का प्रयास करके जो लागू नहीं होते हैं (त्वरित-उत्तर query को पूर्ण संश्लेषण उपचार मिलता है) या शोर से विफल होने से (दस्तावेज़-विश्लेषण पथ त्वरित-उत्तर चरण संरचना में फिट नहीं होता है)।

परीक्षण। वास्तविक इनपुट के प्रतिनिधि नमूने को देखें (या उनकी सावधानीपूर्वक कल्पना करें)। क्या चरण क्रम उन सभी में समान रहता है?

• हां, प्रत्येक इनपुट समान चरणों से गुजरता है → workflow स्थिर है; build और sequential workflow।
• नहीं, अलग-अलग इनपुट के लिए अलग-अलग चरण अनुक्रम की आवश्यकता होती है → workflow परिवर्तनशील है; आपको या तो (ए) स्पष्ट शाखा के साथ एक workflow की आवश्यकता है जो प्रत्येक संस्करण को संभालती है, या (बी) एक agentic pattern की आवश्यकता है जो इनपुट के आधार पर पथ को अनुकूलित करता है।

जहां टीमों को यह गलती मिलती है। "औसतन ज्ञात" को "ज्ञात और स्थिर" के रूप में मानना। 80% मामला एक fixed workflow है; 20% मामले में विचलन की आवश्यकता है। इंजीनियर build को 80% मामले के लिए workflow बनाते हैं और 20% के लिए तदर्थ पैच जोड़ते हैं। ** अंततः पैच मूल workflow पर हावी हो जाते हैं, और आपके पास एक अप्रलेखित हाइब्रिड होता है जिसे कोई नहीं समझता है।** यह pattern सबसे अधिक बार तब दिखाई देता है जब टीम यह स्वीकार करने में अनिच्छुक होती है कि task उनकी अपेक्षा से अधिक अनुकूली है: अनुक्रमिक workflows agentic pattern की तुलना में अधिक सुरक्षित महसूस करते हैं, इसलिए वे ओवर-फिट होते हैं।

मार्ग। यदि workflow स्थिर और स्थिर है → Sequential Workflow। पेड़ की इस शाखा के लिए यहां रुकें। प्रश्न छोड़ें 3 और (अक्सर) 4. केवल Q5 पर विचार करें यदि स्केल workflow उदाहरणों में समानांतरीकरण को बल देता है।

यदि workflow ज्ञात-लेकिन-चर है → आपके पास दो विकल्प हैं:

1. Sequential workflow स्पष्ट शाखाओं के साथ: प्रत्येक प्रकार को एक शाखा के रूप में लिखें; इसे निश्चित रूप से रूट करें (अक्सर एक छोटे LLM कॉल के माध्यम से जो केवल इनपुट प्रकार को वर्गीकृत करता है, फिर रूट)। सबसे अच्छा तब जब वेरिएंट कम और स्थिर हों।
2. पथ को प्रभावी रूप से अज्ञात मानें: Q3 पर आगे बढ़ें और agentic तर्क को भिन्नता को संभालने दें। सर्वोत्तम तब होता है जब वैरिएंट बहुत अधिक हों या विकसित हो रहे हों।

व्यावहारिक अनुमान। यदि आप एक ओर वेरिएंट को list कर सकते हैं और वे अक्सर नहीं बदलते हैं, तो branched workflow। यदि आप नहीं कर सकते, agentic pattern।

निचली पंक्ति: Q2 पूछता है कि क्या ज्ञात पथ आपके अपेक्षित इनपुट पर भी स्थिर है। अनुक्रमिक workflows के लिए स्थिर पथ मार्ग। ज्ञात-लेकिन-परिवर्तनीय पथ या तो स्पष्ट शाखाओं वाले (कुछ स्थिर वेरिएंट) या agentic pattern (कई या विकसित वेरिएंट) के साथ workflows तक जाते हैं। जाल "80% मामला तय हो गया है" को "तय" मान रहा है; 20% केस पैच में विकसित होता है जो मूल डिज़ाइन पर हावी होता है।

संकल्पना 6: Q3: क्या task structure निष्पादन से पहले स्पष्ट किया जा सकता है?

आपने Q1 का उत्तर "पथ अज्ञात है" के साथ दिया है, agentic तर्क की आवश्यकता है। Q3 अगला प्रश्न पूछता है: क्या कार्य की उच्च-स्तरीय संरचना पहले से व्यक्त की जा सकती है, भले ही विशिष्ट चरण न हों?

यहाँ "संरचना" का क्या अर्थ है। स्वयं चरण नहीं, वे, Q1 के अनुसार, अज्ञात हैं। चरण और उनकी निर्भरताएँ। उदाहरण: एक market research agent। आप पहले से चरण निर्दिष्ट नहीं कर सकते (किस स्रोत से परामर्श लेना है, किस competitors की जांच करनी है, कौन सा विश्लेषण चलाना है यह इस पर निर्भर करता है कि आप क्या पाते हैं)। लेकिन आप संरचना को स्पष्ट कर सकते हैं: डेटा इकट्ठा करें → विश्लेषण करें → संश्लेषण करें → रिपोर्ट करें। चार चरण, उस क्रम में, स्पष्ट निर्भरता के साथ। यह स्पष्ट संरचना है।

कंट्रास्ट: एक customer-support agent हैंडलिंग "मुझे एक समस्या हो रही है।" agent जांच करता है। यह जो पाता है उसके आधार पर, कार्य के लिए account लुकअप, फिर ज्ञान-आधार खोज, फिर नीति जांच, फिर वृद्धि की आवश्यकता हो सकती है, या इनमें से किसी की भी आवश्यकता नहीं हो सकती है, बस एक त्वरित पुनर्निर्देशन की आवश्यकता हो सकती है। आप चरणों को स्पष्ट नहीं कर सकते क्योंकि कार्य किसी मंच संरचना में फिट नहीं बैठता; यह जांच है जो पूरी होने पर पूरी होती है। यह कहने योग्य नहीं है।

परीक्षण। किसी भी विशिष्ट इनपुट को देखने से पहले कार्य को चरण आरेख के रूप में बनाने का प्रयास करें। क्या आप प्रमुख चरणों और उनकी निर्भरताओं को लेबल कर सकते हैं?

• हाँ, चरण स्पष्ट हैं (इकट्ठा करें → विश्लेषण → संश्लेषण करें; या डिज़ाइन → कार्यान्वयन → परीक्षण; या अनुसंधान → मसौदा → समीक्षा) → संरचना स्पष्ट है; planning का उपयोग करें।
• नहीं, कार्य चरणों में फिट नहीं बैठता है, यह जांच, पुनरावृत्ति, या ओपन-एंडेड अन्वेषण है → संरचना स्पष्ट नहीं है; ReAct का उपयोग करें।

जहाँ टीमें गलतियाँ करती हैं। ऐसी संरचना का आविष्कार करना जहाँ कोई मौजूद नहीं है। इंजीनियरों को लगता है कि एक योजना हमेशा संभव होनी चाहिए, इसलिए वे एक को मजबूर करते हैं। planner एक योजना तैयार करता है; निष्पादन तुरंत अलग हो जाता है क्योंकि task में वास्तव में वे चरण नहीं थे। तब टीम या तो (ए) विचलन को planner में एक बग के रूप में मानती है ("planner ने एक खराब योजना बनाई"; planner को फिर से लिखें; दोहराएँ) या (बी) योजना को धीरे-धीरे छोटा कर देती है जब तक कि यह तुच्छ न हो जाए और कुछ भी योगदान न दे। ईमानदार उत्तर था "इस task को किसी योजना की आवश्यकता नहीं थी; ReAct का उपयोग करें।"

विपरीत त्रुटि: वास्तव में वहां मौजूद संरचना गायब है। इंजीनियर उन कार्यों के लिए शुद्ध ReAct का उपयोग करते हैं जिनमें वास्तव में चरण होते हैं। agent भटकता है, हल किए गए कार्य को दोबारा देखता है, या समग्र प्रगति का ट्रैक खो देता है। prompt में "इन चरणों को करना याद रखें" जोड़ना एक समाधान है; architectural फिक्स को ReAct loop के ऊपर planning जोड़ना है।

मार्ग। यदि संरचना स्पष्ट है → Planning + ReAct execution। planning agent चरण संरचना का निर्माण करता है; पहचाने गए अज्ञात-चरण अनुकूलन Q1 को संभालने के लिए प्रत्येक चरण के अंदर ReAct runs।

यदि संरचना स्पष्ट नहीं है → Single agent + ReAct + tools। agent वर्तमान स्थिति के बारे में कारण बताता है, अगली कार्रवाई करता है, परिणाम देखता है, और दोहराता है: agent जो स्वयं बनाए रखता है उससे परे संरचना का कोई ओवरले नहीं है।

A heuristic worth internalizing. Planning helps when the shape of the work is predictable but the content isn't. ReAct alone is right when even the shape depends on what you discover. आकार-बनाम-सामग्री का अंतर इन्हें अलग बताने का सबसे साफ तरीका है।

🔍 Q2 बनाम Q3 भ्रम, उदाहरण सहित असंबद्धता

Q2 ("is the workflow fixed and stable?") and Q3 ("is the task structure articulable?") trip even experienced teams. दोनों पूर्वानुमेयता के बारे में पूछते हैं; अंतर यह है कि पूर्वानुमेयता किस प्रकार की है:

प्रश्न	यह क्या पूछता है	"हाँ" का क्या मतलब है	क्या "हाँ" मार्ग
Q2	Are the steps themselves fixed across runs?	The same Python function-call sequence produces the right answer every time. No LLM-driven decisions about what to do next.	Sequential workflow
Q3	क्या प्रमुख चरणों को पहले से ही स्पष्ट किया जा सकता है, भले ही चरण-स्तर का कार्य भिन्न-भिन्न हो?	आप किसी विशिष्ट इनपुट को देखने से पहले व्हाइटबोर्ड पर चरण संरचना का वर्णन कर सकते हैं। LLM still decides what to do within each stage.	Planning + ReAct execution

वह मिश्रण जो काटता है: इंजीनियर task में संरचना देखते हैं ("यहां स्पष्ट रूप से चरण हैं: अनुसंधान, विश्लेषण, लिखना") और Q2 का उत्तर हां में देते हैं। लेकिन "संरचना मौजूद है" Q3 का प्रश्न है, Q2 का नहीं। Q2 पूछता है कि क्या आप रनटाइम पर सटीक चरण अनुक्रम की भविष्यवाणी कर सकते हैं_; यदि agent को अभी भी प्रत्येक चरण के भीतर निर्णय लेने की आवश्यकता है (कौन से स्रोत, कौन सा विश्लेषण करता है, कौन सा फ्रेमिंग), तो Q2 का उत्तर नहीं है और आपको Q3 पर होना चाहिए।

तीन सीमा उदाहरण जो Q2 बनाम Q3 को अलग करते हैं:

उदाहरण A, Invoice intake (Q2 = हाँ → Sequential workflow): निकालें → मान्य करें → स्टोर करें → सूचित करें। हर बार वही पांच चरण। LLM फ़ील्ड निकालता है और अधिसूचना लिखता है, लेकिन यह तय नहीं करता कि आगे क्या करना है। चरण अनुक्रम निश्चित है.

उदाहरण बी, Market research रिपोर्ट (Q2 = नहीं, Q3 = हाँ → Planning + ReAct): डेटा एकत्र करें → विश्लेषण → संश्लेषण → ड्राफ्ट → समीक्षा। चरण स्पष्ट हैं, लेकिन प्रत्येक चरण के भीतर agent निर्णय लेता है कि क्या करना है (किस स्रोत से परामर्श लेना है, किस competitors पर ध्यान केंद्रित करना है, कौन सा विश्लेषण चलाना है)। चरण निश्चित हैं; चरणों के भीतर चरण अनुकूली हैं.

उदाहरण C, Customer-support जांच (Q2 = NO, Q3 = NO → Single agent + ReAct): agent ग्राहक के मुद्दे की जांच करता है। कोई पूर्व निर्धारित चरण संरचना नहीं: agent जो पाता है उसके आधार पर, कार्य एक लुकअप या पांच लुकअप और एक नीति जांच और एक वृद्धि हो सकती है। न तो चरण निश्चित हैं और न ही चरण।

_नोट उदाहरण बी यह मामला है कि भाग 5 में निर्णय केवल आंशिक रूप से लागू होते हैं।

Q2 का ज्ञात-लेकिन-परिवर्तनीय उपकेस (नाम देने लायक)। कभी-कभी Q1 = हाँ (पथ ज्ञात है) लेकिन Q2 = NO (इनपुट में चर), उदाहरण के लिए, workflow में इनपुट प्रकार (त्वरित लुकअप बनाम बहु-स्रोत संश्लेषण बनाम दस्तावेज़ विश्लेषण) के आधार पर 3-4 स्थिर वेरिएंट होते हैं। _यह Sequential workflow या Planning + ReAct मामला नहीं है; यह स्पष्ट इनपुट-प्रकार रूटिंग के साथ एक branched workflow है। अवधारणा 5 इसे कवर करती है; anti-pattern गैलरी में निर्णय 4 का संस्करण (संकल्पना 16.5 की पंक्ति "स्थिर workflow में planning जोड़ने" के बारे में) व्युत्क्रम विफलता को कवर करती है।

निचली पंक्ति: Q3 पूछता है कि क्या task की उच्च-स्तरीय संरचना (चरण और निर्भरताएँ) निष्पादन से पहले स्पष्ट है। planning + ReAct execution के लिए कलात्मक संरचना मार्ग (योजना आकार प्रदान करती है; ReAct प्रत्येक चरण के भीतर अज्ञात सामग्री को संभालती है)। शुद्ध ReAct + tools के लिए गैर-अभिव्यक्त संरचना मार्ग (agent अनुकूल रूप से आकार और सामग्री दोनों की खोज करता है)। जाल ऐसी संरचना का आविष्कार कर रहे हैं जहां कोई भी मौजूद नहीं है (मजबूर योजनाएं जिनका निष्पादन अलग हो जाता है) और वह संरचना गायब है जो वास्तव में वहां है (चरणबद्ध कार्य पर शुद्ध ReAct, जिससे भटकना पड़ता है)।

अवधारणा 7: Q4: क्या checkable criteria के साथ गुणवत्ता गति से अधिक मायने रखती है?

Q4 दो एडिटिव लेयर प्रश्नों में से पहला है। मुख्य pattern (sequential workflow, ReAct, या planning + ReAct) पहले से ही Q1-Q3 द्वारा चुना गया है। Q4 पूछता है कि क्या शीर्ष पर reflection की परत लगानी है।

reflection क्या करता है। agent आउटपुट उत्पन्न करने के बाद, एक समालोचना पास स्पष्ट criteria के विरुद्ध इसका मूल्यांकन करता है। यदि समालोचक दोषों की पहचान करता है, तो agent परिष्कृत (या पुनर्जीवित) करता है। pattern का bet (अवधारणा 2 से): एक समालोचना पास उन त्रुटियों को पकड़ सकता है जो generator छूट गई हैं, और "अच्छे आउटपुट" के लिए criteria पर्याप्त स्पष्ट हैं कि आलोचना सार्थक है।

दो शर्तें जो दोनों को reflection के मूल्यवान होने के लिए मान्य होनी चाहिए।

1. गुणवत्ता गति से अधिक मायने रखती है। Reflection कम से कम एक अतिरिक्त LLM कॉल (आलोचना) और अक्सर दो (आलोचना + परिशोधन) जोड़ता है। इंटरैक्टिव उपयोग के मामलों के लिए जहां latency मायने रखता है (वास्तविक समय customer support, संवादी agents), यह cost अक्सर निषेधात्मक होता है। बैच उपयोग के मामलों के लिए जहां आउटपुट की समीक्षा मनुष्यों द्वारा की जाती है या डाउनस्ट्रीम सिस्टम (रिपोर्ट जनरेशन, कोड जनरेशन, दस्तावेज़ ड्राफ्टिंग) में भेज दी जाती है, latency आमतौर पर स्वीकार्य है। परीक्षण: क्या 2-5× धीमा response सार्थक रूप से उच्च-गुणवत्ता वाले आउटपुट के लिए स्वीकार्य होगा?
2. **मूल्यांकन criteria स्पष्ट और जांच योग्य हैं। ** अस्पष्ट criteria अस्पष्ट आलोचनाएँ उत्पन्न करते हैं। "सुनिश्चित करें कि यह अच्छा है" कोई मानदंड नहीं है। "SQL पार्स को सत्यापित करें, केवल सूचीबद्ध तालिकाओं को हिट करता है, और SELECT * का उपयोग नहीं करता है।" स्पष्ट criteria के बिना, समालोचना पास वाचाल बकवास बन जाती है जो आउटपुट में सुधार नहीं करती है, और अक्सर झूठा विश्वास पैदा करती है कि "AI ने इसकी जाँच की" जबकि वास्तव में कुछ भी जाँच नहीं की गई थी।

दोनों स्थितियाँ समान रूप से मायने रखती हैं। latency-संवेदनशील task में reflection जोड़ने से समय बर्बाद होता है। अस्पष्ट criteria के साथ task में reflection जोड़ने से थिएटर का निर्माण होता है। दोनों विफलताएं आम हैं; दोनों Q4 को छोड़ने और reflection जोड़ने से आते हैं क्योंकि यह कठोर लगता है।

परीक्षण। दो प्रश्न पूछें:

• यदि इस response के उत्पादन में 3-5× को अधिक समय लगता है, तो क्या मेरे उपयोगकर्ताओं (या डाउनस्ट्रीम उपभोक्ताओं) को इससे कोई आपत्ति नहीं होगी, बशर्ते गुणवत्ता में सार्थक सुधार हो? यदि नहीं, तो latency budget द्वारा reflection को उचित नहीं ठहराया जा सकता है।
• क्या मैं 5-10 विशिष्ट बुलेट बिंदुओं में लिख सकता हूं, वास्तव में इस task के लिए "अच्छे आउटपुट" का क्या मतलब है, जैसे कि एक अलग LLM उन बुलेट्स को पढ़ सकता है और उनके खिलाफ आउटपुट की जांच कर सकता है? यदि नहीं, तो reflection मानदंड स्पष्टता द्वारा उचित नहीं है।

यदि दोनों उत्तर हां हैं, तो reflection मूल्य जोड़ता है। यदि इनमें से कोई भी नहीं है, तो reflection को छोड़ें।

जहां टीमें यह गलती करती हैं।

reflection जोड़ा जा रहा है क्योंकि आलोचक कठोर लगते हैं। "उत्पन्न करें, फिर आलोचना करें" अच्छी इंजीनियरिंग की तरह लगता है। यह अक्सर होता है; कभी-कभी यह सिर्फ दिखावे के लिए होता है। परीक्षण यह है कि क्या आलोचना वास्तव में आउटपुट को मापने योग्य तरीकों से बदलती है। यदि आपने reflection जोड़ा है और पोस्ट-reflection आउटपुट उस समय के पूर्व-reflection 90% के समान है, तो reflection काम नहीं कर रहा है; यह cost जोड़ रहा है।

generator और critic दोनों के लिए समान model और prompt शैली का उपयोग करना। critic में generator के समान ही प्रशिक्षण डेटा, समान पूर्वाग्रह, समान ब्लाइंड स्पॉट हैं। यह रबर-स्टैम्प की तरह होता है। प्रभावी reflection pattern या तो (ए) critic के लिए एक अलग model का उपयोग करते हैं, (बी) critic को मौलिक रूप से अलग परिप्रेक्ष्य के साथ फ्रेम करते हैं ("आप एक सख्त reviewer हैं जो समस्याओं की तलाश में हैं" बनाम generator की सहायक फ़्रेमिंग), या (सी) critic को स्पष्ट जांच के साथ प्रदान करें tools (SQL चलाएं, पार्स करें) JSON, schema के विरुद्ध मान्य करें)।

चेक करने योग्य आउटपुट के बिना कार्यों पर विचार करना। Reflection उन कार्यों के लिए काम करता है जहां गलतता को परिभाषित किया गया है: SQL त्रुटियों के साथ, कोड जो compile नहीं करता है, सारांश जो स्रोत में महत्वपूर्ण तथ्यों को याद करते हैं। यह उन कार्यों के लिए खराब काम करता है जहां "अच्छा" व्यक्तिपरक है: marketing copy, रचनात्मक लेखन, संवादी responses। व्यक्तिपरक डोमेन को LLM reflection की तुलना में मानव-में-loop समीक्षा से अधिक लाभ होता है।

मार्ग। यदि दोनों स्थितियाँ लागू होती हैं, तो Q1-Q3 से कोर pattern के शीर्ष पर एक परत के रूप में reflection जोड़ें। यह मूल pattern को प्रतिस्थापित नहीं करता है; यह इसे लपेटता है। एक sequential workflow को reflection runs के साथ workflow, फिर अंतिम आउटपुट की समीक्षा करता है। एक ReAct agent reflection के साथ अपना loop पूरा करता है, फिर अंतिम आउटपुट की समीक्षा करता है। Reflection पोस्ट-हॉक गुणवत्ता नियंत्रण है, मुख्य pattern का प्रतिस्थापन नहीं।

यदि कोई भी शर्त विफल हो जाती है, तो reflection को छोड़ दें। यदि आपको वास्तव में गुणवत्ता आश्वासन की आवश्यकता है लेकिन criteria जांच योग्य नहीं है, तो सही समाधान मानव समीक्षा है, न कि LLM reflection।

निचली पंक्ति: Q4 पूछता है कि क्या गुणवत्ता गति से अधिक मायने रखती है और क्या मूल्यांकन criteria स्पष्ट और जांच योग्य है। मूल्य जोड़ने के लिए reflection के लिए दोनों शर्तें लागू होनी चाहिए। latency-संवेदनशील कार्यों पर Reflection समय बर्बाद करता है; अस्पष्ट-criteria कार्यों पर reflection थिएटर का निर्माण करता है। दो सबसे आम विफलता मोड reflection जोड़ रहे हैं क्योंकि यह कठोर लगता है (यह जांचे बिना कि क्या यह आउटपुट बदलता है) और generator और critic के लिए समान model और prompt शैली का उपयोग करना (जो rubber-stamping उत्पन्न करता है)। जब reflection को उचित ठहराया जाता है, तो यह मूल pattern के शीर्ष पर परत बना देता है, यह इसे प्रतिस्थापित नहीं करता है।

संकल्पना 8: Q5: क्या कोई विशेषज्ञता है, context, या स्केल bottleneck?

Q5 दूसरा एडिटिव लेयर प्रश्न है, और सबसे अधिक परिणामी क्योंकि मल्टी-agent systems build का सबसे महंगा pattern है और अगर वे गलत साबित होते हैं तो उन्हें हटाना सबसे महंगा है।

क्या मल्टी-agent systems सट्टेबाजी कर रहे हैं। तीन अलग-अलग दावे, जिन्हें अक्सर मिला दिया जाता है:

1. विशेषज्ञता का दावा: task को विशिष्ट विशेषज्ञता की आवश्यकता होती है जिसे single agent एक prompt में अच्छी तरह से नहीं रख सकता है। एक कोडर, एक सुरक्षा reviewer, और एक दस्तावेज़ writer प्रत्येक में अलग-अलग इष्टतम prompts, अलग-अलग इष्टतम tools और अलग-अलग इष्टतम मूल्यांकन criteria होता है। तीनों को एक agent में फिट करने का प्रयास तीनों में सामान्यता पैदा करता है।
2. Context दावा: task को single agent की तुलना में अधिक context की आवश्यकता होती है, जिसका प्रभावी ढंग से उपयोग किया जा सकता है। भले ही context window तकनीकी रूप से काफी बड़ा हो, जैसे-जैसे context बढ़ता है, पुनर्प्राप्ति और तर्क में गिरावट आती है। कार्य को agents में विभाजित करना, प्रत्येक का अपना केंद्रित context, तर्क गुणवत्ता को बनाए रखता है।
3. पैमाने का दावा: task में वह कार्य शामिल है जो समानांतर में चल सकता है, और multi-agent system इसे एकल अनुक्रमिक agent की तुलना में तेज़ी से निष्पादित कर सकता है। 10 competitors पर शोध करना एक समय में उन पर एक साथ शोध करने से बेहतर है।

प्रत्येक दावे का वास्तविक task के विरुद्ध अलग से परीक्षण किया जाना चाहिए।

विशेषज्ञता के दावे पर अक्सर बिना सबूत के ही विश्वास कर लिया जाता है। इंजीनियर task को "build एक फीचर" की तरह देखते हैं और इसे भूमिकाओं (वास्तुकार, कोडर, परीक्षक, reviewer) में विघटित करते हैं क्योंकि यह सहज लगता है। अंतर्ज्ञान उतनी ही बार गलत होता है जितनी बार यह सही होता है। वास्तविक सुविधा-निर्माण अक्सर एक agent में अच्छे tool पहुंच के साथ बेहतर होता है, आर्किटेक्ट-कोडर-परीक्षक पृथक्करण handoff costs का परिचय देता है जो विशेषज्ञता लाभ से अधिक है। दावे का परीक्षण करें: यदि कोई डोमेन specialist केवल इस स्लाइस पर केंद्रित हो तो क्या कार्य में सार्थक सुधार होगा?

context का दावा अक्सर बड़े पैमाने पर सत्य होता है। एक single agent दस ज्ञान आधारों में दस पुनर्प्राप्तियाँ करता है context जमा करता है जो तर्क को ख़राब करता है। दस पुनर्प्राप्ति-और-सारांश agents में विभाजित करना, जिनमें से प्रत्येक एक केंद्रित संक्षिप्त विवरण तैयार करता है, फिर संक्षेपों की रचना करता है, अक्सर बेहतर प्रदर्शन करता है, क्योंकि प्रत्येक पुनर्प्राप्ति agent का context छोटा और केंद्रित रहता है। लेकिन यह एक वास्तविक architectural निर्णय है, डिफ़ॉल्ट नहीं।

पैमाने का दावा परीक्षण करना सबसे आसान है: क्या parallel execution मापने योग्य throughput सुधार प्रदान करता है, और क्या task वास्तव में सफाई से समानांतर होता है? यदि कार्य में सख्त अनुक्रमिक निर्भरताएं हैं (प्रत्येक चरण को पिछले चरण के आउटपुट की आवश्यकता है), समानांतर multi-agent निष्पादन गति खरीदे बिना समन्वय cost जोड़ता है।

परीक्षण। तीन उप-प्रश्न:

1. क्या मैं उस विशिष्ट विशेषज्ञता का नाम बता सकता हूँ जो specialist को उचित ठहराती है? "यह साफ़-सुथरा होगा" इसमें कोई गिनती नहीं है। "reviewer को OWASP मानकों को लागू करने की आवश्यकता है जिसे कोडर को सीखना नहीं चाहिए"। यदि आप विशेषज्ञता का नाम नहीं बता सकते, तो विशेषज्ञता का दावा संभवतः सौंदर्यपरक है।
2. क्या task का context single agent के प्रभावी उपयोग से अधिक हो सकता है? आम तौर पर हाँ यदि task को कई अलग-अलग ज्ञान आधारों, कई स्रोतों में लंबे समय तक चलने वाली जांच, या प्रति चरण विशेष tool सेट की आवश्यकता होती है। आम तौर पर नहीं, यदि context एक अच्छी तरह से प्रबंधित prompt में फिट बैठता है।
3. क्या कार्य वास्तव में मापने योग्य throughput सुधार के साथ समानांतर है? यदि कार्य अनुक्रमिक है (प्रत्येक चरण पिछले पर निर्भर करता है), parallel execution मदद नहीं करता है। यदि कार्य वास्तव में स्वतंत्र है (शोध 10 competitors, 10 उम्मीदवारों का मूल्यांकन करें, 10 दस्तावेज़ों का सारांश प्रस्तुत करें), समानांतरीकरण वास्तविक मूल्य प्रदान करता है।

यदि कम से कम एक उप-प्रश्न पर जोरदार हाँ मिलती है, तो multi-agent उचित है। यदि तीनों को "शायद" मिलता है या "संगठनात्मक कारणों से अलग-अलग agents होना अच्छा होगा," एकल-agent pattern के साथ बने रहें। coordination overhead वास्तविक और पर्याप्त है।

जहां टीमें यह गलती करती हैं।

संगठनात्मक कारणों से बहु-agent systems का निर्माण। "हमारे पास इस पर काम करने वाली तीन टीमें हैं; चलो तीन agents हैं।" यह agent architecture को संगठन चार्ट को प्रतिबिंबित कर रहा है। यह लगभग हमेशा गलत होता है। मल्टी-agent systems को task संपत्तियों के आसपास डिज़ाइन किया जाना चाहिए, न कि टीम की सीमाओं के आसपास। (आप एक agent पर तीन टीमें सहयोग कर सकते हैं; संगठन संरचना और agent संरचना का मेल होना जरूरी नहीं है।)

समन्वय को कम आंकना cost. agents के बीच प्रत्येक handoff एक क्रमबद्धता बिंदु (एक agent का आउटपुट दूसरे का इनपुट बन जाता है), एक संभावित विफलता बिंदु (handoff प्रारूप मेल नहीं खा सकता है), और एक debugging कठिनाई (जब कुछ गलत होता है, जो agent के कारण होता है?) प्रस्तुत करता है। **मल्टी-agent systems की तुलना में डीबग करना मोटे तौर पर अधिक महंगा है: cost उचित है या नहीं, इसके बारे में अपने तर्क में इसे ट्रैक करें।

परिष्कार प्रदर्शित करने के लिए multi-agent का निर्माण।_ यह वार्ता-और-प्रदर्शन विफलता मोड है। मल्टी-agent systems architecture आरेखों में प्रभावशाली दिखते हैं; वे "वास्तविक AI" दिखाते हैं। यदि वास्तविक task उन्हें उचित नहीं ठहराता है, तो आपने प्रभावशाली overhead बनाया है।

मार्ग। यदि विशेषज्ञता, context, या स्केल एक वास्तविक bottleneck → Multi-Agent Specialist System बनाता है। सिस्टम में coordinator/routing agent प्लस specialists, या specialists स्पष्ट handoff अनुबंधों के साथ, या specialists साझा स्थिति के माध्यम से संचार हो सकता है। मुख्य pattern (sequential workflow, ReAct, planning + ReAct) अभी भी प्रत्येक specialist के डोमेन में लागू होता है, multi-agent pattern की एक रचना है, उनके लिए प्रतिस्थापन नहीं।

यदि कोई वास्तविक bottleneck मौजूद नहीं है → एकल-agent pattern रखें। यदि वे शर्तें लागू होती हैं तो reflection (Q4) जोड़ें, लेकिन सौंदर्य संबंधी कारणों से multi-agent न जोड़ें।

Q5 के लिए मात्रात्मक triggers, ठोस मेट्रिक्स जो multi-agent निर्णय को सक्रिय करते हैं। "विशेषज्ञता, context, या स्केल bottleneck" डिफ़ॉल्ट रूप से निर्णय-आधारित है, और निर्णय वह है जहां pattern-overshoot आता है। जहां संभव हो, निर्णय को माप से बदलें। निम्नलिखित triggers सामान्य नियम हैं जो Q5 को व्यक्तिपरक से स्थानांतरित करते हैं ("ऐसा लगता है") specialists") से बचाव योग्य ("हमने एक्स मापा और एक्स सीमा से अधिक है")।

Bottleneck दावा	मात्रात्मक trigger जो अपग्रेड को उचित ठहराता है	मीट्रिक क्या मापता है
विशेषज्ञता	एकल-agent traces विशिष्ट ज्ञान डोमेन में केंद्रित tool-रूटिंग त्रुटियों को दिखाता है (एक मोटे कामकाजी सीमा के रूप में, प्रभावित श्रेणी में runs के एक तिहाई के क्रम पर, आपकी अपनी आधार रेखा पर कैलिब्रेट किया गया)। _उदाहरण: एक एकीकृत billing+तकनीकी agent तकनीकी queries के एक बड़े हिस्से पर गलत tool चुनता है क्योंकि billing शब्दावली इसके context पर हावी है।	Per-trace tool-शुद्धता, query श्रेणी द्वारा विभाजित: आपके eval suite से Phoenix evaluator
विशेषज्ञता (गुणात्मक फ़ॉलबैक)	मापा नहीं जा सकता? अपग्रेड से पहले specialist भूमिकाओं, प्रत्येक भूमिका की ज़िम्मेदारियों, tools, और acceptance criteria का स्पष्ट अंग्रेजी में लिखित विवरण आवश्यक है। यदि विशिष्टता अस्पष्ट है या जिम्मेदारी में भूमिकाएं ओवरलैप होती हैं >40%, तो विशेषज्ञता का दावा सौंदर्यपरक है, न कि architectural.	दस्तावेज़ समीक्षा, मीट्रिक नहीं
Context overflow	जैसे-जैसे context बढ़ता है, holdout set पर सटीकता भौतिक रूप से कम हो जाती है (अपने वक्र को मापें; एक मोटे झंडे के रूप में, 15K → 45K token स्वीप पर लगभग 10 बिंदुओं की एक बूंद जांच के लायक है)। _उदाहरण: research agent को लोड करने वाला 25 स्रोत दस्तावेज़ 15K context पर 78%, 30K पर 71%, 45K पर 62% की सटीकता दिखाता है।	golden dataset पर Context-बनाम-सटीकता वक्र
स्केल (parallelizable)	कार्य में प्रति रन >5 स्वतंत्र sub-tasks है और एकल-agent निष्पादन latency user-facing latency budget से >2× अधिक है। उदाहरण: अनुसंधान 10 competitors → एकल-agent क्रमिक रूप से 8 मिनट लेता है, बजट 3 मिनट है → समानांतर multi-agent निष्पादन एकमात्र रास्ता है जो फिट बैठता है।	शुरू से अंत तक latency + sub-task स्वतंत्रता विश्लेषण
स्केल (throughput)	रन वॉल्यूम एकल-agent डिज़ाइन के 10× rate-limit ceiling से अधिक है और कोई भी per-tenant concurrency कैप्स निष्पक्षता को संरक्षित नहीं कर सकते हैं। उदाहरण: 500 RPM OpenAI कोटा के विरुद्ध 5K runs/दिन प्रति tenant को कई agent पहचानों या specialist-शैली अपघटन में fan-out की आवश्यकता होती है।	Production load × API rate limits: operational envelope के प्रवाह-नियंत्रण dashboard में दृश्यमान

साक्ष्य का पदानुक्रम। multi-agent के लिए सबसे मजबूत से सबसे कमजोर औचित्य:

1. Production trace डेटा bottleneck दिखा रहा है (सर्वोत्तम: आपके पास सबूत है कि एकल-agent system वास्तव में इस तरह विफल रहता है)
2. होल्डआउट-सेट माप bottleneck दिखा रहा है (मजबूत: एक नियंत्रित प्रयोग)
3. डोमेन विश्लेषण लिखित specialist-भूमिका विशिष्टताओं के साथ (स्वीकार्य: आपने कम से कम परिभाषित किया है कि आप क्या बना रहे हैं)
4. "specialists जैसा महसूस होता है" (अपर्याप्त: यह वह जगह है जहां pattern-overshoot रहता है)

एक उपयोगी स्व-जांच। _"सबसे छोटा एकल-agent डिज़ाइन कौन सा है जिसे हम पहले ship कर सकते हैं, और कौन सी विशिष्ट विफलता हमें बाद में multi-agent के लिए मजबूर करेगी?" Multi-agent शायद ही कभी गलत होता है endpoint; यह लगभग हमेशा ग़लत आरंभिक बिंदु होता है।

निचली पंक्ति: Q5 पूछता है कि क्या विशेषज्ञता, context, या स्केल एक वास्तविक bottleneck बनाते हैं जो multi-agent architecture को उचित ठहराते हैं। तीनों दावों (विशेषज्ञता, context, स्केल) में से प्रत्येक का अलग-अलग परीक्षण किया जाना चाहिए, और जहां संभव हो मात्रात्मक triggers (उदाहरणात्मक सीमाएं, आपके सिस्टम में कैलिब्रेटेड: runs का लगभग एक तिहाई tool-रूटिंग त्रुटियों को दर्शाता है, उच्च context, latency पर लगभग 10 अंकों की सटीकता में गिरावट, जो बजट से अधिक हो जाती है) 2×). विशेषज्ञता पर अक्सर बिना सबूत के विश्वास किया जाता है; context अक्सर पैमाने पर वास्तविक रूप से सत्य होता है; स्केल का परीक्षण करना सबसे आसान है। सबसे बड़ी विफलता मोड task-संपत्ति कारणों के बजाय संगठनात्मक या सौंदर्य संबंधी कारणों से बहु-agent systems का निर्माण करना है; coordination overhead वास्तविक और पर्याप्त है, और तैनात multi-agent system को हटाना एक पुनर्लेखन है, रिफैक्टर नहीं। एकल प्रारंभ करें-agent; मापे गए triggers को अपग्रेड को बाध्य करने दें।

संकल्पना 8.5: OpenAI Agents SDK primitives, प्रत्येक pattern क्या उपयोग करता है

भाग 3 के पांच pattern पर चलने से पहले, यहां pattern selection से कार्यान्वयन तक का पुल है। पहले के पाठ्यक्रमों में OpenAI Agents SDK को एंकर framework के रूप में पढ़ाया जाता था। इस पाठ्यक्रम के pattern अमूर्त architectural आकार नहीं हैं जिन्हें आप स्क्रैच से पुनः लागू करते हैं; वे वे आकृतियाँ हैं जिन्हें आप SDK primitives का उपयोग करके बनाते हैं, जिनसे आप पहले ही मिल चुके हैं। यह अवधारणा प्रत्येक pattern को विशिष्ट SDK primitives पर मैप करती है जो इसे build करती है।

पांच primitives जो pattern selection के लिए मायने रखते हैं।

Primitive	यह क्या है	कौन से pattern इसका उपयोग करते हैं
Agent	कोर class, निर्देशों के साथ एक LLM-driven इकाई, tools, और वैकल्पिक structured output schema। प्रत्येक pattern की परमाणु इकाई।	सभी पांच pattern
Runner.run(agent, input)	Runs एक agent loop जब तक यह अंतिम आउटपुट उत्पन्न नहीं करता। आपके लिए SDK runs loop: कोई हाथ से घुमाई जाने वाली reason-act-observe साइकिल नहीं।	Single agent + ReAct (सबसे प्रमुख), Planning + ReAct, Multi-agent (प्रति specialist)
@function_tool	Decorator जो Python function को tool में बदल देता है जिसे agent कॉल कर सकता है। प्रकार के हस्ताक्षर और दस्तावेज़ स्वचालित रूप से tool के schema बन जाते हैं।	Single agent + ReAct, Planning + ReAct, Multi-agent (प्रति specialist), Sequential workflow (जब LLM-चरण को tools की आवश्यकता होती है)
handoff(target_agent)	multi-agent ट्रांज़िशन के लिए पहला-class SDK primitive: एक agent वार्तालाप context संरक्षित रखते हुए स्पष्ट रूप से नियंत्रण दूसरे को सौंप देता है। _coordinator को हाथ से घुमाने की तुलना में अधिक स्वच्छ	Multi-agent (प्राथमिक उपयोग); Planning + ReAct (planner-से-executor)
output_guardrail / input_guardrail	SDK primitives सत्यापन/आलोचना चलाने के लिए agent के इनपुट या आउटपुट को पास करता है। reflection के लिए मूल SDK pattern।	Reflection (प्राथमिक उपयोग); किसी भी pattern की आवश्यकता है input validation

नाम देने योग्य एक और primitive: Agent.as_tool()। यह एक Agent को कॉल करने योग्य tool में परिवर्तित करता है जिसे कोई अन्य Agent लागू कर सकता है। यह पदानुक्रमित multi-agent संरचना के लिए SDK का तंत्र है (एक coordinator agent specialist agents को tools के रूप में उपयोग करता है, उन्हें किसी अन्य function tool की तरह बुलाता है)। Agent.as_tool() के साथ मल्टी-agent systems, handoff() के साथ मल्टी-agent systems की तुलना में अधिक सरल हैं क्योंकि coordinator नियंत्रण में रहता है; handoff() उन स्थितियों के लिए है जहां आप वास्तव में चाहते हैं कि specialist बातचीत पर कब्ज़ा कर ले।

pattern → primitive मैपिंग एक नज़र में।

Sequential workflow:
    Agent(output_type=...) at the LLM-steps; plain Python everywhere else
    Runner.run() called once per LLM-step: no agentic loop (the agent has no tools)

Single agent + ReAct + tools:
    Agent(instructions=..., tools=[@function_tool, @function_tool, ...])
    Runner.run(agent, input): the SDK runs the reason-act-observe loop

Planning + ReAct execution:
    planner = Agent(output_type=PlanSchema)
    plan = await Runner.run(planner, task)
    for stage in plan.stages:
        result = await Runner.run(stage.agent, stage.input)

Single agent + reflection:
    Agent(..., output_guardrails=[critic_guardrail])
    OR: Agent(..., tools=[Agent.as_tool(critic_agent)])

Multi-agent specialist system:
    coordinator = Agent(handoffs=[researcher, writer, reviewer])
    OR: coordinator = Agent(tools=[researcher.as_tool(), writer.as_tool(), ...])

निम्नलिखित भाग 3 कोड ब्लॉक इनमें से प्रत्येक को पूर्ण SDK विवरण में दिखाते हैं।_

यह मैपिंग pattern selection के लिए क्यों मायने रखती है। SDK primitives केवल कार्यान्वयन सुविधाएं नहीं हैं, वे architectural निर्णयों को एन्कोड करते हैं। handoff() बनाम as_tool() चुनना अपने आप में एक pattern-रचना निर्णय है। handoff() का अर्थ है "specialist बातचीत को अपने हाथ में ले लेता है"; as_tool() का अर्थ है "coordinator प्रभारी रहता है और specialist को function के रूप में उपयोग करता है।" पूर्व उपयुक्त है जब specialist को उपयोगकर्ता के साथ सीधे बातचीत करने की आवश्यकता होती है; उत्तरार्द्ध उपयुक्त है जब coordinator specialist आउटपुट की रचना कर रहा है। यह जानना कि किस तक पहुंचना है, उसी pattern-चयन अनुशासन का डाउनस्ट्रीम है जो यह पाठ्यक्रम सिखाता है।

कार्य किए गए उदाहरण से कनेक्शन। customer-support Worker (Maya का Tier-1 Support agent) Agent + @function_tool (लुकअप, refund, और एस्केलेशन के लिए) + Runner.run() (FastAPI हैंडलर में) का उपयोग करता है। यह एक सिंगल agent + ReAct + tools pattern है, बिल्कुल वही कॉन्सेप्ट 10 SDK विवरण में चलेगा। Maya का कार्यान्वयन इस पाठ्यक्रम के पाँच pattern में से एक है; अन्य चार वे विविधताएँ हैं जिन तक आप तब पहुँचते हैं जब task गुण बदलते हैं।

संकल्पना की निचली पंक्ति 8.5: SDK primitives सभी पांच pattern के निर्माण खंड हैं। Agent परमाणु इकाई है; Runner.run() runs loop; @function_tool Python functions को tools के रूप में उजागर करता है; handoff() और as_tool() agents को बहु-agent systems में बनाते हैं; output_guardrail reflection लागू करता है। pattern → primitive मैपिंग इस पाठ्यक्रम के architectural विकल्पों को ठोस बनाता है: pattern selection अमूर्त नहीं है; यह एक विकल्प है कि कौन सी SDK primitives रचना की जाए और कैसे।

अवधारणा 8.6: Operational envelope प्रति pattern पर विचार (ठोस उदाहरण के रूप में Inngest के साथ)

📖 स्टैंडअलोन-रीडर नोट. यह अवधारणा pattern चयन के परिचालन परिणामों के बारे में है, न कि Inngest सिखाने के बारे में। architectural argument किसी भी टिकाऊ-निष्पादन प्लेटफ़ॉर्म (Temporal, Restate, Dapr Agents, AWS Step Functions) को सामान्यीकृत करता है; Inngest इसका ठोस उदाहरण है क्योंकि ऑपरेशनल-लिफाफा पाठ्यक्रम यही सिखाता है। यदि आपके पास एक अलग प्लेटफ़ॉर्म है, या आप अभी भी डिज़ाइन चरण में हैं और परिचालन प्लेटफ़ॉर्म अनिर्णीत है, तो pattern के लिए पढ़ें-architecture argument: pattern जितना अधिक विस्तृत होगा, उतना ही यह operational envelope होने पर निर्भर करता है। Inngest वाले के लिए अपने प्लेटफ़ॉर्म के primitives को प्रतिस्थापित करें।

संकल्पना 8.5 ने pattern को इंजन primitives (OpenAI Agents SDK) में मैप किया। अवधारणा 8.6 pattern को ऑपरेशनल लिफाफे primitives में मैप करती है: runtime मशीनरी जो agent loop को विफलताओं से बचाती है, कई समवर्ती उपयोगकर्ताओं के लिए स्केल करती है, और उस दुनिया के साथ एकीकृत करती है जो उस पर events को फायर करती है। **SDK runs agent loop; लिफाफा agent loop production-ग्रेड बनाता है। ** प्रत्येक pattern अलग-अलग लिफाफे primitives का उपयोग करता है, और pattern जितना अधिक विस्तृत होता है, उतना ही यह लिफाफे पर निर्भर करता है।

Agent Factory ट्रैक में, operational envelope Inngest है। नीचे primitives Inngest हैं; अंतर्निहित pattern-architecture argument सामान्य है।

ऑपरेशनल-लिफाफा primitives जो pattern selection के लिए मायने रखता है।

Primitive	यह क्या है	कौन से pattern इसका सबसे अधिक उपयोग करते हैं
@inngest_client.create_function	Decorator जो टिकाऊ-निष्पादन runtime के साथ function को पंजीकृत करता है। परिचालन-प्रबंधित कार्य की इकाई।	सभी पांच pattern
TriggerEvent, TriggerCron	Trigger सतह, events दुनिया में आग, कार्यक्रम जो function को जगाते हैं। agent जब आप इसे कॉल करते हैं तो यह नहीं चलता है; यह runs है जब दुनिया trigger को फायर करती है।	सभी पाँच pattern; cron incident response और बैच workflows के लिए सबसे अधिक प्रासंगिक है
ctx.step.run(name, fn, ...)	प्रत्येक कॉल एक durable checkpoint है, पूर्ण चरण return memoized आउटपुट retry पर; स्वतंत्र रूप से विफल चरण retry। मैकेनिक production विश्वसनीयता से नीचे है।	Sequential workflow (सबसे सीधा map), Planning + ReAct (प्रति चरण एक कदम), Reflection (अलग generator/critic चरण)
ctx.step.wait_for_event(...)	function टिकाऊ रूप से निलंबित रहता है, शून्य गणना खपत, जब तक कि एक मिलान event नहीं आता या टाइमआउट सक्रिय नहीं हो जाता। HITL gates के पीछे runtime primitive.	किसी भी pattern की आवश्यकता है human approval; multi-agent (specialists के बीच); reflection (जब human judgment critic है)
concurrency, throttle, priority	प्रति-function प्रवाह-नियंत्रण नीतियां। Concurrency कैप्स सक्रिय runs; throttle कैप प्रारंभ/सेकंड; priority queue को आदेश देता है; प्रति-कुंजी concurrency multi-tenant निष्पक्षता प्रदान करती है।	Multi-agent (सबसे महत्वपूर्ण, per-specialist सीमाएं rate-limit थकावट को रोकती हैं); कोई भी उच्च-मात्रा एकल-agent pattern
Fan-out triggers	एक event एन को functions की सदस्यता लेने के लिए जगाता है; या माता-पिता में से किसी एक ने किसी बच्चे को events से निकाल दिया। runtime primitive समानांतर specialist निष्पादन के पीछे।	Multi-agent (parallel topology); Planning + ReAct (जब चरण समानांतर में चलते हैं)
Replay + dead-letter	विफल runs जारी रहता है; ship एक समाधान, replay पर क्लिक करें, function नए कोड के साथ विफल चरण से फिर से शुरू होता है। विफलता से पहले के कदम memoized रहें।	सभी pattern, लेकिन pattern जितना अधिक विस्तृत होगा, replay उतना ही अधिक मायने रखता है क्योंकि जब कोई लंबी दौड़ आंशिक रूप से विफल हो जाती है तो उतना ही अधिक दांव पर लगता है।

pattern → primitive मैपिंग एक नज़र में।

Sequential workflow:
    @inngest_client.create_function(trigger=TriggerEvent(...))
    async def workflow(ctx):
        a = await ctx.step.run("extract", extractor_agent.run, ...)
        b = await ctx.step.run("validate", validate, a)
        c = await ctx.step.run("store", db.insert, b)
        await ctx.step.run("notify", notifier_agent.run, ...)
    # Each step independently checkpointed; failure → memoized resume

Single agent + ReAct + tools:
    @inngest_client.create_function(
        trigger=TriggerEvent(event="customer/email.received"),
        concurrency=[Concurrency(limit=10, key="event.data.customer_id")],
    )
    async def support(ctx):
        result = await ctx.step.run("agent-loop", Runner.run, support_agent, ctx.event.data["query"])
        # If agent needs HITL escalation, use step.wait_for_event inside the agent's tool
        return result.final_output

Planning + ReAct execution:
    @inngest_client.create_function(trigger=TriggerEvent(event="research/started"))
    async def planning(ctx):
        plan = await ctx.step.run("plan", Runner.run, planner, ctx.event.data["task"])
        results = {}
        for stage in plan.stages:
            # Each stage = one step.run. Crash mid-stage → only that stage retries.
            results[stage.id] = await ctx.step.run(f"stage-{stage.id}", Runner.run, stage.agent, ...)
        return await ctx.step.run("synthesize", Runner.run, synthesizer, results)

Single agent + reflection:
    @inngest_client.create_function(trigger=TriggerEvent(...))
    async def reflective(ctx):
        output = await ctx.step.run("generate", Runner.run, generator, ctx.event.data["task"])
        critique = await ctx.step.run("critique", Runner.run, critic, output)
        if not critique.final_output.is_safe:
            output = await ctx.step.run("refine", Runner.run, generator, refine_prompt(output, critique))
        return output

Multi-agent specialist system:
    # Coordinator triggers fan-out of specialist events
    @inngest_client.create_function(trigger=TriggerEvent(event="research/landscape.requested"))
    async def coordinator(ctx):
        plan = await ctx.step.run("plan", Runner.run, planner, ctx.event.data["topic"])
        await ctx.step.run("fan-out", fan_out_specialist_events, plan.competitors)
        # Each specialist runs independently as its own function:

    @inngest_client.create_function(
        trigger=TriggerEvent(event="research/competitor.research"),
        concurrency=[Concurrency(limit=5, key="event.data.tenant_id")],  # per-tenant cap
    )
    async def competitor_research(ctx):
        return await ctx.step.run("research", Runner.run, researcher, ctx.event.data["target"])

भाग 3 साइडबार इनमें से प्रत्येक मैपिंग को प्रति pattern एक स्पष्ट परिचालन-लिफाफा अनुभाग के साथ दिखाते हैं।

यह मैपिंग pattern selection के लिए क्यों मायने रखती है। दो production विफलता मोड जो architecture-आरेख स्तर पर दिखाई नहीं देते हैं, लेकिन production में जोर से काटते हैं:

1. उड़ान के बीच में दुर्घटना। छह चरणों वाला planning + ReAct execution जो चरण 4 (बिना durable execution) पर दुर्घटनाग्रस्त हो जाता है, पहले तीन चरणों के लिए पुनः भुगतान करता है। ऑपरेशनल-लिफाफा पाठ्यक्रम इसकी मात्रा निर्धारित करता है: GPT-5-वर्ग मूल्य निर्धारण पर, एक बहु-चरण agent प्रवाह लगभग $0.10-$2.00 प्रति दुर्घटनाग्रस्त रन का पुनर्भुगतान कर सकता है। 1000 runs/दिन पर, जो अकेले दुर्घटनाओं में खोए गए कार्य में $30-$600/माह के क्रम पर है। **अनुक्रमिक workflows दुर्घटनाओं से सस्ते में बच जाते हैं क्योंकि retries छोटे होते हैं; multi-agent + reflection सिस्टम क्रैश होने से बच जाते हैं क्योंकि retries लंबे होते हैं। ** pattern जितना अधिक विस्तृत होगा, operational envelope के step.run मेमोइज़ेशन का डॉलर में मूल्य उतना ही अधिक होगा।
2. पैमाने पर समन्वय। पांच specialists, दस tenants, और 100 events/मिनट के विस्फोट के साथ एक multi-agent system, per-specialist concurrency कैप के बिना rate limits को समाप्त कर देगा। operational envelope यह एक पंक्ति बनाता है: concurrency=[Concurrency(limit=5, key="event.data.tenant_id")]। इस पाठ्यक्रम का decision tree pattern चुनता है; operational envelope का प्रवाह-नियंत्रण primitives चुने हुए pattern को पैमाने पर स्वस्थ रखता है।

Deployment composition. operational envelope (Inngest) और आपका cloud deployment साथ compose होते हैं; वे compete नहीं करते। cloud deployment course cloud topology सिखाता है: ACA + Neon + R2 + Cloudflare Sandbox + Phoenix. operational-envelope course वह layer सिखाता है जो SDK runner को उसी topology के अंदर wrap करती है. एक real production system दोनों का उपयोग करता है: ACA पर deployed Inngest functions, step.run() blocks के अंदर Runner.run() call करते हुए, Neon agent traces store करता है और sandbox tool code execute करता है। Part 3 के deployment-composition sidebars दोनों layers को स्पष्ट रूप से नाम देते हैं।

ईवल संरचना। Inngest की संरचित trace (प्रत्येक चरण का इनपुट, आउटपुट, retry गिनती, latency) Phoenix में उसी तरह प्रवाहित होती है जैसे SDK की agent trace, OpenTelemetry के माध्यम से होती है। eval suite के विफलता-पहचान pattern (trace-लंबाई विसंगतियाँ, योजना-निष्पादन विचलन, rubber-stamping) सभी Inngest-यंत्रित runs पर काम करते हैं; eval suite नहीं बदलता क्योंकि operational envelope जोड़ा गया है।

_संकल्पना की निचली पंक्ति 8.6: operational envelope (Inngest) सभी पांच pattern के लिए production सब्सट्रेट है। Triggers function को जगाएं; step.run इसे टिकाऊ बनाता है; step.wait_for_event HITL gates लागू करता है; concurrency, throttle, और priority इसे load के अंतर्गत आकार देते हैं; fan-out multi-agent specialists का समन्वय करता है; replay बग-फिक्स पुनर्प्राप्ति को संभालता है। pattern जितना अधिक विस्तृत होगा, लिफाफे का मूल्य उतना ही अधिक होगा: अनुक्रमिक workflows इसके बिना जीवित रहेगा; multi-agent + reflection सिस्टम को इसकी आवश्यकता है। लिफाफा आपके cloud deployment और आपके eval suite के साथ बनता है, विकल्प के रूप में नहीं, बल्कि production architecture की समानांतर परतों के रूप में।

तीन परतें, एक साथ। अवधारणाएं 8.5 और 8.6 एक साथ स्थापित करती हैं कि कोई भी production agentic pattern तीन परतों की एक संरचना है: operational envelope (Inngest), इंजन (OpenAI Agents SDK), और cloud deployment। दुनिया शीर्ष पर triggers फायर करती है (ग्राहक ईमेल, billing या Slack या CRM से webhooks, एक cron शेड्यूल, अन्य Workers से fan-out events, मानव अनुमोदन); वे triggers तीन परतों से होकर नीचे बहती हैं। नीचे दिया गया चित्र प्रत्येक परत में primitives को दर्शाता है और प्रत्येक क्या करता है। जब भी भाग 3 के परिचालन-लिफाफा साइडबार अमूर्त लगें तो इसे वापस देखें।

टेकअवे: तीन परतें stack। Inngest (लिफाफा) SDK (इंजन) को लपेटता है, और दोनों cloud deployment के अंदर चलते हैं। **यह पाठ्यक्रम pattern चुनता है; तीन परतें चुने हुए pattern को production वास्तविकता में बदल देती हैं। ** भाग 3 के सभी पांच pattern इन तीन परतों की रचनाएं हैं; pattern दर pattern भिन्न-भिन्न होता है, प्रत्येक परत में किस primitives का उपयोग किया जाता है। pattern जितना अधिक विस्तृत होगा (reflection के साथ multi-agent), परिचालन-आवरण परत उतनी ही महत्वपूर्ण हो जाएगी, क्योंकि समन्वय, स्थायित्व और HITL अब वैकल्पिक नहीं हैं।

भाग 2. के बाद, AI के साथ प्रयास करें आपके पास पांच प्रश्न हैं। pattern को गहराई से पढ़ने से पहले किसी वास्तविक चीज़ पर उनका उपयोग करें। अपना क्लाउड कोड या ओपनकोड सत्र खोलें और पेस्ट करें:

_"मैं agentic architectures को चुनना सीख रहा हूं। अपने वास्तविक काम से एक वास्तविक task चुनें, जिसके लिए मैं build को agent बना सकूं। मुझसे इसका वर्णन करने के लिए कहें, फिर मुझे पांच प्रश्नों के माध्यम से बताएं: Q1 (क्या solution path ज्ञात है?), Q2 (क्या workflow निश्चित और स्थिर है?), Q3 (क्या task structure व्यक्त करने योग्य है?), Q4 (गुणवत्ता क्या है?) गति से अधिक, checkable criteria के साथ?), Q5 (क्या कोई विशेषज्ञता है, context, या स्केल bottleneck?)।

आप क्या सीख रहे हैं। पांच प्रश्न केवल तभी रिफ्लेक्स बन जाते हैं जब आप उन्हें task पर चलाते हैं जिनकी आप वास्तव में परवाह करते हैं। एक बार ऐसा करना, ज़ोर से, कमजोर उत्तरों पर कुछ दबाव डालते हुए, अगले दस पेज पढ़ने से अधिक मूल्यवान है।

---

भाग 3: गहराई में पाँच pattern

भाग 2 प्रश्न स्तर पर decision tree पर चला गया। भाग 3 इसे pattern स्तर पर चलाता है। पांच टर्मिनल pattern में से प्रत्येक के लिए: pattern क्या है, इसका विशिष्ट कार्यान्वयन कैसा दिखता है, आपके deployment topology के लिए इसका क्या अर्थ है, और आपका eval suite क्या देखता है यह पता लगाने के लिए कि pattern कब गलत तरीके से लागू होता है।

deployment-और-eval रचना वह है जो यह पाठ्यक्रम शीर्ष पर जोड़ता है। agentic pattern पर कुछ पाठ्यक्रम इस परत को सिखाते हैं, क्योंकि इसे आधार के रूप में deployment और eval पाठ्यक्रमों की आवश्यकता होती है। यदि आपने उन पाठ्यक्रमों को नहीं किया है, तो जो आने वाला है उसके पूर्वावलोकन के रूप में साइडबार पढ़ें; यदि आपके पास है, तो रचना pattern selection को क्रियाशील बनाती है।

एक-एक करके pattern पर चलने से पहले, यहां मैट्रिक्स है जो पूरे भाग का सारांश देता है। प्रत्येक pattern cloud stack के एक अलग उपसमूह का उपयोग करता है; deployment cost अंतर वास्तविक और पर्याप्त हैं। इसे वापस देखें क्योंकि अवधारणाएँ 9-13 प्रत्येक pattern पर विस्तार से चलती हैं।

Matrix प्रत्येक pattern (columns) को उन cloud deployment components (rows) के against map करता है जिनकी उसे जरूरत होती है। Check का अर्थ needed; cross का अर्थ not needed; tilde का अर्थ conditional. Figures illustrative हैं।

cost अनुशासन pattern selection में एन्कोड किया गया है: शीर्ष पर reflection के साथ एक multi-agent system समान task वॉल्यूम के लिए sequential workflow का एक बड़ा गुणक cost कर सकता है (उदाहरणात्मक अनुपात, दसियों गुना के क्रम पर, मापा गया बेंचमार्क नहीं)। एक sequential workflow sandbox और ब्रिज-Worker स्तरों को पूरी तरह से छोड़ देता है, इसलिए यह बुनियादी ढांचे के एक बड़े हिस्से से बच जाता है; बिना किसी औचित्य के ReAct या multi-agent तक पहुंचने से उस क्षमता का भुगतान होता है जिसकी task को आवश्यकता नहीं है।

टेकअवे: sequential workflow को दो स्पष्ट "आवश्यक नहीं" मार्कर (sandbox और bridge Worker) मिलते हैं, जो agentic pattern की तुलना में सार्थक रूप से कम बुनियादी ढांचे का अनुवाद करता है। Multi-agent को सबसे अधिक विस्तार मार्कर (per-specialist traceिंग, per-specialist ब्रिज-Worker कॉन्फ़िगरेशन) मिलते हैं। मैट्रिक्स decision tree का cost अनुशासन है, जिसे दृश्यमान बनाया गया है।

संकल्पना 9: Sequential workflow, विशिष्ट आकार, deployment, eval signals

यह क्या है। चरणों का एक निश्चित pipeline जहां प्रत्येक चरण का आउटपुट अगले चरण को फीड करता है। पथ ज्ञात और स्थिर है (Q1=हाँ, Q2=हाँ)। LLM कॉल उन चरणों के लिए आरक्षित हैं जिनकी वास्तव में व्याख्या या पीढ़ी, निष्कर्षण, सारांशीकरण, वर्गीकरण की आवश्यकता है, न कि यह तय करने के लिए कि अगला कदम क्या आएगा।

OpenAI Agents SDK में विशिष्ट कार्यान्वयन:

from agents import Agent, Runner
from pydantic import BaseModel

class Invoice(BaseModel):
    vendor: str
    amount_cents: int
    due_date: str
    line_items: list[dict]

class NotificationMessage(BaseModel):
    subject: str
    body: str

# Two narrow agents: each does ONE LLM-step in the workflow.
# Notice: no tools, no agentic loop. Just structured-output extraction.
extractor = Agent(
    name="invoice_extractor",
    instructions="Extract structured invoice fields from the email body. Be strict about field types.",
    output_type=Invoice,
)

notifier = Agent(
    name="notification_writer",
    instructions="Write a brief notification message to the requester, referencing the invoice details.",
    output_type=NotificationMessage,
)

async def invoice_intake_workflow(email_content: str) -> ProcessingResult:
    # Step 1: extraction (SDK Agent with structured output)
    extraction = await Runner.run(extractor, email_content)
    invoice: Invoice = extraction.final_output

    # Step 2: validation (plain Python, no LLM)
    validation = validate_against_db(invoice)
    if not validation.ok:
        return ProcessingResult(status="rejected", reason=validation.reason)

    # Step 3: store (plain Python, no LLM)
    record_id = db.insert(invoice)

    # Step 4: notify (SDK Agent with structured output)
    notif = await Runner.run(notifier, f"Invoice {record_id} from {invoice.vendor} stored. Notify {invoice.requester}.")
    email.send(invoice.requester, notif.final_output.subject, notif.final_output.body)

    return ProcessingResult(status="completed", record_id=record_id)

SDK आकार पर ध्यान दें: दो संकीर्ण Agent उदाहरण, प्रत्येक एक LLM-केवल कार्य (निष्कर्षण, अधिसूचना लेखन) कर रहे हैं। प्रत्येक agent में output_type= के माध्यम से structured output है, कोई फ्री-फॉर्म टेक्स्ट पार्सिंग नहीं है। Runner.run() को दो बार कॉल किया जाता है, प्रत्येक LLM-चरण में एक बार। नहीं tools, नहीं @function_tool decorators, कोई हैंडऑफ़ नहीं, क्योंकि workflow को agentic तर्क की आवश्यकता नहीं है, बस LLM सादे Python में एम्बेडेड कॉल हैं।

SDK अंतर्दृष्टि को आत्मसात करने लायक: Agent का हर उपयोग "agentic" नहीं होता। बिना tools वाला output_type= उपयोग करने वाला Agent, SDK में "typed response के साथ LLM call" करने का idiomatic तरीका है, और sequential workflow के interpretation steps को यही चाहिए। आप agent loop इस्तेमाल किए बिना SDK इस्तेमाल कर रहे हैं।

Deployment रचना। अनुक्रमिक workflows cloud stack के सबसे छोटे उपसमुच्चय का उपयोग करें:

• SDK primitives का उपयोग किया गया: Agent (संरचित निष्कर्षण/पीढ़ी के लिए output_type= के साथ), प्रत्येक LLM-चरण के लिए Runner.run()। नहीं @function_tool, नहीं handoff(), नहीं as_tool(), नहीं output_guardrail. agent loop अप्रयुक्त है, Runner.run() एक LLM कॉल के बाद वापस आ जाता है क्योंकि agent में कोई tools नहीं है।
• FastAPI harness Azure Container Apps पर: हां, requests प्राप्त करने के लिए आपको अभी भी HTTP सेवा की आवश्यकता है।
• Neon Postgres durable state के लिए: हाँ, workflow के रिकॉर्ड-कीपिंग और निष्क्रियता के लिए।
• OpenAI API LLM कॉल के लिए: हाँ, लेकिन केवल उन विशिष्ट चरणों के लिए जिनके लिए इसकी आवश्यकता है।
• Cloudflare R2 फ़ाइलों के लिए: शायद, केवल तभी जब workflow फ़ाइल artifacts को संभालता है।
• Cloudflare Sandbox निष्पादन के लिए: नहीं. अनुक्रमिक workflows न चलाएं agent-generated code; वे एम्बेडेड LLM कॉल के साथ निर्धारक कोड चलाते हैं। sandbox परत (और bridge Worker) की आवश्यकता नहीं है।

यह अनुक्रमिक workflows के बारे में सबसे कम प्रशंसित खोज है: उन्हें cloud-deployment पाठ्यक्रम द्वारा सिखाई जाने वाली अधिकांश deployment जटिलता की आवश्यकता नहीं है। यदि आपका task sequential workflow में फिट बैठता है, तो आप FastAPI + Postgres + OpenAI stack पर ship कर सकते हैं और इसे छोड़ सकते हैं। sandbox बुनियादी ढांचा पूरी तरह से। लागत बचत: पूर्ण agentic deployment की तुलना में सार्थक रूप से कम बुनियादी ढांचा, क्योंकि आप sandbox और ब्रिज-worker स्तरों को पूरी तरह से छोड़ देते हैं। उस क्षमता के लिए भुगतान न करें जिसकी pattern को आवश्यकता नहीं है।

Eval signals. eval suite अनुक्रमिक workflows के लिए विशेष रूप से क्या देखता है:

विफलता मोड	इवल इसे किस रूप में पकड़ता है
निष्कर्षण चरण इनपुट को गलत तरीके से पढ़ता है	आउटपुट schema validation विफल; DeepEval structured-output mismatch को पकड़ता है
सत्यापन तर्क में एक अंतर है	Production मामला छूट गया; trace भंडारण तक पहुंचने वाला वैध-लेकिन-गलत रिकॉर्ड दिखाता है
अधिसूचना संदेश ऑफ-टोन या तथ्यात्मक रूप से गलत है	उत्पन्न संदेश पर Phoenix inline evaluator इसे पकड़ लेता है; golden dataset को पदोन्नति
Workflow ऐसे मामले को संभालता है जिसके लिए इसे डिज़ाइन नहीं किया गया था	DeepEval परीक्षण सूट में "edge केस इनपुट" शामिल हैं; विफलताएँ workflow की धारणा सीमा को उजागर करती हैं

मुख्य अंतर्दृष्टि: sequential workflow मूल्यांकन चरण-स्तरीय शुद्धता के बारे में हैं, न कि agent reasoning गुणवत्ता के बारे में। आप प्रत्येक LLM-उपयोग चरण का स्वतंत्र रूप से परीक्षण करते हैं (क्या निष्कर्षण return सही schema है? क्या पीढ़ी सही स्वर उत्पन्न करती है?)। आप workflow के शाखा बिंदुओं का परीक्षण करते हैं (क्या सत्यापन उन मामलों को पकड़ता है जो इसे करना चाहिए?)। आपको यह परीक्षण करने की आवश्यकता नहीं है कि "क्या agent ने सही रास्ता चुना" क्योंकि रास्ता तय हो गया है।

जहां टीमों को production में यह गलती मिलती है। LLM-एम्बेडेड workflows के साथ ऐसा व्यवहार करना जैसे कि वे agentic हों। टीमें workflows में agent loops (tool-call tracing, reasoning-step inspection) के लिए डिज़ाइन की गई observability जोड़ती हैं, जबकि उनमें न tool calls होते हैं और न reasoning steps। आपको बस standard request/response tracing plus structured-output validation per step चाहिए। Phoenix के agent-reasoning dashboards जरूरत से ज़्यादा हैं; App Insights की standard request tracing सही level है।

Operational envelope. Sequential workflow, Inngest के टिकाऊ-निष्पादन model के लिए सबसे सीधा फिट है। pattern की संरचना, निश्चित चरण, प्रत्येक संभावित रूप से विफल, नियतात्मक निर्भरता, बिल्कुल वही है जिसके लिए Inngest functions का निर्माण किया गया है।

• Inngest primitives का उपयोग किया गया: workflow को पंजीकृत करने के लिए @inngest_client.create_function; वेक सिग्नल के लिए TriggerEvent या TriggerCron; एक ctx.step.run("step-name", fn, args) प्रति workflow चरण। नहीं step.wait_for_event (नियमित workflow के लिए कोई HITL आवश्यक नहीं), कोई fan-out नहीं (workflow रैखिक है), कोई जटिल प्रवाह नियंत्रण नहीं।
• 1:1 मैपिंग: sequential workflow में प्रत्येक चरण Inngest function में एक ctx.step.run कॉल बन जाता है। कॉन्सेप्ट 9 के कोड (एक्सट्रेक्ट → वेलिडेट → स्टोर → नोटिफाई) से पांच-चरण invoice intake पांच step.run कॉल बन जाते हैं। चरण 3 → चरण 1-2 return memoized आउटपुट पर क्रैश, चरण 3 retries.
• Cost लाभ: $0.001-$0.05 प्रति LLM कॉल पर, एक workflow जो मेमोइज़ेशन के बिना चरण 5 पर क्रैश हो जाता है, चरणों के लिए पुनः भुगतान करता है 1-4. मेमोइज़ेशन के साथ, केवल चरण 5 retries। ऑपरेशनल-लिफाफा पाठ्यक्रम इसकी मात्रा निर्धारित करता है; workflows के रूप में बचत यौगिक लंबा होता है।

Sequential workflow प्लस Inngest पाठ्यक्रम में सबसे सरल production-तैयार agentic deployment है। कई वास्तविक workflows जिन्हें गलती से "agentic सिस्टम" समझ लिया जाता है, उन्हें step.run checkpoints के साथ Inngest functions होना चाहिए। decision tree का Q1 ("क्या रास्ता ज्ञात है?") अनिवार्य रूप से पूछ रहा है कि क्या आपको Inngest तक पहुंचना चाहिए, जिसके ऊपर कोई agent loop न हो।

*संकल्पना की निचली पंक्ति 9: sequential workflow सही pattern है जब पथ ज्ञात और स्थिर होता है। यह cloud stack (कोई sandbox आवश्यक नहीं) के सबसे छोटे उपसमूह का उपयोग करता है, केवल व्याख्या चरणों के लिए LLM कॉल को सुरक्षित रखता है, और इसका मूल्यांकन agent-reasoning स्तर के बजाय चरण स्तर पर किया जाता है। सबसे आम production गलती workflows को agent-ग्रेड observability के साथ ओवर-इंस्ट्रूमेंट करना है जिनकी उन्हें आवश्यकता नहीं है।*

संकल्पना 10: Single agent + ReAct + tools, विशिष्ट आकार, deployment, eval signals

यह क्या है। एक agent जो अपनी वर्तमान स्थिति के बारे में तर्क करने और एक कार्रवाई करने (एक tool call) के बीच वैकल्पिक होता है, परिणाम देखता है, और दोहराता है। पथ अज्ञात है (Q1=नहीं) और संरचना स्पष्ट नहीं है (Q3=नहीं)। परिभाषित करने वाली संपत्ति: agent अभी जो देखा गया है उसके आधार पर निर्णय लेता है कि आगे क्या करना है।

OpenAI Agents SDK में विशिष्ट कार्यान्वयन:

from agents import Agent, Runner, function_tool

# Tools: plain async Python functions, exposed to the agent via the decorator.
# Type hints and docstrings become the tool's schema automatically.
@function_tool
async def lookup_account(account_id: str) -> dict:
    """Look up an account's current state including balance, plan, and billing status."""
    return await db.accounts.find_by_id(account_id)

@function_tool
async def lookup_transactions(account_id: str, since_days: int = 90) -> list[dict]:
    """Return recent transactions for an account; defaults to last 90 days."""
    return await db.transactions.find(account_id=account_id, since=since_days)

@function_tool
async def issue_refund(transaction_id: str, amount_cents: int, reason: str) -> dict:
    """Issue a refund. Fails if amount exceeds agent's authority ($500). Returns refund_id."""
    return await refund_service.create(transaction_id, amount_cents, reason)

@function_tool
async def escalate_to_human(reason: str, context: dict) -> str:
    """Hand the case to a human reviewer. Returns the escalation ticket id."""
    return await escalation_service.create_ticket(reason, context)

# One Agent with all the tools. The SDK runs the reason-act-observe loop.
support_agent = Agent(
    name="tier1_support",
    instructions=(
        "You are a Tier-1 customer support agent. Investigate the customer's issue "
        "using your tools. Issue refunds only when policy clearly allows and the "
        "amount is under $500. Escalate any ambiguous case. If you cannot determine "
        "the right action within 3 lookups, escalate. State when you are done."
    ),
    tools=[lookup_account, lookup_transactions, issue_refund, escalate_to_human],
)

# The FastAPI handler: exactly the customer-support Worker's shape.
async def handle_support_request(customer_id: str, query: str) -> str:
    result = await Runner.run(
        support_agent,
        input=f"Customer {customer_id} asks: {query}",
        max_turns=25,  # explicit step budget: non-optional in production
    )
    return result.final_output

SDK आकार पर ध्यान दें: एकाधिक tools के साथ एक Agent, जिसे Runner.run() के माध्यम से बुलाया जाता है। आंतरिक रूप से SDK runs reason-act-observe loop: आप for step in range(max_steps): response = llm.chat(...); for tool_call in response.tool_calls: ... नहीं लिखते हैं। max_turns parameter चरण बजट है; हिट होने पर SDK MaxTurnsExceeded बढ़ा देता है।

SDK अंतर्दृष्टि को आत्मसात करने लायक: विहित ReAct loop एक Runner.run() कॉल है। जटिलता tool परिभाषाओं और agent के निर्देशों में है; loop मशीनरी SDK की जिम्मेदारी है। यह बिल्कुल Maya के Tier-1 Support agent, customer-support Worker के पीछे का pattern है।

Deployment रचना। एकल-agent ReAct cloud stack का अधिकांश उपयोग करता है:

• SDK primitives का उपयोग किया गया: Agent (tools= और instructions= के साथ), प्रत्येक Python function पर @function_tool decorator को tool के रूप में प्रदर्शित किया गया, agentic loop के लिए Runner.run(agent, input, max_turns=N)। यह विहित SDK आकार है, बिल्कुल वही जो customer-support Worker प्रदर्शित करता है। कोई handoff() या as_tool() नहीं (वे multi-agent primitives हैं); नहीं output_guardrail (वह reflection है)।
• FastAPI harness Azure Container Apps पर: हाँ, HTTP सेवा के लिए।
• Neon Postgres के लिए durable state: हाँ, sessions, runs, traces के लिए। महत्वपूर्ण क्योंकि agent का तर्क trace प्राथमिक debugging artifact है।
• Cloudflare R2 फ़ाइलों के लिए: हाँ, यदि agent फ़ाइल इनपुट/आउटपुट को संभालता है।
• Cloudflare Sandbox निष्पादन के लिए: हाँ, यदि agent में कोड-निष्पादन tools है। agent runs apply_patch, शेल कमांड, या मनमाना Python; वह कोड sandbox में जाता है। bridge Worker आवश्यक है.
• Background worker pattern: हाँ, क्योंकि ReAct loops 30+ सेकंड ले सकता है और HTTP request को ब्लॉक नहीं करना चाहिए।

Eval signals. ReAct के विफलता मोड तर्क-स्तर के हैं, इसलिए eval signals तर्क-स्तर के हैं:

विफलता मोड	इवल इसे किस रूप में पकड़ता है
Agent loops, हल किए गए कार्य पर दोबारा गौर करना	Trace-लंबाई विसंगति: एक ही tool को समान arguments के साथ बार-बार कॉल किया जाता है। Phoenix ध्वज
Agent अस्तित्वहीन tools का आह्वान करता है (भ्रमपूर्ण tools)	Tool-SDK में कॉल सत्यापन; संरचित trace अमान्य कॉल दिखाता है; CI eval कैच DeepEval के माध्यम से
Agent हल करने से पहले हार मान लेता है (समयपूर्व समाप्ति)	अंतिम आउटपुट की तुलना अपेक्षित व्यवहार से करें; trace कुछ चरण दिखाता है; DeepEval कैच
Agent का तर्क उसके कार्यों से भिन्न है	Phoenix tool-शुद्धता मूल्यांकनकर्ता: क्या agent का बताया गया कारण उसके द्वारा कहे गए tool से मेल खाता है?
Tool call latency कैस्केड (प्रत्येक चरण धीमा है)	OTel समय से पता चलता है कि कुल runtime latency budget से अधिक है

मुख्य अंतर्दृष्टि: ReAct मूल्यांकन को केवल इनपुट/आउटपुट ही नहीं, बल्कि तर्क trace को भी कैप्चर करना चाहिए। trace डेटा है। यदि आप केवल यह जांचते हैं कि क्या agent को सही उत्तर मिला है, तो आप उन मामलों को छोड़ देंगे जहां इसे भाग्यशाली tool calls द्वारा सही उत्तर मिला था, और उन मामलों को चूक जाएंगे जहां इसे सही उत्तर मिलना चाहिए था लेकिन एक भी गलत निर्णय के कारण नहीं मिला। Phoenix के इनलाइन trace मूल्यांकनकर्ता ReAct के लिए load-असर observability परत हैं।

जहां टीमों को production में यह गलती मिलती है। स्टेप बजट को डिफ़ॉल्ट रूप से अनंत तक छोड़ देना। बिना स्टेप कैप वाला एक ReAct loop, अंततः, एक इनपुट का सामना करेगा जो इसे अनिश्चित काल के लिए loop बनाता है, tokens को जलाता है, workers को अवरुद्ध करता है, और rate limits को समाप्त करता है। हमेशा स्पष्ट रूप से चरणों को कैप करें (25 एक उचित डिफ़ॉल्ट है; कुछ कार्यों के लिए 50 की आवश्यकता होती है; बहुत कम को 100 की आवश्यकता होती है)। जब टोपी पर चोट लगती है, तो यह जांच करने का संकेत है, हटाने का कोई उपाय नहीं।

Operational envelope. Single agent + ReAct Inngest में सफाई से लपेटता है, एक संरचनात्मक निर्णय सही होने के साथ: क्या आप संपूर्ण agent loop को एक चरण में चलाते हैं, या क्या आप इसे कई चरणों में विघटित करते हैं?

• Inngest primitives का उपयोग किया गया: @inngest_client.create_function एक event trigger (TriggerEvent(event="customer/email.received"), Maya का सटीक सेटअप) के साथ; ctx.step.run("agent-loop", Runner.run, agent, input) SDK की Runner.run() कॉल को रैप कर रहा है; डाउनस्ट्रीम सिस्टम की सुरक्षा के लिए concurrency और throttle; वैकल्पिक रूप से HITL को लागू करने के लिए ctx.step.wait_for_event अंदर एक वृद्धि tool।
• संरचनात्मक विकल्प: संपूर्ण agent लूप के लिए एक step.run मानक pattern है। SDK runs reason-act-observe loop आंतरिक रूप से; Inngest के दृष्टिकोण से, यह एक टिकाऊ कदम है। मध्य-loop में दुर्घटना → संपूर्ण loop retries (SDK के traces खो जाते हैं, लेकिन function पुनः प्राप्त हो जाते हैं)। वैकल्पिक रूप से, विघटित, प्रत्येक tool call को अपने स्वयं के step.run में लपेटें, महीन दाने वाला स्थायित्व देता है लेकिन SDK के loop को Runner.run() से बाहर निकालने की आवश्यकता होती है, जो नाजुक है। जब तक आपके पास विघटित होने का कोई विशेष कारण न हो, प्रति agent loop एक step.run पर डिफ़ॉल्ट होता है।
• HITL wait_for_event के माध्यम से: संकल्पना 10 के कोड से वृद्धि tool एक Inngest pattern बन जाती है। जब agent escalate_to_human को कॉल करता है, तो वह tool एक event (refund/approval.requested) को फायर करता है और function step.wait_for_event के माध्यम से निलंबित हो जाता है जब तक कि मानव प्रतिक्रिया नहीं देता। agent कोड साफ रहता है, यह बस tool को कॉल करता है, और स्थायित्व को लिफाफे द्वारा नियंत्रित किया जाता है।
• Concurrency कैप्स: concurrency=[Concurrency(limit=10, key="event.data.customer_id")] एक ग्राहक को दूसरों को भूखा मारने से रोकता है। यह Maya का प्रति-कुंजी concurrency pattern है, जो सीधे Maya के deployment पर लागू होता है।

Maya का Tier-1 Support agent _निहित रूप से यह रचना है: इंजन के लिए SDK Agent + Runner.run(), deployment के लिए ACA + नियॉन + R2 + sandbox, साथ ही triggers, स्थायित्व और प्रवाह नियंत्रण के लिए Inngest लिफाफा (जब मौजूद हो)। भाग 5 में निर्णय 1 रचना को स्पष्ट करता है।

अवधारणा की निचली पंक्ति 10: एकल-agent ReAct सही pattern है जब पथ अज्ञात है और संरचना स्पष्ट नहीं है। यह अधिकांश cloud stack (sandbox यदि agent runs कोड के लिए आवश्यक है; Python हार्नेस के लिए bridge Worker आवश्यक है) का उपयोग करता है। ईवल अनुशासन तर्क trace को पकड़ता है, न कि केवल अंतिम आउटपुट को: Phoenix ReAct के लिए load-असर observability है क्योंकि trace-स्तर के सिग्नल विशिष्ट विफलताओं (लूपिंग, मतिभ्रम tools, समय से पहले समाप्ति, तर्क-क्रिया विचलन) को पकड़ते हैं।

संकल्पना 11: Planning + ReAct execution, विशिष्ट आकार, deployment, eval signals

यह क्या है। एक दो-परत pattern: planning agent निष्पादन शुरू होने से पहले एक स्पष्ट योजना (निर्भरता के साथ चरण) तैयार करता है; ReAct + tools प्रत्येक चरण में कार्य संभालता है। चरण स्तर (Q1=नहीं) पर पथ अज्ञात है, लेकिन चरण स्तर (Q3=हाँ) पर संरचना स्पष्ट है।

OpenAI Agents SDK में विशिष्ट कार्यान्वयन:

from agents import Agent, Runner, function_tool
from pydantic import BaseModel
from typing import Literal

class Stage(BaseModel):
    id: str
    description: str
    agent_role: Literal["researcher", "analyzer", "synthesizer"]
    depends_on: list[str]  # other stage ids
    step_budget: int

class Plan(BaseModel):
    task_summary: str
    stages: list[Stage]
    success_criteria: str

# Planner: an Agent that produces a structured plan, no tools.
planner = Agent(
    name="market_research_planner",
    instructions=(
        "Given a research task, produce a plan with 3-7 stages. Each stage has clear "
        "dependencies and a step budget. Prefer fewer broader stages over many narrow ones."
    ),
    output_type=Plan,
)

# Three execution specialists: each with its own tools and instructions.
researcher = Agent(
    name="researcher",
    instructions="Investigate the assigned topic using your tools. Return a structured brief.",
    tools=[web_search, fetch_url, read_document],
)
analyzer = Agent(
    name="analyzer",
    instructions="Analyze the briefs from researchers. Identify patterns, contradictions, gaps.",
    tools=[compute_metrics, compare_briefs],
)
synthesizer = Agent(
    name="synthesizer",
    instructions="Synthesize the analyzed findings into a coherent report.",
    tools=[draft_report, format_citations],
)

ROLE_TO_AGENT = {"researcher": researcher, "analyzer": analyzer, "synthesizer": synthesizer}

async def planning_then_react(task: str, session_id: str) -> str:
    # Stage 1: Generate the plan via the planner Agent
    plan_result = await Runner.run(planner, task)
    plan: Plan = plan_result.final_output
    await db.runs.persist_plan(session_id, plan)  # cloud deployment: plan persistence

    # Stage 2: Execute each stage via the matching specialist Agent
    stage_results: dict[str, str] = {}
    for stage in topological_order(plan.stages):
        agent = ROLE_TO_AGENT[stage.agent_role]
        stage_input = compose_stage_input(stage, stage_results, task)
        stage_run = await Runner.run(agent, stage_input, max_turns=stage.step_budget)
        stage_results[stage.id] = stage_run.final_output
        await db.runs.persist_stage(session_id, stage.id, stage_run.final_output)

    # Stage 3: Final synthesis via the synthesizer one more time
    final = await Runner.run(
        synthesizer,
        f"Compose the final report. Plan: {plan.model_dump_json()}. Results: {stage_results}",
    )
    return final.final_output

SDK आकार पर ध्यान दें: planner एक Agent है जिसमें output_type=Plan है और कोई tools नहीं है (यह केवल structured output उत्पन्न करता है)। प्रत्येक निष्पादन चरण चरण की भूमिका से मेल खाने वाले specialist Agent का उपयोग करता है, जिसे Runner.run() के माध्यम से बुलाया जाता है। योजना Pydantic द्वारा संरचित है, इसलिए SDK इसे प्रकार के स्तर पर मान्य करता है: कोई JSON-पार्सिंग-एंड-होपिंग नहीं। योजना की दृढ़ता cloud deployment के नियॉन-Postgres runs तालिका के माध्यम से होती है (customer-support Worker इसे तार देती है)।

SDK अंतर्दृष्टि को आत्मसात करने लायक: structured-output Agent + tool-Agent का उपयोग करना planning + ReAct execution के दो भाग हैं। SDK का output_type= ही सबसे पहले योजनाएं बनाता है-class artifacts; rest Runner.run() कॉल पर सादा ऑर्केस्ट्रेशन कोड है।

Deployment रचना। Planning + ReAct एकल-agent ReAct के समान घटकों का उपयोग करता है, साथ ही एक अतिरिक्त अनुशासन भी:

• SDK primitives का उपयोग किया गया: planner Agent output_type=PlanSchema के साथ (केवल tools नहीं, structured output); tools=[...] और @function_tool decorators के साथ प्रति भूमिका एक निष्पादन Agent; Runner.run() ने planner के लिए एक बार और प्रति चरण एक बार कॉल किया। योजना की दृढ़ता cloud deployment की runs तालिका में रहती है, SDK में नहीं; Runner.run() कॉलों में SDK स्टेटलेस है।
• संकल्पना 10 से सभी ReAct deployment आवश्यकताएँ: समान harness, sandbox, R2, background worker।
• नियॉन में योजना की दृढ़ता। योजना स्वयं ऑडिट और पुन: प्रयोज्यता के लिए भंडारण योग्य artifact है। runs तालिका में एक नई तालिका या schema एक्सटेंशन plan_id, योजना सामग्री और चरण-दर-चरण प्रगति को ट्रैक करता है।
• लंबे समय तक चलने वाले runs अधिक सामान्य हैं। योजनाओं में अक्सर 5-10 चरण होते हैं, प्रत्येक संभावित रूप से चलने वाले 20-30 ReAct चरण होते हैं। शुरू से अंत तक runs में से 5-10 मिनट सामान्य हैं। background worker pattern अनिवार्य है, वैकल्पिक नहीं।

Eval signals. Planning + ReAct शुद्ध ReAct से परे नए विफलता मोड जोड़ता है:

विफलता मोड	इवल इसे किस रूप में पकड़ता है
Planner से एक योजना कार्यान्वयन भिन्न होता है	योजना की वास्तविक चरण निष्पादन से तुलना करें; जब चरणों को छोड़ दिया गया, पुन: व्यवस्थित किया गया, या मध्य-दौड़ में मूल रूप से पुन: परिभाषित किया गया तो ध्वजांकित किया गया
योजना में चरण गायब हैं (स्पष्ट चरण योजना में नहीं है)	समान कार्यों के लिए गोल्डन-डेटासेट योजनाओं की तुलना करें; DeepEval संरचनात्मक विचलन को चिह्नित करता है
स्टेज हैंडऑफ़ हार गए context	प्रत्येक चरण में इनपुट का निरीक्षण करें; यदि चरण N चरण M से महत्वपूर्ण आउटपुट को संदर्भित नहीं कर सकता है, तो handoff जानकारी खो जाती है
योजना अत्यधिक विस्तृत है (प्रत्येक चरण एक एकल tool call है)	योजना-चरण आकार विश्लेषण; यदि प्रत्येक चरण 1-2 ReAct चरणों में निष्पादित होता है, तो planning परत काम नहीं कर रही है
योजना का विवरण कम है (एक चरण में व्यापक दायरा शामिल है)	योजना-चरण आकार विश्लेषण; यदि एक चरण runs 50+ ReAct चरण, planning वास्तव में विघटित नहीं होता है

मुख्य अंतर्दृष्टि: planning + ReAct मूल्यांकन को योजना गुणवत्ता को निष्पादन गुणवत्ता से अलग मापना चाहिए। खराब क्रियान्वयन वाली एक अच्छी योजना अच्छे क्रियान्वयन वाली खराब योजना से अलग दिखती है; उन्हें मिलाने से गलत निदान उत्पन्न होता है। eval signal "योजना-निष्पादन विचलन" सबसे अधिक जानकारीपूर्ण है, यह इंगित करता है कि planner ऐसी संरचना का निर्माण कर रहा है जो task के पास वास्तव में नहीं है।

जहां टीमों को production में यह गलती मिलती है। योजना पर ऐसे भरोसा करना जैसे कि यह एक अनुबंध था। योजना एक प्रारंभिक संरचना है; चरणों के भीतर निष्पादन से वैध रूप से यह पता चल सकता है कि अगले चरण में योजना से भिन्न कार्य की आवश्यकता है। विचलन को हमेशा-बुरा मानना ​​कठोरता पैदा करता है; इसे हमेशा-ठीक मानने से planning का मान समाप्त हो जाता है। सही अनुशासन है: log प्रत्येक विचलन, समय-समय पर pattern के लिए विचलन की समीक्षा करें (आवर्ती विचलन का मतलब है कि planner में सुधार की आवश्यकता है), और बिना किसी चेतावनी के छोटे चरण के अनुकूलन होने दें।

Operational envelope. Planning + ReAct execution, Inngest के चरण.रन model के लिए सबसे स्पष्ट फिट है, प्रत्येक चरण एक step.run पर मैप होता है, और मल्टी-स्टेज रन में स्थायित्व लाभ यौगिक होता है।

• Inngest primitives का उपयोग किया गया: @inngest_client.create_function मूल function के लिए; प्रति चरण एक ctx.step.run (step.run("plan", Runner.run, planner, task), फिर प्रति निष्पादन चरण एक step.run); यदि कुछ चरणों में गैर-क्षणिक विफलता मोड हैं तो retries= प्रति चरण कॉन्फ़िगर किया गया है; concurrency को समानांतर कैप करने के लिए runs।
• योजना-फिर-निष्पादित मैपिंग: step.run("plan", ...) योजना तैयार करता है; function फिर योजना चरणों को दोहराता है, प्रत्येक के लिए step.run(f"stage-{stage.id}", ...) को कॉल करता है। यदि function निष्पादन के मध्य में क्रैश हो जाता है (जैसे, 6 के चरण 4 पर), Inngest योजना को पुनर्स्थापित करता है और 1-3 को संस्मरण से हटा देता है; एकमात्र चरण 4 retries। योजना दृढ़ता निःशुल्क है, Inngest इसे "योजना" चरण के आउटपुट के रूप में संग्रहीत करता है।
• Cost प्रभाव: यहां बचत किसी भी pattern से सबसे बड़ी है। planning + ReAct रन में 5-10 मिनट लग सकते हैं और इसमें 20-30 tool calls शामिल हो सकता है; बिना टिकाऊपन के 8 मिनट पर एक दुर्घटना हर चीज़ के लिए पुनः भुगतान करती है। operational envelope का संस्मरण GPT-5-वर्ग मूल्य निर्धारण पर प्रति क्रैश रन $0.50-$2.00 को बचा सकता है। 1000 जैसे runs/दिन और 1-5% क्रैश दर वाले सिस्टम के लिए क्षणिक बुनियादी ढांचे के मुद्दों से, वह $150-$1000/महीना सीधे सहेजे गए LLM costs में है।
• समानांतर चरण निष्पादन: एक-दूसरे पर निर्भरता के बिना चरणों को operational envelope के fan-out pattern (प्रति चरण एक event, प्रत्येक अपने स्वयं के function को ट्रिगर करता है) के माध्यम से बढ़ाया जा सकता है, प्रति-चरण स्थायित्व को संरक्षित करते हुए निष्पादन को समानांतर किया जा सकता है।

संकल्पना 11 की deployment संरचना से "नियॉन में योजना दृढ़ता" की आवश्यकता आंशिक रूप से अनावश्यक है यदि Inngest लिफाफे में है, क्योंकि Inngest योजना को "योजना" चरण के आउटपुट के रूप में संग्रहीत करता है। नियॉन अभी भी ऑडिट के लिए रन और observability को OTel के माध्यम से ट्रैक करता है, लेकिन योजना-पुनर्प्राप्ति कहानी को Inngest द्वारा नियंत्रित किया जाता है, आपके एप्लिकेशन कोड द्वारा नहीं।

संकल्पना की निचली पंक्ति 11: planning + ReAct execution सही pattern है जब संरचना स्पष्ट है लेकिन चरण-स्तरीय कार्य के लिए अनुकूलन की आवश्यकता होती है। यह पूर्ण ReAct deployment stack प्लस योजना दृढ़ता और पृष्ठभूमि-worker pattern का उपयोग करता है। eval अनुशासन योजना की गुणवत्ता को निष्पादन की गुणवत्ता से अलग करता है, योजना-निष्पादन विचलन सबसे अधिक जानकारीपूर्ण संकेत है, जो दर्शाता है कि planner संरचना का निर्माण कर रहा है जो task के पास वास्तव में नहीं है।

संकल्पना 12: Single agent + reflection, विशिष्ट आकार, deployment, eval signals

यह क्या है। किसी भी मूल pattern के शीर्ष पर परत: agent आउटपुट उत्पन्न करने के बाद, एक समालोचना पास स्पष्ट criteria के विरुद्ध इसका मूल्यांकन करता है; यदि दोषों की पहचान की जाती है, तो agent परिष्कृत या पुनर्जीवित करता है। Reflection Q4 (गुणवत्ता > गति और checkable criteria) द्वारा उचित है।

OpenAI Agents SDK में विशिष्ट कार्यान्वयन। SDK आपको reflection के लिए दो अलग-अलग primitives देता है, आप सत्यापन (खराब आउटपुट को ब्लॉक करें) या शोधन (बॉर्डरलाइन आउटपुट में सुधार) चाहते हैं, इसके आधार पर चुनें।

सत्यापन-शैली reflection के लिए स्वाद 1, output_guardrail (हल्का SDK-देशी pattern):

from agents import Agent, Runner, output_guardrail, GuardrailFunctionOutput, RunContextWrapper
from pydantic import BaseModel

class SQLReview(BaseModel):
    is_safe: bool
    issues: list[str]
    reasoning: str

# A critic Agent: uses a different model from the generator to avoid blind-spot overlap.
sql_critic = Agent(
    name="sql_critic",
    model="claude-opus-4-5",  # different model family from the generator
    instructions=(
        "Review the SQL query. Check that it parses, hits only allowed tables, "
        "does not use SELECT *, and has appropriate WHERE clauses. Flag any issues."
    ),
    output_type=SQLReview,
)

@output_guardrail
async def critic_guardrail(ctx: RunContextWrapper, agent: Agent, output: str) -> GuardrailFunctionOutput:
    review_result = await Runner.run(sql_critic, output)
    review: SQLReview = review_result.final_output
    return GuardrailFunctionOutput(
        output_info={"issues": review.issues, "reasoning": review.reasoning},
        tripwire_triggered=not review.is_safe,
    )

# The generator Agent: uses output_guardrails to invoke the critic.
sql_generator = Agent(
    name="sql_generator",
    model="gpt-5",  # different model family from the critic
    instructions="Generate a SQL query that answers the user's question.",
    tools=[fetch_schema, list_tables],
    output_guardrails=[critic_guardrail],
)

# When tripwire fires, Runner.run raises OutputGuardrailTripwireTriggered.
# Catch it and decide: retry with critique context, escalate, or fail loudly.

फ्लेवर 2, शोधन-शैली reflection के लिए critic-और-रिफाइनर loop को अलग करता है (जब आप चाहते हैं कि generator अपने आउटपुट को ठीक करे, न कि केवल खराब आउटपुट को ब्लॉक करें):

async def with_reflection(task: str, max_refinements: int = 2) -> str:
    output = (await Runner.run(sql_generator, task)).final_output
    for refinement in range(max_refinements):
        critique = (await Runner.run(sql_critic, output)).final_output
        if critique.is_safe and not critique.issues:
            return output
        # Refinement: feed the critique back to the generator
        refine_prompt = f"Original query:\n{output}\n\nCritic flagged: {critique.issues}\n\nRevise the query."
        output = (await Runner.run(sql_generator, refine_prompt)).final_output
    return output  # max refinements reached; output is best-effort

दो SDK आकृतियों पर ध्यान दें: output_guardrail "खराब आउटपुट को ब्लॉक करने" के लिए SDK का मूल pattern है: घोषणात्मक, agent की परिभाषा से बंधा हुआ, runs प्रत्येक Runner.run() पर स्वचालित रूप से। अलग critic-और-रिफाइनर loop "बॉर्डरलाइन आउटपुट में सुधार" के लिए SDK का मुहावरेदार pattern है: अधिक लचीला, लेकिन आप ऑर्केस्ट्रेशन लिखते हैं। दोनों pattern critic और generator के लिए अलग-अलग models का उपयोग करते हैं। यह अनुशासन अवधारणा 7 है, जिसे प्रत्येक Agent पर SDK के model= parameter के माध्यम से ठोस बनाया गया है।

SDK अंतर्दृष्टि को आत्मसात करने लायक: reflection SDK में एक अलग framework primitive नहीं है, यह Agent + Agent की एक रचना है। output_guardrail decorator दूसरे agent को पहले वाले के आउटपुट पथ में जोड़ने के लिए सिर्फ एक SDK कन्वेंशन है।

Deployment रचना। Reflection परतें मुख्य pattern के शीर्ष पर होती हैं, इसलिए deployment संरचना इस पर निर्भर करती है कि नीचे क्या है:

• SDK primitives का उपयोग किया गया: output_guardrail (SDK का मूल सत्यापन primitive) ब्लॉक-खराब-आउटपुट reflection के लिए; या दो Agent उदाहरण (generator + critic) Runner.run() के साथ शोधन-शैली reflection के लिए agent के अनुसार बुलाए जाते हैं। गंभीर रूप से: critic को जेनरेटर से भिन्न model=, समान SDK, भिन्न model परिवार का उपयोग करना चाहिए।
• यदि कोर sequential workflow है, तो reflection 1-2 LLM कॉल जोड़ता है; deployment संरचनात्मक रूप से नहीं बदलता है।
• यदि कोर ReAct + tools है, तो agent loop पूर्ण होने के बाद reflection 1-2 LLM कॉल जोड़ता है; deployment संरचनात्मक रूप से नहीं बदलता है।
• यदि कोर planning + ReAct है, तो reflection अक्सर चरणों के बीच जाता है (चरण N+1 शुरू होने से पहले चरण N का आउटपुट समालोचना करता है) और अंतिम संश्लेषण पर; यह latency जोड़ता है।

नया deployment विचार: model किस्म। यदि critic generator से भिन्न model का उपयोग करता है (क्लाउड GPT की आलोचना करता है, या इसके विपरीत), तो harness को कई model प्रदाताओं का समर्थन करने की आवश्यकता होती है। cloud deployment पाठ्यक्रम एकल-प्रदाता deployment सिखाता है; reflection को जोड़ने से अक्सर बहु-प्रदाता एक वास्तविक आवश्यकता के रूप में सामने आता है। _ तदनुसार रहस्य-प्रबंधन और रूटिंग की योजना बनाएं।_

Eval signals. Reflection के अपने विशिष्ट विफलता मोड हैं:

विफलता मोड	इवल इसे किस रूप में पकड़ता है
Reflection आउटपुट नहीं बदलता (rubber-stamping)	प्री-reflection और पोस्ट-reflection आउटपुट की तुलना करें; यदि वे उस समय के लगभग समान हैं >80%, तो reflection काम नहीं कर रहा है
Reflection गलत दिशा में परिष्कृत करता है (आउटपुट को बदतर बनाता है)	golden dataset के विरुद्ध reflection से पहले और बाद में स्कोर करें; शुद्ध नकारात्मक प्रभाव का मतलब है critic मिसफायरिंग है
Critic और generator ब्लाइंड स्पॉट साझा करते हैं	ए/बी परीक्षण: एक ही generator, दो अलग-अलग आलोचक (अलग-अलग models या prompts); यदि आलोचना सामग्री दृढ़ता से सहसंबद्ध है, तो आलोचक पर्याप्त रूप से स्वतंत्र नहीं हैं
Criteria समय के साथ बहाव (criteria list तदर्थ रूप से बढ़ता या सिकुड़ता है)	संस्करण-नियंत्रण criteria list; जब परिवर्तन प्रलेखित निर्णयों के अनुरूप न हों तो ध्वजांकित करें
शोधन loops बजट से अधिक है	शोधन काउंटर सीमा से अधिक है; जांच करें कि critic ऐसी खामियां क्यों ढूंढता रहता है जिन्हें generator ठीक नहीं कर सकता

मुख्य अंतर्दृष्टि: reflection मूल्यांकनों को यह मापना चाहिए कि क्या reflection नेट-पॉजिटिव है, न कि केवल यह कि क्या यह runs है। एक reflection उस runs को बिना आउटपुट बदले overhead पास करता है; reflection पास जो आउटपुट को बदतर बनाता है वह हानिकारक है। "रबर-स्टैम्प" विफलता मोड का पता लगाना सबसे कठिन है क्योंकि सतह मीट्रिक से सिस्टम स्वस्थ दिखता है (latency ऊपर चला गया, त्रुटियाँ स्थिर रहीं) लेकिन अपनी cost अर्जित नहीं कर रहा है।

जहां टीमों को production में यह गलती मिलती है। reflection को जोड़ना क्योंकि यह कठोर लगता है। टीमें यह मापे बिना "उत्पन्न करें, फिर आलोचना करें" pattern जोड़ती हैं कि क्या आलोचना उन चीजों को पकड़ती है जो generator से छूट गई हैं। महीनों बाद, reflection पास में अतिरिक्त LLM कॉल में cost $X है और मापने योग्य गुणवत्ता सुधार में $0 प्रदान किया गया है। अनुशासन है: पहले महीने के भीतर reflection के शुद्ध योगदान को मापें, और यदि योगदान सीमा से कम है तो इसे हटा दें।

Operational envelope. Reflection, Inngest के चरण model के साथ अच्छी तरह से रचना करता है, प्रत्येक पास (उत्पन्न, आलोचना, परिष्कृत) अपना स्वयं का step.run बन जाता है, और स्थायित्व लाभ किसी भी व्यक्तिगत विफलता से पहले आपके द्वारा किए गए कितने पासों के अनुपात में होते हैं।

• Inngest primitives का उपयोग किया गया: प्रति रन तीन या चार ctx.step.run कॉल, शोधन प्रयासों के लिए step.run("generate", ...), step.run("critique", ...), और 0-2 step.run("refine-N", ...)। वैकल्पिक रूप से: ctx.step.wait_for_event जब critic मानव है (function तब तक निलंबित रहता है जब तक कोई मानव reviewer अनुमोदन event को सक्रिय नहीं कर देता, वही HITL-गेट primitive operational envelope प्रदान करता है)।
• स्थायित्व जीतता है: यदि generator चरण सफलतापूर्वक पूरा हो जाता है (सबसे महंगा कदम, यह समीक्षित आउटपुट उत्पन्न करता है), और critic चरण क्षणिक रूप से विफल हो जाता है (दर सीमा, नेटवर्क ब्लिप), केवल critic चरण retries। _generator का आउटपुट memoized है और पुनर्जीवित नहीं होता है। _operational envelope का step.run अनुशासन ही है जो क्रैश होने पर reflection के जोड़े गए latency को डबल-cost में संयोजित होने से रोकता है।
• HITL reflection। जब मूल्यांकन criteria को किसी अन्य LLM (संकल्पना 7 के "व्यक्तिपरक डोमेन" चेतावनी) द्वारा जांचा नहीं जा सकता है, तो सही उत्तर अक्सर मानवीय प्रतिबिंब होता है। Inngest का step.wait_for_event इसे साफ़ बनाता है: step.run("generate", ...) → step.run("send-to-reviewer", ...) → step.wait_for_event("await-human-decision", timeout=timedelta(hours=4)) → step.run("act-on-decision", ...)। मानव समीक्षा करते समय function शून्य गणना खपत के साथ निलंबित हो जाता है। परिचालन-लिफाफा पाठ्यक्रम HITL pattern पर विस्तार से चलता है।
• Reflection का cost-प्रति-आउटपुट अनुशासन: Inngest का रन-लेवल cost ट्रैकिंग (step.run के LLM cost के अनुसार) reflection के शुद्ध योगदान को मापना आसान बना देता है। प्रति-रन cost तुलना (reflection बनाम बिना-reflection के साथ) एक Phoenix dashboard query दूर है।

कॉन्सेप्ट 12 से reflection के दो SDK फ्लेवर (output_guardrail बनाम अलग critic-और-रिफाइनर loop) दोनों स्वाभाविक रूप से Inngest के लिफाफे के साथ बनते हैं। reflection शैली द्वारा SDK स्वाद चुनें; लिफ़ाफ़ा अनुशासन किसी भी तरह से समान है।

अवधारणा की निचली पंक्ति 12: reflection सही योगात्मक परत है जब गुणवत्ता गति से अधिक मायने रखती है और criteria जांच योग्य होती है। यह किसी भी मूल pattern के शीर्ष पर परतें चढ़ाता है। ईवल अनुशासन मापता है कि क्या reflection नेट-पॉजिटिव है, rubber-stamping सबसे घातक विफलता मोड है क्योंकि सतह मेट्रिक्स स्वस्थ दिखते हैं। यदि reflection, deployment के एक महीने के भीतर आउटपुट में उल्लेखनीय सुधार नहीं कर रहा है, तो इसे हटा दें।

संकल्पना 13: Multi-agent specialist system, विशिष्ट आकार, deployment, eval signals

यह क्या है। विभिन्न भूमिकाओं वाले एकाधिक agents एक task पर सहयोग करते हैं। Q5 द्वारा उचित, विशेषज्ञता, context, या स्केल एक वास्तविक bottleneck बनाता है। pattern composition मायने रखता है: प्रत्येक specialist का आंतरिक architecture sequential workflow, ReAct, या planning + ReAct हो सकता है। Multi-agent अन्य pattern का प्रतिस्थापन नहीं है; यह उनकी एक रचना है.

तीन SDK-मूल topologies, प्रत्येक एक अलग SDK primitive का उपयोग कर रहे हैं।

Topology 1, Coordinator specialists के साथ tools (SDK का Agent.as_tool() pattern)। coordinator नियंत्रण में रहता है; specialists को function tools की तरह बुलाया जाता है।

from agents import Agent, Runner, function_tool

# Three specialists, each with its own tools and instructions.
researcher = Agent(name="researcher", instructions="...", tools=[web_search, fetch_url])
writer = Agent(name="writer", instructions="...", tools=[draft_document])
reviewer = Agent(name="reviewer", instructions="...", tools=[lint_check, fact_check])

# The coordinator uses specialists as_tool(): calling them like functions.
coordinator = Agent(
    name="coordinator",
    instructions=(
        "Decompose the task into research, writing, and review phases. "
        "Use the specialist tools in order. Compose their outputs into a final report."
    ),
    tools=[
        researcher.as_tool(tool_name="research_topic", tool_description="Investigate a topic and return a brief"),
        writer.as_tool(tool_name="draft_document", tool_description="Draft a document from research notes"),
        reviewer.as_tool(tool_name="review_document", tool_description="Review a draft and return critique"),
    ],
)

async def coordinator_topology(task: str) -> str:
    result = await Runner.run(coordinator, task, max_turns=30)
    return result.final_output

Topology 2: अनुक्रमिक handoff (SDK का handoff() pattern)। Specialists बातचीत को संभालें; SDK उनके बीच context पास करता है।

from agents import Agent, Runner, handoff

# Define specialists; each one declares which agents it can hand off TO.
final_reviewer = Agent(name="reviewer", instructions="Review the draft and produce the final output.")
writer = Agent(
    name="writer",
    instructions="Draft from the research. When the draft is ready, hand off to the reviewer.",
    handoffs=[handoff(final_reviewer)],
)
researcher = Agent(
    name="researcher",
    instructions="Investigate the topic. When research is complete, hand off to the writer.",
    tools=[web_search, fetch_url],
    handoffs=[handoff(writer)],
)

async def handoff_topology(task: str) -> str:
    # Start with the researcher; the SDK threads control through handoffs.
    result = await Runner.run(researcher, task, max_turns=50)
    return result.final_output  # whoever ended up holding the conversation

Topology 3, समानांतर specialists एक synthesizer द्वारा रचित। SDK runs प्रत्येक specialist स्वतंत्र रूप से Runner.run() के माध्यम से; synthesizer उनके आउटपुट तैयार करता है।

import asyncio
from agents import Agent, Runner

# Five domain specialists running in parallel: one per competitor to research.
competitor_specialist = Agent(
    name="competitor_research",
    instructions="Research one competitor in depth: pricing, product, positioning, recent news.",
    tools=[web_search, fetch_url, read_document],
)
synthesizer = Agent(
    name="synthesizer",
    instructions="Compose competitor briefs into a single comparative landscape report.",
)

async def parallel_topology(competitors: list[str]) -> str:
    # Each specialist runs independently: different Runner.run() calls.
    parallel_briefs = await asyncio.gather(*[
        Runner.run(competitor_specialist, f"Research: {c}", max_turns=15)
        for c in competitors
    ])
    briefs_text = "\n\n".join(r.final_output for r in parallel_briefs)
    final = await Runner.run(synthesizer, briefs_text)
    return final.final_output

खेल में तीन SDK primitives पर ध्यान दें:

• Agent.as_tool() एक agent को कॉल करने योग्य tool के रूप में लपेटता है, coordinator प्रभारी रहता है, specialists को functions की तरह कॉल करता है। सबसे अच्छा तब जब coordinator को आउटपुट लिखने और अगला चरण तय करने की आवश्यकता हो।
• handoff() बातचीत को दूसरे agent को भेजता है, स्थानांतरण को नियंत्रित करता है, और SDK context को प्रबंधित करता है। सर्वोत्तम तब होता है जब specialist को user-facing इंटरैक्शन पर कब्ज़ा करने की आवश्यकता होती है।
• समानांतर Runner.run() + asyncio.gather() runs specialists स्वतंत्र रूप से: कोई साझा बातचीत नहीं, कोई handoff नहीं। सबसे अच्छा तब जब specialists अलगाव में काम करता है और आउटपुट synthesizer द्वारा बनाए जाते हैं।

SDK अंतर्दृष्टि को आत्मसात करने लायक: SDK आपको multi-agent रचना के लिए मूल primitives देता है। आप रूटिंग लॉजिक को हाथ से रोल नहीं करते हैं। पदानुक्रमित संरचना के लिए as_tool(); क्रमिक अधिग्रहण के लिए handoff(); fan-out के लिए समानांतर Runner.run()। उनके बीच चयन करना अपने आप में एक pattern-चयन निर्णय है, और यह उसी task गुणों Q5 का डाउनस्ट्रीम सामने आया है।

Deployment रचना। मल्टी-agent systems पूर्ण cloud stack के साथ-साथ एक महत्वपूर्ण अतिरिक्त अनुशासन का उपयोग करते हैं:

• SDK primitives का उपयोग किया जाता है: पदानुक्रमित संरचना के लिए Agent.as_tool() (coordinator नियंत्रण में रहता है); क्रमिक अधिग्रहण के लिए handoff() (specialist बातचीत को अपने हाथ में ले लेता है); fan-out के लिए समानांतर Runner.run() + asyncio.gather()। प्रत्येक specialist अपने स्वयं के tools= list और instructions= के साथ अपना Agent है। SDK context-हैंडऑफ़ को पार करने का प्रबंधन करता है; आप रूटिंग को हैंड-रोल नहीं करते हैं.
• प्रत्येक specialist के लिए एकल-agent ReAct की सभी आवश्यकताएं (यदि आवश्यक हो तो harness, sandbox, R2, background worker)।
• Per-specialist runs/traces नियॉन में। प्रत्येक specialist का निष्पादन अपना स्वयं का रन है; multi-agent system एक पेरेंट रन है जो बच्चे runs को संदर्भित करता है। schema को parent_run_id और agent_role कॉलम की आवश्यकता है।
• रूटिंग ऑडिट logs. प्रत्येक रूटिंग निर्णय (कौन सा specialist? कौन सा handoff प्रारूप?) लॉग किया जाता है। Multi-agent विफलताएं आमतौर पर गलत-रूटिंग-निर्णय या खोए-context-on-handoff के रूप में प्रकट होती हैं; स्पष्ट रूटिंग के बिना logs, debugging लगभग असंभव है।
• Cost प्रति specialist ट्रैकिंग। मल्टी-agent systems यह पता लगाना आसान बनाता है कि कौन सा specialist tokens जला रहा है। Per-specialist cost एट्रिब्यूशन भगोड़े costs को समग्र मेट्रिक्स में छिपने से रोकता है।

bridge Worker प्लस specialists। यदि प्रत्येक रन कोड एकाधिक specialists है, तो आपको एकाधिक ब्रिज-Worker कॉन्फ़िगरेशन (विभिन्न specialists' toolींग आवश्यकताओं के लिए अलग-अलग मैनिफ़ेस्ट) या एक एकल bridge Worker की आवश्यकता हो सकती है जो specialist पहचान द्वारा रूट करता है। जटिलता लोगों की अपेक्षा से अधिक तेज़ी से बढ़ती है: यहीं से deployment-topology costs हावी होने लगती है।

Eval signals. Multi-agent विफलताओं का मूल्यांकन करना सबसे कठिन है क्योंकि विफलताएं तीन स्तरों पर हो सकती हैं: specialist के भीतर, रूटिंग/समन्वय में, या एकीकरण में:

विफलता मोड	इवल इसे किस रूप में पकड़ता है
Specialist गलत आउटपुट उत्पन्न करता है	प्रत्येक specialist की भूमिका पर मानक प्रति-agent मूल्यांकन (प्रत्येक specialist के साथ ऐसा व्यवहार करें जैसे कि यह मूल्यांकन उद्देश्यों के लिए एक स्टैंडअलोन agent हो)
Coordinator गलत मार्ग पर जाता है specialist	रूटिंग-सटीकता मूल्यांकन: task दिया गया, क्या यह दाईं ओर specialist पर गया? golden dataset में लेबल किए गए रूटिंग उदाहरणों की आवश्यकता है
Handoff जानकारी खो देता है (specialist B specialist A के आउटपुट का उपयोग नहीं कर सकता)	Handoff-पूर्णता मूल्यांकन: क्या specialist B के पास वह है जो उसे specialist A से चाहिए था? प्रारंभ में मैनुअल लेबल; एक बार pattern स्पष्ट हो जाने पर इसे स्वचालित किया जा सकता है
एकीकरण specialists' आउटपुट को गलत तरीके से जोड़ता है	golden dataset के विरुद्ध शुरू से अंत तक मूल्यांकन; यदि specialists व्यक्तिगत रूप से पास हो जाता है लेकिन एकीकृत आउटपुट विफल हो जाता है, तो एकीकरण समस्या है
Specialists बिना समाधान के असहमत हैं	असंगति डिटेक्टर: समानांतर specialists परस्पर विरोधी उत्तर उत्पन्न करते हैं; एग्रीगेटर या तो स्पष्ट रूप से समाधान करता है या विरोध को सामने लाता है
Coordination overhead कार्य मूल्य से अधिक है	Cost-प्रति-सही-आउटपुट: यदि multi-agent costs 3× एकल-agent पर है और गुणवत्ता में सुधार 20% के अंतर्गत है, तो architecture अपनी overhead अर्जित नहीं कर रहा है।

मुख्य अंतर्दृष्टि: multi-agent मूल्यांकन के लिए तीन अलग-अलग scoreboards की आवश्यकता होती है: specialist गुणवत्ता, रूटिंग सटीकता, एकीकरण गुणवत्ता। उन्हें मिलाने से निरर्थक समग्र स्कोर उत्पन्न होते हैं। प्रत्येक specialist की व्यक्तिगत गुणवत्ता 95% हो सकती है, रूटिंग सटीकता 90% हो सकती है, एकीकरण गुणवत्ता 80% हो सकती है, और एंड-टू-एंड सिस्टम ~68% (उत्पाद) पर प्रदर्शन करता है। अलगाव के बिना, आप यह नहीं बता सकते कि किस परत में सुधार करना है।

जहां टीमों को production में यह गलती मिलती है। multi-agent system को एक इकाई के रूप में मानना। जब कुछ विफल होता है, तो टीम एक परत को स्थानीयकृत करने के बजाय पूरे सिस्टम को डीबग करती है। समाधान: पहले दिन से per-specialist traceिंग और प्रति-handoff लॉगिंग लागू करें। इसके बिना, multi-agent debugging एकल-agent debugging की तुलना में काफी कठिन और धीमा है, अक्सर एक बड़े गुणक द्वारा, और यह pattern के सबसे बड़े छिपे हुए costs में से एक है।

Operational envelope. Multi-agent वह pattern है जो Inngest के operational envelope पर सबसे अधिक निर्भर करता है। लगभग हर लिफाफा primitive एक भूमिका निभाता है: समानांतर specialists के लिए fan-out, tenant निष्पक्षता के लिए प्रति-कुंजी concurrency, tier-आधारित कतार के लिए priority, specialists के बीच HITL gates, आंशिक-विफलता पुनर्प्राप्ति के लिए replay।

• Inngest primitives का उपयोग किया गया (पाठ्यक्रम में सबसे व्यापक रचना):
  • Fan-out trigger pattern समानांतर specialist निष्पादन के लिए: coordinator function N specialist events सक्रिय करता है; प्रत्येक specialist का अपना @inngest_client.create_function है और उसका अपना TriggerEvent है। एक event जागता है N functions; वे समानांतर में चलते हैं; Inngest प्रत्येक को स्वतंत्र रूप से ट्रैक करता है।
  • step.run प्रति specialist रन प्रत्येक specialist function के भीतर, एकल-agent ReAct (अवधारणा 10) के समान स्थायित्व की कहानी, लेकिन एन द्वारा गुणा किया गया।
  • किसी एक tenant को specialist क्षमता पर एकाधिकार जमाने से रोकने के लिए प्रति-कुंजी concurrency कैप्स: concurrency=[Concurrency(limit=5, key="event.data.tenant_id")]। प्रति-कुंजी concurrency यहां load-असर pattern है।
  • tier आधारित निष्पक्षता के लिए Priority अभिव्यक्ति: एंटरप्राइज़ tenant runs queue में मुफ़्त tier से आगे निकल गया।
  • step.wait_for_event specialists के बीच जब हैंडऑफ़ को human approval की आवश्यकता होती है (उदाहरण के लिए, अनुसंधान → मानव-परीक्षणित अनुसंधान → विश्लेषण)।
  • Replay आंशिक विफलता पुनर्प्राप्ति के लिए: जब 5 specialists में से 3 विफल हो जाता है और 2 सफल हो जाता है, तो विफलता-specialist के कोड और replay को ठीक करें; 2 सफल specialists' आउटपुट memoized हैं।
• समन्वय-cost अंतर्दृष्टि: अवधारणा 13 ने नोट किया कि multi-agent का coordination overhead इसका सबसे बड़ा छिपा हुआ cost है। Inngest का primitives उस overhead में से अधिकांश को अवशोषित करता है: रूटिंग लॉजिक events + triggers (कोई हैंड-रोल्ड राउटर नहीं) बन जाता है; handoff अनुबंध event schemas बन जाते हैं (Pydantic models SDK द्वारा मान्य); एकीकरण विफलताएं replay उम्मीदवार बन जाती हैं (काम नहीं खोया); per-specialist cost ट्रैकिंग प्रति-function dashboard मेट्रिक्स बन जाती है।
• मात्राबद्ध बचत। Inngest के बिना multi-agent system के लिए आमतौर पर आवश्यकता होती है:
  • एक कस्टम रूटिंग/प्रेषण परत (~500-2000 कोड की पंक्तियाँ)
  • एक कस्टम retry/dead-letter हैंडलर (~200-1000 लाइनें)
  • टाइमआउट के साथ एक कस्टम HITL अनुमोदन queue (~500-1500 लाइनें)
  • Per-tenant दर सीमित (~300-800 लाइनें)
  • कस्टम replay/रिकवरी toolिंग (~500-2000 लाइनें)

एक साथ: परिचालन-लिफाफा कोड की 2,000-7,000 लाइनें जिनका परीक्षण, डिबग और रखरखाव किया जाना चाहिए। Inngest के साथ, यह trigger घोषणाओं और step.run कॉलों की ~50-200 लाइनें बन जाती हैं। एक production multi-agent system के जीवनकाल में कुल-cost अंतर यौगिक होता है।

• तीन-scoreboard observability रहते हैं। eval suite की per-specialist गुणवत्ता, रूटिंग सटीकता, और एकीकरण गुणवत्ता scoreboards (संकल्पना 13 के eval signals से) अभी भी लागू होती है; Inngest का संरचित traces OTel के माध्यम से Phoenix में प्रवाहित होता है, इसलिए eval अनुशासन नहीं बदलता है।

cloud deployment की "per-specialist traceिंग, रूटिंग ऑडिट logs, cost ट्रैकिंग प्रति specialist" आवश्यकता आंशिक रूप से Inngest द्वारा अवशोषित की जाती है। आपको अभी भी एप्लिकेशन-स्तरीय traces (Phoenix) की आवश्यकता है, लेकिन ऑडिट logs और cost ट्रैकिंग बन जाती है। functions-of-function-runs Inngest dashboard में। संरचना है: रन-लेवल ऑपरेशनल डेटा के लिए Inngest, trace-लेवल मूल्यांकन डेटा के लिए Phoenix, एप्लिकेशन-लेवल ऑडिट के लिए नियॉन। तीन परतें, प्रत्येक के पास वह है जो वह सबसे अच्छा करता है।

_अवधारणा की निचली पंक्ति 13: multi-agent specialist सिस्टम पूर्ण cloud stack प्लस per-specialist traceिंग, रूटिंग ऑडिट logs, और cost-per-specialist ट्रैकिंग का उपयोग करते हैं। मूल्यांकन अनुशासन के लिए तीन अलग-अलग scoreboards (specialist गुणवत्ता, रूटिंग सटीकता, एकीकरण गुणवत्ता) की आवश्यकता होती है क्योंकि समग्र स्कोर छिपाते हैं कि कौन सी परत विफल रही। Coordination overhead सबसे कम अनुमानित cost है; कठोर per-specialist उपकरण के बिना, debugging सिंगल-agent debugging की तुलना में कहीं अधिक कठिन और धीमा है।

भाग 3. के बाद AI के साथ प्रयास करें आपने देखा है कि costs से deploy तक प्रत्येक pattern क्या है और प्रत्येक कैसे विफल रहता है। इसे उस pattern के लिए ठोस बनाएं जिस तक आप वास्तव में पहुंचेंगे। अपना क्लाउड कोड या ओपनकोड सत्र खोलें और पेस्ट करें:

"agentic pattern चुनें, मुझे अगले build की सबसे अधिक संभावना है (sequential workflow, single agent के साथ ReAct और tools, planning के साथ ReAct, या एक multi-agent specialist system)। उस pattern के लिए, मुझे दो चीजों के बारे में बताएं। सबसे पहले, deployment topology: इसे किन घटकों की आवश्यकता है (HTTP सेवा, durable state, file storage, sandboxed code execution, पृष्ठभूमि workers, trace observability) और यह किसे छोड़ सकता है? दूसरा, एकल failure signal जिसे मुझे production में सबसे पहले देखना चाहिए, और architecture को बदलने से पहले प्रयास करने के लिए विशिष्ट सस्ता समाधान। मेरे pattern के बारे में ठोस रहें, सामान्य नहीं।"

आप क्या सीख रहे हैं। एक pattern का चुनाव तब तक वास्तविक नहीं है जब तक आप यह नहीं बता सकते कि इसे क्या चलाना है costs और आपको कैसे पता चलेगा कि यह टूट गया है। यह आपके द्वारा पढ़ी गई किसी चीज़ की deployment-और-इवल रचना को किसी ऐसी चीज़ में बदल देता है जिसे आप व्हाइटबोर्ड पर स्केच कर सकते हैं।

---

भाग 4: Failure signals और pattern संशोधन

आपने एक आरंभिक pattern चुना है. सिस्टम runs। आपको क्या बताता है कि pattern गलत था, और आपको इसके बारे में क्या करना चाहिए? भाग 4 में Bala Priya C के लेख से पांच विशेषता failure signals को शामिल किया गया है, जो आपके eval suite से विशिष्ट eval और observability संकेतों के लिए मैप किया गया है, लक्षित सुधारों के साथ जिन्हें architecture को छोड़ने की आवश्यकता नहीं है।

संकल्पना 14: पांच failure signals (और प्रत्येक का क्या अर्थ है)

लेख पांच runtime लक्षणों की पहचान करता है जो pattern-task बेमेल का संकेत देते हैं। प्रत्येक की एक विशिष्ट आकृति होती है, जिसे आप एक बार दो बार देखने के बाद तुरंत पहचान सकते हैं।

सिग्नल 1: ReAct loops या हल किए गए कार्य को दोबारा देखता है। agent एक ही arguments के साथ एक ही बार में एक ही arguments को कई बार कॉल करता है। या यह आंशिक आउटपुट उत्पन्न करता है, फिर उन्हें स्क्रैच से पुनः प्राप्त करता है। pattern में संरचना या stop conditions गायब है। agent के पास यह जानने का कोई तरीका नहीं है कि यह पूरा हो गया है।

यह observability में कहां दिखाई देता है: trace-लंबाई विसंगतियां (रन ने 40 कदम उठाए जब अधिकांश runs 15 लेते हैं); डुप्लिकेट-tool-कॉल pattern (उसी customer_lookup को पांच बार कॉल किया गया); तर्क-loop संकेत (model का तर्क पाठ "मुझे इसे फिर से आज़माने दें" या समकक्ष दिखाता है)।

संभावित अर्थ, आवृत्ति के क्रम में:

• agent का prompt यह परिभाषित नहीं करता कि कार्य कब "पूरा" हो गया है
• Tool अनुबंध ढीले हैं (एकाधिक tools संभवतः एक ही कार्य कर सकते हैं; agent उनके बीच दोलन करता है)
• task को वास्तव में planning की आवश्यकता थी (Q3 को हाँ होना चाहिए था)

सिग्नल 2, Planner एक योजना बनाता है लेकिन निष्पादन अलग हो जाता है। योजना कहती है "स्टेज 1: अनुसंधान; स्टेज 2: ड्राफ्ट; स्टेज 3: समीक्षा।" निष्पादन चरण 1, करता है, फिर चरण 3, पर जाता है, फिर चरण 2. पर वापस आता है या निष्पादन चरण जोड़ता है, जिसमें planner शामिल नहीं है। task अनुमानित planning दांव से कम पूर्वानुमानित था।

यह observability में कहां दिखाई देता है: योजना-निष्पादन विचलन मीट्रिक (योजनाबद्ध चरणों और निष्पादित चरणों के बीच संपादन दूरी की गणना करें); सिग्नलों को पुनः व्यवस्थित करना (चरण dependency ऑर्डर से बाहर हो जाते हैं); सम्मिलित-चरण संकेत (निष्पादन में वे चरण शामिल हैं जो योजना में नहीं हैं)।

संभावित अर्थ, आवृत्ति के क्रम में:

• task की संरचना आंशिक रूप से स्पष्ट है, पूरी तरह से नहीं, planner प्रमुख चरणों की सही पहचान करता है लेकिन अनुकूली उप-चरणों को याद करता है (लाइटवेट planning का उपयोग करें)
• planner का प्रशिक्षण इस task के डोमेन से मेल नहीं खाता (डोमेन उदाहरणों के साथ planning prompt में सुधार करें)
• task में वास्तव में स्पष्ट संरचना नहीं है (Q3 नहीं होना चाहिए था; शुद्ध ReAct में डाउनग्रेड करें)

सिग्नल 3, Reflection उत्तर में सुधार नहीं करता है। समालोचना runs को पास करती है, आलोचना उत्पन्न करती है, agent परिष्कृत करती है, और परिष्कृत आउटपुट मूल से अप्रभेद्य होता है। या परिष्कृत आउटपुट बदतर है. reflection दांव विफल हो रहा है: या तो criteria अस्पष्ट हैं, या critic और generator ब्लाइंड स्पॉट साझा करते हैं, या दोनों।

यह observability में कहां दिखाई देता है: पूर्व/बाद-reflection तुलना स्कोर (यदि वे सांख्यिकीय रूप से अप्रभेद्य हैं, तो reflection काम नहीं कर रहा है); मानदंड-फायरिंग दरें (कौन सा criteria trigger शोधन? यदि हमेशा एक ही है, तो मानदंड ही एकमात्र उपयोगी है); critic-generator समझौता दर (यदि critic लगभग हमेशा पास हो जाता है, तो यह rubber-stamping है)।

संभावित अर्थ, आवृत्ति के क्रम में:

• Criteria परिशोधन को चलाने के लिए बहुत अस्पष्ट हैं (उन्हें अधिक विशिष्ट और जांच योग्य बनाएं)
• Critic और generator समान prompts के साथ एक ही model हैं (एक अलग model या मौलिक रूप से अलग critic फ़्रेमिंग का उपयोग करें)
• task को वास्तव में reflection की आवश्यकता नहीं थी (Q4 नहीं होनी चाहिए थी, गुणवत्ता मायने रख सकती है, लेकिन criteria जांच योग्य नहीं है)

सिग्नल 4, Multi-agent रूटिंग विफल। coordinator task को गलत specialist पर भेजता है। या दो specialists परस्पर विरोधी आउटपुट उत्पन्न करते हैं जिनका एग्रीगेटर समाधान नहीं कर सकता। या specialists के बीच handoff महत्वपूर्ण जानकारी खो देता है। coordination overhead काम पर हावी हो रहा है।

यह observability में कहां दिखाई देता है: रूटिंग सटीकता मीट्रिक (coordinator के रूटिंग निर्णयों की गोल्डन-डेटासेट लेबल से तुलना करें); handoff-पूर्णता संकेत (specialist B का इनपुट specialist A के आउटपुट से महत्वपूर्ण सामग्री को संदर्भित नहीं करता है); एकीकरण-विफलता दर (specialists व्यक्तिगत रूप से पास, शुरू से अंत तक विफल)।

संभावित अर्थ, आवृत्ति के क्रम में:

• specialists' भूमिकाएँ ओवरलैप होती हैं (सीमाओं को स्पष्ट करें; ओवरलैपिंग को merge करें specialists)
• Handoff अनुबंध अंतर्निहित हैं (उन्हें स्पष्ट करें; संरचित handoff प्रारूपों की आवश्यकता है)
• task को वास्तव में multi-agent की आवश्यकता नहीं थी (Q5 को नहीं होना चाहिए था; single agent को संक्षिप्त करें)

सिग्नल eval signal सिस्टम जटिल लगता है लेकिन बेहतर नहीं। निदान करना सबसे कठिन है क्योंकि कोई भी eval signal इसे पकड़ नहीं पाता है। architecture में कई परतें हैं (planning + reflection + multi-agent, मान लीजिए), लेकिन आउटपुट गुणवत्ता एक सरल आधार रेखा से बेहतर नहीं है। architecture एक सौंदर्य संबंधी समस्या का समाधान कर रहा है, न कि task bottleneck.

यह observability में कहां दिखाई देता है: कोई एकल observability सिग्नल नहीं है। पता लगाने के लिए आधारभूत तुलना की आवश्यकता होती है: उसी task (single agent + ReAct + tools, कोई reflection, कोई multi-agent) का एक सरल संस्करण लागू करें और golden dataset पर इसकी गुणवत्ता को मापें। यदि सरल संस्करण जटिल संस्करण के लगभग 10% के भीतर प्रदर्शन करता है, तो जटिल architecture अपना cost अर्जित नहीं कर रहा है।

संभावित अर्थ, लगभग सभी मामलों में:

• टीम ने यह परीक्षण किए बिना pattern स्तरित किए कि क्या प्रत्येक परत उचित थी, overshoot कई निर्णयों में जमा हुआ

अवधारणा की निचली पंक्ति 14: पांच विशेषताएँ failure signals pattern-task बेमेल दर्शाती हैं: ReAct loops/पुनरीक्षण (लापता संरचना), योजना-निष्पादन विचलन (overstructured), reflection में सुधार नहीं हो रहा है (अस्पष्ट criteria), multi-agent रूटिंग विफलताएं (overpartitioned), सिस्टम-महसूस-जटिल-लेकिन-बेहतर नहीं (संचयी overshoot)। प्रत्येक सिग्नल की एक विशिष्ट observability आकृति होती है। सिग्नल को पहचानना पहला कदम है; समाधान हमेशा architectural नहीं होता है, कभी-कभी यह prompt सख्ती या अनुबंध स्पष्टीकरण होता है।

संकल्पना 15: लक्षित सुधार जिनके लिए architecture को छोड़ने की आवश्यकता नहीं है

failure signal को पहचानने का मतलब हमेशा architecture को दोबारा लिखना नहीं होता है। अधिकांश सुधार prompt, अनुबंध, या उपकरण स्तर पर हैं, न कि architectural स्तर पर। यह अवधारणा प्रत्येक सिग्नल को फिक्स-पहले सबसे सस्ते विकल्प पर मैप करती है।

संकेत	सबसे पहले प्रयास करने योग्य सबसे सस्ता उपाय	यदि वह काम नहीं करता है	Architectural परिवर्तन आवश्यक है
ReAct loops/पुनरीक्षण	स्पष्ट stop conditions जोड़ें ("आपने task पूरा कर लिया है जब...") और tool सीमाएं ("उद्देश्य Y के लिए X का उपयोग करें; Z के लिए X का उपयोग न करें")	tool अनुबंधों में सुधार करें (बेहतर विवरण, स्पष्ट return प्रकार)	planning परत जोड़ें (संकल्पना 11 के pattern में अपग्रेड करें)
योजना-निष्पादन विचलन	हल्के planning पर स्विच करें (कम, व्यापक चरण)	डोमेन-विशिष्ट उदाहरणों के साथ planner prompt में सुधार करें	शुद्ध ReAct में डाउनग्रेड करें (संकल्पना 10)
Reflection में सुधार नहीं हो रहा है	criteria को अधिक विशिष्ट और जांच योग्य बनाएं (संख्यात्मक सीमाएँ, schema validation, स्पष्ट नियम)	critic के लिए एक अलग model का उपयोग करें; या स्पष्ट जाँच tools (पार्सर, सत्यापनकर्ता) का उपयोग करें	यदि कोई सुधार नहीं होता है तो reflection को पूरी तरह से हटा दें
Multi-agent रूटिंग विफल	ज्ञात मामलों के लिए LLM-आधारित से coordinator को नियतात्मक रूटिंग पर स्विच करें	handoff अनुबंधों को स्पष्ट और संरचित बनाएं (Pydantic models, मुक्त-पाठ नहीं)	ओवरलैपिंग merge करें specialists; यदि Q5 वास्तव में पकड़ में नहीं आता है तो single agent पर संक्षिप्त करें
जटिल-लेकिन-बेहतर नहीं	सबसे ऊपरी परत (सबसे हाल ही में जोड़ा गया pattern) हटाएं और मापें	अगली परत ऊपर हटा दें; पुनरावृत्त करना	मजबूत आधार रेखा के साथ Return से single agent तक; केवल साक्ष्य के साथ पुनर्निर्माण करें

सिद्धांत: सबसे छोटे दायरे में ठीक करें जो काम करता है। Prompt कसना tool-अनुबंध परिवर्तन से सस्ता है। Tool-अनुबंध परिवर्तन architectural परिवर्तनों से सस्ते हैं। Architectural परिवर्तन पुनर्लेखन की तुलना में सस्ते हैं। अधिकांश failure signals को prompt या अनुबंध स्तर पर संबोधित किया जा सकता है, पहले architecture नॉब तक न पहुंचें।

अपवाद: यदि prompt के बाद failure signal की पुनरावृत्ति होती है और अनुबंध ठीक हो जाता है, तो यह सबूत है कि architecture वास्तव में गलत है। "मैं इसे पैच करता रह सकता हूं" को "मैं इसे पैच करता रहता हूं और यह नए तरीकों से विफल होता रहता है" से अंतर बताएं। बाद वाला pattern selection को फिर से देखने का संकेत है।

संकल्पना की निचली पंक्ति 15: failure signals को हमेशा architectural परिवर्तनों की आवश्यकता नहीं होती है। अधिकांश को prompt स्तर (stop conditions, criteria विनिर्देश, भूमिका सीमाएं) या अनुबंध स्तर (tool विवरण, handoff संरचनाएं, रूटिंग लॉजिक) पर तय किया जा सकता है। Architectural परिवर्तन अंतिम उपाय है, पहला कदम नहीं। अपवाद: prompt और अनुबंध सुधारों के बाद बार-बार होने वाली विफलताएं इंगित करती हैं कि pattern स्वयं गलत है; तभी decision tree पर दोबारा चलना है।

संकल्पना 16: जब decision tree गलत है

decision tree अच्छा है. यह अचूक नहीं है. तीन स्थितियाँ जहाँ पेड़ का पहला उत्तर गलत है, और क्या करें:

स्थिति 1, Task गुण deployment के बाद बदल जाते हैं। जो स्थिर workflow था वह अनुकूली हो जाता है (व्यवसाय 20 edge मामले जोड़ता है)। जो विशिष्ट विशेषज्ञता थी वह वस्तु बन जाती है (LLM बेहतर हो जाती है और एक सामान्य विशेषज्ञ अब उस कार्य को संभाल सकता है जिसके लिए specialist की आवश्यकता होती है)। वास्तविक उदाहरण: एक customer-support workflow जो अनुक्रमिक pipeline (अर्क → वर्गीकृत → मार्ग → प्रतिक्रिया) के रूप में शुरू हुआ, एक बार टीम द्वारा वैयक्तिकरण, इतिहास-जागरूकता और टोन-मिलान जोड़ने के बाद अनुकूली हो जाता है। मूल pattern अब गलत है, लेकिन सिस्टम production में है।

समाधान: कॉन्सेप्ट 14 से विफलता-संकेत observability को इसे पकड़ना चाहिए। जब workflow पथ विफल होने लगते हैं क्योंकि वास्तविक इनपुट अब workflow के अपेक्षित आकार से मेल नहीं खाते हैं, तो यह संकेत है। नई task संपत्तियों के साथ decision tree पर फिर से चलें। यह दिखावा न करें कि मूल विकल्प अभी भी सही है क्योंकि इसे ही तैनात किया गया है।

स्थिति 2, अलग-अलग sub-tasks को अलग-अलग pattern की आवश्यकता होती है। Maya के Tier-1 Support agent रूटिंग, लुकअप, रिफंड, एस्केलेशन को संभालते हैं। कुछ workflow-आकार के हैं (लुकअप: नियतात्मक)। कुछ ReAct-आकार के हैं (refund जांच: अनुकूली)। एकल-agent ReAct pattern उन सभी को संभालता है, लेकिन अच्छी तरह से नहीं बल्कि पर्याप्त रूप से। समाधान: पहचानें कि यह एक बहु-pattern composition अवसर है। pattern-विशिष्ट उप-प्रणालियों के लिए एक शीर्ष-स्तरीय coordinator मार्ग: लुकअप के लिए sequential workflow, जांच के लिए ReAct + tools, जटिल बहु-चरणीय विवादों के लिए planning। संरचना multi-agent है, लेकिन specialists भूमिका-आधारित नहीं हैं, वे pattern-आधारित हैं।

स्थिति 3, बाधाएं उत्तर बदल देती हैं। decision tree मानता है कि आप जो भी pattern फिट बैठता है उसे चुन सकते हैं। कभी-कभी आप नहीं कर सकते। कठिन latency budget reflection को खारिज करता है। कठिन cost बजट multi-agent को खारिज करता है। कठोर सरलता आवश्यकता planning को खारिज करती है। जब बाधाएं उस pattern को बाहर कर देती हैं जिसे पेड़ चुनता है, तो आपको या तो बाधाओं को बदलना होगा, task दायरे को बदलना होगा, या बदतर फिट को स्वीकार करना होगा।

ठीक: एक अलग निर्णय के रूप में बाधा-संचालित pattern विकल्पों को स्पष्ट रूप से ट्रैक करें। दस्तावेज़: "decision tree ने multi-agent की ओर इशारा किया, लेकिन हमने एकल-agent को चुना क्योंकि cost सीमा के लिए इसकी आवश्यकता थी। ज्ञात सीमा: विशेषज्ञता-संचालित विफलताएँ अधिक सामान्य होंगी।" यह बाधा-संचालित विकल्प को दृश्यमान और पुनरीक्षित बनाता है, जब बाधाएं बदलती हैं, तो आप जानते हैं कि किस पर पुनर्विचार करना है।

संकल्पना की निचली पंक्ति 16: decision tree एक प्रारंभिक बिंदु है, स्थायी उत्तर नहीं। तीन स्थितियों में पेड़ पर दोबारा गौर करने की आवश्यकता होती है, deployment के बाद task गुण बदल जाते हैं (विफलता-सिग्नल observability के माध्यम से पकड़ते हैं), अलग-अलग sub-tasks को अलग-अलग pattern की आवश्यकता होती है (एकाधिक pattern बनाते हैं), और बाधाएं पेड़ के उत्तर को बाहर कर देती हैं (बाधा-संचालित विकल्प को स्पष्ट रूप से दस्तावेज़ित करें)। Pattern selection पुनरावृत्तीय है, एक-शॉट नहीं।

संकल्पना 16.5: anti-pattern गैलरी, सामान्य गलत विकल्प और इसके बजाय क्या करना है

भाग 5 सही pattern selection के worked examples दिखाता है। उससे पहले उलटा देखें: common wrong choices की एक quick gallery और हर choice का बेहतर alternative। anti-patterns को पहचानना अपने-आप में skill है: जो students decision tree को internalize कर लेते हैं, वे भी pattern-overshoot या pattern-undershoot में पड़ सकते हैं जब architectural temptation strong हो।

दृश्य विषमता, 5 overshoot anti-patterns बनाम 3 undershoot, production सिस्टम में वास्तविक आवृत्ति को दर्शाता है। Overshoot अधिक दृश्यमान है क्योंकि विस्तृत pattern बेहतर डेमो बनाते हैं; undershoot अधिक खतरनाक है क्योंकि विफलता मोड सूक्ष्म हैं। डिज़ाइन-समीक्षा के समय दोनों समान रूप से ध्यान देने योग्य हैं। नीचे दी गई तालिका गैलरी का पूरा पाठ देती है:

ख़राब चुनाव	यह विफल क्यों होता है	बेहतर आरंभिक pattern
Multi-agent सरल सामग्री निर्माण के लिए (उदाहरण के लिए, तीन agents, researcher + writer + reviewer, एक LinkedIn पोस्ट के लिए)	Coordination overhead विशेषज्ञता लाभ से काफी अधिक है। "researcher" आउटपुट एक पैराग्राफ है जिसे "writer" सारांशित करता है। रूटिंग विफलताएं, handoff प्रारूप बेमेल, कोई मापने योग्य गुणवत्ता सुधार के लिए tokens से तीन गुना अधिक।	Single agent + ReAct + tools (अवधारणा 10), या sequential workflow (अवधारणा 9) यदि सामग्री का आकार निश्चित है। multi-agent के लिए तभी पहुंचें जब Q5 वास्तव में सक्रिय हो।
ReAct निश्चित invoice processing के लिए (निकालें → मान्य करें → स्टोर करें → सूचित करें)	agent कभी-कभी चरणों को छोड़ देता है, कभी-कभी पहले से किए गए कार्य को पुनः सत्यापित करता है, कभी-कभी tool calls का आविष्कार करता है। runs के 5% में चरण-बजट की समाप्ति। टीम prompt में "stop conditions" जोड़ती है, जो architectural बेमेल के बजाय लक्षणों का इलाज करती है।	Sequential workflow (संकल्पना 9)। पथ ज्ञात और स्थिर है; एक LLM-driven loop गलत tool है।
Planner ओपन-एंडेड debugging के लिए (planner एक 5-चरण योजना तैयार करता है; निष्पादन तुरंत अलग हो जाता है)	task की संरचना पहले से स्पष्ट नहीं है। planner एक योजना तैयार करता है जो चरण 2. योजना-निष्पादन विचलन trace पर हावी हो जाती है। टीम या तो planner को अंतहीन रूप से कसती है या योजना को सजावटी मानती है।	Single agent + ReAct + tools (अवधारणा 10)। शुद्ध ReAct उन कार्यों को संभालता है जहां आकार और सामग्री अज्ञात हैं।
Reflection अस्पष्ट गुणवत्ता वाले कार्यों पर criteria (marketing copy, संवादी responses, व्यक्तिपरक सामग्री)	critic और generator ब्लाइंड स्पॉट साझा करते हैं। आलोचना rubber-stamping बन जाती है। Latency दोगुना; गुणवत्ता स्थिर रहती है. इससे भी बदतर: टीम को झूठा विश्वास हो गया कि "AI ने इसकी जाँच की है।"	या तो reflection को पूरी तरह से हटा दें (सबसे सामान्य सही उत्तर) या LLM reflection को मानव समीक्षा से बदलें (संकल्पना 12)। LLM reflection केवल checkable criteria पर काम करता है।
कई डोमेन के लिए एक विशाल agent (billing + तकनीकी + account + refund + sales, सभी एक agent में एक 4,000-token सिस्टम prompt के साथ)	Context overflow, role confusion, tool-रूटिंग त्रुटियां तेजी से बढ़ती हैं। Reflection मामूली मदद करता है लेकिन मूल कारण को ठीक नहीं करता है। agent billing नीति के साथ तकनीकी प्रश्नों का उत्तर देता है और इसके विपरीत।	Multi-agent specialist system (संकल्पना 13), specialists प्रति डोमेन, coordinator इरादे वर्गीकरण द्वारा मार्ग। Q5 की विशेषज्ञता का दावा वास्तव में यहां काम करता है।
planning को स्थिर workflow में जोड़ना (planner हर बार एक ही योजना बनाता है क्योंकि task वही है)	प्रत्येक रन एक अतिरिक्त LLM कॉल के लिए भुगतान करता है जिसका कोई योगदान नहीं होता। जब इनपुट थोड़ा असामान्य होता है, तो planner थोड़ा अलग योजना तैयार करता है, और अब टीम को डीबग करना होगा "planner ने एक अलग रास्ता क्यों अपनाया?"	Sequential workflow (संकल्पना 9)। जब पथ तय हो जाता है, तो planning की आवश्यकता नहीं होती है, पथ को सीधे लिखें।
बड़े पैमाने पर context की आवश्यकता वाले कार्यों के लिए शुद्ध एकल-agent (एक agent लोड हो रहा है 20 स्रोत दस्तावेज़, तीन ज्ञान आधार, और एक database schema इसके prompt में)	Context window अवनति। जैसे-जैसे context बढ़ता है, agent का तर्क कमजोर होता जाता है; model उन चीजों को मिस करता है जिनके बारे में आप कसम खाते हैं कि इसे देखना चाहिए।	Multi-agent specialist system केंद्रित संदर्भों के साथ (संकल्पना 13)। प्रत्येक specialist केवल वही context लोड करता है जिसकी उसे आवश्यकता होती है; synthesizer उनके आउटपुट तैयार करता है। Q5 का context दावा वास्तव में यहां लागू होता है।
उन आउटपुट पर reflection को छोड़ना जिन्हें वास्तव में सत्यापन की आवश्यकता है (SQL queries से production, कानूनी ड्राफ्ट से clients, कोड रेपो में बदल जाता है)	सूक्ष्म त्रुटियाँ ship। टीम तथ्य के बाद परीक्षण जोड़ती है, जो पीढ़ी के समय में त्रुटियों को पकड़ने की तुलना में कम त्रुटियों को पकड़ती है।	कोर pattern के शीर्ष पर Reflection layer (संकल्पना 12)। जब criteria जाँच योग्य होते हैं, तो reflection वास्तव में मूल्यवान होता है। Q4 आग; इसे छोड़ें नहीं.

anti-pattern गैलरी में pattern: सबसे खराब विकल्प pattern हैं-overshoot सौंदर्य अपील द्वारा संचालित (multi-agent प्रभावशाली दिखता है, planning कठोर दिखता है, reflection सावधान दिखता है)। एक छोटा लेकिन समान रूप से महत्वपूर्ण उपसमुच्चय है pattern-undershoot जो सादगी पूर्वाग्रह से प्रेरित है (एक बड़ा agent, workflow कार्यों पर शुद्ध ReAct, चेक करने योग्य आउटपुट पर कोई reflection नहीं)। decision tree को दोनों प्रकार की गलतियों को सामने लाने के लिए डिज़ाइन किया गया है: pattern प्राथमिकताओं के बजाय task गुणों के बारे में पूछकर।

एक pattern विकल्प को लॉक करने से पहले एक उपयोगी स्व-जांच: "यदि एक वरिष्ठ इंजीनियर ने मेरी पसंद की समीक्षा की, तो वे सबसे अधिक संभावित आपत्ति क्या उठाएंगे?" यदि आप आपत्ति के खिलाफ भविष्यवाणी और बचाव नहीं कर सकते हैं, तो संभवतः आपने अभी तक कोई सैद्धांतिक विकल्प नहीं बनाया है।

संकल्पना की निचली पंक्ति 16.5: pattern selection overshoot (आवश्यकता से अधिक विस्तृत) के माध्यम से सबसे अधिक बार विफल होती है और कम बार लेकिन undershoot (आवश्यकता से अधिक सरल) के माध्यम से समान रूप से हानिकारक होती है। anti-pattern गैलरी दोनों विफलता मोड के सबसे सामान्य आकार का नाम देती है। इन्हें आंतरिक बनाने से decision tree के अनुशासन में तेजी आती है; अपने स्वयं के ड्राफ्ट architecture में anti-pattern को पहचानना framework द्वारा निर्मित व्यावहारिक कौशल है। इस कोर्स के अंत में एक-पेज डिज़ाइन-समीक्षा टेम्पलेट देखें। इसमें एक स्पष्ट anti-pattern चेक शामिल है ("यदि एक वरिष्ठ इंजीनियर ने इस विकल्प की समीक्षा की, तो वे object को क्या करेंगे?") जो टीम डिज़ाइन समीक्षाओं के लिए इस अनुशासन को संचालित करता है।

---

भाग 5: decision lab

भाग 5 पांच वास्तविक कार्यों पर decision tree चलता है। प्रत्येक निर्णय एक सुव्यवस्थित वर्गीकरण है: task, उत्तर दिए गए पांच प्रश्न, परिणामी pattern, deployment topology स्केच, और देखने के लिए eval signals। बात सही उत्तर की नहीं है; यह अनुशासन को लागू होता देख रहा है।

प्रत्येक निर्णय एक ही आकार का अनुसरण करता है:

• task (एक पैराग्राफ)
• पेड़ पर चलना (पांच प्रश्नों के उत्तर task-विशिष्ट तर्क के साथ दिए गए)
• pattern चयन और औचित्य
• Deployment topology स्केच (कौन से cloud घटक, नियॉन में कौन सी नई तालिकाएँ, कौन सा ब्रिज-Worker कॉन्फ़िगरेशन)
• Eval signals देखने के लिए (कौन से pattern का मूल्यांकन करते हैं, कौन से Phoenix मूल्यांकनकर्ता)
• सिम्युलेटेड ट्रैक कॉलआउट उन पाठकों के लिए जिन्होंने deployment और eval पाठ्यक्रम नहीं किए हैं

निर्णय 1: Maya का Tier-1 Support agent

task. एक customer-support agent आने वाले queries को संभालता है। agent: account जानकारी देख सकता है, लेन-देन इतिहास देख सकता है, नीति नियम देख सकता है, ज्ञान का आधार खोज सकता है, प्राधिकरण सीमा के भीतर रिफंड जारी कर सकता है, अधिकार सीमा पार होने पर या मामला अस्पष्ट होने पर human review तक बढ़ सकता है। agent ग्राहक के साथ संवादात्मक संपर्क बनाए रखता है।

आपकी बारी। आगे पढ़ने से पहले इस task पर पाँच प्रश्न पढ़ें। एक pattern के प्रति प्रतिबद्ध रहें, फिर स्वयं को कार्यान्वित उत्तर से जांचें। (या task को अपने AI में पेस्ट करें और यह आपसे Q1 से Q5 तक प्रश्नोत्तरी कराए, जब आपका तर्क कमजोर हो तो उसे पीछे धकेलें।)

पहले इसे स्वयं चलाएं, फिर कार्यान्वित उत्तर खोलें।

पेड़ पर चलना।

Q1: क्या solution path को पहले से परिभाषित किया जा सकता है? नहीं। ग्राहक queries बहुत भिन्न होता है: "मेरा refund कहां है?" खोज की आवश्यकता है; "मुझ पर दो बार आरोप लगाए गए" की जांच की आवश्यकता है; "मैं रद्द करना चाहता हूं" के लिए account परिवर्तनों की आवश्यकता हो सकती है; "क्या आप मेरे बिल की व्याख्या कर सकते हैं" के लिए नीति खोज और स्पष्टीकरण की आवश्यकता है। रास्ता अज्ञात है.

Q2: N/A (Q1 नहीं था, इसलिए Q2 छोड़ें)।

Q3: क्या निष्पादन से पहले task structure व्यक्त किया जा सकता है? नहीं। कोई व्यक्त करने योग्य "चरण" नहीं हैं; ऐसी जांच है जो पूरी होने पर पूरी होती है। agent एक लुकअप और प्रतिक्रिया दे सकता है, या पांच लुकअप और तीन नीति जांच कर सकता है। कोई स्पष्ट मंच संरचना नहीं.

Q4: क्या गुणवत्ता गति से अधिक मायने रखती है? मिश्रित। गति मायने रखती है क्योंकि ग्राहक लाइव वार्तालाप की प्रतीक्षा कर रहे हैं; गुणवत्ता मायने रखती है क्योंकि ग़लत refund निर्णय व्यवसाय का पैसा cost करते हैं। लेकिन "अच्छे response" के लिए criteria का मूल्यांकन वास्तविक समय में जांचने योग्य नहीं है। उनमें इस बारे में सूक्ष्म निर्णय शामिल होता है कि ग्राहक की स्थिति को अच्छी तरह से संभाला गया था या नहीं। प्रतिबिंब यहाँ फिट नहीं बैठता।

Q5: क्या कोई विशेषज्ञता है, context, या स्केल bottleneck? बॉर्डरलाइन। agent को billing, तकनीकी, account, और refund मुद्दों को संभालने की आवश्यकता है, जो विशेषज्ञता के मामले की तरह लगता है। लेकिन: ओवरलैप की मात्रा (अधिकांश ग्राहकों के पास श्रेणियों में फैले प्रश्न हैं) का मतलब है कि specialist रूटिंग विशेषज्ञता लाभ की तुलना में अधिक handoff घर्षण पैदा करेगी। सिंगल agent सही कॉल है।

pattern चयन: Single agent + ReAct + tools। अवधारणाएँ 10 का pattern।

Deployment topology स्केच। यह बिल्कुल वही है जो customer-support Worker के cloud deployment ने बनाया है। पूर्ण stack: ACA पर FastAPI, sessions के लिए नियॉन, runs, और traces, किसी भी संलग्न दस्तावेज़ के लिए R2, apply_patch के लिए bridge Worker के माध्यम से Cloudflare Sandbox tool agent कभी-कभी refund-दस्तावेज़ीकरण फ़ाइलें उत्पन्न करने के लिए उपयोग करता है, runs के लिए background worker वह 30 सेकंड से अधिक है। deployment द्वारा भेजे जाने वाले जहाज़ की तुलना में कोई deployment परिवर्तन नहीं होता।

Eval signals देखने लायक। ReAct की विशिष्ट विफलताएँ:

• Trace-लंबाई विसंगतियाँ (Phoenix dashboard)
• Tool-कॉल दोहराव (agent एक ही account को तीन बार देख रहा है)
• तर्क-क्रिया विचलन (Phoenix tool-शुद्धता मूल्यांकनकर्ता)
• समय से पहले समाप्ति (agent कहता है "मैं मदद नहीं कर सकता" बहुत जल्दी)
• चरण-बजट थकावट (आउटपुट उत्पन्न किए बिना agent loops पिछले 25 चरण)

production में सबसे संभावित विफलता मोड: agent अस्पष्ट refund मामलों पर loop करेगा। समाधान: स्पष्ट stop conditions जोड़ें ("यदि आप 3 लुकअप के भीतर सही refund राशि निर्धारित नहीं कर सकते, तो आगे बढ़ें") और "आगे जांच करें" और "मानव तक बढ़ें" के बीच की सीमा को स्पष्ट करें।

Operational envelope. Maya का सेटअप customer-support agent के लिए विहित Inngest रचना है:

• Trigger: TriggerEvent(event="customer/email.received"), ईमेल-अंतर्ग्रहण webhook event को सक्रिय करता है; function प्रत्येक ग्राहक ईमेल के लिए सक्रिय होता है।
• स्थायित्व: Runner.run(support_agent, ...) को एक step.run("agent-loop", ...) में लपेटें। loop के बीच में क्रैश → संपूर्ण agent रन retries; loop के अंदर उप-चरण SDK-आंतरिक हैं और अलग से टिकाऊ नहीं हैं।
• HITL बढ़ने पर: escalate_to_human tool refund/approval.requested को फायर करता है और function step.wait_for_event के माध्यम से 4 घंटों तक निलंबित रहता है। प्रतीक्षा के दौरान शून्य compute खपत हुई। मानव Slack के माध्यम से अनुमोदन करता है; function फैसले के साथ फिर से शुरू होता है।
• Concurrency: concurrency=[Concurrency(limit=10, key="event.data.customer_id"), Concurrency(limit=50)], अधिकतम 2-3 समवर्ती runs प्रति ग्राहक (एक नाराज ग्राहक हर किसी को भूखा नहीं रख सकता) और 50 विश्व स्तर पर (OpenAI दर सीमा और नियॉन कनेक्शन पूल की सुरक्षा करता है)।

निर्णय 1. के लिए सिम्युलेटेड ट्रैक कॉलआउट deployment और eval पाठ्यक्रमों के बिना भी, आप इस अभ्यास को कागज पर कर सकते हैं: Maya के task के लिए पांच प्रश्नों पर चलें, pattern की पसंद को उचित ठहराएं, और स्केच करें कि tools को agent की क्या आवश्यकता होगी (account लुकअप, लेनदेन लुकअप, नीति खोज, refund जारी करना, वृद्धि)। वर्गीकरण अनुशासन वह है जो निर्णय 1 सिखाता है; deployment विशिष्टताएँ इसे गहरा करती हैं लेकिन framework को आंतरिक बनाने के लिए आवश्यक नहीं हैं।

निर्णय 2: Incident response agent

task। एक ऑन-कॉल agent को अलर्ट (निगरानी प्रणाली, ग्राहक रिपोर्ट, या आंतरिक टीमों से) और runs प्रारंभिक incident response प्राप्त होता है: सेवा स्वास्थ्य की जांच करें, हाल की तैनाती के साथ सहसंबंध करें, संभावित मूल कारण की पहचान करें, यदि लागू हो तो remediation रनबुक चलाएं, यदि स्थिति नई या गंभीर है तो मानव ऑन-कॉल को आगे बढ़ाएं। agent को एक स्पष्ट घटना रिपोर्ट प्रस्तुत करनी होगी।

आपकी बारी। आगे पढ़ने से पहले इस task पर पाँच प्रश्न पढ़ें। एक pattern के प्रति प्रतिबद्ध रहें, फिर स्वयं को कार्यान्वित उत्तर से जांचें। (या task को अपने AI में पेस्ट करें और यह आपसे Q1 से Q5 तक प्रश्नोत्तरी कराए, जब आपका तर्क कमजोर हो तो उसे पीछे धकेलें।)

पहले इसे स्वयं चलाएं, फिर कार्यान्वित उत्तर खोलें।

पेड़ पर चलना।

Q1: क्या solution path को पहले से परिभाषित किया जा सकता है? आंशिक रूप से। एक मानक संरचना है: "सेवा स्वास्थ्य की जांच करें, तैनाती को सहसंबंधित करें, कारण की पहचान करें, remediation का प्रयास करें, यदि आवश्यक हो तो आगे बढ़ाएं।" लेकिन विशिष्ट पथ इस बात पर निर्भर करता है कि वास्तव में क्या हो रहा है। सेवा A में latency स्पाइक से "हाल ही में deploy को रोलबैक" हो सकता है; सेवा बी में 500-त्रुटि स्पाइक के कारण "रीस्टार्ट पॉड" हो सकता है; ग्राहक द्वारा रिपोर्ट की गई समस्या के कारण "उपयोगकर्ता-विशिष्ट डेटा प्रवाह की जांच" हो सकती है। पथ चरण स्तर पर अज्ञात है लेकिन चरण स्तर पर संरचित है।

Q2: एन/ए.

Q3: क्या task structure को निष्पादन से पहले स्पष्ट किया जा सकता है? हाँ। चरण स्पष्ट हैं: परीक्षण → निदान → उपचार → रिपोर्ट। प्रत्येक घटना इन चरणों से होकर गुजरती है, भले ही प्रत्येक चरण के भीतर विशिष्ट कार्य भिन्न-भिन्न हो। आर्टिकुलेबल संरचना.

Q4: क्या गुणवत्ता गति से अधिक मायने रखती है? incident response के लिए, गति बहुत मायने रखती है: घटना के समय का हर मिनट costs व्यवसाय है। लेकिन गुणवत्ता भी मायने रखती है क्योंकि गलत remediation चीजों को बदतर बना सकता है। Reflection को क्रियान्वित करने से पहले remediation कदम उठाना उचित है। एक त्वरित आलोचना पास जो पूछता है "क्या यह remediation सुरक्षित है? क्या यह घटना के वास्तविक लक्षणों से मेल खाता है?" latency के लायक है। remediation निर्णयों पर reflection जोड़ें।

Q5: क्या कोई विशेषज्ञता है, context, या स्केल bottleneck? नहीं। मॉनिटरिंग, deploy इतिहास, रनबुक library और remediation tools तक पहुंच वाला एक agent इसे संभाल सकता है। अफ़प्रोटा__मत करो।

pattern चयन: Planning + ReAct execution, reflection के साथ remediation चरणों पर। अवधारणाएँ 11 + 12 स्तरित।

Deployment topology स्केच। ReAct के deployment (अवधारणा 10) प्लस योजना दृढ़ता (अवधारणा 11) पर निर्मित। विशिष्ट परिवर्धन:

• नई नियॉन तालिका: incidents (घटना_आईडी, गंभीरता, योजना, वर्तमान_चरण, निवारण_इतिहास)
• योजना को स्पष्ट रूप से संग्रहीत किया जाता है और चरण पूरा होने पर अद्यतन किया जाता है
• remediation पर Reflection एक अलग agent के रूप में (अलग-अलग model अनुशंसित, एक क्लाउड-इंस्टेंस जो GPT-इंस्टेंस की आलोचना करता है, या इसके विपरीत, ब्लाइंड-स्पॉट ओवरलैप से बचने के लिए)
• background worker pattern अनिवार्य है (घटना runs में 5-15 मिनट लग सकते हैं)

Eval signals देखने लायक।

• योजना-निष्पादन विचलन (क्या योजना वास्तव में जो हुआ उससे मेल खाती है?)
• remediation पर Reflection प्रभावशीलता (क्या समालोचना ने कोई असुरक्षित उपचार पकड़ा? यदि महीनों तक नहीं, तो reflection rubber-stamping हो सकता है)
• समय-से-रिज़ॉल्यूशन मीट्रिक (incident response को गति से आंका जाता है; प्रतिगमन पर ट्रैक और अलर्ट)
• वृद्धि सटीकता (क्या agent तब बढ़ी जब इसे बढ़ना चाहिए था? क्या इसने सुधार किया जब इसे होना चाहिए था?)

production में सबसे अधिक संभावित विफलता मोड: planner latency को जोड़कर, साधारण घटनाओं के लिए अत्यधिक विस्तृत योजनाएं तैयार करता है। _समाधान:planner को उपयुक्त योजना की विस्तृतता, स्पष्ट घटनाओं के लिए छोटी योजनाएँ, अस्पष्ट घटनाओं के लिए लंबी योजनाएँ के उदाहरणों पर प्रशिक्षित करें। योजना का महत्व व्यापक होने में नहीं है; यह स्थिति के लिए सही आकार में है।

Operational envelope. Incident response वह pattern है जो लगभग हर Inngest आदिम, cron, events, fan-out, स्थायित्व, HITL, replay का उपयोग करता है:

• Triggers: सक्रिय स्वास्थ्य जांच के लिए दोहरी triggers, TriggerCron(cron="*/5 * * * *") और प्रतिक्रियाशील घटनाओं के लिए TriggerEvent(event="incident/alert.fired")। एक ही function आकार दोनों को संभालता है।
• प्रति चरण स्थायित्व: एक step.run प्रति planning चरण और प्रत्येक remediation चरण; यदि remediation आंशिक रूप से विफल रहता है, तो पिछले चरण memoized बने रहते हैं।
• HITL पर remediation: planner के आउटपुट और निष्पादन के बीच, step.wait_for_event("await-remediation-approval", timeout=timedelta(minutes=15)) मानव reviewer को गेट करता है। संकट समयबाह्य क्योंकि घटनाएँ समय-संवेदनशील होती हैं।
• Replay गलत-सकारात्मक बग फिक्स के लिए: जब remediation स्क्रिप्ट में एक बग होता है जो घटनाओं को एक विशेष तरीके से विफल कर देता है, तो स्क्रिप्ट को ठीक करें और Inngest dashboard से विफल घटनाओं को बल्क-replay करें। कोई मैन्युअल घटना पुनः परीक्षण नहीं।

निर्णय 2. के लिए सिम्युलेटेड ट्रैक कॉलआउट यह पहला निर्णय है जो pattern composition (planning + reflection) पेश करता है। कागज पर भी, यह अभ्यास सार्थक है: ध्यान दें कि reflection जोड़ने का विकल्प अकेले Q4 से नहीं आया था, यह विशेष रूप से remediation चरण पर लागू Q4 से आया था। प्रतिबिंब शायद ही कभी सब कुछ या कुछ भी नहीं होता है; इसे अक्सर विशिष्ट उच्च-स्टेक आउटपुट पर स्तरित किया जाता है।

निर्णय 3: Market research agent

task। एक विषय ("agentic AI मिडलवेयर में प्रतिस्पर्धी परिदृश्य") और एक शोध संक्षिप्त (मुख्य प्रश्न, गहराई की आवश्यकताएं, समय सीमा) को देखते हुए, agent एक शोध रिपोर्ट तैयार करता है। कार्य में शामिल हैं: प्रासंगिक स्रोतों की पहचान करना, एकाधिक databases की खोज करना, दस्तावेजों को पढ़ना और निकालना, सभी स्रोतों के दावों की तुलना करना, निष्कर्षों का मसौदा तैयार करना और एक अंतिम रिपोर्ट तैयार करना।

आपकी बारी। आगे पढ़ने से पहले इस task पर पाँच प्रश्न पढ़ें। एक pattern के प्रति प्रतिबद्ध रहें, फिर स्वयं को कार्यान्वित उत्तर से जांचें। (या task को अपने AI में पेस्ट करें और यह आपसे Q1 से Q5 तक प्रश्नोत्तरी कराए, जब आपका तर्क कमजोर हो तो उसे पीछे धकेलें।)

पहले इसे स्वयं चलाएं, फिर कार्यान्वित उत्तर खोलें।

पेड़ पर चलना।

Q1: क्या solution path को पहले से परिभाषित किया जा सकता है? नहीं। किन स्रोतों से परामर्श लेना है, किस competitors की जांच करनी है, कौन सा विश्लेषण चलाना है, यह सब इस बात पर निर्भर करता है कि रास्ते में क्या खोजा गया है। अज्ञात पथ.

Q2: एन/ए.

Q3: क्या task structure निष्पादन से पहले व्यक्त किया जा सकता है? हाँ। मानक अनुसंधान-रिपोर्ट आकार: डेटा इकट्ठा करें → विश्लेषण → संश्लेषण → ड्राफ्ट → समीक्षा। भले ही विशिष्ट स्रोत और विश्लेषण अज्ञात हैं, प्रमुख चरण स्पष्ट हैं। आर्टिकुलेबल संरचना.

Q4: क्या गुणवत्ता गति से अधिक मायने रखती है? हां, दृढ़ता से। अनुसंधान रिपोर्ट निर्णय निर्माताओं द्वारा पढ़ी जाती हैं; तथ्यात्मक त्रुटियों और कमजोर विश्लेषण के वास्तविक परिणाम होते हैं। गुणवत्ता criteria आंशिक रूप से जांच योग्य है, "सभी दावे स्रोत हैं," "competitor विश्लेषण प्रत्येक प्रमुख खिलाड़ी को कवर करता है," "संश्लेषण संक्षिप्त प्रश्नों का उत्तर देता है।" चिंतन उचित है, विशेषकर संश्लेषण और अंतिम मसौदे पर।

Q5: क्या कोई विशेषज्ञता है, context, या स्केल bottleneck? संभवतः हाँ context के लिए। गहराई पर अनुसंधान के लिए बड़ी मात्रा में स्रोत सामग्री लोड करने की आवश्यकता होती है; एक agent के context window में ऐसा करने से तर्कशक्ति में गिरावट का जोखिम रहता है। अनुसंधान-और-सारांश-प्रति-स्रोत agents में विभाजित करना जो केंद्रित संक्षिप्त विवरण तैयार करता है, फिर संक्षिप्त विवरण तैयार करना, सही pattern है। मल्टी-agent context-प्रबंधन कारणों से।

pattern चयन: Multi-agent specialist system, शीर्ष परत पर planning के साथ, अनुसंधान के भीतर ReAct specialists, और अंतिम संश्लेषण पर reflection। अवधारणाओं की संरचना 11, 13, और 12.

Deployment topology स्केच। पूर्ण cloud stack प्लस multi-agent अतिरिक्त (संकल्पना 13):

• नियॉन में पैरेंट-रन + per-specialist रन संरचना (parent_run_id, agent_role)
• रूटिंग ऑडिट logs जिसके लिए specialist को कौन सा स्रोत मिला
• Per-specialist cost ट्रैकिंग (शोध agents50-पेज पढ़ने से पीडीएफ़ tokens तेजी से बर्न हो सकते हैं)
• bridge Worker दस्तावेज़-पढ़ने का काम संभालता है tools जिसे specialists में साझा किया जाता है
• एग्रीगेटर agent एक साझा नियॉन तालिका से पढ़ता है जहां specialists अपना सारांश जमा करता है

Eval signals देखने लायक।

• तीन अलग-अलग scoreboards: per-specialist अनुसंधान गुणवत्ता, रूटिंग सटीकता (क्या सही specialist को सही स्रोत मिला?), एकीकरण गुणवत्ता (क्या अंतिम रिपोर्ट specialists के निष्कर्षों को अच्छी तरह से संश्लेषित करती है?)
• शीर्ष-स्तरीय योजना पर योजना-निष्पादन विचलन
• अंतिम संश्लेषण पर Reflection प्रभावशीलता
• Cost-प्रति-सही-आउटपुट (multi-agent + reflection इसे महंगा बनाता है; ट्रैक करें और उचित ठहराएं)

production में सबसे अधिक संभावित विफलता मोड: specialists उत्कृष्ट व्यक्तिगत संक्षिप्त विवरण तैयार करता है जिसे एग्रीगेटर साफ-सुथरा रूप से संश्लेषित नहीं कर सकता क्योंकि संक्षिप्त विवरण असंगत प्रारूपों या शब्दावली का उपयोग करते हैं। समाधान: संरचित handoff प्रारूप लागू करें (संक्षिप्त संरचना के लिए Pydantic schemas), ताकि एग्रीगेटर को समान आकार के इनपुट प्राप्त हों।

Operational envelope. Market research इस पाठ्यक्रम में प्रमुख fan-out उदाहरण_ है, pattern Inngest के प्रवाह-नियंत्रण primitives को इसके लिए डिज़ाइन किया गया था:

• Fan-out trigger pattern: coordinator function प्रति competitor में एक research/competitor.research event सक्रिय करता है; प्रत्येक एक स्वतंत्र function रन चलाता है। N competitors → N समानांतर function runs, सभी को अलग से ट्रैक किया गया, सभी स्वतंत्र रूप से टिकाऊ।
• Per-tenant concurrency कैप: competitor-अनुसंधान function पर concurrency=[Concurrency(limit=5, key="event.data.tenant_id")], एक tenant के "अनुसंधान 50 competitors" request को सिस्टम पर एकाधिकार करने से रोकता है।
• प्रति specialist स्थायित्व: प्रत्येक competitor-शोध रन की अपनी step.run कॉल (वेब ​​खोज, दस्तावेज़ लाने, संक्षिप्त पीढ़ी) होती है; अनुसंधान के बीच में दुर्घटना केवल retries असफल कदम है, संपूर्ण अनुसंधान नहीं।
• एक अलग function के रूप में एकत्रीकरण: जब सभी specialist runs पूर्ण हो जाते हैं (Inngest "सभी पूर्ण" events का उत्सर्जन करते हैं), research/landscape.synthesize द्वारा ट्रिगर किया गया एक synthesizer function संक्षिप्त विवरण पढ़ता है और अंतिम रिपोर्ट बनाता है। events के माध्यम से वियुग्मित; कोई साझा स्थिति नहीं.
• Cost-per-specialist दृश्यता: Inngest का प्रति-function dashboard प्रति competitor token व्यय दर्शाता है; आउटलेर्स (competitor X cost 5× अन्य से अधिक) तुरंत दिखाई देते हैं।

निर्णय 3. के लिए सिम्युलेटेड ट्रैक कॉलआउट यह निर्णय pattern संरचना दिखाता है, multi-agent अन्य pattern का प्रतिस्थापन नहीं है; यह उनकी एक रचना है. planning agent planning का उपयोग करता है; अनुसंधान specialists उपयोग ReAct; संश्लेषण agent reflection का उपयोग करता है। Multi-agent topology है; topology के अंदर के pattern अभी भी वही पांच pattern हैं।

निर्णय 4: Enterprise onboarding agent

task। जब कोई नया उद्यम ग्राहक साइन अप करता है, तो एक agent runs ऑनबोर्डिंग workflow: उनके tenant का प्रावधान करता है (खाते बनाता है, databases, कॉन्फ़िगरेशन), बीज डेटा पॉप्युलेट करता है, उनके प्रशासकों को आमंत्रित करता है, kickoff मीटिंग शेड्यूल करता है, स्वागत सामग्री भेजता है। कार्य में कई नियतात्मक प्रावधान चरण और कुछ व्यक्तिगत संचार शामिल हैं।

आपकी बारी। आगे पढ़ने से पहले इस task पर पाँच प्रश्न पढ़ें। एक pattern के प्रति प्रतिबद्ध रहें, फिर स्वयं को कार्यान्वित उत्तर से जांचें। (या task को अपने AI में पेस्ट करें और यह आपसे Q1 से Q5 तक प्रश्नोत्तरी कराए, जब आपका तर्क कमजोर हो तो उसे पीछे धकेलें।)

पहले इसे स्वयं चलाएं, फिर कार्यान्वित उत्तर खोलें।

पेड़ पर चलना।

_Q1: क्या solution path को पहले से परिभाषित किया जा सकता है? प्रत्येक ऑनबोर्डिंग इसी क्रम में इन चरणों से होकर गुजरती है। कुछ चरणों की सामग्री वैयक्तिकृत है (स्वागत संदेश ग्राहक के नाम और उद्योग का संदर्भ देता है) लेकिन चरण अनुक्रम अपरिवर्तनीय है। ज्ञात पथ.

Q2: क्या workflow runs में स्थिर और स्थिर है? हाँ। प्रत्येक एंटरप्राइज़ ग्राहक समान ऑनबोर्डिंग workflow का पालन करता है। स्थिर.

Q3, Q4, Q5: N/A या नहीं। decision tree Q2 पर समाप्त हो जाता है क्योंकि workflow निश्चित है।

pattern चयन: Sequential workflow. संकल्पना 9.

Deployment topology स्केच। न्यूनतम cloud stack:

• एसीए पर FastAPI
• ऑनबोर्डिंग स्थिति के लिए नियॉन (कौन से ग्राहक किस चरण में हैं)
• किसी भी दस्तावेज़ के लिए R2 (पीडीएफ, ऑनबोर्डिंग गाइड का स्वागत है)
• वैयक्तिकरण चरणों में एम्बेडेड LLM कॉल (ग्राहक द्वारा अनुरोध किए जाने पर स्वागत संदेश निर्माण, account-नाम सुझाव)
• नहीं sandbox की आवश्यकता। नहीं bridge Worker। लंबे समय तक चलने वाले agentic तर्क के लिए किसी पृष्ठभूमि-worker pattern की आवश्यकता नहीं है (हालाँकि workflow स्वयं पैमाने को संभालने के लिए पृष्ठभूमि कार्य के रूप में चल सकता है)।

यह deployment है जो पूर्ण cloud स्टैक से सार्थक रूप से सस्ता है, क्योंकि task को cloud deployment की अधिकांश जटिलता की आवश्यकता नहीं है।

Eval signals देखने लायक।

• चरण-स्तरीय शुद्धता (प्रत्येक प्रावधान चरण सफल हुआ; निष्कर्षण वैध schemas लौटा)
• Workflow पूर्णता दर (ऑनबोर्डिंग का कितना भाग सफलतापूर्वक पूर्ण होता है?)
• वैयक्तिकरण गुणवत्ता (LLM-जनित स्वागत संदेश, Phoenix टोन, तथ्यात्मक सटीकता को ग्रेड कर सकता है)
• विफलता मोड: workflow चरण गलत इनपुट पर लागू होते हैं (सत्यापन अंतराल)

production में सबसे अधिक संभावित विफलता मोड: एक edge-केस उद्यम (असामान्य उद्योग, विशेष अनुपालन आवश्यकताएं) मानक workflow में फिट नहीं होता है। ठीक: या तो (ए) edge मामले के लिए workflow में स्पष्ट शाखाएँ जोड़ें (यदि आपके पास कुछ edge मामले हैं), या (बी) पहचानें कि workflow परिवर्तनशील होता जा रहा है और ReAct + tools में अपग्रेड करने पर विचार करें (यदि edge मामले बढ़ते हैं)। समय के साथ इस परिवर्तन पर नजर रखें: workflows अक्सर स्थिर रूप से शुरू होता है और धीरे-धीरे अनुकूल हो जाता है।

Operational envelope. Enterprise onboarding इस पाठ्यक्रम में सबसे स्वच्छ Inngest sequential workflow उदाहरण है: प्रत्येक चरण step.run है, कोई agentic जटिलता नहीं है:

• Trigger: TriggerEvent(event="customer/enterprise.signed_up"), CRM में डील बंद होने पर सक्रिय हो जाता है।
• प्रत्येक ऑनबोर्डिंग चरण पर एक कदम चलाएं: step.run("provision-tenant", ...), step.run("configure-defaults", ...), step.run("seed-data", ...), step.run("invite-admins", ...), step.run("schedule-kickoff", ...), step.run("send-welcome", ...)। प्रत्येक चरण टिकाऊ है; चरण 4 पर दुर्घटना → चरण 1-3 memoized हैं।
• कोई HITL आवश्यक नहीं: ऑनबोर्डिंग पूरी तरह से स्वचालित है; मानक पथ में कोई step.wait_for_event कॉल नहीं है।
• step.sleep विलंबित कार्यों के लिए: step.sleep("wait-2-days-before-followup", timedelta(days=2)) एक अनुवर्ती शेड्यूल करता है जो ऑनबोर्डिंग पूर्ण होने के बाद सक्रिय होता है, प्रतीक्षा के दौरान शून्य गणना खपत होती है।
• Cron जोड़ी: एक अलग cron-ट्रिगर function (TriggerCron("0 9 * * *")) ग्राहक database को उन ऑनबोर्डिंग के लिए प्रतिदिन स्वीप करता है जो रुकी हुई थीं (एक चरण विफल हो गया और retries खत्म हो गया); cron function अटके हुए मामलों के लिए पुनर्प्राप्ति events शुरू करता है।

यह deployment है जो दूसरों की तुलना में काफी हद तक सस्ता है, और Inngest cost अनुशासन को दृश्यमान बनाता है: function dashboard चरण-दर-चरण सफलता दर और चरण-दर-चरण costs दिखाता है, ताकि आप देख सकें कि कौन सा ऑनबोर्डिंग चरण bottleneck है।

निर्णय 4. के लिए सिम्युलेटेड ट्रैक कॉलआउट यह निर्णय मायने रखता है क्योंकि यह agentic pattern के लिए नकारात्मक उदाहरण है। task को agentic तर्क की आवश्यकता नहीं है। एम्बेडेड LLM कॉल वाला workflow सस्ता, अधिक विश्वसनीय और डीबग करना आसान है। जब workflow काम करता है तो ReAct तक न पहुंचें। यह decision tree द्वारा सिखाया जाने वाला सबसे महत्वपूर्ण अनुशासन है।

निर्णय 5: Coding agent (उन्नत ट्रैक)

task। एक coding agent एक सुविधा request प्राप्त करता है और एक कार्यशील कार्यान्वयन तैयार करता है: मौजूदा कोडबेस को पढ़ता है, परिवर्तन को डिज़ाइन करता है, कोड लिखता है, परीक्षण लिखता है, runs परीक्षण करता है, विफलताओं को ठीक करता है, और human review के लिए तैयार PR तैयार करता है। कोडबेस बड़ा है, परिवर्तन जटिल हो सकते हैं, और शुद्धता मायने रखती है।

आपकी बारी। आगे पढ़ने से पहले इस task पर पाँच प्रश्न पढ़ें। एक pattern के प्रति प्रतिबद्ध रहें, फिर स्वयं को कार्यान्वित उत्तर से जांचें। (या task को अपने AI में पेस्ट करें और यह आपसे Q1 से Q5 तक प्रश्नोत्तरी कराए, जब आपका तर्क कमजोर हो तो उसे पीछे धकेलें।)

पहले इसे स्वयं चलाएं, फिर कार्यान्वित उत्तर खोलें।

पेड़ पर चलना।

Q1: क्या solution path को पहले से परिभाषित किया जा सकता है? नहीं। Coding कार्य में निरंतर खोज शामिल है, कोडबेस में क्या मौजूद है, मौजूदा कोड कैसे संरचित है, परीक्षणों से कौन से edge मामले सामने आते हैं। अज्ञात पथ.

Q2: एन/ए.

_Q3: क्या task structure को निष्पादन से पहले स्पष्ट किया जा सकता है? लेकिन: जटिल परिवर्तनों के लिए, डिज़ाइन चरण पुनरावृत्त हो सकता है (डिज़ाइन → बाधा की खोज → डिज़ाइन को संशोधित → बाधा की पुनः खोज)। व्यक्त करने योग्य लेकिन आंतरिक अनुकूलन आवश्यकताओं के साथ।

Q4: क्या गुणवत्ता गति से अधिक मायने रखती है? हाँ, बहुत। production पर भेजे जाने वाले कोड के वास्तविक परिणाम होते हैं। गुणवत्ता criteria जांच योग्य हैं: परीक्षण पास या असफल, प्रकार की जांच पास या असफल, लिंटर पास या विफल, कोड समीक्षा विशिष्ट मुद्दों की पहचान करती है। चिंतन अत्यधिक उचित है।

Q5: क्या कोई विशेषज्ञता है, context, या स्केल bottleneck? विशेषज्ञता और context दोनों के लिए वास्तव में हाँ। Coding में कम से कम तीन अलग-अलग कौशल सेट शामिल हैं: कोड जनरेशन (अच्छा कोड लिखना), सुरक्षा समीक्षा (कमजोरियों को पकड़ना), और दस्तावेज़ीकरण (परिवर्तन की व्याख्या करना)। प्रत्येक को एक केंद्रित agent से लाभ होता है। Multi-agent उचित।

pattern चयन: Multi-agent specialist system, शीर्ष पर planning के साथ, specialists के भीतर ReAct + tools, और कोड आउटपुट पर स्पष्ट reflection। सभी चार अन्य pattern की संरचना।

Deployment topology स्केच। पूर्ण cloud stack प्लस multi-agent एक्सटेंशन:

• Coordinator agent: सुविधा request प्राप्त करता है, चरणों के साथ एक योजना तैयार करता है (डिज़ाइन → कोड → समीक्षा → दस्तावेज़)
• कोडर specialist: ReAct + tools (कोडबेस पढ़ें, फ़ाइलें लिखें, परीक्षण चलाएँ)। भारी sandbox उपयोग (परीक्षण चलाना, कोड निष्पादित करना)। Bridge Worker अनिवार्य।
• Reviewer specialist: ReAct + tools (कोडर का आउटपुट पढ़ें, सुरक्षा जांच चलाएं, लिंटर चलाएं)। हल्का sandbox उपयोग।
• दस्तावेज़ीकरण specialist: सरल, संभवतः अनुक्रमिक (परिवर्तन निकालें → दस्तावेज़ उत्पन्न करें)।
• कोडर के अंतिम PR पर Reflection layer (क्या यह सभी परीक्षण पास करता है? क्या यह आवश्यकता से मेल खाता है?)।
• नियॉन में Per-specialist runs; रूटिंग ऑडिट logs; cost प्रति specialist ट्रैकिंग (कोडर costs पर हावी होगा)।

Eval signals देखने लायक। multi-agent के सभी तीन scoreboards, साथ ही reflection मेट्रिक्स। इन पर विशेष फोकस:

• कोड-शुद्धता eval (क्या generated code परीक्षण पास करता है?)
• सुरक्षा-समीक्षा प्रभावशीलता (क्या reviewer ने कमजोरियाँ पकड़ीं? गलत-सकारात्मक दर भी मायने रखती है)
• योजना-निष्पादन विचलन (coordinator की योजना बनाम वास्तव में क्या भेजा गया)
• Cost-प्रति-PR (यह एक महंगा pattern है; सुनिश्चित करें कि यह अपना cost अर्जित करे)

production में सबसे अधिक संभावित विफलता मोड: reviewer specialist bottleneck बन जाता है, या तो बहुत सख्त (मामूली शैली के मुद्दों के साथ वैध कोड को अस्वीकार करना) या बहुत अधिक अनुमेय (वास्तविक बग के साथ कोड पास करना)। फिक्स: reviewer के निर्णयों के लिए स्पष्ट criteria, और एक अलग मूल्यांकन जो एक ही कोड पर मानव reviewer निर्णयों के विरुद्ध reviewer के निर्णयों को ग्रेड करता है।

Operational envelope. coding agent प्रत्येक Inngest आदिम का उपयोग करता है, यह वह pattern है जो पूर्ण operational envelope को उचित ठहराता है:

• Triggers: TriggerEvent(event="github/issue.assigned_to_agent"), जब कोई issue सौंपा जाता है तो सक्रिय हो जाता है; या Slack में एक chat command event को सक्रिय करती है।
• Fan-out समन्वय: coordinator function फीचर को चरणों में विघटित करता है, फिर events को specialist functions (coding/specialist.code, coding/specialist.review, coding/specialist.docs) में सक्रिय करता है। प्रत्येक specialist अपने स्वयं के concurrency और स्थायित्व के साथ अपना स्वयं का function है।
• step.run प्रति फ़ाइल संपादन: कोडर specialist प्रत्येक फ़ाइल संशोधन को step.run("edit-{path}", ...) में लपेटता है ताकि मल्टी-फ़ाइल संपादन के दौरान क्रैश होने पर पूर्ण संपादन न खोएं। मेमोइज़ेशन यहां विशेष रूप से मूल्यवान है, आंशिक रूप से पूरा होने के बाद LLM-generated code परिवर्तन को फिर से चलाना महंगा है और मूल योजना से विचलन का जोखिम है।
• PR merge पर step.wait_for_event: agent द्वारा PR उत्पन्न करने के बाद, function step.wait_for_event("await-human-merge-approval", timeout=timedelta(days=2)) के माध्यम से निलंबित हो जाता है। GitHub पर मानव समीक्षाएँ अनुमोदित करती हैं; function merge के बाद सफाई करना फिर से शुरू करता है।
• Per-tenant concurrency: कोडर specialist पर concurrency=[Concurrency(limit=2, key="event.data.tenant_id")] एक tenant को coding क्षमता पर एकाधिकार करने से रोकता है। (Coding महंगा है; per-tenant कैप महत्वपूर्ण हैं।)
• tier-आधारित निष्पक्षता के लिए Priority: एंटरप्राइज़ tenants' coding कार्य queue (priority=Priority(run="100 - (event.data.tier_priority * 100)")) में Free-tier से आगे निकल जाते हैं।
• Replay आंशिक विफलता के लिए: जब reviewer specialist किसी निश्चित कारण से कोड को अस्वीकार कर देता है, तो कोडर समीक्षा event को ठीक करता है और पुनः सक्रिय करता है; function dashboard प्रति PR पुनरावृत्ति इतिहास दिखाता है।
• step.sleep सुरक्षा विंडो के लिए: step.sleep("await-tests-stable", timedelta(hours=2)) विलय के बाद, यह पुष्टि करने के लिए 2 घंटों तक CI runs तक प्रतीक्षा करें कि agent कार्य को पूर्ण के रूप में चिह्नित करने से पहले परिवर्तन के कारण डाउनस्ट्रीम परीक्षणों में बाधा न आए।

निर्णय 5. के लिए सिम्युलेटेड ट्रैक कॉलआउट यह सबसे कठिन निर्णय है क्योंकि task को वास्तव में प्रत्येक pattern को एक साथ बनाने की आवश्यकता है। यहां अभ्यास यह याद रखना नहीं है कि कौन से pattern लागू होते हैं; यह देखना है कि decision tree कैसे व्यवस्थित रूप से पहचानता है कि कौन सा pattern बनाना है और कहां। coding agent "उन्नत" नहीं है क्योंकि यह जटिल है; यह उन्नत है क्योंकि pattern composition के अनुशासन के लिए अभ्यास की आवश्यकता होती है।

---

भाग 6: ईमानदार सीमाएँ

17: Cost और latency की अवधारणा architectural बाधाओं के रूप में है, बाद के विचार नहीं

इस पाठ्यक्रम में अब तक pattern selection के साथ ऐसा व्यवहार किया गया है जैसे कि cost और latency गौण थे। production में, वे अक्सर प्राथमिक होते हैं। संकल्पना 17 प्रत्येक pattern के cost और latency प्रोफाइल को स्पष्ट रूप से नाम देती है, इसलिए decision tree को बजट बाधाओं को ध्यान में रखते हुए चलाया जा सकता है।

Cost प्रोफ़ाइल प्रति pattern (परिमाण का मोटा क्रम, GPT-5-वर्ग मूल्य निर्धारण मानते हुए):

pattern	Cost प्रति task	Cost ड्राइवर
Sequential workflow	1× (बेसलाइन)	LLM कॉलों की संख्या (अक्सर 1-3 प्रति workflow)
Single agent + ReAct	3-10×	ReAct पुनरावृत्तियों की संख्या (model को प्रति loop में एक बार बुलाया जाता है)
Planning + ReAct execution	5-15×	Planning कॉल + प्रति चरण ReAct loops
Single agent + reflection	2-3× अंतर्निहित pattern	आलोचना + परिशोधन पास
Multi-agent specialist	5-20×	specialist runs + coordinator + एकीकरण की संख्या

संख्याएं उदाहरणात्मक हैं, सटीक नहीं। अनुपात क्या मायने रखता है: शीर्ष पर reflection के साथ एक multi-agent system उसी task वॉल्यूम के लिए sequential workflow से अधिक cost 30-60× कर सकता है। जब वह गुणक गुणवत्ता द्वारा उचित है, तो ठीक है। जब इसे सौंदर्यशास्त्र द्वारा उचित ठहराया जाता है, तो यह एक बजट आपदा घटित होने की प्रतीक्षा कर रही है।

Latency प्रोफ़ाइल प्रति pattern:

pattern	Latency	चालक
Sequential workflow	न्यूनतम (~1-5s)	नियतात्मक चरण + LLM क्रम में कॉल करते हैं
Single agent + ReAct	मध्यम (~10-30s)	प्रति loop एक model कॉल; loops खिंच सकता है
Planning + ReAct	मध्यम-उच्च (~30-90s)	Planning कॉल + अनुक्रमिक चरण निष्पादन
Single agent + reflection	2-3× अंतर्निहित pattern	समालोचना + परिशोधन गुणात्मक जोड़ें latency
Multi-agent specialist	परिवर्तनीय	Parallel execution मदद करता है; समन्वय overhead जोड़ता है

decision tree के साथ एकीकरण। Q4 (गुणवत्ता बनाम गति) परोक्ष रूप से latency को संबोधित करता है। Q5 (विशेषज्ञता/पैमाना) स्पष्ट रूप से cost को संबोधित करता है। लेकिन decision tree स्पष्ट रूप से यह नहीं कहता है "उत्तर पेड़ द्वारा सुझाए गए pattern से एक pattern कम विस्तृत है, क्योंकि आपका latency budget कठिन है।" यह पेड़ के शीर्ष पर एक बाधा-परत निर्णय है।

व्यावहारिक अनुशासन: decision tree पर चलने से पहले, अपना latency और cost बजट लिखें। यदि पेड़ का चुना हुआ pattern किसी भी बजट का उल्लंघन करता है, तो आपके पास तीन विकल्प हैं:

1. बाधाएँ बदलें। अधिक बजट प्राप्त करें, latency सहनशीलता बढ़ाएँ, या धीमी डिलीवरी स्वीकार करें।
2. दायरा बदलें। सिस्टम को जो करना है उसे कम करें, ताकि कम विस्तृत pattern इसे संभाल सके।
3. खराब फिट को स्वीकार करें। कम विस्तृत pattern का उपयोग करें और स्वीकार करें कि कुछ विफलता मोड अधिक विस्तृत pattern को पकड़ लेंगे।

दस्तावेज़ करें कि आपने कौन सा विकल्प चुना और क्यों। जब सिस्टम विफलता मोड दिखाता है जिसे विस्तृत pattern ने रोका होगा, तो आप याद रखना चाहेंगे कि आपने कौन सा व्यापार-बंद किया था।

संकल्पना की निचली पंक्ति 17: cost और latency architectural बाधाएं हैं, बाद के विचार नहीं। प्रत्येक pattern में एक विशेषता cost और latency प्रोफ़ाइल होती है, और जब pattern बनाए जाते हैं तो गुणक यौगिक होते हैं। Multi-agent reflection के साथ समान task वॉल्यूम (उदाहरणात्मक अनुपात) के लिए cost 30-60× को sequential workflow कर सकता है। decision tree इन्हें Q4 और Q5 के माध्यम से स्पष्ट रूप से संबोधित करता है, लेकिन स्पष्ट बजट बाधाएं कभी-कभी पेड़ के उत्तर को ओवरराइड कर देती हैं; ओवरराइड का दस्तावेजीकरण करें और परिणामी विफलता मोड को सचेत रूप से स्वीकार करें।

अवधारणा 18: Pattern composition, विभिन्न परतों पर एकाधिक pattern

इस पाठ्यक्रम में बड़े पैमाने पर pattern का व्यवहार किया गया है जैसे कि आप किसी एक को चुनते हैं। वास्तविक सिस्टम अक्सर विभिन्न परतों पर pattern बनाते हैं: शीर्ष पर एक planning agent, प्रत्येक योजना चरण के भीतर ReAct + tools, अंतिम आउटपुट पर reflection। निर्णय 3 और 5 ने पहले ही यह दिखा दिया था; संकल्पना 18 इसे प्रथम-class architectural कदम का नाम देती है।

पहचानने लायक तीन रचना आकृतियाँ:

पदानुक्रमित संरचना। एक उच्च-स्तरीय pattern निचले-स्तरीय pattern को लपेटता है। उदाहरण:

• Planning agent (शीर्ष) + ReAct + tools (प्रत्येक चरण के भीतर)
• Multi-agent coordinator (शीर्ष) + अनुक्रमिक workflows (specialists के भीतर)
• ReAct (शीर्ष) + sequential workflow (tool के रूप में ReAct agent कॉल करता है जब उसे नियतात्मक कार्य की आवश्यकता होती है)

अनुक्रमिक रचना। pattern एक के बाद एक चलते हैं, पहले का आउटपुट दूसरे को फीड करता है। उदाहरण:

• Sequential workflow (संरचित डेटा निकालें) → ReAct agent (संरचित डेटा की जांच करता है)
• ReAct agent (आउटपुट उत्पन्न करता है) → reflection layer (आलोचना और परिशोधन)

सशर्त संरचना। अलग-अलग pattern अलग-अलग मामलों को संभालते हैं, राउटर pattern का चयन करता है। उदाहरण:

• ज्ञात-आकार requests के लिए, sequential workflow तक मार्ग; अज्ञात आकार के लिए requests, ReAct का मार्ग
• हाई-स्टेक आउटपुट के लिए, reflection लागू करें; कम जोखिम वाले आउटपुट के लिए, इसे छोड़ें

रचना के लिए व्यावहारिक नियम: प्रत्येक परत के pattern की पसंद को उन्हीं पांच प्रश्नों द्वारा उचित ठहराया जाना चाहिए, जो उस परत के दायरे में लागू होते हैं। शीर्ष-स्तरीय pattern को समग्र task पर पेड़ पर चलकर चुना जाता है। प्रत्येक उप-component का pattern उस उप-component के कार्य के आधार पर पेड़ पर चलकर चुना जाता है। pattern न लिखें क्योंकि रचना परिष्कृत लगती है; उन्हें लिखें क्योंकि प्रत्येक परत के task गुण इसकी मांग करते हैं।

सबसे आम रचना गलती: परतें जोड़ना क्योंकि परतें जोड़ना अच्छी इंजीनियरिंग की तरह दिखता है। एक coding agent जो प्रत्येक आउटपुट पर multi-agent + planning + reflection है और एक सर्किट ब्रेकर pattern जो हर चीज को लपेटता है _कठोर लगता है; यह अक्सर अनावश्यक होता है. सबसे ऊपरी परत को हटाकर रचना का परीक्षण करें। यदि आउटपुट ख़राब नहीं होता है, तो परत अपनी cost अर्जित नहीं कर रही थी।

संकल्पना की निचली पंक्ति 18: वास्तविक सिस्टम विभिन्न परतों पर pattern बनाते हैं, पदानुक्रमित (एक pattern दूसरे को लपेटता है), अनुक्रमिक (एक का आउटपुट दूसरे को फ़ीड करता है), सशर्त (विभिन्न मामलों के लिए अलग-अलग pattern)। प्रत्येक परत के pattern की पसंद को उस परत के दायरे में decision tree पर चलकर उचित ठहराया जाना चाहिए। सबसे आम रचना संबंधी गलती परतें जोड़ना है क्योंकि स्तरित architectures परिष्कृत लगती है; सबसे ऊपरी परत को हटाकर परीक्षण करें और जांचें कि गुणवत्ता में गिरावट आई है या नहीं।

---

भाग 7: समापन

Concept 19: Agent Factory curriculum में connective tissue के रूप में pattern selection

यह course agent क्या है (agent-building course: agent loops और tools) और agent को ship करने के लिए क्या चाहिए (cloud deployment course: production deployment, eval-driven course: operational evaluation) के बीच bridge है।

pattern selection के बिना, संयोजी ऊतक गायब है। आप एक agent को build कर सकते हैं और आप इसे deploy भी कर सकते हैं, लेकिन बीच में डिज़ाइन का निर्णय, इस task के लिए किस प्रकार का agent, सिद्धांतहीन था। यह पाठ्यक्रम उस अंतर को भरता है।

पाँच प्रश्न सरल लगते हैं। क्या रास्ता ज्ञात है? क्या workflow स्थिर है? क्या संरचना स्पष्ट है? क्या गुणवत्ता गति से अधिक महत्वपूर्ण है? क्या कोई विशेषज्ञता है bottleneck? लेकिन वे architectural विशिष्टताओं को कूटबद्ध करते हैं जिस पर काम करने में क्षेत्र ने पांच साल बिताए हैं। **pattern कैटलॉग (ReAct, planning, reflection, multi-agent) मौजूद हैं; उनके बीच चयन करने के लिए decision logic की कमी थी। ** Bala Priya C का लेख उस अंतर को भरता है; यह पाठ्यक्रम इसे deployment और मूल्यांकन संरचना के साथ विस्तारित करता है जिसकी Agent Factory छात्रों को आवश्यकता होती है।

deployment रचना वह योगदान है जो इस पाठ्यक्रम को अलग करती है। agentic pattern पर कुछ पाठ्यक्रम सिखाते हैं कि cloud stack के लिए प्रत्येक pattern का क्या अर्थ है:

• अनुक्रमिक workflows sandbox परत को पूरी तरह से छोड़ दें
• एकल-agent ReAct पूर्ण stack का उपयोग करता है
• Planning + ReAct योजना की दृढ़ता और लंबी पृष्ठभूमि जोड़ता है workers
• Reflection अक्सर बहु-प्रदाता model रूटिंग का परिचय देता है
• Multi-agent per-specialist traceिंग, रूटिंग ऑडिट logs, और प्रति-रोल cost एट्रिब्यूशन की मांग करता है

ये अमूर्त चिंताएँ नहीं हैं। वे छोटे कार्यभार के लिए deployment वाले costs $130/माह और उसी कार्यभार के लिए costs $400/माह के बीच अंतर हैं क्योंकि pattern अत्यधिक विस्तृत था। Pattern selection cost अनुशासन के साथ-साथ architecture अनुशासन भी है।

मूल्यांकन संरचना दूसरा योगदान है। प्रत्येक pattern में विशिष्ट विफलता मोड होते हैं जिन्हें आपका eval suite अलग तरीके से पकड़ता है:

• अनुक्रमिक workflows: DeepEval के माध्यम से चरण-स्तरीय शुद्धता
• ReAct: तर्क traces के माध्यम से Phoenix
• Planning + ReAct: एक कस्टम मीट्रिक के रूप में योजना-निष्पादन विचलन
• Reflection: पूर्व/पोस्ट तुलना और रबर-स्टैम्प का पता लगाना
• Multi-agent: specialist गुणवत्ता, रूटिंग, एकीकरण के लिए तीन अलग-अलग scoreboards

pattern-जागरूक मूल्यांकन के बिना, eval suite सामान्य है और प्रत्येक pattern उत्पन्न होने वाली विशिष्ट विफलताओं को याद करता है। यह पाठ्यक्रम बताता है कि क्या देखना है, pattern दर pattern, ताकि आपका eval suite pattern-जागरूक हो जाए।

Agent Factory track के लिए closing thesis sentence अब थोड़ा अलग पढ़ता है। agent-building course ने the agent loop is the engine of an AI-native company से शुरुआत की थी। cloud deployment course ने the agent loop, deployed at production scale with the right architectural separation, observed across the right surfaces, and graded continuously against a living eval suite, is what an AI-native company actually runs on पर close किया था। यह course missing prefix जोड़ता है: task के लिए सही agent loop वही है जिस पर AI-native company चलती है। गलत shape चुनना, overshooting या undershooting, ऐसे systems बनाता है जो धीरे ship होते हैं, ज़्यादा cost करते हैं, और ज़्यादा failure modes में break होते हैं। Pattern selection पहला design decision है; बाकी सब इसके downstream है।

इस पाठ्यक्रम के बाद क्या आता है। cloud deployment पाठ्यक्रम के समापन में तीन सीमाएं नामित की गईं: agent-to-agent वाणिज्य, समान-AI deployment विशिष्टताएं, बहु-क्षेत्र सक्रिय-सक्रिय। वे अभी भी भविष्य के पाठ्यक्रमों के रूप में खड़े हैं। यह पाठ्यक्रम एक और जोड़ता है: pattern-विशिष्ट परीक्षण हार्नेस। eval suite सामान्य है; भविष्य का पाठ्यक्रम build pattern-विशिष्ट परीक्षण जेनरेटर (एक "sequential workflow परीक्षक" जो workflow की शाखाओं को कवर करने वाले इनपुट उत्पन्न करता है; एक "multi-agent रूटिंग परीक्षक" जो coordinator के रूटिंग लॉजिक की जांच करने वाले इनपुट उत्पन्न करता है)। यह एक वास्तविक सीमा है, और यह एक शर्त के रूप में इस पाठ्यक्रम के pattern वर्गीकरण पर निर्भर करता है।

अंतिम अभ्यास AI के साथ प्रयास करें। अपना क्लाउड कोड या ओपनकोड सत्र खोलें। चिपकाएँ:

"मैंने अभी-अभी agentic pattern selection पर एक कोर्स पूरा किया है। एक real task चुनें जिसके लिए मैं अगले quarter में agent build करना चाहूँ, मेरी actual job की कोई चीज़, toy example नहीं। मेरे साथ five-question decision tree चलें, हर question पर मुझसे answer मांगें और अगर मेरा reasoning weak हो तो push back करें। फिर बताएं कि आप कौन सा pattern recommend करेंगे, मुझे कौन सी cloud deployment topology चाहिए, और किन eval signals पर ध्यान देना चाहिए। task properties के बारे में specific रहें, generic नहीं।"

आप क्या सीख रहे हैं। decision tree केवल तभी चिपकता है जब इसे आपके _कार्यों पर लागू किया जाता है, पाठ्यपुस्तक के उदाहरणों पर नहीं। यह अभ्यास अनुशासन को एक ठोस निर्णय लेने के लिए बाध्य करता है जिसे आप वास्तव में लेंगे। AI के response को बचाएं; जब आप agent का निर्माण शुरू करें तो इसे दोबारा देखें।

मुख्य पंक्ति: यह पाठ्यक्रम agent डिज़ाइन (agent loops और tools) और agent deployment (cloud deployment और eval पाठ्यक्रम) के बीच संयोजी ऊतक है। पाँच-प्रश्न decision tree उन architectural भेदों को कूटबद्ध करता है जिन पर साहित्य ने वर्षों तक काम किया है; संरचना परत प्रत्येक pattern को विशिष्ट deployment और मूल्यांकन अनुशासन में मैप करती है। समापन थीसिस: task के लिए सही agent loop एक AI-native कंपनी runs है, और pattern selection पहला डिज़ाइन निर्णय है, जिसके डाउनस्ट्रीम में बाकी सब कुछ प्रवाहित होता है। **इस पाठ्यक्रम द्वारा तैयार किए जाने योग्य artifact के लिए, संदर्भ से पहले अंतिम खंड में एक-पेज डिज़ाइन-समीक्षा टेम्पलेट देखें: प्रिंट करने योग्य, टीम-साझा करने योग्य, प्रति architecture प्रस्ताव के लिए ~15-20 मिनट में समान पांच प्रश्न पूछे जाते हैं।

---

चीट शीट: सभी 22 अवधारणाएँ और 5 निर्णय, भाग द्वारा समूहीकृत

दोनों मित्रों की समीक्षाओं ने चीट शीट को सघन बताया; नीचे दिया गया समूह प्रत्येक पंक्ति को उस भाग से मैप करता है जिससे वह संबंधित है, ताकि आप 22 पंक्तियों को स्क्रॉल करने के बजाय अनुभाग द्वारा नेविगेट कर सकें।

भाग 1: pattern-चयन समस्या

#	संकल्पना	कुंजी ले जाना
1	Pattern selection build से पहले का डिज़ाइन कार्य है	pattern अच्छी तरह से प्रलेखित हैं; उनके बीच चयन करने के लिए decision logic नहीं है। production में गलत विकल्प वाले यौगिक महंगे हैं।
2	प्रत्येक pattern task के बारे में एक शर्त है	Sequential workflow ज्ञात रास्तों पर दांव लगाता है; अज्ञात रास्तों पर ReAct; स्पष्ट संरचना पर planning; reflection पर checkable criteria; वास्तविक विशेषज्ञता आवश्यकताओं पर multi-agent।
3	दो विफलता मोड, overshoot और undershoot	Overshoot (आवश्यकता से अधिक विस्तृत) प्रसिद्ध विधा है; undershoot (आवश्यकता से अधिक सरल) समान रूप से सामान्य और सूक्ष्म है।

भाग 2: पाँच-प्रश्न decision tree

#	संकल्पना	कुंजी ले जाना
4	Q1: क्या solution path को पहले से परिभाषित किया जा सकता है?	workflows के लिए ज्ञात पथ मार्ग; अज्ञात पथ agentic तर्क के लिए मार्ग। "Python function बिना LLM कॉल्स" अनुमान के साथ परीक्षण करें।
5	Q2: क्या workflow स्थिर और स्थिर है?	sequential workflow के लिए स्थिर पथ मार्ग; ज्ञात-लेकिन-परिवर्तनीय मार्ग या तो branched workflow या agentic pattern के लिए।
6	Q3: क्या task structure व्यक्त करने योग्य है?	व्यक्त करने योग्य → planning + ReAct execution; व्यक्त करने योग्य नहीं → शुद्ध ReAct। आकार-बनाम-सामग्री भेद. Q2/Q3 असंबद्धता साइडबार सीमा मामलों पर चलता है।
7	Q4: गुणवत्ता > गति और checkable criteria?	मूल्य जोड़ने के लिए reflection के लिए दोनों शर्तें लागू होनी चाहिए। सबसे आम विफलताएँ: rubber-stamping, अस्पष्ट criteria, latency budget उल्लंघन।
8	Q5: विशेषज्ञता, context, या स्केल bottleneck?	जहां संभव हो, मात्रात्मक triggers के विरुद्ध तीन दावों का अलग-अलग परीक्षण किया गया: >30% tool-रूटिंग त्रुटियां (विशेषज्ञता), >10% उच्च context (ओवरफ्लो) पर सटीकता में गिरावट, >2× latency budget ओवररन (स्केल)।

ब्रिज अवधारणाएँ: pattern selection से कार्यान्वयन तक

#	संकल्पना	कुंजी ले जाना
8.5	SDK primitives: प्रत्येक pattern क्या उपयोग करता है	Agent परमाणु इकाई है। Runner.run() runs loop। @function_tool tools को उजागर करता है। specialist अधिग्रहण के लिए handoff(); coordinator-प्रभारी के लिए as_tool()। output_guardrail के लिए reflection। pattern चयन एक विकल्प है जिसके बारे में primitives लिखना है।
8.6	Operational envelope प्रति pattern (Inngest ठोस उदाहरण के रूप में)	Triggers function को जगाएं (TriggerEvent, TriggerCron); step.run इसे टिकाऊ बनाता है; step.wait_for_event HITL gates लागू करता है; concurrency/throttle/priority आकार load; fan-out multi-agent specialists का समन्वय करता है; replay बग-फिक्स पुनर्प्राप्ति को संभालता है। pattern जितना विस्तृत होगा, लिफाफा उतना ही महत्वपूर्ण होगा।

भाग 3: गहराई में पांच pattern

#	संकल्पना	कुंजी ले जाना
9	Sequential workflow, pattern, deployment, इवेल्स, लिफाफा	cloud stack के सबसे छोटे उपसमूह का उपयोग करता है (कोई sandbox की आवश्यकता नहीं है)। Step-level evals, agent-reasoning नहीं। सबसे सीधा map से Inngest functions।
10	Single agent + ReAct, pattern, deployment, इवेल्स, लिफाफा	पूर्ण cloud stack जिसमें bridge Worker भी शामिल है। Phoenix trace मूल्यांकन load-असर वाले हैं। संपूर्ण agent loop के लिए एक step.run।
11	Planning + ReAct execution, pattern, deployment, इवेल्स, लिफाफा	योजना दृढ़ता जोड़ता है; लंबी पृष्ठभूमि workers। योजना-निष्पादन विचलन कुंजी eval signal है। प्रति चरण एक step.run।
12	Single agent + reflection (एडिटिव लेयर), pattern, deployment, इवेल्स, लिफाफा	किसी भी मूल pattern के शीर्ष पर परतें। अक्सर बहु-प्रदाता model रूटिंग का परिचय देता है। Rubber-stamping सबसे घातक विफलता है। SDK output_guardrail या अलग generator/critic।
13	Multi-agent specialist system, pattern, deployment, इवेल्स, लिफाफा	पूर्ण stack प्लस per-specialist traceिंग। तीन अलग-अलग scoreboards की आवश्यकता है। प्रत्येक Inngest primitive (fan-out, per-tenant concurrency, priority, HITL) का उपयोग करता है। Coordination overhead वास्तविक है।

भाग 4: Failure signals और संशोधन

#	संकल्पना	कुंजी ले जाना
14	पांच failure signals	ReAct loops (अनुपलब्ध संरचना), योजना-निष्पादन विचलन (overstructured), reflection कोई सुधार नहीं (अस्पष्ट criteria), multi-agent रूटिंग विफल (overpartitioned), जटिल-लेकिन-बेहतर नहीं (संचयी overshoot)।
15	पहले सबसे छोटे दायरे में सुधार करता है	Prompt-level architectural बदलने से पहले contract-level (tool विवरण, handoff संरचनाएं) से पहले (stop conditions, criteria स्पेक्स) को ठीक करता है।
16	जब decision tree गलत हो	Task गुण पोस्ट-deploy में बदल जाते हैं, अलग-अलग sub-tasks को अलग-अलग pattern की आवश्यकता होती है, बाधाएं पेड़ के उत्तर को बाहर कर देती हैं। फिर से पेड़ पर चलो.
16.5	anti-pattern गैलरी, सामान्य गलत विकल्प	पाँच overshoot undershoot + तीन undershoot। सामग्री के लिए Multi-agent (→ single agent); चालान के लिए ReAct (→ workflow); debugging के लिए planner (→ ReAct); अस्पष्ट criteria पर reflection (→ हटाएं); एक विशाल agent (→ multi-agent); चेक करने योग्य आउटपुट पर reflection को छोड़ना (→ जोड़ें)।

भाग 5: decision lab (पांच निर्णय, नीचे अलग तालिका)

भाग 6: ईमानदार सीमाएँ

#	संकल्पना	कुंजी ले जाना
17	Cost और latency architectural बाधाओं के रूप में	Multi-agent + reflection cost 30-60× sequential workflow कर सकते हैं (उदाहरणात्मक अनुपात)। दस्तावेज़ बाधा-संचालित pattern विकल्प स्पष्ट रूप से।
18	विभिन्न परतों पर Pattern composition	श्रेणीबद्ध, अनुक्रमिक, सशर्त. प्रत्येक परत का pattern चयन उस दायरे में समान पाँच प्रश्नों द्वारा उचित ठहराया गया।

भाग 7: समापन

#	संकल्पना	कुंजी ले जाना
19	Pattern selection संयोजी ऊतक के रूप में	agent डिज़ाइन (agent loops और tools) और deployment (cloud deployment कोर्स) के बीच सेतु। task के लिए सही agent loop वही है जो AI-native कंपनी runs पर है।

पांच निर्णय (भाग 5)

#	निर्णय	कोर pattern + योगात्मक परतें
1	Maya का Tier-1 Support agent	कोर: Single agent + ReAct + tools (संकल्पना 10)। कोई योगात्मक परतें नहीं.
2	Incident response agent	कोर: Planning + ReAct execution (संकल्पना 11)। + Reflection layer remediation चरणों पर (संकल्पना 12)।
3	Market research agent	कोर: Multi-agent specialist system (संकल्पना 13), specialists के भीतर planning + ReAct के साथ। + Reflection layer संश्लेषण पर।
4	Enterprise onboarding agent	कोर: Sequential workflow (संकल्पना 9)। कोई योगात्मक परतें नहीं. agentic pattern के लिए नकारात्मक उदाहरण।
5	Coding agent	कोर: Multi-agent specialist system (अवधारणा 13), specialists के भीतर planning + ReAct के साथ। + कोडर आउटपुट पर Reflection layer। उन्नत मामला: प्रत्येक architectural निर्णय की रचना।

त्वरित संदर्भ: पाँच प्रश्न, पाँच pattern

Q1: Can the solution path be defined in advance?
    Yes  → Q2
    No   → Q3 (need agentic reasoning)

Q2: Is the workflow fixed and stable across runs?
    Yes  → SEQUENTIAL WORKFLOW
    No   → Q3 (or branched workflow if few stable variants)

Q3: Is the task structure articulable before execution?
    Yes  → PLANNING + REACT EXECUTION
    No   → SINGLE AGENT + REACT + TOOLS

Q4: Quality > speed AND criteria are checkable?
    Yes  → Add REFLECTION on top of the chosen pattern
    No   → Skip reflection

Q5: Specialization, context, or scale bottleneck?
    Yes  → MULTI-AGENT SPECIALIST SYSTEM
    No   → Keep single-agent pattern

डिज़ाइन-समीक्षा टेम्पलेट (एक पृष्ठ, मुद्रण योग्य)

*डिज़ाइन समीक्षाओं में इस पाठ्यक्रम के framework को लागू करने के लिए एक टीम-साझा करने योग्य वर्कशीट। प्रति architecture प्रस्ताव एक प्रिंट करें। टेम्प्लेट समान पाँच प्रश्नों पर चलता है और समान रचनात्मक निर्णयों को सामने लाता है; मूल्य इसे अकेले भरना नहीं है, इसमें चर्चा के दौरान प्रश्न दिखाई देना है।*

═══════════════════════════════════════════════════════════════════════
  COURSE ELEVEN: Agentic Architecture Design Review
═══════════════════════════════════════════════════════════════════════

Task name: _______________________________________________________

Task description (1-3 sentences):
  ________________________________________________________________
  ________________________________________________________________
  ________________________________________________________________

Reviewer(s): __________________________  Date: ____________________

───────────────────────────────────────────────────────────────────────
  CORE PATTERN (Q1-Q3)
───────────────────────────────────────────────────────────────────────

Q1. Can the solution path be defined in advance?
    [ ] YES, known        → go to Q2
    [ ] NO, adaptive      → skip to Q3
  Evidence:
    ______________________________________________________________

Q2. Is the workflow fixed and stable across runs?
    [ ] YES, stable        → CORE = Sequential Workflow → skip to Q4
    [ ] NO, variable        → continue to Q3
  Evidence:
    ______________________________________________________________

Q3. Is the task's high-level structure articulable before execution?
    [ ] YES, articulable   → CORE = Planning + ReAct execution
    [ ] NO, emergent       → CORE = Single Agent + ReAct + tools
  Evidence:
    ______________________________________________________________

  → CORE PATTERN CHOSEN: ________________________________________

───────────────────────────────────────────────────────────────────────
  ADDITIVE LAYERS (Q4-Q5)
───────────────────────────────────────────────────────────────────────

Q4. Quality > speed AND criteria are checkable?
    [ ] YES: both          → ADD Reflection layer
    [ ] NO: vague criteria → DO NOT add reflection
    [ ] NO: latency budget → DO NOT add reflection (consider human review)
  Checkable criteria (if YES):
    ______________________________________________________________
    ______________________________________________________________

Q5. Specialization, context, or scale bottleneck?
    [ ] YES: specialization (name it): _______________________________
    [ ] YES: context overflow (describe): ____________________________
    [ ] YES: parallelizable scale (quantify): ________________________
    [ ] NO: keep single agent

  → If Q5 is YES → upgrade CORE to: Multi-Agent Specialist System
    Specialist roles: ____________________________________________

───────────────────────────────────────────────────────────────────────
  FINAL ARCHITECTURE
───────────────────────────────────────────────────────────────────────

Core pattern:         ________________________________________________
+ Reflection (Y/N):   ________________________________________________
+ Multi-agent (Y/N):  ________________________________________________

───────────────────────────────────────────────────────────────────────
  IMPLEMENTATION & DEPLOYMENT
───────────────────────────────────────────────────────────────────────

SDK primitives used (Concept 8.5):
  [ ] Agent (with output_type if structured)
  [ ] Runner.run(agent, input, max_turns=__)
  [ ] @function_tool decorators on N tools (N = __)
  [ ] handoff() between agents
  [ ] Agent.as_tool() for coordinator composition
  [ ] output_guardrail (if reflection layer)

Operational envelope primitives (Concept 8.6, if applicable):
  [ ] Trigger: ___________________________________________________
  [ ] step.run per: _____________________________________________
  [ ] step.wait_for_event for: __________________________________
  [ ] Concurrency cap: ______ per ______________________________
  [ ] Fan-out for: ______________________________________________
  [ ] Priority/fairness rule: ___________________________________

Cloud deployment subset needed (Concept 9-13 sidebars):
  [ ] FastAPI on ACA (always)
  [ ] Neon Postgres
  [ ] R2 (if files in/out)
  [ ] Sandbox + Bridge Worker (if agent runs code)
  [ ] Phoenix (if agentic: any pattern except pure sequential workflow)

───────────────────────────────────────────────────────────────────────
  RISK ANALYSIS
───────────────────────────────────────────────────────────────────────

Cost class (Concept 17):
  [ ] 1× baseline (Sequential workflow)
  [ ] 3-10× (Single agent + ReAct)
  [ ] 5-15× (Planning + ReAct)
  [ ] +2-3× core (with Reflection)
  [ ] 5-20× (Multi-agent)

Latency budget check:
  Expected latency: ___________________________________________
  User-facing budget: _________________________________________
  [ ] Fits           [ ] Tight           [ ] Will not fit

Most likely failure signal to watch (Concept 14):
  [ ] ReAct loops / revisits solved work
  [ ] Plan-execution divergence
  [ ] Reflection not improving output
  [ ] Multi-agent routing failures
  [ ] System feels complex but not better
  Mitigation if it appears:
    ______________________________________________________________

Eval signals to wire (Concept 9-13 sidebars):
  ______________________________________________________________
  ______________________________________________________________

───────────────────────────────────────────────────────────────────────
  ANTI-PATTERN CHECK (Concept 16.5)
───────────────────────────────────────────────────────────────────────

If a senior engineer reviewed this choice, what would they object to?
  ______________________________________________________________
  ______________________________________________________________

Counter-argument (why our choice is right despite the objection):
  ______________________________________________________________
  ______________________________________________________________

───────────────────────────────────────────────────────────────────────
  SIGN-OFF
───────────────────────────────────────────────────────────────────────

Architecture approved for: [ ] Prototype  [ ] Pilot  [ ] Production
Approved by:    ______________________________________________________
Re-review date: ______________________________________________________

═══════════════════════════════════════════════════════════════════════

टेम्पलेट जानबूझकर architecture प्रस्ताव के अनुसार 15-20 मिनट में चलने योग्य है। इसे भरना अनुशासन है; टीम वार्तालाप के दौरान प्रश्नों का दिखाई देना महत्वपूर्ण है। प्रति प्रमुख architecture निर्णय में से एक प्रिंट करें; भरे हुए संस्करणों को अपनी टीम के डिज़ाइन-निर्णय संग्रह में रखें।

सन्दर्भ

• Bala Priya C, "सही चुनना Agentic Design Pattern: एक निर्णय-वृक्ष दृष्टिकोण," Machine Learning Mastery, मई 15, 2026, machinelearningmastery.com/choosing-the-right-agentic-design-pattern-a-decision-tree-approach। इस पाठ्यक्रम की रीढ़ decision tree उसी की है।
• Yao et al., "ReAct: भाषा में तर्क और अभिनय का समन्वय Models" (2022), मूल ReAct पेपर।
• Wang et al., "Voyager: बड़ी भाषा Models के साथ एक ओपन-एंडेड सन्निहित Agent" (2023), planning + निष्पादन संरचना का प्रारंभिक उदाहरण।
• Shinn et al., "Reflexion: भाषा Agents मौखिक सुदृढीकरण सीखने के साथ" (2023), reflection pattern की औपचारिकता।
• OpenAI, "Agents SDK का अगला विकास" (अप्रैल 2026), SDK अद्यतन (model-native harness प्लस मूल sandbox निष्पादन) जो pattern को शिप करने योग्य बनाता है।
• agent-बिल्डिंग कोर्स (पैनवर्सिटी Agent Factory): agent loops और एक AI-native कंपनी का इंजन।
• eval-संचालित पाठ्यक्रम (Panaversity Agent Factory): eval-संचालित विकास और trace-to-eval अनुशासन।
• cloud deployment पाठ्यक्रम (Panaversity Agent Factory): cloud में OpenAI Agents SDK harness को तैनात करना।

---

Agent Factory ट्रैक के लिए pattern-चयन क्रैश कोर्स: पांच प्रश्न, पांच pattern, failure signals, और आपके deployment, आपके eval suite और operational envelope (Inngest) के साथ संरचना। एंकर लेख: Bala Priya C, Machine Learning Mastery, मई 15, 2026. agent डिज़ाइन (agent loops और tools) और deployment और eval पाठ्यक्रमों के production अनुशासन के बीच pattern-चयन अंतर को बंद करता है, जो operational envelope से बना है, अनुवाद के माध्यम से किसी भी agentic stack के लिए पोर्टेबल है। तालिका.

फ़्लैशकार्ड अध्ययन सहायता