Catalogue › Microsoft 365 Agents › agent-use-case-design

Agent use-case design

Turns an approved agent opportunity into an agent brief covering audience, purpose, scope and exclusions, instructions approach, knowledge sources, actions, the build-or-reuse decision, owner, support and success measures. Use when an idea has passed suitability as an agent, when a maker wants to start building, or when an existing agent needs its scope rewritten.

Department

Microsoft 365 Agents

Lifecycle

Envision, Deliver

Maturity

adopter, builder, scaler, ai-enterprise

Risk tiers

1, 2, 3, 4

Platforms

m365-agents, copilot-studio, sharepoint

Editions

starter, scale, enterprise

Reviewers

security-privacy, design-authority

Status

draft

Copilot Cowork

Microsoft 365 Agents plugin for Copilot Cowork, or this skill on its own: Download SKILL.md

Licence

CC BY 4.0, by Simon Foote

Purpose

An approved opportunity says an agent is the right answer; it does not yet say what the agent is for, who it serves or what it must refuse. This skill turns the approved opportunity into an agent brief that a maker can build from, a reviewer can judge and an owner can run. Agent work usually goes wrong here: the scope is "everything about HR", the knowledge is "the SharePoint site", nobody is named to own the answers, and the build route is chosen because the maker already knows one tool.

When to use

• An opportunity has been through suitability and the agent rung was chosen.
• A maker or business team wants to start building and has no written scope.
• An existing agent has grown by accretion and needs its purpose and boundaries restated.
• Two teams want similar agents and someone must decide whether to build once or reuse.

When not to use

• Deciding whether an agent is the right answer at all - use opportunity-management:ai-suitability.
• Confirming the risk tier that governs the build - use opportunity-management:risk-classification.
• Judging whether the knowledge the agent will ground on is fit to use - use m365-agents:knowledge-source-readiness.
• Writing the test plan and evaluation set - use m365-agents:agent-testing.
• Detailed topic, action, authentication and ALM design for a Copilot Studio build - use copilot-studio:studio-agent-design.

Questions to ask first

1. Who exactly will use the agent, in which roles, and what question or task brings them to it on a normal working day?
2. What should the agent never do or answer, even if asked politely, and where should it send people instead?
3. Which knowledge will it ground on, who owns each source, and could every intended user already open that content?
4. Does it only answer, or must it also act in another system, and who would be accountable for those actions?
5. Does an existing agent, prompt or published Copilot pattern already meet most of the need?
6. Who will own the agent after release, and who will users contact when it gives a wrong answer?

Required inputs

• The approved opportunity record and suitability decision, with business owner and problem statement, on the opportunity-canvas.
• The initial risk tier from opportunity-management:risk-classification.
• A list of candidate knowledge sources with their apparent owners.
• The organisation's approved agent-building routes and environments, from the CoE or platform team.

Where an input is missing, mark it "to confirm" in the brief and do not progress beyond a draft. In particular, never assume a build route is approved or licensed, and never name an owner who has not agreed.

Decision framework

Build the brief in this order; each row is a gate for the next.

For the build route, compare the options against criteria rather than products: whether the agent only answers or also acts, how wide the audience is, whether it needs custom orchestration or its own model, and which governance zone the organisation runs it in. Read the current capabilities and limits of Agent Builder, Copilot Studio and pro-code routes in the source records (ms-agents-compare, ms-agent-builder, ms-declarative-agents) at the time of the decision, and record what was checked.

Practitioner approach

Start with the person, not the agent. Sit with two or three intended users and ask them to show you the last time they needed the answer the agent is meant to give: where they looked, who they asked, how long it took and what went wrong. Write the purpose from that evidence in one sentence with a measure, for example "Help line managers answer routine absence-policy questions without raising a ticket, so HR advisers spend their time on complex cases." A purpose with "and" in it usually hides two agents.

Write the scope as real questions, not topics. Ten to twenty representative questions in the users' own words become the seed of the evaluation set later, so collect them now. Then write the out-of-scope list with equal care: the questions the agent must decline, the ones it must redirect to a person, and the ones that touch decisions about individuals. Every exclusion needs a destination, otherwise users experience a refusal as a dead end and stop using the agent.

Treat the instructions as a specification, not as clever prompting. The brief should state the role the agent plays, the tone, how it handles uncertainty, when it must cite a source, what it does when knowledge is silent, and how it behaves at the edges of scope. Leave the wording to the maker, but fix the behaviour here so testing has something to test against.

List each knowledge source with its owner, location, audience and the readiness verdict from m365-agents:knowledge-source-readiness. Because an agent answers with the permissions of the person asking, a source that is overshared today becomes easy to discover tomorrow; flag any doubt to the security-privacy reviewer early rather than at the gate.

If the agent must act, name each action, the system it touches, whether it reads or writes, whose identity it runs under, and whether the user must confirm before anything changes. Where the action is a fixed sequence, prefer an automation the agent calls over asking the model to improvise steps.

Before choosing a route, check the solution register and ask the CoE whether a similar agent exists. Extending an owned agent is cheaper than running two that drift apart. When building is justified, compare routes against the decision criteria and today's source records, not memory, and write down why the simpler route was not enough.

Close by agreeing ownership in writing: the business owner who answers for outcomes, the knowledge owners, the maker, and the support route. Add success measures with baselines, the review date, and the risk tier. Walk the business owner through the brief before any build starts; a brief they cannot explain back is not finished.

Outputs

• An agent brief on the agent-brief template: audience, purpose, scope and out-of-scope with redirects, instructions approach, knowledge sources with owners and readiness, actions, build-or-reuse decision and route rationale, ownership, support route, success measures and risk tier.
• A seed list of representative user questions, handed to m365-agents:agent-testing.
• A list of open questions and preconditions, each with an owner and a date.

Microsoft platform considerations

Declarative agents, agents built in Agent Builder, agents built in Copilot Studio and pro-code custom engine agents differ in how they are built, shared, governed and extended. The brief should record the criteria that led to the route, then confirm current capability, sharing options, limits and licensing from the source records, because these change frequently. Copilot Studio agents live in Power Platform environments, so the environment, data policy and governance zone are part of the route decision, not an afterthought.

Adoption considerations

An agent nobody knows about delivers nothing. Name the intended users' existing channels (team sites, manager briefings, Champion networks) in the brief so m365-agents:agent-release-readiness can plan communications. Involve a few users in writing the scope; they become the first advocates and the first honest testers.

Knowledge considerations

The agent's quality is capped by its knowledge. Every source needs an owner and a readiness verdict before build; unowned or stale sources are preconditions to fix, routed through m365-agents:knowledge-source-readiness and knowledge-management:knowledge-lifecycle. Prefer a small, curated source over a whole site.

Security and privacy considerations

Record the sensitivity of each knowledge source, the intended sharing scope, any personal data the agent might surface, and any action that changes data or reaches outside the tenant. From risk tier 2 these go to the security-privacy reviewer through security-privacy:data-exposure-review and security-privacy:connector-review.

Responsible AI considerations

If the agent's answers could inform decisions about people, money, safety or rights, write explicit human oversight into the scope and mark the case for responsible-ai:ai-impact-assessment via risk classification. Users must be able to tell they are dealing with an agent and where its answers come from.

Evaluation requirements

The brief must contain enough to test against: representative questions, expected behaviour at the edges, and refusal rules. The acceptance threshold itself is agreed by the business owner in m365-agents:agent-testing.

Value measures

Record the baseline from the problem statement (for example tickets raised, time to answer, rework) and the measure the business owner will use, with its source and review date. Measure at team or role level; never use agent data to judge individual staff.

Scale notes

Starter

One page is enough: audience, purpose, ten real questions, exclusions, two or three sources with owners, and the named owner. A partner may help choose the route. Most first agents should only answer, not act.

Scale

Use the full brief for every agent through the CoE intake, check the solution register for reuse as a standard step, and apply the governance zone the organisation has defined for each route.

Enterprise

Federate brief writing to business-unit agent product owners using the shared template, with the hub reviewing anything at risk tier 2 or above. Track briefs in the portfolio so overlapping agents are visible before they are built.

Hand-offs

• To m365-agents:knowledge-source-readiness for each knowledge source named in the brief.
• To m365-agents:agent-testing with the seed questions and behaviour rules.
• To security-privacy:data-exposure-review and security-privacy:connector-review from risk tier 2.
• To copilot-studio:studio-agent-design for detailed design of Copilot Studio builds.

Reviewer gates

From risk tier 2, the brief is reviewed by security-privacy for knowledge exposure, sharing scope and actions, and by design-authority:platform-fit-review for route choice and duplication, with the route challenge and response recorded on the brief.

Failure modes

• Scope is written as topics, so the agent answers confidently far outside what its knowledge supports.
• The maker becomes the owner by default, leaves the team, and the agent decays unnoticed.
• The route is chosen from familiarity, and the agent is rebuilt later when its limits are reached.
• A whole site is added as knowledge, surfacing overshared and outdated content to a wide audience.

Sources

references/sources.md in this skill lists the source records behind this skill, what each is authoritative for, how volatile it is and what you may do with it. Product availability, licensing, limits and preview status change often, so check the current source before stating them, and cite what you used.

Never

• Start a build without a named business owner who has agreed the brief.
• Leave exclusions for the instructions to infer, or decline a question without saying where to go instead.
• Choose a build route, or assert its capabilities, from memory rather than the current source records.
• Add knowledge sources that have no owner or readiness verdict.