AI एजेंट लूप: सेल्फ-करेक्टिंग कोडिंग एजेंट काम कैसे खुद पूरा करते हैं

ज़्यादातर लोग आज भी AI कोडिंग एजेंट को जिस तरह इस्तेमाल करते हैं, वह पिंग-पॉन्ग जैसा लगता है। आप prompt देते हैं, वह जवाब देता है, आप गलती पकड़ते हैं, फिर से prompt देते हैं। आप ही correction इंजन हैं, और हर एक turn पर आप लूप के अंदर बैठे रहते हैं।

एक लूप इसे पलट देता है। आप बताते हैं कि आपको क्या चाहिए, एजेंट काम पर लग जाता है, अपनी checklist खुद लिखता है, अपने कमज़ोर हिस्से खुद ढूँढता है, और तब तक दोबारा चलता रहता है जब तक नतीजा टिकाऊ न हो जाए। अब गलतियाँ पकड़ने वाले आप नहीं रहते। एजेंट अपनी गलतियाँ खुद पकड़ता है।

यह बदलाव कोई hype नहीं है। जिन लोगों ने ये टूल बनाए हैं, वे खुद इसी पर भरोसा करते हैं। Claude Code के निर्माता Boris Cherny और Cat Wu agent loops में कोडिंग की बात करते हैं। Geoffrey Huntley, जिन्होंने "Ralph loop" को यह नाम दिया, रातभर एजेंट्स को एक सादे while लूप में चलाते हैं। इस pattern का अब एक नाम है, और Instagram से तीन prompt कॉपी करने से पहले इसे समझ लेना फायदेमंद है।

prompt पिंग-पॉन्ग से लूप तक

एक अकेला prompt एक one-shot होता है। आप पूछते हैं, जवाब मिलता है, लेन-देन खत्म। उसे बेहतर करने के लिए आपको कमी खुद नोटिस करनी होती है और दोबारा prompt देना होता है। इसे किसी असली feature के पैमाने तक ले जाइए, और आप हाथ से दर्जनों micro-correction कर रहे होते हैं।

एक AI एजेंट लूप उस कमी को एजेंट के अंदर ही बंद कर देता है। आप एक goal तय करते हैं, एजेंट प्लान बनाता है, काम करता है, नतीजा देखता है, और correct करता है, बार-बार, जब तक goal पूरा न हो जाए। आप गायब नहीं हो जाते, आप आखिर में रिव्यू करते हैं। पर अब आप हर iteration पर रुकावट नहीं रहते।

prompt पिंग-पॉन्ग आपको हर turn पर लूप के अंदर रखता है। एक असली लूप एजेंट को उसमें रखता है।

AI एजेंट लूप असल में होता क्या है

हर agentic लूप एक ही चार चरणों पर चलता है: plan, act, observe, correct। एजेंट अगला कदम तय करता है, उसे उठाता है (कोड लिखता है, कोई कमांड चलाता है, कोई फाइल पढ़ता है), देखता है कि क्या हुआ, और अपने को adjust करता है। Claude कोड लिखता है, टेस्ट चलाता है, एक failure देखता है, उसे fix करता है, फिर से टेस्ट चलाता है। यही feedback पूरा कमाल है। यही चीज़ लूप को सिर्फ दोहराव की जगह सेल्फ-करेक्टिंग बनाती है।

लूप का सबसे मज़बूत रूप इन चरणों को तीन भूमिकाओं में बाँट देता है: एक जो प्लान बनाए, एक जो बनाए, एक जो रिव्यू करे। इन्हें अलग रखना ही वह चीज़ है जो एजेंट को उसी साँस में अपनी ही कॉपी जाँचने से रोकती है जिसमें वह उसे लिखता है।

तीन-कमांड वाला लूप जिसे आप आज ही कॉपी कर सकते हैं

यह रहा वह सेटअप जो अभी चलन में है, तीन Claude Code slash कमांड के रूप में दोबारा बनाया गया। हर एक को एक बार पेस्ट कीजिए, एजेंट कमांड बना देता है, फिर आप उन्हें क्रम से चलाते हैं।

प्लानर, /spec:

मुझसे एक बार में एक सवाल पूछते हुए interview करो जब तक तुम पूरी तरह समझ न जाओ
कि मैं क्या चाहता हूँ। फिर specs/project.md में एक सटीक प्लान लिखो: objective,
सटीक requirements, edge cases, और क्या scope में है बनाम क्या scope से बाहर।
इसे छोटा और साफ रखो, कोई उपन्यास नहीं।

बिल्डर, /build:

specs/project.md पढ़ो और ठीक वही बनाओ जो उसमें लिखा है, उससे ज़्यादा कुछ नहीं।
जब काम पूरा हो जाए, प्लान की हर requirement की सूची बनाओ और बताओ कि तुमने
कौन-कौन सी पूरी की।

रिव्यूअर, /review:

जो बनाया गया उसकी specs/project.md से तुलना करो, requirement दर requirement।
हर एक के लिए बताओ कि वह पूरी हुई या नहीं। ज़रूरी corrections लिखो और उन्हें
वापस /build को सौंपो। तभी मंज़ूरी दो जब पूरा प्लान कवर हो जाए।

तीन कमांड, एक लूप: spec प्लान लिखता है, build उसे लागू करता है, review उसे प्लान के मुकाबले जाँचता है और corrections वापस build को भेजता है। यह तब तक चलता रहता है जब तक हर requirement पूरी न हो जाए।

प्लान ही सच का स्रोत है। रिव्यू build को उसके मुकाबले नापता है, किसी अंदाज़े के मुकाबले नहीं।

यह अंदर से spec-driven coding ही है: चैट का इतिहास नहीं, बल्कि लिखा हुआ spec वह चीज़ है जिसके पैमाने पर एजेंट को परखा जाता है। GitHub का ओपन-सोर्स Spec Kit इसी विचार को /specify, /plan, /tasks और /implement के साथ औपचारिक रूप देता है, और यह Claude Code, Copilot, Cursor, Codex CLI और Gemini CLI सभी पर समान रूप से चलता है।

एक ताज़ा context लूप को क्यों काम कराता है: Ralph loop

Geoffrey Huntley ने इसके सबसे बेलाग रूप को 2025 के मध्य में यह नाम दिया: Ralph loop। विचार यह है कि एक सादा shell लूप एजेंट को एक लिखे हुए spec के मुकाबले वही prompt बार-बार देता है, उसे एक task चुनकर ship करने देता है, फिर एक बिल्कुल नया एजेंट साफ context के साथ शुरू करता है और वही identical prompt दोबारा देता है।

while has_more_todos; do
  agent --prompt "todo.md से अगले task पर काम करो" --non-interactive
done

जो हिस्सा सीधे समझ नहीं आता, वह है context का रीसेट। एक लंबा सेशन सड़ने लगता है: window पुराने तर्क, बंद गलियों और बासी फाइल कंटेंट से भर जाती है, और model चुपके से instructions छोड़ने लगता है। हर Ralph iteration एक नया एजेंट है जो disk से मौजूदा repo और todo list पढ़ता है, काम की एक इकाई करता है, commit करता है, और साफ-सुथरा बाहर निकल जाता है। Huntley ने इसका नाम Simpsons के किरदार पर जानबूझकर रखा: यह काम करने के लिहाज़ से बहुत बेवकूफ़ाना लगता है, और यह काम करता है। अगर आपने किसी लंबे सेशन को hallucinate करते देखा है, तो आप पहले से जानते हैं कि एक ताज़ा window एक भरी-भरकम window को क्यों हरा देती है।

Claude Code के /loop और /goal

Claude Code सीधे loop primitives के साथ आता है। /goal एक टिकाऊ end state तय करता है, यानी "हो गया" कैसा दिखता है, और Claude हर पास के बाद उसी के मुकाबले अपनी progress को आँकता है, सिर्फ अगला कदम चलाने के बजाय। /loop किसी task को एक cadence पर या किसी condition के टिकने तक दोहराता है, जिसके रूप /loop every 10m या /loop until: <condition> जैसे होते हैं। दोनों को साथ इस्तेमाल करें तो वे एक खुद-चालित और खुद-रुकने वाला लूप बना देते हैं: Claude मौजूदा state और goal के बीच के फर्क पर काम करता है, और तब रुकता है जब goal पूरा हो जाए या आप Ctrl+C दबा दें।

जो बात मायने रखती है: एक लूप continuity बनाए रखता है। उसे याद रहता है कि उसने क्या आज़माया और क्यों नाकाम रहा, इसलिए हर पास पिछले पर टिकता है, उसी बंद गली को दोहराने के बजाय। यह Ralph के साफ-context रीसेट का बिल्कुल उल्टा trade-off है, और दोनों सही हैं। कसी हुई सेल्फ-करेक्शन के लिए continuity, और जब window सड़ रही हो तब ताज़ा context। कौन-सा चुनना है यह जानना ही असली हुनर है।

वही लूप, हर provider के यहाँ

लूप कोई Claude feature नहीं है, यह वह दिशा है जिस ओर पूरा क्षेत्र बढ़ रहा है। नाम बदलते हैं, आकार नहीं।

Codex CLI ने इस लूप को सार्वजनिक रूप से सबसे आगे तक ले गया। OpenAI की टीम ने अपने /goal को Ralph loop पर अपने अंदाज़ के रूप में पेश किया, और a16z के Andrew Chen ने उसे रातभर एक device driver पर 14 घंटे लगातार बिना किसी दखल के चलने दिया। उन्होंने यह भी कहा कि इससे "token खपत 10,000 गुना" बढ़ जाएगी, जो किसी एजेंट को आधे दिन तक पीसने देने की ईमानदार कीमत है।

पेच: एक लूप हर चीज़ को बढ़ा देता है

एक लूप सिर्फ अच्छे output को ही नहीं बढ़ाता, वह एक खराब प्लान को भी बढ़ा देता है। किसी सेल्फ-करेक्टिंग एजेंट को एक धुँधले spec पर लगाइए और वह पूरे आत्मविश्वास से गलत चीज़ बना देगा, उसी धुँधले spec के मुकाबले उसे रिव्यू करेगा, और मंज़ूरी दे देगा। प्लान ही लीवर है। एक तीखा spec दस prompt बचाता है, एक धुँधला spec सौ बरबाद कर देता है।

दो failure modes पर नज़र रखें। लागत बेकाबू हो जाती है: हर iteration token जलाती है, और किसी अस्पष्ट goal पर बिना सीमा का एक लूप बहुत सारे जला सकता है। और लूप हमेशा के लिए चल सकता है, या तो जीत का ऐलान करते हुए या किसी ऐसे लक्ष्य का पीछा करते हुए जिसे वह कभी पूरा नहीं कर सकता। उसे एक सीमा दें: एक साफ until condition, एक token की छत, या merge से पहले एक human checkpoint। बिना रुकने वाला लूप autonomy नहीं है, यह एक बेकाबू भगदड़ है।

पूरे fleet पर लूप चलाना

एक अकेले सेल्फ-करेक्टिंग एजेंट को सँभालना आसान है। असली फायदा तब दिखता है जब आप एक साथ कई चलाते हैं, हर एक अपने task पर लूप करता हुआ, और ठीक वहीं एक terminal को निहारना पैमाने पर टिकना बंद कर देता है।

AgentsRoom इसी के लिए बना है। यह एक मल्टी-एजेंट cockpit है: हर एजेंट की एक भूमिका, एक live status dot और अपना रंग होता है, और आप पूरे fleet को एक ही window से देखते हैं। backlog पर एक ticket डालिए और एक एजेंट उसे उठा लेता है, अपना plan-build-review लूप चलाता है, और आपको एक साफ diff सौंप देता है। यही spec-driven AI coding व्यवहार में है: ticket ही spec है, एजेंट लूप चलाता है, आप नतीजा रिव्यू करते हैं।

चूँकि लंबे लूप context को सड़ाते हैं, AgentsRoom इस पर नज़र रखता है। हर एजेंट हर turn के अंत में एक लाइन का status लिखता है, और जब कोई एजेंट लगातार दो turns तक उसे अपडेट करना बंद कर देता है, तो एक चेतावनी आती है जिसमें साफ context पर एक-क्लिक restart होता है, ठीक वही ताज़ा-window रीसेट जिस पर Ralph loop टिका है। यह कैसे काम करता है, यह context drift detection पेज पर पढ़िए।

और चूँकि लूप provider-agnostic है, आप किसी एक से बँधे नहीं हैं। एक ticket Claude Code पर चलाइए, अगला Codex पर, एक और Gemini CLI पर, सब एक ही dashboard में, हर एक अपने git worktree में लूप करता हुआ ताकि समानांतर एजेंट कभी आपस में न टकराएँ। काम छोड़ने से पहले उन्हें चालू कर दीजिए और सुबह diffs रिव्यू कर लीजिए, यही background coding agents और night shift का पूरा मतलब है।

goal एक बार तय कीजिए, लूप को उसे पूरा करने दीजिए, आखिर में रिव्यू कीजिए। AgentsRoom डाउनलोड कीजिए, provider compatibility matrix देखिए, और per-agent review तथा multi-provider support के बारे में और पढ़िए।