एक Agent बनाना आसान नहीं है।
एक साल पहले, हमें कॉन्टेक्स्ट और मेमोरी खुद संभालनी पड़ती थी, RAG और वेक्टर डेटाबेस के बारे में सोचना पड़ता था, और टूल उपयोग की सटीकता को बहुत सावधानी से समायोजित करना पड़ता था। Claude Code / Claude Agent SDK के उभरने ने यह सब बदल दिया। अब अधिक से अधिक टीमें Claude Agent SDK + VM का उपयोग करके सीधे Agent बनाना शुरू कर रही हैं। तो क्या समस्या सरल हो गई? नहीं।
VM में Claude Code चलाना अब भी एक बहुत चुनौतीपूर्ण काम है।
-
हर यूज़र सेशन को एक स्वतंत्र VM की ज़रूरत होती है। कुछ परिदृश्यों में, VM की पर्सिस्टेंस क्षमता उपयोगी हो सकती है, पर यह VM को अपग्रेड और ऑर्केस्ट्रेट करना भी मुश्किल बना देती है। उदाहरण के लिए, यूज़र के नज़रिए से, वे उम्मीद करते हैं कि VM पर इंस्टॉल किया गया सॉफ्टवेयर महीनों बाद भी उपलब्ध रहेगा। पर VM के वे हिस्से जो ऑर्केस्ट्रेशन परत से संवाद करते हैं, उन्हें भी अपग्रेड रोल आउट करने में सक्षम होना चाहिए।
-
बड़े पैमाने पर VM बनाना और ऑर्केस्ट्रेट करना। एक अकेला k8s क्लस्टर लगभग कुछ हज़ार पॉड के लिए ऑर्केस्ट्रेशन का समर्थन करता है, जो एप्लिकेशन सेवा क्लस्टरों के लिए पर्याप्त है। पर उन परिदृश्यों के लिए यह काफी नहीं है जहाँ हर सेशन को एक claude code पॉड शुरू करने की ज़रूरत होती है।
-
k8s समाधानों का उपयोग k8s द्वारा लाई गई विलंबता का सामना करता है, जिससे 1 सेकंड के भीतर प्रदर्शन हासिल करना मुश्किल हो जाता है।
-
e2b समाधानों का उपयोग करने के लिए पर्सिस्टेंस खुद करनी पड़ती है, और फ़ाइलें अपलोड करना / डाउनलोड करना दोनों बहुत धीमे हैं।
-
e2b समाधान विशिष्ट नेटवर्क एनवायरनमेंट आवश्यकताओं को पूरा नहीं कर सकता, और निजी तैनाती बोझिल है।
हम इन समस्याओं को कैसे हल करें? आइए इतिहास से सीखें। जब कैलेंडर एक दशक से ज़्यादा पीछे, 2012 में मुड़ता है, तब दुनिया में कोई serverless नहीं था, कोई k8s नहीं, और कोई docker नहीं। बैकएंड इंजीनियरों को एक सेवा चलाने के लिए एक भौतिक मशीन पर एक सेवा प्रक्रिया मैन्युअल रूप से बनाए रखनी पड़ती थी। उस समय, ssh और ansible सर्वर इंजीनियरों के लिए मानक उपकरण थे। सेवा प्रक्रियाएँ भौतिक मशीन पर विभिन्न टूल एनवायरनमेंट पर बहुत निर्भर थीं। भौतिक मशीनों में एक जैसे टूल एनवायरनमेंट कॉन्फ़िगरेशन हासिल करना बहुत चुनौतीपूर्ण था, और बड़े पैमाने पर स्केलिंग एक बड़ा काम था जिसके लिए टीमों को बहुत पहले से तैयारी करनी पड़ती थी। मुझे अब भी याद है जब एक इंजीनियर ने एक मशीन का एनवायरनमेंट बदला और उसे दूसरी मशीनों के एनवायरनमेंट से सिंक करना भूल गया, जिससे प्रोडक्शन में एक बहुत मुश्किल से सुलझने वाला भूतिया बग पैदा हो गया। वह दौर एक बहुत दर्दनाक पुराना समय था।
2012 में, docker सामने आया। Docker ने सभी टूल एनवायरनमेंट को एक ही इमेज में पैक कर दिया, एनवायरनमेंट असंगति की समस्या हल कर दी। समुदाय ने धीरे-धीरे महसूस किया कि एक भौतिक मशीन पर एक वर्चुअल मशीन में चलने वाली एक सेवा प्रक्रिया को भौतिक मशीन पर एक प्रक्रिया की तरह प्रबंधित किया जा सकता है। पर docker ऑर्केस्ट्रेशन को अब भी इंजीनियरिंग टीमों से एक ऑर्केस्ट्रेशन सिस्टम बनवाने की ज़रूरत थी। और एक बार जब docker के अंदर की सेवा प्रक्रिया भौतिक मशीन के नेटवर्क और फ़ाइल सिस्टम से जुड़ गई, तो ऑर्केस्ट्रेशन एक बहुत दर्दनाक चीज़ बन जाती।
2014 में, stateless सेवाएँ मुख्यधारा का रुझान बनने लगीं। उस साल Kubernetes और AWS Lambda का जन्म हुआ। उन्होंने अलग-अलग कोणों से stateless सेवाओं के भविष्य का वर्णन किया। Stateless सेवाओं का मतलब था कि सेवा तर्क नेटवर्क पतों से जुड़ाव से बचता था और अब स्थानीय रूप से पर्सिस्टेंट फ़ाइल सिस्टम पर निर्भर नहीं रहता था।
फिर आए cloud native के 10 साल, stateless सेवाओं की लहर ने cloud native इन्फ्रास्ट्रक्चर का एक बड़ा जत्था पैदा किया, जैसे:
- सेवा गेटवे Istio/Linkerd/Envoy/Treafik
- CI/CD प्लेटफ़ॉर्म Argo CD / Flux
- ऑब्ज़र्वेबिलिटी प्लेटफ़ॉर्म Prometheus/Grafana/ELK Stack
- कॉल चेन विश्लेषण Jaeger/Zipkin/OpenTelemetry
- स्टोरेज Rook/MinIO/JuiceFS
और हम अब एक नई शुरुआत पर हैं। दस साल पहले, एक कंप्यूट यूनिट एक java/python api सेवा प्रक्रिया थी। इस साल से, यह कंप्यूट यूनिट एक coding agent बन गई है।
ACFS भौतिक मशीनों पर सेवा प्रक्रियाओं को मैन्युअल रूप से बनाए रखने के दौर जैसा है। E2B, Docker जैसा है। टास्क ऑर्केस्ट्रेशन प्लेटफ़ॉर्म, ऑब्ज़र्वेबिलिटी प्लेटफ़ॉर्म, और वितरित स्टेट पर्सिस्टेंस स्टोरेज क्षमताओं के बिना, coding agents के लिए स्केलेबिलिटी अब भी एक कठिन चीज़ है। और जिस Serverless Agent Infra की मैं उम्मीद करता हूँ उसमें ये क्षमताएँ हैं:
- coding agent के सेशन और वर्किंग डायरेक्टरी को कॉन्टेक्स्ट खोए बिना उचित रूप से पर्सिस्ट करने में सक्षम।
- बेहद तेज़, 100ms के भीतर एक coding agent को काम पर लगाने में सक्षम।
- Agent व्यवहार के लिए ऐसा Logging / Metric / Tracing जो इंसानों के लिए समझना आसान हो, जिससे इंसानों के लिए Agent व्यवहार पैटर्न समझना और समायोजित करना आसान हो जाए।
- डेवलपर्स को अब वर्चुअल मशीन, कंटेनर, और अन्य ops विवरणों जैसी बातों की परवाह करने की ज़रूरत नहीं, जिससे बड़े पैमाने पर ऑर्केस्ट्रेशन बहुत आसान हो जाता है।
मुझे लगता है कि ये क्षमताएँ पूरी कर सकने वाला सारा इन्फ्रास्ट्रक्चर पहले से तैयार है, उदाहरण के लिए firecracker ने microVMs के प्रदर्शन और स्थिरता को प्रमाणित किया है, और वितरित ऑब्ज़र्वेबिलिटी प्लेटफ़ॉर्म और फ़ाइल स्टोरेज सिस्टम के लिए भी कई विकल्प हैं। पर एक ऐसे डेवलपर के रूप में जिसने claude code को इनकैप्सुलेट करने के लिए e2b का उपयोग करने का अनुभव लिया है, इन सबको एक साथ जोड़ना अब भी बहुत मुश्किल है। उदाहरण के लिए, जब E2B में claude code OOM से अप्रत्याशित रूप से बाधित होता है, तो इंजीनियरों के लिए इसकी निगरानी करना मुश्किल है, और उस समय का दृश्य और लॉग पाना तो और भी कठिन।
मुझे उम्मीद है कि 2026 के बाद के डेवलपर्स को ऐसी दर्दनाक प्रक्रिया से नहीं गुज़रना पड़ेगा, ठीक वैसे ही जैसे 2026 में ज़्यादातर इंजीनियरों को भौतिक मशीनों को मैन्युअल रूप से इनिशियलाइज़ करने के लिए अब ssh का उपयोग नहीं करना पड़ता।
यह VM0 का सपना है। मुझे उम्मीद है कि एक दिन मैं एक एर्गोनॉमिक API के ज़रिए एक coding agent चला सकूँगा, जैसे:
cosnt agent = vm0.run({
framework: 'claude-code',
prompt: 'buy me a coffee'
})
