मैंने OpenSecondBrain कैसे बनाया

मैं काफी समय से विभिन्न AI-टूल्स का सक्रिय रूप से इस्तेमाल कर रहा हूँ, लेकिन किसी बिंदु पर यह साफ हो गया: मैं सिर्फ उनका इस्तेमाल नहीं कर रहा हूँ, बल्कि लगभग पूरी तरह से एजेंट्स और AI से जुड़ी हर चीज़ से “ढका” हुआ हूँ।

कई महीनों से एजेंट्स मेरे workflow के अनुसार कोड लिखते हैं: प्लानिंग, इम्प्लीमेंटेशन, रिव्यू, सुधार, फिर से जाँच। यह काम करता है, लेकिन इस प्रक्रिया में एक अजीब मैनुअल हिस्सा बना रहता है। भले ही कोड एजेंट लिखता हो, मुझे फिर भी कार्यों को चरणों के बीच ले जाना होता है, कॉन्टेक्स्ट ट्रांसफर करना होता है, नियम याद दिलाने होते हैं, जाँचें चलानी होती हैं और यह सुनिश्चित करना होता है कि अगला निष्पादक समझे कि पहले ही क्या हो चुका है।

दोहराव वाला काम बहुत ज़्यादा हो गया था। इसलिए अगला स्वाभाविक कदम एक और फीचर नहीं था, बल्कि स्वयं workflow का ऑटोमेशन था।

इसी तरह पैदा हुआ प्रोजेक्ट OpenSecondBrain — एजेंट्स को इस बारे में सामान्य मेमोरी देने का प्रयास कि हम क्या कर रहे हैं, हम ऐसा क्यों कर रहे हैं और कौन से निर्णय पहले ही ले लिए गए हैं।

मैनुअल workflow से Dark Fabric तक

पहली पोस्ट में मैंने बताया था कि कैसे मैंने कोडिंग एजेंट्स की मदद से इस ब्लॉग को लॉन्च किया। वहाँ workflow जानबूझकर आसान था: कॉन्टेक्स्ट दें, Astro प्रोजेक्ट असेंबल करें, डिज़ाइन पास करें, पोस्टर जोड़ें, परिणाम जाँचें।

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

मैं एक ज़्यादा सख्त मॉडल की ओर बढ़ना चाहता था, जिसे अक्सर Dark Fabric कहा जाता है: इनपुट पर एक फीचर आइडिया, आउटपुट पर — फीचर इम्प्लीमेंट, टेस्टेड और डिप्लॉयड। “एजेंट ने कोड का एक टुकड़ा लिखा” नहीं, बल्कि एक फैक्ट्री जो खुद काम को चरणों में बाँट सके और प्रक्रिया से गुज़ार सके।

पूर्ण Dark Fabric अभी बहुत दूर है। लेकिन पहला व्यावहारिक कदम पहले ही मौजूद है: Hermes, VPS पर चल रहा है, अलग-अलग कार्यों के लिए एजेंट्स के साथ, स्किल्स, Telegram इंटरफ़ेस और OmniRoute के ज़रिए सस्ती मॉडल राउटिंग के साथ।

और लगभग तुरंत इस फैक्ट्री का दूसरा अनिवार्य हिस्सा सामने आया: एजेंट्स को मेमोरी चाहिए।

एजेंट को Second Brain क्यों चाहिए

अगर एजेंट एक सेशन काम करता है, तो आप बस प्रॉम्प्ट में कॉन्टेक्स्ट डाल सकते हैं। अगर एजेंट हफ़्तों तक प्रोजेक्ट पर काम करता है, तो यह काफ़ी नहीं है।

उसे जानना चाहिए:

• प्रोजेक्ट में कौन से नियम पहले ही अपनाए गए हैं;
• कौन से निर्णयों पर चर्चा हुई और उन्हीं को क्यों चुना गया;
• जाँच के दौरान कौन से तथ्य सामने आए;
• कौन से आर्टिफैक्ट्स पहले ही बनाए गए हैं;
• काम में कौन से एजेंट्स शामिल थे;
• मानवीय नॉलेज बेस कहाँ है, और एजेंट सर्विस एरिया कहाँ है।

और सबसे ज़रूरी — यह सिर्फ “मॉडल की मेमोरी” पर निर्भर नहीं होना चाहिए। मुझे एक सरल, जाँचने योग्य, फ़ाइल-आधारित नॉलेज सिस्टम चाहिए जिसे हाथ से खोला जा सके, Obsidian में पढ़ा जा सके, सिंक किया जा सके, आंशिक रूप से कमिट किया जा सके या बिल्कुल कमिट न भी किया जाए।

इसलिए open-second-brain शुरू से ही “एक और मेमोरी वाला चैटबॉट” नहीं बना, बल्कि Markdown vault के चारों ओर एक छोटा इंफ्रास्ट्रक्चर बना।

Obsidian और Markdown क्यों

Obsidian-संगत vault का चुनाव लगभग स्पष्ट था।

पहले, ये सामान्य Markdown फ़ाइलें हैं। कोई जादू नहीं, कोई बंद डेटाबेस नहीं, किसी विशिष्ट सेवा पर कोई निर्भरता नहीं। अगर एजेंट ने कुछ लिखा, मैं फ़ाइल खोलकर परिणाम देख सकता हूँ।

दूसरे, Obsidian पहले से ही Second Brain के मानवीय हिस्से को अच्छी तरह सुलझाता है: नोट्स, wikilinks, Daily, मैनुअल नेविगेशन, ग्राफ़, सर्च। अपना खुद का इंटरफ़ेस बनाने का कोई मतलब नहीं था जब एक परिचित टूल पहले से मौजूद था।

तीसरे, एजेंट्स को पूरा Obsidian नहीं चाहिए। उन्हें डिटरमिनिस्टिक ऑपरेशन्स चाहिए: सर्विस स्ट्रक्चर बनाना, डेली लॉग में इवेंट जोड़ना, पेज इंडेक्स बनाना, vault की हेल्थ चेक करना, बिना सीक्रेट्स के कॉन्फ़िग एक्सपोर्ट करना। ये सब CLI और MCP के ज़रिए किया जा सकता है, मॉडल को फ़ाइल ऑपरेशन्स के बारे में “सोचने” के बजाय एक सटीक कमांड चलाना बेहतर है।

अभी open-second-brain vault में एजेंट एरिया AI Wiki/ बनाता है, Daily/*.md में डेली लॉग रखता है, Markdown इंडेक्स अपडेट कर सकता है, कॉन्फ़िगरेशन जाँच सकता है और ## Raw events सर्विस सेक्शन के ऊपर मानवीय नोट्स को नहीं छूता।

मैंने खाली रिपॉज़िटरी दी — एजेंट ने आर्किटेक्चर चुना

सबसे दिलचस्प बात: मैंने इस सबको क्लासिक लाइब्रेरी API की तरह डिज़ाइन करने के लिए नहीं बैठा। मैंने एजेंट को लोकप्रिय इम्प्लीमेंटेशन्स के लिंक दिए, एक खाली रिपॉज़िटरी और एक टास्क: एक यूनिवर्सल प्लगइन बनाओ, मुख्य रूप से Hermes के लिए, लेकिन ऐसा कि दूसरे एजेंट्स भी इसे अपना सकें।

पहला कमिट पूरी तरह डॉक्यूमेंटेशन वाला था: README और प्रोजेक्ट बूटस्ट्रैप 6 मई को। फिर एजेंट ने जल्दी से CLI फाउंडेशन, o2b कमांड, init/doctor, vault primitives और इंडेक्स बनाया। उसी दिन MCP सर्वर भी आ गया — एक महत्वपूर्ण लेयर, क्योंकि MCP के ज़रिए अलग-अलग रनटाइम बिना मैनुअल कमांड लाइन पार्सिंग के एक जैसे टूल्स पा सकते हैं।

पहले वर्ज़न बहुत प्रैक्टिकल थे: ऐसा करो कि Hermes प्लगइन इंस्टॉल कर सके, vault अप कर सके, स्टेटस चेक कर सके और इवेंट्स लिख सके। कागज़ पर एकदम सही आर्किटेक्चर नहीं, बल्कि एक असली एजेंट के लिए काम करने वाली न्यूनतम मेमोरी।

फिर प्रोजेक्ट इंटीग्रेशन के दबाव में बदलने लगा।

Hermes से यूनिवर्सल प्लगइन तक

Hermes मुख्य रनटाइम बना रहा। इसी के लिए प्रोजेक्ट सोचा गया था: प्लगइन इंस्टॉल करो, vault बताओ, एजेंट को टूल्स दो और उसे महत्वपूर्ण इवेंट्स Second Brain में लिखने के लिए मजबूर करो।

लेकिन काफी जल्दी यह साफ हो गया कि सिर्फ Hermes से बाँधना सही नहीं है। मेरे पास पहले से अलग-अलग एजेंट्स और अलग-अलग एनवायरनमेंट हैं: Claude Code, Codex, OpenClaw। अगर Second Brain एक साझा मेमोरी होना चाहिए, तो वह सिर्फ एक क्लाइंट में नहीं रह सकती।

इस तरह प्रोजेक्ट में कई रनटाइम्स के लिए एडैप्टर्स और मैनिफेस्ट्स आए:

• Hermes मुख्य इंस्टॉलेशन परिदृश्य के रूप में;
• Claude Code marketplace मैनिफेस्ट और MCP के ज़रिए;
• Codex अपने marketplace मैनिफेस्ट और MCP के ज़रिए;
• OpenClaw पहले JS एडैप्टर के ज़रिए, फिर पूर्ण native plugin entry के ज़रिए;
• आने वाले रनटाइम्स के लिए generic MCP कॉन्ट्रैक्ट।

यह एक महत्वपूर्ण आर्किटेक्चरल निर्णय है: कोर एक होना चाहिए, लेकिन एंट्री पॉइंट्स कई हो सकते हैं। एजेंट्स को यह तर्क नहीं करना चाहिए कि सत्य कहाँ है। सत्य — vault में है और ऑपरेशन्स के साझा सेट में है।

रास्ते में क्या ठीक करना पड़ा

open-second-brain ने बहुत तेज़ी से विकास किया: 6 से 9 मई तक प्रोजेक्ट README से वर्ज़न 0.7.0 तक का सफ़र तय किया। और लगभग हर वर्ज़न “कॉस्मेटिक” नहीं था, बल्कि इंटीग्रेशन की असल समस्या पर प्रतिक्रिया था।

उदाहरण के लिए, OpenClaw ने पहले native plugin compatibility पाया, लेकिन रनटाइम उम्मीद से ज़्यादा सख्त निकला। name को tool objects के अंदर जोड़ना पड़ा, register() को synchronous बनाना पड़ा, और फिर OpenClaw प्लगइन को शुद्ध JavaScript में बिना child_process के फिर से लिखना पड़ा, क्योंकि security scanner subprocess को ब्लॉक कर रहा था।

अगला बड़ा विषय — identity। अगर डायरी में बस @agent लिखा है, तो ऐसा लॉग लगभग बेकार है। इसलिए 0.6.0 में एजेंट नामों के साथ workflow आया: o2b init --agent-name, AI Wiki/identity/agents.md में रजिस्ट्रेशन और जाँच कि Daily में एंट्रीज़ को सामान्य @agent-name मिले, placeholder नहीं।

फिर timezone, ग़लत vault में लिखने से सुरक्षा, Claude और Codex के लिए marketplace मैनिफेस्ट्स, MCP के लिए ऑटो-इंस्ट्रक्शन्स, खाली आर्गुमेंट्स का नॉर्मलाइज़ेशन, install flow की जाँच, multi-agent registry जोड़े गए। यह कोई हीरोइक प्रोडक्ट फीचर जैसा नहीं लगता, लेकिन ऐसे ही डिटेल्स एक खिलौने को उस टूल से अलग करते हैं जिसे सर्वर पर काम करने के लिए छोड़ा जा सकता है।

वर्ज़न 0.7.0: TypeScript और Bun पर एक कोर

सबसे बड़ा बदलाव 0.7.0 में आया: प्रोजेक्ट Bun पर एकीकृत TypeScript कोर में स्थानांतरित हो गया।

इससे पहले रिपॉज़िटरी में समानांतर लॉजिक था: CLI/MCP के लिए Python इम्प्लीमेंटेशन, OpenClaw के लिए JavaScript हिस्सा, Hermes shim। ऐसी स्कीम जल्दी ड्रिफ्ट होने लगती है। एक जगह बग ठीक किया — कोई गारंटी नहीं कि दूसरी जगह भी ठीक हुआ। Python में timezone जोड़ा — JS में भी दोहराना न भूलना पड़े।

0.7.0 में एजेंट ने डुप्लीकेशन हटा दिया: Hermes, Claude Code, Codex और OpenClaw अब src/core/ से साझा मॉड्यूल्स का उपयोग करते हैं। CLI src/cli/ में रहता है, MCP src/mcp/ में, OpenClaw entry bun build के ज़रिए TypeScript से JS bundle में बनता है।

साथ ही एक अच्छी टेस्ट बेस भी बनी: bun:test पर 176 केस, Python shim टेस्ट्स, 12 प्रोसेस में कॉन्करंट append-event टेस्ट, bundle फ्रेशनेस और मैनिफेस्ट्स में वर्ज़न सिंक जाँचें।

यह वही मोमेंट है जहाँ एजेंट workflow का फ़ायदा दिखता है। इंसान को एक ही कोड को रनटाइम्स के बीच मैन्युअली खिसकाना और टेस्ट फिर से लिखना अच्छा नहीं लगता। एजेंट को — ठीक है, अगर स्पष्ट लक्ष्य, सीमाएँ और परिणाम जाँच दो।

यह VPS पर कैसे काम करता है

यह पूरी कहानी एक सामान्य VPS पर लगभग 8 डॉलर प्रति माह में चल रही है। वहीं Hermes रहता है, वहीं डेवलपमेंट किया जा सकता है, वहीं AI सब्सक्रिप्शन और OmniRoute के ज़रिए राउटिंग मैनेज होती है।

मेरे लिए यह एक्सपेरिमेंट का एक महत्वपूर्ण हिस्सा है। मैं नहीं चाहता कि AI-assisted workflow के लिए अलग से महंगी इंफ्रास्ट्रक्चर चाहिए। सर्वर चाहिए, ब्राउज़र चाहिए, एजेंट के इंटरफ़ेस के लिए Telegram, नज़दीक git रिपॉज़िटरीज़ और मॉडल्स तक सस्ती पहुँच चाहिए।

काफी अजीब, लेकिन काम करने वाली तस्वीर बनती है: मैं फ़ोन से Telegram में एजेंट को लिख सकता हूँ, वह VPS पर टास्क समझेगा, रिपॉज़िटरी में जाएगा, ज़रूरी स्किल्स इस्तेमाल करेगा, आर्टिफैक्ट बनाएगा, जाँचें चलाएगा और महत्वपूर्ण इवेंट Second Brain में लिखेगा।

ये अभी तक Dark Fabric नहीं है। लेकिन ये अब सिर्फ “मॉडल के साथ चैट” भी नहीं है।

क्या बना

इस ड्राफ्ट के समय open-second-brain एजेंट डेवलपमेंट के लिए एक छोटा लेकिन पहले से ही उपयोगी मेमोरी लेयर है।

यह कर सकता है:

• एजेंट कार्य के लिए Obsidian-संगत vault इनिशियलाइज़ करना;
• AI Wiki/ और सर्विस पेज बनाना;
• डेली इवेंट्स Markdown में लिखना;
• एजेंट identity सेव करना;
• उपयोगकर्ता का timezone ध्यान में रखना, सिर्फ सर्वर समय नहीं;
• vault, config और रनटाइम मैनिफेस्ट्स की हेल्थ चेक करना;
• सीक्रेट-जैसे मानों को संपादित करके कॉन्फ़िगरेशन एक्सपोर्ट करना;
• CLI, MCP और रनटाइम एडैप्टर्स के ज़रिए काम करना;
• एक ही रिपॉज़िटरी से Hermes, Claude Code, Codex और OpenClaw को सपोर्ट करना।

सबसे कीमती चीज़ कमांड्स की सूची भी नहीं है। कीमती यह है कि एजेंट्स को एक साझा मेमोरी प्रोटोकॉल मिला: जब कुछ टिकाऊ होता है — कोड, फिक्स, कॉन्फ़िग, कॉन्टेंट, रिसर्च निष्कर्ष, डिज़ाइन निर्णय — इसे ऐसे रिकॉर्ड करना चाहिए कि future-me और future-agent इसे बाद में ढूँढ सकें।

आगे क्या

निकटतम लक्ष्य — Hermes + open-second-brain की जोड़ी को उस स्थिति तक लाना जहाँ एजेंट सिर्फ इवेंट्स न लिखे, बल्कि प्लानिंग और रिव्यू के दौरान इकट्ठा की गई मेमोरी को सच में इस्तेमाल करे।

आगे चाहता हूँ:

• Daily लॉग्स को wiki पेजों से बेहतर जोड़ना;
• प्रोजेक्ट इतिहास पर ज़्यादा उपयोगी सर्च और summaries जोड़ना;
• एक अलग पोस्ट में बताना कि Hermes VPS पर कैसे काम करता है और Telegram के ज़रिए संचार कैसे व्यवस्थित है;
• वर्तमान workflow को ज़्यादा स्वायत्त Dark Fabric में बदलना;
• जाँचना कि क्या अलग-अलग एजेंट्स बिना दिक्कत के एक vault शेयर कर सकते हैं और एक-दूसरे के कॉन्टेक्स्ट को नहीं तोड़ते।

अभी तक का मुख्य निष्कर्ष सरल है: एजेंट्स को सिर्फ मॉडल नहीं चाहिए और सिर्फ रिपॉज़िटरी तक पहुँच नहीं चाहिए। उन्हें एक ऐसा एनवायरनमेंट चाहिए जहाँ निर्णय, तथ्य और इवेंट्स प्रक्रिया का टिकाऊ हिस्सा बन जाएँ।

open-second-brain — इस दिशा में मेरा पहला काम करने वाला कदम है।

यह पोस्ट कैसे लिखी गई

माफ़ कीजिएगा, लेकिन यह पोस्ट भी उसी एजेंट Hermes ने लिखी है। हाथ से सिर्फ यह पैराग्राफ और मेरा Facebook पर पोस्ट लिखा गया है। मैंने बस एजेंट से कहा कि वह मेरे ब्लॉग को एक सामान्य प्रोजेक्ट की तरह क्लोन करे, कमिट इतिहास देखे और Facebook पोस्ट को आधार के रूप में ले। और ज़ाहिर है, मैंने प्रकाशन से पहले टेक्स्ट फिर से पढ़ा और सुधारा। और मत कहिए कि इसमें जान नहीं है, मैं अपनी जान एजेंट में डालता हूँ।