Microsoft AI Agent Decision Tree

Where will end users interact with this agent? This determines which platforms are viable.

Inside M365 Copilot
Teams, Word, Excel, Outlook, Copilot Chat — users stay in their flow of work Teams only
A chatbot or agent experience within Microsoft Teams, not across all M365 apps External / customer-facing
Website widget, mobile app, WhatsApp, Facebook, Dynamics 365 Omnichannel Multi-channel
Must work across M365, external sites, mobile, and potentially third-party platforms Backend / API / pipeline
No end-user UI — agent is triggered by events, APIs, or other agents

More customisation means more control — but also more build effort, more governance responsibility, and higher operational cost.

None — out-of-box Copilot
Summarise meetings, draft emails, analyse spreadsheets — no building required Knowledge + instructions
Scope Copilot to specific SharePoint sites, add custom instructions and persona Knowledge + actions
Agent needs to call APIs, trigger Power Automate flows, or read/write external data Custom engine inside M365
Need your own LLM, custom orchestration, or advanced API integrations — but still surface natively in Copilot / Teams Custom orchestration / LLM
Need specific model selection, custom reasoning chains, or non-standard orchestration Multi-agent workflows
Multiple specialised agents coordinating — sequential, concurrent, handoff, or group chat patterns Fine-tuning / MLOps
Custom model training, evaluation pipelines, model versioning, A/B testing

Governance is architecture, not process overhead. The OWASP Top 10 for Agentic AI (December 2025) established the baseline — agent goal hijack, identity abuse, and rogue agents are the primary risks.

Inherit M365 compliance
Microsoft Purview, Responsible AI guardrails, and data boundary enforcement inherited automatically Power Platform DLP
Connector-level DLP policies, environment security roles, CoE Starter Kit monitoring Azure enterprise controls
Full RBAC, virtual network isolation, bring-your-own-key encryption, Azure Policy integration Full code control
Custom identity management, bespoke audit logging, code-level security controls, own compliance framework

The Cloud Adoption Framework identifies three legitimate reasons for multi-agent: security/compliance boundaries, specialist team ownership, or a roadmap spanning 3-5+ distinct functions. If none applies, a single well-scoped agent with 3–7 tools outperforms multi-agent in simplicity, latency, and cost.

Single agent
One well-scoped agent with focused knowledge and 3–7 tools covers the use case Multi-agent — security boundaries
Different data classification levels need separate processing environments or regulation requires separation of duties Multi-agent — team ownership
Finance, Sales Ops, Procurement each own their domain; independent agents map to ownership boundaries Multi-agent — broad roadmap
A monolithic agent would become unmaintainable; separate agents enable independent modernisation

How will the agent connect to data and services? MCP enables standardised, reusable tool integration across agents. Scope each agent to 3–7 tools maximum — an agent with 40 tools struggles with routing accuracy.

Microsoft Graph only
SharePoint, OneDrive, Exchange, Teams — all data lives within M365 and is accessible via Graph Power Platform connectors
SAP, Salesforce, ServiceNow, Dynamics 365, SQL Server — standard connectors with DLP governance MCP servers
Standardised tool protocol — build once, reuse across agents org-wide. Foundry tool catalogue includes 1,400+ MCP tools REST APIs / custom
Existing OpenAPI specs, bespoke API integrations, or proprietary systems requiring custom code A2A protocol
Cross-runtime agent collaboration — your agents coordinate with agents in other frameworks via structured messaging