AB-100 study guide: how to pass Agentic AI Business Solutions Architect
Copilot Studio Certifications How-to
My daily job is solution architecture for Dynamics applications. That is why in late 2025 I earned both the Power Platform solution architect and the Finance and Operations architect certifications. Imagine my surprise when Microsoft planned to retire both the PL-600 and the MB-700 exams in June 2026. It made sense when I learned about the AB-100.
Part of the AB series of exams that focus on agentic work, this certification does not simply replace the CE and F&O architect credentials. It introduces a more strategic role in the business applications curriculum: one that measures an architect’s ability to design AI solutions for organisations across products and services.
The distinction between Power Platform, Customer Engagement, and Finance and Operations apps does not disappear, but it sits mainly at the functional level for functional consultants and developer associate certifications. For solution architects, Microsoft expects you to deliver end-to-end AI solutions across multiple platforms.
This AB-100 study guide explains the certification and how to prepare so you can pass the exam and get certified. If you are still choosing between the various AB exams, read my article about Microsoft’s new AB certifications. If you want to learn the more hands-on builder path first, read my AB-620 study guide. For the domain weights, prerequisites, and FAQ, read the AB-100 exam guide.
What is an Agentic AI Business Solutions Architect?
Microsoft describes candidates for this exam as accomplished solution architects who design and deliver AI-driven business solutions across multiple Microsoft services. The official profile stresses scalable, secure, integrated designs that use Dynamics 365, Power Platform, Microsoft Copilot Studio, and Microsoft Foundry, including generative AI, multi-agent orchestration, and protocols such as Model Context Protocol (MCP).
From that description, we can derive two important elements of this new role:
- Cross-platform. Single-product expertise is no longer enough for solution architects. Microsoft expects expertise across business applications and AI services.
- Performance and security are a priority. Scalable, secure, and integrated solutions mean AI architecture that serves the organisation’s strategy.
I personally welcome this change of scope for solution architects in business applications. It makes solution architects more strategic and less like very senior functional consultants.
The exam skills measured as of 22 July 2026 fall into three areas:
| Domain | Weight | Study implication |
|---|---|---|
| Plan AI-powered business solutions | 25–30% | Strategy, grounding data, platform choices, and ROI |
| Design AI-powered business solutions | 25–30% | Agents and extensibility across Dynamics, Copilot Studio, and Foundry |
| Deploy AI-powered business solutions | 40–45% | Monitoring, testing, packaging and promotion, security, and responsible AI |
Despite being an architect certification, the deploy domain is the largest slice. You must be able to design how agents are tested, monitored, secured, and released.
Design a project that covers the exam
If you want to prepare for the exam, the official Microsoft Learn self-study material is a good place to start: the AB-100 study guide. Alternatively, check AB-100: Agentic AI Business Solutions Architect, where I have included a few links to our online training partners like MeasureUp and other courses.
In my experience, working on a project that mirrors the exam questions and domains is the best way to prepare for an exam. The project below covers planning, design, and deployment for an AI-enabled case process that spans Customer Engagement and Business Central.
Project: intelligent case management for physical products
The organisation sells physical products and runs customer service on Dynamics 365 Customer Service and warehouse and fulfilment on Business Central. When a customer complains about a product, the process must connect the case, the person, the shipment, the serial number, recall policy, and the teams that act next.
Users
- Customer service representatives who own the case in Dynamics 365 Customer Service
- Warehouse staff who shipped the item and handle returns in Business Central
Also notified
- Engineering, when serial or defect patterns meet defined thresholds. They decide on a recall; they do not need day-to-day access to the case.
End-to-end flow the architecture must support
- Capture the customer complaint and open or update a case in Dynamics 365 Customer Service.
- Identify the customer from the inbound email and related contact or account data.
- Find the product the warehouse shipped in Business Central (sales shipment and serial tracking as configured in the company).
- Use the serial number to check for known defect patterns or matching history.
- Search the organisation’s product recall policy, using only approved knowledge content.
- Alert the right people:
- customer service on the case
- warehouse for a return
- engineering when the pattern may require a recall decision
That process flow covers the AB-100 domain areas: multi-system design, agents and orchestration, knowledge, integrations, hand-offs, and controlled deployment.
Plan the solution
First, we define the business outcomewhich is to reduce the time to qualify a product complaint, connect it to the correct shipment and serial, and help the team decide whether to start a return or a product recall, with fewer manual lookups across Customer Service and Business Central.
Systems and data
| System | Data used in the process |
|---|---|
| Dynamics 365 Customer Service | Cases, contacts/accounts, email, queues, activities |
| Business Central | Shipments, items, serial numbers, return-related documents |
| Knowledge store (SharePoint or equivalent) | Product recall policy and related service policy |
Then, we define ownership for each source: who maintains serial history, who owns the recall policy, who can update case categories. If serial numbers are incomplete in Business Central, the architecture must say what happens next: request the serial from the customer, park the case, or stop automated matching until a person corrects the data.
Then, we define the platforms for this project:
- Dynamics 365 Customer Service is the system of record for the case and for customer service work.
- Business Central is the system of record for product, shipment, and serial data.
- Copilot Studio hosts the agents and orchestration that call into both systems and the recall knowledge base.
- Microsoft Foundry is out of scope for the first release of this process unless a concrete requirement appears that Copilot Studio and the Business Central integration cannot meet.
After that, we decide to build, buy, or extend. In this case, we extend the existing Customer Service and Business Central landscape with Copilot Studio agents and integrations. We do not replace the case system or product tracing for this scenario. After go-live, customer service owns how cases are handled; warehouse owns the quality of serial, shipment, and return data; engineering owns recall decisions; IT or the team that runs Power Platform owns how agents are packaged, moved from development to test to production, and published.
Next, we define the rules that belong in the architecture:
- Do not close or resolve a case without a customer service representative.
- Do not invent recall language that is not in the approved policy content.
- Do not create return or recall actions in Business Central outside the organisation’s existing return process, and require human confirmation where policy demands it.
- Escalate to engineering on defined serial or defect patterns; engineering decides recall, not the agent.
Design the agents and integrations
With the plan in place, we move on and design the orchestration path that implements the flow: a primary agent in Copilot Studio with clear hand-offs to people and, if needed, to a second product recall and quality management specialist agent later.
Intake and case context (Customer Service).
The process starts when a customer complains, usually by email. Dynamics 365 Customer Service already turns that into a case on a queue. In this architecture the agent’s first job is to use the sender address, and any matching contact or account data, to identify the customer and make sure the case is linked to the right record. Customer service representatives still own the case and work it in Customer Service. The agent prepares identity and context for them; it does not take over the queue or close work on their behalf.
Product and serial resolution (Business Central).
Business Central is the system of record for what was shipped and under which serial number. After the case is linked to a customer, the architecture requires a controlled read from Business Central: given customer and product context from the case, return shipment and serial data the service team is allowed to see.
That access is designed as a Business Central MCP server configuration for this process, consumed from Copilot Studio as agent tools. I cover the setup in How to set up and use the MCP Server in Dynamics 365 Business Central. The configuration exposes a fixed, named set of operations for this flow. For example: find shipments for a customer, get serials for a shipment or item. Development, test, and production each use the matching company and environment settings for the MCP connection.
Business Central MCP runs operations under the signed-in user’s identity using Microsoft Entra ID. The AI scope here has two layers: which tools the MCP configuration exposes, and which Business Central permissions users must have. Customer service staff who trigger serial lookup need only the Business Central rights required for this task; we will not grant warehouse administration rights through the agent.
When several shipments or serials match, the agent does not guess one. It returns the shortlist on the case for the customer service representative to confirm. When nothing matches, it records that on the case and stops automated serial matching until a person supplies or corrects the serial.
Defect and policy check.
Once the correct item and serial number are found, the flow must run two different kinds of lookup and keep them separate.
Structured data from Business Central answers “what do we know about this product?” Policy answers in the knowledge base determine what the organisation must do under the product recall policy while generative answers must be allowed only from the approved library. Shipment and serial number data must always come from Business Central through the MCP.
Notifications and hand-offs
When matching and policy checks complete, the flow must perform three actions:
- The customer service team receives a case update on the timeline with customer, item, serial, and the relevant policy extract so the representative can continue the case.
- The warehouse team receives a return instruction tied to the shipment and serial so returns follow the existing Business Central process.
- Engineering receives a recall-risk alert only when defined serial or defect patterns are met, with a summary of the serial cluster, not a full dump of case notes.
Integration standard.
With two platforms and Copilot Studio in between, this architecture requires an integration standard: Customer Service data is reached through Dataverse against the case and contact entities. Business Central data is reached through the Business Central MCP configuration described above. Emails, Teams and SharePoint are connected via the Copilot Studio connector.
Deploy, test, and govern
Deploy is 40–45% of AB-100. Treat this project like a real dual-app release.
Release and packaging. Package Copilot Studio agents, connection references, and related Dataverse components in solutions. Configure the Business Central MCP connection per environment so each stage points at the right company. Move changes through development, then test, then production. Release MCP configuration and Business Central permissions together.
Security. Grant separate access to customer service data and Business Central serial and shipment data. Limit the MCP configuration to the shipment and serial operations. Customer service representatives must not receive warehouse administration rights they do not need; warehouse alerts must not expose unrelated case notes. Restrict who can publish agents and who can edit recall policy content.
Testing. Define cases such as: known serial number with matching shipment vs unknown serial vs multiple shipments; policy match for product recall; engineering alert threshold met; Business Central MCP tool failure. Include negative tests where the agent must stop and hand off to a person.
When plan, design, and deploy for this process are documented and tested in a non-production environment, you have covered the three AB-100 domains with one coherent architecture.
What’s next
After you have passed the exam and obtained your certification, I encourage you to find work that requires agentic architecture skills. It’s common for SAs to fall back into functional consulting or development work. Try to come up with your version of a project that spans across different applications and services. Then, get a trial licence or a sandbox environment for one or more applications and start designing, and don’t forget to share what you built.