Microsoft Teams डेव्हलपर्सना असा इशारा दिला जात आहे की प्रत्येक एक्स्टेंशनला “बॉट” (bot) म्हणणे आता प्रॉडक्शन-ग्रेड फेल्युअरला (production-grade failures) कारणीभूत ठरत आहे. २०२६ मध्ये प्लॅटफॉर्मच्या स्वतःच्या मर्यादा—मेसेजला उत्तर देण्यासाठी १० ते १५ सेकंद—चुकीच्या पद्धतीने डिझाइन केलेल्या बॉट्सना 'टाइमआउट स्टॉर्म्स'मध्ये (timeout storms) रूपांतरित करतील, ज्यामुळे टीम्सना त्यांचे पाइपलाइन्स पुन्हा डिझाइन करण्यास भाग पाडले जाईल.
हा फरक का महत्त्वाचा आहे
Teams तीन प्रकारचे एक्स्टेंशन प्रकार प्रदान करते, जे प्रत्येक वेगवेगळ्या इंटरअॅक्शन पॅटर्नसाठी बनवलेले आहेत. ते एकमेकांत मिसळल्यास चुकीचा रनटाइम, चुकीचे SDK आणि चुकीचे स्केलिंग मॉडेल वापरले जाण्याची शक्यता असते.
Teams apps, bots, आणि agents – ते काय आहेत
- Teams apps – Teams क्लायंटमधील सरफेस टॅब्स (Surface tabs), स्टॅटिक पेजेस किंवा साधे UI घटक. ते प्रामुख्याने वेब ॲप्स आहेत: स्टेटलेस (stateless), मागणीनुसार रेंडर केलेले आणि इतर कोणत्याही HTTP सर्व्हिसप्रमाणे होस्ट केलेले. यामध्ये संवादात्मक प्रवाहाची (conversational flow) अपेक्षा केली जात नाही.
- Bots – Bot Framework SDK वापरून तयार केलेले बॉट्स, स्क्रिप्टेड संवाद (scripted dialogs) फॉलो करतात. त्यांचे लॉजिक हे एक डिटरमिनिस्टिक (deterministic) if/else ट्री असते, जे केवळ येणाऱ्या ॲक्टिव्हिटीच्या आधारे पुढचे उत्तर ठरवते. निर्णय घेण्याचा मार्ग (decision path) आधीच माहित असल्यामुळे, प्रतिसाद प्लॅटफॉर्मच्या कमी टाइमआउट विंडोमध्ये बसतो.
- Agents – ध्येय-चालित (Goal-driven) घटक जे उच्च-स्तरीय उद्दिष्ट, साधनांचा संच (set of tools) आणि एक LLM (large language model) प्राप्त करतात. Agents SDK किंवा Semantic Kernel वापरून, LLM कोणते साधन कधी आणि कोणत्या क्रमाने कॉल करायचे आणि वापरकर्त्याला स्पष्टीकरण विचारण्यासाठी कधी संपर्क साधायचा हे ठरवते. हा प्रवाह डायनॅमिक असतो, ज्यामध्ये अनेकदा अनेक बाह्य कॉल्स आणि जड तर्कशुद्ध प्रक्रिया (heavy reasoning) आवश्यक असतात.
हा फरक स्पष्ट आहे: बॉट हा डिटरमिनिस्टिक असतो; एजंट हा प्रोबॅबिलिस्टिक (probabilistic) असतो आणि रनटाइममध्ये टूल कॉल्सचे नियोजन (orchestrates) करतो.
टाइमआउटचा सापळा
जेव्हा डेव्हलपर्स जड तर्कशुद्ध प्रक्रिया—LLM प्रॉम्प्ट्स, डेटाबेस लूकअप्स किंवा बाह्य API कॉल्स—थेट बॉटच्या मेसेज हँडलरमध्ये एम्बेड करतात, तेव्हा Teams ला वाटते की विनंती त्याच्या १०-१५ सेकंदांच्या विंडोच्या पलीकडे जात आहे. प्लॅटफॉर्म प्रतिसाद रद्द करतो आणि पुन्हा प्रयत्न करतो, ज्यामुळे कामाची पुनरावृत्ती आणि थ्रॉटलिंग (throttling) होऊ शकते. याचे लक्षण अधूनमधून येणारी “bot not responding” अशी त्रुटी दिसते, परंतु त्याचे मूळ कारण आर्किटेक्चरल असते.
प्रॉडक्शन-रेडी असिंक (async) पाइपलाइन तयार करणे
- Webhook entry point – बॉटचा HTTP एंडपॉइंट Teams ॲक्टिव्हिटी स्वीकारतो आणि त्वरित पोचपावती (acknowledgment) देतो.
- Queue the event – हँडलर पेलोड Azure Service Bus सारख्या टिकाऊ क्यू (durable queue) मध्ये पाठवतो.
- Background worker – Azure Durable Function, Service Bus trigger किंवा कोणताही दीर्घकाळ चालणारा वर्कर मेसेज घेतो, LLM तर्कशुद्ध प्रक्रिया किंवा टूल ऑर्केस्ट्रेशन चालवतो आणि Bot Framework च्या प्रोअॅक्टिव्ह मेसेजिंग API द्वारे Teams ला अंतिम प्रतिसाद पाठवतो.
कारण सुरुवातीचा वेबहुक त्वरित प्रतिसाद देतो, Teams कधीही त्याच्या टाइमआउट मर्यादेपर्यंत पोहोचत नाही आणि जड काम स्वतःच्या गतीने सुरू राहते. क्यू (Queue) अचानक वाढलेला लोड (spikes) हाताळते आणि वर्कर्स बॅकलॉगच्या लांबीनुसार ऑटो-स्केल होतात.
त्वरित निर्णय मार्गदर्शक (व्हाईटबोर्ड टेस्ट)
- तुम्ही कोणताही कोड लिहिण्यापूर्वी संपूर्ण डिसीजन ट्री (decision tree) काढू शकता का? हो → बॉट तयार करा. डिटरमिनिस्टिक प्रवाह Bot Framework मॉडेलमध्ये बसतो आणि प्रतिसादाच्या विंडोमध्ये राहतो.
- समस्या उच्च-स्तरीय उद्दिष्ट आणि संभाव्य साधनांच्या सूचीने परिभाषित केली आहे का? हो → एजंट तयार करा. LLM ला नियोजन करू द्या आणि साधने वापरू द्या; नियोजनाचे काम बॅकग्राउंड वर्करकडे सोपवा.
पुढील काय पाहावे
हे मार्गदर्शन Azure वर इंटेलिजेंट Teams सोल्यूशन्स तयार करणाऱ्या .NET 9 डेव्हलपर्ससाठीच्या मालिकेतील पहिले भाग आहे.
जर तुम्हाला आधीच Teams लॉग्समध्ये “Bot timed out” त्रुटी दिसत असतील, तर उपाय सोपा आहे: वेबहुकला जड कामापासून वेगळे करा (decouple), क्यू-ड्रिव्हन वर्करचा अवलंब करा आणि सुरुवातीपासूनच योग्य एक्स्टेंशन प्रकार निवडा. प्लॅटफॉर्मची टाइमआउट मर्यादा आहे, परंतु तुमचे आर्किटेक्चर ते टाळू शकते.
महत्त्वाचा मुद्दा (Takeaway): Teams एक्स्टेंशनला बॉट म्हणून चुकीच्या पद्धतीने लेबल केल्यामुळे सिंक्रोनस डिझाइनला भाग पडते जे Teams टिकवू शकत नाही. विनंतीला (request) तर्कशुद्ध प्रक्रियेपासून (reasoning) वेगळे करा, योग्य SDK निवडा आणि तुमचे Teams सोल्यूशन प्रतिसादक्षम राहील, जरी त्यामागील मेंदू LLM-पॉवर्ड एजंट असला तरीही.