Microsoft Teams डेवलपर्स को चेतावनी दी जा रही है कि हर एक्सटेंशन को "bot" कहना अब प्रोडक्शन-ग्रेड विफलताओं (production-grade failures) का कारण बन रहा है। 2026 में, प्लेटफॉर्म की अपनी सीमाएं—एक संदेश का उत्तर देने के लिए 10 से 15 सेकंड—गलत तरीके से आर्किटेक्ट किए गए bots को 'timeout storms' में बदल देंगी, जिससे टीमों को अपने पाइपलाइनों को फिर से डिजाइन करने के लिए मजबूर होना पड़ेगा।

यह अंतर क्यों महत्वपूर्ण है

Teams तीन प्रकार के एक्सटेंशन प्रदान करता है, जिनमें से प्रत्येक को अलग-अलग इंटरैक्शन पैटर्न के लिए बनाया गया है। उन्हें मिलाने से गलत रनटाइम, गलत SDK और गलत स्केलिंग मॉडल का उपयोग करने की मजबूरी पैदा होती है।

Teams apps, bots, और agents – वे क्या हैं

  • Teams apps – Teams क्लाइंट के भीतर सरफेस टैब (surface tabs), स्टैटिक पेज, या सरल UI कंपोनेंट्स। ये अनिवार्य रूप से वेब ऐप्स हैं: स्टेटलेस (stateless), मांग पर रेंडर होने वाले, और किसी भी अन्य HTTP सर्विस की तरह होस्ट किए गए। इनमें किसी संवादात्मक प्रवाह (conversational flow) की अपेक्षा नहीं की जाती है।
  • Bots – Bot Framework SDK के साथ बनाए गए, bots स्क्रिप्टेड डायलॉग्स का पालन करते हैं। उनका लॉजिक एक नियतात्मक (deterministic) if/else ट्री है जो पूरी तरह से आने वाली एक्टिविटी के आधार पर अगले जवाब का निर्णय लेता है। चूंकि निर्णय का रास्ता पहले से ज्ञात होता है, इसलिए प्रतिक्रिया प्लेटफॉर्म की छोटी टाइमआउट विंडो के भीतर फिट हो जाती है।
  • Agents – लक्ष्य-संचालित संस्थाएं (goal-driven entities) जो एक उच्च-स्तरीय उद्देश्य, टूल का एक सेट और एक LLM (large language model) प्राप्त करती हैं। Agents SDK या Semantic Kernel का उपयोग करते हुए, LLM यह चुनता है कि किस टूल को कब और किस क्रम में कॉल करना है, और उपयोगकर्ता से स्पष्टीकरण कब मांगना है। यह प्रवाह गतिशील (dynamic) होता है, जिसमें अक्सर कई बाहरी कॉल और भारी तर्क (reasoning) की आवश्यकता होती है।

यह अंतर स्पष्ट है: एक bot नियतात्मक (deterministic) है; एक agent संभाव्य (probabilistic) है और रनटाइम पर टूल कॉल को ऑर्केस्ट्रेट करता है।

टाइमआउट का जाल (The timeout trap)

जब डेवलपर्स भारी तर्क (heavy reasoning)—जैसे LLM प्रॉम्प्ट, डेटाबेस लुकअप, या बाहरी API कॉल—को सीधे किसी bot के मैसेज हैंडलर के अंदर एम्बेड करते हैं, तो Teams देखता है कि अनुरोध उसकी 10-15 सेकंड की विंडो से आगे बढ़ गया है। प्लेटफॉर्म प्रतिक्रिया को रद्द कर देता है और उसे फिर से प्रयास (retry) करता है, जो डुप्लिकेट काम और थ्रॉटलिंग (throttling) में बदल सकता है। लक्षण एक रुक-रुक कर होने वाली "bot not responding" त्रुटि जैसा दिखता है, लेकिन इसका मूल कारण आर्किटेक्चरल है।

प्रोडक्शन-रेडी async पाइपलाइन बनाना

  1. Webhook entry point – बॉट का HTTP एंडपॉइंट Teams एक्टिविटी को स्वीकार करता है और तुरंत प्राप्ति की पुष्टि (acknowledges receipt) करता है।
  2. Queue the event – हैंडलर पेलोड को Azure Service Bus जैसे ड्यूरेबल क्यू (durable queue) में भेज देता है।
  3. Background worker – एक Azure Durable Function, Service Bus trigger, या कोई भी लॉन्ग-रनिंग वर्कर मैसेज को खींचता है, LLM रीजनिंग या टूल ऑर्केस्ट्रेशन चलाता है, और Bot Framework के प्रोएक्टिव मैसेजिंग API के माध्यम से Teams को अंतिम उत्तर वापस भेजता है।

चूंकि प्रारंभिक वेबहुक तुरंत वापस आ जाता है, इसलिए Teams कभी भी अपने टाइमआउट तक नहीं पहुँचता है, और भारी काम अपनी गति से चलता रहता है। क्यू (queue) स्पाइक्स को बफर करती है, और वर्कर्स बैकलॉग की लंबाई के आधार पर ऑटो-स्केल होते हैं।

त्वरित निर्णय गाइड (the whiteboard test)

  • क्या आप कोई भी कोड लिखने से पहले पूरा डिसीजन ट्री (decision tree) बना सकते हैं? हाँ → एक bot बनाएं। नियतात्मक प्रवाह Bot Framework मॉडल में फिट बैठता है और रिस्पॉन्स विंडो के भीतर रहता है।
  • क्या समस्या एक उच्च-स्तरीय लक्ष्य और संभावित टूल की सूची द्वारा परिभाषित है? हाँ → एक agent बनाएं। LLM को योजना बनाने और टूल को इनवोक करने दें; प्लानिंग का काम बैकग्राउंड वर्कर को सौंप दें।

आगे क्या देखें

यह मार्गदर्शन Azure पर इंटेलिजेंट Teams समाधान बनाने वाले .NET 9 डेवलपर्स के लिए एक श्रृंखला का पहला भाग है।

यदि आप पहले से ही Teams लॉग में "Bot timed out" त्रुटियां देख रहे हैं, तो समाधान सरल है: वेबहुक को भारी कार्यों (heavy lift) से अलग करें, एक क्यू-संचालित वर्कर (queue-driven worker) अपनाएं, और शुरुआत से ही सही एक्सटेंशन प्रकार चुनें। प्लेटफॉर्म की एक टाइमआउट सीमा है, लेकिन आपका आर्किटेक्चर इससे बच सकता है।

Takeaway: Teams एक्सटेंशन को गलत तरीके से bot के रूप में लेबल करना एक सिंक्रोनस डिज़ाइन को मजबूर करता है जिसे Teams बनाए नहीं रख सकता। अनुरोध को तर्क (reasoning) से अलग करें, सही SDK चुनें, और आपका Teams समाधान तब भी रिस्पॉन्सिव बना रहेगा जब इसके पीछे का दिमाग एक LLM-संचालित agent होगा।