Catalogue › Copilot Cowork › delegated-work-review

Delegated work review

Sets and applies the review a person carries out on a finished Copilot Cowork output before it is sent, filed, published or acted on, checking it against the definition of done, its sources, the audience and any actions taken, with a proportionate depth by consequence. Use when someone is about to use delegated output, when errors from Cowork reached others, or when a team needs a shared standard for checking delegated work.

Department

Copilot Cowork

Lifecycle

Deliver, Assure

Maturity

adopter, builder, scaler, ai-enterprise

Risk tiers

0, 1, 2, 3

Platforms

copilot-cowork, m365-copilot

Editions

starter, scale, enterprise

Reviewers

responsible-ai

Status

draft

Copilot Cowork

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

Licence

CC BY 4.0, by Simon Foote

Purpose

The final review is where the person who delegated takes the output back and makes it their own. It is the last chance to catch a wrong figure, a missing caveat, a sentence that should never reach that audience, or an action that should not happen. This skill gives teams a proportionate review standard for Cowork outputs and a way to apply it, so review is neither a skim of a confident-looking document nor a full redo that removes the point of delegating. It goes wrong when fluent, well-formatted output is taken as evidence of accuracy.

When to use

• A person is about to send, file, publish or act on an output produced by Cowork.
• An error from delegated work has reached a customer, colleague or decision and the team wants to prevent a repeat.
• A team needs a shared standard for what "checked" means for delegated outputs.
• A manager asks how the team assures work that Cowork helped to prepare.

When not to use

• Designing the approvals that happen during the run - use copilot-cowork:human-checkpoint-design.
• Testing a task design before people rely on it - use copilot-cowork:workflow-validation.
• Reviewing code produced with an AI coding agent - use copilot-code:generated-code-review.
• Teaching general habits for verifying Copilot responses in everyday use - use m365-copilot:prompting-practice.
• Formal oversight review of a tier 2 or higher solution - use responsible-ai:human-oversight.

Questions to ask first

1. Who will see or rely on this output, and what will they do because of it?
2. What was the definition of done, and does this output meet it?
3. Which claims, figures or statements in the output matter most, and can each be traced to a source?
4. Did the run take any action already, such as saving, sharing or scheduling, that needs checking or undoing?
5. Would you be comfortable putting your name to this output as if you had written it yourself?

Required inputs

• The output and, where available, the intermediate outputs and sources Cowork used.
• The definition of done from the task design.
• The intended audience and use of the output.
• The risk tier or, if none, the consequence level from the review depth table below.

If the sources cannot be seen, the reviewer cannot verify the key claims, and the output is treated as a draft to be checked by hand. Never review against an imagined standard; use the definition of done.

Decision framework

Set review depth by what the output will do.

Every review covers five checks: meets the definition of done; key claims trace to sources; nothing inappropriate for the audience; caveats and gaps stated; any actions taken are correct. An output that fails any check at the required depth is corrected or not used.

Practitioner approach

Start by reading the output as its recipient would, not as its commissioner. Ask what they will take from it and what they will do next. This shifts attention from "does this look finished" to "is this right and safe for them", and it often reveals a missing caveat or a sentence pitched at the wrong audience.

Identify the claims that matter. Most outputs have a few statements that carry the weight: a figure in a summary, a recommendation, a date, a commitment. Trace each to its source. If Cowork cited sources, open them and confirm the claim is actually there and from the authoritative version. If it did not, the depth of review rises, because nothing in the output can be taken on trust. Fluency is not evidence: a confident paragraph can rest on a misread table.

Look for what is missing as well as what is wrong. Did the output state where sources disagreed or were silent, as the task design asked? Were the known awkward cases handled? An output that is complete only because gaps were quietly filled with plausible content fails review, however polished it looks.

Check audience fit. Delegated work draws on everything the delegator can reach, so sensitive details from one context can appear in an output for another: a personal circumstance in a team update, an internal margin in a customer letter. Read specifically for names, figures and internal references that should not travel.

Check what already happened. If the run saved, shared or scheduled anything, confirm it went to the right place and the right people, and undo anything that should not stand.

Then decide and own it. The person who uses the output is accountable for it, in the same way as for work drafted by a colleague. If the review found errors, note the pattern: an error that recurs across outputs points to a fix in the task design, the sources or the checkpoints, and should go back through copilot-cowork:workflow-validation rather than being corrected by hand every time.

Outputs

• A review standard for the team, with depth by consequence and the five checks, recorded in the cowork-task-design template for shared designs.
• For each high-consequence output, a brief review note: who reviewed, what was checked, corrections made and any second reviewer.
• A log of recurring error patterns at team level, referred back to the task design owner.

Microsoft platform considerations

How Cowork shows its sources, intermediate outputs and actions taken may change with product updates. Confirm current behaviour in the source records (ms-copilot-cowork-customise, ms-copilot-overview) and adapt the review routine to what is visible. Where an output cannot show its sources, plan for a deeper manual check.

Adoption considerations

People adopt review habits when the standard is short and proportionate. Teach the five checks and the depth table, and share real examples of errors that review caught. Avoid messages that imply Cowork outputs need no checking; they erode trust when the first error appears.

Knowledge considerations

Errors traced to stale or conflicting sources should reach the source owner through copilot-cowork:grounding-readiness rather than being corrected silently in each output.

Security and privacy considerations

Read high-consequence outputs specifically for personal data, confidential figures and internal references that should not reach the audience. Where something sensitive appears, find out which source supplied it and whether that source is overshared, and report it.

Responsible AI considerations

The reviewer remains accountable for what is used. Where outputs inform decisions about individuals, the output is input to a human decision, never the decision itself. Consider whether recipients should be told AI helped prepare the output, in line with the organisation's transparency position.

Evaluation requirements

Not applicable as a separate evaluation; recurring review findings feed copilot-cowork:workflow-validation, which re-tests the design.

Value measures

Track, at team level, how many outputs pass review with light edits, how many need substantial correction and how many errors reach recipients, against the pre-Cowork baseline for the work. Never report review results for individuals.

Scale notes

Starter

Teach the five checks and the depth table to everyone using Cowork, and ask teams to note errors that reached others.

Scale

Build the review standard into every shared task design, collect recurring error patterns at team level and route them to design owners.

Enterprise

Set the depth table centrally, with business units adding domain-specific checks (for example regulated communications), and require second reviewers for high-consequence outputs at risk tier 2 and above.

Hand-offs

• To copilot-cowork:workflow-validation with recurring error patterns.
• To copilot-cowork:grounding-readiness with source-related errors.
• To responsible-ai:human-oversight from risk tier 2 for outputs that affect individuals.

Reviewer gates

From risk tier 2, responsible-ai reviews the review standard to confirm high-consequence outputs receive a real human decision with appropriate authority. Findings are blocking or advisory; absence of review for outputs that affect individuals is blocking.

Failure modes

• Polished formatting is taken as evidence of accuracy, and a misread figure goes to the board.
• Gaps filled with plausible content pass review because nobody checked what was missing.
• Sensitive details from one context appear in an output for another audience.
• The same error is corrected by hand every week instead of being fixed in the task design.

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

• Send, publish or act on a high-consequence output without checking its key claims against sources.
• Treat delegated output as the decision on a matter affecting an individual.
• Attribute accountability for a used output to the AI rather than the person who used it.
• Use review records to rank or monitor individual staff.