Microsoft Teams ડેવલપર્સને ચેતવણી આપવામાં આવી રહી છે કે દરેક એક્સ્ટેંશનને "bot" કહેવાથી હવે પ્રોડક્શન-ગ્રેડની નિષ્ફળતાઓ (failures) થઈ શકે છે. 2026 માં પ્લેટફોર્મની પોતાની મર્યાદાઓ—મેસેજનો જવાબ આપવા માટે 10 થી 15 સેકન્ડ—ખોટી રીતે આર્કિટેક્ટ કરેલા બોટ્સને 'timeout storms' માં ફેરવી દેશે, જેના કારણે ટીમોએ તેમના પાઇપલાઇન્સને ફરીથી ડિઝાઇન કરવા પડશે.

આ તફાવત શા માટે મહત્વનો છે

Teams ત્રણ પ્રકારના એક્સ્ટેંશન ઓફર કરે છે, જે દરેક અલગ ઇન્ટરેક્શન પેટર્ન માટે બનાવવામાં આવ્યા છે. તેમને મિક્સ કરવાથી ખોટું runtime, ખોટું SDK અને ખોટું scaling model લાગુ પડે છે.

Teams apps, bots, અને agents – તેઓ શું છે

  • Teams apps – Teams ક્લાયન્ટની અંદર સપાટી પરના ટેબ્સ (Surface tabs), સ્ટેટિક પેજ અથવા સાદા UI ઘટકો. તેઓ મૂળભૂત રીતે વેબ એપ્સ છે: stateless, જરૂરિયાત મુજબ રેન્ડર થાય છે, અને અન્ય કોઈપણ HTTP સર્વિસની જેમ હોસ્ટ કરવામાં આવે છે. તેમાં કોઈ વાતચીતનો પ્રવાહ (conversational flow) અપેક્ષિત નથી.
  • Bots – Bot Framework SDK સાથે બનાવેલા બોટ્સ, સ્ક્રિપ્ટેડ ડાયલોગ્સ અનુસરે છે. તેમનું લોજિક એક deterministic if/else ટ્રી છે જે ફક્ત આવતી એક્ટિવિટીના આધારે આગલા જવાબનો નિર્ણય લે છે. કારણ કે નિર્ણય લેવાનો માર્ગ અગાઉથી જાણીતો હોય છે, તેથી પ્રતિસાદ પ્લેટફોર્મના ટૂંકા timeout વિન્ડોમાં સમાઈ જાય છે.
  • Agents – લક્ષ્ય-સંચાલિત એન્ટિટીઝ જે ઉચ્ચ-સ્તરનું ઉદ્દેશ્ય, સાધનોનો સમૂહ અને LLM (large language model) મેળવે છે. Agents SDK અથવા Semantic Kernel નો ઉપયોગ કરીને, LLM નક્કી કરે છે કે કયા સાધનને કયા ક્રમમાં બોલાવવું અને વપરાશકર્તા પાસેથી સ્પષ્ટતા ક્યારે માંગવી. આ પ્રવાહ ડાયનેમિક હોય છે, જેમાં ઘણીવાર મલ્ટિપલ એક્સટર્નલ કોલ્સ અને ભારે રીઝનિંગની જરૂર પડે છે.

આ તફાવત સ્પષ્ટ છે: બોટ deterministic છે; એજન્ટ probabilistic છે અને runtime પર tool calls ને સંચાલિત (orchestrate) કરે છે.

Timeout નો ફાંસો

જ્યારે ડેવલપર્સ બોટના મેસેજ હેન્ડલરની અંદર સીધું જ ભારે રીઝનિંગ—LLM prompts, ડેટાબેઝ લુકઅપ અથવા એક્સટર્નલ API કોલ્સ—જોડે છે, ત્યારે Teams જોશે કે વિનંતી તેના 10-15 સેકન્ડના વિન્ડો કરતા વધુ સમય લઈ રહી છે. પ્લેટફોર્મ પ્રતિસાદ રદ કરે છે અને ફરીથી પ્રયાસ કરે છે, જે ડુપ્લીકેટ કામ અને throttling માં પરિણમી શકે છે. આના લક્ષણો વચ્ચે-વચ્ચે આવતી “bot not responding” ભૂલ જેવા લાગે છે, પરંતુ તેનું મૂળ કારણ આર્કિટેક્ચરલ છે.

Production-ready async પાઇપલાઇન બનાવવી

  1. Webhook entry point – બોટનું HTTP endpoint Teams એક્ટિવિટી સ્વીકારે છે અને તરત જ તેની પ્રાપ્તિની જાણ કરે છે.
  2. Queue the event – હેન્ડલર પેલોડને Azure Service Bus જેવી ટકાઉ (durable) ક્યુમાં મોકલે છે.
  3. Background worker – Azure Durable Function, Service Bus trigger, અથવા કોઈપણ લાંબા સમય સુધી ચાલતું worker મેસેજ ખેંચે છે, LLM રીઝનિંગ અથવા tool orchestration ચલાવે છે, અને Bot Framework ના proactive messaging API દ્વારા Teams પર અંતિમ જવાબ પોસ્ટ કરે છે.

કારણ કે પ્રારંભિક webhook તરત જ રિટર્ન કરે છે, Teams ક્યારેય તેના timeout પર પહોંચતું નથી, અને ભારે કામ તેના પોતાના ગતિએ આગળ વધે છે. ક્યુ (queue) સ્પાઇક્સને બફર કરે છે, અને વર્કર્સ બેકલોગની લંબાઈના આધારે auto-scale થાય છે.

ઝડપી નિર્ણય માર્ગદર્શિકા (the whiteboard test)

  • શું તમે કોઈપણ કોડ લખતા પહેલા આખું decision tree દોરી શકો છો? હા → બોટ બનાવો. Deterministic પ્રવાહ Bot Framework મોડેલ સાથે સુસંગત છે અને પ્રતિસાદ વિન્ડોની અંદર રહે છે.
  • શું સમસ્યા ઉચ્ચ-સ્તરના લક્ષ્ય અને સંભવિત સાધનોની યાદી દ્વારા વ્યાખ્યાયિત છે? હા → એજન્ટ બનાવો. LLM ને પ્લાન કરવા અને સાધનોને બોલાવવા દો; પ્લાનિંગને background worker પર સોંપી દો.

આગળ શું જોવું

આ માર્ગદર્શન Azure પર ઇન્ટેલિજન્ટ Teams સોલ્યુશન્સ બનાવતા .NET 9 ડેવલપર્સ માટેની શ્રેણીનો પ્રથમ ભાગ છે.

જો તમે Teams લોગ્સમાં પહેલેથી જ “Bot timed out” ભૂલો જોઈ રહ્યા હોવ, તો તેનો ઉકેલ સરળ છે: webhook ને ભારે કામથી અલગ કરો (decouple), queue-driven worker અપનાવો, અને શરૂઆતથી જ સાચો એક્સ્ટેંશન પ્રકાર પસંદ કરો. પ્લેટફોર્મની timeout મર્યાદા છે, પરંતુ તમારું આર્કિટેક્ચર તેને ટાળી શકે છે.

Takeaway: Teams એક્સ્ટેંશનને બોટ તરીકે ખોટી રીતે લેબલ કરવાથી સિંક્રનસ ડિઝાઇન (synchronous design) નો આગ્રહ રાખવો પડે છે જે Teams ટકી શકતું નથી. વિનંતીને રીઝનિંગથી અલગ કરો, સાચું SDK પસંદ કરો, અને તમારું Teams સોલ્યુશન પ્રતિભાવશીલ રહેશે, ભલે તેની પાછળનું મગજ LLM-સંચાલિત એજન્ટ હોય.