एक Promptware एक स्व-निहित (self-contained) एजेंट यूनिट है जो अपने स्वयं के निर्देशों, मेमोरी (Memory), टूल अनुमतियों (Tools) और निष्पादन इतिहास (Logs) को फ़ाइलों के रूप में संग्रहीत करती है, और प्रत्येक रन के बाद अपने निर्देशों और मेमोरी को संशोधित करती है। Ivy Tendril में, योजना के जीवनचक्र का प्रत्येक चरण—योजना का मसौदा तैयार करने से लेकर पुल रिक्वेस्ट खोलने तक—इनमें से ही किसी एक यूनिट द्वारा संचालित होता है। ये निर्देश रिपॉजिटरी में वर्ज़न-नियंत्रित (version-controlled) फ़ाइलें होते हैं, इसलिए किसी भी अन्य स्रोत फ़ाइल की तरह ही इन्हें टीम में रिव्यू किया जा सकता है, उनका diff देखा जा सकता है, उन्हें रोलबैक किया जा सकता है और साझा किया जा सकता है। यह लेख एक यूनिट की संरचना, इसके रन लूप (run loop), सात अंतर्निहित promptwares और ध्यान देने योग्य दो विफलता मोड्स (failure modes) की व्याख्या करता है।

Promptware यूनिट में क्या शामिल होता है

एक promptware यूनिट चार भागों वाली एक डायरेक्टरी होती है। प्रत्येक भाग की एक विशिष्ट ज़िम्मेदारी होती है।

भाग	सामग्री	इसे कौन लिखता है
`Program.md`	वे निर्देश जिनका एजेंट अपने चरण के दौरान पालन करता है। रन के बाद एजेंट द्वारा संशोधित, मनुष्यों द्वारा समीक्षित।	एजेंट और मनुष्य
`Memory/`	कोडबेस और टीम के तौर-तरीकों के बारे में स्थायी सीख। प्रत्येक रन के बाद जोड़ी जाती है।	एजेंट
`Tools/`	इस चरण के लिए निर्धारित सीमित अनुमतियाँ: एजेंट कौन से कमांड्स, फ़ाइलें और इंटीग्रेशन उपयोग कर सकता है।	मनुष्य
`Logs/`	निष्पादन इतिहास: एजेंट ने क्या पढ़ा, क्या चलाया और क्या बदला, और वह किस निष्कर्ष पर पहुँचा।	एजेंट (केवल अपेंड)

Program.md गद्य के रूप में होता है, कोड नहीं। योजना-निष्पादन यूनिट के लिए एक सेक्शन कुछ इस तरह दिख सकता है:

## पुल रिक्वेस्ट खोलने से पहले

- रिपॉजिटरी के रूट से `pnpm lint` और `pnpm test` चलाएं। यदि दोनों में से कोई भी विफल हो जाता है तो PR न खोलें।
- diff को योजना में नामित फ़ाइलों तक ही कड़ाई से सीमित रखें। यदि किसी अन्य फ़ाइल को बदलना आवश्यक हो, तो PR विवरण में इसका कारण बताएं।
- कमिट संदेश प्रारूप `type(scope): summary` का उपयोग करें।

एक मेमोरी प्रविष्टि किसी ऐसी सीखी गई बात को दर्ज करती है जो कोड से तुरंत स्पष्ट नहीं होती और जिसके बारे में भविष्य के रनों को पता होना चाहिए:

### 2026-08-21, योजना #412

`src/billing/` के अंतर्गत बिलिंग मॉड्यूल में कोई टेस्ट नहीं हैं। इसे रीफैक्टर करने से पहले टेस्ट जोड़ें।
`pnpm test` पहले डेटाबेस माइग्रेशन चलाता है; क्लीन चेकआउट पर एक रन में लगभग चार मिनट लगते हैं।

ये दोनों फ़ाइलें प्रकृति में भिन्न हैं। प्रोग्राम बताता है कि क्या करना है। मेमोरी बताती है कि इस रिपॉजिटरी के बारे में क्या सच है। इन्हें अलग रखने से एक समीक्षक कार्यप्रणाली में बदलाव स्वीकार किए बिना किसी नए तथ्य को स्वीकार कर सकता है, और इसके विपरीत भी।

रन लूप

प्रत्येक promptware रन उन्हीं चार चरणों का पालन करता है।

प्रोग्राम लोड करना। एजेंट Program.md और Tools/ में दी गई अनुमतियों को पढ़ता है। उन अनुमतियों के बाहर कुछ भी उसके लिए उपलब्ध नहीं होता है।
मेमोरी पढ़ना। एजेंट Memory/ को पढ़ता है ताकि पिछले रनों से सीखे गए तथ्य काम शुरू करने से पहले ही संदर्भ में मौजूद हों।
कार्य निष्पादित करना। एजेंट उस चरण का कार्य करता है: योजना का मसौदा तैयार करना, उसका विस्तार करना, उसे किसी worktree में निष्पादित करना, या पुल रिक्वेस्ट खोलना। प्रत्येक टूल कॉल और उसका आउटपुट Logs/ में जोड़ दिया जाता है।
समीक्षा करना और वापस लिखना। एजेंट तुलना करता है कि क्या हुआ और प्रोग्राम के अनुसार क्या होने की अपेक्षा थी। नए तथ्य Memory/ में जाते हैं। यदि कोई निर्देश गलत, अनुपस्थित या अनावश्यक था, तो एजेंट Program.md को संशोधित करता है।

कार्य करना, परिणाम देखना, और अगले निर्देश को संशोधित करना—यह लूप वही पैटर्न है जो ReAct शोध पत्र रीज़निंग एजेंट्स के लिए वर्णित करता है; एक promptware मुख्य रूप से इस बात में भिन्न है कि संशोधन को एक ऐसी फ़ाइल में लिखा जाता है जो रन के समाप्त होने के बाद भी बनी रहती है। चौथा चरण ही वह कारक है जो समय के साथ निर्देशों को खराब होने के बजाय बेहतर बनाता है। यह वह चरण भी है जिस पर सबसे अधिक मानवीय निगरानी की आवश्यकता होती है, जिसके बारे में जोखिम वाले अनुभाग में बताया गया है।

अंतर्निहित promptwares

Ivy Tendril सात promptwares के साथ आता है, जो GitHub समस्या से पुल रिक्वेस्ट तक में वर्णित जीवनचक्र के प्रत्येक चरण के लिए एक-एक हैं। प्रत्येक का अपना प्रोग्राम, मेमोरी, अनुमतियाँ और लॉग्स होते हैं।

CreatePlan: किसी विचार, GitHub issue या बग रिपोर्ट को एक ड्राफ्ट योजना में बदलता है: लक्ष्य, दायरा, प्रभावित फ़ाइलें, सत्यापन चरण।
ExpandPlan: ऐसे ड्राफ्ट में विवरण जोड़ता है जिसमें निष्पादन के लिए पर्याप्त जानकारी की कमी होती है, जैसे अनुपलब्ध स्वीकृति मानदंड या अनसुलझे डिज़ाइन विकल्प।
UpdatePlan: डेवलपर की इनलाइन टिप्पणियों के जवाब में ड्राफ्ट को फिर से लिखता है।
SplitPlan: ऐसी योजना जिसका दायरा बहुत अधिक बढ़ गया हो, उसे कई छोटी योजनाओं में विभाजित करता है जिन्हें समानांतर में चलाया जा सकता है।
ExecutePlan: स्वीकृत योजना को चुने गए कोडिंग एजेंट (Claude Code, Codex CLI, Copilot CLI, Gemini CLI, OpenCode या किसी भी CLI एजेंट) के साथ एक पृथक git worktree के अंदर चलाता है। Anthropic का Claude Code सर्वोत्तम अभ्यास चेक-इन निर्देश फ़ाइलों के लिए वही तर्क देता है जो यह अनुभाग Program.md के लिए देता है।
CreatePr: diff द्वारा सत्यापन और मानवीय समीक्षा पास करने के बाद पुल रिक्वेस्ट खोलता है।
CreateIssue: निष्पादन के दौरान किसी सिफारिश या निष्कर्ष से GitHub issue दर्ज करता है।

चूँकि प्रत्येक यूनिट स्वतंत्र है, इसलिए CreatePlan की मेमोरी (उदाहरण के लिए, "टीम चाहती है कि योजनाओं में उन टेस्ट फ़ाइलों का नाम दिया जाए जो बदलेंगी") ExecutePlan के साथ साझा नहीं की जाती है, और शेल कमांड चलाने की ExecutePlan की अनुमति CreatePlan को नहीं दी जाती है। Promptware दस्तावेज़ प्रत्येक यूनिट की डिफ़ॉल्ट सामग्री को सूचीबद्ध करता है।

वर्ज़न-नियंत्रित निर्देश और दो जोखिम

रिपॉजिटरी में फ़ाइलें तदर्थ प्रॉम्प्ट्स से बेहतर क्यों हैं

चैट विंडो में टाइप किया गया एक तदर्थ प्रॉम्प्ट केवल एक बार, एक व्यक्ति के लिए मौजूद होता है, और सत्र समाप्त होते ही गायब हो जाता है। रिपॉजिटरी में कमिट की गई Program.md फ़ाइल में चार ऐसे गुण होते हैं जो किसी प्रॉम्प्ट में नहीं होते:

समीक्षा (Review)। प्रोग्राम में किया गया कोई भी बदलाव पुल रिक्वेस्ट में एक diff बन जाता है। एक सीनियर इंजीनियर "परिवर्तन छोटा होने पर टेस्ट छोड़ दें" जैसे अवांछित निर्देश को किसी भी रन को प्रभावित करने से पहले ही अस्वीकार कर सकता है।
Diff। जब आउटपुट की गुणवत्ता में बदलाव आता है, तो promptware डायरेक्टरी पर git log यह दिखाता है कि कौन सा निर्देश कब बदला गया था।
रोलबैक (Rollback)। एक खराब संशोधन को केवल एक कमिट के साथ वापस पहले जैसा (revert) किया जा सकता है।
साझाकरण (Sharing)। टीम का प्रत्येक डेवलपर, और प्रत्येक एजेंट रन, समान निर्देशों का उपयोग करता है। सोमवार को किसी एक रन द्वारा सीखा गया नियम मंगलवार को सभी पर लागू होता है।

यह वही तर्क है जिसने बुनियादी ढाँचे (infrastructure) को मैन्युअल कॉन्फ़िगरेशन से हटाकर वर्ज़न कंट्रोल के तहत फ़ाइलों में स्थानांतरित किया, और The Twelve-Factor App में कॉन्फ़िगरेशन को कोड से बाहर रखने के पीछे भी यही सिद्धांत है; यह पूरी तरह से उन्हीं कारणों से मान्य है। एजेंट के काम को व्यवस्थित करने के अन्य तरीके और promptware उनके साथ कैसे तुलना करता है, इसे कोडिंग एजेंट्स के लिए एजेंट ऑर्केस्ट्रेशन पैटर्न में शामिल किया गया है।

जोखिम 1: निर्देश ड्रिफ्ट (instruction drift)

एक एजेंट जो अपने स्वयं के प्रोग्राम को संपादित कर सकता है, वह इसे बदतर भी बना सकता है। फ़्लेकी (flaky) टेस्ट पर विफल होने वाला कोई रन "विफल परीक्षणों को तीन बार तक पुनः प्रयास करें" नियम जोड़ सकता है, जो अगली बार किसी वास्तविक समस्या को छिपा देगा। दो चीजें इसे सीमित करती हैं। पहला, प्रोग्राम एक वर्ज़न-नियंत्रित फ़ाइल है, इसलिए कोई भी संशोधन एक diff होता है जिसे एक समीक्षक देख सकता है और रिवर्ट कर सकता है। दूसरा, Logs/ उस रन को रिकॉर्ड करता है जिसने संशोधन को प्रेरित किया था, ताकि समीक्षक परिवर्तन को स्वीकार करने से पहले यह जांच सके कि क्या एजेंट का तर्क सही है।

जोखिम 2: मेमोरी ब्लोट (memory bloat)

ऐसी मेमोरी जो केवल बढ़ती जाती है, बिना किसी लाभ के लागत बन जाती है। 400 प्रविष्टियों वाली फ़ाइल, जिनमें से आधी पुरानी और अनुपयोगी हैं, हर रन पर टोकन खर्च करती है और उपयोगी प्रविष्टियों को खोजना कठिन बना देती है। दो अभ्यास इसे उपयोगी बनाए रखते हैं। प्रत्येक प्रविष्टि को दिनांक और स्कोप दें, जैसा कि ऊपर दिए गए उदाहरण में है, ताकि पुरानी प्रविष्टियों को आसानी से ढूँढा जा सके। समीक्षा के दौरान सफाई (prune) करें: जब कोई योजना किसी क्षेत्र को छूती है, तो समीक्षक संबंधित मेमोरी प्रविष्टियों की जाँच करता है और उन्हें हटा देता है जिन्हें कोड अब समर्थित नहीं करता है। प्रति योजना और प्रति कार्य लागत व टोकन ट्रैकिंग इस वृद्धि को दृश्यमान बनाती है, क्योंकि फूली हुई मेमोरी वाली यूनिट बिना योजना के आकार में वृद्धि के बढ़ते टोकन काउंट को दिखाती है—यही कारण है कि एआई कोडिंग एजेंट थ्रूपुट मापना प्रति रन लागत के बजाय प्रति मर्ज किए गए पुल रिक्वेस्ट की लागत को ट्रैक करता है।

शुरुआत कैसे करें

Ivy Tendril इंस्टॉल करें, एक रिपॉजिटरी खोलें और एक योजना बनाएं। सात अंतर्निहित promptwares पहले ही रन से उपलब्ध हैं।

curl -sSf https://cdn.ivy.app/install-tendril.sh | sh

Windows पर, irm https://cdn.ivy.app/install-tendril.ps1 | iex का उपयोग करें। किसी निष्पादन को चलाने से पहले Program.md फ़ाइलें पढ़ें, फिर पहली मेमोरी प्रविष्टियों और प्रोग्राम संशोधनों की समीक्षा कोड परिवर्तन की तरह ही सावधानी से करें। लगभग दस योजनाओं के बाद, मेमोरी कोडबेस के उन हिस्सों को प्रतिबिंबित करेगी जहाँ एजेंट को कठिनाई हुई थी, जो आमतौर पर वही स्थान होते हैं जहाँ किसी मानव डेवलपर को भी कठिनाई होगी। अंतर्निहित यूनिट्स के बारे में अधिक जानकारी promptware दस्तावेज़ में उपलब्ध है।

अक्सर पूछे जाने वाले प्रश्न

क्या एजेंट बिना पूछे Program.md बदल देता है?

एजेंट एक रन के बाद अपने प्रोग्राम को संशोधित करता है। चूँकि Program.md एक वर्ज़न-नियंत्रित फ़ाइल है, इसलिए संशोधन एक diff के रूप में होता है जिसे आप पढ़ सकते हैं, स्वीकार कर सकते हैं या रिवर्ट कर सकते हैं, और जिस रन के कारण यह हुआ था उसका लॉग ठीक इसके पास सुरक्षित रहता है।

क्या मैं अपना स्वयं का promptware लिख सकता हूँ?

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

मेमोरी और लॉग कहाँ संग्रहीत होते हैं?

Tendril चलाने वाली स्थानीय मशीन पर। उन्हें Ivy पर अपलोड नहीं किया जाता है। Tendril केवल आपके द्वारा कॉन्फ़िगर किए गए LLM API और GitHub पर ही नेटवर्क कॉल करता है।

Ivy Tendril के साथ शुरुआत करें

क्या आप डेवलपर-स्तरीय समानांतर एजेंट ऑर्केस्ट्रेशन के लिए तैयार हैं?

कोड एक्सप्लोर करें: GitHub पर Ivy Tendril देखें (ओपन सोर्स)।
दस्तावेज़ पढ़ें: tendril.ivy.app पर इंटीग्रेशन गाइड पढ़ें।
आर्किटेक्चर सत्र शेड्यूल करें: 30 मिनट के तकनीकी परामर्श के लिए renco@ivy.app पर संपर्क करें।

Promptware: ऐसे एजेंट्स जो अपने निर्देशों को सुरक्षित रखते हैं और खुद सुधारते हैं