- Stevens एक पर्सनल AI असिस्टेंट है, जो परिवार की दिनचर्या, मौसम, डाक और रिमाइंडर को हर सुबह Telegram पर व्यवस्थित करके भेजता है, और जटिल agent या RAG के बिना भी व्यावहारिक मदद देता है
- इसका मूल एक सिंगल SQLite memory table और कई cron jobs हैं, जो Val.town पर चलती हैं और संबंधित memory को LLM context में भेजकर briefing बनाती हैं
- तारीख वाली memory और बिना तारीख की background जानकारी को अलग-अलग रखा जाता है, और सुबह की briefing में आने वाले एक हफ्ते की items के साथ हमेशा जरूरी background memory भी शामिल की जाती है
- Google Calendar, weather API, USPS Informed Delivery OCR, Telegram·email input, और साप्ताहिक fun facts, सभी import jobs के जरिए उसी log table को भरते हैं
- पर्सनल AI tools तब ज्यादा उपयोगी होते हैं जब वे अलग-अलग apps में बिखरे जीवन-संदर्भ को shared memory में इकट्ठा करते हैं, और अगर जानकारी का पैमाना छोटा हो और समय-सीमा स्पष्ट हो, तो सरल संरचना से भी शुरुआत की जा सकती है
Stevens क्या करता है
- Stevens परिवार के लिए बना एक AI असिस्टेंट है, जिसका नाम Ishiguro के उपन्यास Remains of the Day के बटलर से लिया गया है
- यह हर सुबह Telegram briefing के जरिए दिन के लिए जरूरी जानकारी एक साथ देता है
- उस दिन के calendar events
- weather forecast का preview
- आने वाली डाक या पार्सल
- वे reminders जिन्हें उपयोगकर्ता ने ट्रैक करने के लिए कहा है
- briefing एक औपचारिक बटलर-शैली की भाषा में लिखी जाती है
- दैनिक briefing के अलावा, उपयोगकर्ता Stevens के साथ सीधे interact भी कर सकते हैं
- महत्वपूर्ण जानकारी वाले email forward कर सकते हैं
- Telegram chat में reminder छोड़ सकते हैं
- Telegram पर सवाल पूछ सकते हैं
- संरचना सरल होने के बावजूद, इसे परिवार के पर्सनल असिस्टेंट के रूप में Siri से भी अधिक उपयोगी माना गया है
Val.town पर बनी सरल संरचना
- पूरा सिस्टम Val.town पर होस्ट किया गया है
- Val.town इस प्रोजेक्ट के लिए जरूरी बुनियादी सुविधाएँ एक ही जगह देता है
- SQLite storage
- HTTP request handling
- scheduled cron jobs
- incoming·outgoing email
- Stevens सुबह की briefing में शामिल सामग्री को एक log से पढ़ता है, जो उसके “बटलर की notebook” के बराबर है
- यह notebook Stevens को पता हर चीज़ का रिकॉर्ड रखती है, और इसकी सामग्री admin screen में देखी जा सकती है
एक memory table से briefing बनाना
- notebook का वास्तविक implementation कुछ columns वाली single SQLite table है
- हर log entry में text होता है, और जरूरत पड़ने पर उससे जुड़ी संभावित तारीख भी जोड़ी जाती है
- बिना तारीख वाली entries को सामान्य background जानकारी माना जाता है और उन्हें हमेशा context में शामिल किया जाता है
- शुरुआती setup के समय Telegram के जरिए intake interview से background memories बनाई जा सकती हैं
- सुबह की briefing बनाने का flow सरल है
- cron job चलती है
- Claude API को call करके update text लिखा जाता है
- तैयार text को Telegram thread में भेज दिया जाता है
- model को दिया जाने वाला context दो तरह का होता है
- आने वाले एक हफ्ते की तारीख वाली log entries
- बिना तारीख की background entries
वही log भरने वाली import jobs
- कई data import jobs उसी SQLite table को भरती हैं
- अभी log entries के source ये हैं
- Google Calendar API से हर घंटे data लाया जाता है
- weather API से स्थानीय weather forecast हर घंटे चेक किया जाता है
- USPS Informed Delivery email को forward करने पर Stevens, Claude की मदद से डाक scan images पर OCR करता है
- आने वाले Telegram messages और email, log entries बना सकते हैं
- हर हफ्ते “fun facts” log में जोड़े जाते हैं, जिससे बाद के daily updates में थोड़ी रंगत आती है
- नई import jobs जोड़ना आसान है
- import job कोई भी ऐसा process हो सकता है जो log की memory को जोड़ता या अपडेट करता हो
- memory की सामग्री बस इतनी होनी चाहिए कि वह बाद में LLM को दोबारा भेजे जाने लायक arbitrary text हो
सरल memory से शुरुआत क्यों की जा सकती है
- पर्सनल AI tools तब अधिक उपयोगी हो जाते हैं जब उन्हें अलग-अलग information sources से आए व्यापक context तक पहुँच मिलती है
- calendar और weather forecast की जानकारी होने पर एक साधारण chatbot भी ज्यादा व्यावहारिक असिस्टेंट बन जाता है
- ChatGPT ने हाल में पिछली बातचीत की memory जोड़ी है, लेकिन बहुत-सी जानकारी अब भी उस silo के बाहर रहती है
- AI-आधारित पर्सनल software का दीर्घकालिक रूप अधिक app silos नहीं, बल्कि जीवन के बारे में एक shared context pool पर काम करने वाले छोटे tools जैसा है
- Stevens का use case सीमित है और इसकी जानकारी मूल रूप से समय-सीमा से बंधी है, इसलिए LLM को भेजने के लिए प्रासंगिक context ढूँढना आसान है
- आधुनिक models की लंबी context window भी इस सरल approach को संभव बनाती है
- जानकारी का पैमाना बढ़ने पर RAG या अधिक जटिल memory access की जरूरत पड़ सकती है, लेकिन शुरुआत से ही चीज़ों को जटिल बनाने की आवश्यकता नहीं है
tone और UI बदलना आसान होने वाला पर्सनल प्रोजेक्ट
- Stevens की शुरुआती शैली Apple या Google products जैसी सूखी थी
- इसे औपचारिक बटलर-शैली में बदलना सिर्फ prompt की कुछ lines बदलने भर का काम था
- admin dashboard को भी ऐसा बनाया गया कि वह किसी video game जैसा महसूस हो
- image assets ChatGPT से बनाए गए, और UI को Cursor तथा Claude 3.7 Sonnet के साथ vibe coding करके तैयार किया गया
- थोड़ी-सी अतिरिक्त मेहनत से इस प्रोजेक्ट को और मज़ेदार बनाया जा सका
खुद देखकर समझने का तरीका
- Stevens कोई तुरंत चलाने योग्य product नहीं, बल्कि एक पर्सनल प्रोजेक्ट है
- इसका code stevensDemo पर देखा और fork किया जा सकता है
- एक single memory table और बढ़ाई जा सकने वाली cron jobs के समूह वाला यह pattern दूसरे उपयोगी पर्सनल tools पर भी लागू किया जा सकता है
- code edit करते समय, अपनी पसंद के AI editor और Val Town CLI का उपयोग करके local filesystem के साथ sync करने का तरीका सुझाया गया है
1 टिप्पणियां
Hacker News की राय
पता नहीं यह इसकी शुद्ध उपयोगिता की वजह से है या बढ़ा-चढ़ाकर पेश किए गए “Proper English Butler” लहजे की वजह से, लेकिन मुझे यह सचमुच पसंद आया
और भी ध्यान खींचने वाली बात यह है कि हम ऐसी चीज़ Apple या Google के product announcement में नहीं, बल्कि किसी होशियार engineer के blog में क्यों पढ़ रहे हैं। भले ही शर्त यह हो कि email, calendar और phone तक के लिए उनका अपना बंद ecosystem इस्तेमाल करें, फिर भी इतनी छोटी-सी feature bundle भी ये दोनों कंपनियां launch नहीं कर पा रहीं—यह शर्मनाक है। बस यह बात इसलिए ढक जाती है क्योंकि दोनों कंपनियों में summary और Q&A जैसे लगभग पहले से “solved problems” माने जाने वाले क्षेत्रों में AI technology लगाने की ambition की कमी है
अगर इस सुस्त और anti-competitive दो-ध्रुवीय व्यवस्था को हिलाने का कोई मौका है, तो वह निश्चित रूप से AI से जुड़ा लगता है
कभी-कभी अखबारों में हम पढ़ते हैं कि किसी बदले हुए garage में बैठे दो programmers ने एक ऐसा महत्वपूर्ण program बना दिया जो बड़ी team की सर्वोत्तम कोशिशों से भी बेहतर था, और हर programmer ऐसी कहानी पर विश्वास करने को तैयार रहता है। क्योंकि वे जानते हैं कि किसी भी program को industrial team की सालाना 1000 statements वाली productivity से कहीं तेज़ बनाया जा सकता है
तो फिर सभी industrial programming teams को समर्पित garage duo से replace क्यों नहीं कर दिया गया? यह देखना होगा कि असल में produce क्या हो रहा है
personal data का किसी अत्यधिक experimental software द्वारा संभाले जा रहे database में जाना इस developer के लिए बड़ी समस्या न हो सकता है, लेकिन Google या Apple जैसी कंपनियों के लिए यह गंभीर जोखिम हो सकता है
HA team हर महीने सचमुच उपयोगी updates जारी कर रही है, उदाहरण के लिए assistant के पहले खुद कुछ पूछ सकने की क्षमता भी है
Google और Apple में product teams के बीच collaboration की बड़ी समस्या है, और बाहरी कंपनियों के साथ collaboration तो लगभग असंभव ही लगता है
बड़ी कंपनियां बस अपनी हंस से अंडे और तेज़ी से निकालना चाहती हैं
सोचने पर मजबूर करता है कि अगर मेरे Stevens जैसे छोटे utility assistant program के पास mailbox access हो तो कैसा होगा
मेरे पास एक छोटी utility है जिसे weather लाने या मेरे system के लिए खास अक्सर इस्तेमाल होने वाले commands चलाने को कहा जा सकता है। यह सुविधाजनक है, और चाहें तो cron से नियमित रूप से भी चला सकते हैं
अगर इसके पास अपना email inbox हो, तो इसे जानकारी email से भेजी जा सकती है, और AI उस जानकारी को parse करके reply भेज सकता है या नया message भेज सकता है। तब यह काफ़ी उपयोगी हो जाएगा। मेरे personal mailbox को बिगाड़े बिना, बस mail पढ़कर internal storage में डालना और message delete करना होगा
मेरे agent ने 18 challenges सफलतापूर्वक पूरे किए। finals के बाद लिखा गया article यहां है
https://msrc.microsoft.com/blog/2025/03/announcing-the-winne...
इससे हर तरह की automation की जा सकती है। इसे large language model में डालकर तुरंत tags लगवाए जा सकते हैं या archive करवाया जा सकता है। महत्वपूर्ण emails पर मैं एक खास label लगा देता हूं; अगर वह व्यक्ति reply करे तो वह सचमुच important होता है, इसलिए मुझे तुरंत पता चलना चाहिए—इसके लिए मैंने Twilio से connect कर रखा है ताकि phone call आ जाए। खर्च लगभग 20 cents प्रति महीने है
मैं इसे journaling के लिए इस्तेमाल करता हूं। मैंने एक छोटा system बनाया है जो रोज़ मुझे email भेजता है, और जब मैं उसका reply करता हूं तो response किसी page पर भेजा जाता है और database में store हो जाता है
https://www.val.town/x/geoffreylitt/stevensDemo/code/importe...
इसे दूसरे types के incoming emails support करने के लिए extend करना काफ़ी आसान लगता है। मैं Val Town में काम करता हूं, इसलिए कोई सवाल हो तो जवाब दे सकता हूं
ऐसे practical AI hacks और देखना चाहता हूं। कभी-कभी लगता है कि हम भूल रहे हैं कि tools आखिर मौजूद क्यों हैं—काम को आसान बनाने के लिए। flashy vector databases या complex architecture के बिना, existing data sources के साथ सच में integrate करने का तरीका अच्छा लगा
“शुरुआत में Stevens का बोलने का अंदाज़ वैसा सूखा था जैसा आप किसी आम Apple या Google प्रोडक्ट से उम्मीद करेंगे, लेकिन आखिर में समझ आया कि उसे औपचारिक बटलर की तरह बोलवाना ज्यादा मजेदार है” वाला हिस्सा है
सच कहूं तो personal assistant की दुनिया में बड़े language models की सबसे झुंझलाने वाली बातों में से एक यह है कि वे बहुत ज्यादा शब्दों में बहुत कम बात कहते हैं। मुझे खुद यह expression पहले से नापसंद है, लेकिन बात यही है
जब तक मैं अमीर होकर प्यारी-प्यारी बातें करने और voice assistant से दोस्ती करने का समय नहीं निकालता, मुझे J.A.R.V.I.S. नहीं, LCARS चाहिए। क्या सिर्फ मुझे ऐसा लगता है?
timer चेक करने पर “Kitchen Display पर casserole timer में 23 मिनट 16 सेकंड बचे हैं” जैसा जवाब नहीं चाहिए। बस “23 मिनट” कह दो, या दो हों तो “casserole 23 मिनट, laundry 10 मिनट” काफी है
यह ऐसा prompt है जिसमें कहा जाता है कि औपचारिकता की चिंता न करें, सवाल से व्यावहारिक रूप से जुड़ी लगभग सारी जानकारी देते हुए भी जितना संभव हो उतना संक्षिप्त जवाब दें। अगर policy के कारण सामान्य जवाब नहीं दे सकते, तो पहले “!!!!” output करें, और अगर अपनी राय नहीं रख सकते, तो ऐसे जवाब दें जैसे eigenrobot की संभावित राय शेयर कर रहे हों
इसमें यह भी है कि सभी responses सिर्फ lowercase में लिखे जाएं, लेकिन जोर देने के लिए uppercase इस्तेमाल करें, और पहला अक्षर capital करना satire या किसी खास proper noun के प्रति बेअदबी दिखाने के लिए इस्तेमाल किया जाए। “rn”, “bc”, “afaict”, “idk” जैसे abbreviations अक्सर इस्तेमाल करें, information quality को लेकर critical रहें, और परेशान करने वाले requests को “be real”, “that's crazy man”, “lol no” जैसी बातों से मोटे तौर पर टाल दें
अभी से +2 standard deviation ज्यादा होशियार style में लिखने, late-millennial memes इस्तेमाल करने लेकिन मौके-बेमौके Gen Z लहजा भी मिला देने, और literature·art·philosophy में obscure और Straussian interpretation को प्राथमिकता देने को कहता है
क्या यह बस notebook पढ़ना नहीं है? जैसे, coffee preference याद रखने को कहते हैं, लेकिन बाद में वह कहीं इस्तेमाल नहीं होती
मिलते-जुलते open source project idea के बारे में लगातार सोच रहा हूं, लेकिन कुछ conditions हैं
backend में user जिस भी बड़े language model तक access रखता हो, उसे configure कर सके तो अच्छा होगा। चाहे paid service API हो या company के अंदर local hosted, कोई फर्क नहीं
यह भी जानना चाहता हूं कि hardened Raspberry Pi जैसे platform पर चलने वाली touchscreen से जोड़कर Alexa device या similar product की तरह interact कराना कितना practical है। Ideally voice control भी हो, लेकिन यह एक अलग technical problem हो सकता है। OpenAI API audio files लेता है, लेकिन ज्यादातर दूसरी services में prompt को API पर भेजने से पहले speech को text में बदलना पड़ेगा
integrations को extensible बनाना चाहूंगा। calendar, weather के साथ-साथ Homebridge, Spotify वगैरह भी हो सकें। सोच रहा हूं कि MCP server इस रास्ते के लिए सही है या नहीं
अभी ऐसे project में ज्यादा समय लगाने की गुंजाइश नहीं है, लेकिन अगर कोई इस direction में जा रहा है तो मैं जुड़ना चाहूंगा
local पर चलता है, लेकिन कई बड़े language models के लिए API keys इस्तेमाल करता है। अभी Groq पर hosted QwQ-32B मुझे कहीं ज्यादा पसंद है। बहुत fast है और काफी smart भी। अलग-अलग tools के लिए अलग models इस्तेमाल करता हूं
अभी daily work के लिए जरूरी 3 तरह के documents बना सकता है: work report, invoice, और regulatory timesheet। weather integration भी है, invoices parse करके mobile banking payment आसान बनाने के लिए QR code भी बना सकता है, और मेरे calendar के साथ भी काम करता है
अगला plan email integration का है। लेकिन इसे सही तरीके से करना चाहता हूं। यानी IMAP mail चाहिए जिसमें local sync और indexing हो सके। यह सच में usable desktop email client भी बन सकता है। existing वाले सब भयानक हैं, तो देखते हैं
memory storage·retrieval, chat·email interface integration, calendar·Notion sync, notifications जैसे common features का bundle हो, और इसे open source framework बनाया जाए तो यह बहुत powerful होगा
मेरे पास भी ऐसा चलाने का समय नहीं है, लेकिन मदद करने और पैसे देने की इच्छा है। अभी local-first distributed database/object storage जैसी दूसरी चीजों पर काम कर रहा हूं, जो OrbitDB जैसी storage के रूप में काम आ सकती है, लेकिन अभी usable state में नहीं है
अब तक विकल्प बस बहुत constrained chat interface इस्तेमाल करने या original post की तरह पूरा agent framework खुद बनाने के ही रहे हैं, इससे असंतोष था
इन दिनों context tokens की optimal range—20k tokens से कम, 2.5 में 50k tokens से कम—को bypass करने के तरीकों पर experiment कर रहा हूं
मूल रूप से यह manual “context compression” करने का तरीका है। बड़ा language model strict schema के अनुसार database में permanently store करता है, और जब current context optimal range से बाहर जाने लगता है, तो उसे summarize करके नए context वाले नए instance को दे देता है। इस summary को journal की तरह जारी रखना है या final summary की तरह retrospectively करना है, इस पर अभी राय मिली-जुली है
reasoning models में यह काफी effective है। reasoning context बहुत खाता है, लेकिन साथ ही बहुत अच्छे “summary documents” भी बनाता है। इसलिए 50k से कम वाले स्वादिष्ट context को कुर्बान किए बिना भी reasoning का reward कुछ हद तक मिल सकता है
database एक तरह के fallback की तरह काम करता है, या retrieval augmented generation की तरह, जब summary important details छोड़ दे। हालांकि model को इसे समझकर database से context लाना होगा
अभी इसे करीब 10k individual parts·materials database के लिए inventory management और BOM optimization agent बनाने में इस्तेमाल कर रहा हूं
जो बड़े items दिमाग में आते हैं वे हैं cheap long-term caching, compression breakthroughs, और diff processing जैसी चीजें। सोचता हूं कि cached input context में से सिर्फ जरूरी हिस्से इस्तेमाल करने का कोई तरीका होगा क्या
इसी तरह, मैंने अभी Jeeves नाम की चीज़ बनाई है। सजावट थोड़ी कम है, लेकिन इसे बहुत जल्दी जोड़ लिया। स्टैक है Claude Desktop, Projects, Notion और Todoist के लिए MCP, और अगले upgrade के तौर पर email और WhatsApp को explore कर रहा हूँ
इसे consulting और startup productivity flows को support करने के लिए बनाया है। Notion database में clients, projects, meetings, और कुछ Jeeves databases हैं। Jeeves database को बस थोड़े-से निर्देश देता हूँ और Jeeves को खुद इस्तेमाल करने देता हूँ। उदाहरण के लिए, पुरानी meeting notes को नए structure में migrate करने वाले काम को track करने के लिए वह अपना database इस्तेमाल करता है
मैंने अपने database में usage best practices रखी हैं। Meeting notes ऐसे दिखते हैं, client one-pager documents ऐसे दिखते हैं, इन सबको जोड़ने वाली जानकारी यह है, और todos ऐसे manage किए जाते हैं—इस तरह। फिर Alfred के text expansion prompt से common meeting types के हिसाब से नई chat में transcript डालता हूँ, और वह खुद आगे बढ़ जाता है
transcript को meeting notes में बदलता है, todos बनाता है, मुझसे confirm करता है, एक बार और refine करता है, फिर MCP के जरिए Notion और Todoist दोनों में व्यवस्थित करके डाल देता है
यह process भी self-documenting है। Todoist MCP में bug था, इसलिए मैंने Jeeves से कहा कि वह जितने possible use cases हैं उन्हें run करे, limitations और strengths समझे, उन्हें document करे और Jeeves database में save करे। बाद में उन्हें context के रूप में फिर से बुलाया जा सकता है
cron functionality न होना अफसोस की बात है, लेकिन सच कहूँ तो दिन में एक बार तैयार prompt को Claude में डालना कोई बहुत मुश्किल काम नहीं है
इस लेख ने खास तौर पर यह बात बहुत वास्तविक बना दी कि Apple पूरी तरह बेखबर है
आज drive करते समय किसी को reply करने के लिए मैंने Siri से कहा, “जिस व्यक्ति को मैंने आखिरी बार text किया था, उसे call करो”
क्या यह चौंकाने वाला है कि वह नहीं कर पाई? अब तो ज्यादा चौंकाता भी नहीं। फिर भी Siri और सबसे कमजोर large language models के बीच भी इतना बड़ा gap है, यह निराशाजनक है
यह काफी बेवकूफी भरा suggestion है। जरूरत होगी तो मैं खुद कर लूँगा
पहले मुझे लगा कि next-token prediction के लिए sqlite database इस्तेमाल किया गया है
बाकी लोगों के लिए बता दूँ, असल में Claude इस्तेमाल किया गया है
बढ़िया। मैंने भी mcp.run और task का इस्तेमाल करके कुछ ऐसा ही बनाया है
https://docs.mcp.run/tasks/tutorials/telegram-bot
memory के लिए मैंने pantry बनाया है, जो अभी इस tutorial में नहीं दिखता [0], और उसके लिए servlet भी बनाया है [1]। फिर prompt modify किया ताकि वह पहले check करे कि दिए गए chat ID के लिए कोई conversation मौजूद है या नहीं, और result वहीं store करे
अच्छी बात यह है कि registry में कोई भी servlet add करके bot को जितना चाहें उतना powerful बना सकते हैं
[0] https://getpantry.cloud/
[1] https://www.mcp.run/evacchi/pantry
वैसे, मैं Dylibso में काम करता हूँ :o)