Karpathy-स्टाइल LLM wiki को agents खुद maintain करने वाला सिस्टम - Markdown और Git आधारित

 (github.com/nex-crm)
2 पॉइंट द्वारा GN⁺ 3 일 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • इसे इस तरह बनाया गया है कि कई AI agents एक ही office में मिलकर काम करें, और hidden API calls के बजाय browser UI तथा role-based team structure के ज़रिए दिखने वाला workflow सामने रहे
  • memory को agent-specific notebook और team-shared wiki में बाँटा गया है, ताकि raw working context निजी हिस्से में रहे और सिर्फ verified facts तथा repeatable playbooks ही shared knowledge के रूप में ऊपर जाएँ
  • default wiki सिर्फ एक साधारण document folder नहीं है, बल्कि local Git repository की तरह काम करता है, और इसके साथ typed facts, append-only logs, LLM-synthesized briefs, /lookup, /lint जैसे file-first tool system भी मिलते हैं
  • sessions हर turn पर नए सिरे से शुरू होते हैं और tools भी agent के हिसाब से सीमित रहते हैं; push-driven execution model और prompt cache को मिलाकर session की लंबाई से अलग flat input volume बनाए रखने के लिए इसे ट्यून किया गया है
  • Telegram, OpenClaw, One CLI और Composio तक कनेक्ट करके external messages और action execution लाए जाते हैं, लेकिन self-hosted open source और अपनी API keys के इस्तेमाल के आधार पर team memory और agent collaboration को एक ही जगह में बाँधकर रखा जाता है

मेमोरी और wiki की संरचना

  • agent-specific notebook और team-shared wiki को अलग रखा गया है, ताकि व्यक्तिगत working context और organizational knowledge को अलग-अलग layers में मैनेज किया जा सके
  • notebook में काम के दौरान मिले raw context, observations और tentative conclusions रखे जाते हैं, और सिर्फ लंबे समय तक काम आने वाली जानकारी जैसे repeat playbooks, verified facts और confirmed preferences को ही wiki में promote करने के लिए डिज़ाइन किया गया है
  • कोई भी जानकारी अपने-आप promote नहीं होती, agent खुद तय करता है कि notebook से wiki में क्या भेजना है
  • wiki में यह जानकारी भी शामिल होती है कि आख़िरी बार उस context को किसने रिकॉर्ड किया था, ताकि दूसरा agent तय कर सके कि किसे फिर से mention करना है
  • नए installation में markdown backend default है, जबकि मौजूदा Nex या GBrain workspace मौजूदा knowledge graph backend को वैसे ही बनाए रखते हैं
  • अगर none backend चुना जाए तो shared wiki बंद हो जाता है, लेकिन local notebook काम करता रहता है

markdown wiki कैसे काम करता है

  • default wiki सिर्फ Markdown folder नहीं है, बल्कि local Git repository-based team wiki की तरह काम करता है, और इसका path ~/.wuphf/wiki/ है
  • इसमें triplet form के typed facts, entity-wise append-only fact logs, LLM द्वारा synthesize किए गए briefs, citation-based /lookup, और contradictions, orphan documents, stale claims तथा broken cross-references ढूँढने वाला /lint शामिल है
  • LLM द्वारा synthesize किए गए briefs archivist identity के नाम से commit होते हैं, और cat, grep, git log, git clone जैसे file-first tool system को वैसे ही इस्तेमाल किया जा सकता है
  • इस default wiki को API key के बिना इस्तेमाल किया जा सकता है
  • code naming में notebook private memory है और wiki shared memory, जबकि markdown backend और nex·gbrain backends अलग MCP tool surfaces इस्तेमाल करते हैं
  • markdown backend toolset और nex·gbrain के legacy toolset एक ही server instance में साथ मौजूद नहीं रहते
  • इससे जुड़ी details आगे DESIGN-WIKI.md, docs/specs/WIKI-SCHEMA.md में मिलती हैं

execution model और configuration options

  • default agent CLI है Claude Code, और --provider codex के साथ Codex CLI भी चुना जा सकता है
  • memory backend के तौर पर nex, gbrain, none, और default markdown में से चुना जा सकता है
  • --no-nex इस्तेमाल करने पर भी Telegram जैसे local integration features चलते रहते हैं, और run के बाद /focus से CEO routing delegation mode में वापस जाया जा सकता है
  • gbrain चुनने पर शुरुआती onboarding में OpenAI या Anthropic key माँगी जाती है, और अगर embeddings और vector search चाहिए तो OpenAI का इस्तेमाल करना पड़ता है
  • role packs में starter, founding-team, coding-team, lead-gen-agency, revops दिए गए हैं
  • --opus-ceo, --no-open, --web-port, --unsafe जैसे flags से model, browser auto-open, port और permission checks को adjust किया जा सकता है
  • repository अभी pre-1.0 state में है और main branch रोज़ बदल सकती है, इसलिए fork करते समय main की जगह release tag pin करने की सलाह दी गई है

collaboration और external integrations

  • Telegram bridge supported है; office के अंदर /connect चलाने के बाद Telegram चुनकर और @BotFather token डालकर group या DM के साथ two-way message flow जोड़ा जा सकता है
  • OpenClaw agents को भी /connect openclaw से लाया जा सकता है, जहाँ gateway URL और ~/.openclaw/openclaw.json में मौजूद gateway.auth.token का इस्तेमाल करके session bridge किया जाता है
  • OpenClaw sessions office के भीतर first-class members की तरह जुड़ते हैं और उन्हें @mention किया जा सकता है, जबकि असली execution उनके अपने sandbox में चलता रहता है
  • OpenClaw gateway authentication के लिए Ed25519 keypair इस्तेमाल होता है, और keys ~/.wuphf/openclaw/identity.json में 0600 permission के साथ store की जाती हैं
  • external action execution के लिए One CLI और Composio दो providers built-in हैं
  • One CLI local binary के रूप में user की machine पर actions चलाता है, इसलिए यह third party को credentials न भेजने वाले flow के हिसाब से बनाया गया है
  • Composio, Composio के hosted OAuth flow के ज़रिए Gmail, Slack जैसे SaaS accounts को connect करता है

design choices और operational characteristics

  • sessions हर turn पर नए सिरे से शुरू होते हैं, यानी conversation history accumulate नहीं होती
  • tools का scope agent के हिसाब से सीमित है; DM में सिर्फ 4 MCP tools load होते हैं, जबकि पूरे office में 27 tools load होते हैं
  • agents सिर्फ तब जागते हैं जब broker notification push करता है, यानी यह push-driven model है और heartbeat polling की ज़रूरत नहीं होती
  • काम के बीच भी किसी खास agent को DM भेजकर बिना restart किए बीच में adjustment किया जा सकता है
  • Claude Code, Codex और OpenClaw runtimes को एक ही channel में mix किया जा सकता है
  • memory में agent-specific notebook और workspace wiki दोनों रखे जाते हैं, और GBrain या Nex की knowledge graph-based memory भी चुनी जा सकती है
  • pricing के लिहाज़ से MIT license, self-hosting और अपनी API keys के इस्तेमाल को मिलाकर इसे free open source model के रूप में पेश किया गया है
  • Codex-based 10-turn CEO session measurement में input tokens प्रति turn लगभग 87k पर flat रखे गए दिखाए गए हैं
  • cache के बाद billable tokens लगभग 40k प्रति turn और 10 turns का कुल लगभग 286k बताया गया है
  • Claude API prompt cache के हिसाब से 97% cache hit rate दर्ज किया गया, और Claude Code के 5 turns की लागत $0.06 लिखी गई है
  • जहाँ cumulative session orchestrator में उसी session में प्रति turn input 124k से 484k तक बढ़ता है, वहीं WUPHF session length से स्वतंत्र flat input volume बनाए रखता है
  • लिखा है कि यह अंतर 8 turns के आधार पर 7x difference के रूप में मापा गया
  • ये characteristics fresh session, shared prefix पर आधारित prompt caching, DM mode में कम tools, और heartbeat के बिना push-driven wake structure के साथ जुड़ी हुई हैं
  • reproduction script के रूप में wuphf --pack starter & के बाद ./scripts/benchmark.sh दिया गया है, और सभी numbers user के local environment और keys के साथ measured हैं

implementation status और verification flow

  • README के हर मुख्य section में claim status table दी गई है जो सीधे code path से जुड़ती है, ताकि क्या shipped है और क्या partial है यह अलग दिखे
  • default CEO का Sonnet होना और --opus-ceo से upgrade होना, collaborative mode का default, /focus switching, per-agent MCP scoping, fresh session, push-driven wake, workspace isolation, Telegram bridge, 2 action providers, OpenClaw bridge, wuphf import, और --memory-backend markdown default — इन सभी को shipped के रूप में दिखाया गया है
  • live web agent streaming को partial दिखाया गया है, जबकि goreleaser-based prebuilt binary को config ready status दिया गया है
  • restart होने पर in-progress work restore करना v0.0.2.0 में shipped बताया गया है
  • LLM Wiki को git-native team memory और Wikipedia-style UI के साथ shipped माना गया है, और संबंधित implementation locations के रूप में internal/team/wiki_git.go, internal/team/wiki_worker.go, web/src/components/wiki/, DESIGN-WIKI.md जोड़े गए हैं
  • अगर claim और status में conflict हो तो code को प्राथमिकता दी जाती है, और समस्या मिले तो issue खोलने का निर्देश है

evaluation और demo materials

  • fork करने से पहले AI coding assistant की मदद से repository evaluate करने के लिए fork-or-skip prompt दिया गया है, जिसमें marketing wording के बिना file paths, line numbers और verdict को 500 शब्दों से कम में माँगा गया है
  • लिखा है कि इस prompt का internal इस्तेमाल release से पहले भी किया जाता है
  • wiki के वास्तव में लिखे जाने वाला flow दिखाने के लिए 5-minute terminal demo के रूप में ./scripts/demo-entity-synthesis.sh दिया गया है
  • इस demo में agents पाँच facts रिकॉर्ड करते हैं, फिर synthesis threshold trigger होता है, उसके बाद broker local LLM CLI को call करता है, result archivist identity के नाम से Git repository में commit होता है, और पूरी writing chain git log में दर्ज रहती है
  • demo requirements में curl, python3, --memory-backend markdown के साथ चल रहा broker, और claude·codex·openclaw में से कोई supported LLM CLI PATH में होना चाहिए

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 3 일 전
Hacker News की राय

  • मुझे note automation की बात का असली मतलब समझ नहीं आता। पहले भी टेक्स्ट को copy-paste करके नोट्स में डालना मेरे किसी काम का नहीं था, तो अब वही चीज़ 100 गुना बढ़ाने से क्या बदल जाएगा, समझ नहीं आता
    मेरे लिए नोट्स का सार यह है कि मैं स्रोत को आलोचनात्मक नज़र से पढ़ूं, उसे अपने mental model के हिसाब से आत्मसात करूं, और फिर उसे दर्ज करूं
    डिटेल्स बाद में फिर से देखी जा सकती हैं; असल में महत्वपूर्ण बात उस मॉडल को तराशने की प्रक्रिया है

    • यह सिर्फ note-taking से बढ़कर लग रहा है। असल में यह इंसानी दखल को न्यूनतम रखते हुए agents के बीच काम समन्वित करने वाला एक और harness ज़्यादा लगता है
      अगर ऐसा है, तो शायद मकसद उस mental model को खुद बनाने के बजाय एक shared LLM brain को सौंप देना हो सकता है
      लेकिन इस तरह के approach से product owner के लिए सच में कोई मूल्यवान चीज़ बन पाएगी या नहीं, इस पर मुझे काफ़ी संदेह है। अगर सिर्फ prompts और agent harness से कोई मूल्यवान product बनाया जा सकता है, तो उसे कोई भी दोबारा बना सकेगा, product development खुद commodity बन जाएगा, और आख़िर में शायद value सिर्फ tokens में बचेगी
      मेरी परिकल्पना है कि Paul Graham का do things that don’t scale आगे भी सही रहेगा, बस उन non-scalable कामों की प्रकृति बदल सकती है
      फिर भी, मैंने हाल में Obsidian को ठीक से इस्तेमाल करना शुरू किया है। note-taking, research, linking, splitting, और knowledge base restructuring के लिए skills सेट कर देने के बाद ऐसा लगता है जैसे मेरे पास व्यवस्थित करने में मदद करने वाला एक digital assistant हो
      अब मैं सिर्फ बिखरे हुए विचार भी लिख दूं, तो agent उनकी structure बना देता है, follow-up सवाल पूछता है, और उन्हें दूसरे कामों से जोड़ देता है। स्रोत पढ़ना और mental model बनाना अभी भी मैं खुद करता हूँ, लेकिन अच्छी quality के notes अब लगभग मुफ़्त जैसे मिल जाते हैं
    • मुझे लगता है लोग AI से बहुत सारा बेकार का काम बना रहे हैं और फिर उसे दोबारा कभी देखते भी नहीं
      यह बहुत बड़ी बर्बादी है
    • note-taking वाली बात से पूरी तरह सहमत हूँ। लोग notes को बहुत हल्के में लेते हैं, और आखिरकार उन्हें अटारी या बेसमेंट की तरह ज़रूरत से ज़्यादा जमा करते जाते हैं
      ज़्यादातर चीज़ों को शुरू से ही notes में जाने की ज़रूरत नहीं होती, और LLM बिना ढंग की verification या filtering के noise को बहुत ज़्यादा बढ़ा देता है
      इस विषय पर JA Westenberg का एक essay/video अच्छा था
      https://youtube.com/watch?v=3E00ZNdFbEk
    • अब तक आई कुछ गिनी-चुनी scientific studies के मुताबिक, जब ऐसे markdown collections को पूरी तरह LLM maintain करता है तो output quality उल्टे गिर जाती है, जबकि इंसान maintain करे तो बेहतर होती है
      यह काफ़ी दिलचस्प था
      मुझे लगता है optimal point human curation है, और खासकर अगर debt या drift को जानबूझकर manage न किया जाए तो बिना निगरानी के चलाना समाधान नहीं है
    • मुझे भी शुरू में लगा था कि यह कोई parody है
      ऊपर से इसका नाम भी The Office में आए उस बेकार और redundant product Wuphf.com जैसा है, इसलिए और भी ऐसा लगा

  • ऐसा लगता है कि product के नाम में सिर्फ AI जोड़ दो तो अरबों डॉलर पीछे लग जाते हैं, और blog post में सिर्फ Karpathy लिख दो तो Anthropic के principal engineer बन जाओ
    पूरा माहौल ऐसा लगता है कि trend के रहते-रहते पैसा निचोड़ लेने की कोशिश हो रही है, और ग्राहक को वास्तव में क्या चाहिए इस पर बहुत कम ध्यान है
    सब लोग बस लहर आई है तो हाथ धो लेने की दौड़ में लगे हैं

    • NFT, उससे पहले blockchain, और कुछ हद तक Web 2.0 का craze भी ऐसा ही था
      फिर भी तब लोग सच में कुछ बनाते तो थे, और उस समय की कड़ी funding situation ने overheat को थोड़ा दबाकर रखा था
      इस बार का LLM boom कम से कम कुछ वास्तविक संभावना और value तो रखता है, और सीखने-परखने में भी यह काफ़ी मज़ेदार tech है
      मैंने बहुत पहले ही मान लिया था कि अगर किसी जगह पैसा उमड़ रहा हो, तो जब तक वह अनैतिक न हो, वहाँ मौके पकड़ना ठीक है। जब तक VC/PE का पैसा बह रहा है, तब तक कुछ मूल्यवान और शानदार बनाया भी जा सकता है
    • अगर चीज़ काम कर रही है तो वही काफ़ी नहीं है क्या। लोग AI tools किसी वजह से बना रहे हैं, और सच कहें तो हम सब उन्हें खरीद भी रहे हैं
      मैं अब भी Claude Code की बराबरी करने वाले world-class CLI harness का इंतज़ार कर रहा हूँ। memory issues और design issues हल करने वाली चीज़ चाहिए
      web design अभी भी LLM के साथ करना लगभग दुःस्वप्न जैसा है
    • पिछले साल मैंने HubSpot के founder Dharmesh Shah के backing से एक AI-native CRM बनाया था, revenue भी था, और वहीं से कई बार pivot करते हुए मुझे लगा कि context graph infra ही असली moat है
      enterprise PoC भी किए, और यह सब आखिरकार इस project में सिमट गया, जिसे मैंने अपने निजी काम में मदद के लिए side में बनाया था। नतीजे में, context infra के लिए वास्तव में उपयोगी interface यही निकला
      Anthropic में principal engineer की नौकरी में मेरी कोई दिलचस्पी नहीं है। पहले मैं HubSpot में Product Manager था और मेरी कमाई अभी से कहीं बेहतर थी; आगे कुछ साल भी शायद मैं उस स्तर तक न पहुँचूँ
      मैंने कई बार bet लगाई और लगातार iterate किया क्योंकि यह सीधे customers से बात करते हुए evolve हुआ। जबकि पुराने competitors अब भी stealth mode में AI CRM बना रहे हैं
      इंडस्ट्री में लंबे समय से होने के नाते, मेरे लिए लहर खुद उतनी महत्वपूर्ण नहीं है, लेकिन उसके नीचे से निकाली जा सकने वाली ठोस value ज़रूर है

  • मैंने यह review देखा: https://zby.github.io/commonplace/agent-memory-systems/reviews/wuphf/
    24 घंटे के भीतर front page पर आने वाला यह तीसरा LLM wiki है, तो साफ़ है कि विषय काफ़ी गर्म है
    इस क्षेत्र में मेरी भी हिस्सेदारी है, इसलिए मैं पूरी तरह निष्पक्ष नहीं हूँ, लेकिन मैंने ऐसे systems से अपनी अपेक्षाएँ अलग से लिख रखी हैं
    https://zby.github.io/commonplace/notes/designing-agent-memory-systems/
    सबका अपना-अपना system फिर से बनाना बहुत बड़ी duplicate investment जैसा लगता है; अच्छा होगा अगर सहयोग का कोई रास्ता निकले

    • notes काफ़ी दिलचस्प थे
      लेकिन writing style से साफ़ लगता है कि यह LLM ने लिखा है, तो मैं जानना चाहूँगा कि क्या आप बाद में ऐसी design notes को अपने शब्दों में दोबारा लिखते हैं ताकि पक्का हो सके कि उनमें सचमुच आपके अपने विचार हैं
    • Borrowable Ideas section मुझे खास तौर पर अच्छा लगा, और अच्छा होगा अगर लोग उसे सच में अपनाएँ
      हम Karpathy के LLM wiki idea सामने लाने से बहुत पहले nex.ai नाम की एक context infra company के तौर पर शुरू हुए थे, और उसकी capabilities अभी WUPHF में लगभग दिखाई नहीं देतीं, लेकिन अब हम धीरे-धीरे उन्हें खोल रहे हैं
      comparison post में लिखी गई कई चिंताएँ वही चीज़ें हैं जिनसे हम अपनी context infra में पहले से निपटते आए हैं, इसलिए यह देखकर अच्छा लगा
      फिर भी duplication कम करने और एक-दूसरे से सीख बाँटने वाले सहयोग का हम पूरा स्वागत करेंगे
    • यह तो साफ़ है कि generative slot machines लोगों को अलग-थलग भी करती हैं
      आपने कहा कि सहयोग का मौका होना चाहिए, तो यह थोड़ा अजीब लगा, जैसे अभी वह मौका है ही नहीं
    • एक बार पढ़ूँगा
    • सच कहूँ तो अब यह मुझे खुद बनाकर चला लेने वाले क्षेत्र में प्रवेश करता दिखता है
      Obsidian vault पर बस QMD चढ़ा दें तो 80% काम हो जाएगा, और शायद 2 घंटे भी न लगें

  • संदर्भ के लिए Karpathy की मूल पोस्ट के links भी हैं
    https://x.com/karpathy/status/2039805659525644595
    https://xcancel.com/karpathy/status/2039805659525644595

  • सोच रहा हूँ कि AI Notes value बढ़ाएँगे या सिर्फ noise बनाएँगे
    हालांकि वेबसाइट का ASCII style मुझे काफ़ी पसंद आया

  • इस समस्या के समाधान के रूप में कोई StackOverflow revival जैसा कुछ बनाए तो अच्छा होगा
    इंसान curation करें, लेकिन जब सामूहिक LLMs किसी समस्या को हल करते-करते अटक जाएँ तो पुराने तरीके से सवाल पोस्ट कर दें — यानी एक distributed knowledge graph
    अगर मेरा agent कहे, "मैं यहाँ अटक गया हूँ, SO पर सवाल डाल दिया है, जवाब आए तो बाद में लौटते हैं," तो मुझे यह पूरी तरह ठीक लगेगा

  • मैं सोच रहा हूँ कि LLM को बहुत ज़्यादा लिखने से कैसे रोका जाए
    मैंने ऐसे कुछ tools और systems बनाए हैं, और हर बार LLM ने documentation को फुलाकर पूरे system को बिगाड़ दिया; system जितना बड़ा हुआ, उतना कम उपयोगी हो गया
    मैंने पहले एक experiment किया था जहाँ आप कुछ links देते थे, फिर LLM संबंधित topics पर research करके अपनी knowledge wiki बनाता था, हर page पर summary, mutual links, और sources व्यवस्थित करता था
    ऊपर-ऊपर से यह अच्छा लगता था, लेकिन असली data पढ़ने पर उतना अच्छा नहीं था
    वह experiment कुछ साल पुराना है, तो शायद अब opus 4.7 जैसी किसी चीज़ के साथ उसे दोबारा आज़माना सार्थक हो सकता है

  • विचार के लिए एक और बात: TiddlyWiki community ने भी स्वाभाविक रूप से AI tools को explore किया है
    TiddlyWiki एक self-modifiable single HTML file आधारित wiki है, और 20 साल से अधिक समय से मौजूद है
    यह ज़रूरी नहीं कि पूरी तरह agentic environment में evolve हुआ हो, लेकिन इसमें markdown plugin भी हैं, और files को executable या self-serving webapp में बदलने वाले tools भी हैं। Git थोड़ा मुश्किल है
    इसलिए सिद्धांततः एक single-file agentic wiki इधर-उधर घूमते हुए खुद को modify भी कर सकता है
    https://tiddlywiki.com/

    • जानकारी के लिए, TiddlyWiki का मूल निर्माता मैं ही हूँ
      आपने जिस single-file setup का ज़िक्र किया, उसके लिए पहले से कई LLM connectors हैं। जैसे https://github.com/rimir-cc/tw-llm-connect
      इसकी खूबी भी ठीक वही है। कोई dependencies नहीं, installation की ज़रूरत नहीं, storage बहुत आसान — इसलिए ऐसा single-file agentic wiki जो खुद को edit करे, आज ही संभव है
      Karpathy के LLM Wiki pattern के और करीब एक चीज़ twillm भी है, जिस पर मैं काम कर रहा हूँ
      https://github.com/Jermolene/twillm
      यह TiddlyWiki के Node.js setup का इस्तेमाल करता है, tiddlers को अलग-अलग files में store करता है, जिससे मौजूदा Markdown vault को सीधे point किया जा सकता है और Claude Code जैसे tools के साथ इस्तेमाल किया जा सकता है
      TiddlyWiki के फायदे भी काफ़ी साफ़ हैं। यह open source है, इसलिए लंबी अवधि में भी इस्तेमाल किया जा सकता है, और web-based होने के कारण कहीं से भी access किया जा सकता है
      साथ ही, computed views materialized index files की जगह लेते हैं। Karpathy वाले approach में LLM को हर बार notes जोड़ते समय index.md को sync रखना पड़ता है, और इस तरह की चीज़ session बदलते ही stale होना आसान है — खासकर LLM के लिए
      जबकि TiddlyWiki के views real-time filter expressions होते हैं, इसलिए जैसे "concept tag वाले tiddlers को rating के हिसाब से sort करो" जैसी चीज़ें render time पर तुरंत calculate हो जाती हैं
      Frontmatter भी queryable structure बन जाता है। Obsidian YAML frontmatter को note के ऊपर box-style metadata की तरह दिखाता है, जबकि TiddlyWiki उन fields को first-class tiddler fields बना देता है, जिन्हें सीधे filtering, sorting, और aggregation में इस्तेमाल किया जा सकता है
      और LLM सिर्फ content ही नहीं बल्कि छोटे applets भी लिख सकता है। Markdown notes के अलावा wikitext tiddlers (.tid) डालकर dashboards, tag exploration tools, journal indexes, glossary जैसी interactive live views भी बनाई जा सकती हैं

  • self building artefacts का क्षेत्र दिलचस्प है, और हाल में LLM, खासकर coding models, इस दिशा में तेज़ी से बेहतर होने के कारण यह अभी काफ़ी बढ़ रहा है
    मैंने भी हाल में एक project पर experiment किया है जो dependencies को न्यूनतम रखने और local पर agents को control करने पर केंद्रित है
    https://github.com/GistNoesis/Shoggoth.db/
    यह prompt में दिए गए long-running tasks को पूरा करने के लिए खुद एक sqlite database बनाता और व्यवस्थित करता है, और source data के रूप में local Wikipedia copy का इस्तेमाल करता है
    agent drift को test करने के लिए harness और tools भी बहुत न्यूनतम रखे गए हैं
    image processing tools जोड़ना भी काफ़ी आसान है। images को base64 में encode करके llama.cpp को दे दीजिए, और बाकी implementation को local LLM से लगभग vibecoding करवा सकते हैं
    मुझे यह काफ़ी broadly useful tool लगता है
    उदाहरण के लिए, पहले मेरे पास ऐसा script था जो folder में पड़े invoices और receipts से amounts, dates, और vendors निकालने के लिए Amazon Textract इस्तेमाल करता था, और फिर numbers को इंसान verify करके accountant को देने के लिए CSV बनाता था
    अब आप उस Amazon Textract call को किसी सही prompt वाले llama.cpp model call से बदल सकते हैं, और मौजूदा invoice tool को बरकरार रखते हुए उससे कहीं ज़्यादा रचनात्मक accounting workflows भी कर सकते हैं
    मैंने camera image sequence से physical robot चलाने वाला एक variant भी आज़माया, और साधारण मामलों में वह सचमुच चलकर लक्ष्य तक पहुँच गया
    लेकिन मेरा इस्तेमाल किया हुआ LLM मूलतः robot driving के लिए trained नहीं था, और अगला action चुनने में 10 सेकंड लगा देता था, इसलिए व्यावहारिक नहीं था। आज के non-deep-learning traditional controllers vision loop को 20Hz पर चलाते हैं

  • LLM models और उन पर बने agents deterministic नहीं बल्कि probabilistic होते हैं
    वे कुछ प्रतिशत मामलों में काम कर लेते हैं, लेकिन हर बार सफल नहीं होते
    इसलिए agent किसी task को जितना लंबा खींचता है, failure probability उतनी बढ़ती जाती है। इस तरह के long-running agents आखिरकार fail हो जाते हैं, और इस प्रक्रिया में भारी token cost भी जला देते हैं
    LLM agents की एक खासियत यह भी है कि वे अपने instructions को फिर से लिखने में अच्छे होते हैं
    तरकीब यह है कि thinking model के समय और reasoning steps को सीमित किया जाए, फिर evaluate, update, और rerun किया जाए
    एक तरह से कहें तो agent को गिरने वाला मानिए। उसे बहुत देर तक दौड़ाकर गिराने के बजाय, 10 मिनट एक बार की तुलना में 5 मिनट दो बार बेहतर है
    कुछ ही हफ्तों में ऐसे self-referential agents शायद सबके Twitter feed के ऊपर छाए होंगे

    • agents और ML में यह समस्या भी है कि अगर external feedback न हो तो वे local maxima में फँस जाते हैं
      इसलिए ऐसे wiki systems किसी एक अवस्था पर पहुँचकर वहीं रुक जाने की पूरी संभावना रखते हैं