आपका Agent सब कुछ भूल जाता है: File, Vector और MCP Memory की तुलना

पिछले महीने मैंने देखा कि Claude Code चौथी बार यह फिर से पता लगा रहा था कि मेरा project pnpm इस्तेमाल करता है न कि npm। उसने npm test चलाया, उसे fail होते देखा, माफी माँगी, और pnpm से दोबारा कोशिश की। मैंने इसे पिछले तीन sessions में समझाया था। इनमें से कोई भी बात बची नहीं। Agent runs के बीच कुछ भी नहीं ले जाता जब तक मैं उसे ऐसा न बनाऊं।

यही पूरी समस्या है। एक coding agent runs के बीच stateless होता है। हर session एक खाली context window से शुरू होता है। कल उसने जो कुछ भी पता लगाया — आपके build commands, कोई test flaky क्यों है, staging database रात को reset होती है — सब चला गया। आप दोबारा समझाते हैं, वो दोबारा derive करता है, दोनों tokens बर्बाद करते हैं।

तो आप उसे memory देते हैं। और जैसे ही आप ढूंढने जाते हैं, आपको तीन अलग-अलग चीज़ें मिलती हैं जिन्हें सब "memory" कहते हैं, और उनके बारे में ज़्यादातर लेखन या तो vendor pitch है या tutorial जो आपको नहीं बताएगा कि यह approach कब fail होती है।

संक्षिप्त version: एक solo builder के लिए, flat files default हैं और आपको कुछ और जोड़ने से पहले उन्हें exhausts करना चाहिए। Vector stores तब काम आते हैं जब आपके पास एक बड़ा corpus है जो context में fit नहीं होता। MCP memory servers सबसे flexible हैं और सबसे आसानी से चुपचाप poison हो सकते हैं। ज़्यादातर लोग पहले fancy वाला पकड़ लेते हैं। यह उल्टा है।

यहाँ "memory" का असल मतलब क्या है

तीनों options एक ही चीज़ के competing implementations नहीं हैं। वे अलग-अलग problems solve करते हैं और अलग-अलग तरीकों से fail होते हैं।

Flat files वो markdown या text होती है जो agent startup पर पढ़ता है — CLAUDE.md, AGENTS.md, एक scratch NOTES.md। आप या agent उन्हें लिखते हैं, और वे हर session में context में load होती हैं। कोई search नहीं, कोई embeddings नहीं — बस "पहले यह file पढ़ो।"

Vector stores text को embeddings में बदलते हैं और agent को filename की बजाय meaning के हिसाब से retrieve करने देते हैं। आप कुछ एक बार लिखते हैं, store बाद में relevant chunk ढूंढ लेता है भले ही words match न हों।

MCP memory servers अलग processes हैं जिनसे agent Model Context Protocol पर बात करता है, जो किसी भी compatible host को tools, resources और prompts expose करता है। एक memory server "इस fact को store करो" और "मेरी memory search करो" जैसे tools add करता है जिन्हें agent task के दौरान call करता है।

मैंने तीनों के साथ ship किया है। यहाँ हर एक का ईमानदार मूल्यांकन है।

Files: बोरिंग, सस्ती, और सही default

File memory वो है जो आपके पास पहले से है। Claude Code हर session की शुरुआत में CLAUDE.md पढ़ता है, system prompt के बाद एक user message के रूप में पूरी तरह load होकर — enforced configuration के रूप में नहीं, जो मायने रखता है, क्योंकि agent इसे ignore भी कर सकता है। Files एक hierarchy से load होती हैं: एक managed org-wide file, आपकी personal ~/.claude/CLAUDE.md, project ./CLAUDE.md, और एक gitignored CLAUDE.local.md, सबसे broad से most specific तक ordered ताकि सबसे करीबी instruction आखिर में पढ़ी जाए।

अब auto memory भी है: Claude अपने notes ~/.claude/projects/<project>/memory/MEMORY.md में लिखता है, और उस file की पहली 200 lines (या 25KB) हर session में load होती हैं। यह build commands और debugging insights save करता है जो उसे discover होती हैं, बिना आपके type किए। मैं इसे on रखता हूँ; इसने कुछ "हाँ, API tests को local Redis चाहिए" जैसे facts पकड़े हैं जो मैंने वरना दोबारा समझाए होते।

CLAUDE.md में क्या डालना है इस पर मैं दोबारा नहीं लिखूँगा — मैंने उस पर पूरी post लिखी है। यहाँ point architectural है: files ठीक एक काम में अच्छी हैं, और वो काम ज़्यादातर agents को चाहिए — facts का एक छोटा, curated set जो हर session में सच होना चाहिए।

Files किसमें अच्छी हैं:

• कोई infrastructure नहीं। यह आपके repo में एक text file है। Version-controlled, diffable, PR में reviewable।
• आप अपनी खुद की memory पढ़ सकते हैं। जब agent कुछ मूर्खतापूर्ण करे, आप file खोलें और देखें उसे क्या बताया गया था। Embedding के साथ करके देखो।
• यह survive करती है। Project-root CLAUDE.md को /compact के बाद भी re-inject किया जाता है, इसलिए एक लंबा session इसे नहीं खोता।

Files किसमें कमज़ोर हैं:

• हर request में tokens खर्च होते हैं। CLAUDE.md में सब कुछ पूरे session में आपके context window में रहता है। Docs कहते हैं 200 lines से कम रखें, और वो सही हैं — उसके बाद adherence गिरती है और आप उन instructions के लिए pay कर रहे हैं जिन्हें agent skim करता है।
• कोई retrieval नहीं। आप एक ऐसी file में हज़ार facts नहीं रख सकते जो agent हर बार पढ़े। यह working set है, database नहीं।
• Staleness आपकी ज़िम्मेदारी है। अगर आपका build command बदला और आप file update करना भूल गए, agent confidently पुराना चलाएगा। File को नहीं पता वो गलत है।

ज़्यादातर solo projects के लिए files काफी हैं। मैंने ऐसे products ship किए हैं जहाँ CLAUDE.md और auto memory पूरा memory system था और मुझे कभी ज़्यादा नहीं चाहिए था।

Vector stores: अच्छा recall, कोई judgment नहीं

जब आप जो याद रखना चाहते हैं वो एक file में fit नहीं होता जिसे agent हर बार पढ़े — एक साल के architecture decisions, एक बड़ा internal wiki, हर past bug और उसका fix — तो आप retrieval की तरफ जाते हैं। एक vector database आपके text के high-dimensional embeddings store करता है और meaning के हिसाब से nearest matches ढूंढता है, आमतौर पर दसियों milliseconds में।

शुरू करने के लिए dedicated vector DB की ज़रूरत नहीं। अगर आप पहले से Postgres चला रहे हैं, pgvector उस database में vector storage और search add करता है जो आपके पास पहले से है, जो आमतौर पर solo builder के लिए सही पहला कदम है। 2026 का default hybrid search है — keyword plus vector — क्योंकि pure semantic search exact-match cases miss करती है जैसे specific function name या error code।

Vector stores किसमें अच्छे हैं:

• Scale पर recall। यह तीनों में से अकेला है जो "मेरे पास दस हज़ार notes हैं, relevant तीन ढूंढो" handle करता है। Files नहीं कर सकतीं और MCP graph servers struggle करते हैं।
• Wording पर नहीं, meaning पर। आपने लिखा "checkout flow retry पर double-charge करता है", बाद में आपने पूछा "payment दो बार क्यों fire होता है", और यह note ढूंढ लेता है। Keyword search नहीं ढूंढता।

Vector stores किसमें कमज़ोर हैं:

• Retrieval quality एक pipeline है, setting नहीं। Embedding model, chunking strategy, index type, और update cadence सब interact करते हैं। Chunking गलत हो जाए और आप आधी thought retrieve करते हैं। यह real काम है, और ज़्यादातर solo builders इसे underestimate करते हैं।
• सच का कोई concept नहीं। Vector store वो return करता है जो similar है, जो correct या current है वो नहीं। अगर आपने March में एक fact store किया और May में सच बदल गया, दोनों versions index में हैं और March वाला similarity पर जीत सकता है।
• यह एक poisoning surface है। जो भी store में feed करता है — agent ने index की हुई कोई web page, shared folder में किसी ने drop किया doc — वो text plant कर सकता है जो बाद में authoritative context के रूप में retrieve होता है। इस पर नीचे और बात।

मैं vector store तब लेता हूँ जब corpus वाकई context के लिए बहुत बड़ा हो और मुझे recall चाहिए। "मेरे पाँच project conventions याद रखो" के लिए यह wildly over-engineered है।

MCP memory servers: flexible, structured, और बड़ा attack surface

तीसरा option है MCP पर connect एक memory server। Reference implementation Anthropic का knowledge-graph memory server है। यह memory को एक graph के रूप में model करता है: entities (type के साथ named nodes), relations (उनके बीच directed, active-voice connections), और observations (entity से attached atomic facts)। यह एक local memory.jsonl file में persist करता है और create_entities, add_observations, search_nodes, और read_graph जैसे tools expose करता है।

Pitch यह है कि structure flat blob से बेहतर है। "User pnpm prefer करता है" एक User entity पर observation बन जाती है, एक Project entity से related, और agent prose grep करने की बजाय उसे traverse करता है। Practice में यह files और vectors के बीच है: text file से ज़्यादा queryable, embedding से ज़्यादा interpretable।

जानने योग्य: Anthropic का अपना memory tool एक अलग mechanism है — एक client-side tool जहाँ model /memories directory पर view, create, str_replace, delete commands issue करता है और आप implement करते हैं कि bytes कहाँ रहते हैं। इसका system prompt model को बताता है "किसी और चीज़ से पहले हमेशा अपनी MEMORY DIRECTORY देखो... आपका context window किसी भी पल reset हो सकता है।" यह कुछ बताता है: Anthropic का खुद का "memory tool" भी नीचे files ही है।

MCP memory servers किसमें अच्छे हैं:

• Structured recall जिस पर agent reason कर सके। Graph traversal "इस project के बारे में मुझे क्या पता है" का जवाब similarity search से ज़्यादा precisely देता है।
• Portability। MCP एक standard है, इसलिए वही server Claude Code, Cursor और किसी भी compatible host पर काम करता है। एक memory, कई tools।
• Explicit writes। Agent decide करता है क्या एक discrete observation के रूप में store करने लायक है, जो memory को pure transcripts को vector index में dump करने से ज़्यादा clean रखती है।

MCP memory servers किसमें कमज़ोर हैं:

• Setup और running process। Install, configure और alive रखने का एक और हिस्सा। एक project के लिए, यह बहुत ceremony है।
• Graph drift करता है। Discipline के बिना, आपको duplicate entities ("Project", "the project", "my app") और contradictory observations मिलते हैं। जो structure help करने वाली थी उसे अब gardening चाहिए।
• Poison करना सबसे आसान है। Persistent, writable, retrieved-as-authoritative — यही attackers का exact target profile है।

दो failure modes जो कोई landing page पर नहीं लिखता

हर "अपने agent को memory दो" post upside बेचती है। यहाँ वो दो हैं जिन्होंने मुझे काटा।

Memory poisoning। यह seriously लेने वाला है। Prompt injection के विपरीत जो session close होने पर खत्म हो जाता है, memory poisoning एक persistence attack है — आज आपके store में plant की गई malicious instruction हफ्तों बाद एक unrelated task से trigger होती है। Attack और उसका effect temporally decoupled हैं। Memory में लिखने वाला कोई भी pipeline एक entry point है: agent ने index की हुई web page, उसने summarize की dependency का README, एक shared doc। Vector stores और MCP servers दोनों exposed हैं क्योंकि दोनों automatically content ingest करते हैं और trusted context के रूप में serve करते हैं। Files वो safe वाली हैं, precisely क्योंकि human उन्हें लिखता है और diff में पढ़ सकता है।

Stale facts reality को override करते हैं। कम dramatic, ज़्यादा common। आपकी memory कहती है pricing tier $20 है। यह पिछले मंगलवार $25 हो गई। Agent cached fact pull करता है बिना time-to-live check के और पुरानी संख्या को authoritative बताता है। Agent को पता नहीं page एक घंटे पहले बदली। हर memory system में यह problem है, और system जितना "automatic" है, उतना बुरा है, क्योंकि कोई नहीं देख रहा क्या लिखा गया। मैंने इस exact तरीके से एक गलत config value ship की है। Memory confident थी। Memory गलत थी।

असहज सच: जितना आप memory को automate करते हैं, उतना कम आप notice करते हैं जब वो आपसे झूठ बोल रही है। Files को hand से maintain करना annoying है, और वही annoyance audit भी है।

Solo builder के रूप में मैं actually क्या चलाऊँगा

Files से शुरू करें। CLAUDE.md उन facts के लिए जो आप बार-बार समझाते रहते हैं, auto memory on रखें ताकि agent बाकी capture करे। यह ज़्यादातर solo project को जो चाहिए वो cover करता है, setup में कुछ खर्च नहीं, और आप इसका हर byte पढ़ सकते हैं। तब तक दूसरा system न जोड़ें जब तक files clearly fail न हों — और "fail" मतलब एक specific symptom: agent उस decision को नहीं ढूंढ सकता जो आप जानते हैं आपने लिखा था, या आपकी CLAUDE.md 200 lines से ज़्यादा हो गई जो केवल कभी-कभी matter करती हैं।

जब ऐसा हो, एक सवाल पूछें: क्या problem recall है या structure? अगर आपके पास बड़ा corpus है और agent सही piece नहीं ढूंढ सकता, वो recall है — vector store जोड़ें, अगर Postgres पर हैं तो pgvector से शुरू करें, hybrid search इस्तेमाल करें। अगर आप चाहते हैं agent sessions के पार relationships के बारे में reason करे और आप multiple tools में काम करते हैं, वो structure है — MCP memory server का setup cost justify होता है।

जो भी जोड़ें, memory को ऐसी चीज़ की तरह treat करें जो गलत हो सकती है। जो facts expire होते हैं उन पर date डालें। समय-समय पर पढ़ें क्या लिखा गया — Claude Code का /memory command files के लिए exactly यही दिखाता है, और यह plain markdown है जिसे आप edit या delete कर सकते हैं। Automated pipeline को कभी memory में उस source से न लिखने दें जिसे आप खुद अपने terminal में paste नहीं करेंगे।

Agent का सब कुछ भूलना annoying है। Agent का गलत चीज़ confidently याद रखना बुरा है। सबसे simple memory चुनें जो आपकी actual problem solve करे, और इतनी छोटी रखें कि आप तब भी बता सकें जब वो गलत हो।