मैंने अपने AI एजेंट को वॉलेट कैसे दिया और उसे तुरंत मेमोरी की ज़रूरत क्यों पड़ी

कुछ दिन पहले मैंने open-second-brain रिलीज़ किया - AI एजेंट्स के लिए एक फ़ाइल-आधारित मेमोरी लेयर। तभी से एक विचार मेरे दिमाग में लगातार घूम रहा था। अगर एजेंट किसी VPS पर, अपने ही शेड्यूल पर, Telegram के ज़रिए चलता है - तो देर-सबेर उसे पैसे खर्च करने की ज़रूरत पड़ेगी। कोई API कॉल ख़रीदना। कोई इलस्ट्रेशन जनरेट करना। किसी पेड सर्च को ट्रिगर करना।

भुगतान अपने आप में बहुत पहले हल की गई समस्या है। pay.sh एक साधारण HTTP कॉल को Solana पर USDC माइक्रोपेमेंट्स के ज़रिए पेड कॉल में लपेट देता है। एजेंट pay के ज़रिए curl चलाता है, वॉलेट ट्रांज़ैक्शन साइन करता है, दूसरी तरफ़ से जवाब आता है। हो गया।

लेकिन “हो गया” बस आधी कहानी है।

वॉलेट के साथ अव्यवस्था

कल्पना कीजिए: एजेंट किसी टास्क पर काम कर रहा है, रास्ते में मुट्ठीभर निर्णय लेता है, उनमें से दो पेड कॉल्स हैं। एक घंटे बाद आप टर्मिनल खोलते हैं और scrollback कब का स्क्रीन से ऊपर उड़ चुका है। कहीं ऊपर pay के इनवोकेशन हुए थे, कहीं tx सिग्नेचर आए थे, कहीं JSON रिस्पॉन्स लौटे थे।

एजेंट ने ऐसा क्यों किया? किस आधार पर? वह कितना खर्च करने वाला था? असल में कितना डेबिट हुआ? नतीजा कहाँ है?

अगर आप एजेंट पर किसी भी स्वायत्त काम के लिए भरोसा करना चाहते हैं, “scrollback पढ़ लो” काम नहीं चलेगा। टर्मिनल लॉग संरचित नहीं है, टास्क से जुड़ा नहीं है, इंडेक्स नहीं किया जा सकता, रीस्टार्ट नहीं झेलता, और इसे Obsidian में एक सामान्य आर्टिफ़ैक्ट की तरह खोला नहीं जा सकता।

मैंने काफ़ी जल्दी समझ लिया कि टास्क “एजेंट को भुगतान करना सिखाना” नहीं था - टास्क था “यह सुनिश्चित करना कि हर भुगतान अपने पीछे एक सार्थक निशान छोड़े”।

यह इलस्ट्रेशन ठीक उसी तरीक़े से जनरेट किया गया जिसका ज़िक्र पोस्ट ख़ुद करता है: pay.sh के ज़रिए, paysponge/fal x402 गेटवे और fal-ai/fast-sdxl एंडपॉइंट का इस्तेमाल करते हुए। जनरेशन की लागत mainnet वॉलेट 64FaukkZDUdFTufXF49H1CrHjDfsmBFqfrUjsAS8XrgP से 0.01 USDC रही; पब्लिक Solana ट्रांज़ैक्शन है 5ZYnkabzLvHqEgXNJfKopiRwbGkriHJ2bps2NnkX7HzqQAyTZYjcyJVCTvZwMquyMviv2juyAdbP9P2depHrJxQW। request id था 019e135a-357b-71f3-8b9d-305e728b05fb, और जनरेट हुआ asset लोकल में image.png के नाम से सेव हुआ।

और यहीं open-second-brain बिल्कुल फिट बैठा।

Pay Memory

वर्शन 0.8.0 में OSB को एक नई लेयर मिली - Pay Memory। संक्षेप में: पैसे के लिए मेमोरी।

हर पेड एक्शन के बाद vault में इन फ़ील्ड्स के साथ एक सादा Markdown फ़ाइल दिखाई देती है:

• क्यों एजेंट ने भुगतान करने का निर्णय लिया;
• कौन-सी सर्विस कॉल की गई;
• कौन-सी spending policy लागू थी और उसने क्या तय किया (allowed / approval_required / denied / not_checked);
• अपेक्षित लागत और वास्तव में डेबिट हुई राशि;
• payment proof - विशिष्ट Solana सिग्नेचर, जिसे आप Solscan में खोलकर वेरीफ़ाई कर सकते हैं;
• नतीजा - आउटपुट वाली एक अलग asset note का लिंक;
• किसने approve किया, अगर policy ने माँगा हो।

यह SQLite टेबल नहीं है और न ही dashboard। यह सादा Markdown है जो उसी फ़ोल्डर में बैठा है जहाँ एजेंट अपना daily log लिखता है। आप इसे आँखों से खोल सकते हैं, इस पर टिप्पणी कर सकते हैं, Git में commit कर सकते हैं, बाद में grep से ढूँढ सकते हैं, या सबूत की तरह दिखा सकते हैं।

OSB यहाँ कोई पेमेंट सिस्टम नहीं बन जाता - वह वॉलेट नहीं रखता, ट्रांज़ैक्शन साइन नहीं करता, enforcement नहीं करता। वह वही करता है जो उसे अच्छा आता है: एक ईमानदार, मानव-पाठ्य मेमोरी रखता है। pay.sh एजेंट को पेड संसाधनों तक पहुँच देता है; Pay Memory इंसान को यह क्षमता देता है कि एक हफ़्ते बाद vault खोलकर वह आराम से समझ सके कि क्या हुआ था।

वैसे, असली receipt बिल्कुल ऐसा दिखता है - पोस्ट की शुरुआत में जो इलस्ट्रेशन है, ठीक उसी के लिए। vault से सीधा कच्चा Markdown, बिना किसी प्रोसेसिंग के। ऊपर सूचीबद्ध सभी फ़ील्ड्स के साथ frontmatter, और उसके नीचे “क्यों”, “policy ने क्या लौटाया” और “वास्तव में कितना डेबिट हुआ” के बारे में मानवीय भाषा में लिखा हुआ टेक्स्ट।

Second Brain के भीतर यह इस पथ पर रहता है:

AI Wiki/
└── payments/
    └── 2026-05-10/
        └── fal-generate-a-no-text-fast-sdxl-illustration-for-the-techmeat-d.md

कोई जादू नहीं: तारीख → फ़ोल्डर, slug → फ़ाइल का नाम। grep, git diff और Obsidian में सामान्य नेविगेशन के लिए सुविधाजनक।

एक सिद्धांत जो बाक़ी सब से ज़्यादा महत्वपूर्ण निकला

जब मैंने ड्राफ़्ट इम्प्लीमेंटेशन का रिव्यू किया, मेरी नज़र तुरंत एक बारीकी पर अटक गई: receipt हमेशा “Allowed by the configured spending policy” लिख रहा था - तब भी जब vault में कोई policy थी ही नहीं।

सुनने में छोटी-सी बात लगती है। हक़ीक़त में यह पूरे उद्देश्य को मार देती है।

Pay Memory एक audit लेयर है। एक audit लेयर ठीक उतनी ही मूल्यवान है जितनी ईमानदार है। जिस पल receipt वास्तविक कहानी के बजाय एक सुंदर कहानी सुनाने लगता है, सब कुछ बिखर जाता है। तो नियम सरल निकला: allowed को आत्मविश्वास से ग़लत लॉग करने से बेहतर है not_checked लिखना। अगर policy चेक नहीं हुई - तो वही लिखो। अगर policy ने denied लौटाया लेकिन किसी इंसान ने कॉल को मैन्युअली पास होने दिया - तो वह भी लिखो।

“अच्छी कहानी” का प्रलोभन audit सिस्टम का सबसे बड़ा दुश्मन है। और यही, शायद, दिन का सबसे महत्वपूर्ण सबक है - जिसे मैं प्रोजेक्ट के दूसरे हिस्सों में भी ले जाने का इरादा रखता हूँ।

प्रोडक्शन में एक असली भुगतान

दिन के अंत तक यह सब sandbox फ़िक्स्चर्स पर नहीं, बल्कि असली पैसों पर परखना ज़रूरी था। मैंने एक नई Solana वॉलेट पर दस सेंट USDC भेजे और एजेंट से कहा कि Google Places के ज़रिए बेलग्रेड में तीन कैफ़े ढूँढे।

एक सेकंड बाद तीन असली जगहें वापस आईं - Artist Specialty Coffee, Dusha, DRIP। Tx mainnet पर finalised, $0.001 USDC, बैलेंस 0.10 से 0.099 पर चला गया। Solscan में सिग्नेचर, क्लिक करने योग्य।

और तब पूरी Pay Memory चेन सक्रिय हो गई: vault में असली सिग्नेचर के साथ एक receipt, तीन कैफ़े वाली एक अलग asset note, दैनिक पेमेंट रिपोर्ट और Daily में दोनों फ़ाइलों के लिंक के साथ एक छोटी एंट्री। मैं Obsidian में vault खोल सकता हूँ, proof पर क्लिक कर सकता हूँ, explorer में असली भुगतान देख सकता हूँ - और ठीक उसके बगल में एजेंट ने यह क्यों किया, इसकी एक साफ़, इंसानी भाषा वाली कहानी।

यह सब किसलिए

मैं अपने लिए न तो enterprise compliance बना रहा हूँ और न ही blockchain-for-everything। आर्किटेक्चर ख़ुद शर्मनाक हद तक सादा है - सही फ़ोल्डरों में Markdown फ़ाइलों का एक सेट।

लेकिन इसके पीछे का विचार मायने रखता है।

अगर एजेंट और भी स्वायत्त रूप से काम कर रहा है, तो उसकी मेमोरी को केवल पाठीय एक्शनों को नहीं, बल्कि उन एक्शनों को भी कवर करना होगा जिनके परिणाम होते हैं: किसी बाहरी सर्विस को कॉल करना, पैसे खर्च करना, asset बनाना, approval माँगना। भुगतान बस सबसे जीवंत उदाहरण है, क्योंकि भरोसे का सवाल वहाँ तुरंत खड़ा हो जाता है। वही सिद्धांत आसानी से किसी पोस्ट को प्रकाशित करने, ईमेल भेजने, deploy करने, जनरेशन ऑर्डर करने, on-chain ऑपरेशन पर लागू हो जाते हैं।

संक्षेप में:

pay.sh एजेंट को पेड संसाधनों तक पहुँच देता है। Pay Memory इंसान को यह क्षमता देता है कि एक हफ़्ते बाद वह समझ सके कि एजेंट ने इस पहुँच का इस्तेमाल क्यों किया।

अगर एजेंट सिर्फ़ पैसे ख़र्च करता है - तो यह जोखिम है। अगर एजेंट पैसे ख़र्च करता है और एक ईमानदार, जुड़ा हुआ, मानव-पाठ्य निशान छोड़ता है - तो यह पहले से ही एक ऐसा workflow है जिस पर धीरे-धीरे भरोसा करना शुरू किया जा सकता है।

Pay Memory open-second-brain 0.8.0 के हिस्से के रूप में रिलीज़ हुआ।