Module 2 of 11
Analyze requirements for AI-powered business solutions
Decide where agents genuinely add value, then prove the underlying data is fit to ground them.
Exam questions Q11–Q20 6 units on Learn
Open module 2 on Microsoft Learn ↗ Watch the episode (30 min)
Why this module matters
Two things dominate this module, and both appear heavily in the exam. First, classifying a candidate scenario as task automation, data analytics, or decision support — because each implies different grounding, different risk, and a different degree of human oversight.
Second, the five data-quality dimensions. Microsoft names them explicitly, and questions test them by describing a symptom and asking which dimension has failed. Learn them as a list you can recite.
The one big ideaMost failed agent projects are data projects that were not recognised as data projects. Assess grounding data before you commit to a design.
What Microsoft Learn covers
Units in this module, as published on Microsoft Learn:
- Introduction
- Assess the use of agents in task automation, data analytics, and decision-making
- Review data for grounding accuracy, relevance, timeliness, cleanliness, and availability
- Organize business solution data for AI systems
- Module assessment
- Summary
Watch this module
Microsoft Learn publishes a free video course for AB-100 on YouTube. This module is covered by one 30 min episode. An instructor walking through the module is often faster than reading it twice.
Key concepts and definitions
| Task automation | The agent performs repeatable, rules-light work — routing, drafting, summarising, data entry. Highest volume, lowest risk, usually the best first scenario. |
| Data analytics | The agent interprets and explains data, surfacing trends and anomalies. Value depends almost entirely on data quality and freshness. |
| Decision-making | The agent recommends or takes a consequential decision. Requires explainability, human oversight, and audit. |
| Accuracy | Is the grounding content factually correct and authoritative? Symptom of failure: confidently wrong answers traced to a wrong source. |
| Relevance | Does the content actually relate to the questions being asked? Symptom: correct-but-useless answers, or retrieval returning noise. |
| Timeliness | Is the content current? Symptom: the agent quotes a superseded policy or last quarter's price list. |
| Cleanliness | Is it deduplicated, consistently formatted, and free of contradiction? Symptom: two conflicting answers to the same question. |
| Availability | Can the agent actually reach it, at the right time, with the right permissions? Symptom: gaps, timeouts, or empty retrieval. |
| Functional requirement | What the solution must do — answer policy questions, create a case, send a summary. |
| Non-functional requirement | How well it must do it — latency, throughput, availability, accuracy thresholds, language support. |
| Authoritative source | The single system or document set designated as the truth for a topic, with a named owner accountable for its currency. |
Design guidance
Running discovery
- Map the process at task level with volume, time per task, and pain points. Value is volume × time saved × confidence, not enthusiasm.
- Interview the frontline workers who do the task today — the most commonly overlooked and most informative stakeholder group.
- For every knowledge requirement, ask: *which source is authoritative, who owns it, and how often does it change?*
- Write scope boundaries explicitly, including what the agent should do when asked something out of scope.
Setting success criteria
- Agree the baseline before build. Without a before-measurement you cannot claim an after-improvement.
- Define target metrics, how each is measured, and how improvement will be attributed to the agent rather than to seasonality or other changes.
- Include a quality bar (for example groundedness and task success) alongside adoption, so a popular but inaccurate agent cannot be declared a success.
Organising data for grounding
- Consolidate to a small number of curated, authoritative sources rather than pointing the agent at everything.
- Chunk long documents sensibly and attach metadata — owner, effective date, region, audience — so retrieval can filter.
- Retire superseded content. Leaving it discoverable is a direct cause of contradictory answers.
- Confirm permissions on the source are correct before connecting it: an agent inherits and amplifies whatever oversharing already exists.
Good practice vs. anti-pattern
Do
- Quantify current-state volume and effort during discovery.
- Name an owner for every knowledge source.
- Define out-of-scope behaviour and escalation.
- Assess the five data-quality dimensions explicitly.
Avoid
- Accept "the agent should answer HR questions" as a requirement.
- Point an agent at an entire SharePoint tenant and hope.
- Defer success measurement until after go-live.
- Treat regulated personal data as an implementation detail.
Exam traps to watch for
TrapA latency, throughput, or accuracy-threshold requirement is non-functional, even though it sounds technical and specific.
TrapWhen a stakeholder gives a one-line request, the best next step is almost always a clarifying question about authoritative sources and ownership, not a technology choice.
TrapPersonal data of EU residents pulls in two things: data residency/processing location *and* lawful basis, purpose limitation, and data subject rights. Questions often expect both.
Trap"Users like it" and "the vendor's benchmark" are never acceptable success criteria.
Readiness checklist
You are ready to move on when you can do all of these without notes.
- Recite the five grounding data-quality dimensions and give a failure symptom for each.
- Classify a scenario as task automation, analytics, or decision-making and say what oversight each needs.
- Turn a vague stakeholder request into three sharp clarifying questions.
- Distinguish functional from non-functional requirements in a mixed list.
- Explain why source permissions must be reviewed before connecting a knowledge source.