Microsoft Teams ഡെവലപ്പർമാർക്ക് ഒരു മുന്നറിയിപ്പ്: എല്ലാ എക്സ്റ്റൻഷനുകളെയും “ബോട്ട്” എന്ന് വിളിക്കുന്നത് ഇപ്പോൾ പ്രൊഡക്ഷൻ നിലവാരത്തിലുള്ള പരാജയങ്ങൾക്ക് (production-grade failures) കാരണമാകുന്നു. 2026-ഓടെ പ്ലാറ്റ്ഫോമിന്റെ തന്നെ പരിമിതികൾ—ഒരു സന്ദേശത്തിന് മറുപടി നൽകാൻ 10 മുതൽ 15 സെക്കൻഡ് വരെ മാത്രം—തെറ്റായ രീതിയിൽ രൂപകൽപ്പന ചെയ്ത ബോട്ടുകളെ ടൈമൗട്ട് പ്രശ്നങ്ങളുടെ പ്രളയത്തിലേക്ക് (timeout storms) നയിക്കും, ഇത് ടീമുകളെ അവരുടെ പൈപ്പ്ലൈനുകൾ പുനർരൂപകൽപ്പന ചെയ്യാൻ നിർബന്ധിതരാക്കും.
ഈ വ്യത്യാസം പ്രധാനമാകുന്നത് എന്തുകൊണ്ട്
വ്യത്യസ്തമായ ഇന്ററാക്ഷൻ പാറ്റേണുകൾക്കായി നിർമ്മിച്ച മൂന്ന് തരം എക്സ്റ്റൻഷനുകളാണ് Teams വാഗ്ദാനം ചെയ്യുന്നത്. ഇവ തമ്മിൽ കൂട്ടിക്കലർത്തുന്നത് തെറ്റായ റൺടൈം, തെറ്റായ SDK, തെറ്റായ സ്കെയിലിംഗ് മോഡൽ എന്നിവയ്ക്ക് കാരണമാകും.
Teams apps, bots, and agents – അവ എന്തൊക്കെയാണ്
- Teams apps – Teams ക്ലയന്റിനുള്ളിലെ Surface tabs, സ്റ്റാറ്റിക് പേജുകൾ അല്ലെങ്കിൽ ലളിതമായ UI ഘടകങ്ങൾ. ഇവ അടിസ്ഥാനപരമായി വെബ് ആപ്പുകളാണ്: stateless ആണ്, ആവശ്യാനുസരണം റെൻഡർ ചെയ്യപ്പെടുന്നു, കൂടാതെ മറ്റ് HTTP സർവീസുകളെപ്പോലെ ഹോസ്റ്റ് ചെയ്യപ്പെടുന്നു. ഇവയിൽ നിന്ന് സംഭാഷണ രീതികൾ (conversational flow) പ്രതീക്ഷിക്കപ്പെടുന്നില്ല.
- Bots – Bot Framework SDK ഉപയോഗിച്ച് നിർമ്മിച്ച ബോട്ടുകൾ, സ്ക്രിപ്റ്റ് ചെയ്ത ഡയലോഗുകൾ പിന്തുടരുന്നു. ഇവയുടെ ലോജിക് ഒരു നിശ്ചിത രീതിയിലുള്ള (deterministic) if/else ട്രീ ആണ്, ഇത് വരുന്ന ആക്ടിവിറ്റിയുടെ അടിസ്ഥാനത്തിൽ അടുത്ത മറുപടി തീരുമാനിക്കുന്നു. തീരുമാനങ്ങൾ മുൻകൂട്ടി അറിയാവുന്നത് കൊണ്ട്, മറുപടി പ്ലാറ്റ്ഫോമിന്റെ ചെറിയ ടൈമൗട്ട് വിൻഡോയ്ക്കുള്ളിൽ തന്നെ ലഭിക്കുന്നു.
- Agents – ഒരു ഉയർന്ന ലക്ഷ്യം (high-level objective), ടൂളുകളുടെ ഒരു കൂട്ടം, ഒരു LLM (large language model) എന്നിവ സ്വീകരിക്കുന്ന ലക്ഷ്യധിഷ്ഠിത സംവിധാനങ്ങളാണ് ഏജന്റുകൾ. Agents SDK അല്ലെങ്കിൽ Semantic Kernel ഉപയോഗിച്ച്, ഏത് ടൂൾ ഏത് ക്രമത്തിൽ ഉപയോഗിക്കണം എന്നും ഉപയോക്താവിനോട് എപ്പോൾ കൂടുതൽ വിവരങ്ങൾ ചോദിക്കണം എന്നും LLM തീരുമാനിക്കുന്നു. ഇതിന്റെ പ്രക്രിയ ഡൈനാമിക് ആണ്, പലപ്പോഴും ഒന്നിലധികം എക്സ്റ്റേണൽ കോളുകളും കഠിനമായ റീസണിംഗും (reasoning) ആവശ്യമായി വരാം.
ഇവ തമ്മിലുള്ള വ്യത്യാസം വ്യക്തമാണ്: ഒരു ബോട്ട് നിശ്ചിത രീതിയിൽ പ്രവർത്തിക്കുന്നതാണ് (deterministic); എന്നാൽ ഒരു ഏജന്റ് പ്രോബബിലിസ്റ്റിക് (probabilistic) ആണ്, അത് റൺടൈമിൽ ടൂൾ കോളുകൾ ഏകോപിപ്പിക്കുന്നു.
ടൈമൗട്ട് കെണി (The timeout trap)
ഡെവലപ്പർമാർ കഠിനമായ റീസണിംഗ്—LLM പ്രോംപ്റ്റുകൾ, ഡാറ്റാബേസ് ലുക്കപ്പുകൾ അല്ലെങ്കിൽ എക്സ്റ്റേണൽ API കോളുകൾ—നേരിട്ട് ഒരു ബോട്ടിന്റെ മെസ്സേജ് ഹാൻഡ്ലറினுள் ഉൾപ്പെടുത്തുമ്പോൾ, Teams ആ അഭ്യർത്ഥന അതിന്റെ 10-15 സെക്കൻഡ് വിൻഡോയ്ക്ക് അപ്പുറം നീളുന്നത് കാണുന്നു. പ്ലാറ്റ്ഫോം മറുപടി നൽകുന്നത് നിർത്തി വീണ്ടും ശ്രമിക്കുന്നു (retry), ഇത് ഡ്യൂപ്ലിക്കേറ്റ് ജോലികളിലേക്കും ത്രോട്ട്ലിംഗിലേക്കും (throttling) നയിച്ചേക്കാം. ഇതിന്റെ ലക്ഷണങ്ങൾ ഇടയ്ക്കിടെ ഉണ്ടാകുന്ന “bot not responding” എന്ന എറർ പോലെ തോന്നാമെങ്കിലും, ഇതിന്റെ യഥാർത്ഥ കാരണം ആർക്കിടെക്ചറിലെ പിഴവാണ്.
പ്രൊഡക്ഷൻ റെഡി ആയ ഒരു async പൈപ്പ്ലൈൻ നിർമ്മിക്കുക
- Webhook entry point – ബോട്ടിന്റെ HTTP എൻഡ്പോയിന്റ് Teams ആക്ടിവിറ്റി സ്വീകരിക്കുകയും ഉടൻ തന്നെ അത് ലഭിച്ചുവെന്ന് അറിയിക്കുകയും ചെയ്യുന്നു.
- Queue the event – ഹാൻഡ്ലർ ഈ ഡാറ്റ Azure Service Bus പോലുള്ള ഒരു ഡ്യൂറബിൾ ക്യൂവിലേക്ക് (durable queue) എത്തിക്കുന്നു.
- Background worker – ഒരു Azure Durable Function, Service Bus trigger, അല്ലെങ്കിൽ മറ്റേതെങ്കിലും ലോങ്ങ്-റണ്ണിംഗ് വർക്കർ ഈ സന്ദേശം എടുക്കുകയും, LLM റീസണിംഗോ ടൂൾ ഓർക്കസ്ട്രേഷനോ നടത്തുകയും, തുടർന്ന് Bot Framework-ന്റെ proactive messaging API വഴി അന്തിമ മറുപടി Teams-ലേക്ക് അയക്കുകയും ചെയ്യുന്നു.
ആദ്യത്തെ വെബ്ഹുക്ക് ഉടൻ തന്നെ മറുപടി നൽകുന്നതുകൊണ്ട്, Teams ഒരിക്കലും അതിന്റെ ടൈമൗട്ട് പരിധിയിൽ എത്തില്ല, കഠിനമായ ജോലികൾ അതിന്റെ സ്വാഭാവിക വേഗതയിൽ മുന്നോട്ട് പോകും. ക്യൂ വർക്കുകൾ തമ്മിലുള്ള വ്യത്യാസങ്ങൾ ക്രമീകരിക്കുന്നു, കൂടാതെ ബാക്ക്ലോഗ് അനുസരിച്ച് വർക്കറുകൾ ഓട്ടോ-സ്കെയിൽ ചെയ്യുകയും ചെയ്യുന്നു.
പെട്ടെന്നുള്ള തീരുമാനത്തിനുള്ള മാർഗ്ഗനിർദ്ദേശം (the whiteboard test)
- കോഡ് എഴുതുന്നതിന് മുമ്പ് നിങ്ങൾക്ക് മുഴുവൻ ഡിസിഷൻ ട്രീയും വരയ്ക്കാൻ കഴിയുമോ? അതെ → ഒരു ബോട്ട് നിർമ്മിക്കുക. നിശ്ചിത രീതിയിലുള്ള (deterministic) പ്രക്രിയ Bot Framework മോഡലിന് അനുയോജ്യമാണ് കൂടാതെ മറുപടി നൽകാനുള്ള സമയപരിധിക്കുള്ളിൽ നിൽക്കുകയും ചെയ്യുന്നു.
- ഒരു ഉയർന്ന ലക്ഷ്യവും സാധ്യമായ ടൂളുകളുടെ പട്ടികയും ഉപയോഗിച്ചാണോ പ്രശ്നം നിർവചിച്ചിരിക്കുന്നത്? അതെ → ഒരു ഏജന്റ് നിർമ്മിക്കുക. പ്ലാനിംഗിനായി LLM-നെ അനുവദിക്കുക; ഈ പ്ലാനിംഗ് ജോലികൾ ഒരു ബാക്ക്ഗ്രൗണ്ട് വർക്കറിലേക്ക് മാറ്റുക.
അടുത്തതായി ശ്രദ്ധിക്കേണ്ടത്
Azure-ൽ ഇന്റലിജന്റ് Teams സൊല്യൂഷനുകൾ നിർമ്മിക്കുന്ന .NET 9 ഡെവലപ്പർമാർക്കായുള്ള ഒരു പരമ്പരയിലെ ആദ്യ ഭാഗമാണിത്.
നിങ്ങളുടെ Teams ലോഗുകളിൽ ഇപ്പോൾ തന്നെ “Bot timed out” എററുകൾ കാണുന്നുണ്ടെങ്കിൽ, പരിഹാരം ലളിതമാണ്: വെബ്ഹുക്കിനെ കഠിനമായ ജോലികളിൽ നിന്ന് വേർപെടുത്തുക (decouple), ഒരു ക്യൂ-ഡ്രൈവൻ വർക്കർ ഉപയോഗിക്കുക, തുടക്കം മുതൽ ശരിയായ എക്സ്റ്റൻഷൻ ടൈപ്പ് തിരഞ്ഞെടുക്കുക. പ്ലാറ്റ്ഫോമിന് ഒരു ടൈമൗട്ട് പരിധിയുണ്ട്, എന്നാൽ നിങ്ങളുടെ ആർക്കിടെക്ചർ ഉപയോഗിച്ച് അത് ഒഴിവാക്കാം.
ചുരുക്കത്തിൽ (Takeaway): ഒരു Teams extension-നെ ബോട്ട് എന്ന് തെറ്റായി വിളിക്കുന്നത് Teams-ന് താങ്ങാൻ കഴിയാത്ത ഒരു സിൻക്രണസ് ഡിസൈനിലേക്ക് നയിക്കും. അഭ്യർത്ഥനയെയും റീസണിംഗിനെയും വേർതിരിക്കുക, ശരിയായ SDK തിരഞ്ഞെടുക്കുക, അപ്പോൾ നിങ്ങളുടെ Teams സൊല്യൂഷൻ ഒരു LLM-അധിഷ്ഠിത ഏജന്റാണെങ്കിൽ പോലും കൃത്യമായി പ്രതികരിക്കുന്നതായിരിക്കും.