The M365 write-back brief: closing the status-update loop

What changed on 7 July 2026

This pattern is drawn from Claude Can Now Send Your Email. Should It? — The D*AI*LY Brief, which covers the write tools launch and the guardrails Anthropic shipped alongside it.

For most of 2026, the Microsoft 365 connector for Claude worked in one direction. Claude could read Outlook threads, Teams messages, SharePoint documents, and calendar history, then produce a draft you still had to copy, paste, and send yourself. That last step was small but persistent: one manual handoff per status cycle, per project, per stakeholder group.

Write tools close it. As of 7 July, Claude can draft and send Outlook email, create and update calendar events, and write files to OneDrive and SharePoint — all within your existing M365 permissions. The write tools ship off by default, require a Microsoft Entra admin to consent to the expanded permissions, and your Claude organisation must enable them. A typical individual cannot flip them on unilaterally.

What write tools cannot do is equally important: they cannot send email with attachments, they cannot act on Teams (which remains read-only), and they have no event triggers — actions only run when you instruct them, never automatically when mail arrives. Every email Claude sends carries an agent-attribution header in the email headers, which makes the action auditable and distinguishable from a human-sent message.

The write-back brief

This prompt requires the M365 connector enabled and write tools turned on. The pattern below is designed for a weekly status send, but the three-step structure adapts to any situation where you need to read before writing:

You have access to my Outlook, Teams, SharePoint, and OneDrive
via the M365 connector.

Step 1 — Gather context:
Read emails and Teams messages mentioning [Project X]
from the last 7 days.
Pull the most recent status document from SharePoint:
[folder name or file name].
List the top 3 open items, any blockers, and any decisions
made since last week.

Step 2 — Draft the update:
Write a status email to: [stakeholder names or distribution list]
Subject: [Project X] — Status update, week of [date]
Tone: direct and factual, under 200 words.
Do not include items with no change since last week.
Do not include forward-looking tasks that have not started.

Step 3 — Show me the draft before sending.
I will review it and say "send it", edit the draft,
or say "cancel".
Do not send until I confirm.

Why each instruction earns its keep

Name the project exactly. "Emails about the project" returns anything that loosely matches. The exact project name, team alias, or subject-line prefix your organisation uses cuts irrelevant threads at source. Claude cannot know your naming conventions; you do.

Pull the document of record. Status threads drift from the authoritative document over a week of replies and side conversations. Including the SharePoint file in Step 1 anchors the synthesis to what was actually agreed, not what someone restated in a reply.

Two exclusions, not a word count. "Under 200 words" is a format constraint. "No unchanged items" and "no not-yet-started tasks" are editorial constraints. The second type cuts the dead weight that inflates most status emails — the line about the thing that is still on track, still in progress, still coming next quarter. Removing it forces Claude to surface only what has genuinely changed.

The explicit approval gate. Step 3 is the non-negotiable. Write tools mean Claude can act on your behalf in your inbox. The review step means it does not act until you decide. Omitting "show me first" is technically possible; it is also the fastest way to send a draft you regret to a distribution list you cannot recall from. The one-sentence gate costs nothing and makes the workflow safe to repeat week after week.

Worked example

You manage a product launch across marketing, engineering, and legal. Every Friday you send a status email to a VP and three team leads. Before write tools, the loop was: ask Claude to summarise threads → copy the draft → open Outlook → paste → adjust the subject line → send.

With the write-back brief, you open Claude, run the prompt above with "Product Launch Q3" as the project name and the SharePoint status deck as the document reference. Claude reads the week's threads and the deck, shows you a 180-word draft. You read it, change one line about the legal review timeline, type "send it with that change", and Claude sends from your Outlook account with the updated line.

The total time in the loop goes from roughly twelve minutes (finding the right threads, writing the summary, formatting the email) to roughly four (reading the draft, making the edit, confirming the send). The review step is still there — it is just faster because the synthesis is already done.

What this will not do

The write-back brief does not replace judgement about what to share with whom. Claude reads recent threads and documents; it cannot read the political context behind a decision, the history with a stakeholder, or the fact that one recipient prefers bullet points and another prefers narrative prose. The draft is a first pass from a capable synthesiser. The review step is where your judgement applies.

The prompt also does not help if your organisation has not enabled write tools. The feature requires admin consent at the Microsoft Entra level and a Claude organisation setting. If you are on a Team or Enterprise plan, raise it with whoever manages your Claude organisation. If you are on a Pro or Max plan as an individual, write tools on personal tenancies follow the same admin-consent requirement on the M365 side.

Failure modes to watch

Vague Step 1 returns noisy synthesis. If the draft covers items you do not recognise, the project name in Step 1 is too broad. Use the exact project tag or subject prefix your team uses. Run the gather step alone first (Step 1 only, no draft) to confirm Claude is reading the right threads before asking it to draft.

Skipping the SharePoint pull. If you omit the document reference, Claude synthesises from threads only. Threads contain decisions-in-motion; the status document contains decisions-as-agreed. The gap between them is where most status-email errors live.

Approving without reading. The review step is only useful if you use it. The attribution header means the email is traceable as agent-sent, but it does not stop an inaccurate email from reaching the distribution list. Read the draft before confirming. The brief is designed to make that reading fast, not to replace it.