Microsoft Bot Framework
Type: full-code · Vendor: Microsoft · Language: C#, JavaScript, TypeScript, Python, Java · License: MIT · Status: deprecated · Status in practice: deprecated · First released: 2016-03-30 · Successor: ms-365-agents-sdk
Microsoft's pre-LLM SDK for building turn-based conversational bots in C#/JS/Python/Java with dialog stacks, channel adapters, scoped state, and a documented handoff-to-human protocol; archived on GitHub with support ending December 2025.
Description. Microsoft Bot Framework SDK v4 is a modular SDK and set of services (Azure Bot Service, Bot Connector) for building bots that converse across channels (Teams, Slack, Telegram, Facebook, web chat, SMS via Twilio, and others). Bots are activity-driven (each user message is a turn), use the Dialog library (component, waterfall, prompt, adaptive dialogs) to manage multi-turn flows, persist state in three scopes (user / conversation / private-conversation) over Memory / Azure Blob / Cosmos storage, and support a standardised handoff protocol with `handoff.initiate` and `handoff.status` events. The SDK and Bot Framework Emulator have been archived; Microsoft recommends migrating to the Microsoft 365 Agents SDK.
Agent loop shape. Activity-driven turn loop: the Bot Connector relays an activity from a channel to the bot, the bot's turn handler reads/writes state through state property accessors, the active Dialog on the dialog stack continues from where it left off (multi-turn persistence via dialog state), the bot replies, and state is saved. There is no LLM agent loop in the SDK itself — the bot is imperative; LUIS/QnA Maker provide NLU.
Primary use cases
- multi-channel enterprise chatbots (Teams, Slack, Facebook Messenger, web chat, SMS)
- dialog-stack-driven multi-turn conversation flows with waterfall and prompts
- QnA Maker / Custom Question Answering knowledge bots
- bot-as-proxy or bot-as-agent handoff to human-agent platforms
Key concepts
- Activity / Turn (docs) — A bot processes activities one turn at a time; conversation state must be re-read each turn.
- Dialogs → plan-and-execute (docs) — Container, component, waterfall, prompt, adaptive, skill, and QnA Maker dialogs manage multi-turn flows via a dialog stack.
- State buckets (user / conversation / private-conversation) → session-isolation (docs) — Three scoped state buckets persisted via state property accessors over Memory / Blob / Cosmos.
- Channels / Bot Connector (docs) — Connect a single bot to Teams, Slack, Facebook, Telegram, SMS, web chat with a normalised activity stream.
- Handoff protocol → conversation-handoff (docs) — Standard `handoff.initiate` and `handoff.status` events for bot-to-human escalation; bot-as-agent and bot-as-proxy integration models.
Patterns this full-code implements —
- ★★Conversation Handoff to Human
Standardised handoff protocol with `handoff.initiate` and `handoff.status` events, plus two named integration models (bot-as-agent and bot-as-proxy) and a Handoff Library sample.
- ★★Session Isolation
Three predefined scoped state buckets (user / conversation / private-conversation), each keyed by channel-id plus user/conversation id.
- ★★Fallback Chain
Bot Framework Orchestrator and orchestration workflow are documented intent-only recognition engines used to determine which LUIS model or QnA Maker knowledge base can best handle a given message; Qn…
- ★★Plan-and-Execute
Dialog stack is the SDK's explicit multi-turn plan; component dialogs encapsulate sub-plans, waterfall dialogs sequence steps, prompt dialogs gather inputs.
- ★★Cross-Session Memory
User state is keyed by channel-id+from-id and persists across conversations; can be backed by Azure Blob or Cosmos partitioned storage.
- ★★Tool Use
Bots can call APIs and external services from turn-handler code, but the SDK predates LLM tool-calling — no native tool-call primitive. Custom logic patterns suggest calling all relevant services per…