The Problem With "Teams Bot" as a Catch-All Term
If you've shipped anything inside Microsoft Teams over the last few years, you've probably called it a "bot" regardless of what it actually does. That label is starting to break down. In 2026, a Teams extension can be a static app, a scripted conversational bot, or an autonomous agent that plans, calls tools, and takes action. Treating all three the same way in your architecture diagrams is exactly how projects end up with the wrong infrastructure underneath them.
This is Part 1 of a series on building intelligent Teams applications with .NET 9 and Azure. Before touching a line of Bot Framework or Agents SDK code, it's worth being precise about what's actually running inside the Teams client, what's running behind Microsoft Graph, and where Azure AI enters the request path.
Teams Apps vs. Bots vs. Agents
These three terms get used interchangeably in casual conversation, but they map to genuinely different runtime behaviors and engineering commitments.
| Category | What It Does | State Model | Typical Backend |
|---|---|---|---|
| Teams App | Surfaces a tab, static content, or a fixed UI inside Teams | Mostly stateless, page-driven | Web app / SPA hosted behind Azure App Service or Static Web Apps |
| Bot | Responds to messages via scripted dialogs or activity handlers | Turn-based, conversation state per session | Bot Framework SDK or Teams AI Library on Azure App Service |
| Agent | Plans, selects tools, calls external systems, and acts on a goal | Persistent, goal-driven, multi-step orchestration | Microsoft 365 Agents SDK / Semantic Kernel over Azure AI Foundry |
The distinction that matters architecturally is simple: a bot resolves a conversation turn-by-turn using fixed logic, while an agent resolves a goal by deciding, at runtime, which tools to invoke and in what order. If your Teams extension has an if/else tree or a deterministic dialog state machine deciding what to say next, it's a bot. If it's handing the LLM a tool registry and letting it dynamically choose the sequence of Graph calls, database writes, or approval triggers, it's an agent. That difference changes the architecture around it dramatically, including retry limits, tool validation, loop guards, and human-in-the-loop checkpoints.
The Request Path and the Production Fallacy
Every Teams extension, regardless of category, ultimately resolves through the same layered path before it touches your business logic:
- Teams Client: The user interacts with the UI component.
- Microsoft Graph and the Teams Platform: The incoming activity webhook is routed to your registered endpoint.
- Ingress and Orchestration Layer (Azure App Service / Azure Functions): The request is accepted and application logic begins.
- AI Layer (Azure AI Foundry / Azure OpenAI): LLM inference, intent planning, and tool selection are handled here.
- Downstream Dependencies: The workflow reaches your line-of-business APIs, SQL databases, SharePoint, or internal services.
The anti-pattern most teams fall into is putting their reasoning logic directly inside the bot or agent message handler. That works for a local dev tunnel demo. It falls over in production. Teams expects an HTTP 200 OK response within roughly 10–15 seconds to avoid timeout retries, so heavy reasoning loops can break raw endpoints. There is also no durability if your hosting instance restarts mid-task, no clean separation between what the model planned and what actually executed, and no natural place to insert an approval gate.
To survive production, your middle layer should be asynchronous by design. The message handler should accept the webhook, publish the event to a reliable queue such as Azure Service Bus, and let a background worker or an Azure Durable Function perform the actual reasoning loop.
Bot Framework vs. the Microsoft 365 Agents SDK
This is the decision point most teams hit first, and it is worth being deliberate about rather than defaulting to whichever SDK your team used last year.
| Dimension | Bot Framework SDK | Microsoft 365 Agents SDK |
|---|---|---|
| Interaction model | Conversations and dialogs you author explicitly | Intent-driven, the agent plans its own steps |
| Control flow | Manual — you write the branching logic | AI planning — the model decides the path |
| Best fit | Deterministic workflows: FAQ bots, structured forms, ticket routing | Open-ended tasks: research, multi-step approvals, cross-system orchestration |
| Ecosystem | Azure Bot Service and Teams extensibility | Microsoft 365 Copilot ecosystem and agent-native experiences |
Bot Framework is not legacy. It remains the right choice when you need predictable, auditable conversation flows and do not want an LLM improvising the sequence of steps for a regulated process. The Agents SDK earns its complexity when the task genuinely benefits from dynamic planning — especially when the right path depends on what the first tool call returns or what data is available in a live enterprise context.
Where Adaptive Cards and Event-Driven Apps Fit
1. Presentation Decoupling
Adaptive Cards are not a competing architecture decision. They are the cross-platform presentation layer regardless of whether a bot or an agent is driving the interaction. The distinction is in how the card gets populated. A scripted bot renders a card from a fixed template using values it already has. An agent renders a card as the terminal step of a reasoning loop, after it has decided what data is relevant and pulled it from a tool call. Keep card schema generation isolated from your core planning logic.
2. Event-Driven Teams Apps
Not every Teams interaction originates from a user typing a message. In modern cloud architecture, Teams often acts as an operational cockpit. External events — a pull request opened in Azure DevOps, a security anomaly flagged by a monitoring pipeline, or a closed CRM deal — can flow through Azure Event Grid, Service Bus, or Event Hub into an Azure Function that posts proactive updates into a channel or chat. That pattern is increasingly important for enterprise scenarios where Teams is the front door to action, not just conversation.
The .NET 9 Implementation Roadmap
This series moves in a deliberate order, moving from architecture to production-grade implementation:
- Modern Teams Architecture in 2026 (this article)
- Building Teams Bots with .NET 9 and the Teams AI Library
- Microsoft 365 Agents vs. Bot Framework — a deep code-level comparison
- State Management: Distributed caching with Redis vs. Cosmos DB bot state
- Teams + Azure AI Foundry: Implementing Semantic Kernel chat completion
- Securing the Channel: Entra ID, managed identities, and the On-Behalf-Of (OBO) flow
- Event-Driven Proactive Messaging with Azure Service Bus and .NET workers
- Durable Agents: Managing long-running LLM tasks without Teams timeouts
If you're deciding whether your next Teams project needs a bot or an agent, use the whiteboard test: can you draw the full, absolute decision tree before writing code? If yes, build a bot. If the decision tree is really just a high-level goal statement and a bag of tools, you need an agent — and a much more deliberate, asynchronous harness around it.
This is Part 1 of the "Building Intelligent Microsoft Teams Applications with .NET & Azure" series, part of the Emerging Tech & Architecture Series.
Top comments (0)