AKB - लोगों और AI द्वारा साथ में पढ़े-लिखे जाने वाला टीम knowledge infrastructure, साथ में permission management भी

नमस्ते। मैं जिस Dnotitia टीम से जुड़ा हूँ, वहाँ हम AKB(Agent Knowledge Base) बना रहे हैं, एक ऐसा टीम नॉलेज बेस जिसे AI एजेंट काम के दौरान सीधे पढ़ और लिख सकते हैं।

इसे क्यों बनाया?

लोगों के लिए लिखे जाने वाले विकी (Confluence·Notion) पहले से बहुत हैं। एजेंटों की तरफ भी इसी तरह के टूल मौजूद हैं। mem0 बातचीत से निकाली गई बातों को व्यक्तिगत मेमोरी के रूप में जमा करता है, और LLM Wiki ऐसा निजी नॉलेज बेस बनाता है जिसे एजेंट पढ़ और लिख सकते हैं। लेकिन ये ज़्यादातर व्यक्तिगत स्तर पर ही रुक जाते हैं, इसलिए इन्हें कई लोगों द्वारा साथ में पढ़े और लिखे जाने वाले साझा आधार के रूप में डिज़ाइन किया गया कहा जाना मुश्किल है।

इसी तरह की समस्या की ओर Google का Open Knowledge Format(OKF) भी इशारा करता है। ज्ञान विकी, कैटलॉग और कोड में बिखरा रहता है, इसलिए एजेंटों को हर बार संदर्भ फिर से जुटाना पड़ता है। यानी ज़रूरत किसी एक और बंद सेवा की नहीं, बल्कि ऐसे साझा फ़ॉर्मैट की है जिसे कई टूल साथ में पढ़ और लिख सकें। OKF द्वारा प्रस्तावित फ़ॉर्मैट सरल है: Markdown फ़ाइलों को एक फ़ोल्डर में रखिए, और हर फ़ाइल के सबसे ऊपर YAML की कुछ पंक्तियाँ जोड़ दीजिए। फिर इस फ़ॉर्मैट को कौन बनाएगा, कैसे पढ़ेगा और कैसे बढ़ाएगा, यह अलग-अलग implementations पर छोड़ा गया है।

AKB क्या करता है?

AKB उसी फ़ॉर्मैट को टीम के साझा नॉलेज फ़ाउंडेशन के रूप में लागू करने वाला इन्फ्रास्ट्रक्चर है। vault, OKF-संगत Markdown फ़ाइलों का एक संग्रह है, लेकिन यह सिर्फ खोजकर पढ़ने वाला इंडेक्स नहीं, बल्कि ऐसा साझा स्टोरेज है जहाँ इंसान और एजेंट एक ही मूल स्रोत को साथ में पढ़ते और लिखते हैं। इंसान वेब UI से पहुँचते हैं, और एजेंट MCP के ज़रिए। फिर भी जिस मूल स्रोत को छुआ जाता है, वह एक ही है। जब एजेंट लिखना शुरू करते हैं, तब यह भी महत्वपूर्ण हो जाता है कि "क्या और कैसे बदला"। vault एक Git रिपॉज़िटरी है, इसलिए हर बदलाव commit और diff के रूप में दर्ज होता है।

इसमें सिर्फ दस्तावेज़ ही नहीं रखे जाते। अगर OKF ज्ञान को Markdown में लिखने का फ़ॉर्मैट है, तो AKB उसी vault में queryable tables और file storage भी जोड़ता है, और दस्तावेज़ों को knowledge graph से जोड़ता है। दस्तावेज़ों को मनुष्यों द्वारा पढ़े जाने और एजेंटों द्वारा संदर्भित किए जाने वाले ज्ञान के रूप में रखा जा सकता है, जबकि सूचियाँ, स्थिति और आँकड़ों जैसे structured data को अलग तालिकाओं में संग्रहीत कर query किया जा सकता है। इसलिए केवल मानव-विकी या खोज से कठिन काम, जैसे AKB को data और change-history layer की तरह इस्तेमाल कर उसके ऊपर business apps विकसित और संचालित करना, भी संभव है।

लेकिन टीम का साझा नॉलेज फ़ाउंडेशन बनने के लिए सिर्फ डेटा और इतिहास काफ़ी नहीं हैं। OKF जैसे फ़ॉर्मैट यह तय नहीं करते कि कौन क्या देख सकता है। AKB में जिस हिस्से पर हमने सबसे ज़्यादा मेहनत की, वह permissions हैं। एजेंट अपनी token जारी करने वाले व्यक्ति के रूप में प्रमाणित होते हैं, और उसी व्यक्ति के vault permissions विरासत में लेते हैं। इंसानों पर लागू access boundary एजेंटों पर भी वैसी ही लागू होती है। इस boundary को हम दो परतों में enforce करते हैं। documents, files और search जैसी सामान्य पहुँच के लिए app layer पर permissions जाँची जाती हैं। tables पर aggregation या analysis SQL चलाने वाले रास्ते को DB layer पर एक बार और रोका जाता है। query उस उपयोगकर्ता के PostgreSQL role के रूप में चलती है, यानी PG ACL मॉडल में अगर वह अपने अधिकार-क्षेत्र के बाहर के vault को संदर्भित करे, तो उसे app नहीं बल्कि PostgreSQL सीधे अस्वीकार कर देता है।

हमारी टीम AKB इन्फ्रास्ट्रक्चर के ऊपर issue tracker reef चलाकर उपयोग कर रही है। एक issue, vault के भीतर Markdown document भी है और queryable table row भी। डेवलपर Claude Code·Codex जैसे coding agents के साथ, और PM reef के dedicated agent के साथ, vault के भीतर उसी एक document को देखकर काम करते हैं। PM को डेवलपर-उन्मुख spec syntax जानने की ज़रूरत नहीं होती; वह AKB में संचित संदर्भ के आधार पर issue बना सकता है। डेवलपर भी बिखरे हुए background explanation को फिर से खोदे बिना MCP के ज़रिए उसे लेकर development कर सकते हैं। डेवलपर और PM के बीच की तकनीकी और भाषाई बाधाएँ एजेंटों के माध्यम से कम होती हुई हमने अपनी टीम में सीधे महसूस की हैं।

अभी देखें

अगर आप बिना इंस्टॉल किए तुरंत देखना चाहते हैं, तो public demo (akb-demo.agent.seahorse.dnotitia.ai) पर जाएँ। (साइन-अप ज़रूरी है, लेकिन यह डेमो के लिए है, इसलिए सारा डेटा हर हफ्ते रीसेट कर दिया जाता है।)

अगर आप इसे खुद चलाकर देखना चाहते हैं, तो नीचे की तरह Docker compose से इसे चलाएँ और फिर localhost:3000 पर जाएँ। embedding key न होने पर भी keyword (BM25) search काम करेगी।

git clone https://github.com/dnotitia/akb && cd akb  
cp config/app.yaml.example   config/app.yaml  
cp config/secret.yaml.example config/secret.yaml  
docker compose up -d  

अभी भी इसमें कई कमियाँ हैं। एक बार इसे चलाकर देखिए, और अगर कोई bug, अजीब बात, या आपका अनुभव हो, तो कृपया टिप्पणी में बेझिझक बताइए।