Microsoft Teams developers are being warned that calling every extension a “bot” now causes production-grade failures. In 2026 the platform’s own limits—10 to 15 seconds to answer a message—turn mis-architected bots into timeout storms, forcing teams to redesign their pipelines.

Why the distinction matters

Teams offers three extension types, each built for a different interaction pattern. Mixing them forces the wrong runtime, the wrong SDK, and the wrong scaling model.

Teams apps, bots, and agents – what they are

  • Teams apps – Surface tabs, static pages, or simple UI components inside the Teams client. They are essentially web apps: stateless, rendered on demand, and hosted like any other HTTP service. No conversational flow is expected.
  • Bots – Built with the Bot Framework SDK, bots follow scripted dialogs. Their logic is a deterministic if/else tree that decides the next reply based purely on the incoming activity. Because the decision path is known in advance, the response fits within the platform’s short timeout window.
  • Agents – Goal-driven entities that receive a high-level objective, a set of tools, and an LLM (large language model). Using the Agents SDK or Semantic Kernel, the LLM chooses which tool to call, in what order, and when to ask the user for clarification. The flow is dynamic, often requiring multiple external calls and heavy reasoning.

The split is stark: a bot is deterministic; an agent is probabilistic and orchestrates tool calls at runtime.

The timeout trap

When developers embed heavy reasoning—LLM prompts, database lookups, or external API calls—directly inside a bot’s message handler, Teams sees the request linger past its 10-15-second window. The platform aborts the response and retries, which can cascade into duplicate work and throttling. The symptom looks like an intermittent “bot not responding” error, but the root cause is architectural.

Building a production-ready async pipeline

  1. Webhook entry point – The bot’s HTTP endpoint accepts the Teams activity and immediately acknowledges receipt.
  2. Queue the event – The handler pushes the payload to a durable queue such as Azure Service Bus.
  3. Background worker – An Azure Durable Function, Service Bus trigger, or any long-running worker pulls the message, runs the LLM reasoning or tool orchestration, and posts the final reply back to Teams through the Bot Framework’s proactive messaging API.

Because the initial webhook returns instantly, Teams never hits its timeout, and the heavy work proceeds at its own pace. The queue buffers spikes, and workers auto-scale based on backlog length.

Quick decision guide (the whiteboard test)

  • Can you draw the entire decision tree before you write any code? Yes → Build a bot. Deterministic flow fits the Bot Framework model and stays within the response window.
  • Is the problem defined by a high-level goal and a list of possible tools? Yes → Build an agent. Let the LLM plan and invoke tools; offload the planning to a background worker.

What to watch next

The guidance is the first installment of a series for .NET 9 developers building intelligent Teams solutions on Azure.

If you’re already seeing “Bot timed out” errors in Teams logs, the fix is simple: decouple the webhook from the heavy lift, adopt a queue-driven worker, and choose the correct extension type from the start. The platform has a timeout limit, but your architecture can avoid it.

Takeaway: Mislabeling a Teams extension as a bot forces a synchronous design that Teams cannot sustain. Separate the request from the reasoning, pick the right SDK, and your Teams solution will stay responsive even when the brain behind it is an LLM-powered agent.