Study guide
2.4 Developing Use Cases for Prebuilt Agents & the Microsoft Agent Catalog
Microsoft Certified: Agentic AI Business Solutions Architect Expert AB-100
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Requirements Analysis & Grounding Data
1.1 Assessing Agents for Task Automation, Analytics & Decision-Making 1.2 Grounding Data Evaluation: Accuracy, Relevance, Timeliness, Cleanliness & Availability 1.3 Structuring Enterprise Business Data for AI System Interoperability
2 Chapter 2: AI Strategy, Cloud Adoption Framework & CoE
2.1 Cloud Adoption Framework (CAF) for Azure AI Strategy & Roadmap 2.2 Multi-Agent Architecture: Microsoft 365 Copilot, Copilot Studio & Foundry 2.3 Microsoft AI Center of Excellence (CoE) & Solution Governance 2.4 Developing Use Cases for Prebuilt Agents & the Microsoft Agent Catalog 2.5 Solution Rules & Constraints for Copilot Studio, Microsoft Foundry & Foundry Tools
3 Chapter 3: Model Selection, Prompt Engineering & Dynamics AI
3.1 Model Selection Strategy, Custom Models & Small Language Models (SLMs) 3.2 Enterprise Prompt Engineering Guidelines & Prompt Libraries 3.3 Cross-App AI Strategy for Multi-App Dynamics 365 Solutions
4 Chapter 4: ROI, TCO, Build vs Buy & Model Routing
4.1 ROI Criteria & Total Cost of Ownership (TCO) for AI Solutions 4.2 Comprehensive Financial ROI Analysis for Business Processes 4.3 Build vs Buy vs Extend Architectural Decision Framework 4.4 Dynamic Model Router Architecture & Cost-Performance Optimization
5 Chapter 5: Dynamics 365 AI & Contact Center Design
5.1 Business Terms & Copilot Customization in Customer Experience and Service 5.2 Connectors & Data Flow Design for Copilot in Dynamics 365 Sales 5.3 Agent Integration with Dynamics 365 Contact Center Channels
6 Chapter 6: Agent Archetypes & Copilot Studio Core
6.1 Designing Task Agents, Autonomous Agents & Prompt-and-Response Agents 6.2 Copilot Studio Topic Design, Trigger Phrases & Graceful Fallbacks 6.3 Orchestration Selection: Standard NLP vs CLU vs Generative AI Orchestration
7 Chapter 7: Copilot Studio Advanced Actions & Power Platform
7.1 Designing Agent Flows & Prompt Actions in Copilot Studio 7.2 Power Apps Canvas App Integration, Generative Pages & Agent Feeds 7.3 Power Platform Well-Architected Framework for AI Workloads 7.4 Proposing Microsoft Power Platform AI Features & the AI Hub
8 Chapter 8: Agent Extensibility, MCP & Computer Use
8.1 Microsoft Foundry Custom Models & Foundry Tools Selection 8.2 Agent Extensibility via Model Context Protocol (MCP) in Copilot Studio 8.3 Computer Use Automation & Web UI Interactions in Copilot Studio
9 Chapter 9: Advanced Behaviors & Prebuilt App Orchestration
9.1 Agent Behaviors: Multi-Step Reasoning, Voice Mode & M365 Agent Optimization 9.2 Orchestrating Prebuilt AI in Dynamics 365 F&O and M365 Copilot for Sales/Service 9.3 Orchestrating Prebuilt Copilot AI Features in Dynamics 365 Customer Experience & Service 9.4 Proposing Microsoft 365 Agents for Business Scenarios 9.5 Adding Knowledge Sources to In-App Help & Guidance in Dynamics 365 Finance & Supply Chain
10 Chapter 10: Telemetry, Monitoring & Agent Tuning
10.1 Monitoring Architectures: Azure Monitor, Application Insights & Studio Analytics 10.2 Telemetry Data Interpretation, Performance Metrics & Latency Tuning 10.3 User Feedback Analysis, Backlog Prioritization & Continuous Improvement
11 Chapter 11: Testing Strategy & Model Validation
11.1 Agent Testing Frameworks, Quality Metrics & Groundedness Benchmarks 11.2 Custom AI Model Validation, Safety Criteria & Regression Testing 11.3 Copilot-Assisted Test Case Generation & Cross-Dynamics End-to-End Testing 11.4 Validating Effective Copilot Prompt Practices
12 Chapter 12: ALM for Grounding Data & Copilot Studio Agents
12.1 ALM for Grounding Data, Vector Indexes & Knowledge Synchronization 12.2 ALM for Copilot Studio Agents, Connectors & Solution Packaging 12.3 Environment Strategy & Automated Deployment Pipelines for Studio Agents
13 Chapter 13: ALM for Foundry Agents & Dynamics 365 AI
13.1 ALM for Microsoft Foundry Agents Service & Model Registries 13.2 ALM for Custom AI Models, Fine-Tuning Artifacts & Deployment Slots 13.3 ALM for Dynamics 365 AI in Finance, Supply Chain & Customer Engagement
14 Chapter 14: Agent Identity, Security & Access Controls
14.1 Agent Identity Architecture, Microsoft Entra ID & Authentication Flows 14.2 Access Controls, Role-Based Security & Permissions on Grounding Data 14.3 Secure Data Processing & Grounding Data Isolation
15 Chapter 15: Model Security & Threat Mitigation
15.1 Model Security Architecture & Defense Against Vulnerabilities 15.2 Mitigating Prompt Manipulation, Jailbreaks & Indirect Prompt Injections 15.3 Azure AI Content Safety, Prompt Shields & Guardrails
16 Chapter 16: Responsible AI, Governance, Residency & Audit
16.1 Microsoft Responsible AI Standard: Principles, Assessment & Implementation 16.2 Data Residency, Sovereign Boundaries & Cross-Border Compliance 16.3 Comprehensive Audit Trails, Model Decision Logging & Microsoft Purview 16.4 Designing Governance for Agents: Environment Strategy, Data Policies & Agent Inventory
2.4 Developing Use Cases for Prebuilt Agents & the Microsoft Agent Catalog
Key Takeaways Explain This Topic AI
Prebuilt agents arrive through four distinct supply channels: first-party Dynamics 365 agents enabled inside a business app, Microsoft 365 Copilot agents licensed with the Copilot seat, Copilot Studio agent templates, and Dynamics 365 agent templates published through the FastTrack implementation-assets repository on GitHub.
First-party Dynamics 365 agents such as Sales Qualification, Supplier Communications, Case Management and Account Reconciliation are enabled rather than deployed: Microsoft retains ownership of model selection, orchestration, responsible-AI review and release cadence.
Microsoft 365 Copilot ships Researcher for multi-source cited research, Analyst for data-to-insight work, Facilitator for Teams meeting management, and SharePoint agents for permission-trimmed content questions, all before any custom build is considered.
A template creates a customer-owned artefact the moment it is instantiated, so it shortens time-to-first-demo without reducing long-run ALM, responsible-AI or regression ownership.
The four-gate fit assessment tests outcome coverage, data-model and licensing preconditions, configuration headroom, and governance transfer, with the governance gate frequently dominating the others for regulated processes.
Last updated: September 2026
Prebuilt Agent Use Cases: The Microsoft Agent Catalog & Fit Assessment
Quick Answer: Before an architect authorises a single line of custom agent configuration, the AB-100 blueprint expects a deliberate survey of what Microsoft already ships. Prebuilt agents arrive in four distinct supply channels: first-party Dynamics 365 agents that are switched on inside a business app (Sales Qualification Agent, Supplier Communications Agent, Customer Intent), Microsoft 365 Copilot agents licensed with the Copilot seat (Researcher, Analyst, Facilitator, SharePoint agents), Copilot Studio agent templates that ship as editable starting points, and Dynamics 365 agent templates published through the FastTrack implementation-assets repository on GitHub for financial services, retail, healthcare, and the public sector. The architectural discipline is not "which agent is coolest" but a structured fit assessment : does a shipped agent already cover the business outcome at an acceptable configuration cost, and does adopting it transfer the responsible-AI, ALM, and update burden to Microsoft rather than to the customer?
Most failed agentic programmes do not fail because the technology did not work. They fail because a delivery team spent an eleven-week sprint hand-building a conversational lead-qualification agent in Copilot Studio that Microsoft already shipped, supported, and updated quarterly inside Dynamics 365 Sales. The custom build then decayed: nobody owned its prompts, its knowledge index drifted, and its behaviour diverged from the platform agent that colleagues in another business unit had simply enabled.
Developing the use cases for prebuilt agents is therefore a planning-domain activity, not a design-domain one. It happens before the solution architecture is drawn, and its output is a written inventory that says, for each candidate business process, whether the organisation will enable , template , extend , or build .
- 1. The Four Supply Channels for Prebuilt Agents
- 1.1 First-Party Dynamics 365 Agents
These are Microsoft-authored agents that live inside a Dynamics 365 application and are enabled through that application's admin centre. They are not downloaded, not imported, and not versioned by the customer. Microsoft owns the model selection, the orchestration, the responsible-AI review, and the release cadence.
Representative examples an AB-100 candidate should recognise by business outcome:
Agent Host app Business outcome
Sales Qualification Agent Dynamics 365 Sales Researches inbound leads, drafts outreach, and lets sellers concentrate on the highest-priority opportunities
Sales Research Agent Dynamics 365 Sales Answers strategic questions on pipeline exploration and sales operations from Dynamics 365 Sales data plus other Dataverse environments, Fabric Lakehouse, or uploaded Excel, CSV and PDF files
Customer Intent Agent Dynamics 365 Customer Service / Contact Center Autonomously discovers intents from past interactions to build an intent library and ask intent-specific follow-up questions
Customer Knowledge Management Agent Dynamics 365 Customer Service Converts resolved cases into draft knowledge-base articles for human review
Case Management Agent Dynamics 365 Customer Service Automates the case life cycle — create, update, resolve and close — removing manual case-detail entry from representatives
Supplier Communications Agent Dynamics 365 Supply Chain Management Autonomously chases suppliers to confirm delivery dates and surfaces likely delays
Account Reconciliation Agent Dynamics 365 Finance Evaluates reconciliation exceptions raised in the Account reconciliation workspace and recommends actions, moving the close from reactive to continuous
Expense Agent Dynamics 365 Project Operations Creates expense lines directly from receipts, extracting merchant name, date, currency and total amount
Release status varies by agent — several are generally available while others, such as the Account Reconciliation Agent and the Expense Agent, are in preview at the time of writing, and Microsoft notes that most exam questions cover generally available features while preview features may appear if they are commonly used. The catalogue expands every release wave. An architect should never memorise it as a fixed list; the exam-relevant skill is knowing where to look (the app's own admin centre plus the current Dynamics 365 release plan) and knowing that first-party agents are enabled , not deployed .
1.2 Microsoft 365 Copilot Agents
These ship with the Microsoft 365 Copilot licence and operate across Microsoft Graph rather than inside a line-of-business application:
Researcher — performs multi-step research across work data, the web, and connected sources, producing a cited synthesis. Use it when the requirement is planning, multi-source retrieval, and reasoning, not a single lookup.
Analyst — turns tabular business data into insight and visualisations, iterating over analysis steps the way a data analyst would.
Facilitator — takes notes, answers in-meeting questions, and moderates Microsoft Teams meetings.
SharePoint agents — scoped to a site, library, or set of documents, answering questions grounded strictly in that content with the user's existing permissions honoured.
The critical architectural point: these agents are already grounded in tenant content through Microsoft Graph and already permission-trimmed . Rebuilding "an agent that answers questions about our SharePoint policies" as a custom Copilot Studio agent frequently reproduces, badly, what a SharePoint agent does natively.
1.3 Copilot Studio Agent Templates
Copilot Studio publishes editable templates that pre-populate topics, instructions, tools, and sample knowledge configuration for common scenarios such as IT helpdesk, HR benefits, safety reporting, and website support. Unlike first-party Dynamics agents, a template produces a customer-owned agent : the moment it is created, the organisation owns its lifecycle, its solution packaging, and its responsible-AI review. A template shortens time-to-first-demo; it does not reduce long-run ownership cost.
1.4 Dynamics 365 Agent Templates (FastTrack)
Microsoft publishes industry agent templates for financial services, retail, healthcare, and the public sector through the Dynamics 365 FastTrack implementation-assets repository on GitHub, with product-specific families for Service, Commerce, and Customer Insights. Microsoft describes their benefits as a faster start without complex architecture choices, industry-focused scenarios that address frequently requested regulatory requirements, deployment in days, a known high-impact process with identifiable ROI, and standardised behaviour and governance patterns across teams.
Because these are downloaded solution artefacts, they behave like templates for ALM purposes: the customer imports, customises, and thereafter owns them.
2. The Fit Assessment: A Four-Gate Decision
A defensible prebuilt-agent recommendation runs each candidate business process through four sequential gates. Failing any gate pushes the process to the next tier.
Gate 1 — Outcome coverage. Does a shipped agent already deliver the business outcome , not merely a superficially similar feature? Compare against the process's exit criteria, not its narrative. "Chases suppliers for delivery confirmation" is an outcome; "talks to suppliers" is not.
Gate 2 — Data and licensing preconditions. First-party agents assume their host application's data model. The Supplier Communications Agent assumes purchase orders in Dynamics 365 Supply Chain Management. If purchase orders live in SAP and are only mirrored into Dataverse as virtual tables, the prebuilt agent may not see the fields it needs. Equally, Researcher and Analyst require Microsoft 365 Copilot seats for the users who will invoke them.
Gate 3 — Configuration headroom. Every first-party agent exposes a bounded configuration surface — instructions, prompts, thresholds, knowledge attachment, approval requirements. If the business requirement falls inside that surface, enabling is correct. If it requires behaviour the surface cannot express, the process escalates to extend or build .
Gate 4 — Governance transfer. Enabling a first-party agent transfers responsible-AI review, model currency, content-filter tuning, and regression testing to Microsoft. Building transfers all of it to the customer. For a regulated process, this gate frequently dominates the other three even when a custom build would be marginally more capable.
3. Worked Fit Assessment: A Distribution Business
A European industrial distributor brings four processes to its AI Center of Excellence intake board.
Process Gate 1 Gate 2 Gate 3 Gate 4 Verdict
Confirm supplier delivery dates on open POs Supplier Communications Agent covers it POs are native in Supply Chain Management Thresholds and escalation windows configurable Microsoft owns RAI Enable
Draft knowledge articles from resolved cases Customer Knowledge Management Agent covers it Cases native in Customer Service Review-before-publish is configurable Microsoft owns RAI Enable
Answer questions about the internal quality manual SharePoint agent covers it Manual already in a governed SharePoint library Scope and instructions configurable Permission trimming inherited Enable
Quote configured-to-order industrial pumps against a bespoke pricing engine No shipped agent covers bespoke pricing logic Pricing engine is an on-premises REST service Outside any prebuilt configuration surface Customer accepts RAI ownership Build (Copilot Studio agent + agent flow + on-premises data gateway)
Three of four processes are delivered by enabling shipped agents. The single custom build absorbs the whole engineering budget — and, crucially, the architect can now justify that budget because the alternative was documented and rejected on evidence.
4. Anti-Patterns the Exam Tests
Catalogue blindness. Designing a custom Copilot Studio agent for lead qualification, case triage, or document Q&A without first checking whether Dynamics 365 or Microsoft 365 Copilot already ships it. This is the single most common wrong answer stem in planning-domain scenarios.
Template mistaken for first-party. Assuming that because an agent came from a Microsoft template, Microsoft will keep it current. A template creates a customer-owned artefact from the moment of instantiation.
Ignoring the licence precondition. Proposing Researcher or Analyst for users without Microsoft 365 Copilot seats, or proposing Dynamics-hosted agents to users without the relevant Dynamics 365 licence.
Enabling everything at once. Turning on the full first-party catalogue across production without a pilot cohort, feedback loop, or measurement plan produces adoption noise and no attributable value.
Treating "prebuilt" as "no governance". Even enabled first-party agents need an owner, an adoption metric, an escalation path, and a review of what grounding data they now reach.
AB-100 Exam Tip: When a planning scenario describes a common, well-bounded business process inside a Dynamics 365 app — lead qualification, case summarisation, supplier follow-up, ledger reconciliation — and the option set offers both "build a custom agent in Copilot Studio" and "enable the corresponding first-party agent and configure it", the shipped agent is almost always the intended answer. Custom build becomes correct only when the scenario explicitly introduces logic, data, or a system that lies outside the host application.