एजेंट स्वायत्तता के स्तर

• एजेंटिक इंजीनियरिंग अब prompt writing से अधिक operational design के करीब जा रही है, और हर काम के लिए कितनी स्वायत्तता देनी है तथा उसे सहारा देने वाली validation method क्या होगी, यह साथ में तय करना ज़रूरी है
• एकल ladder model किसी एक एजेंट पर भरोसे को संख्या में व्यक्त करने के लिए उपयोगी है, लेकिन कई एजेंटों को एक साथ संभालने की क्षमता को agency और orchestration इन दो अक्षों में बाँटकर देखना चाहिए
• 0~5 स्तर का मॉडल केवल सुझाव देने वाले Assist से लेकर ऐसी Managed-by-exception orchestration तक जाता है जहाँ इंसान केवल अपवाद स्थितियों में हस्तक्षेप करता है, और ऊपरी स्तरों पर लक्ष्य, दायरा, प्रमाण, अधिकार और बजट अधिक स्पष्ट होने चाहिए
• Anthropic के Claude Code विश्लेषण में लगभग 4 लाख sessions और लगभग 2.35 लाख users के डेटा से यह पैटर्न दिखा कि योजना से जुड़े लगभग 70% निर्णय इंसान लेते हैं, जबकि execution का लगभग 80% Claude करता है
• परिपक्व एजेंट उपयोग का मतलब ऊँची स्वायत्तता का दिखावा करना नहीं, बल्कि जोखिम और rollback की क्षमता के हिसाब से calibrated autonomy लागू करना और validation bottleneck को संभालना है

---

prompt writing से operational design की ओर बढ़ती agentic engineering

• agentic engineering का केंद्र prompt writing से operational design की ओर खिसक रहा है
• software factory, goal, loop, background session, subagent, hook, sandbox, और agents द्वारा agents को approve करने जैसे तरीके अब सामने आ रहे हैं
• Claude Code और Codex को इस बदलाव को दिखाने वाले प्रतिनिधि products के रूप में देखा जाता है
• engineer जोखिम घटाने और rollback आसान बनाने के लिए कम स्वायत्तता का उपयोग कर सकते हैं, जबकि स्पष्ट activities या बड़े codebase refactoring के लिए अधिक स्वायत्तता और parallel agent fleet का उपयोग किया जा सकता है
• मुख्य सवाल यह है कि हर task के लिए किस स्तर की स्वायत्तता की अनुमति दी जाए, और कौन-सी validation उस स्तर को सुरक्षित रख सकती है

एकल ladder की जगह दो अक्षों में स्वायत्तता को देखना

• Steve Yegge की “Welcome to Gas Town” में बताए गए single-axis ladder का उपयोग एक एजेंट पर भरोसे को संख्या में व्यक्त करने के लिए उपयोगी है
• 2026 की शुरुआत में, जब काम delegation से orchestration की ओर जा रहा था, तब भी single axis जोखिम मापने के एक मोटे proxy की तरह काम करता था
• जब कई एजेंट एक साथ चलने लगते हैं, तब केवल एक स्तर से multi-agent capability को समझाना कठिन हो जाता है
• स्वायत्तता पर चर्चा अक्सर दो अलग सवालों को मिला देती है
  • एक एजेंट को इंसान से कितनी दूर तक भेजा जा सकता है
  • कई एजेंटों को कितनी अच्छी तरह समन्वित किया जा सकता है
• इन्हें अलग करने के लिए दो अक्षों की ज़रूरत है
  • agency: एक एजेंट सुझाव, सीमित काम, या लक्ष्य प्राप्ति को कितनी स्वायत्तता से कर सकता है
  • orchestration: एक thread से लेकर कई task tree, backlog·issue tracker·schedule आधारित निरंतर काम तक कितना समन्वय किया जा सकता है

agency और orchestration का अर्थ

• agency axis के निचले स्तर पर एजेंट संभावित actions सुझाता है और इंसानी निर्णय का इंतज़ार करता है
• मध्यम स्तर पर एजेंट एक विशेष काम करता है लेकिन उसका दायरा सीमित रहता है, और वह किए गए काम की रिपोर्ट प्रमाण सहित देता रहता है ताकि इंसान समायोजन कर सके
• ऊँची agency में एजेंट लक्ष्य की दिशा में experiment, learning, testing, blockage handling, सवाल पूछना, और दूसरे approaches आज़माना भी करता है, और उसे प्रमाण के रूप में वापस देता है
• orchestration axis का निचला स्तर एक एजेंट और एक thread है
• मध्यम स्तर पर कई एजेंट अपने-अपने अलग worktree में अलग-अलग लक्ष्यों पर काम करते हैं
• ऊँचे स्तर पर orchestrator backlog, issue tracker, schedule और queue को लगातार चलने वाले काम में बदल देता है, और इंसान केवल failure की स्थिति में हस्तक्षेप करता है; यह management by exception जैसा रूप है
• संबंधित features और products के उदाहरण इस प्रकार हैं
  • Claude Code: /plan, /goal, /loop, /background, /batch, /code-review, /security-review, subagents, hooks, checkpoints, agent delegation और management methods, background sessions, agent team patterns, /schedule argument
  • Codex: local·cloud threads, Goal mode, worktree, Automations, subagents, review panel, GitHub code review, hooks, sandbox, Auto-review, rerun

तीन युग और छह स्तर

• ladder को नीचे से ऊपर पढ़ने पर ऐसा लगता है जैसे agency और orchestration दोनों साथ बढ़ रहे हों
• छह स्तर तीन युगों में बँटे हैं
  • वह युग जिसमें इंसान ड्राइविंग सीट पर है, एजेंट सहायक है और इंसानी input का इंतज़ार करता है
  • वह युग जिसमें एजेंट सीमित task या goal संभालता है, लेकिन इंसान उसे tune और validate करता है
  • orchestration का वह युग जिसमें system कई एजेंटों में काम बाँटता है, और इंसान मुख्यतः समस्या आने पर हस्तक्षेप करता है
• वास्तविक engineering में दिन भर अलग-अलग स्तरों के बीच आना-जाना स्वाभाविक है

Level 0: Assist

• एजेंट आम तौर पर अच्छे और कभी-कभी लगभग perfect सुझाव देता है, लेकिन execute करना है या नहीं यह फैसला हमेशा इंसान का होता है
• उदाहरण हैं autocomplete, inline edit suggestion, या chat में ऐसे बदलाव पर चर्चा करना जिसे अभी किसी ने own नहीं किया है
• यह महंगी गलती वाले काम, बहुत छोटे बदलाव, या ऐसे कामों के लिए उपयुक्त है जिनमें अभी judgment बन रहा हो
• validation अधिकतर local स्तर पर होती है

Level 1: Supervised action

• एजेंट आपकी जगह edit करता है या command चलाता है, लेकिन महत्वपूर्ण execution से पहले इंसानी approval माँगता है
• यह उस default posture के करीब है जिसे ज्यादातर लोग इस्तेमाल करते हैं
• यह local sandbox में changes apply करने से पहले approval लेकर, या interactive session में किया जा सकता है
• हर approval इस बात की स्वतंत्र validation की तरह काम करता है कि यह change लागू करना ठीक है या नहीं
• मुख्य failure mode है approval fatigue
  • आप जो भी approve करें, हर approval एक जैसा लगने लग सकता है
  • इसका सामना diff को जल्दी से देखकर, heuristics अपनाकर, किसी और से check कराकर, या एजेंट को ज़िम्मेदारी लेने देकर किया जा सकता है
• Codex Auto-review इस समस्या को boundary condition की final approval एक अलग reviewer agent को सौंपकर संभालता है

Level 2: Scoped task delegation

• यह वह स्तर है जहाँ सीमित task एजेंट को सौंपा जाता है
• task में स्पष्ट goal, constraints और done state के साथ task definition होनी चाहिए
• इंसान पास ही रहता है और बीच में रोक सकता है, लेकिन ज़्यादातर सीधे शामिल नहीं होता
• software engineering में इसे केंद्र के करीब का स्तर माना जाता है
• validation इंसान की सीधी जाँच से हटकर उस प्रमाण की ओर जाती है जिसे एजेंट तैयार कर सकता है
  • passed automated tests
  • उचित types
  • lint suggestions
  • screenshots
  • reproduction steps
  • example-based sources

Level 3: Goal-driven autonomy

• एजेंट तब तक लक्ष्य प्राप्ति के लिए आवश्यक काम करता है जब तक कोई विशेष condition पूरी न हो जाए
• prompt mode में prompt itself ही goal बन जाता है
  • उदाहरण: “क्या इस page का time-to-interactive 1 second से कम किया जा सकता है?”
• Codex में Goal mode इसी के अनुरूप है, जहाँ एजेंट plan -> act -> test -> review चरणों को दोहराता है और success criteria पूरा न होने पर रुक जाता है
• Claude Code में /goal, /loop, /schedule commands इस स्तर के उदाहरण हैं
• इस स्तर के उपयोगी होने के लिए stop condition ऐसी measurable होनी चाहिए जिसे automated किया जा सके
• “user experience को overall बेहतर बनाओ” या “codebase को अधिक testable बनाओ” जैसे अस्पष्ट goals इसके लिए उपयुक्त नहीं हैं
• बेहतर goals वे हैं जो specific, measurable और automatable हों
  • static analysis से बच निकलने वाले production bugs ढूँढना
  • load time कम करना
  • explicit any के बिना strict TypeScript build सुनिश्चित करना
  • पूरे dependency set को इस तरह classify करना कि केवल समझने योग्य और tests pass करने वाली dependencies बचें
• production bug ढूँढने के लिए एजेंट को production-जैसे environment में होना चाहिए

Level 4: Parallel delegation

• यह वह स्तर है जहाँ कई एजेंट parallel में काम करते हैं
• हर एजेंट काम का अलग हिस्सा संभालता है
• सबसे बड़ा bottleneck यह तय करना है कि किस हिस्से को सौंपा जाए; यानी decomposition
• सहायक features में subagents, background sessions, /batch, worktree, agent teams आदि शामिल हैं
• मुख्य failure mode है false parallelism
  • अगर कई एजेंट overlapping हिस्सों पर एक साथ काम करें, तो अधिक काम होने के बजाय merge conflict और duplicate decisions पैदा हो सकते हैं
• इसे अच्छी तरह चलाने के लिए एजेंटों का एक-दूसरे से isolated होना ज़रूरी है
  • हर एजेंट के पास उसकी own files और state होनी चाहिए
  • हर एजेंट की अपनी review queue भी होनी चाहिए
• हर एजेंट पर token cost आती है, और यह साथ चल रहे agents की संख्या के अनुपात में बढ़ती है
• इंसानी पक्ष में कुछ संख्या के बाद अतिरिक्त एजेंट जोड़ने की marginal cost orchestration tax के कारण बढ़ने लगती है

Level 5: Managed-by-exception orchestration

• success की परिभाषा और लागू की जाने वाली policies इंसान तय करता है, और manager agent trigger मिलने पर जागकर काम बाँटता है
• trigger के उदाहरण हैं नया issue, नया task, या clock
• manager agent worker agents को deploy करता है, progress monitor करता है, outputs validate करता है, और failure होने पर retry करता है
• conditions पूरी होने पर वह अधिक सक्षम agent या इंसान तक escalate करता है, और results को aggregate करके PR जैसे work artifacts और evidence को बाहरी system में लौटाता है
• इस स्तर की तुलना factory से की जाती है
  • input है issue tracker या backlog
  • output है कई resolved issues या bugs
• एजेंट पर्याप्त boundaries और ज़रूरत पड़ने पर exit path वाले isolated environment में काम करते हैं
• इस factory को क्या करना है, यह manager agent द्वारा परिभाषित operating system तय करता है
• OpenAI ने Symphony के लिए spec प्रस्तावित किया है, जिसमें Linear board केंद्र में है
  • हर issue का अपना agent workspace होता है
  • एजेंट यह जाँचता रहता है कि वह अपने workspace की spec file में परिभाषित goal की दिशा में लगातार प्रगति कर रहा है या नहीं
• orchestration की अग्रिम पंक्ति अब ऐसी persistent agent factory बनाना है जहाँ सैकड़ों या हज़ारों एजेंट काम करें
• इस स्तर पर independent validation और अधिक महत्वपूर्ण हो जाती है
  • implementer और reviewer को अलग रखना
  • test runner और QA को अलग रखना
  • security checks को अलग रखना
  • acceptance के लिए process gates को अलग रखना

जोखिम और rollback क्षमता स्वायत्तता की ऊपरी सीमा तय करते हैं

• Anthropic के Claude Code पर research में पाया गया कि कुछ सबसे कठिन tasks में Claude Code ने user interruption की तुलना में दो गुना से भी अधिक बार clarification questions पूछे
• अनुभवी users, जिनके लगभग 750 sessions थे, 50 से कम sessions वाले users की तुलना में auto-approval और interruption का अधिक उपयोग करते थे और progress पर नज़र रखते थे
• Anthropic का व्यापक analysis 2025 के अक्टूबर से 2026 के अप्रैल तक लगभग 2.35 लाख users के लगभग 4 लाख sessions को कवर करता है
• हर session में यह देखा जा सका कि user ने हर prompt पर कितने actions माँगे, क्या auto-approve किया, और interruption कितनी बार हुआ
• इंसान लगभग 70% planning decisions लेते हैं, जबकि Claude execution का लगभग 80% करता है
• ऊँची स्वायत्तता का मतलब इंसान को loop से बाहर करना नहीं, बल्कि हर step खुद करने से हटकर अगली दिशा तय करने की भूमिका में जाना है
• यह तय करने के लिए कि कोई बड़ा AI system सच में उच्च स्वायत्तता से काम कर रहा है या नहीं, तीन सवाल ज़रूरी हैं
  • कितनी जल्दी पता चल सकता है कि क्या गलत हो रहा है
  • जो हो रहा है उसे कितनी साफ़ तरह से rollback किया जा सकता है
  • कौन-सा प्रमाण दिखाता है कि किया जा रहा काम सही है
• अगर जवाब है “जल्दी पता नहीं चल सकता, rollback कठिन है, और summary पर भरोसा करना पड़ेगा”, तो वह उच्च स्वायत्तता नहीं है

एजेंट रन से पहले contract में क्या होना चाहिए

• हर agent run से पहले एक contract चाहिए जो परिभाषित करे कि क्या किया जाना है
• contract में ये बातें शामिल होनी चाहिए
  • goal: activity या technique नहीं, बल्कि हासिल किया जाने वाला परिणाम
  • scope: काम का domain और अनुमति प्राप्त techniques
  • non-goals: जो इस उद्देश्य का हिस्सा नहीं हैं
  • tools और permissions: एजेंट बाहरी दुनिया से कैसे interact करेगा
  • stop conditions: कब रुकना है, संभव हो तो measurable variables के साथ
  • evidence: completion को independently verify करने वाले tests, screenshots, logs, database records आदि
  • escalation: किस स्थिति में कौन हस्तक्षेप करेगा, और एजेंट को कौन चलाएगा
  • budget: time, effort, token limits
• token बड़े AI models का budget हैं, और इसमें attempts की संख्या तथा parallelism की सीमा भी शामिल हो सकती है

metrics स्वायत्तता को थोड़ा अधिक भरोसेमंद बनाते हैं

• metrics को केवल बाद में तय करना पर्याप्त नहीं हो सकता
• metrics को पहले से एक संक्षिप्त document में रखा जा सकता है, और इससे स्वायत्तता अधिक भरोसेमंद बनती है
• स्वायत्तता के स्तर के अनुसार ट्रैक किए जा सकने वाले metrics के उदाहरण हैं
  • interventions के बीच औसत समय
  • accepted task criteria के तहत अधिकतम unattended runtime
  • sandbox में किए गए actions बनाम escalated actions का अनुपात
  • auto-approved actions बनाम rejected actions का अनुपात
  • प्रति human instruction एजेंट actions की औसत संख्या
  • clarification request rate
  • interruption request rate
  • accepted change पर review time
  • trust level के अनुसार rework rate
  • trust level के अनुसार defect escape rate
  • accepted change पर token cost
• एक single agent जो इंसान से लगातार handoff लेकर व्यस्त रहता है, dashboard लगे Level 4 के करीब है; जबकि automated intake·retry और पर्याप्त evidence के बिना आगे न बढ़ने वाला conservative agent असली gates वाले Level 5 के अधिक करीब है

readiness और autonomy level का चयन

• tasks को risk और rollback की क्षमता के आधार पर classify करना चाहिए
• autonomy को conservative तरीके से लागू करना चाहिए, और केवल तब बढ़ाना चाहिए जब उच्च स्तर को support करने वाला evidence जमा हो जाए
• मजबूत tests, reviewer agents, और साफ़ rollback path वाला payment engine refactoring, बिना gold standard वाले documentation automation से अधिक स्वायत्तता को support कर सकता है
• autonomy level को task के नाम नहीं, बल्कि validation process का अनुसरण करना चाहिए

स्वायत्तता के चार anti-patterns

• Autonomy as status

  • एजेंट की autonomy grade एक अर्थहीन status badge की तरह काम करने लगती है
  • उच्च autonomy को safety नहीं, capability के प्रमाण की तरह देखा जाता है, और एजेंट उस स्तर पर चलने लगता है जिसे validation support नहीं करती
  • सही autonomy level चुनने और सीमा न लांघने वाले लोगों की सराहना और reward होना चाहिए

• Permission laundering

  • approval fatigue के कारण AI agents और tools को आवश्यकता से अधिक broad access दे दिया जाता है
  • sandbox profiles, scoped write roots, allowed commands lists, hooks, Auto-review जैसी boundaries को मज़बूत करना चाहिए

• Summary substitution

  • एजेंट के काम की summary review की जगह ले लेती है
  • इसे manual review जैसे evidence packet के साथ बाँधना चाहिए
  • इसमें diff, tests, logs, screenshots, reviewer findings, risks और gaps शामिल हो सकते हैं

• Fleet cosplay

  • दर्जनों एजेंट parallel में चलाए जाते हैं, लेकिन इंसान अभी भी सभी dependencies को manually coordinate करता रहता है
  • shared state, ownership rules और बेहतर dependency tracking manual coordination की ज़रूरत घटाते हैं
  • छोटा WIP limit coordination steps को encode और document करने पर ध्यान देता है, जिससे orchestration automation तक पहुँचा जा सकता है

सुरक्षित तरीके से ऊपर कैसे बढ़ें

• हाल की agent-assisted 10 tasks की समीक्षा करने वाला calibration exercise सुझाया गया है
  • हर task का autonomy level
  • risk
  • rollback की आसानी
  • validation requirements को पूरा करने के लिए बनाया गया evidence
  • review time
  • rework हुआ या नहीं
  • क्या अगली बार भी वही autonomy level उपयुक्त रहेगा
• एक समय में केवल एक axis पर ऊपर बढ़ना चाहिए
• शुरुआत का बिंदु है एक single supervised agent द्वारा एक सीमित task करना, जो defendable success evidence तैयार करे
• इसके बाद तीन दिशाओं में धीरे-धीरे विस्तार किया जा सकता है
  • read-heavy exploration tasks को parallelize करना
  • सीमित file ownership rules वाले अलग worktree में write agents जोड़ना
  • repeated automation जोड़ने के बाद issue या voice आधारित agent-driven orchestration जोड़ना
• हर स्तर वृद्धि के साथ नए failure modes को संभालने वाले नए safeguards चाहिए
• failure modes इस प्रकार हैं
  • लंबे single-agent runs: drift, context corruption, missed communication, goal deviation
  • background tasks: stale assumptions, weak handoff
  • बहुत अधिक parallel work: merge conflict, duplicate decisions
  • बहुत अधिक repeated work: silent token spending, stale prompts
  • managed-by-exception: लंबी review queues, notification fatigue
• ज़्यादा आक्रामक भरोसा करने के बजाय दायरा छोटा करना, बेहतर evidence लेना, सस्ता rollback path बनाना, gates मज़बूत करना, और ownership rules अधिक स्पष्ट करना चाहिए

हर स्तर के लिए उपयुक्त उपयोग

• Level 0 सूक्ष्म कामों और judgment बन रही स्थिति के लिए सबसे उपयुक्त है
• Level 1 उन अधिकांश exploratory tasks के लिए उपयुक्त है जो अच्छी तरह समझी गई boundaries के पास हों
• Level 2 उन अधिकांश सीमित tasks के लिए उपयुक्त है जहाँ unknown dependencies और unexpected problems हो सकते हैं
• Level 3 तब उपयुक्त है जब success conditions को पर्याप्त स्पष्टता से बताया जा सके
• Level 4 तब उपयुक्त है जब काम को success conditions के आधार पर साफ़ तौर पर बाँटा जा सके
• Level 5 तब उपयुक्त है जब कई success conditions के बीच आवश्यक coordination और communication पूरी तरह encode हो चुके हों

validation आगे भी bottleneck बनी रहती है

• आज के confidence और tools के स्तर के बावजूद, AI agents के साथ काम करने वाली परिपक्व engineering teams का रुख calibrated autonomy ही है
• निकट भविष्य में ऐसे loops डिज़ाइन करने होंगे जो जानते हों कि कब काम करना है, कब validate करना है, और कब सवाल पूछना है
• engineer की क्षमता आगे भी सही autonomy level चुनने, उसके अंधेरे पक्ष को रोकने वाले patterns बनाने, और defendable evidence तैयार करने में ही निहित रहेगी