Transform2AI
RSS All posts
Skill July 9, 2026 · 7 min read

The Cowork dispatch brief: handing off work before you leave your desk

A five-part brief for handing a background task to Claude Cowork Dispatch so the output is waiting on your phone when you return.

TL;DR

Claude Cowork Dispatch runs tasks in the cloud while you're away from your desk. A five-part brief — goal, inputs, output format, stop conditions, quality check — turns a background session into something reliable enough to run on a schedule. Usage data released with the mobile launch shows 91% of Cowork sessions are non-coding work; Business Process and Operations is the largest category at 33%.

What changed this week

On 7 July 2026, Anthropic expanded Claude Cowork from desktop-only to mobile and web. This pattern is drawn from VentureBeat's coverage of the launch, which included the first usage breakdown Anthropic has published: 91.3% of sampled Cowork sessions had nothing to do with software development. Business Process and Operations — pulling status updates into a single report, reconciling spreadsheets, building onboarding checklists — was the single largest category at 33.4%.

The mobile expansion matters for one specific reason: Dispatch tasks now run in the cloud. You fire a task from any device, close the app, and pick up the finished output on any other screen when you're ready. That makes background task design — not prompt engineering in the traditional sense — the skill worth building.

What a dispatch task is

Dispatch is the background-execution mode in Cowork. You give it a high-level instruction and it works independently — reading connected tools, processing files, synthesising output — then saves the result to your project folder. You don't supervise it. You review the finished deliverable.

This is the part most people underestimate: because there are no follow-up questions, every edge case the agent encounters will be handled by whatever the brief implies. An underspecified brief doesn't produce a helpful clarifying message — it produces a confident, wrong output. The five-part structure below is what makes a dispatch task reliable rather than a gamble.

The brief

Copy this template. Fill in the bracketed sections. Send it as a Dispatch task in Cowork.

You are running as a background Dispatch task in Claude Cowork.
Execute this fully without waiting for input from me.

GOAL
[One sentence describing the deliverable, not the process.
Example: "Produce a Monday briefing showing last week's pipeline
movement, open support themes, and the three items needing an
owner this week."]

INPUTS
Read only the following sources, within the scope shown:
- [Tool or file + scope. Example: "HubSpot — deals updated in
  the last 7 days; show owner, stage, and next step only."]
- [Tool or file + scope. Example: "Zendesk — tickets opened and
  closed this week, grouped by tag."]
- [Tool or file + scope. Example: "Google Calendar — meetings
  this Mon–Fri with attendee names and agenda links."]

OUTPUT
Save as [filename]-[YYYY-MM-DD].md in [project folder].
Structure:
  1. Pipeline — up to 5 bullets. One deal per bullet.
     Include: owner, current stage, next step.
  2. Support themes — up to 5 bullets. Include ticket count
     and the most common resolution for each theme.
  3. Decisions needed — up to 3 items. Each item must name
     the owner, the deadline, and what is blocking progress.
Total length: under 400 words.

STOP CONDITIONS
If a data source is unavailable or returns an error, note the
gap in the output file rather than estimating. Do not fill
missing data from memory. If you cannot produce a verifiable
output after two attempts on any single source, stop and write
a short error note naming the source that failed.

QUALITY CHECK
Before saving, verify that each claim can be traced to a source
record (deal ID, ticket number, calendar entry). If you cannot
produce that trace, mark the claim [UNVERIFIED] rather than
removing it.

Why each part earns its keep

Goal. One sentence of outcome, not steps. Agents that receive step-by-step instructions tend to optimise for completing steps rather than producing useful output. Stating what you want to read — not how to produce it — gives the agent room to handle variation without losing the plot.

Inputs. Named sources with explicit scope limits stop the agent from pulling in every record a connected tool holds. Without a date range, a "last week's pipeline" brief can silently expand to pull six months of deal history and produce a document you didn't ask for.

Output. Format instructions do double duty. They tell the agent what to produce, and they give you a review checklist: if section 3 has four items instead of three, you know immediately that something ran outside its constraints — before you've read a single word of content.

Stop conditions. This is the brief's safety valve. Without them, an agent that hits an error will either halt with a useless message or — more dangerously — fill the gap from memory. "Note the gap" is more useful than either outcome, because a visible gap is reviewable. A gap filled from memory is invisible.

Quality check. The [UNVERIFIED] flag pattern does not prevent hallucination. It makes any unverifiable claim visible at review rather than buried in prose. That's a weaker guarantee than you'd want, but it is a much stronger guarantee than a brief without it.

What this won't do

It will not replace your review step. The stop conditions and quality check reduce risk; they don't eliminate it. Treat the output as a strong first draft, not a finished document. Check figures and dates before acting on them.

It is not right for tasks that require mid-task judgement. If the correct output depends on a decision that only you can make — "which of these deals should we prioritise?" — Dispatch is the wrong tool. Use a supervised Cowork session for that, where you're present for the handoff points.

It will not access tools you haven't connected. Before writing an Inputs line, confirm the relevant tool appears in your Cowork connected tools list. A brief that references an unavailable source will produce a stop-condition note rather than the expected data — which is the correct failure mode, but is still a failed run.

Monday morning

Start with one brief, one source, one output. A dispatch task that reads your project's latest status file and saves a three-paragraph summary is enough to build the habit. Confirm the output is what you asked for, then add a second input source next week. The brief earns its schedule only after you've run it manually twice.

Keep reading

All posts, sorted newest first →