Module 5 of 11
Design AI agents for business solutions
Design task, autonomous, and prompt-driven agents in Copilot Studio, plus Copilot customisations across Dynamics 365.
Exam questions Q41–Q50 21 units on Learn
Open module 5 on Microsoft Learn ↗ Watch the episodes (102 min)
Why this module matters
Twenty-one units make this the second-heaviest module. It is where abstract architecture becomes concrete: instructions, knowledge, tools, triggers, topics, fallback, and agent flows.
The recurring exam skill is component selection. Given a requirement, you must say whether it calls for a knowledge source, a tool or action, a topic, a trigger, an agent flow, or a prompt action — and the distinctions are precise.
The one big ideaKnowledge answers questions. Tools take actions. Topics handle known conversational paths. Triggers decide when the agent wakes up. Confusing these is the most common design error.
What Microsoft Learn covers
Units in this module, as published on Microsoft Learn:
- Introduction
- Define core tenets of responsible AI guidelines for AI business solutions
- Design business terms for Copilot in Dynamics 365 Customer Service
- Design customizations for Copilot in Dynamics 365 apps
- Design connectors for Copilot in Dynamics 365 Sales
- Design AI agents for Dynamics 365 Contact Center
- Design task agents in Microsoft Copilot Studio
- Design autonomous agents in Copilot Studio
- Design prompt-driven agents using Copilot Studio
- Propose Foundry tools given a requirement
- Propose code first generative pages and agent feed applications
- Design topics for Copilot Studio, including fallback
- Design data processing workflows for grounded AI
- Design business processes with AI in Power Apps canvas apps
- Apply the Microsoft Power Platform Well-Architected Framework to intelligent application workloads
- Determine the use of standard natural language processing
- Design agents and agent flows with Copilot Studio
- Design prompt actions in Copilot Studio
- Define success criteria and adoption goals for AI business solutions
- Module assessment
- Summarize AI agent design for business solutions
Watch this module
Microsoft Learn publishes a free video course for AB-100 on YouTube. This module is covered across two episodes, 51 min and 51 min. An instructor walking through the module is often faster than reading it twice.
Key concepts and definitions
| Agent instructions | The system prompt defining role, scope, tone, and guardrails. This is what the agent is *for* and what constrains it. |
| Knowledge source | Content the agent retrieves from to answer questions accurately — SharePoint, Dataverse, public websites, Graph connectors, uploaded files. |
| Tool / action | A callable operation that does something outside the conversation — read an ERP order, create a case, send a message. Actions change state; knowledge does not. |
| Topic | A defined conversational path triggered by phrases or events, with explicit steps. Use for known, structured journeys. |
| Fallback topic | What happens when nothing matches. Must state the limitation and offer escalation or handoff — never silence or an empty reply. |
| Task agent | Performs a bounded, well-defined job on request. The safest starting shape. |
| Autonomous agent | Triggered by an event or schedule rather than a user prompt; acts without someone typing. Needs tight permissions and monitoring. |
| Prompt-driven agent | Behaviour shaped principally by natural-language instruction rather than authored topics. |
| Agent flow | Deterministic, orchestrated steps the agent invokes when reliability matters more than model improvisation. |
| Prompt action | A reusable, parameterised generative step — summarise, classify, extract — invoked as a building block. |
| Power Platform Well-Architected Framework | The pillars for evaluating workload quality: reliability, security, operational excellence, performance efficiency, and experience optimisation. |
| Delegated (user-context) authentication | The agent acts as the signed-in user, so existing permissions are enforced. Preferred over a shared service account. |
Design guidance
Choosing the right component
- Needs to answer from content → knowledge source. Never paste the content into the instructions.
- Needs to fetch or change data in another system → a tool/action with a typed parameter schema.
- Needs a known, repeatable conversational path → a topic.
- Needs to start without a user → an event or schedule trigger.
- Needs deterministic multi-step execution → an agent flow rather than free-form reasoning.
Making tool selection reliable
- Give tools clear, distinct names and descriptions that state when to use them, plus precise parameter schemas. Vague descriptions are the main cause of wrong-tool errors.
- Fewer, well-described tools beat many overlapping ones.
- Validate tool inputs; never let retrieved content dictate which tool runs or with what arguments.
Splitting agents and adding safety
- Split into multiple agents when scope, knowledge, permissions, or ownership diverge — not merely because the agent is large.
- Require confirmation before any action that is irreversible or has financial, legal, or customer-facing impact.
- Use delegated authentication so the user's own permissions apply; avoid broad shared service accounts.
- Define success criteria and adoption goals as part of the design, not after launch.
Good practice vs. anti-pattern
Do
- Write tight, role-scoped instructions with explicit guardrails.
- Design an explicit fallback with escalation.
- Confirm before irreversible or high-impact actions.
- Use user-context auth so permissions are enforced.
Avoid
- Embed bulk data in the system prompt instead of grounding it.
- Register many similar tools with vague descriptions.
- Let an out-of-scope question be answered from general model knowledge.
- Run agents under a broad shared account for convenience.
Exam traps to watch for
TrapLooking up live data from an external system is a tool/action, not a knowledge source and not a bigger prompt.
TrapThe right reason to split an agent is divergent scope, knowledge, permissions, or ownership — not token limits and not licensing.
TrapFor an out-of-scope question, the correct behaviour is a defined fallback that states the limitation and offers escalation — not silent general-knowledge answering, not an empty response.
TrapReliability of tool choice comes from better tool descriptions and schemas, not from more tools or a larger model.
Readiness checklist
You are ready to move on when you can do all of these without notes.
- Given five requirements, assign each to knowledge, tool, topic, trigger, or agent flow.
- Write the criteria you would use to split one agent into several.
- Describe what a good fallback does, in one sentence.
- Explain why delegated authentication beats a service account for user-data scenarios.
- Name the pillars of the Power Platform Well-Architected Framework.