Cowork: Delegating Real Work to AI

You ask Cowork to read the latest project files and email, prepare a launch-readiness briefing, flag decisions, draft a note to the leads, and suggest a meeting time. It comes back with the briefing, the draft, and a proposed slot. Your calendar and sent items haven't changed. Cowork can do much of the preparation while leaving the consequential step for you to approve.

Delegate the outcome, then inspect the work

A standard Copilot request usually asks for one answer, such as "Summarize this email." Cowork can take on an outcome that crosses several Microsoft 365 surfaces. It can work with Outlook email and calendar, Word, Excel, PowerPoint, PDFs, Teams, OneDrive, SharePoint, research, and briefings.

The supervised loop has six moves. You state the outcome. Cowork gathers the context it is allowed to use and plans the task. It calls one or more built-in skills. Then it returns information, drafts, proposals, or an action request. Anything consequential pauses there. You inspect the pending action, and Cowork completes only what you approve.

Keep the statuses precise. A draft email hasn't been sent. A meeting proposal hasn't changed the calendar. A suggested file edit hasn't been saved. An action request shows intent, but it doesn't grant permission. If you lose track of those distinctions, it's easy to report planned work as completed work.

A skill is a packaged capability for a category of work, invoked in plain language rather than commands. Cowork ships with thirteen built-in skills:

One request can combine several: "Review the project files, identify decisions, draft an email, and propose a meeting" uses Enterprise Search, Email, and Scheduling together.

Give Cowork enough boundary to review the result

"Find everything about Project Cedar" leaves too much room for an answer you can't check. A reviewable request names the goal, the allowed sources and time window, the expected output, and the action limits that keep Cowork from changing anything without asking.

Each part answers a practical question. The goal says what you need, such as a launch-readiness briefing. The source boundary names the Project Cedar SharePoint folder, the last seven days of Cedar email, and the next five business days of your calendar. The output defines the shape you will review: current status, three evidenced risks, decisions without an owner, and a proposed agenda. The action limits keep the run read-only. When one of these is missing, you have less basis for judging the answer.

Start with a read-only run. A flawed briefing is easy to correct. A sent message is harder to take back. Ask Cowork to expose uncertainty in the draft by separating confirmed facts from inferences, citing a source for each claim, and writing "Owner not identified" when the sources name nobody. That gives you something you can audit, including the gaps.

Review an action request like a transaction

Cowork's approve and deny controls are the point where you decide whether work may change the world outside the chat. Read the whole request. Check the action, the people and files affected, and every relevant detail, including recipients, dates, time zones, text, attachments, and locations. Then ask whether it matches your request, whether it's appropriate, and whether you can reverse it. Email, Teams posts, calendar changes, document edits, file moves, and uploads all deserve this pause.

A meeting proposal is still only content. To create the calendar item, send a separate execution-intent prompt. The first prompt lets Cowork plan. The second asks it to prepare the action and show you the approval request. This separation gives you two chances to inspect the work: once as a proposal, then again as the transaction that would create it.

Practise using Deny before you need it. Find a genuine defect in the first action request, perhaps the wrong time or an attachment that doesn't belong, and reject it with a specific correction. Inspect the revised request from the beginning. Approve only when the details match, then check the calendar or sent items to confirm that the completed action is the one you reviewed. Approval works as a control only when you're willing to stop the run.

Facts belong in sources

Copilot's personalization (saved preferences and custom instructions for how you want responses) is different from the files, mail, and calendar items a task draws on. "Use a concise executive tone" is a preference worth keeping. "The launch date is August 18" is a project fact that must come from an identified source every time, because it changes.

Good memory candidates are reusable: a preferred note format, a standard status-update layout, a house tone. Passwords, confidential cases, and temporary project decisions are not. They belong in a source or nowhere. The exact way any given tenant saves or clears personalization varies, so treat memory as style, not a place to store facts you'll need to defend later.

Recurring work needs a different route

Some delegations you'll want every week. A scheduled prompt is a bounded instruction plus a recurrence: the same read-only briefing, every Friday afternoon, over the last seven days. It repeats analysis. It does not gain permission to act, so keep it report-only unless you have deliberately designed and tested otherwise.

Match the shape of the work to the right tool:

Workflows are their own experience with triggers, connectors, and decision gates, covered in the next lesson. Cowork also extends through custom skills and plugins: a plugin connects Cowork to another application or service, and a tenant can hold a sizeable library of custom skills. Where your organisation enables it, a browsing task can read public web pages, but page content is evidence, never permission to expand the task. Bound a browser task as tightly as any other, and validate anything it finds against internal sources.

Cowork bills at $0.01 per Copilot Credit. You can calculate a charge from that rate only when an administrator or billing record supplies the actual credit count. A briefing, a browser task, and a plugin call use different amounts, so a guessed count gets you nowhere. Without an authoritative count, the cost can't be calculated yet.