Microsoft updates the skills measured for Exam AB-100, the Agentic AI Business Solutions Architect certification, on 14 October 2026. Anyone revising now is revising for the new outline.
We read the updated skills list end to end, all 74 bullet points, and checked each one against the Microsoft Learn pages behind it. This post is what came out of that. It is not a syllabus and it does not teach the exam. It is a list of the places where we had to stop and work out what Microsoft actually meant, because the answer was not the obvious one.
A pattern showed up often enough to be worth naming. AB-100 covers a part of the product estate that has been renamed repeatedly, and Microsoft's training material has not always caught up with its own product documentation. Several of the hardest moments on this exam are not hard concepts. They are two Microsoft pages using one word for two things.
What kind of exam it is
AB-100 asks you to choose between options and to justify the choice. You are not asked to build anything, and there is no code.
The skills list has three areas. Planning and analysing requirements carries 20 bullets. Designing agents and solutions carries 30. Deploying, monitoring, testing and governing them carries 24, and that third area is roughly 40 to 45 percent of the exam.
That weighting catches people out. The design area has more bullets, so it looks like the bigger subject, but the deploy area carries more marks per bullet. It is also the area most freely available study material covers least, because release processes and governance are duller to write about than agents.
Where Microsoft uses one name for two things
Foundry Tools
The Learn training unit for the relevant skill defines Foundry Tools as model catalogues, tool APIs, orchestration frameworks, evaluation utilities and SDKs. In the product documentation, Foundry Tools is the new name for the renamed Azure AI services, the ones you knew as Speech, Language, Vision, Document Intelligence and Content Safety.
Both are current. Both are Microsoft's. When a question says Foundry Tools, read the rest of the scenario before deciding which sense applies. If it is about what an agent calls while it runs, it is the first. If it is about which prebuilt service handles transcription or OCR, it is the second.
Copilot Hub and the Copilot area
The Power Platform admin centre page calls it the Copilot area, reached by selecting Copilot in the navigation pane. The Dynamics 365 pages call the same console Copilot Hub, and that is where they put the agent deployment wizard. The URL of the first page is still copilot-hub.
One console, two names, and no page that says so. If a scenario mentions both, it is not describing two places.
Manage agents, or operate agents
The Cloud Adoption Framework's agent lifecycle has a phase the CAF page calls manage agents, with integrate and operate sitting underneath it as sub-steps. The Learn unit for the adoption skill calls the same phase operate agents. If an option list gives you one name and your notes hold the other, they are the same phase.
A prompt, a prompt action, and where prompts live
Prompt Gallery is where prompts are saved and shared across a team. The prompt lab is where published organisational prompts appear to the people who use them. Those are two surfaces and they get treated as one constantly.
A prompt is the reusable instruction you write. A prompt action is that prompt wrapped in a plugin definition with a name, a description and named parameters, which is what lets a copilot match a user's words against it and call it. A scenario where Microsoft 365 Copilot has to be able to run one of your prompts is asking about the action, not the prompt.
Try a real Azure AI lab, free
A pre-provisioned Azure environment in your browser. No Azure account, no credit card, no setup.
Most large enterprises already run on Microsoft infrastructure. Azure AI Foundry is the platform those teams use to build and deploy AI apps, so the skills you practice here map directly to real job demand.
Where the numbers get misquoted
The ceiling for generative orchestration is quoted online in several forms. What Microsoft's page says is that the orchestrator handles a maximum of 128 tools per agent, and that for best performance you should keep an agent to no more than 25 to 30 tools. A child agent runs its own orchestration and gets a separate set of up to 128.
What matters is what the number counts. It counts tools. We could not find a Microsoft Learn page that extends the ceiling to topics or to other agents, and we looked at the generative orchestration guidance, the multi-agent patterns guidance, the FAQ, the tools overview, the child agent page and the quotas page. A lower combined figure is in circulation. We could not source it.
This has a practical consequence. When an agent has accumulated too many tools, the construct Microsoft documents for the extra headroom is a child agent. Splitting work into a separate connected agent is a different decision, and Microsoft's criteria for that are a distinct domain of expertise with its own tools or knowledge, different governance or access controls, and reuse across several main agents. A question about tool crowding and a question about team ownership have different answers.
The area worth the most marks
If revision time is short, spend it on the deploy area. Three things in it come up in scenarios and are rarely covered elsewhere.
What a release has to carry
Microsoft sets out the data lifecycle as a series of gates, lettered A to F, tied to phases rather than to environments. Each gate names the evidence it wants. Early on that is a data contract with an accountable owner, classification and labelling, and a catalogue entry. Later it is a profiling report, a lineage graph, stamped schema versions, evaluation thresholds met on frozen datasets, a recorded residency decision, and a rollback plan that has been exercised.
Questions here tend to offer plausible artefacts that are not evidence of anything: a schema file from a migration tool, or a retention policy. Knowing that a gate has a named evidence list is usually enough to eliminate them.
An AI change in the finance apps crosses more than one lifecycle
This one is a genuine trap, and the wrong answer is the tidy one. A change that touches an agent in Dynamics 365 finance and supply chain does not travel as a single managed solution.
The Dataverse side, meaning the agent, its prompts, its flows and its connection references, moves in a solution. An X++ extension moves as a deployable package, built on a build machine, published to the Lifecycle Services asset library and applied after user acceptance testing. A third set of things travels in neither, and has to be set again in every environment: feature management flags, Copilot settings, consent to data movement, and the agent user's licences and roles.
Promote one managed solution and two thirds of the change is missing. That is our framing rather than Microsoft's wording, but every part of it is in their documentation.
What an environment copy leaves behind
Copy a Customer Service environment and the copied agent needs its capabilities, connections, authentication and workstream associations revalidated, any reference to the source environment updated, and the agent published in the target. Separately, Omnichannel real-time analytics and the historical analytics report each have to be switched off and back on in the Copilot Service admin centre so that reports reflect the new environment rather than the old one.
The scenario usually arrives as a symptom. The copied agent answers questions but never escalates, and the dashboards still show production figures.
Still here? You clearly care, grab the exam study guide
One-page quick reference plus the hands-on labs that go with it.
Two smaller things that decide questions
Not every failure is a knowledge problem. Microsoft's troubleshooting material works from five root causes, and two of them are easy to miss: configuration issues, meaning a wrong environment variable, feature toggle or role setting, and governance interference, meaning a data loss prevention block, a sensitivity label or a restricted action. Both produce symptoms that look like the agent does not know something. An agent that answers correctly but cannot create a case for one group of users is a permissions or policy problem, and no amount of knowledge tuning will fix it. Worth knowing that a blocked connector surfaces as a DataLossPreventionViolation error, and that since March 2025 agents cannot be exempted from data policy enforcement.
Chain of thought is not universally good advice. Microsoft presents it as a technique that improves correctness on analysis and troubleshooting, and lists overuse as the pitfall. For reasoning models the guidance is the opposite: keep instructions simple and do not ask for chain of thought, because the model already works that way. An option that applies it to everything is wrong, and so is an option that rejects it outright.
How to revise for this one
Reading for recall does not work here, because the options in a question all exist and all sound reasonable. Knowing what a feature does will not eliminate three of them.
Try it in reverse. Take a capability and write the requirement that would make it the right answer, then write the requirement that would rule it out. If you cannot produce the second one, you do not know that option well enough to reject it under time pressure.
Track preview status as you go. Whether something is generally available or still in preview is used to separate a correct answer from a plausible one more often than you would expect, and it moves. Service Agent in Microsoft 365 Copilot reached general availability on 30 June 2026, for example, and nothing in Microsoft's documentation describes it as a replacement for Copilot in Customer Service, which is still documented and still extended through Copilot Studio. Two products, both live.
Finally, get used to sign-off criteria. Validation for a custom model is not one number. Microsoft's own worked example sets a threshold on each dimension: latency under two seconds, correctness at 90 percent or better, incorrect information at three percent or less, no guardrail violations, and a satisfaction score of at least 4.5 out of 5. A question asking what "ready for production" means wants the whole set, not the best individual metric.
Note: Microsoft changes exam outlines and product documentation, sometimes quickly. Everything above was checked against Microsoft Learn on 20 September 2026. Confirm against the official skills list before you book.
Frequently asked questions
When does the AB-100 outline change?
14 October 2026. If your exam is on or after that date, revise from the updated skills list.
Is AB-100 a developer exam?
No. It is an architect exam. It asks you to select between approaches and justify the selection, and there is no code.
Which area should I spend most time on?
Deploying, monitoring, testing and governing. It is roughly 40 to 45 percent of the exam and it is the area most study material covers least.
Do I need to know which features are in preview?
Where the skills list names them, yes. Preview status is used as a discriminator between a right answer and a plausible wrong one, so track it as you revise rather than looking it up at the end.
Why do some sources quote a different tool limit?
We do not know. Microsoft's page gives 128 tools per agent and a recommendation of no more than 25 to 30, with child agents getting their own set of 128. A lower combined figure covering topics and agents circulates widely, and we could not find it on any Microsoft Learn page.
Do you have an AB-100 study guide?
Yes, and it is free. Twelve modules following Microsoft's own learning path for the exam, about three and a half hours of reading, every fact checked against Microsoft Learn and checked again by someone other than the writer before publishing. It is free to read with a GetHandsOn.ai account: AB-100 study guide.