9.4 Proposing Microsoft 365 Agents for Business Scenarios

Proposing Microsoft 365 Agents for Business Scenarios

Quick Answer: Microsoft 365 Copilot is extended by two structurally different agent types, and proposing the right one is the whole skill. A declarative agent supplies custom instructions, custom knowledge, and custom actions but runs on Copilot's own orchestrator and foundation models, so it inherits Microsoft 365 security, compliance, and responsible-AI standards, requires no additional hosting, and runs inside Microsoft 365 Copilot and apps such as Teams, Word, Excel, and Outlook. A custom engine agent brings its own orchestrator and models, requires additional hosting (typically Azure, at additional cost), can run inside and outside Microsoft 365, supports group collaboration, supports proactive interactions that fire without user input, supports agent-to-agent collaboration — and makes the customer responsible for its own compliance, responsible-AI practices, and security. Alongside both sit Microsoft's first-party agents that arrive with the Copilot licence — Researcher, Analyst, Facilitator, and SharePoint agents — which should be proposed before any custom build. Build tools span low-code (Copilot Studio, the Microsoft 365 Copilot agent builder) and pro-code (Visual Studio / VS Code with the Microsoft 365 Agents Toolkit, the Microsoft 365 Agents SDK).

An architect who proposes a custom engine agent for "an IT helpdesk assistant that answers from our SharePoint policies and files a ServiceNow ticket" has committed the organisation to hosting, scaling, model currency, content-filter tuning, responsible-AI review, and a security posture that Microsoft would otherwise have provided for free. An architect who proposes a declarative agent for "a loan-approval agent with bespoke decision rules, its own fine-tuned model, and proactive escalation to a Teams channel" has proposed something the platform cannot deliver.

Proposing Microsoft 365 agents for business scenarios is a discrete design-domain skill on the AB-100 blueprint, and the exam tests the boundary between the two types far more often than it tests how to build either one.

---

1. Start With What the Licence Already Includes

Before either agent type is proposed, check the first-party catalogue that ships with Microsoft 365 Copilot:

Proposing a custom agent for a scenario these already cover is the most common planning error in this part of the blueprint.

---

2. Agent Core Components

Both agent types are assembled from the same conceptual parts, which is why the choice is about ownership, not capability shape:

• Knowledge — specialised instructions and data sources that tailor the agent's responses.
• Actions — actions, triggers, and workflows that automate business processes.
• Orchestrator — the central engine managing how the agent interacts with knowledge, skills, and autonomy.
• Foundation models — the reasoning, language-understanding, and generation layer.
• User experience layer — how the agent surfaces inside Microsoft 365 apps or external platforms.

A declarative agent lets the customer own knowledge, actions, and instructions while Microsoft owns the orchestrator, models, and experience layer. A custom engine agent moves the orchestrator and models into customer ownership too.

---

3. Declarative Agents

To configure a declarative agent the architect supplies three things:

• Custom instructions that shape Copilot's responses to the organisation's workflow.
• Custom knowledge connecting Microsoft 365 sources — Teams messages, SharePoint, OneDrive, Copilot connectors — or external data via Microsoft 365 Copilot connectors.
• Custom actions that integrate with APIs to interact with external systems in real time.

Characteristics that drive the proposal:

• Hosting: none required — the agent uses Copilot's orchestrator and foundation model.
• Tooling: low-code through the Microsoft 365 Copilot agent builder, or pro-code through Visual Studio / VS Code with the Microsoft 365 Agents Toolkit.
• Channels: Microsoft 365 Copilot and Microsoft 365 apps including Teams, Word, Excel, and Outlook.
• Compliance: inherits Microsoft 365 compliance, responsible-AI, and security standards.

Propose a declarative agent when the agent should work within Copilot's orchestration and models for consistency with security and compliance; when a faster, low-code or streamlined pro-code implementation is wanted; or when the user's workflow already sits inside Microsoft 365 apps and they want to work in that context — for example an IT helpdesk agent that responds to @mentions in Teams, or a document-summarisation agent invoked in SharePoint.

---

4. Custom Engine Agents

To develop a custom engine agent the architect must supply:

• Custom orchestration for full control of workflows, integrating additional knowledge and external API calls, potentially across multiple language models.
• Custom models — foundation large language models, small language models, fine-tuned models, or industry-specific models.
• Autonomy and proactive agentic support to programmatically initiate workflows and actions, operate independently, make decisions, and escalate tasks.

Characteristics:

• Hosting: required outside Microsoft 365, typically Azure, at additional cost.
• Tooling: low-code orchestration in Copilot Studio, or pro-code in Visual Studio / VS Code and the Agents Toolkit using .NET, Python, or JavaScript with frameworks such as Semantic Kernel or LangChain.
• Channels: Microsoft 365 Copilot, Microsoft 365 apps including Teams, Word, Excel, and Edge, and external applications.
• Collaboration: supports agent-to-agent communication, allowing agents to delegate tasks and coordinate workflows across multiple agents in the organisation.
• Compliance: the customer must ensure its own compliance, responsible-AI practices, and security measures.

Propose a custom engine agent when the agent requires custom orchestration for complex workflows, specific business logic, precise decision rules, or multiple system integrations — a financial loan-approval agent with defined business rules, precise data-gathering requirements, and multiple credit-check systems is Microsoft's own canonical example. Also propose it when the organisation needs its own or domain-specific models; when group productivity is required so multiple users collaborate with the same agent in a Teams channel or meeting; when an existing conversational assistant built outside Copilot must be integrated; when the agent must be available outside Microsoft 365; or when proactive messaging must trigger agent behaviour without user interaction.

---

5. The Decision Matrix

Three rows decide most exam scenarios: proactive interactions, group collaboration, and availability outside Microsoft 365. Any one of them present in the requirement forces a custom engine agent. None of them present, with Microsoft 365 as the workflow home, points to declarative.

---

6. Governance, Publication & Cost

Agents do not become available simply because they were built. Publication paths run within my organisation or to the commercial store for ISVs, and organisational agents are governed in the Microsoft 365 admin center, where administrators manage which conversational and AI actions and agents appear in Microsoft 365 Copilot. An architect proposing an agent should therefore also name the approval path, not only the build tool.

Cost implications exist from both the user and the hosting perspective. Declarative agents add no hosting cost but presume Microsoft 365 Copilot seats for their users. Custom engine agents add hosting, model inference, and operational cost that must appear in the total cost of ownership analysis rather than being discovered after go-live.

---

7. Anti-Patterns

• Declarative for proactive. Proposing a declarative agent for a scenario requiring scheduled or event-driven initiation. Declarative agents rely on user-initiated interactions.
• Custom engine by default. Choosing custom engine because it sounds more capable, and inheriting the full compliance and responsible-AI burden for a scenario Copilot's orchestrator handled natively.
• Ignoring first-party agents. Building what Researcher, Analyst, Facilitator, or a SharePoint agent already does.
• Forgetting the group dimension. Declarative agents are designed for individual use; a Teams-channel agent serving a whole team is a custom engine scenario.
• Omitting the admin approval path. Treating build completion as deployment, with no plan for Microsoft 365 admin center governance.

AB-100 Exam Tip: Read the scenario for three trigger words before anything else — proactively, the team, and outside Microsoft 365. Any of them makes the answer a custom engine agent regardless of how simple the rest of the scenario looks. If none appear and the work happens in Teams, SharePoint, Outlook, or Word, the answer is a declarative agent, and the cheapest correct answer is often a first-party agent that needs no build at all.