Microsoft Teams ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਚੇਤਾਵਨੀ ਦਿੱਤੀ ਜਾ ਰਹੀ ਹੈ ਕਿ ਹਰ ਐਕਸਟੈਂਸ਼ਨ ਨੂੰ “bot” ਕਹਿਣਾ ਹੁਣ production-grade ਅਸਫਲਤਾਵਾਂ ਦਾ ਕਾਰਨ ਬਣ ਰਿਹਾ ਹੈ। 2026 ਵਿੱਚ, ਪਲੇਟਫਾਰਮ ਦੀਆਂ ਆਪਣੀਆਂ ਸੀਮਾਵਾਂ—ਮੈਸੇਜ ਦਾ ਜਵਾਬ ਦੇਣ ਲਈ 10 ਤੋਂ 15 ਸੈਕਿੰਡ—ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਤਿਆਰ ਕੀਤੇ ਗਏ bots ਨੂੰ timeout storms ਵਿੱਚ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ, ਜਿਸ ਨਾਲ ਟੀਮਾਂ ਨੂੰ ਆਪਣੇ pipelines ਨੂੰ ਮੁੜ ਡਿਜ਼ਾਈਨ ਕਰਨ ਲਈ ਮਜਬੂਰ ਹੋਣਾ ਪੈਂਦਾ ਹੈ।

ਇਹ ਅੰਤਰ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ

Teams ਤਿੰਨ ਤਰ੍ਹਾਂ ਦੀਆਂ extension ਕਿਸਮਾਂ ਪੇਸ਼ ਕਰਦਾ ਹੈ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਵੱਖਰੇ interaction pattern ਲਈ ਬਣਾਈ ਗਈ ਹੈ। ਇਨ੍ਹਾਂ ਨੂੰ ਮਿਲਾਉਣ ਨਾਲ ਗਲਤ runtime, ਗਲਤ SDK, ਅਤੇ ਗਲਤ scaling model ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਮਜਬੂਰ ਹੋਣਾ ਪੈਂਦਾ ਹੈ।

Teams apps, bots, ਅਤੇ agents – ਉਹ ਕੀ ਹਨ

  • Teams apps – Teams client ਦੇ ਅੰਦਰ Surface tabs, static pages, ਜਾਂ ਸਧਾਰਨ UI components। ਇਹ ਅਸਲ ਵਿੱਚ web apps ਹਨ: stateless, on demand render ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਕਿਸੇ ਵੀ ਹੋਰ HTTP service ਵਾਂਗ host ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਇਨ੍ਹਾਂ ਤੋਂ ਕਿਸੇ conversational flow ਦੀ ਉਮੀਦ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ।
  • Bots – Bot Framework SDK ਨਾਲ ਬਣਾਏ ਗਏ, bots scripted dialogs ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ। ਇਨ੍ਹਾਂ ਦਾ logic ਇੱਕ deterministic if/else tree ਹੁੰਦਾ ਹੈ ਜੋ ਸਿਰਫ਼ ਆਉਣ ਵਾਲੀ activity ਦੇ ਅਧਾਰ 'ਤੇ ਅਗਲੇ ਜਵਾਬ ਦਾ ਫੈਸਲਾ ਕਰਦਾ ਹੈ। ਕਿਉਂਕਿ ਫੈਸਲੇ ਦਾ ਰਸਤਾ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਜਾਣਿਆ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਜਵਾਬ ਪਲੇਟਫਾਰਮ ਦੇ ਛੋਟੇ timeout window ਦੇ ਅੰਦਰ ਹੀ ਆ ਜਾਂਦਾ ਹੈ।
  • Agents – Goal-driven ਇਕਾਈਆਂ ਜੋ ਇੱਕ ਉੱਚ-ਪੱਧਰੀ ਉਦੇਸ਼, ਸਾਧਨਾਂ (tools) ਦਾ ਇੱਕ ਸਮੂਹ, ਅਤੇ ਇੱਕ LLM (large language model) ਪ੍ਰਾਪਤ ਕਰਦੀਆਂ ਹਨ। Agents SDK ਜਾਂ Semantic Kernel ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, LLM ਚੁਣਦਾ ਹੈ ਕਿ ਕਿਸ tool ਨੂੰ ਕਦੋਂ ਅਤੇ ਕਿਸ ਕ੍ਰਮ ਵਿੱਚ ਕਾਲ ਕਰਨਾ ਹੈ, ਅਤੇ ਉਪਭੋਗਤਾ ਤੋਂ ਸਪਸ਼ਟੀਕਰਨ ਕਦੋਂ ਮੰਗਣਾ ਹੈ। ਇਹ flow dynamic ਹੁੰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਅਕਸਰ ਕਈ ਬਾਹਰੀ calls ਅਤੇ ਭਾਰੀ reasoning ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਇਹ ਵੱਖਰੇਵਾਂ ਬਹੁਤ ਸਪਸ਼ਟ ਹੈ: ਇੱਕ bot deterministic ਹੁੰਦਾ ਹੈ; ਇੱਕ agent probabilistic ਹੁੰਦਾ ਹੈ ਅਤੇ runtime 'ਤੇ tool calls ਨੂੰ ਸੰਗਠਿਤ (orchestrate) ਕਰਦਾ ਹੈ।

Timeout ਦਾ ਜਾਲ

ਜਦੋਂ ਡਿਵੈਲਪਰ ਭਾਰੀ reasoning—LLM prompts, database lookups, ਜਾਂ external API calls—ਸਿੱਧੇ ਤੌਰ 'ਤੇ bot ਦੇ message handler ਦੇ ਅੰਦਰ ਜੋੜਦੇ ਹਨ, ਤਾਂ Teams ਅਨੁਭਵ ਕਰਦਾ ਹੈ ਕਿ ਬੇਨਤੀ (request) ਉਸਦੇ 10-15 ਸੈਕਿੰਡ ਦੇ window ਤੋਂ ਬਾਹਰ ਜਾ ਰਹੀ ਹੈ। ਪਲੇਟਫਾਰਮ ਜਵਾਬ ਨੂੰ ਰੋਕ ਦਿੰਦਾ ਹੈ ਅਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਜੋ ਕਿ ਦੁਬਾਰਾ ਕੰਮ (duplicate work) ਅਤੇ throttling ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਹੈ। ਇਸਦਾ ਲੱਛਣ ਕਦੇ-ਕਦੇ ਇੱਕ ਰੁਕ-ਰੁਕ ਕੇ ਆਉਣ ਵਾਲੀ “bot not responding” error ਵਾਂਗ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਪਰ ਇਸਦਾ ਮੂਲ ਕਾਰਨ architectural ਹੁੰਦਾ ਹੈ।

Production-ready async pipeline ਬਣਾਉਣਾ

  1. Webhook entry point – Bot ਦਾ HTTP endpoint Teams activity ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਅਤੇ ਤੁਰੰਤ ਪ੍ਰਾਪਤੀ ਦੀ ਪੁਸ਼ਟੀ (acknowledge) ਕਰਦਾ ਹੈ।
  2. Queue the event – Handler payload ਨੂੰ Azure Service Bus ਵਰਗੀ ਇੱਕ durable queue ਵਿੱਚ ਪਾ ਦਿੰਦਾ ਹੈ।
  3. Background worker – ਇੱਕ Azure Durable Function, Service Bus trigger, ਜਾਂ ਕੋਈ ਵੀ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਚੱਲਣ ਵਾਲਾ worker ਮੈਸੇਜ ਨੂੰ ਕੱਢਦਾ ਹੈ, LLM reasoning ਜਾਂ tool orchestration ਚਲਾਉਂਦਾ ਹੈ, ਅਤੇ Bot Framework ਦੇ proactive messaging API ਰਾਹੀਂ Teams ਨੂੰ ਅੰਤਿਮ ਜਵਾਬ ਵਾਪਸ ਭੇਜਦਾ ਹੈ।

ਕਿਉਂਕਿ ਸ਼ੁਰੂਆਤੀ webhook ਤੁਰੰਤ ਵਾਪਸ ਆਉਂਦਾ ਹੈ, Teams ਕਦੇ ਵੀ ਆਪਣੇ timeout ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦਾ, ਅਤੇ ਭਾਰੀ ਕੰਮ ਆਪਣੇ ਆਪ ਦੀ ਰਫ਼ਤਾਰ ਨਾਲ ਚੱਲਦਾ ਰਹਿੰਦਾ ਹੈ। Queue ਉਤਸਾਹ (spikes) ਨੂੰ ਬਫਰ ਕਰਦੀ ਹੈ, ਅਤੇ workers backlog ਦੀ ਲੰਬਾਈ ਦੇ ਅਧਾਰ 'ਤੇ auto-scale ਹੁੰਦੇ ਹਨ।

ਤੇਜ਼ ਫੈਸਲਾ ਲੈਣ ਲਈ ਗਾਈਡ (whiteboard test)

  • ਕੀ ਤੁਸੀਂ ਕੋਈ ਵੀ ਕੋਡ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਪੂਰਾ decision tree ਬਣਾ ਸਕਦੇ ਹੋ? ਹਾਂ → ਇੱਕ bot ਬਣਾਓ। Deterministic flow Bot Framework ਮਾਡਲ ਦੇ ਅਨੁਕੂਲ ਹੁੰਦਾ ਹੈ ਅਤੇ response window ਦੇ ਅੰਦਰ ਰਹਿੰਦਾ ਹੈ।
  • ਕੀ ਸਮੱਸਿਆ ਇੱਕ ਉੱਚ-ਪੱਧਰੀ ਉਦੇਸ਼ ਅਤੇ ਸੰਭਵ tools ਦੀ ਇੱਕ ਸੂਚੀ ਦੁਆਰਾ ਪਰਿਭਾਸ਼ਿਤ ਹੈ? ਹਾਂ → ਇੱਕ agent ਬਣਾਓ। LLM ਨੂੰ plan ਕਰਨ ਅਤੇ tools ਨੂੰ ਕਾਲ ਕਰਨ ਦਿਓ; planning ਦਾ ਕੰਮ background worker ਨੂੰ ਸੌਂਪ ਦਿਓ।

ਅੱਗੇ ਕੀ ਦੇਖਣਾ ਹੈ

ਇਹ ਮਾਰਗਦਰਸ਼ਨ Azure 'ਤੇ intelligent Teams solutions ਬਣਾਉਣ ਵਾਲੇ .NET 9 ਡਿਵੈਲਪਰਾਂ ਲਈ ਇੱਕ ਲੜੀ ਦਾ ਪਹਿਲਾ ਹਿੱਸਾ ਹੈ।

ਜੇਕਰ ਤੁਸੀਂ Teams logs ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ “Bot timed out” errors ਦੇਖ ਰਹੇ ਹੋ, ਤਾਂ ਇਸਦਾ ਹੱਲ ਸਧਾਰਨ ਹੈ: webhook ਨੂੰ ਭਾਰੀ ਕੰਮ ਤੋਂ ਵੱਖ ਕਰੋ, ਇੱਕ queue-driven worker ਅਪਣਾਓ, ਅਤੇ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਸਹੀ extension type ਚੁਣੋ। ਪਲੇਟਫਾਰਮ ਦੀ ਇੱਕ timeout limit ਹੈ, ਪਰ ਤੁਹਾਡਾ architecture ਇਸ ਤੋਂ ਬਚ ਸਕਦਾ ਹੈ।

Takeaway: Teams extension ਨੂੰ bot ਵਜੋਂ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਲੇਬਲ ਕਰਨਾ ਇੱਕ synchronous design ਨੂੰ ਮਜਬੂਰ ਕਰਦਾ ਹੈ ਜਿਸ ਨੂੰ Teams ਸਹਿਣ ਨਹੀਂ ਕਰ ਸਕਦਾ। Request ਨੂੰ reasoning ਤੋਂ ਵੱਖ ਕਰੋ, ਸਹੀ SDK ਚੁਣੋ, ਅਤੇ ਤੁਹਾਡਾ Teams solution ਉਦੋਂ ਵੀ responsive ਰਹੇਗਾ ਜਦੋਂ ਇਸਦੇ ਪਿੱਛੇ ਦਾ ਦਿਮਾਗ ਇੱਕ LLM-powered agent ਹੋਵੇਗਾ।