The Use Case Qualifier Is Not an Agent, It Is a Chain

Microsoft featured the Use Case Qualifier system prompt as System Prompt of the Week on the Copilot Prompt Library, in a post by Rabia Williams, Senior Cloud Advocate, on 26 May 2026, ahead of the Microsoft 365 developer community call.

That is external validation rather than a self-assessment: somebody at Microsoft read the instructions and decided to put them in front of an audience. The post is here.

An agent that interviews and an agent that judges do not have the same instructions, and they do not carry the same risk. Mix the two and you get an agreeable agent: one that qualifies everything, because the same system prompt that gathers enthusiasm is also grading it.

So the work is split in three:

• Upstream: seven specialists plus an orchestrator, whose job is to find signal.
• The qualifier: the one that decides, with the authority to refuse.
• The contract: a conversational JSON payload that carries what the upstream found, with a no-regression rule written down.

Pain Miner, Peer Benchmark, Process Audit, Cal/Mail/Teams Miner, Doc Graveyard Scanner, Copilot Usage Gap Analyzer, Competitive Threat Scanner, behind one orchestrator.

The design choice worth defending: these specialists do not interview the user. They go and find the signal where it already is, in the tickets, in the calendars, in the documents nobody has opened in two years, in the Copilot consumption data. A user who has already been profiled by the Pain Miner does not sit through the full interview again.

A guided 4P interview covering Persona, Pain, Process and Payback, eight questions deep, digging until there are numbers rather than adjectives.

Then scoring on five dimensions, each 1 to 5: the real cost of the problem, how often it happens, how many people it affects, whether the data exists and is accessible, and whether the case fits the Microsoft stack the client already pays for. The qualification threshold is 15 out of 25. Below it, the agent refuses and names the two weakest dimensions.

Some requests are rejected whatever they score:

• A feature request with no business problem behind it.
• A trivial generic function, along the lines of "summarise my email".
• Personal or consumer use, outside the professional scope.
• A case that is illegal, saturated with personal data, or politically partisan.
• A framing along the lines of "replace my whole team".

Every rejection ships with two or three concrete reframes, so a refusal becomes a workable lead rather than a closed door. And the filters are never bypassed by a handoff: even a case arriving through the upstream chain with a full payload is refused if it is out of scope.

The report is drafted in the requester's own Outlook mailbox, in Invoker mode, never from a shared service identity. And the agent cannot send: it prepares, and a human confirms.

That changes two things. Traceability stays attached to a real person, and there is no service account quietly sending mail on everyone's behalf. It is the difference between a demo and something a security committee will approve.

• Two bots, language-locked, French and English, rather than one bot that switches. A bot locked to one language has shorter instructions, a cleaner knowledge base, and it does not drift mid-answer.
• Versioned Power Platform solution, iteration 1.0.0.22.
• Instructions kept under 8,000 characters, the platform limit. Knowing the real ceilings is what separates shipping from prototyping.
• Grounded on the Microsoft Learn MCP server to justify the Microsoft-fit dimension rather than asserting it.

Dropped into a client, the chain produces a qualified pipeline without tying up a senior consultant. That is the point of it.