Redis ने Iris का विस्तार करते हुए एजेंट रूटिंग, निगरानी और मैसेजिंग जोड़ी

Redis ने 4 नवंबर, 2026 को घोषणा की कि उसका Iris रीयल-टाइम कॉन्टेक्स्ट इंजन अब AI एजेंटों के लिए छह संयोज्य क्षमताएँ देता है, जिनमें से चार आम तौर पर उपलब्ध हैं और दो बीटा में हैं। इस विस्तार से ऐसे उत्पाद में अनुरोध रूटिंग, दोबारा इस्तेमाल की जा सकने वाली प्रक्रियाएँ, निगरानी और भरोसेमंद मैसेजिंग जुड़ती हैं, जिसका केंद्र पहले कॉन्टेक्स्ट और मेमोरी था।

ग्राहक इन क्षमताओं का इस्तेमाल एक साथ, अलग-अलग या एक ही रनटाइम में किसी भी संयोजन में कर सकते हैं। Rowan Trollope का तर्क है कि एजेंटों को मेमोरी, प्रासंगिक कॉन्टेक्स्ट, लाइव डेटा तक पहुँच, रूटिंग और संचार देने के लिए डेवलपर्स को अलग-अलग इंफ्रास्ट्रक्चर उत्पाद जोड़ने की ज़रूरत नहीं होनी चाहिए। Redis की शुरुआत करने की पेशकश में 5,000 मुफ़्त संदेश शामिल हैं।

Redis के सॉफ़्टवेयर इंजीनियरिंग निदेशक Simba Khadder की एक पूरक तकनीकी गहन विवेचना उन उत्पादन-संबंधी समस्याओं का वर्णन करती है, जिनका समाधान इस डिज़ाइन से करना है: एजेंटों का पिछला इतिहास जाने बिना काम शुरू करना, उपयोगी प्राथमिकताएँ भूलते हुए संवेदनशील विवरण याद रखना, अधूरी जानकारी के साथ काम करना और उन अनुरोधों के लिए बार-बार कॉन्टेक्स्ट तैयार करना जिन्हें वे पहले ही संभाल चुके हैं। ये विफलता-स्थितियाँ इस रिलीज़ की अलग-अलग सुविधाओं को निरंतरता, पुनः उपयोग और नियंत्रण के साझा उद्देश्य से जोड़ती हैं।

चार क्षमताएँ आम तौर पर उपलब्ध

Intent Router किसी अनुरोध को उसके सटीक शब्दों के बजाय उसके अर्थ के आधार पर पहचानता है, फिर उसे याद रखे गए FAQ, एजेंट कौशल, किसी व्यक्ति या LLM तक भेजता है। यह एजेंट और मॉडल रूटिंग, सुरक्षा-नियंत्रण तथा अस्पष्टता सहने वाले सशर्त निर्णयों का भी समर्थन करता है। इससे एक ही अनुरोध के अलग-अलग ढंग से लिखे गए रूपों को एक ही मूल समस्या मानकर संभाला जा सकता है।

Agent Playbooks उन स्थिर उत्तरों को अलग करता है जिनका दोबारा इस्तेमाल किया जा सकता है, उन अनुरोधों से जिनके लिए मौजूदा डेटा और पहले से ज्ञात प्रक्रिया को नए सिरे से चलाना ज़रूरी है। Redis के अनुसार, बार-बार इस्तेमाल से प्लेबुक अधिक विस्तृत और सटीक होते जाते हैं, जिससे समस्या सुलझाने में लगने वाला समय और टोकन खर्च घटता है। इस तरह Playbooks, Intent Router का पुनः उपयोग वाला पूरक बनता है: एक अनुरोध का प्रकार पहचानता है, जबकि दूसरा तय करता है कि कोई मौजूदा उत्तर या प्रक्रिया उसे पूरा कर सकती है या नहीं।

Agent Memory, MemoryETL का इस्तेमाल करके उपयोगकर्ता की गतिविधियों, दस्तावेज़ों, नॉलेज बेस और अन्य अर्ध-संरचित डेटा से मेमोरी तैयार करता है। यह अधिक सूक्ष्म नियंत्रण के लिए उन मेमोरी को पदानुक्रम में व्यवस्थित करता है और निरीक्षण, ऑडिट तथा स्रोत-इतिहास की सुविधाएँ देता है, ताकि टीमें देख सकें कि हर मेमोरी कहाँ से आई। यह ऐसी जानकारी को भी हटा सकता है जिसे इसे अपने पास नहीं रखना चाहिए, जिसमें व्यक्तिगत पहचान योग्य जानकारी भी शामिल है।

Context Gateway, जुड़े हुए कॉन्टेक्स्ट स्रोतों तक पहुँचने के लिए एक ही नियंत्रित प्रवेश-बिंदु देता है। ग्राहक अपने MCP सर्वर जोड़ सकते हैं, यह कैश कर सकते हैं कि कौन-से टूल खास समस्याएँ हल करते हैं, और अलग-अलग सत्रों में एकरूपता बनाए रखने के लिए दोबारा इस्तेमाल किए जा सकने वाले नतीजे तैयार कर सकते हैं। Redis टूल कैशिंग को टोकन का इस्तेमाल घटाने का तरीका बताता है। इससे बार-बार मॉडल से काम कराने से बचने पर इस रिलीज़ का ज़ोर, उत्तरों और प्रक्रियाओं से आगे बढ़कर डेटा तक पहुँचने तक पहुँचता है।

बीटा टूल ऑडिट और कनेक्शन विफलताओं से निपटते हैं

Lens किसी एजेंट के नतीजे का पता लगाकर बताता है कि उसे किस कौशल, रूट या FAQ ने पूरा किया, कौन-सी मेमोरी इस्तेमाल हुई और मूल सत्र कौन-सा था। यह प्रति कार्य सफलता, प्रति कार्य टोकन और विलंबता भी दिखाता है, जिससे ऑडिट ट्रेल के साथ परिचालन मापदंड भी मिलते हैं। इसका उद्देश्य यह है कि जब टीमों को गलत उत्तर का कारण पता करना हो, टोकन खपत की जाँच करनी हो या यह जानना हो कि कोई कार्रवाई क्यों हुई, तो वे एजेंट के व्यवहार के बारे में प्रश्न पूछकर जानकारी हासिल कर सकें।

Agent Mesh संचार में आने वाली रुकावटों से निपटता है। एजेंट अस्थायी स्ट्रीम के ज़रिए संवाद करते हैं; कनेक्शन टूटने पर डेटा अपने-आप बफ़र होता है और कनेक्शन फिर से जुड़ जाता है। टिकाऊ SSE Streams को इस तरह बनाया गया है कि रुकावटों के दौरान भी जवाब आते रहें, जबकि A2A Comms एजेंटों के बीच कार्य सौंपने और हस्तांतरण के लिए एक चैनल देता है। इस तरह Lens और Mesh उत्पादन के अलग-अलग जोखिमों को संभालते हैं: किसी निर्णय की प्रक्रिया का पता लगाना और बातचीत को जारी रखना।

मई में शुरुआत से लेकर ग्राहकों के इस्तेमाल तक

Redis ने 18 मई, 2026 को Iris पेश किया, जिसे एजेंट और उसके लिए ज़रूरी डेटा के बीच कॉन्टेक्स्ट और मेमोरी की परत के रूप में बनाया गया था। उस शुरुआती पेशकश में Context Retriever, Agent Memory, Redis Data Integration, LangCache और Redis Search शामिल थे; Context Retriever और Agent Memory पूर्वावलोकन में थे। इसके बाद Agent Memory आम तौर पर उपलब्ध हो गया है, जबकि नई सुविधाएँ मूल डेटा पुनर्प्राप्ति और मेमोरी पर केंद्रित पेशकश को रूटिंग, बार-बार चलाई जा सकने वाली प्रक्रियाओं, निर्णयों का पता लगाने और स्ट्रीम बहाल करने तक विस्तृत करती हैं।

Safe in Home के वरिष्ठ सॉफ़्टवेयर डेवलपर Nick Thompson ने Redis Iris के उत्पाद पृष्ठ पर एक ठोस तैनाती का वर्णन किया: “Redis Agent Memory हमारे कोडिंग एजेंटों के बीच कॉन्टेक्स्ट को रीयल टाइम में सहेजने और दोबारा इस्तेमाल करने में हमारी मदद करता है।” उनकी टीम इंजीनियरिंग संबंधी निर्णयों, बग के विवरण और विकास के कॉन्टेक्स्ट को एजेंटों के काम के दौरान दर्ज करने के लिए इसका इस्तेमाल करती है, ताकि यह जानकारी सत्रों या टूल के बीच खोने के बजाय पूरी टीम के लिए उपलब्ध रहे। एक सेवा कंपनी के API की निगरानी करते हुए उस मेमोरी से जानकारी पढ़ती और उसमें लिखती भी है, फिर रीयल टाइम में कंपनी के टिकटिंग सिस्टम में बग रिपोर्ट दर्ज करती है।

इस तरह यह रिलीज़ Iris की भूमिका को केवल कॉन्टेक्स्ट देने से आगे बढ़ाकर यह समन्वय करने तक विस्तृत करती है कि एजेंट किसी अनुरोध को कैसे संभाले, पहले किए गए काम का दोबारा उपयोग कैसे करे, चुनी हुई जानकारी कैसे याद रखे और नियंत्रित डेटा तक कैसे पहुँचे। हालाँकि, इसकी अलग-अलग क्षमताएँ परिपक्वता के अलग-अलग चरणों में हैं: परिचालन की ये बुनियादी सुविधाएँ आम तौर पर उपलब्ध हैं, जबकि निर्णयों के ऑडिट और कनेक्शन बहाल करने वाली परतें अभी बीटा में हैं।