Claude API और Persistent Memory के साथ एक PM Agent बनाना

मई 2026 · 11 मिनट पढ़ाई · Fran Olivares, Founder of OlivaresAI

Project management ज्यादातर memory का काम है। इस stream का मालिक कौन है? Migration window के बारे में हमने क्या सहमति दी? हमने rate limiter को descope क्यों किया? Release को कानूनी समीक्षा कब block करती है? एक agent जिसे हर सुबह ये प्रश्न फिर से पूछने होते हैं वह agent नहीं है — वह थोड़ा तेज़ intern है। इसे आप तब बदलते हैं जब आप model को एक persistent memory layer देते हैं जिसे वह turns के बीच पढ़ और लिख सकता है, बातचीत से अपने आप populated। यह guide LLM के रूप में Anthropic Claude API और memory layer के रूप में Alma's REST API का उपयोग करते हुए reference architecture और integration code के माध्यम से चलती है।

एक PM agent को विशेष रूप से persistent memory की आवश्यकता क्यों है?

तीन संरचनात्मक कारण। पहला, एक PM जिन entities को track करता है (लोग, निर्णय, deliverables, SLAs, risks) वे स्वयं लंबे समय तक जीवित रहते हैं — परिभाषा के अनुसार वे किसी एकल बातचीत से अधिक जीते हैं। दूसरा, conversational style high-frequency और low-effort है: छोटे standup messages, त्वरित स्पष्टीकरण, "हमने X के बारे में क्या कहा?" प्रश्न। context का सही slice सस्ते में load करना मायने रखता है। तीसरा, भूलने की लागत अधिक है: एक चूका हुआ निर्णय एक चूका हुआ release बन जाता है, एक भुला हुआ dependency एक blocker बन जाता है।

एक stateless Claude बातचीत एक single planning session को अच्छी तरह handle करती है। जैसे ही उपयोगकर्ता निरंतरता चाहता है ("कल हमने सहमति दी…", "इस सप्ताह auth team को क्या block कर रहा है?"), बातचीत को या तो पूरा इतिहास context window में replay करना होगा (महंगा, अंततः असंभव) या model के बाहर एक memory layer पर निर्भर रहना होगा।

Reference architecture कैसी दिखती है?

चार चलते हुए हिस्से:

• Claude API conversation loop। Anthropic SDK से एक project-aware system prompt के साथ एक standard messages.create stream। Tool use enabled है ताकि model आवश्यकता पड़ने पर name से entities के लिए memory layer से पूछ सके।
• Project entity द्वारा keyed memory store। प्रत्येक stakeholder, deliverable, decision और SLA एक category tag (stakeholder, decision, sla, risk) और एक importance score के साथ एक memory record है। Episodes संकुचित दैनिक standups पकड़ते हैं; procedures आवर्ती workflows पकड़ते हैं ("जिस तरह से हम hotfixes handle करते हैं")।
• Automatic extractor। हर बातचीत turn के बाद, एक छोटा Claude Haiku call हाल के messages को पढ़ता है और नई memories (या मौजूदा में updates) प्रस्तावित करता है। यही वह है जो agent को low-friction बनाता है: उपयोगकर्ता निर्णयों को manually log नहीं करता; agent उनके लिए करता है।
• Context assembler। प्रत्येक user turn से पहले, user query के दिए जाने पर सबसे प्रासंगिक entries के लिए memory API से पूछा जाता है। परिणाम Claude system prompt का हिस्सा बन जाता है — इसे इस विशिष्ट प्रश्न के लिए एक curated cheat-sheet के रूप में सोचें।

मैं एक PM agent के लिए memory categories को कैसे structure करूँ?

पाँच categories अधिकांश teams को cover करती हैं: stakeholder (role + ज़िम्मेदारियों वाले लोग), decision (क्या सहमति दी गई, कब, किसके द्वारा, औचित्य के साथ), sla (अन्य teams या ग्राहकों के लिए प्रतिबद्धताएँ), risk (मालिक + शमन के साथ खुले मुद्दे), milestone (target date + scope + status)। प्रत्येक memory एक importance score रखती है ताकि assembler retrieval में high-stakes items को प्राथमिकता दे सके।

Category केवल organisation के लिए नहीं है — यह retrieval signal का हिस्सा है। जब उपयोगकर्ता पूछता है "हमने क्या निर्णय लिया?", assembler decision-category memories को अधिक weigh करता है। जब वे पूछते हैं "कौन block हुआ है?", risk-category memories ऊपर rank होती हैं। Alma context assembly इसी use case के लिए per-category boost weights उजागर करती है।

वास्तविक code में integration loop क्या है?

प्रति user message तीन phases। नीचे pseudo-code Alma SDK और Anthropic SDK के साथ Node.js का उपयोग करता है, लेकिन वही आकार Python या किसी अन्य stack में काम करता है:

• Phase 1 — context assemble करें। const { systemPrompt } = await alma.context.assemble({ query: userMessage, environmentId: projectId });
• Phase 2 — Claude को call करें। const stream = anthropic.messages.stream({ model: 'claude-opus-4-7', system: systemPrompt, messages: [{ role: 'user', content: userMessage }] });
• Phase 3 — memories extract करें। Stream पूरा होने के बाद, await alma.memories.extract({ text: lastTurn, environmentId: projectId });

Phase 3 पृष्ठभूमि में चलता है — उपयोगकर्ता streamed response तुरंत देखता है, और extraction अगले ~1 s में block किए बिना होता है। नई memories deduplicated होती हैं, contradictions मौजूदा entries के विरुद्ध detected होती हैं, और store अपने आप साफ रहता है। पूर्ण SDK reference: @olivaresai/alma-sdk; REST API documentation में HTTP equivalents।

Agent multi-project isolation को कैसे handle करता है?

Alma environments का उपयोग करें: प्रति project एक environment। प्रत्येक environment की अपनी memories, episodes, procedures और Soul blocks होती हैं, दूसरों से पूरी तरह अलग। Agent हर memory call पर environmentId pass करता है; API सीमा को enforce करता है। एक स्पष्ट environment switch के बिना cross-project queries संभव नहीं हैं — जो कि एक PM tool के लिए सही default है जहाँ project A से निर्णय project B में leak होना एक वास्तविक समस्या है।

Team-wide PM agents (एक ही agent के साथ interact करने वाले कई मनुष्य) के लिए, Alma teams resource का उपयोग करें: प्रत्येक team में सभी सदस्यों को दिखाई देने वाली shared memories, plus व्यक्तिगत प्राथमिकताओं के लिए per-user memories होती हैं। Role-based access नियंत्रित करता है कि कौन क्या लिख सकता है।

एक दैनिक standup turn end-to-end कैसा दिखता है?

User message: "standup: backend team, Maria आज migration को unblock कर रही है, José rate limiter पर है; हमने Friday को GA release push करने का निर्णय लिया क्योंकि legal अभी भी DPA की समीक्षा कर रहा है"। Agent का flow:

• Context assemble करें: assembler प्रासंगिक context लौटाता है — पिछली standup episode, GA release के बारे में decision memory, Maria और José के stakeholder records, legal review के बारे में risk memory।
• Claude जवाब देता है: "Updated standup logged। Maria → migration unblocking; José → rate limiter; GA release Friday तक स्थानांतरित pending legal review of DPA। Risk #4 (legal review) status खुला रहता है आपके साथ owner के रूप में।"
• Extractor चलता है: एक नई episode standup का सारांश देती है, GA-release decision memory नई date के साथ update होती है, legal-review risk memory की last touched timestamp refresh होती है (ताकि वह decay न हो), और एक procedure memory workflow "जब GA slip होती है, decision log करें + risk update करें" पकड़ती है।

ध्यान में रखने योग्य सामान्य workflows

Decision archaeology। "हमने rate limiter को descope क्यों किया?" — agent decision memory plus आसपास की episode और जिस risk memory का उसने संदर्भ दिया उसे retrieve करता है। records के citations के साथ उत्तर लौटाता है, ताकि आवश्यकता पड़ने पर उपयोगकर्ता बातचीत में drill कर सके।

Stakeholder lookup। "Migration का मालिक कौन है?" — stakeholder category के विरुद्ध सीधी memory query, record लौटाता है। यदि उत्तर stale है (role पिछले सप्ताह बदल गया), contradiction detection इसे अगली बातचीत में पकड़ता है जो नए मालिक का उल्लेख करती है।

आवर्ती report generation। "इस सप्ताह auth stream के लिए एक status report generate करें" — agent उस stream के लिए tagged episodes, decisions और risks का एक context window assemble करता है, फिर उस curated slice से report का draft बनाता है। यह Claude से raw chat history का सारांश देने के लिए कहने की तुलना में काफी सस्ता और अधिक सटीक है।

मैं system prompt को छोटा कैसे रखूँ जबकि अभी भी grounded रहूँ?

Assembler में default token budgets: memories के लिए ~2 K tokens, episodes के लिए ~1 K, procedures के लिए ~500, Soul blocks के लिए ~500। कुल ~4 K — किसी भी model के context budget से बहुत नीचे, और cache hits बातचीत के पार amortised होते हैं। यदि आपकी project छोटी है (<100 active memories), आप budget को और कम कर सकते हैं। यदि यह बड़ी है (10 K+ memories), assembler ~4 K पर रहता है क्योंकि retrieval records की संख्या को सीमित करता है भले ही store बड़ा हो।

Operationally दो चीज़ें मायने रखती हैं: Soul blocks (agent की identity) को एक stable system-prompt prefix के रूप में cache किया जाना चाहिए ताकि बार-बार calls input tokens का फिर से भुगतान न करें; और dynamic context (memories + episodes) को cache breakpoint के बाद बैठना चाहिए ताकि प्रत्येक call केवल बदले हुए हिस्से को फिर से upload करे। Anthropic की prompt-caching documentation breakpoint placement को covers करती है।

व्यवहार में इसकी लागत क्या है?

एक typical PM team flow (~20 messages/day प्रति उपयोगकर्ता, ज्यादातर standups + clarifications) पर, marginal लागत स्वयं LLM calls द्वारा प्रभावित होती है। Memory layer जोड़ता है: एक assemble call (कुछ KB read + retrieval, ~30 ms), एक extract call (Haiku, ~$0.001 प्रति turn)। प्रति दिन प्रति active user कुल memory overhead: एक cent से बहुत कम। PM team के निर्णय न खोने के value की तुलना में — और math स्पष्ट है।

मैं prototyping कैसे शुरू करूँ?

Alma का Starter plan ($14/month) entry tier है और इसमें persistent memory layer शामिल है। alma.olivares.ai पर sign up करें, Settings में एक API key generate करें, और developers page से SDK starter clone करें। अपने agent code में three-phase loop wire करें, इसे एक single test project पर point करें, और एक सप्ताह तक चलाएँ। Store बातचीतों से स्वाभाविक रूप से populate होगा; आप बिना manual data entry के निर्णयों, stakeholders और risks को जमा होते देखेंगे। वहाँ से यह बस categories को बढ़ाने और assembler को tune करने की बात है।

सम्बंधित पठन: Persistent Memory for AI: Complete 2026 Guide · How to Give AI Persistent Memory · Three-Layer Memory Architecture · Context Assembly Documentation · Environments।

See plans