Stop Picking AI Frameworks Before You Answer This One Question
If you're building AI agents on Azure, you've been here: a kickoff meeting where someone asks "what framework should we use?" and the next 90 minutes becomes a debate between Semantic Kernel, AutoGen, Copilot Studio, Foundry, and Logic Apps — before anyone has agreed on what the agent actually needs to do.
That is the wrong sequence. And it's why so many Azure AI projects start with the most sophisticated-sounding option and spend the next three months fighting the wrong abstraction.
The Microsoft ecosystem gives you more agent architecture flexibility than any other cloud provider. Conversational or headless. Low-code or pro-code. M365-native or Azure-native. That flexibility is a genuine advantage — but only if you read the decision tree in the right order.
This post walks through that tree. By the end you'll have a repeatable framework for choosing the right architecture the first time, plus a list of SDK retirement dates you need to know before you commit.
The Platform Landscape First
Before the decision tree, it helps to understand the three tiers Microsoft gives you:
┌─────────────────────────────────────────────────────────────────┐
│ Microsoft Agent Platform Tiers │
│ │
│ ┌───────────────────┐ ┌──────────────────┐ ┌──────────────┐ │
│ │ Copilot Studio │ │ Copilot Studio │ │ Microsoft │ │
│ │ Lite │ │ (Pro Makers) │ │ Foundry │ │
│ │ │ │ │ │ │ │
│ │ M365 scenarios │ │ More actions, │ │ Pro devs, │ │
│ │ Low complexity │ │ channels, │ │ custom code, │ │
│ │ No-code │ │ orchestration │ │ full control │ │
│ └───────────────────┘ └──────────────────┘ └──────────────┘ │
│ Simple ◄─────────────────────────────────► Advanced │
└─────────────────────────────────────────────────────────────────┘
These aren't competing products. They're a spectrum. The question is which tier fits your team's constraints, not which one is "best."
The One Question That Drives Everything
Before frameworks, before data layers, before deployment — the single most important decision is:
What is the interaction pattern?
There are exactly three answers:
┌─────────────────────┐
│ What is the │
│ interaction pattern? │
└──────────┬──────────┘
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
┌─────────────┐ ┌─────────────────┐ ┌──────────────┐
│ Chat / UI │ │ Autonomous / │ │ Headless / │
│ (User │ │ Event-Driven │ │ API │
│ talks to │ │ (Runs in the │ │ (Systems │
│ the agent) │ │ background) │ │ call it) │
└─────────────┘ └─────────────────┘ └──────────────┘
This fork determines nearly every downstream decision. Teams that skip it and jump straight to framework selection spend months fighting the wrong abstraction. Teams that start here make better choices in minutes.
Path 1: Chat / UI-Based Agents
If a human will talk directly to the agent, follow this branch.
Step 1: Where does the user live?
Is the experience entirely within Microsoft 365?
│
├── YES → M365 Copilot
│ Best fit when users already work in the Microsoft
│ ecosystem and you want strong user-in-the-loop
│ experience without a custom application layer.
│
└── NO → Does it need Teams or multi-channel support?
│
├── YES (need speed) → Copilot Studio
│ Best for business workflows,
│ fast time-to-production,
│ avoiding a full engineering sprint.
│
└── YES (need control) → Pro-code path ↓
Step 2: The pro-code fork
When you need a conversational UI with full engineering control, one more decision determines the right SDK:
Is this M365-centric?
│
├── YES → M365 Agents SDK
│ Deepest integration with Teams, Outlook, SharePoint.
│ Handles auth, channel routing, and M365 data access
│ without custom plumbing.
│
└── NO → Azure-centric path
│
Do you need a custom, interactive frontend
(streaming, shared state, embedded web/app UI)?
│
├── YES → Agent Framework + AG-UI
│ AG-UI is an emerging protocol that gives
│ agents a standard way to talk to modern
│ frontends. Critical when your agent is
│ embedded in a React app, not just a chat
│ window.
│
└── NO → Microsoft Foundry
Cleanest Azure-first path when you
don't need the custom UI protocol layer.
The summary for UI-based agents comes down to four questions:
- Is this conversational? (Yes — you're on this path)
- Where does the user interact? (M365, Teams, or custom?)
- Low-code or pro-code?
4. M365-first or Azure-first?
Path 2: Autonomous / Event-Driven Agents
These agents run in the background. They react to triggers. They process information and take action with minimal or no direct user interaction. The architecture here follows the workflow, not the chat UI.
Autonomous Agent Decision Tree:
│
├── Want low-code? → Copilot Studio with Event Triggers
│ Good starting point for business-user-built
│ automation with Power Automate triggers.
│
├── Need custom UI protocol? → Agent Framework + AG-UI
│ Same AG-UI story as the chat path —
│ richer app experiences with
│ streaming and state.
│
├── Azure-centric + enterprise controls? → Microsoft Foundry
│ Deep governance,
│ model routing, tracing,
│ and evaluation built in.
│
└── Heavy enterprise system integration?
(SAP, ServiceNow, Salesforce, etc.)
→ Logic Apps AI Agent Workflows
Logic Apps gives agents access to 1,400+ enterprise connectors.
When integration is the core problem — not model selection —
the connector story matters more than the model story.
These workflows can now be exposed as MCP tools for
standardized agent access.
Key insight for this path: Autonomous agents aren't chatbots with the chat stripped out. They are workflow systems. The architecture choice should follow the workflow shape, the trigger sources, and the integration surface — not the sophistication of the model you want to run.
This matters especially for enterprise workflows where the agent's job is to call SAP, read from ServiceNow, and write back to Salesforce. The agent framework is almost irrelevant compared to the integration layer.
Path 3: Headless / API Services
No chat window. No copilot interface. The agent exposes a backend service that other systems call. The main variable here is hosting requirements:
Headless Agent Hosting:
│
├── Managed platform service → Azure Container Apps
│ Best default — handles scaling,
│ secrets, and networking without
│ managing Kubernetes directly.
│
├── Local / Edge deployment → Azure IoT Edge / Container Apps
│ For agents that need to run
│ close to data or offline.
│
└── Full self-hosting control → AKS
When you need full orchestration
control, custom networking, or
multi-agent mesh configurations.
This branch is less about user experience and more about runtime shape. When the agent is infrastructure — called by other services, not by users — the deployment target and SLA requirements drive the decision.
The Data Layer: Don't Treat It as an Implementation Detail
Here is where most Azure AI projects underinvest. The quality of your agent's responses will depend far more on the retrieval layer than on the model you choose.
Does the agent need custom data?
│
├── Microsoft 365 data (emails, docs, SharePoint)
│ → Graph Connectors + M365 data layer
│
├── Unstructured documents at scale
│ → Azure AI Search (Agentic RAG)
│ Semantic ranking, hybrid search (dense + sparse),
│ integrated chunking and vectorization.
│ Critical when your knowledge base is PDFs, contracts,
│ or policy documents.
│
├── Vector search on structured/semi-structured data
│ → Choose based on existing infrastructure:
│ • Cosmos DB (NoSQL + vector)
│ • PostgreSQL with pgvector
│ • Azure SQL with vector support
│ • Fabric SQL (if analytics context needed)
│
└── Analytics context (dashboards, metrics, BI data)
→ Microsoft Fabric
When the agent needs to reason over business intelligence
or time-series data alongside documents.
A practical rule: if the agent answers questions by retrieving information, the retrieval architecture is the most important design decision you'll make. The model is a commodity; how you feed it isn't.
Deployment: Where Does the Agent Need to Live?
After interaction model, build approach, and data layer, the final decision is where users or systems reach the agent:
| Target Audience | Deployment Path |
|---|---|
| M365 users in Copilot | M365 Copilot channel |
| Teams users | Teams channel |
| Web or mobile users | Web/mobile channel |
| Multiple surfaces | Multi-channel SDK route |
| Other Azure services / APIs | Azure Container Apps, App Service, or AKS |
And once you've decided: don't skip monitoring. Observability, governance, and cost visibility need to be part of the design from day one, not retrofitted after the first production incident.
The Retirement Dates You Must Know Before You Commit
This section belongs in every Azure AI architecture conversation right now. Three SDKs have announced or confirmed retirement dates within current planning horizons:
| SDK / Service | Retirement Date | Successor |
|---|---|---|
| Bot Framework | December 31, 2025 | M365 Agents SDK |
| azure-ai-inference SDK | May 30, 2026 | openai SDK |
| Assistants API | August 26, 2026 | Foundry Agent Service / Responses API |
If any of these are in your current stack or your evaluation shortlist, start the migration now.
The cost of discovering a retirement date mid-project — after you've trained your team on the SDK, written documentation, and built integrations — is always higher than starting on the right platform. This is especially true for teams with multi-quarter planning cycles.
The Bot Framework retirement is already past as of this writing. If you're still on it, the M365 Agents SDK migration is not optional.
The Short Version (Put This on Your Whiteboard)
STEP 1: What is the interaction pattern?
Chat UI → go to Step 2
Autonomous → go to Step 3
Headless → go to Step 4
STEP 2: Chat UI path
M365 only? → M365 Copilot
Low-code + multi-channel? → Copilot Studio
Pro-code + M365-first? → M365 Agents SDK
Pro-code + custom UI? → Agent Framework + AG-UI
Pro-code + Azure-first? → Foundry
STEP 3: Autonomous path
Low-code → Copilot Studio + Event Triggers
Enterprise integrations → Logic Apps AI Agent Workflows
Custom UI protocol → Agent Framework + AG-UI
Azure-first + governance → Foundry
STEP 4: Headless path
Managed → Container Apps
Edge → IoT Edge / Container Apps
Full control → AKS
Then: Choose your data layer based on data type.
Then: Choose your deployment channel based on who/what calls the agent.
Then: Wire in monitoring and governance before you ship.
Check retirement dates. Start on the right platform.
Key Takeaways
- The single most important decision in Azure AI agent architecture is the interaction pattern (Chat/UI, Autonomous, Headless). Every other choice flows from it — framework debates before this question is answered are premature.
- Low-code (Copilot Studio) is a strategic choice, not a compromise. If your users already live in Teams and M365, it often gets you to production faster than a custom pro-code solution with equivalent results.
- The data layer determines agent quality more than the model tier. Choosing Azure AI Search, pgvector, Cosmos DB, or Fabric depends on the shape of your data — decide this early.
- Three SDKs have confirmed retirement dates within 2026 planning horizons: Bot Framework (retired Dec 2025), azure-ai-inference SDK (May 2026), and Assistants API (Aug 2026). Audit your stack now.
- Logic Apps AI Agent Workflows with 1,400+ enterprise connectors is the right path when the core problem is integration, not model selection. The connector story matters more than the model story in those scenarios.
The Question Worth Sitting With
Every team I've seen debate Azure AI frameworks starts with "which one is most powerful?" The right question is "which one fits the shape of what we're actually building?"
If you've been through an Azure AI architecture decision recently — what forced the framework choice? Was it the interaction model, the data layer, team skill, time pressure, or something else entirely?
Drop it in the comments. Hearing what drove real decisions is more useful than any decision tree.
Top comments (0)